15:08:46 #startmeeting mistral 15:08:47 Meeting started Mon Apr 23 15:08:46 2018 UTC and is due to finish in 60 minutes. The chair is d0ugal. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:08:48 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:08:50 The meeting name has been set to 'mistral' 15:08:51 Hey folks, sorry for the late start. 15:08:58 I was a little ambitious in a 5km run. 15:09:13 d0ugal, rakhmerov, apetrich, bobh, mcdoker181818 ^ 15:09:19 Welcome to the Mistral office hour :) 15:09:26 or, the Mistral 50 mins really. 15:10:20 o/ 15:10:31 \ะพ 15:10:36 o/ 15:10:57 Anyone got anything to discuss? 15:11:13 d0ugal: I'm working on this: https://review.openstack.org/#/c/554950/ 15:11:20 thrash: I'd like chat about that CI issue... any idea how we can move forward with it? 15:11:34 and found an issue - there are two different sort_keys options 15:11:42 one by mistral API and one by cliff 15:11:51 d0ugal: not sure atm... is there any chatter on the ml? 15:11:54 bobh: looking, I hadn't seen this patch yet. 15:12:01 thrash: good question, I'll have a search. 15:12:09 d0ugal: looking too 15:12:35 d0ugal: also the fields option conflicts with the formatter - if you don't select the fields the formatter is expecting it complains 15:12:49 bobh: does this mean that we overwrite the cliff sort_keys? 15:12:58 no - they both get used 15:13:07 d0ugal: but they can conflict 15:13:09 oh, so they have different cli args? 15:13:15 sounds confusing :/ 15:13:43 d0ugal: definitely 15:13:58 cliff provides -c and that gets applied after the formatter is done 15:14:03 for field selection 15:14:18 right, I use -c all the time. 15:14:42 cliff is also providing a sort column option, which gets applied after the formatter as well 15:15:08 I'm not sure if it can do asc/desc - maybe with a - prefix 15:15:44 bobh: is the cliff sort client-side only? 15:15:48 yes 15:16:01 which actually makes my problem easier I think 15:16:12 yeah, and it could be possibly useful? 15:16:14 since I'll tell the server to get the data I want then let cliff sort it 15:16:28 i.e. I want to get the 100 newest from mistral but then sort them by status client side 15:16:34 exactly! 15:16:35 kinda weird, but almost makes sense. 15:16:42 almost :) 15:16:49 I'll take almost 15:17:17 bobh: so do you think we need to change anything or it is okay? 15:17:33 assuming I can get a desc sort to work in cliff, I think it makes sense to remove the sort_keys and sort_dirs CLI options that operate on the server-side 15:17:43 and force the user to use the cliff options 15:17:55 d0ugal: there is a thread about it, but not much of a resolution. 15:17:58 it simplifies things and makes them work 15:18:22 same with --fields - remove it for -c instead 15:18:33 d0ugal: let me see what it takes to fix on our end. 15:20:33 bobh: hmm, I think we need the server side sort. 15:21:03 thrash: thanks, I'll see if I can take a look later 15:21:09 bobh: I am trying to think of an example... 15:21:12 we need it for retrieving oldest vs newest 15:21:28 bobh: not just oldest or newest - you could sort by other cols? 15:21:37 but once you have the dataset you want, the sort can be handled on the client? 15:22:07 bobh: what if I want to get the 100 newest task's that are in ERROR state 15:22:20 that's a filter - status=ERROR 15:22:23 oh yeah 15:22:26 damn 15:22:30 Maybe I don't have a good example :) 15:22:34 I could just be wrong. 15:23:02 I'll play with it some more and update the patchset 15:23:10 bobh: but generally I agree, it would be good to make things simpler - we do need to take into account backwards compatability tho' 15:23:37 d0ugal: we could convert the sort_keys/sort_dirs options to the appropriate cliff input 15:23:50 yeah, that makes sense 15:23:55 and display a deprecation warning 15:24:04 then remove them in the S or T cyclre 15:24:08 cycle* 15:24:11 d0ugal: yes 15:26:53 I'll look out for an update on the patch :) 15:27:14 d0ugal: thanks 15:27:31 We still have 0 "NEW" bugs :) 15:27:51 I plan to create one :) 15:28:37 https://review.openstack.org/#/c/563479/1/mistral/tests/unit/engine/test_direct_workflow.py 15:29:10 mcdoker181818: oh yeah, I started looking at this :) 15:29:25 mcdoker181818: so the problem is that it should end with an error from the exception, not the timeout? 15:29:43 wf was failed by timeout but i think it was finished successfully 15:29:45 actually, no, you expect SUCCESS :) 15:30:29 I don't understand how it would be successful. 15:30:46 Can you walk me through it? 15:31:12 First timeout still works after retry but I expect that task will create a new timeout delayed call and previous timeout delayed call was skipped 15:31:36 oh, I see. So the task should only fail once. 15:31:40 yep 15:32:28 mcdoker181818: so you think it should have a timeout of 3 seconds for each action execution? 15:32:58 I expect this :) 15:33:07 Interesting. 15:33:11 I don't :) 15:33:16 I think the timeout is for the task itself. 15:33:46 We use the timeout in quite a few places in tripleo 15:34:25 mcdoker181818: https://github.com/openstack/tripleo-common/blob/4739027b9eaf3dc895b29b67dbca0ffc79b36d4b/workbooks/stack.yaml#L18-L24 15:34:45 How should timeout work with retry? 15:34:46 mcdoker181818: in our use case, having the timeout be per-action-execution doesn't make sense :) 15:35:11 mcdoker181818: I think they are unrelated. 15:35:27 To me the timeout is for how long the task tasks 15:35:33 But timeout will retry task 15:35:40 retry then means the task can take longer 15:36:10 mcdoker181818: really? so if you hit the timeout it will then trigger the retry? 15:36:15 and that retry will timeout instantly? 15:36:42 No 15:37:10 But you say that this is bug https://bugs.launchpad.net/mistral/+bug/1764441 15:37:11 Launchpad bug 1764441 in Mistral "Timeout policy doesn't work with retry policy properly" [High,In progress] - Assigned to Vitalii Solodilov (mcdoker18) 15:37:37 in previous meeting 15:38:07 mcdoker181818: workflows should never be stuck in RUNNING. 15:38:23 I believe that is a similar, but different issue. 15:39:50 It might be a good idea to chat about this when rakhmerov is around - to get some historical perspective. 15:40:55 Maybe i create a email? [openstack-dev][mistral] 15:41:00 Sure, good idea. 15:41:31 Brad P. Crochet proposed openstack/mistral stable/pike: Avoid tox_install.sh for constraints support https://review.openstack.org/563674 15:41:33 d0ugal: ^^^ 15:41:42 ooh 15:41:54 d0ugal: that might should do it. :) 15:42:41 d0ugal: if tox_install don't exist, it won't call it. :) 15:42:59 works for me 15:48:38 Dougal Matthews proposed openstack/mistral stable/pike: Correct the string formatting in a info log message https://review.openstack.org/562046 15:58:46 I gotta run and take care of a few things 15:58:53 So I'm going to end the meeting bot. 15:59:29 On Friday I plan to start going through the bugs and blueprints assigned to Rocky-2. 15:59:35 Should be fun :) 15:59:37 Thanks everyone 15:59:39 #endmeeting