| *** d0ugal has quit IRC | 01:38 | |
| *** d0ugal has joined #openstack-mistral | 01:53 | |
| *** csatari has quit IRC | 03:42 | |
| *** csatari has joined #openstack-mistral | 03:45 | |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral master: moved generic util functions from mistral to mistral-lib https://review.opendev.org/676373 | 04:23 |
|---|---|---|
| *** eyalb has joined #openstack-mistral | 04:57 | |
| *** jtomasek has joined #openstack-mistral | 05:13 | |
| *** boxiang has joined #openstack-mistral | 05:42 | |
| *** pgaxatte has joined #openstack-mistral | 06:26 | |
| *** ricolin has joined #openstack-mistral | 06:38 | |
| *** ricolin has quit IRC | 06:39 | |
| openstackgerrit | Merged openstack/mistral master: Add db api tests for scheduled jobs https://review.opendev.org/669559 | 06:40 |
| boxiang | hi everyone here | 06:45 |
| boxiang | I meet a problem when I use the mistral cron trigger | 06:45 |
| boxiang | I create a workflow which will create a volume and also will create a trigger such as deleting volume. | 06:46 |
| boxiang | then I create a cron trigger for this workflow | 06:47 |
| boxiang | but when the cron trigger is running, we meet some error info in mistral-executor.log | 06:48 |
| boxiang | as followed | 06:48 |
| boxiang | Authorization failed: You are not authorized to perform the requested action: Using trust-scoped token to create another token. Create a new trust-scoped token instead. | 06:49 |
| boxiang | anybody knows how to handle this? | 06:50 |
| boxiang | thanks | 06:50 |
| rakhmerov | boxiang: hi | 07:53 |
| rakhmerov | what this something similar? https://review.opendev.org/#/c/680858/ | 07:53 |
| rakhmerov | was.. | 07:53 |
| rakhmerov | I guess it's your patch, no? | 07:54 |
| rakhmerov | boxiang: we are generally aware of such issues with trusts, but they are not really solved yet in a good way | 07:55 |
| rakhmerov | #startmeeting Mistral | 08:00 |
| openstack | Meeting started Wed Sep 11 08:00:43 2019 UTC and is due to finish in 60 minutes. The chair is rakhmerov. Information about MeetBot at http://wiki.debian.org/MeetBot. | 08:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 08:00 |
| *** openstack changes topic to " (Meeting topic: Mistral)" | 08:00 | |
| rakhmerov | hi all | 08:00 |
| openstack | The meeting name has been set to 'mistral' | 08:00 |
| vgvoleg | hi! | 08:00 |
| rakhmerov | if there's anyone here for the meeting reveal yourself! ) | 08:01 |
| rakhmerov | vgvoleg: hi | 08:01 |
| rakhmerov | eyalb: ^ | 08:01 |
| vgvoleg | I'd like to discuss something | 08:02 |
| rakhmerov | guys, I have to step away urgently for 20-30 mins. Oleg, please start writing your topics/questions, I'll join later | 08:02 |
| vgvoleg | First of all, I've found that notifier base is not moved to mistral_lib | 08:02 |
| vgvoleg | so to write custom publisher we should import mistral | 08:03 |
| vgvoleg | I guess that it is not OK and I'm going to move it | 08:03 |
| vgvoleg | Nod if you agree :D | 08:04 |
| rakhmerov | Nodding.. ) | 08:04 |
| vgvoleg | Secondly, I've found that PUT operations in our api are not safe at all | 08:04 |
| rakhmerov | ? | 08:05 |
| vgvoleg | We can break anything if we send multiple put requests to one execution | 08:06 |
| vgvoleg | no check mechanisms | 08:06 |
| vgvoleg | no locks | 08:06 |
| vgvoleg | we can send contradictory commands to engine at the same time | 08:07 |
| vgvoleg | it is not ok | 08:07 |
| vgvoleg | And, IMO, it should be fixed on the api side | 08:08 |
| vgvoleg | But I don't know how to do it nice | 08:08 |
| vgvoleg | And the third topic I'd like to discuss it our ERROR state | 08:09 |
| vgvoleg | in our state machine, SUCCESS is truly terminal, we can't do anything with execution if it was completed successfully | 08:10 |
| vgvoleg | but ERROR is not truly terminal - we can rerun it, for example | 08:10 |
| vgvoleg | and I think that it is a gap, that we don't have truly terminal state to indicate error | 08:11 |
| vgvoleg | Something that moves ERROR execution to read-only | 08:12 |
| vgvoleg | Something that means "OK, we don't care that it is failed and we are not going to do anything with it" | 08:13 |
| vgvoleg | I think we can use CANCELLED state for it, but current implementation does not support this transaction | 08:14 |
| vgvoleg | maybe we should add any additional state for this | 08:15 |
| openstackgerrit | yatin proposed openstack/mistral master: moved generic util functions from mistral to mistral-lib https://review.opendev.org/676373 | 08:15 |
| vgvoleg | I dont know tbh | 08:15 |
| vgvoleg | So I'll be glad to listen your opinion | 08:16 |
| rakhmerov | I'm here | 08:22 |
| rakhmerov | reading.. | 08:22 |
| rakhmerov | vgvoleg: on your 2nd thing, can you given an example? | 08:22 |
| vgvoleg | rakhmerov: sure, we can send two PUT requests to /v2/executions, the first request should pause execution, the second one should cancel it | 08:24 |
| rakhmerov | on #3 I don't see why it is a real problem. It's all kind of relative, terminal or non-terminal. ERROR is really considered terminal from perspective of the running workflow | 08:24 |
| rakhmerov | rerun mechanism is not a regular part of the execution process | 08:24 |
| rakhmerov | vgvoleg: so what can happen? | 08:25 |
| vgvoleg | and API will send two commands to the engine | 08:25 |
| vgvoleg | which is not ok | 08:25 |
| rakhmerov | so? | 08:25 |
| rakhmerov | what bad is going to happen? | 08:25 |
| rakhmerov | what's going to break? | 08:26 |
| vgvoleg | it's a dice roll | 08:26 |
| rakhmerov | why? | 08:26 |
| rakhmerov | Oleg, it is something that a user can legally do | 08:27 |
| rakhmerov | it's out of our control | 08:27 |
| rakhmerov | yes, they can do it virtually simulteneously | 08:27 |
| rakhmerov | but what will be broken in Mistral? | 08:27 |
| vgvoleg | ok, I dont have the concrete example right now :D | 08:28 |
| rakhmerov | if the CANCEL request comes first it will win, the PAUSE request will fail because it'll see that the execution is not in a proper state | 08:28 |
| rakhmerov | if we'll have an opposite order I don't see any issues as well | 08:29 |
| rakhmerov | as far as I remember we can legally cancel workflows that are in PAUSE state | 08:29 |
| vgvoleg | ok ok ok I'll find a bug for sure | 08:29 |
| vgvoleg | about #3 | 08:30 |
| rakhmerov | remember that in both cases it will be one DB TX | 08:30 |
| vgvoleg | we should strictly separate terminal states and not-terminal states | 08:30 |
| rakhmerov | it will either fail w/o changing anything in DB or will succeed and not let the other one make changes | 08:30 |
| rakhmerov | vgvoleg: what does "strictly" mean here? | 08:31 |
| vgvoleg | since we have rerun mechanism, ERROR is not terminal state | 08:31 |
| rakhmerov | it is a terminal state from perspective of the certain scenario | 08:31 |
| vgvoleg | so we can't work with it like it is a read-only | 08:31 |
| vgvoleg | we can't cache it and so on | 08:31 |
| rakhmerov | ok, what's the practical task you're trying to solve? ) | 08:32 |
| rakhmerov | we can but we need to do a better job when caching | 08:32 |
| rakhmerov | invalidating etc. | 08:32 |
| vgvoleg | I want to have a state that means ERROR, but will be read only | 08:33 |
| rakhmerov | what will be the difference? | 08:33 |
| rakhmerov | from the regular ERROR? | 08:33 |
| vgvoleg | so that I’m sure that it will not change | 08:33 |
| rakhmerov | I don't understand | 08:33 |
| vgvoleg | the current ERROR execution could be changed | 08:34 |
| rakhmerov | what's the point? Why can't we rerun a workflow in that state too? | 08:34 |
| vgvoleg | because it is read only | 08:34 |
| rakhmerov | I mean logically what will be the difference? | 08:35 |
| vgvoleg | it is a terminal state, that means it will be not changed | 08:35 |
| rakhmerov | how are we going to explain user why we can rerun one ERROR state and can't rerun another kind of ERROR state? | 08:35 |
| vgvoleg | so there will be a transition (something like) TEMPORARY ERROR -> ERROR | 08:36 |
| vgvoleg | and this will be human-initiated operation | 08:36 |
| rakhmerov | nope | 08:37 |
| rakhmerov | I fail to understand this.. | 08:37 |
| vgvoleg | Renat right now we call ERROR state as a terminal | 08:37 |
| vgvoleg | but it is not terminal state | 08:37 |
| rakhmerov | so all workflows have to be moved to that state only if a human says to do so? | 08:37 |
| vgvoleg | so I want to have the FINAL_ERROR state | 08:38 |
| rakhmerov | Oleg, again: in a certain scenario it is a terminal state | 08:38 |
| rakhmerov | caching is a completely different problem | 08:38 |
| rakhmerov | it's an implementation issue that we need to solve | 08:38 |
| vgvoleg | caching was my stupid example | 08:38 |
| rakhmerov | w/o letting users know about it | 08:38 |
| vgvoleg | of use cases of read only objects | 08:39 |
| vgvoleg | I told about external caching | 08:39 |
| vgvoleg | not in Mistral | 08:39 |
| rakhmerov | I don't see any point in having one more state for ERROR, really. What would be an explanation for users? | 08:39 |
| rakhmerov | imagine someone coming here and asking "Guys, why did you add one more state? I lived just fine w/o it." | 08:40 |
| rakhmerov | what are you going to answer? | 08:40 |
| vgvoleg | Because we want to be honest with our clients | 08:40 |
| vgvoleg | ERROR is not terminal | 08:40 |
| rakhmerov | "The new state is terminal, the old one is not" ? | 08:40 |
| vgvoleg | yes | 08:40 |
| vgvoleg | :) | 08:40 |
| rakhmerov | vgvoleg: Oleg, lots of clients don't care it all whether something is terminal or not :) | 08:41 |
| vgvoleg | because right now we say that ERROR is a terminal state | 08:41 |
| rakhmerov | in a certain (most common) scenario it's 100% true | 08:41 |
| vgvoleg | yes | 08:42 |
| vgvoleg | sure | 08:42 |
| rakhmerov | let's not bother users with such mathematical kid of terms at all. It's not what they care about | 08:42 |
| vgvoleg | until people find out that mistral has an amazing feature like rerun | 08:43 |
| rakhmerov | ERROR is a truly terminal state meaning that a system doesn't have an automatic algorithm that can change this state to something else | 08:43 |
| rakhmerov | only a human reasonably can | 08:43 |
| rakhmerov | but in this case they know what they are doing and they don't care if it's not considered globally terminal anymore | 08:44 |
| rakhmerov | because it's they decision to change it | 08:44 |
| rakhmerov | but if we're talking about automatic processing it's 100% terminal | 08:44 |
| vgvoleg | while we say that this is a terminal state, users can assume that such a state does not change, they can build their logic around this | 08:45 |
| rakhmerov | again: they make a decision to change this state themselves :) | 08:46 |
| rakhmerov | they know that it can change | 08:47 |
| vgvoleg | ok I got what you mean | 08:47 |
| rakhmerov | but only if they want to | 08:47 |
| rakhmerov | automatically it can never ever change to something else | 08:47 |
| vgvoleg | probably I'll return with this discussion when there will be more people :D | 08:49 |
| vgvoleg | that's all, thank you! | 08:50 |
| rakhmerov | ok :) | 08:51 |
| boxiang | rakhmerov: https://review.opendev.org/#/c/680858/ can not fix my issue. | 08:51 |
| rakhmerov | ok, let's wrap for now | 08:55 |
| rakhmerov | #endmeeting | 08:55 |
| *** openstack changes topic to "Mistral the Workflow Service for OpenStack. https://docs.openstack.org/mistral/latest/" | 08:55 | |
| openstack | Meeting ended Wed Sep 11 08:55:08 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 08:55 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/mistral/2019/mistral.2019-09-11-08.00.html | 08:55 |
| rakhmerov | boxiang: ok | 08:55 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/mistral/2019/mistral.2019-09-11-08.00.txt | 08:55 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/mistral/2019/mistral.2019-09-11-08.00.log.html | 08:55 |
| boxiang | but for the patch you have pasted, I alse meet the issue. And after I apply the patch, I find it can fix the bug https://bugs.launchpad.net/mistral/+bug/1843175 | 08:57 |
| openstack | Launchpad bug 1843175 in Mistral "Error validate token when run an action with cron trigger" [Medium,In progress] - Assigned to Bo Tran (ministry.nd) | 08:57 |
| boxiang | rakhmerov: but my issue is not for normal user to use cron trigger | 08:57 |
| boxiang | in short, just like in cron trigger to create a new cron trigger | 08:58 |
| boxiang | but it failed | 08:58 |
| boxiang | rakhmerov: thanks :) | 08:59 |
| *** zhubx has joined #openstack-mistral | 09:26 | |
| *** boxiang has quit IRC | 09:29 | |
| *** pgaxatte has quit IRC | 09:52 | |
| *** vgvoleg has quit IRC | 10:06 | |
| *** d0ugal has quit IRC | 10:16 | |
| *** d0ugal has joined #openstack-mistral | 10:30 | |
| openstackgerrit | Eyal proposed openstack/mistral master: Add a cookiecutter template to generate custom stuff https://review.opendev.org/679782 | 12:08 |
| *** pgaxatte has joined #openstack-mistral | 12:10 | |
| openstackgerrit | Bo Tran proposed openstack/mistral-dashboard master: Add pagination for objects in mistral https://review.opendev.org/681453 | 12:13 |
| openstackgerrit | Eyal proposed openstack/mistral master: Add a cookiecutter template to generate custom stuff https://review.opendev.org/679782 | 12:24 |
| openstackgerrit | Eyal proposed openstack/mistral master: Add a cookiecutter template to generate custom stuff https://review.opendev.org/679782 | 13:40 |
| *** ricolin has joined #openstack-mistral | 14:18 | |
| *** eyalb has quit IRC | 14:34 | |
| *** zhubx has quit IRC | 14:37 | |
| *** zhubx has joined #openstack-mistral | 14:37 | |
| *** zhubx has quit IRC | 14:41 | |
| *** zhubx has joined #openstack-mistral | 14:41 | |
| *** zhubx has quit IRC | 14:43 | |
| *** zhubx has joined #openstack-mistral | 14:44 | |
| *** pgaxatte has quit IRC | 14:54 | |
| *** d0ugal has quit IRC | 15:44 | |
| *** d0ugal has joined #openstack-mistral | 15:59 | |
| *** ricolin has quit IRC | 16:22 | |
| *** d0ugal has quit IRC | 17:04 | |
| *** d0ugal has joined #openstack-mistral | 17:09 | |
| *** d0ugal has quit IRC | 18:47 | |
| *** d0ugal has joined #openstack-mistral | 18:52 | |
| *** pgaxatte has joined #openstack-mistral | 19:33 | |
| *** pgaxatte has quit IRC | 19:36 | |
| *** boxiang has joined #openstack-mistral | 21:19 | |
| *** zhubx has quit IRC | 21:20 | |
| *** threestrands has joined #openstack-mistral | 22:37 | |
| *** d0ugal has quit IRC | 23:23 | |
| *** d0ugal has joined #openstack-mistral | 23:25 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!