| *** achanda has joined #openstack-mistral | 00:39 | |
| *** bobh has joined #openstack-mistral | 00:49 | |
| *** toddjohn has joined #openstack-mistral | 00:55 | |
| *** toddjohn has quit IRC | 00:59 | |
| *** achanda has quit IRC | 01:10 | |
| *** rbrady has quit IRC | 01:13 | |
| *** toddjohn has joined #openstack-mistral | 01:27 | |
| *** achanda has joined #openstack-mistral | 01:31 | |
| *** toddjohn has quit IRC | 01:34 | |
| *** bobh has quit IRC | 02:02 | |
| *** toddjohn has joined #openstack-mistral | 02:31 | |
| *** achanda has quit IRC | 02:32 | |
| *** bobh has joined #openstack-mistral | 02:37 | |
| *** toddjohn has quit IRC | 02:38 | |
| *** achanda has joined #openstack-mistral | 02:44 | |
| *** bobh has quit IRC | 02:52 | |
| *** achanda has quit IRC | 03:14 | |
| *** achanda has joined #openstack-mistral | 03:55 | |
| *** achanda has quit IRC | 03:55 | |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral: Invalidate workflow spec cache on workflow definition updates https://review.openstack.org/348828 | 04:31 |
|---|---|---|
| openstackgerrit | Renat Akhmerov proposed openstack/mistral: Towards non-locking model: removing env update from WF controller https://review.openstack.org/349466 | 04:31 |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral: Removing unnecessary workflow specification parsing https://review.openstack.org/347758 | 04:31 |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral: Towards non-locking model: fix obvious workflow controller issues https://review.openstack.org/349457 | 04:31 |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral: Towards non-locking model: Add 'unique_key' for delayed calls https://review.openstack.org/349445 | 04:31 |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral: Splitting executions into different tables https://review.openstack.org/347172 | 04:31 |
| *** toddjohn has joined #openstack-mistral | 04:35 | |
| *** toddjohn has quit IRC | 04:39 | |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral: Invalidate workflow spec cache on workflow definition updates https://review.openstack.org/348828 | 04:48 |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral: Towards non-locking model: removing env update from WF controller https://review.openstack.org/349466 | 04:48 |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral: Removing unnecessary workflow specification parsing https://review.openstack.org/347758 | 04:48 |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral: Towards non-locking model: fix obvious workflow controller issues https://review.openstack.org/349457 | 04:48 |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral: Towards non-locking model: Add 'unique_key' for delayed calls https://review.openstack.org/349445 | 04:48 |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral: Splitting executions into different tables https://review.openstack.org/347172 | 04:48 |
| rakhmerov | hparekh, ddeja: hi, can you please review my patches again starting with https://review.openstack.org/#/c/347172/ | 05:12 |
| rakhmerov | I rebased them, tests have almost passed | 05:12 |
| hparekh | rakhmerov, sure | 05:12 |
| rakhmerov | thanks | 05:13 |
| rakhmerov | and looks like all of your comments are addressed too | 05:13 |
| *** achanda has joined #openstack-mistral | 05:46 | |
| openstackgerrit | Merged openstack/mistral: Splitting executions into different tables https://review.openstack.org/347172 | 06:18 |
| *** toddjohn has joined #openstack-mistral | 06:36 | |
| rakhmerov | ddeja: hey, can you please glance at https://review.openstack.org/#/c/348828/ ? | 06:38 |
| rakhmerov | it's basically an addition to the previous one | 06:38 |
| *** toddjohn has quit IRC | 06:40 | |
| ddeja | rakhmerov: looking | 06:45 |
| rakhmerov | ddeja: ok | 06:48 |
| openstackgerrit | Merged openstack/python-mistralclient: Add cancelled state to executions https://review.openstack.org/346280 | 06:50 |
| *** brunograz has joined #openstack-mistral | 07:11 | |
| *** achanda has quit IRC | 07:15 | |
| *** jpich has joined #openstack-mistral | 07:20 | |
| *** Venkat has joined #openstack-mistral | 07:21 | |
| *** Venkat has quit IRC | 07:21 | |
| *** venkat has joined #openstack-mistral | 07:21 | |
| *** jpich has quit IRC | 07:29 | |
| *** shardy has joined #openstack-mistral | 07:30 | |
| *** janki has joined #openstack-mistral | 07:33 | |
| jtomasek | ddeja: Hi, here is the bug https://bugs.launchpad.net/mistral/+bug/1608827 let me know if you need more information | 07:37 |
| openstack | Launchpad bug 1608827 in Mistral "action error handling" [Undecided,New] | 07:37 |
| openstackgerrit | Merged openstack/mistral: Removing unnecessary workflow specification parsing https://review.openstack.org/347758 | 07:40 |
| *** jpich has joined #openstack-mistral | 07:41 | |
| * ddeja ddeja is looking | 07:51 | |
| *** nmakhotkin has joined #openstack-mistral | 08:01 | |
| *** nmakhotkin has quit IRC | 08:03 | |
| *** nmakhotkin has joined #openstack-mistral | 08:04 | |
| *** achanda has joined #openstack-mistral | 08:16 | |
| *** clenimar has quit IRC | 08:19 | |
| *** kong has quit IRC | 08:19 | |
| *** kong_ has joined #openstack-mistral | 08:21 | |
| *** kong_ has quit IRC | 08:21 | |
| *** kong_ has joined #openstack-mistral | 08:21 | |
| *** kong_ is now known as kong | 08:21 | |
| *** achanda has quit IRC | 08:22 | |
| *** clenimar has joined #openstack-mistral | 08:23 | |
| ddeja | rakhmerov: are there any guides about using our python client? | 08:30 |
| openstackgerrit | Andras Kovi proposed openstack/mistral: Add target parameters to REST API https://review.openstack.org/339349 | 08:30 |
| rakhmerov | ddeja: I think this is the only one we have, http://docs.openstack.org/developer/mistral/guides/mistralclient_guide.html | 08:37 |
| ddeja | rakhmerov: oh, but it is only for CLI client. I'm trying to use it from python... | 08:41 |
| rakhmerov | then no docs :) | 08:42 |
| ddeja | :/ | 08:42 |
| rakhmerov | but it should be pretty straightforward actually | 08:42 |
| rakhmerov | you just need to instantiate Client class properly and you're good to go | 08:42 |
| ddeja | well, right now I'm strugling with getting client class | 08:42 |
| rakhmerov | and then use REST API spec to understand what you can do | 08:42 |
| rakhmerov | ok, take a look at how it's instantiated in CLI | 08:43 |
| ddeja | it lacks the "password", for example | 08:43 |
| ddeja | ok, will do | 08:43 |
| rakhmerov | ooh, yeah | 08:44 |
| rakhmerov | it's a confusing place | 08:44 |
| rakhmerov | it's called "api_key" | 08:44 |
| rakhmerov | :) | 08:44 |
| rakhmerov | it's, in fact, a password | 08:44 |
| rakhmerov | it's a legacy from old OpenStack names and conventions | 08:44 |
| rakhmerov | btw, you can fix it (but accurately) if you want | 08:45 |
| ddeja | rakhmerov: ok, I see | 08:45 |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral: Update docs and add release not for safe-rerun flag https://review.openstack.org/349449 | 08:46 |
| ddeja | OK, I knowing that api_key == password make it easy | 08:48 |
| ddeja | thanks! | 08:48 |
| nmakhotkin | hi rakhmerov | 08:52 |
| ddeja | jtomasek: Hi. Good news - I am able to reproduce this on my env | 08:52 |
| rakhmerov | nmakhotkin: hi Nikolay | 08:53 |
| nmakhotkin | I hope we easily can generate docs for mistralclient | 08:53 |
| jtomasek | ddeja: cool!:) | 08:53 |
| nmakhotkin | I mean from source | 08:53 |
| nmakhotkin | like it is done in novaclient | 08:53 |
| ddeja | jtomasek: I'm looking for a problem and hopefully will send the fix soon | 08:53 |
| jtomasek | ddeja: thanks | 08:54 |
| rakhmerov | nmakhotkin: yes | 09:12 |
| rakhmerov | ddeja: is it really a bug? | 09:12 |
| rakhmerov | I wonder what it is | 09:12 |
| rakhmerov | and why it's not been revealed earlier :) | 09:12 |
| ddeja | rakhmerov: Yes it is | 09:14 |
| *** Ravikiran_K has joined #openstack-mistral | 09:14 | |
| rakhmerov | hm.. ok | 09:14 |
| ddeja | I think i know why it is happening | 09:14 |
| rakhmerov | why? | 09:14 |
| rakhmerov | briefly | 09:14 |
| ddeja | take a look on method start_action in default engine | 09:14 |
| rakhmerov | looking | 09:15 |
| ddeja | if action have save_result set to true, we return the object from the DB, which inbcludes State and so on | 09:15 |
| ddeja | but if it does not have 'save_result', we are returning... | 09:16 |
| ddeja | hm, only input and output, despite the name | 09:16 |
| ddeja | OK, I'm confused now | 09:17 |
| rakhmerov | :) | 09:17 |
| ddeja | so, this is what happens | 09:18 |
| ddeja | if save_rerun == False | 09:18 |
| rakhmerov | this is ok because this method just starts an action | 09:18 |
| rakhmerov | no state yet | 09:18 |
| rakhmerov | and result | 09:18 |
| ddeja | action is run, but nothing returns to engine and so on | 09:18 |
| ddeja | save_state, not save_rerun, to much RPC api ;) | 09:18 |
| ddeja | if save_state is set, we get all info back | 09:19 |
| ddeja | the point is - is it working as designed, rakhmerov? | 09:19 |
| rakhmerov | save_result | 09:20 |
| ddeja | rakhmerov: yes, save_result. | 09:20 |
| ddeja | I write faster than think | 09:20 |
| rakhmerov | yeah, ok | 09:21 |
| rakhmerov | I see now | 09:21 |
| rakhmerov | so, here is the use case that doesn't work properly | 09:21 |
| rakhmerov | when "save_result" is True and action is synchronous | 09:21 |
| rakhmerov | no, sorry | 09:22 |
| rakhmerov | if "save_result" is set to False and the action is sync | 09:23 |
| rakhmerov | yes | 09:23 |
| ddeja | rakhmerov: yes. Then action is run but there is no way to find out how it ended. | 09:23 |
| ddeja | Is it working as designed? | 09:24 |
| rakhmerov | so when we build db_models.ActionExecution we need to add state and state_info | 09:24 |
| rakhmerov | just like it happens normally if an action is async | 09:24 |
| rakhmerov | ddeja: no, it's a bug | 09:24 |
| rakhmerov | I guess we're lacking tests for this | 09:25 |
| ddeja | ok | 09:25 |
| rakhmerov | ddeja: it always makes sense to set state properly | 09:25 |
| ddeja | to be honest, it is quite complicated at a first glance | 09:25 |
| rakhmerov | even if we don't store action execution in DB | 09:25 |
| rakhmerov | ddeja: yeah, I know. I used to be even more complicated before big refactoring a couple of months ago ) | 09:26 |
| rakhmerov | this code just tries to cover many use cases in one place | 09:26 |
| ddeja | OK, I see | 09:26 |
| ddeja | so, If the action is sync we want it to send additional info to engine? | 09:27 |
| ddeja | or we have this information in engine right now and just have to use it? | 09:27 |
| rakhmerov | ddeja: what do you mean by "to engine"? | 09:28 |
| rakhmerov | ok, so | 09:29 |
| ddeja | rakhmerov: well, if i run action like this: c.action_executions.create(name="std.noop") | 09:29 |
| ddeja | the method on_action_complete is not called | 09:29 |
| rakhmerov | yes, right | 09:29 |
| rakhmerov | it's not needed | 09:29 |
| rakhmerov | if save_result is False | 09:30 |
| ddeja | yah, sure, but this is the place where we change state to Success | 09:30 |
| rakhmerov | :) | 09:30 |
| rakhmerov | right | 09:30 |
| rakhmerov | ok, let me explain | 09:30 |
| rakhmerov | this start_action() covers several different use cases | 09:30 |
| rakhmerov | 1) Asynchronous action | 09:31 |
| rakhmerov | In this case we can't get action result after running mistral.actions.base.Action.run() method | 09:31 |
| rakhmerov | so we have to store ActionExecution in order to track execution | 09:31 |
| ddeja | yes | 09:32 |
| rakhmerov | so that when on_action_complete() is called we know what to update with result | 09:32 |
| rakhmerov | ok | 09:32 |
| rakhmerov | in this case we always save action result because we have to, so "save_result" is ignored | 09:32 |
| ddeja | I think that I got your point | 09:32 |
| rakhmerov | yes | 09:32 |
| ddeja | if action is sync and save_result==true, we just wait for executor to return result, there is no need to store anything in the db | 09:33 |
| rakhmerov | 2) Synchronous action for which we want to save a result | 09:33 |
| rakhmerov | yes | 09:33 |
| ddeja | and we just should set state based on that result | 09:33 |
| rakhmerov | 3) Synchronous action for which we don't want to store a result in DB (just run-through kind of behaviour) | 09:33 |
| rakhmerov | ddeja: exactly right | 09:34 |
| rakhmerov | so our use case is #3 | 09:34 |
| rakhmerov | if we build ActionExecution manually in the engine we just need to check if result is successful or not | 09:35 |
| rakhmerov | if it's not we should set state to ERROR and state_info from 'error' field of Result | 09:35 |
| ddeja | ok | 09:35 |
| rakhmerov | like we do in other places | 09:35 |
| rakhmerov | ok | 09:35 |
| openstackgerrit | Merged openstack/mistral: Invalidate workflow spec cache on workflow definition updates https://review.openstack.org/348828 | 09:36 |
| ddeja | ok, I got this, thanks! | 09:36 |
| ddeja | Fix in progress :) | 09:36 |
| rakhmerov | ddeja: cool :) | 09:42 |
| rakhmerov | btw, guys, has anybody ever implemented "upsert" behavior with SQLAlchemy? | 09:43 |
| rakhmerov | it's when I need to "insert or update" an object | 09:43 |
| ddeja | rakhmerov: with SQLAlchemy or with oslo_db? | 10:01 |
| rakhmerov | with any of them | 10:01 |
| ddeja | with sqlAlchemy it should work like in this anwser http://stackoverflow.com/questions/1382469/sqlalchemy-easy-way-to-insert-or-update | 10:01 |
| ddeja | with oslo_db no idea unfortunately | 10:01 |
| rakhmerov | ok, thanks. Will take a look | 10:06 |
| rakhmerov | ddeja: yeah, the problem is that this one won't work concurrently | 10:11 |
| rakhmerov | I need this "insert or update" to work in a single SQL expression | 10:11 |
| rakhmerov | it's kind of like INSERT ... ON DUPLICATE KEY UPDATE | 10:11 |
| kong | rakhmerov: hi, need your suggestion to https://review.openstack.org/#/c/320509/, i am not sure what I explained could answer zane's concern. | 10:15 |
| rakhmerov | kong: hi | 10:15 |
| rakhmerov | ok | 10:15 |
| kong | rakhmerov: thanks | 10:15 |
| rakhmerov | kong: I actually looked at this discussion briefly some time ago but didn't quite get the details | 10:17 |
| kong | rakhmerov: i will be here for next 1 hour, if you have any question, please ask :-) | 10:17 |
| rakhmerov | kong: so what's the problem? The problem is that we have "owner" in permissions for operations with event triggers? | 10:19 |
| kong | rakhmerov: zane's concern is, we should confine the 'admin_only' rule | 10:20 |
| rakhmerov | ok | 10:20 |
| kong | especially for event trigger feature | 10:20 |
| rakhmerov | and why is it not true in your opinion? | 10:20 |
| *** achanda has joined #openstack-mistral | 10:20 | |
| kong | 1. currently, RBAC in Mistral only defines if a user can access Mistral API, it doesn't define if user has access to resources of other users, i.e. in Mistral, you can not list/show/update/delete other user's resources even if you have admin role in admin project. | 10:21 |
| rakhmerov | yeah, because we have isolation | 10:22 |
| kong | 2. It makes functional tests even harder if we only allow admin user in admin project to have access to event trigger aip | 10:22 |
| rakhmerov | on API level | 10:22 |
| kong | rakhmerov: yes | 10:22 |
| rakhmerov | hm... | 10:22 |
| kong | rakhmerov: currently, we don't use admin user for our functional testing | 10:22 |
| kong | and I don't think we need one just for event trigger feature | 10:23 |
| kong | it doesn't make any sense | 10:23 |
| rakhmerov | wait a sec.. | 10:23 |
| kong | things will be same with admin role or not | 10:23 |
| kong | ok | 10:23 |
| rakhmerov | I'm not sure that his concern is about this.. | 10:23 |
| kong | his concern is about notitication | 10:24 |
| rakhmerov | so | 10:25 |
| rakhmerov | his concerned about a huge security breach | 10:25 |
| kong | but I don't see there is any security problem with current implementation | 10:25 |
| rakhmerov | what is the mechanism? Why do we have this breach? | 10:25 |
| rakhmerov | I'm still trying to get this.. | 10:25 |
| kong | rakhmerov: users can only define exchange+topic+event to trigger workflow, they don't have access to notification content actually | 10:26 |
| *** achanda has quit IRC | 10:26 | |
| kong | it's the event-engine service that can do that | 10:27 |
| rakhmerov | because notifications are always issued under admin permissions? | 10:27 |
| kong | rakhmerov: nop. whoever have access to rabbitmq can receieve notification | 10:28 |
| kong | in our case, it's mistral itself | 10:28 |
| rakhmerov | ooh, goosh... | 10:28 |
| rakhmerov | I can't understand.. | 10:28 |
| rakhmerov | ok, let me read to the end | 10:28 |
| kong | rakhmerov: ok, sure | 10:29 |
| rakhmerov | He says: "That doesn't matter, because the oslo.messaging notifications contain data that is private to the operator even if it is about a resource owned by the user, and this features provides a way for the user to extract that private data." | 10:29 |
| rakhmerov | this is kind of what I said | 10:30 |
| rakhmerov | about notifications being issued under admin always | 10:30 |
| rakhmerov | so, things I understood: | 10:33 |
| rakhmerov | 1) There's a bug with admin_only | 10:33 |
| rakhmerov | its definition in Mistral's policy.json is not correct | 10:33 |
| rakhmerov | and he proposes a alternative way of declaring this: "admin_only": "role:admin and auth_token_info.token.is_admin_project:True" | 10:34 |
| rakhmerov | kong: do you agree with this? | 10:34 |
| kong | "this features provides a way for the user to extract that private data" I don't agree on this | 10:35 |
| rakhmerov | why? | 10:35 |
| rakhmerov | could you explain? I don't know all the details | 10:35 |
| kong | in this feature, as I said, users can only define exchange+topic+event to trigger workflow, they don't have access to notification content actually | 10:35 |
| rakhmerov | ooh | 10:36 |
| rakhmerov | I see what you're saying | 10:36 |
| rakhmerov | so Mistral will have access, right? But users of Mistral will never do? | 10:36 |
| rakhmerov | if I understood you | 10:36 |
| kong | absolutely | 10:36 |
| rakhmerov | ok, I see | 10:36 |
| rakhmerov | so, he's saying it must always be admin in admin project, hm... | 10:37 |
| rakhmerov | ok | 10:37 |
| rakhmerov | if what you're saying is true then I also don't see any issues | 10:37 |
| kong | and that admin_only thing doesn't affect mistral for now | 10:37 |
| rakhmerov | because we don't use it for anything else but API endpoints? | 10:38 |
| kong | correct | 10:38 |
| kong | we didn't totally implement RBAC | 10:38 |
| rakhmerov | what do other services do with RBAC? | 10:38 |
| rakhmerov | for example | 10:38 |
| rakhmerov | besides API endpoints | 10:38 |
| kong | e.g. nova | 10:38 |
| rakhmerov | yep | 10:38 |
| kong | admin user can list vms of all tenants | 10:38 |
| rakhmerov | and we can set it in policy.json? | 10:39 |
| kong | but in mistral, admin users can not | 10:39 |
| kong | no. policy.json only affect API access | 10:39 |
| *** venkat has quit IRC | 10:40 | |
| rakhmerov | ok, so basically this should be based on auth token inspection somehow | 10:40 |
| rakhmerov | I guess | 10:40 |
| kong | yes | 10:40 |
| rakhmerov | which contains info about user roles etc. | 10:40 |
| rakhmerov | ok | 10:40 |
| kong | things in db layer | 10:40 |
| rakhmerov | yeah | 10:40 |
| rakhmerov | kong: your last comment looks reasonable to me | 10:43 |
| rakhmerov | let me write a comment too | 10:43 |
| kong | rakhmerov: this is what Nova does: https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L1982 | 10:44 |
| kong | fyi | 10:44 |
| rakhmerov | kong: btw | 10:46 |
| rakhmerov | you said that we don't have access to notification content actually? | 10:47 |
| rakhmerov | as far as I remember we were supposed to? | 10:47 |
| rakhmerov | according to the spec | 10:47 |
| kong | rakhmerov: end user doesn't, but mistral service does. | 10:48 |
| rakhmerov | kong: where can I look at in the code to see that this is right | 10:48 |
| rakhmerov | where does it happen in the code? | 10:48 |
| rakhmerov | link pls? | 10:48 |
| rakhmerov | as far as I remember, we're supposed to pass this notification content to a triggered workflow, no? | 10:49 |
| kong | rakhmerov: yeah, you remind me | 10:50 |
| rakhmerov | so you're saying it's just not implemented differently? | 10:51 |
| rakhmerov | comparing to the spec | 10:51 |
| d0ugal | Why isn't this tool added as a standard setuptools entry point command? https://github.com/openstack/mistral/blob/master/tools/sync_db.py | 10:52 |
| rakhmerov | d0ugal: it's implicitly used by mistral-db-manage which is added | 10:53 |
| d0ugal | rakhmerov: I see, then can't we just remove that? :) | 10:53 |
| rakhmerov | d0ugal: yep, we can :) | 10:53 |
| rakhmerov | kong: ok, I'm now looking at the spec: http://specs.openstack.org/openstack/mistral-specs/specs/newton/approved/event-notification-trigger.html | 10:54 |
| rakhmerov | event_type: <% execution().params.notification_event_type %> | 10:54 |
| rakhmerov | payload: <% execution().params.notification_payload %> | 10:54 |
| kong | rakhmerov: me too | 10:54 |
| rakhmerov | this is how we thought we would pass notification payload to workflow | 10:54 |
| d0ugal | rakhmerov: cool, I'll look into doing that at some point :) | 10:54 |
| rakhmerov | d0ugal: sure | 10:54 |
| rakhmerov | kong: and seems like this is the main Zane's concern | 10:55 |
| rakhmerov | because he said he didn't look at the whole impl | 10:55 |
| rakhmerov | but he remembers the discussions around the spec | 10:55 |
| rakhmerov | kong: I guess this is a confusion point | 10:55 |
| rakhmerov | so 1) if it's implemented differently for now then we should explicitly reply to him and point to this difference | 10:56 |
| rakhmerov | 2) if it's implemented in this way then 2a) Think how to use admin_only (which I hate) 2b) Rip out sensitive info from notification payload somehow | 10:57 |
| rakhmerov | kong: what do you think? | 10:58 |
| kong | rakhmerov: I will take a look at what info contained in the payload. I still hope this feature will be available to normal users. | 10:58 |
| rakhmerov | kong: yeah, I think we need to drill down to details of what this private data actually contains | 11:00 |
| rakhmerov | because w/o this info it all sounds too abstract to me | 11:00 |
| rakhmerov | I'd like to see what exact data we're talking about | 11:00 |
| kong | rakhmerov: yep. | 11:00 |
| rakhmerov | kong: I know you may be anxious about completing this task, I hope it will be soon. But please try to keep patience since it's an important and pretty complicated thing | 11:01 |
| rakhmerov | try not to hurry and dig into all needed details | 11:01 |
| rakhmerov | :) | 11:02 |
| kong | rakhmerov: yes, it really is tricky. | 11:02 |
| rakhmerov | just take more time and investigate it | 11:02 |
| rakhmerov | I know man, I hope you'll be able to take something else soon | 11:02 |
| rakhmerov | actually you can if you want | 11:03 |
| rakhmerov | in parallel with this work | 11:03 |
| kong | rakhmerov: btw, do you know any new additional user cases about mistral willing to share? | 11:03 |
| kong | rakhmerov: I am asking because we have been talking about how to provide mistral service in our public cloud | 11:05 |
| rakhmerov | kong: well, there's a bunch of them but the problem is that we don't have enough hands to summarize them on some public resource | 11:05 |
| rakhmerov | we will at some point | 11:05 |
| kong | rakhmerov: I am keen to see how end user use mistral, rather than how operators or sysadmins use that. | 11:06 |
| kong | because I know mistral is really useful to operators and admins. | 11:06 |
| rakhmerov | yeah | 11:07 |
| kong | and that's also the question I am thinking about when I am preparing my speech in pycon | 11:07 |
| *** shardy is now known as shardy_lunch | 11:14 | |
| *** zhenguo has joined #openstack-mistral | 11:25 | |
| openstackgerrit | Merged openstack/mistral: Update docs and add release not for safe-rerun flag https://review.openstack.org/349449 | 11:32 |
| *** Kiall has quit IRC | 11:34 | |
| openstackgerrit | hardik proposed openstack/mistral: Updated Doc for SSL configuration https://review.openstack.org/349945 | 11:35 |
| *** Kiall has joined #openstack-mistral | 11:36 | |
| d0ugal | ddeja: Congrats of becoming core :) Well deserved! | 11:46 |
| * d0ugal is catching up with emails | 11:46 | |
| ddeja | d0ugal: thank you :) | 11:47 |
| *** dprince has joined #openstack-mistral | 11:55 | |
| *** jaosorior has joined #openstack-mistral | 12:04 | |
| jaosorior | Hello folks | 12:04 |
| *** shardy_lunch is now known as shardy | 12:05 | |
| jaosorior | So, I ran into an issue with the baremetal_introspection actions. Where the action creation is done erronously if python-ironic-inspector is listening on something other than localhost or 0.0.0.0 | 12:13 |
| jaosorior | It seems that the issue is that when populating the actions. No keystone session is passed. And at some point python-ironic-inspector, when donig the __init__ in the class, tries to call itself to get the version | 12:14 |
| jaosorior | which ends up failing | 12:14 |
| jaosorior | dprince ^^ | 12:14 |
| jaosorior | anyway guys, anybody has ideas on how to fix it? | 12:15 |
| dprince | jaosorior: http://git.openstack.org/cgit/openstack/mistral/tree/mistral/actions/openstack/actions.py#n383 | 12:16 |
| dprince | jaosorior: we should be setting a version=1 there | 12:17 |
| jaosorior | dprince: no, the issue is when populating the database https://github.com/openstack/mistral/blob/master/mistral/actions/openstack/action_generator/base.py#L86 | 12:17 |
| jaosorior | dprince: That is before any action is taken. When mistral is getting those actions from the json mapping | 12:18 |
| dprince | jaosorior: right, so perhaps we need a _get_fake_client for the inspector | 12:18 |
| dprince | jaosorior: when populating the actions mistral uses the _get_fake_client functions | 12:18 |
| dprince | jaosorior: some of the actions don't require this function... but perhaps we missed that ironic inspector does? | 12:19 |
| jaosorior | dprince: Can you show an example? | 12:19 |
| *** SonalOjha has joined #openstack-mistral | 12:19 | |
| dprince | jaosorior: http://git.openstack.org/cgit/openstack/mistral/tree/mistral/actions/openstack/actions.py#n549 | 12:19 |
| dprince | jaosorior: if you grep for that function you should see its usage | 12:20 |
| jaosorior | Ah | 12:20 |
| jaosorior | that seems like it could work! | 12:20 |
| jaosorior | dprince: Thanks dude, I'll submit a fix in a bit | 12:22 |
| SonalOjha | I have been facing issues with mistral executions deleting from the mistral executions_v2 table, I could see the execution in the logs but somehow it gets deleted from the database | 12:22 |
| dprince | jaosorior: NP. link me and I'll +1 | 12:22 |
| SonalOjha | can someone help? | 12:22 |
| SonalOjha | need a lead to whats exactly happening | 12:23 |
| *** achanda has joined #openstack-mistral | 12:24 | |
| jaosorior | dprince: Anyway, once this is fixed the ironic-inspector TLS code will work | 12:26 |
| ddeja | SonalOjha: Hi, please provide: logs from executor and engine; command for startign your workflow; workflow definition. Thanks | 12:26 |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/mistral: Make ironic-inspector use specific version https://review.openstack.org/349968 | 12:27 |
| *** achanda has quit IRC | 12:29 | |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/mistral: Add _get_fake_client to ironic-inspector actions https://review.openstack.org/349968 | 12:32 |
| *** szaher has joined #openstack-mistral | 12:33 | |
| SonalOjha | ddeja: I am using a direct workflow (cant really share the workflow) .. but every task is dependent on another task like task1: action : ... on-success: task2 task2: action : ... on-success: task3 and so on | 12:34 |
| SonalOjha | ddeja: I see logs | 12:34 |
| SonalOjha | 02/Aug/2016:11:32:48 +0000 WF INFO [-] Starting workflow: 'xxxxx.xxxxx' (execution_id=fc9c0fa2-7cf0-48dc-8291-bf892122bb08) 02/Aug/2016:11:32:50 +0000 WF INFO [-] Task 'xxxxxx' is RUNNING [action_name = <action1>] (execution_id=fc9c0fa2-7cf0-48dc-8291-bf892122bb08 task_id=db3ba52a-374d-49bf-b5a9-250969c1e65b) 02/Aug/2016:11:32:54 +0000 WF INFO [-] Action execution '<action1>' [RUNNING -> SUCCESS, result = {u'token': u'a | 12:35 |
| SonalOjha | ddeja: but after a while I dont see the execution in the database nor could query through mistral cli | 12:36 |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/mistral: Add _get_fake_client to ironic-inspector actions https://review.openstack.org/349968 | 12:36 |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/mistral: Add _get_fake_client to ironic-inspector actions https://review.openstack.org/349968 | 12:37 |
| openstackgerrit | hardik proposed openstack/mistral-dashboard: Remove requirements satisfied by horizon https://review.openstack.org/315542 | 12:39 |
| openstackgerrit | hardik proposed openstack/mistral-dashboard: Remove requirements satisfied by horizon https://review.openstack.org/315542 | 12:39 |
| *** toddjohn has joined #openstack-mistral | 12:41 | |
| *** toddjohn has quit IRC | 12:43 | |
| *** toddjohn has joined #openstack-mistral | 12:44 | |
| *** bobh has joined #openstack-mistral | 12:44 | |
| *** janki has quit IRC | 12:48 | |
| *** janki has joined #openstack-mistral | 12:48 | |
| *** bobh has quit IRC | 12:52 | |
| ddeja | SonalOjha: hm, is there a moment that you can see execution in the DB and then it disappears? | 12:57 |
| ddeja | or it just doesn't appear at all? | 12:58 |
| *** rbrady has joined #openstack-mistral | 13:01 | |
| *** toddjohn has quit IRC | 13:06 | |
| openstackgerrit | Dawid Deja proposed openstack/mistral: Add state info for synchronous actions run from CLI https://review.openstack.org/349993 | 13:06 |
| *** toddjohn has joined #openstack-mistral | 13:06 | |
| *** clenimar has quit IRC | 13:09 | |
| ddeja | jtomasek: https://review.openstack.org/349993 here will land fix for your issue | 13:09 |
| *** clenimar has joined #openstack-mistral | 13:10 | |
| *** nmakhotkin has quit IRC | 13:10 | |
| *** toddjohn has quit IRC | 13:10 | |
| *** bobh has joined #openstack-mistral | 13:20 | |
| *** nmakhotkin has joined #openstack-mistral | 13:27 | |
| SonalOjha | ddeja it appears momentarily | 13:35 |
| SonalOjha | ddeja: I could see the execution details in mistral dashboard / mistral cli but later it just gets deleted | 13:36 |
| openstackgerrit | Andras Kovi proposed openstack/mistral: Add target parameters to REST API https://review.openstack.org/339349 | 13:39 |
| *** rbrady has quit IRC | 13:42 | |
| *** toddjohn has joined #openstack-mistral | 13:44 | |
| *** rbrady has joined #openstack-mistral | 13:53 | |
| *** rbrady has quit IRC | 13:56 | |
| ddeja | SonalOjha: To be honest, I'm not aware of any mechanism that would delete anything from the DB... rakhmerov, hparekh are there any? | 14:03 |
| d0ugal | Are action executions often used in production? | 14:03 |
| ddeja | d0ugal: no idea | 14:04 |
| d0ugal | I feel like they are mostly useful for development etc. but we have a simple action in TripleO and we are considering documenting that users should call it directly | 14:04 |
| d0ugal | Since providing a workflow to call one action seems a bit silly | 14:04 |
| d0ugal | I just want to check there are no downsides | 14:04 |
| ddeja | d0ugal: from Executor point of view, it would be run in a same manner as if it would be part of workflow | 14:05 |
| ddeja | and if it would be run with flag save_result set to true, it would be store in a DB, just like wf action | 14:05 |
| d0ugal | ddeja: but I guess it skips scheduling and is just executed directly? | 14:06 |
| SonalOjha | ddeja: I see few database entries having no workflow_execution_id | 14:06 |
| ddeja | d0ugal: well, it still uses rabbitmq round-robin capability | 14:07 |
| d0ugal | ddeja: oh okay, cool | 14:07 |
| ddeja | SonalOjha: it may happen if you run some action without workflow | 14:08 |
| ddeja | using mistral run-action | 14:08 |
| *** SonalOjha has quit IRC | 14:10 | |
| *** tonytan4ever has joined #openstack-mistral | 14:17 | |
| *** rbrady has joined #openstack-mistral | 14:19 | |
| jtomasek | ddeja, d0ugal: using save_result has one implication: In case action-execution is called with save_result flag, then it behaves just like workflow -> does not give result as part of the response to the request that triggered action-execution | 14:24 |
| d0ugal | jtomasek: heh, that is weird | 14:25 |
| ddeja | jtomasek: yes, becouse it is scheduled to be run later | 14:25 |
| jtomasek | d0ugal: agree, I got quite confused by it at first | 14:25 |
| ddeja | you can then get the results later using 'get' | 14:25 |
| jtomasek | ddeja: yeah, but that is another api call | 14:26 |
| ddeja | but nevertheless, I have a fix for your issue, so do not worry | 14:26 |
| ddeja | jtomasek: ^ | 14:26 |
| jtomasek | ddeja: :) yeah | 14:26 |
| ddeja | I'm just waiting for jenkins to run test to show that there is a problem and I'll push fix | 14:27 |
| d0ugal | Nice! | 14:27 |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/mistral: Add _get_fake_client to ironic-inspector actions https://review.openstack.org/349968 | 14:28 |
| *** achanda has joined #openstack-mistral | 14:36 | |
| *** achanda has quit IRC | 14:48 | |
| *** ddeja is now known as ddeja|away | 14:51 | |
| *** rrecio has joined #openstack-mistral | 14:53 | |
| *** rrecio_ has joined #openstack-mistral | 14:59 | |
| *** rrecio has quit IRC | 15:01 | |
| *** janki has quit IRC | 15:13 | |
| *** jaosorior has quit IRC | 15:52 | |
| *** venkat has joined #openstack-mistral | 15:52 | |
| *** janki has joined #openstack-mistral | 15:56 | |
| *** gokrokve has joined #openstack-mistral | 16:02 | |
| *** nmakhotkin has quit IRC | 16:08 | |
| *** gokrokve has quit IRC | 16:17 | |
| *** toddjohn has quit IRC | 16:17 | |
| *** brian_price has joined #openstack-mistral | 16:19 | |
| *** krotscheck is now known as krot_sickleave | 16:27 | |
| *** jpich has quit IRC | 16:47 | |
| *** toddjohn_ has joined #openstack-mistral | 16:53 | |
| *** chlong has quit IRC | 16:58 | |
| *** venkat has quit IRC | 17:00 | |
| *** bobh has quit IRC | 17:08 | |
| *** chlong has joined #openstack-mistral | 17:11 | |
| *** janki has quit IRC | 17:21 | |
| *** bobh has joined #openstack-mistral | 17:38 | |
| *** bobh has quit IRC | 17:39 | |
| openstackgerrit | Michal Gershenzon proposed openstack/mistral: DB migration to three execution tables and increase some columns https://review.openstack.org/350183 | 17:59 |
| *** shardy has quit IRC | 18:10 | |
| *** toddjohn_ has quit IRC | 18:12 | |
| *** toddjohn has joined #openstack-mistral | 18:13 | |
| *** Ravikiran_K has quit IRC | 18:14 | |
| *** bobh has joined #openstack-mistral | 18:39 | |
| *** bobh has quit IRC | 18:44 | |
| *** toddjohn has quit IRC | 19:19 | |
| *** toddjohn has joined #openstack-mistral | 19:19 | |
| *** toddjohn has quit IRC | 19:19 | |
| *** toddjohn has joined #openstack-mistral | 19:20 | |
| *** toddjohn has quit IRC | 19:20 | |
| *** toddjohn has joined #openstack-mistral | 19:20 | |
| *** toddjohn has quit IRC | 19:24 | |
| *** toddjohn has joined #openstack-mistral | 19:28 | |
| *** bobh has joined #openstack-mistral | 19:40 | |
| *** bobh has quit IRC | 19:47 | |
| *** dprince has quit IRC | 19:51 | |
| *** toddjohn has quit IRC | 20:25 | |
| *** toddjohn has joined #openstack-mistral | 20:27 | |
| *** toddjohn has quit IRC | 20:31 | |
| *** openstackgerrit_ has joined #openstack-mistral | 20:35 | |
| *** openstackgerrit_ has quit IRC | 20:36 | |
| *** tonytan4ever has quit IRC | 20:46 | |
| *** toddjohn has joined #openstack-mistral | 21:00 | |
| *** toddjohn has quit IRC | 21:03 | |
| *** toddjohn has joined #openstack-mistral | 21:03 | |
| *** toddjohn has quit IRC | 21:09 | |
| *** bobh has joined #openstack-mistral | 21:44 | |
| *** tonytan4ever has joined #openstack-mistral | 21:47 | |
| *** bobh has quit IRC | 21:49 | |
| *** tonytan4ever has quit IRC | 21:52 | |
| *** brian_price has quit IRC | 23:47 | |
| *** dprince has joined #openstack-mistral | 23:56 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!