15:02:43 <d0ugal> #startmeeting mistral 15:02:43 <openstack> Meeting started Mon Apr 9 15:02:43 2018 UTC and is due to finish in 60 minutes. The chair is d0ugal. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:47 <openstack> The meeting name has been set to 'mistral' 15:02:59 <bobh> o/ 15:03:38 <d0ugal> Hey bobh 15:04:06 <d0ugal> so I am continuing with my experiment to log the office hours and also use this etherpad for taking notes: https://etherpad.openstack.org/p/mistral-office-hours 15:05:10 <d0ugal> I plan on continuing with some Mistral bug triage today! 15:05:38 <d0ugal> Unless anyone has anything to discuss. 15:05:45 <d0ugal> bobh: Do you have anything? 15:06:29 <bobh> two quick things: 15:07:21 <bobh> workflow failures don't trigger error leg processing (exception caught in task_handler force fails the workflow) and I'm wondering if there is a way to trigger the error legs 15:07:59 <d0ugal> bobh: Do you have an example? is there a bug? 15:08:16 <bobh> I think it's actually the root cause of several existing bugs 15:09:58 <openstackgerrit> Doug Hellmann proposed openstack/python-mistralclient master: add lower-constraints job https://review.openstack.org/556147 15:11:37 <bobh> Any YAQL/Jinja or sub-workflow error that triggers an exception will not propagate the error handling up to higher-level workflows 15:13:34 <d0ugal> bobh: right 15:13:41 <bobh> so the calling workflow is left in RUNNING state when the lower level workflow goes to ERROR 15:13:58 <d0ugal> Interesting, I had not hit that problem 15:14:01 <d0ugal> We should fix it :) 15:14:05 <bobh> :-) 15:14:51 <d0ugal> bobh: Is this something you want to work on? 15:14:55 <d0ugal> bobh: do we have a bug for it? 15:15:00 <bobh> I need it so I'm happy to work on it 15:16:09 <d0ugal> bobh: sounds good, let me know if I can help 15:16:26 <bobh> ok - I'll open a bug - or see if there is an existing bug I can reuse 15:17:20 <d0ugal> bobh: https://bugs.launchpad.net/mistral/+bug/1756353 15:17:21 <openstack> Launchpad bug 1756353 in Mistral "Mistral workflow stuck in RUNNING state after error "list index of range" encountered" [Medium,Triaged] 15:17:50 <d0ugal> Maybe that is similar, but if it is my comment on it is wrong :) 15:17:57 <d0ugal> I think that is different actually 15:21:31 <d0ugal> bobh: I can't find a bug, so I guess it is best to open one 15:21:36 <d0ugal> bobh: what was the other thing you had? 15:21:40 <bobh> d0ugal: ok 15:22:02 <bobh> d0ugal: wondering if a null input passed to a workflow that has a default value for the input should be overriding the default 15:22:32 <bobh> d0ugal: if I don't pass the input the default is used 15:22:50 <d0ugal> bobh: what if I wanted to pass in null and have null be used? :) 15:23:07 <bobh> d0ugal: yeah that's the problem :-) 15:23:11 <d0ugal> bobh: I think that would be confusing. 15:23:20 <d0ugal> Why do you want it to use the default when you pass null? 15:23:56 <bobh> d0ugal: I wanted the parameter to be optional at the top level workflow but the lower level workflow requires it and so has a default 15:24:26 <d0ugal> bobh: right, I see the problem 15:24:42 <d0ugal> you would need to have two tasks in the top-level workflow, one that passes the input and one that doesn't 15:24:44 <d0ugal> hmm 15:26:34 <bobh> d0ugal: I'm using dynamic workflow names so I have to build the dict to send in the parameters, so I could use Jinja to update the dict with the parameter if it is non-null otherwise leave it out so it picks up the default 15:26:55 <bobh> d0ugal: it's just a lot of effort, but it might be the only way since null could be valid as you say 15:27:49 <d0ugal> bobh: I think it would be a tricky problem to solve 15:28:09 <bobh> d0ugal: on the first issue, do you think it would be reasonable to check to see if the workflow being force-failed is a subworkflow, and if it is trigger the task error processing in the parent workflow? 15:28:24 <bobh> d0ugal: yes, and probably not worth the risk of breakage 15:28:25 <d0ugal> bobh: I think that makes sense, yes 15:28:36 <d0ugal> bobh: if the sub-workflow fails then the task that started that workflow should error. 15:30:00 <bobh> d0ugal: that's what I thought - I'll test it on master, I think the environment where we saw the issue is on stable/pike, so it might have been fixed in queens 15:30:01 <mcdoker181818> Hi all. How can i receive all notification about activity in https://review.openstack.org/#/q/project:openstack/mistral (new MR, changes of MR, merged MR, etc) ? 15:30:54 <d0ugal> bobh: for the null problem - I guess the sub-workflow could have a task to check if the input is null, and if it is, use the default - does mean you would need to duplicate it... 15:31:05 <bobh> mcdoker181818: go to Settings -> Watched Projects and add mistral to the list of watched projects 15:31:09 <d0ugal> mcdoker181818: you can turn it on in the gerrit settings 15:31:13 <d0ugal> ^ what bobh said :) 15:31:35 <d0ugal> It can be very noisy! 15:31:39 <bobh> d0ugal: thanks - I'll figure out a workaround 15:32:08 <bobh> noisy but interesting - always seems to be someone working on something 15:33:09 <d0ugal> True. 15:33:40 <mcdoker181818> Thank you all 15:34:55 <bobh> d0ugal: thanks - I'll see if I can reproduce the issue on master and open a bug 15:35:04 <d0ugal> bobh: thanks 15:49:41 <hardikjasani> bobh, d0ugal: I guess this is the bug bobh is talking about: https://bugs.launchpad.net/mistral/+bug/1743649 15:49:42 <openstack> Launchpad bug 1743649 in Mistral "Bad jinja template prevents upstream action execution from completing" [Medium,Triaged] - Assigned to Hardik Jasani (hjasani) 15:49:54 <hardikjasani> Similar to above, https://bugs.launchpad.net/mistral/+bug/1661094 15:49:55 <openstack> Launchpad bug 1661094 in Mistral "join task stuck in waiting if jinja fails to evaluate action input parameter" [High,New] - Assigned to Hardik Jasani (hjasani) 15:50:13 <d0ugal> hardikjasani: yes, that looks like it! 15:50:27 <d0ugal> hardikjasani: thanks. 15:50:28 <hardikjasani> I am going to start working on it from tomorrow. 15:50:53 <d0ugal> oh, nice 15:50:58 <d0ugal> bobh: ^ 15:52:30 <d0ugal> hardikjasani: it sounds like bobh would be willing to help test it if nothing else :) 15:55:31 <hardikjasani> Sure, more help is always welcome :) 15:58:03 <bobh> hardikjasani: Thanks - that looks similar to what I'm seeing 16:00:43 <d0ugal> That is us at the end of the hour 16:00:50 <d0ugal> I'll be around for a bit longer if there is anything else 16:01:00 <d0ugal> but I'll stop the meeting bot before I forget 16:01:03 <d0ugal> #endmeeting