| openstackgerrit | Tony Breeds proposed openstack/mistral-dashboard: Add Constraints support https://review.openstack.org/413300 | 00:51 |
|---|---|---|
| *** bobh has joined #openstack-mistral | 01:03 | |
| *** harlowja has joined #openstack-mistral | 01:06 | |
| openstackgerrit | yunfeng zhou proposed openstack/mistral-dashboard: add CONTRIBUTING.rst https://review.openstack.org/412865 | 01:06 |
| openstackgerrit | yunfeng zhou proposed openstack/mistral-specs: add CONTRIBUTING.rst https://review.openstack.org/412866 | 01:07 |
| *** harlowja has quit IRC | 01:44 | |
| *** sharatss has quit IRC | 03:18 | |
| *** sharatss has joined #openstack-mistral | 03:18 | |
| *** bobh has quit IRC | 03:22 | |
| rakhmerov | kong_: please have a look at https://review.openstack.org/#/c/410567/ again | 03:58 |
| rakhmerov | I need these patches very much | 03:58 |
| openstackgerrit | Merged openstack/mistral-dashboard: Updated from global requirements https://review.openstack.org/413149 | 04:12 |
| *** thrash is now known as thrash|g0ne | 04:45 | |
| openstackgerrit | Merged openstack/mistral-dashboard: Workflow list - added missing fields https://review.openstack.org/412517 | 04:56 |
| openstackgerrit | Merged openstack/mistral-dashboard: add CONTRIBUTING.rst https://review.openstack.org/412865 | 04:57 |
| openstackgerrit | Merged openstack/mistral-specs: add CONTRIBUTING.rst https://review.openstack.org/412866 | 04:57 |
| openstackgerrit | Merged openstack/mistral-dashboard: Add Constraints support https://review.openstack.org/413300 | 04:59 |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral: Refresh object state after lock acquisition in WithItemsTask https://review.openstack.org/413416 | 05:36 |
| *** sharatss has quit IRC | 05:48 | |
| *** dkushwaha has joined #openstack-mistral | 05:55 | |
| *** dkushwaha has left #openstack-mistral | 05:56 | |
| *** Qiming has quit IRC | 06:01 | |
| *** Qiming has joined #openstack-mistral | 06:07 | |
| *** ist has joined #openstack-mistral | 06:28 | |
| *** sharatss has joined #openstack-mistral | 06:56 | |
| sharatss | rakhmerov: hi | 07:03 |
| rakhmerov | hi | 07:04 |
| rakhmerov | how can I help you, sir? :) | 07:04 |
| *** jaosorior has joined #openstack-mistral | 07:17 | |
| sharatss | rakhmerov: https://bugs.launchpad.net/mistral/+bug/1649366 do u think this is valid sir? :)) | 07:20 |
| openstack | Launchpad bug 1649366 in Mistral "body for std.email seems to actually be required - throws error when not present" [Undecided,Confirmed] - Assigned to Sharat Sharma (sharat-sharma) | 07:20 |
| rakhmerov | let me see | 07:20 |
| rakhmerov | sharatss: Yes, the bug looks valid | 07:21 |
| rakhmerov | but I think I've seen a patch for it already | 07:21 |
| sharatss | rakhmerov: my doubt is whether the body has to optional or the subject | 07:22 |
| sharatss | rakhmerov: definitely both should not be optional | 07:22 |
| rakhmerov | well, you're talking about a different aspect | 07:22 |
| rakhmerov | this bug says that the doc says "optional" but, in fact, it's not optional | 07:23 |
| rakhmerov | not whether it should be optional or not | 07:23 |
| rakhmerov | it just states a mismatch | 07:23 |
| rakhmerov | from this perspective it's valid | 07:23 |
| rakhmerov | the other thing is that how it should be | 07:24 |
| rakhmerov | I think the answer is: does SMTP protocol allow empty subject and body? | 07:24 |
| rakhmerov | if yes, then I see no reason why not keep them optional | 07:24 |
| *** ist has quit IRC | 07:24 | |
| *** shardy has joined #openstack-mistral | 07:24 | |
| rakhmerov | I'm pretty sure that subject can be empty in SMTP | 07:24 |
| rakhmerov | not sure about body though | 07:25 |
| rakhmerov | makes sense? | 07:25 |
| sharatss | rakhmerov: in code we have subject as optional. should this be changed in doc as well or a code change is required to make body optional | 07:25 |
| rakhmerov | again, I don't know at this point | 07:26 |
| rakhmerov | please check what SMTP says | 07:26 |
| rakhmerov | if it allows them to be empty then we need to change our docs | 07:27 |
| rakhmerov | sorry | 07:27 |
| rakhmerov | the code | 07:27 |
| rakhmerov | so that they are optional in both docs and implementation | 07:27 |
| sharatss | rakhmerov: i just checked | 07:28 |
| sharatss | rakhmerov: both can be optional | 07:28 |
| rakhmerov | ok, so? | 07:28 |
| rakhmerov | ok | 07:28 |
| rakhmerov | let's do so | 07:28 |
| sharatss | rakhmerov: yea.. | 07:29 |
| rakhmerov | ok :) | 07:29 |
| openstackgerrit | Sharat Sharma proposed openstack/mistral: Make body of std.email optional https://review.openstack.org/413468 | 07:48 |
| *** openstackgerrit has quit IRC | 07:48 | |
| *** _gryf has quit IRC | 08:16 | |
| *** _gryf has joined #openstack-mistral | 08:21 | |
| *** mgershen has joined #openstack-mistral | 08:22 | |
| *** mgershen has quit IRC | 08:36 | |
| *** jpich has joined #openstack-mistral | 08:52 | |
| *** gongysh has joined #openstack-mistral | 08:54 | |
| gongysh | kong_, hi | 08:54 |
| *** jaosorior has quit IRC | 08:58 | |
| *** jaosorior has joined #openstack-mistral | 08:58 | |
| *** chlong has quit IRC | 09:34 | |
| *** mgershen has joined #openstack-mistral | 09:47 | |
| rakhmerov | kong_: thanks! | 10:04 |
| *** mgershen has quit IRC | 10:05 | |
| *** ^Gal^ has joined #openstack-mistral | 10:06 | |
| ddeja | Hi rakhmerov | 10:20 |
| rakhmerov | hi | 10:20 |
| ddeja | I found the problem with failing tests | 10:21 |
| rakhmerov | ok | 10:21 |
| rakhmerov | what is it this time? | 10:21 |
| ddeja | let me find the line in github | 10:21 |
| ddeja | https://github.com/openstack/mistral/blob/master/mistral/engine/rpc_backend/rpc.py#L67-L75 | 10:22 |
| ddeja | rakhmerov: so, we are using global to store the engine_client object | 10:22 |
| ddeja | and we use wsgi to start the API | 10:22 |
| ddeja | wsgi startes a number of workers with API, which are greenthreads | 10:23 |
| rakhmerov | they are processes | 10:23 |
| rakhmerov | not greenthreads | 10:23 |
| rakhmerov | AFAIK | 10:23 |
| ddeja | hm from debbuging it looks like theye were greenthreads | 10:23 |
| ddeja | but that doesn't matter | 10:23 |
| ddeja | the point is | 10:24 |
| rakhmerov | ok | 10:24 |
| ddeja | we got 2 threads using same engine_client object | 10:24 |
| kong_ | rakhmerov: np :-) | 10:24 |
| ddeja | so in a very rare (but not rare enaught) situation when tow threads want to send something over RPC at the same time | 10:24 |
| rakhmerov | :) | 10:24 |
| kong_ | the patches all look good | 10:24 |
| kong_ | gongysh: hi | 10:24 |
| gongysh | hi | 10:25 |
| kong_ | gongysh: how are u, man | 10:25 |
| gongysh | how is the life? | 10:25 |
| ddeja | rakhmerov: they both try to use same http socket | 10:25 |
| kong_ | gongysh: not bad | 10:25 |
| rakhmerov | ddeja: ok, go on pls | 10:25 |
| gongysh | kong_, me either. | 10:25 |
| rakhmerov | same http socket? | 10:25 |
| ddeja | which result in simultaneus fileread error | 10:25 |
| rakhmerov | oooh, damn... | 10:25 |
| ddeja | rakhmerov: yes, rpc is using http sockets deep down ;) | 10:26 |
| rakhmerov | I think I understand | 10:26 |
| ddeja | so, my idea is to change the lines I've just send you | 10:26 |
| gongysh | kong_, http://docs.openstack.org/developer/mistral/architecture.html | 10:26 |
| ddeja | so we don't use global, but local thread storage instead | 10:26 |
| rakhmerov | wait a sec.. | 10:26 |
| gongysh | kong_, is the mistral arch doc right? | 10:26 |
| rakhmerov | let me think | 10:26 |
| ddeja | so each thread got it's own client object | 10:27 |
| rakhmerov | let's think | 10:27 |
| rakhmerov | about pros and cons | 10:27 |
| ddeja | but I'm not sure if it's good idea, so that is why I write here instead of sending a patch :) | 10:27 |
| rakhmerov | client object seems to be pretty cheap to create, right? | 10:27 |
| rakhmerov | nothing like a heavy initialization etc. | 10:27 |
| ddeja | yes | 10:28 |
| rakhmerov | it's just a simple object parameterized with rpc info | 10:28 |
| rakhmerov | hm... | 10:28 |
| ddeja | but we don't want to spawn a lot of it, since each keeps an RPC connection to AMQP broker | 10:28 |
| rakhmerov | yes, that's what I thought too | 10:28 |
| ddeja | but one per process should be OK | 10:29 |
| rakhmerov | so, does this happen only in case of our Kombu RPC? | 10:29 |
| rakhmerov | or with oslo.m too? | 10:29 |
| ddeja | I've never seen it with oslo | 10:29 |
| ddeja | there may be some locking mechanism inside | 10:29 |
| rakhmerov | ok, so we're talking only about Kombu | 10:29 |
| ddeja | or oslo internaly may have a lot of workers | 10:29 |
| rakhmerov | I see | 10:29 |
| kong_ | gongysh: yes, i think so | 10:30 |
| ddeja | rakhmerov: that is another approach | 10:30 |
| ddeja | I can make kombu_client thread-safe | 10:30 |
| gongysh | kong_ is the 'scheduler' an process? | 10:30 |
| gongysh | kong_, do we have such process? | 10:30 |
| *** Qiming has quit IRC | 10:30 | |
| ddeja | (well, I'd like to made it multi-thread support during Ocata cycle) | 10:31 |
| kong_ | gongysh: it's a periodic task running inside mistral-engine actually | 10:31 |
| rakhmerov | ddeja: since this is pluggable (currently o.m and kombu) we need to define requirements for implementation | 10:31 |
| rakhmerov | if that should be thread-safe it needs to be thread-safe :) | 10:31 |
| rakhmerov | for all of them | 10:31 |
| rakhmerov | because a calling code doesn't know what it calls | 10:31 |
| rakhmerov | what impl | 10:31 |
| ddeja | rakhmerov: yes. Right now I'm treating the o.m as an reference driver | 10:32 |
| rakhmerov | so the question is: 1) do we specify that implementation can be not thread-safe 2) opposite | 10:32 |
| rakhmerov | ok | 10:32 |
| ddeja | OK, so I'll jump into the o.m | 10:32 |
| ddeja | to check if there are some mechanism that prevents it | 10:33 |
| ddeja | or we are just lucky ;) | 10:33 |
| rakhmerov | ddeja: I mean it's probably ok if we say "we allow them to be not thread-safe" | 10:33 |
| rakhmerov | just brainstorming.. | 10:33 |
| ddeja | then I'll proceed with a fix | 10:33 |
| rakhmerov | yes | 10:33 |
| gongysh | kong_ where is the event-engine? | 10:33 |
| ddeja | rakhmerov: Ok, thanks a lot Renat! | 10:34 |
| rakhmerov | np | 10:34 |
| rakhmerov | many thanks to you | 10:34 |
| * kong_ goes to pm to give rakhmerov and ddeja dedicated channel :-) | 10:34 | |
| rakhmerov | you do awesome job on ivestigating such issues :) | 10:34 |
| rakhmerov | kong_: no! | 10:34 |
| rakhmerov | we're almost finished :) | 10:35 |
| ddeja | kong_: we just finished I guess ;) | 10:35 |
| *** Qiming has joined #openstack-mistral | 10:35 | |
| rakhmerov | ddeja: so, just one question: why did you say "one per process is enough"? | 10:35 |
| rakhmerov | not sure I understand.. | 10:35 |
| rakhmerov | and I'm surprised why you saw workers implemented as green threads | 10:35 |
| ddeja | I meant that: there should be no simultaneus reads error and on the other hand, we should not create too many connections | 10:36 |
| ddeja | rakhmerov: I may misread something in logs | 10:36 |
| rakhmerov | if you look at oslo.service project you'll see that there's two things: ServiceLauncher and ProcessLauncher | 10:36 |
| rakhmerov | the latter is for using with workers as separate threads | 10:36 |
| ddeja | and, ps aux | grep mistral shows more than one API service, so there are really threads :) | 10:36 |
| rakhmerov | maybe for unit tests it runs differently | 10:36 |
| rakhmerov | ooh, ok :) | 10:37 |
| rakhmerov | system threads | 10:37 |
| rakhmerov | this is important :) | 10:37 |
| rakhmerov | I mean operating system threads | 10:37 |
| ddeja | but nevertheless, still they use same connection and sometimes try to use it at the same time, and it of course is not working :) | 10:37 |
| rakhmerov | hm... | 10:38 |
| rakhmerov | ok | 10:38 |
| rakhmerov | so, I would say: it would be cool if we could make Kombu thread-safe, but I can't tell right away how problematic it is | 10:39 |
| rakhmerov | you need to look into this.. | 10:39 |
| ddeja | rakhmerov: I know how to do this, that's not a problem | 10:39 |
| rakhmerov | awesome | 10:39 |
| ddeja | I was just not sure if it's right approach | 10:40 |
| *** mgershen has joined #openstack-mistral | 10:47 | |
| ddeja | rakhmerov: I've checked - oslo is using something called 'connection pools' internally | 11:02 |
| ddeja | it get's new connection from pool for each message | 11:02 |
| ddeja | that is why we don't see this error in oslo | 11:03 |
| *** openstackgerrit has joined #openstack-mistral | 11:04 | |
| openstackgerrit | Merged openstack/mistral: Get rid of with_items.py module in favor of WithItemsTask class https://review.openstack.org/410567 | 11:04 |
| rakhmerov | ddeja: yeah, typical pool pattern | 11:06 |
| rakhmerov | is it their own pool implementation? | 11:06 |
| rakhmerov | I wonder if we can reuse something like this | 11:06 |
| rakhmerov | from some generic lib (of course, not o.m) | 11:06 |
| ddeja | rakhmerov: no, they are using pika-pool | 11:07 |
| ddeja | but what is worse | 11:07 |
| ddeja | it seems like kombu is also using connection pools right now | 11:07 |
| rakhmerov | :))) | 11:07 |
| rakhmerov | the game is getting more interesting? :) | 11:07 |
| *** sharatss has quit IRC | 11:08 | |
| ddeja | rakhmerov: wait, no | 11:08 |
| ddeja | ok | 11:08 |
| ddeja | there is a difference | 11:08 |
| *** sharatss has joined #openstack-mistral | 11:08 | |
| ddeja | in docs for using pools: "from kombu.pools import producers" | 11:08 |
| ddeja | in our code "from kombu import producers" | 11:08 |
| ddeja | (not excactly that, but this is the problem) | 11:09 |
| ddeja | but hmm, it looks like it points to the same place | 11:10 |
| ddeja | OK, so now I know nothing | 11:10 |
| rakhmerov | :) | 11:11 |
| rakhmerov | it happens | 11:11 |
| * ddeja is getting back to debbuging | 11:12 | |
| ddeja | I'll send a patch once I got it working | 11:12 |
| *** gongysh has quit IRC | 11:13 | |
| openstackgerrit | Gal Margalit proposed openstack/mistral-dashboard: Fixed: Dashboard: "Run action" functionality doesn't work https://review.openstack.org/413152 | 11:14 |
| openstackgerrit | Merged openstack/mistral: Slightly improve 'with-items' tests https://review.openstack.org/410676 | 11:18 |
| openstackgerrit | Merged openstack/mistral: Apply locking to control 'with-items' concurrency https://review.openstack.org/410690 | 11:18 |
| openstackgerrit | Merged openstack/mistral: Fix 'with-items' task completion condition https://review.openstack.org/412341 | 11:18 |
| rakhmerov | ddeja: ok | 11:21 |
| rakhmerov | ddeja, d0ugal, kong_, hparekh: could some of you please look at https://review.openstack.org/#/c/413416/ ? It is small but very important | 11:21 |
| rakhmerov | great, thanks d0ugal | 11:25 |
| d0ugal | np | 11:25 |
| rakhmerov | you made me happy :) | 11:25 |
| d0ugal | haha | 11:25 |
| * d0ugal is reviewing all the things | 11:25 | |
| d0ugal | (but mostly in TripleO so far) | 11:25 |
| openstackgerrit | Merged openstack/mistral: Small adjustments in WithItemsTask https://review.openstack.org/412761 | 11:28 |
| rakhmerov | :) | 11:28 |
| d0ugal | I guess this is technically isn't backwards compatible.... but is that okay? https://review.openstack.org/#/c/412389/ | 11:32 |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral: Add a test for 'with-items' task: count=100, concurrency=10 https://review.openstack.org/413574 | 11:39 |
| *** thrash|g0ne is now known as thrash | 11:45 | |
| *** mgershen has quit IRC | 11:48 | |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral: Add rally tests for 'join': 100 and 500 parallel tasks https://review.openstack.org/413586 | 11:57 |
| *** mgershen has joined #openstack-mistral | 12:04 | |
| *** shardy is now known as shardy_lunch | 12:05 | |
| openstackgerrit | Merged openstack/mistral: Refresh object state after lock acquisition in WithItemsTask https://review.openstack.org/413416 | 12:17 |
| *** mgershen has quit IRC | 12:29 | |
| openstackgerrit | Merged openstack/mistral: Fix configuration generator https://review.openstack.org/412256 | 12:52 |
| openstackgerrit | Merged openstack/mistral: Added test cases for a few possible scenarios https://review.openstack.org/409117 | 12:52 |
| *** shardy_lunch is now known as shardy | 12:55 | |
| *** weshay_afk is now known as weshay | 12:56 | |
| *** mgershen has joined #openstack-mistral | 13:06 | |
| *** jtomasek has joined #openstack-mistral | 13:10 | |
| *** dprince has joined #openstack-mistral | 13:17 | |
| *** gongysh has joined #openstack-mistral | 13:30 | |
| *** gongysh has quit IRC | 13:34 | |
| *** shardy has quit IRC | 13:35 | |
| *** mgershen has quit IRC | 13:48 | |
| *** sharatss has quit IRC | 13:50 | |
| *** sharatss has joined #openstack-mistral | 13:51 | |
| *** jaosorior has quit IRC | 14:21 | |
| *** jaosorior has joined #openstack-mistral | 14:21 | |
| Qiming | hi, guys | 14:47 |
| Qiming | I'm studying mistral api | 14:48 |
| Qiming | it seems that a workflow update request can be posted to /v2/workflows directly, without providing an ID, am I understanding this correctly? | 14:49 |
| Qiming | oh, the verb is PUT, but ... still, the workflow ID is not required, right? | 14:49 |
| *** dprince has quit IRC | 14:52 | |
| *** dprince has joined #openstack-mistral | 14:54 | |
| *** bobh has joined #openstack-mistral | 14:57 | |
| *** mgershen has joined #openstack-mistral | 15:00 | |
| *** bobh has quit IRC | 15:31 | |
| d0ugal | Qiming: correct. | 15:34 |
| d0ugal | Qiming: Workflows are referenced by name - which is in the workflow definition | 15:35 |
| d0ugal | I don't really know why we need ID :) | 15:35 |
| d0ugal | Maybe it was just added incase we need it in the future? | 15:35 |
| d0ugal | rakhmerov: ^ | 15:35 |
| *** ^Gal^ has quit IRC | 15:39 | |
| *** jamielennox is now known as jamielennox|away | 15:46 | |
| *** openstackgerrit_ has joined #openstack-mistral | 15:47 | |
| *** openstackgerrit_ has quit IRC | 15:49 | |
| *** bobh has joined #openstack-mistral | 15:49 | |
| d0ugal | is mistral.tests.unit.services.test_trigger_service.TriggerServiceV2Test.test_trigger_create faiing for anyone else? | 15:50 |
| *** chlong has joined #openstack-mistral | 15:52 | |
| *** jamielennox|away is now known as jamielennox | 15:54 | |
| *** bobh has quit IRC | 16:00 | |
| *** jaosorior has quit IRC | 16:03 | |
| *** ^Gal^ has joined #openstack-mistral | 16:05 | |
| d0ugal | jpich: so I am currently investigating https://github.com/openstack/mistral/blob/master/mistral/services/triggers.py#L28-L34 | 16:23 |
| jpich | d0ugal: Is that what gets called in the problematic test? | 16:24 |
| d0ugal | jpich: yeah, well, create_cron_trigger | 16:24 |
| d0ugal | jpich: yeah, well, create_cron_trigger in that file gets called. | 16:24 |
| d0ugal | jpich: but the call to that small function is the only bit that looks suspicious (unless the issue is at the database leveel) | 16:24 |
| *** ^Gal^_ has joined #openstack-mistral | 16:25 | |
| *** ^Gal^ is now known as Guest10260 | 16:25 | |
| *** ^Gal^_ is now known as ^Gal^ | 16:25 | |
| rakhmerov | d0ugal, Qiming: on the API question Dougal's answer is 100% correct. As far as id, it's needed when it comes to e.g. multiple tenants | 16:28 |
| rakhmerov | tenants can have workflows with same names actually | 16:29 |
| rakhmerov | and the thing is that these workflows in some cases need to be accessible from many tenants | 16:29 |
| d0ugal | jpich: so, "local_time" is correct. https://github.com/openstack/mistral/blob/master/mistral/services/triggers.py#L29 | 16:29 |
| d0ugal | jpich: it matches what the test expects. | 16:29 |
| rakhmerov | either if they are created with scope=public or if a workflow is shared by one tenant with another one through resource sharing mechanism | 16:30 |
| d0ugal | jpich: something in the following two lines takes it back an hour | 16:30 |
| *** ^Gal^ has quit IRC | 16:30 | |
| rakhmerov | d0ugal: is this test failing for you locally? | 16:30 |
| d0ugal | rakhmerov: Yup | 16:30 |
| rakhmerov | hm.. | 16:31 |
| rakhmerov | let me check | 16:31 |
| d0ugal | rakhmerov: and jpich confirmed it as failing too, so it isn't only me | 16:31 |
| *** bobh has joined #openstack-mistral | 16:31 | |
| *** bobh has quit IRC | 16:31 | |
| rakhmerov | yes | 16:32 |
| rakhmerov | same to me | 16:32 |
| rakhmerov | weird | 16:32 |
| d0ugal | rakhmerov: interesting ;) | 16:32 |
| rakhmerov | it passes on our gates, doesn't it? | 16:32 |
| d0ugal | rakhmerov: yup, it does. | 16:32 |
| d0ugal | rakhmerov: which OS are you running? | 16:32 |
| rakhmerov | Mac OS | 16:32 |
| rakhmerov | Sierra | 16:32 |
| d0ugal | k, good - so not specific to Feodra :) | 16:32 |
| rakhmerov | nope | 16:32 |
| d0ugal | (I think that is good?) | 16:32 |
| rakhmerov | yeah :) | 16:33 |
| rakhmerov | it's not only your trouble :) | 16:33 |
| d0ugal | hah | 16:33 |
| d0ugal | rakhmerov: it must be late for you? | 16:33 |
| rakhmerov | yes, kind of | 16:33 |
| rakhmerov | I'll go to bed soon | 16:33 |
| rakhmerov | so recently ddeja made changes related to how we store time | 16:35 |
| d0ugal | Yeah, I guess that must be related. | 16:35 |
| rakhmerov | I wonder if that's related | 16:35 |
| jpich | d0ugal: I changed my timezone and the difference was 5 hours rather than one, some kind of UTC vs local time issue? | 16:36 |
| jpich | reference = datetime.datetime(2010, 8, 25, 0, 5) - actual = datetime.datetime(2010, 8, 25, 5, 5) | 16:36 |
| d0ugal | jpich: interesting. | 16:36 |
| rakhmerov | jpich: yeah, right.. Let me find a patch that may have affected this | 16:38 |
| openstackgerrit | Dougal Matthews proposed openstack/mistral: Testing without utc https://review.openstack.org/413713 | 16:38 |
| d0ugal | jpich, rakhmerov: ^ that fixes the test for me. I am interested to see what happens when CI runs it. | 16:39 |
| rakhmerov | https://review.openstack.org/#/c/406740/ | 16:39 |
| rakhmerov | I didn't have a chance to review this patch | 16:39 |
| rakhmerov | maybe it introduces some issue | 16:39 |
| d0ugal | yeah, so that patch did introduce the line I just changed. | 16:40 |
| rakhmerov | :) | 16:40 |
| jpich | Other places in that patch seem to expect utc | 16:41 |
| openstackgerrit | Dougal Matthews proposed openstack/mistral: Testing without utc https://review.openstack.org/413713 | 16:41 |
| d0ugal | wow gerrit is slow today | 16:41 |
| rakhmerov | d0ugal: so now tests pass only if local time is UTC ? | 16:41 |
| d0ugal | rakhmerov: I don't really understand yet. | 16:42 |
| rakhmerov | ok | 16:42 |
| d0ugal | I think the problem might be that we go from a datetime with a timzone to the epoch seconds which doesn't have a timezone | 16:42 |
| rakhmerov | gerrit is also very slow | 16:43 |
| d0ugal | then we convert that back to a datetime | 16:43 |
| rakhmerov | ooh, you said gerrit, yes (i thought about something different) | 16:43 |
| d0ugal | :-D | 16:43 |
| rakhmerov | maybe, yes | 16:43 |
| openstackgerrit | Dougal Matthews proposed openstack/mistral: [WIP] Testing without utc https://review.openstack.org/413713 | 16:45 |
| d0ugal | I will need to stop shortly, but I guess I will look into this tomorrow. | 16:46 |
| rakhmerov | please do | 16:46 |
| rakhmerov | I'm off for today too | 16:46 |
| d0ugal | That CI test patch causes another totally unrelated unit test to fail for me locally | 16:52 |
| d0ugal | lol | 16:52 |
| d0ugal | mistral.tests.unit.api.v2.test_tasks.TestTasksController.test_put_current_task_in_error | 16:52 |
| d0ugal | jpich: how do you change your tz? just in gnome settings? | 16:53 |
| *** Kiall has quit IRC | 16:53 | |
| jpich | d0ugal: rm /etc/localtime, ln -s /usr/share/zoneinfo/America/Chicago /etc/localtime (as sudo) | 16:53 |
| d0ugal | fancy | 16:54 |
| jpich | I like the style, changing tz by symlink :) | 16:54 |
| d0ugal | kinda scary | 16:54 |
| d0ugal | okay, I might use that tomorrow. | 16:55 |
| jpich | Gerrit seems like it might need a reboot, getting a lot of proxy errors | 16:55 |
| jpich | Good luck! | 16:55 |
| d0ugal | Yeah, gerrit is so so slow | 16:55 |
| d0ugal | partly why I am leaving :) | 16:55 |
| *** openstack has quit IRC | 17:02 | |
| *** openstack has joined #openstack-mistral | 17:04 | |
| *** jpich has quit IRC | 17:08 | |
| *** mgershen has quit IRC | 17:17 | |
| *** bobh has joined #openstack-mistral | 17:37 | |
| *** bobh has quit IRC | 17:46 | |
| *** dprince has quit IRC | 17:46 | |
| *** dprince has joined #openstack-mistral | 17:46 | |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral: Add rally tests for 'join': 100 and 500 parallel tasks https://review.openstack.org/413586 | 17:53 |
| *** jtomasek has quit IRC | 19:22 | |
| *** dprince has quit IRC | 19:34 | |
| *** weshay is now known as weshay_relocatin | 19:42 | |
| *** sharatss has quit IRC | 20:30 | |
| *** sharatss has joined #openstack-mistral | 20:30 | |
| *** chlong has quit IRC | 20:36 | |
| *** chlong has joined #openstack-mistral | 20:52 | |
| *** weshay_relocatin is now known as weshay | 21:05 | |
| *** sharatss has quit IRC | 21:58 | |
| openstackgerrit | Lingxian Kong proposed openstack/mistral: Role based resource access control - get workflows https://review.openstack.org/413791 | 22:02 |
| *** chlong has quit IRC | 22:04 | |
| *** bobh has joined #openstack-mistral | 22:14 | |
| *** bobh has quit IRC | 22:31 | |
| *** bobh has joined #openstack-mistral | 23:46 | |
| *** thrash is now known as thrash|g0ne | 23:48 | |
| *** catintheroof has joined #openstack-mistral | 23:48 | |
| *** bobh has quit IRC | 23:51 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!