| *** d0ugal has quit IRC | 02:49 | |
| *** d0ugal has joined #openstack-mistral | 02:50 | |
| *** gkadam has joined #openstack-mistral | 03:53 | |
| *** gkadam has quit IRC | 04:20 | |
| *** gkadam has joined #openstack-mistral | 04:26 | |
| *** hardikjasani has joined #openstack-mistral | 04:41 | |
| *** jaosorior has joined #openstack-mistral | 05:12 | |
| *** jaewook_oh has quit IRC | 05:32 | |
| *** d0ugal has quit IRC | 05:48 | |
| *** d0ugal has joined #openstack-mistral | 05:54 | |
| *** shardy has joined #openstack-mistral | 07:14 | |
| *** jpich has joined #openstack-mistral | 07:43 | |
| *** gkadam has quit IRC | 07:57 | |
| openstackgerrit | Adriano Petrich proposed openstack/mistral-tempest-plugin master: Fix todo that is not needed anymore stestr conf https://review.openstack.org/565164 | 08:04 |
|---|---|---|
| *** livelace has joined #openstack-mistral | 08:16 | |
| *** livelace-link has quit IRC | 10:09 | |
| *** livelace-link has joined #openstack-mistral | 10:12 | |
| d0ugal | apetrich: I wonder if a revert would make more sense? re: ^ | 10:19 |
| d0ugal | oh, wait, nevermind | 10:20 |
| d0ugal | :) | 10:20 |
| apetrich | d0ugal, :) | 10:20 |
| d0ugal | My brain is delayed today | 10:20 |
| apetrich | so say we all today | 10:21 |
| *** pengdake_ has joined #openstack-mistral | 10:49 | |
| *** bobh has joined #openstack-mistral | 11:33 | |
| *** thrash|g0ne is now known as thrash | 11:42 | |
| *** pengdake_ has quit IRC | 11:53 | |
| *** bobh has quit IRC | 11:59 | |
| *** ninag has joined #openstack-mistral | 12:22 | |
| *** ninag has quit IRC | 12:22 | |
| *** jaosorior has quit IRC | 12:43 | |
| apetrich | d0ugal, thanks for the recheck it worked | 12:48 |
| d0ugal | yay | 12:49 |
| *** hardikjasani has quit IRC | 13:31 | |
| toure | rbrady thrash scrum | 13:37 |
| toure | ? | 13:37 |
| *** toure is now known as toure|biab | 13:49 | |
| *** livelace has quit IRC | 14:02 | |
| *** livelace has joined #openstack-mistral | 14:05 | |
| *** bobh has joined #openstack-mistral | 14:14 | |
| *** toure|biab is now known as toure | 14:59 | |
| d0ugal | #startmeeting mistral | 15:00 |
| openstack | Meeting started Mon Apr 30 15:00:14 2018 UTC and is due to finish in 60 minutes. The chair is d0ugal. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| *** openstack changes topic to " (Meeting topic: mistral)" | 15:00 | |
| openstack | The meeting name has been set to 'mistral' | 15:00 |
| d0ugal | rakhmerov, apetrich, bobh, mcdoker181818: https://etherpad.openstack.org/p/mistral-office-hours | 15:01 |
| d0ugal | Office hour time :) | 15:01 |
| apetrich | o/ | 15:01 |
| d0ugal | Reminder to anyone else, if you want a ping like that at the start of the meeting, add yourself to the etherpad ^ | 15:01 |
| apetrich | so I was reading this and was wondering if I can pick your minds? | 15:04 |
| apetrich | https://bugs.launchpad.net/tripleo/+bug/1757430 | 15:04 |
| openstack | Launchpad bug 1757430 in tripleo "The ssh_keys and tripleo.undercloud-config Mistral environments should be move to swift" [High,Triaged] | 15:04 |
| apetrich | it is a bit tripleo-ish but my questions is more about the mistral side of it | 15:04 |
| d0ugal | apetrich: That is a tripleo bug... but maybe it is relevant here? :) | 15:04 |
| d0ugal | oh, okay | 15:04 |
| d0ugal | Go for it | 15:04 |
| apetrich | The bug is store some env keys in swift. but those are done with the environment-get | 15:05 |
| apetrich | I was wondering if there's a way to do that in a way that is better for the community | 15:06 |
| apetrich | like maybe a setting for a backend storage for environment vars | 15:06 |
| d0ugal | "do so that" - do what exactly? | 15:07 |
| d0ugal | right | 15:07 |
| apetrich | because the best way that I think is having that keep the same api that we have today | 15:07 |
| d0ugal | apetrich: I'd argue the Swift API is better than the Mistral Environments API - for tripleo's use anyway :) | 15:08 |
| d0ugal | but having a pluggable environment backend would be interesting - it would make it easier to secure things with say a barbican backend | 15:08 |
| d0ugal | or the secure swift containers. | 15:09 |
| bobh | o/ | 15:09 |
| apetrich | or memcache if that is needed a lot | 15:09 |
| d0ugal | Aye | 15:09 |
| d0ugal | bobh: Hey! | 15:09 |
| d0ugal | apetrich: sounds like it would be worth exploring anyway - I am not sure how easy it would be | 15:10 |
| d0ugal | I don't know much much of the implementation is tied to the environment database code. | 15:10 |
| apetrich | me neither but either doing a all in approach like a setting in the mistral.conf or a per env var | 15:10 |
| apetrich | from my quick lazy ass research seems that we store that in the database and that's it | 15:11 |
| d0ugal | apetrich: yeah, there is the weird mechanism for loading an environment into an execution - but I forget how that works exactly | 15:11 |
| d0ugal | It isn't something we use in tripleo | 15:11 |
| apetrich | oh that's that | 15:12 |
| apetrich | yeah I forgot that | 15:12 |
| d0ugal | but that should be easy to make it lookup which backend to use | 15:12 |
| apetrich | a setting to change the backend for it would be the best in case of a memcache/elasticsomething storage is welcome | 15:13 |
| apetrich | because not hitting the database to get that is important | 15:13 |
| d0ugal | yeah | 15:13 |
| apetrich | on the other hand an extra optional json field in the database poiting to where it is is an other idea to store that | 15:13 |
| d0ugal | lol | 15:14 |
| d0ugal | Indeed | 15:14 |
| d0ugal | I'd probably prefer a global setting, just for simplicity | 15:14 |
| apetrich | if that is empty just return that otherwise use the values that to get the needed value | 15:14 |
| d0ugal | I'm not sure I can think of a good use-case for having multiple environment backenvs. | 15:14 |
| d0ugal | backends | 15:14 |
| apetrich | +1 for the global setting | 15:14 |
| apetrich | the use case I think is you just want to store the ssh_keys var into a secured swift that might be extra slow the rest is just trivial | 15:15 |
| apetrich | and can be stored in the database | 15:15 |
| d0ugal | True | 15:16 |
| d0ugal | For tripleo, part of the desire is to have everything stored in one place - so we want everything in Swift | 15:16 |
| d0ugal | bobh: Feel free to jump in if you have anything to discuss | 15:17 |
| d0ugal | We are just chatting in general | 15:17 |
| d0ugal | The same goes to anyone else ^ | 15:17 |
| bobh | d0ugal: one question came up last week - would there be any value in allowing a "publish-on-error" setting in task-defaults? | 15:17 |
| d0ugal | bobh: yes! | 15:18 |
| d0ugal | I would like this :) | 15:18 |
| bobh | d0ugal: ok, I'll put it on my list of things to do | 15:18 |
| bobh | I thought it would be useful too, and was surprised it wasn't supported | 15:18 |
| d0ugal | Indeed - I think it makes lots of sense. | 15:19 |
| d0ugal | bobh: oh, actually - I don't think there is even "publish" on task-defaults? | 15:20 |
| bobh | d0ugal: nope | 15:20 |
| bobh | d0ugal: I think they both make sense, if you are doing any sort of structured workflow | 15:20 |
| d0ugal | Yeah - I think if we add one we need both. | 15:20 |
| d0ugal | I wonder if there is a blueprint for this already... /me searches | 15:21 |
| d0ugal | bobh: I didn't find a blueprint for this, but I found this: https://blueprints.launchpad.net/mistral/+spec/mistral-task-default-context | 15:23 |
| d0ugal | I wonder if not having the context there might make it hard to support? | 15:24 |
| d0ugal | Otherwise it sounds like it should be easy. | 15:24 |
| bobh | I wondered the same thing, but theoretically the expressions should not be evaluated until the task context it available - never on their own | 15:24 |
| d0ugal | Yup, good point | 15:24 |
| bobh | assuming it was implemented properly :-) | 15:25 |
| d0ugal | haha, I'm sure it was ;) | 15:25 |
| bobh | one other question - I ran into a problem with DB updates failing that was caused by this line: | 15:26 |
| bobh | https://github.com/openstack/mistral/blob/master/mistral/engine/tasks.py#L379 | 15:26 |
| d0ugal | What error did you get? | 15:27 |
| bobh | I thought it was interesting that there is an assumption of a specific field name in an output of an action | 15:27 |
| bobh | The DB update failed because it was trying to set state_info to a null dict | 15:27 |
| d0ugal | bobh: the output from actions is always under the result key. | 15:27 |
| bobh | ah - makes sense | 15:28 |
| d0ugal | sort-of :) | 15:28 |
| bobh | so in this case it was a null dict | 15:28 |
| d0ugal | Yeah, that is strange. I am not sure what would cause that. | 15:28 |
| bobh | I had to add "or None" after the action output reference to fix the problem | 15:28 |
| bobh | that works fine, but I'm trying to come up with a test to reproduce the problem and verify the fix | 15:29 |
| d0ugal | That would be good | 15:29 |
| d0ugal | Was it a custom action? | 15:29 |
| bobh | I'll have to go back and look -could be, we do a lot of that | 15:29 |
| bobh | and we don't always do it well... | 15:29 |
| bobh | I think adding the or None is probably a good idea in general, just to be safe | 15:30 |
| bobh | but I do want to test it | 15:30 |
| d0ugal | https://github.com/openstack/mistral-lib/blob/master/mistral_lib/actions/types.py#L58-L60 | 15:31 |
| d0ugal | I think that is where/why there should always be a result key | 15:31 |
| d0ugal | (that code was moved from the mistral repo to mistral-lib, so I'm not sure why it was done like that originally) | 15:31 |
| bobh | makes sense | 15:32 |
| d0ugal | We had a new bug this week! https://bugs.launchpad.net/mistral/+bug/1767830 | 15:38 |
| openstack | Launchpad bug 1767830 in Mistral "Task and execution description" [Medium,Confirmed] | 15:38 |
| d0ugal | Which seems valid - we don't expost the descriptions for tasks and executions. | 15:38 |
| d0ugal | I am a little concerned about how much more database space this would take... since it would need to be duplicated for each exectuion. | 15:39 |
| d0ugal | But maybe we store it all anyway? I'd need to check. | 15:39 |
| bobh | The execution description is set when you execution-create or execution-update -d | 15:42 |
| bobh | it doesn't get copied from the workflow description | 15:42 |
| d0ugal | bobh: Good point. There are two different descriptions we need to make sure we don't confuse them :) | 15:44 |
| d0ugal | There is the execution description, and the workflow description for that execution | 15:44 |
| bobh | seems like copying the workflow description into every execution would not make a lot of sense | 15:45 |
| bobh | the workflow_id is there, so you can go get it if you need it | 15:45 |
| d0ugal | bobh: but it can change, I think that is the point | 15:45 |
| bobh | the workflow description can change? at runtime? | 15:46 |
| d0ugal | Not quite. | 15:46 |
| bobh | or over time | 15:46 |
| d0ugal | You can upload a workflow, start an execution, update a workflow and start a new execution | 15:46 |
| bobh | right - but how much of the previous version of the workflow do we need to preserve? | 15:46 |
| d0ugal | The two executions could have different desriptions | 15:46 |
| d0ugal | bobh: I think we preserve almost all of it. | 15:47 |
| bobh | do we have the spec that was executed? The description would be in there | 15:47 |
| d0ugal | That is what I am not sure about. | 15:47 |
| d0ugal | I believe we do have it all. | 15:47 |
| d0ugal | bobh: https://github.com/openstack/mistral/blob/master/mistral/db/v2/sqlalchemy/models.py#L173 | 15:48 |
| bobh | which should have the description, I think | 15:48 |
| d0ugal | yup, I think so. | 15:49 |
| bobh | though its not exposed via the API for retrieval maybe? | 15:49 |
| bobh | spec field | 15:49 |
| d0ugal | I don't think so | 15:49 |
| d0ugal | so, then I guess the question is - do we want to expost the full spec via the API? | 15:50 |
| bobh | probably makes sense to be able to tell what exactly was executed | 15:50 |
| d0ugal | True. | 15:50 |
| bobh | output will be a huge | 15:51 |
| d0ugal | Yeah, that is my concern :) | 15:51 |
| d0ugal | we don't want to add that to every request - so maybe we need to add an option or a new endpoint. | 15:52 |
| bobh | similar to get-definition | 15:53 |
| d0ugal | Yup | 15:53 |
| d0ugal | I'm going to copy some of this into the bug ^ | 15:53 |
| d0ugal | I am going to end the meeting slightly early - I gotta run and do something | 15:57 |
| d0ugal | Thanks everyone! | 15:57 |
| d0ugal | #endmeeting | 15:57 |
| *** openstack changes topic to " (Meeting topic: test)" | 15:57 | |
| openstack | Meeting ended Mon Apr 30 15:57:25 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:57 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/mistral/2018/mistral.2018-04-30-15.00.html | 15:57 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/mistral/2018/mistral.2018-04-30-15.00.txt | 15:57 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/mistral/2018/mistral.2018-04-30-15.00.log.html | 15:57 |
| *** jpich has quit IRC | 16:32 | |
| *** itlinux has joined #openstack-mistral | 16:33 | |
| *** itlinux has quit IRC | 17:29 | |
| *** shardy is now known as shardy_afk | 17:45 | |
| *** itlinux has joined #openstack-mistral | 18:18 | |
| *** livelace has quit IRC | 18:26 | |
| *** itlinux has quit IRC | 19:07 | |
| *** thrash is now known as thrash|biab | 19:08 | |
| *** livelace has joined #openstack-mistral | 19:12 | |
| *** livelace has quit IRC | 19:18 | |
| *** d0ugal has quit IRC | 19:45 | |
| *** d0ugal has joined #openstack-mistral | 19:47 | |
| *** thrash|biab is now known as thrash | 19:49 | |
| *** d0ugal_ has joined #openstack-mistral | 20:01 | |
| *** d0ugal has quit IRC | 20:02 | |
| *** itlinux has joined #openstack-mistral | 20:06 | |
| *** itlinux has quit IRC | 20:17 | |
| *** d0ugal_ has quit IRC | 20:18 | |
| *** itlinux has joined #openstack-mistral | 20:19 | |
| *** d0ugal_ has joined #openstack-mistral | 20:20 | |
| *** d0ugal_ has quit IRC | 20:36 | |
| *** itlinux has quit IRC | 20:36 | |
| *** d0ugal_ has joined #openstack-mistral | 20:44 | |
| *** d0ugal_ has quit IRC | 21:32 | |
| *** d0ugal_ has joined #openstack-mistral | 21:36 | |
| *** d0ugal_ has quit IRC | 21:38 | |
| *** d0ugal_ has joined #openstack-mistral | 21:39 | |
| *** d0ugal_ has quit IRC | 21:57 | |
| *** d0ugal_ has joined #openstack-mistral | 22:00 | |
| *** bobh has quit IRC | 22:14 | |
| *** toure has quit IRC | 22:54 | |
| *** toure has joined #openstack-mistral | 22:55 | |
| *** d0ugal__ has joined #openstack-mistral | 23:12 | |
| *** d0ugal_ has quit IRC | 23:14 | |
| *** d0ugal__ has quit IRC | 23:29 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!