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