15:02:43 #startmeeting mistral 15:02:43 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:47 The meeting name has been set to 'mistral' 15:02:59 o/ 15:03:38 Hey bobh 15:04:06 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 I plan on continuing with some Mistral bug triage today! 15:05:38 Unless anyone has anything to discuss. 15:05:45 bobh: Do you have anything? 15:06:29 two quick things: 15:07:21 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 bobh: Do you have an example? is there a bug? 15:08:16 I think it's actually the root cause of several existing bugs 15:09:58 Doug Hellmann proposed openstack/python-mistralclient master: add lower-constraints job https://review.openstack.org/556147 15:11:37 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 bobh: right 15:13:41 so the calling workflow is left in RUNNING state when the lower level workflow goes to ERROR 15:13:58 Interesting, I had not hit that problem 15:14:01 We should fix it :) 15:14:05 :-) 15:14:51 bobh: Is this something you want to work on? 15:14:55 bobh: do we have a bug for it? 15:15:00 I need it so I'm happy to work on it 15:16:09 bobh: sounds good, let me know if I can help 15:16:26 ok - I'll open a bug - or see if there is an existing bug I can reuse 15:17:20 bobh: https://bugs.launchpad.net/mistral/+bug/1756353 15:17:21 Launchpad bug 1756353 in Mistral "Mistral workflow stuck in RUNNING state after error "list index of range" encountered" [Medium,Triaged] 15:17:50 Maybe that is similar, but if it is my comment on it is wrong :) 15:17:57 I think that is different actually 15:21:31 bobh: I can't find a bug, so I guess it is best to open one 15:21:36 bobh: what was the other thing you had? 15:21:40 d0ugal: ok 15:22:02 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 d0ugal: if I don't pass the input the default is used 15:22:50 bobh: what if I wanted to pass in null and have null be used? :) 15:23:07 d0ugal: yeah that's the problem :-) 15:23:11 bobh: I think that would be confusing. 15:23:20 Why do you want it to use the default when you pass null? 15:23:56 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 bobh: right, I see the problem 15:24:42 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 hmm 15:26:34 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 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 bobh: I think it would be a tricky problem to solve 15:28:09 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 d0ugal: yes, and probably not worth the risk of breakage 15:28:25 bobh: I think that makes sense, yes 15:28:36 bobh: if the sub-workflow fails then the task that started that workflow should error. 15:30:00 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 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 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 mcdoker181818: go to Settings -> Watched Projects and add mistral to the list of watched projects 15:31:09 mcdoker181818: you can turn it on in the gerrit settings 15:31:13 ^ what bobh said :) 15:31:35 It can be very noisy! 15:31:39 d0ugal: thanks - I'll figure out a workaround 15:32:08 noisy but interesting - always seems to be someone working on something 15:33:09 True. 15:33:40 Thank you all 15:34:55 d0ugal: thanks - I'll see if I can reproduce the issue on master and open a bug 15:35:04 bobh: thanks 15:49:41 bobh, d0ugal: I guess this is the bug bobh is talking about: https://bugs.launchpad.net/mistral/+bug/1743649 15:49:42 Launchpad bug 1743649 in Mistral "Bad jinja template prevents upstream action execution from completing" [Medium,Triaged] - Assigned to Hardik Jasani (hjasani) 15:49:54 Similar to above, https://bugs.launchpad.net/mistral/+bug/1661094 15:49:55 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 hardikjasani: yes, that looks like it! 15:50:27 hardikjasani: thanks. 15:50:28 I am going to start working on it from tomorrow. 15:50:53 oh, nice 15:50:58 bobh: ^ 15:52:30 hardikjasani: it sounds like bobh would be willing to help test it if nothing else :) 15:55:31 Sure, more help is always welcome :) 15:58:03 hardikjasani: Thanks - that looks similar to what I'm seeing 16:00:43 That is us at the end of the hour 16:00:50 I'll be around for a bit longer if there is anything else 16:01:00 but I'll stop the meeting bot before I forget 16:01:03 #endmeeting