| *** altlogbot_1 has quit IRC | 00:23 | |
| *** irclogbot_1 has quit IRC | 00:23 | |
| *** threestrands has quit IRC | 00:32 | |
| *** irclogbot_3 has joined #openstack-mistral | 01:34 | |
| *** irclogbot_3 has quit IRC | 01:39 | |
| *** irclogbot_1 has joined #openstack-mistral | 01:40 | |
| *** irclogbot_1 has quit IRC | 01:43 | |
| *** apetrich has quit IRC | 02:10 | |
| *** irclogbot_0 has joined #openstack-mistral | 02:54 | |
| *** irclogbot_0 has quit IRC | 02:59 | |
| *** irclogbot_2 has joined #openstack-mistral | 03:34 | |
| *** irclogbot_2 has quit IRC | 03:39 | |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral master: Add "published_global" field to the task execution REST resource https://review.opendev.org/678530 | 03:56 |
|---|---|---|
| openstackgerrit | Renat Akhmerov proposed openstack/mistral master: Fix 'with-items' expression evaluation https://review.opendev.org/679203 | 03:57 |
| *** gkadam has joined #openstack-mistral | 03:59 | |
| *** gkadam_ has joined #openstack-mistral | 04:01 | |
| *** gkadam_ has quit IRC | 04:01 | |
| *** irclogbot_1 has joined #openstack-mistral | 04:02 | |
| *** gkadam has quit IRC | 04:03 | |
| *** irclogbot_1 has quit IRC | 04:07 | |
| *** ricolin_ has joined #openstack-mistral | 04:08 | |
| *** ricolin_ has quit IRC | 04:08 | |
| *** ricolin has joined #openstack-mistral | 04:10 | |
| *** irclogbot_2 has joined #openstack-mistral | 04:22 | |
| *** irclogbot_2 has quit IRC | 04:33 | |
| *** eyalb has joined #openstack-mistral | 04:50 | |
| openstackgerrit | Andras Kovi proposed openstack/mistral master: Improve workflow notifications and webhook data https://review.opendev.org/679795 | 05:20 |
| *** irclogbot_3 has joined #openstack-mistral | 05:20 | |
| *** irclogbot_3 has quit IRC | 05:25 | |
| *** jtomasek has joined #openstack-mistral | 06:06 | |
| *** ricolin_ has joined #openstack-mistral | 06:15 | |
| *** irclogbot_0 has joined #openstack-mistral | 06:16 | |
| *** ricolin has quit IRC | 06:17 | |
| *** irclogbot_0 has quit IRC | 06:21 | |
| *** irclogbot_0 has joined #openstack-mistral | 06:24 | |
| *** irclogbot_0 has quit IRC | 06:29 | |
| *** pgaxatte has joined #openstack-mistral | 06:51 | |
| *** apetrich has joined #openstack-mistral | 07:23 | |
| *** irclogbot_1 has joined #openstack-mistral | 07:30 | |
| *** irclogbot_1 has quit IRC | 07:35 | |
| *** cervigni has joined #openstack-mistral | 07:36 | |
| *** abdelal has joined #openstack-mistral | 07:47 | |
| *** abdelal has quit IRC | 07:48 | |
| *** irclogbot_1 has joined #openstack-mistral | 07:51 | |
| *** irclogbot_1 has quit IRC | 07:53 | |
| *** abdelal has joined #openstack-mistral | 07:58 | |
| rakhmerov | vgvoleg: hi :) | 08:02 |
| rakhmerov | hi everyone | 08:02 |
| rakhmerov | meeting? | 08:02 |
| vgvoleg | yes | 08:04 |
| vgvoleg | hi | 08:04 |
| vgvoleg | I'd like to discuss 2 blueprints | 08:04 |
| rakhmerov | #startmeeting Mistral | 08:06 |
| openstack | Meeting started Wed Sep 4 08:06:19 2019 UTC and is due to finish in 60 minutes. The chair is rakhmerov. Information about MeetBot at http://wiki.debian.org/MeetBot. | 08:06 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 08:06 |
| *** openstack changes topic to " (Meeting topic: Mistral)" | 08:06 | |
| rakhmerov | vgvoleg: ok | 08:06 |
| openstack | The meeting name has been set to 'mistral' | 08:06 |
| rakhmerov | go ahead | 08:06 |
| rakhmerov | eyalb, abdelal, apetrich: ^ | 08:06 |
| vgvoleg | First of all, this one https://blueprints.launchpad.net/mistral/+spec/mistral-task-skipping-feature | 08:07 |
| apetrich | o/ | 08:07 |
| eyalb | o/ | 08:07 |
| vgvoleg | It's already done in our fork, but I didn't see any reaction here :( | 08:07 |
| abdelal | o/ | 08:07 |
| rakhmerov | vgvoleg: ok, let me read (again) | 08:07 |
| vgvoleg | I've done changes in cloudflow too to support this | 08:08 |
| vgvoleg | Just tell me that it would be useful and I'll push it :) | 08:09 |
| vgvoleg | https://sun9-12.userapi.com/c854220/v854220580/df9c0/j5PU_qZKAi8.jpg | 08:10 |
| vgvoleg | something like this | 08:10 |
| abdelal | a question regarding that , if t2 published x1 , how will you pass it to t3 since t2 is skipped ? | 08:11 |
| vgvoleg | skipped task also has publish section | 08:12 |
| vgvoleg | it works the same way | 08:12 |
| abdelal | it will publish even if it was skipped ? | 08:12 |
| vgvoleg | oh wait | 08:12 |
| vgvoleg | Maybe I understand you wrong | 08:12 |
| vgvoleg | there is 'publish-on-skip' section | 08:13 |
| rakhmerov | no-no, I think we can't publish anything using the regular "publish" if the state is not SUCCESS | 08:13 |
| vgvoleg | where you can, for example, mock data | 08:13 |
| rakhmerov | vgvoleg: are you aware of different syntax that you can use to publish vars? | 08:13 |
| vgvoleg | It is OK with publish-on-error | 08:14 |
| rakhmerov | you can have publish under "on-success", "on-error", etc. | 08:14 |
| vgvoleg | I don't see any differences with publish-on-skip | 08:14 |
| rakhmerov | vgvoleg: I think we shouldn't mix these things | 08:14 |
| vgvoleg | we didn't mix them | 08:15 |
| vgvoleg | it is another publish section | 08:15 |
| rakhmerov | different states => different language key words | 08:15 |
| vgvoleg | if task is skipped, no 'publish' will be published | 08:15 |
| vgvoleg | :) | 08:15 |
| rakhmerov | vgvoleg: that's right | 08:15 |
| rakhmerov | vgvoleg: regular "publish" and "publish-on-error" will be deprecated I think soon | 08:16 |
| rakhmerov | we'll be encouraging people to use "publish" under "on-..." | 08:16 |
| rakhmerov | where you can define scopes (currently "branch" and "global") | 08:16 |
| vgvoleg | the only thing I'm not sure about is what we should do if task don't have 'on-skip' branch | 08:16 |
| rakhmerov | I'm thinking may be we shouldn't even introduce this "publish-on-skip" | 08:17 |
| rakhmerov | vgvoleg: so, it's still a bit confusing to me.. | 08:17 |
| vgvoleg | In our fork, if we skip a task with no 'on-skip' section, we use 'on-success' | 08:17 |
| rakhmerov | vgvoleg: no, I disagree with this approach | 08:18 |
| rakhmerov | it should be a totally separate things | 08:18 |
| rakhmerov | thing | 08:18 |
| rakhmerov | vgvoleg: can you express with one phrase why this functionality is needed? :) | 08:18 |
| rakhmerov | this whole thing | 08:18 |
| rakhmerov | I'm still struggling with the idea I guess | 08:19 |
| rakhmerov | apetrich, eyalb, abdelal: may be you have some thoughts | 08:19 |
| rakhmerov | vgvoleg: so we do skipping if what? | 08:19 |
| rakhmerov | on an external failure? | 08:20 |
| vgvoleg | If the flow execution is too long, it will be great to have an opportunity to skip a failed task in the tail of the flow | 08:20 |
| apetrich | sorry, I'm trying to understand it too. | 08:20 |
| vgvoleg | if there is an external failure | 08:20 |
| vgvoleg | so retry will not help | 08:20 |
| vgvoleg | So it is all about a manual control of the flow | 08:21 |
| vgvoleg | like rerun, cancel, pause | 08:21 |
| openstackgerrit | Eyal proposed openstack/mistral master: Add a cookiecutter template to generate custom stuff https://review.opendev.org/679782 | 08:22 |
| vgvoleg | If we see that result of the task is not so important right now, we can skip this task and continue the execution of the flow | 08:22 |
| rakhmerov | ok | 08:22 |
| *** irclogbot_0 has joined #openstack-mistral | 08:23 | |
| *** akovi has joined #openstack-mistral | 08:23 | |
| akovi | hi All! | 08:23 |
| rakhmerov | akovi: hi Andras | 08:23 |
| rakhmerov | we're discussing https://blueprints.launchpad.net/mistral/+spec/mistral-task-skipping-feature | 08:23 |
| vgvoleg | and we should be sure that the execution will not break | 08:23 |
| vgvoleg | so we provide an opportunity to 'mock' any data in 'publish-on-skip' | 08:24 |
| rakhmerov | vgvoleg: what's the problem if it breaks? | 08:24 |
| rakhmerov | it will just have status "ERROR" but it will do all the work | 08:24 |
| vgvoleg | in case we need something from 'publish' in further | 08:25 |
| rakhmerov | maybe you just need some mechanisms (in your system) to interpret the results of a failed workflow correctly? | 08:25 |
| *** ricolin_ is now known as ricolin | 08:25 | |
| vgvoleg | We can't expect every situation | 08:25 |
| *** irclogbot_0 has quit IRC | 08:25 | |
| rakhmerov | vgvoleg: again, as far as "publish-on-skip", I'm not sure we need this at all | 08:25 |
| rakhmerov | but may be for the sake of symmetry, we need to do both options: "publish-on-skip" and the totally new clause "on-skip" that can have "publish" inside just like for other "on-xxx" things | 08:26 |
| vgvoleg | I'm not sure if I understand you right | 08:27 |
| rakhmerov | ok | 08:27 |
| vgvoleg | you just say about global problems | 08:27 |
| rakhmerov | no | 08:27 |
| vgvoleg | not about problems of this feature? | 08:27 |
| rakhmerov | I'm talking about the new syntax for "publish" | 08:27 |
| rakhmerov | no-no, it's related | 08:28 |
| rakhmerov | that's why I touched it | 08:28 |
| akovi | so, to clarify: the basic idea is to let a task be skipped before rerunning it. Right? | 08:28 |
| vgvoleg | Ok I got it | 08:28 |
| rakhmerov | akovi: even after running it | 08:28 |
| rakhmerov | vgvoleg: is that right? | 08:28 |
| vgvoleg | akovi: yes, we skip the task and rerun the workflow | 08:28 |
| akovi | the execution fails, we skip the task and rerun | 08:29 |
| akovi | ok | 08:29 |
| rakhmerov | yep | 08:29 |
| vgvoleg | Consider the situation: in the flow there is a task that requests any data from a third-party service while it is dead. Retries will not help in this situation, the task will go to the ERROR terminal state and the workflow will finish its work. Starting the workflow from the very beginning can be very expensive - it could have been several days bef | 08:29 |
| vgvoleg | ore the fall. For such cases in the mistral there is a rerun mechanism - a certain decision maker determines whether circumstances have changed (whether third-party service has come to life), and if so, the workflow will continue its work from the fallen task. | 08:29 |
| rakhmerov | because "retry" wouldn't make sense in many cases | 08:29 |
| vgvoleg | n fact, the environment cannot always stabilize, and it can be very expensive to adapt the workflow to work with a new environment. Also it is not always possible to automatically assess the nature of the error that led to the fall. It can be something fatal, and maybe something insignificant, which in general does not affect the execution of the w | 08:29 |
| vgvoleg | hole workflow. The decision maker can assess how important the results of the current task are and continue the execution of the workflow if not important. | 08:29 |
| vgvoleg | yes | 08:29 |
| vgvoleg | it's flom blueprint :D | 08:29 |
| rakhmerov | I figured ) | 08:29 |
| vgvoleg | all the arguments are there | 08:29 |
| akovi | this is probably useful when wfs are executed under human surveillance | 08:30 |
| vgvoleg | yes | 08:30 |
| rakhmerov | vgvoleg: too many arguments, usually if we can't express an idea with 1 phrase then it's a bad idea ) | 08:30 |
| rakhmerov | akovi: well, yes, it's exactly about that | 08:30 |
| rakhmerov | akovi: basically, that way we provide more ways for humans to influence workflow executions | 08:31 |
| akovi | so my general stance on wfs is that if needed, they should be implemented in an idempotent way | 08:32 |
| rakhmerov | so I guess, I'm not against it if 1) It's 100% backwards compatible (shouldn't be a problem here) 2) if it's a totally separate feature that doesn't interfere with existing stuff | 08:32 |
| akovi | however, it's freaking hard in many cases | 08:32 |
| rakhmerov | by #2 I mean that it doesn't reuse "on-success" etc. | 08:32 |
| rakhmerov | akovi: yeah.. | 08:32 |
| akovi | I think this feature is a useful one. | 08:33 |
| vgvoleg | It would be very comfortable to reuse 'on-success' if 'on-skip' is missed | 08:33 |
| akovi | Unfortunately it will work in many cases only if the publish-on-skip closure is defined in the wf spec | 08:34 |
| rakhmerov | vgvoleg: no, let's please not do this | 08:34 |
| vgvoleg | In many cases we want to continue 'on-success' execution | 08:34 |
| rakhmerov | well, on the other hand... | 08:34 |
| vgvoleg | So we will have duplicates | 08:34 |
| vgvoleg | in every task | 08:34 |
| rakhmerov | I know you want, but I'm not sure at all if other people will want ) | 08:35 |
| rakhmerov | I want to make sure we have the common sense here | 08:35 |
| vgvoleg | akovi: yes, that's the main idea: if you want to use this feature, be sure that your flow is ready for this | 08:35 |
| rakhmerov | vgvoleg: they you can have "on-skip" where needed | 08:36 |
| akovi | what if we omit the publish-on-skip and substitute it with a noop task that just publishes the same values? | 08:36 |
| rakhmerov | vgvoleg: I somewhat don't like the idea to reuse "on-success" | 08:36 |
| vgvoleg | rakhmerov: it's not a problem if we have 'on-skip: t1, on-success: t1' | 08:36 |
| rakhmerov | other people can say "we want to consider such tasks failed but w/o moving them to ERROR status) | 08:36 |
| vgvoleg | but if we have a long array with next tasks, duplicating them would be ugly | 08:36 |
| rakhmerov | vgvoleg: why? | 08:37 |
| rakhmerov | why ugly? | 08:37 |
| rakhmerov | it's just about your case | 08:37 |
| rakhmerov | but like I said, we're a considering a completely different even that may happen in a workflow | 08:37 |
| rakhmerov | and different people may treat it differently | 08:38 |
| rakhmerov | that's why I want to make it more generic and not let it interfere with the existing mechanisms | 08:38 |
| vgvoleg | well, I can write some docs... :D | 08:38 |
| rakhmerov | docs for what? | 08:38 |
| vgvoleg | For this feature | 08:38 |
| akovi | wf: | 08:38 |
| akovi | task1: | 08:38 |
| akovi | action: some_custom_action | 08:38 |
| akovi | publish: | 08:38 |
| akovi | var1: <% task (). result.var1%> | 08:38 |
| akovi | var2: <% task (). result.var2%> | 08:39 |
| akovi | var3: <% task (). result.var3%> | 08:39 |
| akovi | on-success: task2 | 08:39 |
| akovi | on-skip: task2 | 08:39 |
| akovi | skipped-task1: | 08:39 |
| akovi | action: std.noop | 08:39 |
| akovi | publish: | 08:39 |
| akovi | var1: "var1" | 08:39 |
| akovi | var2: "var2" | 08:39 |
| vgvoleg | If something is described in docs, it is legal | 08:39 |
| rakhmerov | vgvoleg: let me put it this way: you may want to have lots of repeating tasks in "on-success" and in "on-error". But we don't say "it's ugly to repeat them" | 08:39 |
| rakhmerov | because those a totally different cases | 08:39 |
| rakhmerov | for that we actually have "on-complete" where we can move repeating stuff | 08:40 |
| rakhmerov | vgvoleg: no-no, I can't accept that approach ("If something is described in docs, it is legal"), sorry | 08:40 |
| rakhmerov | docs must not aim to explain why we came up with a bad design | 08:41 |
| vgvoleg | akovi: how do you want to describe them? | 08:41 |
| vgvoleg | if we run this flow the skipped task will be executed with task1 in the parallel way :D | 08:42 |
| akovi | no | 08:42 |
| akovi | I messed it up | 08:42 |
| akovi | task1.on-skip = skipped-task1 | 08:42 |
| vgvoleg | oh | 08:43 |
| akovi | this way there's no need for alternative publish methods | 08:43 |
| vgvoleg | I can't undestand why 'publish-on-error' is OK and 'publish-on-skip' is not OK | 08:44 |
| akovi | where do we usually share copy-pastes? I forgot the name of the service | 08:44 |
| eyalb | pastebin | 08:44 |
| vgvoleg | I think that creating redundant instances for publish is not OK | 08:44 |
| rakhmerov | redundant instances? | 08:44 |
| rakhmerov | what's that? | 08:44 |
| vgvoleg | noop task just for publish | 08:45 |
| rakhmerov | guys, please let's be more accurate with terms | 08:45 |
| rakhmerov | noop for publish... I fail to understand this | 08:45 |
| vgvoleg | look at Andras' example | 08:46 |
| rakhmerov | ok, yes... | 08:46 |
| rakhmerov | well, IMO it's not a problem to make a separate "publish-on-skip" thing | 08:47 |
| rakhmerov | and "publish" under "on-skip" | 08:47 |
| rakhmerov | it's easy | 08:47 |
| rakhmerov | I just don't like the idea to reuse either "on-success" or something else that already exists to handle skipping | 08:48 |
| rakhmerov | duplicates, in my opinion, is not a problem that we need to solve now | 08:48 |
| vgvoleg | ok | 08:48 |
| abdelal | the plan is to eventually remove publish and publish-on-error right?, i dont think its wise to add publish-on-skip too | 08:48 |
| rakhmerov | abdelal: yes! | 08:48 |
| rakhmerov | abdelal: yes, right | 08:49 |
| rakhmerov | I just thought that maybe we still need to add it, but just for the sake of symmetry with other clauses | 08:49 |
| abdelal | so i think we should follow the current synyax we want,just have publish under on-skip if anything | 08:49 |
| abdelal | syntax* | 08:49 |
| rakhmerov | that's for sure, yes | 08:49 |
| vgvoleg | guys I'm OK with this changes but please don't mix them to the feature discussion | 08:50 |
| eyalb | I agree | 08:50 |
| rakhmerov | I'm just saying that the language should always be symmetric around similarities that we're adding | 08:50 |
| rakhmerov | vgvoleg: :) | 08:50 |
| rakhmerov | so, if there's no serious objections then I'd say "go ahead and push a patch" | 08:51 |
| abdelal | i think this feature is useful overall , but also as renat said , it should be as generic as much as possible and be alligned with current syntax | 08:51 |
| rakhmerov | these technical nuances is something that we'll polish a bit later | 08:51 |
| rakhmerov | not now | 08:51 |
| rakhmerov | yes | 08:51 |
| akovi | ok, great | 08:51 |
| rakhmerov | vgvoleg: sounds OK? | 08:52 |
| vgvoleg | sure :) | 08:52 |
| akovi | so on-skip.publish? or publish.on-skip? | 08:52 |
| rakhmerov | once we see your patch we may notice something else to discuss | 08:52 |
| rakhmerov | akovi: I'm for adding "publish-on-skip" and "on-skip" (that may contain "publish") just the same way as for other clauses | 08:53 |
| rakhmerov | then it'll be 100% symmetric | 08:53 |
| vgvoleg | guys, in the blueprint everything is symmetric | 08:53 |
| vgvoleg | 102% | 08:53 |
| akovi | hmm | 08:53 |
| akovi | the removal of publish-on* was new info for me | 08:54 |
| vgvoleg | It's because they mix two different topics | 08:54 |
| akovi | and if this is being removed then I'm not sure why we would provide this syntax for a new feature | 08:54 |
| akovi | but I'm ok | 08:54 |
| vgvoleg | relax :) | 08:54 |
| rakhmerov | vgvoleg: yes, sorry for that | 08:55 |
| rakhmerov | but it's kind of related | 08:55 |
| rakhmerov | if we are to discuss particular syntax | 08:55 |
| vgvoleg | so the second blueprint I'd like to discuss in the next meeting | 08:56 |
| rakhmerov | vgvoleg: yes, please | 08:56 |
| vgvoleg | thank you! | 08:56 |
| rakhmerov | we don't have enough time today | 08:56 |
| rakhmerov | thanks guys, I have to wrap up ) | 08:56 |
| rakhmerov | thanks everyone for joining | 08:56 |
| rakhmerov | I'd encourage you to do it more often | 08:56 |
| eyalb | bye | 08:56 |
| rakhmerov | bye | 08:56 |
| vgvoleg | bye! | 08:56 |
| akovi | great, I'm looking forward to see this working | 08:56 |
| rakhmerov | #endmeeting | 08:56 |
| *** openstack changes topic to "Mistral the Workflow Service for OpenStack. https://docs.openstack.org/mistral/latest/" | 08:56 | |
| openstack | Meeting ended Wed Sep 4 08:56:58 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 08:57 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/mistral/2019/mistral.2019-09-04-08.06.html | 08:57 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/mistral/2019/mistral.2019-09-04-08.06.txt | 08:57 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/mistral/2019/mistral.2019-09-04-08.06.log.html | 08:57 |
| *** vgvoleg has quit IRC | 09:00 | |
| *** irclogbot_1 has joined #openstack-mistral | 09:09 | |
| *** vgvoleg has joined #openstack-mistral | 09:09 | |
| *** irclogbot_1 has quit IRC | 09:11 | |
| *** ricolin has quit IRC | 09:34 | |
| *** ricolin has joined #openstack-mistral | 09:35 | |
| *** pgaxatte has quit IRC | 09:40 | |
| *** pgaxatte has joined #openstack-mistral | 09:46 | |
| *** akovi has quit IRC | 10:13 | |
| *** akovi has joined #openstack-mistral | 10:14 | |
| *** vgvoleg has quit IRC | 10:27 | |
| *** irclogbot_0 has joined #openstack-mistral | 10:29 | |
| *** irclogbot_0 has quit IRC | 10:33 | |
| *** irclogbot_2 has joined #openstack-mistral | 10:43 | |
| *** irclogbot_2 has quit IRC | 10:45 | |
| *** akovi has quit IRC | 10:57 | |
| *** irclogbot_3 has joined #openstack-mistral | 10:59 | |
| *** irclogbot_3 has quit IRC | 11:02 | |
| *** irclogbot_0 has joined #openstack-mistral | 11:43 | |
| *** irclogbot_0 has quit IRC | 11:47 | |
| *** vgvoleg has joined #openstack-mistral | 12:21 | |
| *** irclogbot_1 has joined #openstack-mistral | 13:39 | |
| *** irclogbot_1 has quit IRC | 13:42 | |
| *** irclogbot_0 has joined #openstack-mistral | 13:59 | |
| *** irclogbot_0 has quit IRC | 14:02 | |
| *** irclogbot_1 has joined #openstack-mistral | 14:05 | |
| openstackgerrit | Merged openstack/mistral master: Support OpenStack services dynamic versions https://review.opendev.org/621470 | 14:06 |
| *** irclogbot_1 has quit IRC | 14:08 | |
| *** irclogbot_2 has joined #openstack-mistral | 14:11 | |
| *** irclogbot_2 has quit IRC | 14:14 | |
| *** pgaxatte has quit IRC | 14:28 | |
| *** irclogbot_3 has joined #openstack-mistral | 14:37 | |
| *** irclogbot_3 has quit IRC | 14:40 | |
| *** irclogbot_1 has joined #openstack-mistral | 14:51 | |
| *** irclogbot_1 has quit IRC | 14:54 | |
| openstackgerrit | Eyal proposed openstack/mistral master: Add "published_global" field to the task execution REST resource https://review.opendev.org/678530 | 14:55 |
| *** eyalb has quit IRC | 15:06 | |
| *** irclogbot_3 has joined #openstack-mistral | 15:19 | |
| *** irclogbot_3 has quit IRC | 15:22 | |
| *** irclogbot_2 has joined #openstack-mistral | 15:33 | |
| *** abdelal has quit IRC | 15:35 | |
| *** irclogbot_2 has quit IRC | 15:36 | |
| *** irclogbot_2 has joined #openstack-mistral | 15:37 | |
| *** vgvoleg has quit IRC | 15:37 | |
| *** altlogbot_1 has joined #openstack-mistral | 15:39 | |
| *** ricolin has quit IRC | 18:50 | |
| *** irclogbot_2 has quit IRC | 18:54 | |
| *** irclogbot_0 has joined #openstack-mistral | 18:55 | |
| *** irclogbot_0 has quit IRC | 19:02 | |
| *** irclogbot_3 has joined #openstack-mistral | 19:03 | |
| *** jtomasek has quit IRC | 20:08 | |
| openstackgerrit | Merged openstack/mistral master: Fix 'with-items' expression evaluation https://review.opendev.org/679203 | 23:19 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
