*** jistr has quit IRC | 00:07 | |
*** jistr has joined #openstack-mistral | 00:13 | |
*** thrash is now known as thrash|g0ne | 00:25 | |
*** d0ugal has quit IRC | 00:36 | |
*** d0ugal has joined #openstack-mistral | 01:03 | |
*** pengdake_ has joined #openstack-mistral | 01:09 | |
*** hardikjasani has joined #openstack-mistral | 04:12 | |
*** pengdake_ has quit IRC | 04:17 | |
*** pengdake_ has joined #openstack-mistral | 04:19 | |
*** jaosorior has joined #openstack-mistral | 04:42 | |
*** pengdake_ has quit IRC | 05:05 | |
*** pengdake_ has joined #openstack-mistral | 05:07 | |
*** pengdake_ has quit IRC | 05:41 | |
*** threestrands has quit IRC | 05:47 | |
*** pengdake_ has joined #openstack-mistral | 05:54 | |
*** nguyenhai has joined #openstack-mistral | 06:12 | |
*** nguyenhai_ has quit IRC | 06:16 | |
*** jtomasek has joined #openstack-mistral | 06:45 | |
*** mcdoker1818 has joined #openstack-mistral | 07:07 | |
*** openstackgerrit has joined #openstack-mistral | 07:08 | |
openstackgerrit | Qi Peng proposed openstack/mistral master: Fix error workbook example https://review.openstack.org/566221 | 07:08 |
---|---|---|
*** jaosorior has quit IRC | 07:25 | |
*** gkadam has joined #openstack-mistral | 07:41 | |
*** jpich has joined #openstack-mistral | 07:51 | |
*** gkadam has quit IRC | 07:52 | |
*** gkadam has joined #openstack-mistral | 07:52 | |
d0ugal | Office hour time :) | 08:01 |
d0ugal | #startmeeting mistral | 08:01 |
openstack | Meeting started Fri May 4 08:01:50 2018 UTC and is due to finish in 60 minutes. The chair is d0ugal. Information about MeetBot at http://wiki.debian.org/MeetBot. | 08:01 |
openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 08:01 |
*** openstack changes topic to " (Meeting topic: mistral)" | 08:01 | |
openstack | The meeting name has been set to 'mistral' | 08:01 |
d0ugal | rakhmerov, apetrich, bobh, mcdoker181818: ping! ^ | 08:02 |
d0ugal | Happy friday everyone :) | 08:02 |
d0ugal | I just need to get a coffee, back in a few mins. | 08:02 |
rakhmerov | d0ugal: hey | 08:02 |
apetrich | o/ | 08:02 |
rakhmerov | here | 08:02 |
d0ugal | I don't have anything particular for the agenda, I'd like to go through and tidy up some of the blueprints maybe | 08:02 |
d0ugal | Otherwise happy to discuss anything people have! | 08:02 |
d0ugal | but first, coffee :) | 08:03 |
d0ugal | https://blueprints.launchpad.net/mistral/ | 08:09 |
d0ugal | So we have 140 blueprints, that is more than the number of bugs :) | 08:09 |
d0ugal | I guess we should triage blueprints like we do with bugs. Lots of them are "New" and "Not Started" | 08:09 |
rakhmerov | :) | 08:18 |
rakhmerov | ok | 08:18 |
rakhmerov | d0ugal: I'm here | 08:21 |
d0ugal | rakhmerov: Great | 08:21 |
d0ugal | I'm just reading some blueprints, I have not seen many of these before :) | 08:21 |
d0ugal | I am also reading https://help.launchpad.net/Blueprint - just so I can learn how blueprints should be used :) | 08:22 |
d0ugal | It might be that we don't really need to do anything with them... I am not sure | 08:22 |
rakhmerov | ok | 08:22 |
mcdoker1818 | Hi, all. I created new bug ticket yesterday https://bugs.launchpad.net/mistral/+bug/1769012 . We can discuss it after triage blueprints. | 08:22 |
openstack | Launchpad bug 1769012 in Mistral "Workflow pause with task retry policy" [Undecided,New] | 08:22 |
rakhmerov | well, in my understanding we just need to go over them and assign them to cycles and milestones according to our dev plans | 08:23 |
d0ugal | rakhmerov: sure, but I don't think they should stay in "New" for design, like a bug that means they have not been triaged? | 08:24 |
rakhmerov | yes | 08:24 |
d0ugal | they should either be approved or rejected I guess? | 08:24 |
rakhmerov | btw, did we clean up BPs for R-2? | 08:24 |
d0ugal | rakhmerov: no, not yet. | 08:25 |
rakhmerov | d0ugal: I think they can be rejected, yes. If they are nonsense ) | 08:25 |
d0ugal | :) | 08:25 |
d0ugal | or Discussion looks like a useful status if they need to be talked about more | 08:25 |
rakhmerov | yes | 08:26 |
d0ugal | It is just a task I want to do a little bit at a time - I think the bugs are much tidier now, so I'd like to do something similar with blueprints. | 08:26 |
rakhmerov | I'm not sure how to reject them properly though.. | 08:26 |
d0ugal | Good question :) | 08:26 |
rakhmerov | maybe just mark them as "obsolete" | 08:26 |
d0ugal | https://wiki.openstack.org/wiki/Blueprints | 08:27 |
d0ugal | That also looks useful. | 08:27 |
d0ugal | First I think we should discuss mcdoker1818's bug. | 08:27 |
rakhmerov | ok | 08:27 |
rakhmerov | as you wish, commandor ) | 08:27 |
d0ugal | haha, I think it is something he wants to work on now. The blueprints can wait longer :) | 08:28 |
rakhmerov | yes | 08:28 |
rakhmerov | reading it.. | 08:28 |
d0ugal | #link https://bugs.launchpad.net/mistral/+bug/1769012 | 08:28 |
openstack | Launchpad bug 1769012 in Mistral "Workflow pause with task retry policy" [Undecided,New] | 08:28 |
d0ugal | I am too :) | 08:28 |
rakhmerov | woow, so many details.. | 08:29 |
rakhmerov | btw, just something I noticed immediately: the title of the bug doesn't describe the bug | 08:29 |
rakhmerov | :) | 08:29 |
rakhmerov | there's a good BLUF (bottom line up front) principle that I personally try to always use | 08:30 |
rakhmerov | mcdoker1818: Vitalii, can you please put a line right in the beginning of the description that reflects the matter of the bug | 08:31 |
d0ugal | (or change the bug title) | 08:31 |
mcdoker1818 | Updated :) | 08:32 |
rakhmerov | ok, thanks | 08:32 |
d0ugal | I wouldn't delete the details - just make sure there is an easy to understand summary at the top | 08:34 |
rakhmerov | I also slightly updated it | 08:34 |
rakhmerov | yep | 08:34 |
rakhmerov | you can add details after a short summary | 08:35 |
rakhmerov | but ok, I understand it now | 08:35 |
mcdoker1818 | Thanks! | 08:35 |
rakhmerov | I guess the bug should be pretty easy to fix | 08:35 |
rakhmerov | my assumption is that retry policy doesn't take PAUSED state into account for some reason | 08:36 |
d0ugal | Yeah, so in summary - pausing a workflow breaks the retry policy? | 08:36 |
d0ugal | right | 08:36 |
rakhmerov | maybe "Retry policy keeps iterating if the workflow is paused" :) | 08:36 |
d0ugal | +1 | 08:36 |
mcdoker1818 | https://github.com/openstack/mistral/blob/master/mistral/engine/tasks.py#L232 | 08:37 |
d0ugal | I changed the bug to "Confirmed" - how important is this bug for you? :) | 08:37 |
rakhmerov | mcdoker1818: yes, but DELAYED is not the same as PAUSED | 08:38 |
d0ugal | rakhmerov: do we have a good desription of the states somewhere? I get confused with them sometimes. | 08:38 |
mcdoker1818 | Yep, I mean the retry executes before check the pause state | 08:38 |
rakhmerov | just to clarify: DELAYED is mostly an internal state needed to tell Mistral "this task is running but it's delayed due to some internal implementation reasons, like policy or something else" | 08:38 |
mcdoker1818 | d0ugal: I plan to fix it soon | 08:39 |
rakhmerov | PAUSED means that a user stopped it temporarily on purpose | 08:39 |
d0ugal | mcdoker1818: thanks, I added it to rocky-2 | 08:39 |
rakhmerov | d0ugal: probably we don't, let me check | 08:39 |
rakhmerov | ok | 08:39 |
d0ugal | rakhmerov: https://github.com/openstack/mistral/blob/master/mistral/workflow/states.py#L18 :) | 08:40 |
mcdoker1818 | :DD | 08:41 |
rakhmerov | d0ugal: so we have some info about the states in the spec but that's definitely not full | 08:41 |
rakhmerov | d0ugal: haha :)) | 08:41 |
mcdoker1818 | rakhmerov: I guess the main problem how resume task iterations after resume execution | 08:42 |
*** gkadam has quit IRC | 08:42 | |
rakhmerov | mcdoker1818: it shouldn't be a problem | 08:43 |
rakhmerov | we save info about retry iteration in the task 'runtime_context' field | 08:43 |
rakhmerov | under the key 'retry' or something like that | 08:44 |
rakhmerov | so we always know what the current iteration is | 08:44 |
mcdoker1818 | rakhmerov: As I know we resume tasks which has IDLE state | 08:44 |
rakhmerov | nope | 08:45 |
rakhmerov | PAUSED | 08:45 |
hardikjasani | arthur100 | 08:45 |
rakhmerov | IDLE is for a different purpose | 08:45 |
mcdoker1818 | We don't change state task to PAUSED | 08:46 |
rakhmerov | why not? | 08:47 |
rakhmerov | so the states change in this case as follows: RUNNING or RUNNING_DELAYED [we pause wf] -> PAUSED [we resume wf] -> RUNNING or RUNNING_DELAYED | 08:49 |
rakhmerov | as far as RUNNING_DELAYED, you can perceive it as a sub state of RUNNING | 08:50 |
mcdoker1818 | let me check | 08:50 |
rakhmerov | so it's a flavor of RUNNING state | 08:50 |
rakhmerov | hardikjasani: hey | 08:50 |
rakhmerov | what is arthur100? :) | 08:50 |
hardikjasani | typed it in wrong window :D | 08:51 |
hardikjasani | Nothing critical of course | 08:51 |
rakhmerov | ok ) | 08:52 |
rakhmerov | hardikjasani: btw, how is it going? Progressing with your tasks? | 08:52 |
*** nguyenhai has quit IRC | 08:54 | |
mcdoker1818 | rakhmerov: Ok, thank you for clarifying! | 08:55 |
rakhmerov | np | 08:55 |
hardikjasani | rakhmerov: going great! | 08:58 |
rakhmerov | ) | 08:58 |
mcdoker1818 | d0ugal, rakhmerov: What is about this ticket https://bugs.launchpad.net/mistral/+bug/1767830 ? Should I create blueprint for new api? | 08:58 |
openstack | Launchpad bug 1767830 in Mistral "Execution and task specification can be out of date" [Medium,Confirmed] | 08:58 |
mcdoker1818 | Or is it a bug? | 08:59 |
d0ugal | Sory, I got distracted for a moment there. | 09:00 |
d0ugal | mcdoker1818: Looking. | 09:00 |
mcdoker1818 | http://localhost:8989/v2/execution/%ex_id%/spec | 09:00 |
mcdoker1818 | for example | 09:00 |
d0ugal | Yeah, I remember now. | 09:00 |
d0ugal | mcdoker1818: I am happy for you to treat it like a bug | 09:00 |
rakhmerov | hm.. | 09:00 |
rakhmerov | well, wait a second | 09:01 |
rakhmerov | so my concern is the following | 09:01 |
rakhmerov | the 'spec' field is an internal thing and it may look much different from the initial YAML text | 09:02 |
rakhmerov | that's the thing.. | 09:02 |
rakhmerov | and that is why it was not exposed in the first place | 09:02 |
rakhmerov | as a solution, we could keep a snapshot of the initial *YAML* chunk but that's extra space | 09:03 |
d0ugal | yeah | 09:03 |
rakhmerov | we in many cases have many megs of data there | 09:03 |
d0ugal | I guess the best solution is to keep old versions of a workflow while there is a related execution. | 09:03 |
rakhmerov | and imagine if that is stored for every execution | 09:03 |
d0ugal | That is why I think it would be better to version the exectuion | 09:04 |
mcdoker1818 | > the 'spec' field is an internal thing and it may look much different from the initial YAML text | 09:04 |
rakhmerov | d0ugal: yeah, the most decent solution that I can think of is workflow versioning | 09:04 |
mcdoker1818 | Why do you think that it is a problem? | 09:04 |
d0ugal | so we just have one unique copy of every workflow - then a each execution could have a reference to the workflow and a version id (the sha of the yaml contents?) | 09:04 |
rakhmerov | so that workflow definition keep versions and the reference should look like "WF id = 1-2-3-4, ver 5" | 09:04 |
d0ugal | mcdoker1818: if we expose an internal data structure to users then we need to support and document it. | 09:05 |
rakhmerov | yep | 09:05 |
rakhmerov | I'd really hold on with this for now, honestly | 09:05 |
mcdoker1818 | Noop, we will not. We create a ExecutionSpec - resource | 09:05 |
mcdoker1818 | And we will expose it | 09:05 |
rakhmerov | mcdoker1818: from user perspective it doesn't make much sense | 09:06 |
d0ugal | I don't follow. | 09:06 |
rakhmerov | we already have workflows | 09:06 |
rakhmerov | (i.e. workflow definitions) | 09:06 |
rakhmerov | why would user need to deal with one more thing that's called Spec something.. | 09:06 |
rakhmerov | ? | 09:06 |
rakhmerov | from the user perspective they just deal with different versions of workflows | 09:07 |
rakhmerov | but we don't support it properly now | 09:07 |
rakhmerov | it can be done on the user side though: just introduce the policy not to every update workflows and use special naming that includes a version | 09:08 |
rakhmerov | that's it | 09:08 |
mcdoker1818 | of you right, yes | 09:08 |
mcdoker1818 | all of you are right, yes | 09:08 |
rakhmerov | you can even forbid the corresponding operation in the policy.json file | 09:08 |
rakhmerov | yeah | 09:08 |
d0ugal | That is a decent work-around for now. | 09:09 |
d0ugal | Okay - so I guess we consider this bug to be invalid? | 09:09 |
mcdoker1818 | I'm sorry I missed what is wa? | 09:09 |
d0ugal | mcdoker1818: What rakhmerov said. Don't let users update workflows via policy.json and then you can always get the original workflow. | 09:10 |
mcdoker1818 | hahahaah | 09:10 |
d0ugal | Then instead of updating workflow you always create new workflows (and delete old ones later) | 09:10 |
mcdoker1818 | noop, it's not wa :) | 09:10 |
d0ugal | Why not? | 09:11 |
rakhmerov | sorry, what is "wa"? | 09:11 |
mcdoker1818 | We use workflow by name in case of start sub-workflow (from task) | 09:11 |
rakhmerov | not following.. | 09:11 |
mcdoker1818 | work-around | 09:11 |
rakhmerov | ooh | 09:11 |
*** pengdake_ has quit IRC | 09:12 | |
d0ugal | Good point. That makes it harder. | 09:12 |
rakhmerov | sub-workflow names can be dynamic :) | 09:12 |
rakhmerov | but I understand, ok | 09:12 |
d0ugal | but that would get ugly :) | 09:12 |
d0ugal | mcdoker1818: Why do you need the original spec? | 09:13 |
mcdoker1818 | UI | 09:13 |
d0ugal | What do you want to do with it? | 09:13 |
d0ugal | I see | 09:13 |
d0ugal | Would it fit in the workflow execution description? :) | 09:14 |
d0ugal | no, I guess not. | 09:14 |
mcdoker1818 | Sorry, I don't understand you :) | 09:15 |
d0ugal | Don't worry - the idea won't work. | 09:15 |
rakhmerov | the reason I'm arguing this much is that I don't want workarounds | 09:16 |
rakhmerov | I hate them ) | 09:16 |
rakhmerov | they have a trend to live there for long | 09:16 |
rakhmerov | if this is so important then why not implement it in the right way? | 09:17 |
mcdoker1818 | :D | 09:17 |
mcdoker1818 | I like the idea with the version | 09:17 |
rakhmerov | d0ugal: maybe we just need to write a spec and see so that it's backwards compatible and decently implement it? | 09:17 |
rakhmerov | rather than ending up with workarounds | 09:17 |
d0ugal | rakhmerov: Right, that is why I am trying to think of a workaround from the users perspective | 09:18 |
d0ugal | I have never used namespaces - but could a new, unique namespace be used each time? do sub-workflow executions look within a namespace? | 09:18 |
d0ugal | rakhmerov: sure, I just wasn't sure how easy/realistic that was | 09:18 |
d0ugal | but I am happy for workflow versioning to be added. | 09:18 |
rakhmerov | ok | 09:19 |
rakhmerov | so yes, my suggestion is at least write a spec and see how hard it would be | 09:20 |
d0ugal | mcdoker1818: is this something you can work on? | 09:20 |
rakhmerov | let's do some research within a reasonable amount of time and then make a decision, how's that sound? | 09:20 |
d0ugal | Sure, sounds good. I don't have the time for this, but somebody should go fot it :) | 09:20 |
d0ugal | for it* | 09:20 |
mcdoker1818 | It's not a blocker for me right now, but I think it will be :) Yeap, I can do it a little later | 09:21 |
d0ugal | Okay, sounds good | 09:22 |
d0ugal | I'll mark the bug as invalid for now and sumarise this. | 09:22 |
mcdoker1818 | Ok | 09:22 |
d0ugal | Thanks! | 09:25 |
d0ugal | I am going to end the meeting bot before I forget, but I will be around for the rest of the day :) it is only 10:30am here. | 09:25 |
d0ugal | #endmeeting | 09:25 |
*** openstack changes topic to " (Meeting topic: test)" | 09:25 | |
openstack | Meeting ended Fri May 4 09:25:08 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 09:25 |
openstack | Minutes: http://eavesdrop.openstack.org/meetings/mistral/2018/mistral.2018-05-04-08.01.html | 09:25 |
openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/mistral/2018/mistral.2018-05-04-08.01.txt | 09:25 |
openstack | Log: http://eavesdrop.openstack.org/meetings/mistral/2018/mistral.2018-05-04-08.01.log.html | 09:25 |
mcdoker1818 | d0ugal: Do you have a some progress with https://blueprints.launchpad.net/mistral/+spec/mistral-action-providers and https://blueprints.launchpad.net/mistral/+spec/mistral-actions-api-separate-openstack-actions ? I have a view how implement it. Where I can describe it? | 09:25 |
*** pengdake_ has joined #openstack-mistral | 09:25 | |
d0ugal | mcdoker1818: I have not made progress yet, I have been busier than I expected with other things. I hope to look at it this month. | 09:26 |
d0ugal | mcdoker1818: You can add to the whiteboard on the blueprint | 09:26 |
mcdoker1818 | Where you discuss a blueprint\specification? | 09:26 |
mcdoker1818 | Ok | 09:26 |
mcdoker1818 | Thnaks! | 09:26 |
d0ugal | Blueprints in launchpad are not very good, I wish they had comments. | 09:26 |
d0ugal | At some point we should look into moving to Storyboard... :) | 09:26 |
mcdoker1818 | What is the Storyboard? | 09:27 |
d0ugal | mcdoker1818: https://storyboard.openstack.org/ | 09:29 |
d0ugal | Not many projects are using it yet, but some have moved over. | 09:29 |
d0ugal | I don't know if it is ready or not, we would need to do some investigation. | 09:29 |
mcdoker1818 | Woow, looks good) | 09:30 |
rakhmerov | mcdoker1818: btw, are you considering to go to the PTG this year? | 09:32 |
rakhmerov | in Sept | 09:32 |
rakhmerov | in Denver | 09:32 |
rakhmerov | it'd be very cool if you came | 09:32 |
rakhmerov | d0ugal: may be you can help.. I'm struggling with some "pip" mess | 09:33 |
d0ugal | rakhmerov: sure, I can try. | 09:34 |
rakhmerov | pip stopped fetching requirements as neede | 09:34 |
d0ugal | "stopped"? did you get an error? | 09:34 |
d0ugal | Which version of pip? | 09:34 |
rakhmerov | saying there's a problem with TLS verification whatever | 09:34 |
rakhmerov | yeah | 09:34 |
rakhmerov | 8.1.2 | 09:34 |
d0ugal | old :) | 09:34 |
rakhmerov | "There was a problem confirming the ssl certificate: [SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:646) - skipping" | 09:34 |
rakhmerov | yes, I know | 09:35 |
rakhmerov | but :) | 09:35 |
rakhmerov | I update it with get-pip.py | 09:35 |
rakhmerov | to 10 something.. | 09:35 |
d0ugal | btw you can update with "pip install -U pip" | 09:35 |
rakhmerov | and when I run, for example, "tox -epy35" it gets reverted back to 8.1.2 for some reason | 09:35 |
d0ugal | but get-pip should work fine too | 09:35 |
rakhmerov | ok | 09:36 |
d0ugal | rakhmerov: What version of virtualenv? | 09:36 |
d0ugal | and tozx | 09:36 |
d0ugal | tox | 09:36 |
rakhmerov | hah.. one second | 09:36 |
d0ugal | iirc virtualenv includes a copy of pip and setuptools. | 09:36 |
rakhmerov | tox is 2.1.1 | 09:36 |
rakhmerov | old? | 09:36 |
d0ugal | Not sure. Looking. | 09:36 |
d0ugal | Yes, old :) | 09:37 |
rakhmerov | ooh, maybe updating "virtualenv" is a key really.. | 09:37 |
rakhmerov | ok | 09:37 |
d0ugal | tox 2.1.1 is from Jun 23, 2015! | 09:37 |
hardikjasani | tox will use pip from virtualenv | 09:37 |
rakhmerov | yep, but I remember there was a reason not to use later versions | 09:37 |
d0ugal | Yup | 09:37 |
rakhmerov | ok | 09:37 |
rakhmerov | I'll try to update both | 09:37 |
rakhmerov | thanks | 09:37 |
d0ugal | rakhmerov: I use tox 3.0 | 09:37 |
hardikjasani | so just activate py35 env and then upgrade pip | 09:37 |
rakhmerov | yup | 09:38 |
rakhmerov | thanks to you both ) Will try | 09:38 |
mcdoker1818 | rakhmerov: I think it's going to be very difficult for me, but I'll think about it. | 09:39 |
mcdoker1818 | :) | 09:39 |
rakhmerov | mcdoker1818: no worries, we'll help | 09:39 |
rakhmerov | you need to learn to do this kind of work anyway ;) | 09:39 |
mcdoker1818 | :) | 09:40 |
*** pengdake_ has quit IRC | 10:06 | |
*** gkadam has joined #openstack-mistral | 12:09 | |
*** jistr is now known as jistr|mtg | 12:11 | |
*** thrash|g0ne is now known as thrash | 12:14 | |
*** gkadam has quit IRC | 12:24 | |
*** pengdake_ has joined #openstack-mistral | 12:28 | |
*** jistr|mtg is now known as jistr | 12:31 | |
*** pengdake_ has quit IRC | 12:48 | |
*** bobh has joined #openstack-mistral | 13:14 | |
*** hardikjasani has quit IRC | 13:21 | |
*** pengdake_ has joined #openstack-mistral | 13:36 | |
*** pengdake_ has quit IRC | 13:54 | |
*** bobh has quit IRC | 14:11 | |
*** bobh has joined #openstack-mistral | 14:12 | |
*** jistr is now known as jistr|tpb | 14:49 | |
*** jistr|tpb is now known as jistr | 15:05 | |
*** thrash is now known as thrash|biab | 15:15 | |
*** mcdoker1818 has quit IRC | 15:26 | |
*** EmilienM is now known as EvilienM | 16:09 | |
*** thrash|biab is now known as thrash | 16:29 | |
*** jpich has quit IRC | 16:31 | |
*** AlexeyAbashkin has joined #openstack-mistral | 16:43 | |
*** itlinux has joined #openstack-mistral | 17:14 | |
*** AlexeyAbashkin has quit IRC | 18:30 | |
*** rbrady has joined #openstack-mistral | 19:38 | |
*** rbrady is now known as Guest84690 | 19:39 | |
*** Guest84690 has quit IRC | 20:06 | |
*** bobh has quit IRC | 20:57 | |
*** bobh has joined #openstack-mistral | 20:58 | |
*** bobh has quit IRC | 21:23 | |
*** itlinux has quit IRC | 21:47 | |
*** Guest84690 has joined #openstack-mistral | 21:54 | |
*** Guest84690 has quit IRC | 21:59 | |
*** jtomasek has quit IRC | 22:10 | |
*** bobh has joined #openstack-mistral | 23:06 | |
*** bobh has quit IRC | 23:17 | |
*** mfedosin has quit IRC | 23:25 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!