| *** apetrich has quit IRC | 02:10 | |
| zhubx | rakhmerov: ok, I will try to confirm it whether can fix my issue thanks :) | 03:11 |
|---|---|---|
| zhubx | hello rakhmerov | 03:14 |
| zhubx | I read the issue https://bugs.launchpad.net/mistral/+bug/1796820 | 03:14 |
| openstack | Launchpad bug 1788174 in Mistral "duplicate for #1796820 Mistral uses deprecated option keystone_authtoken/auth_uri for keystoneclient creation" [Medium,Fix released] - Assigned to Brad P. Crochet (brad-9) | 03:14 |
| zhubx | and the patch https://review.opendev.org/#/c/594187/ | 03:14 |
| zhubx | but I found that it is not the issue I met | 03:15 |
| zhubx | But from the launchpad I found the same issue I met | 03:15 |
| zhubx | The link is https://bugs.launchpad.net/mistral/+bug/1721508 | 03:15 |
| openstack | Launchpad bug 1721508 in Mistral "Cannot create cron-trigger using trust-scoped token" [High,Confirmed] | 03:16 |
| zhubx | But noone has fixed it | 03:16 |
| zhubx | rakhmerov ^ | 03:16 |
| zhubx | thanks | 03:16 |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral master: Optimize creation of language specs https://review.opendev.org/682024 | 03:24 |
| rakhmerov | zhubx: hi | 03:30 |
| rakhmerov | so should I restore this ticket? | 03:32 |
| rakhmerov | zhubx: ^ | 03:32 |
| zhubx | yes | 03:51 |
| zhubx | https://bugs.launchpad.net/mistral/+bug/1721508 this ticket | 03:51 |
| openstack | Launchpad bug 1721508 in Mistral "Cannot create cron-trigger using trust-scoped token" [High,Confirmed] | 03:51 |
| *** ricolin has joined #openstack-mistral | 03:54 | |
| rakhmerov | zhubx: ok, thanks | 03:54 |
| rakhmerov | zhubx: hey, by the way, do you use happen to use openstack actions with Mistral? | 03:54 |
| rakhmerov | we now have one failing test in CI | 03:55 |
| rakhmerov | seems like something has changed and we need to create a client for some libs in a different way now | 03:55 |
| rakhmerov | e.g. designate | 03:55 |
| zhubx | yes, I use openstack actions with mistral | 03:56 |
| rakhmerov | ok | 03:56 |
| rakhmerov | so if you have some time may be you could help with this issue | 03:57 |
| zhubx | ok but sorry, now I have few time to fix this issue :( | 03:58 |
| rakhmerov | that's ok | 03:58 |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral master: Use v2 designate client instead of v1 https://review.opendev.org/682785 | 04:19 |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral master: Use v2 designate client instead of v1 https://review.opendev.org/682785 | 04:35 |
| *** eyalb has joined #openstack-mistral | 05:09 | |
| *** jtomasek has joined #openstack-mistral | 05:13 | |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral master: Use v2 designate client instead of v1 https://review.opendev.org/682785 | 05:18 |
| *** pgaxatte has joined #openstack-mistral | 06:13 | |
| *** eyalb1 has joined #openstack-mistral | 06:27 | |
| *** eyalb has quit IRC | 06:30 | |
| *** eyalb has joined #openstack-mistral | 06:48 | |
| *** eyalb1 has quit IRC | 06:50 | |
| *** eyalb1 has joined #openstack-mistral | 06:59 | |
| *** apetrich has joined #openstack-mistral | 06:59 | |
| *** eyalb has quit IRC | 07:01 | |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral master: Use v2 designate client instead of v1 https://review.opendev.org/682785 | 07:46 |
| *** akovi has joined #openstack-mistral | 07:54 | |
| *** vgvoleg has joined #openstack-mistral | 07:54 | |
| rakhmerov | hi | 08:02 |
| rakhmerov | anybody wants to discuss anything? | 08:02 |
| vgvoleg | hi! | 08:03 |
| vgvoleg | one question | 08:03 |
| akovi | hi | 08:03 |
| akovi | we have a failing test | 08:03 |
| rakhmerov | akovi: fixing it | 08:03 |
| rakhmerov | https://review.opendev.org/682785 | 08:03 |
| rakhmerov | hopefully it's going to work now | 08:03 |
| rakhmerov | #startmeeting Mistral | 08:04 |
| openstack | Meeting started Wed Sep 18 08:04:02 2019 UTC and is due to finish in 60 minutes. The chair is rakhmerov. Information about MeetBot at http://wiki.debian.org/MeetBot. | 08:04 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 08:04 |
| *** openstack changes topic to " (Meeting topic: Mistral)" | 08:04 | |
| openstack | The meeting name has been set to 'mistral' | 08:04 |
| rakhmerov | so hi :) | 08:04 |
| rakhmerov | vgvoleg: go ahead | 08:04 |
| vgvoleg | hellllllo | 08:04 |
| vgvoleg | I'm again with non-terminal error... :D | 08:04 |
| vgvoleg | We want to have an ability to cancel executions in error state | 08:04 |
| rakhmerov | 🤟 | 08:04 |
| rakhmerov | vgvoleg: why do you want it? ) | 08:05 |
| rakhmerov | akovi: Andras, btw, can you take a look please at https://review.opendev.org/#/c/682785/ ? | 08:05 |
| vgvoleg | so it is probably a good compromise to make execution in error state in something terminal | 08:05 |
| akovi | rakhmerov: done | 08:06 |
| rakhmerov | akovi: the tests now are OK but I have doubts if initialization of the client is right | 08:06 |
| rakhmerov | I'm not too good at all these keystone related stuff | 08:06 |
| akovi | as long as it accepts session, it should be ok | 08:06 |
| rakhmerov | yes, that was my thinking too | 08:07 |
| rakhmerov | 🤦♀️ | 08:08 |
| rakhmerov | vgvoleg: ^ | 08:08 |
| rakhmerov | :)) | 08:08 |
| vgvoleg | '=( | 08:08 |
| rakhmerov | vgvoleg: why do you keep talking so desperately about terminal states? :) | 08:08 |
| vgvoleg | Because we need to make executions in error state read-only | 08:09 |
| rakhmerov | only read them when they are in ERROR state :) | 08:09 |
| vgvoleg | I really can't understand why do you think it is not a gap | 08:09 |
| rakhmerov | I'm failing to understand that this is a gap | 08:10 |
| vgvoleg | so the alternative is to let us transfer ERROR to CANCELLED | 08:10 |
| rakhmerov | Oleg | 08:10 |
| rakhmerov | I'll raise my point again | 08:10 |
| rakhmerov | we have some functionality that automatically moves a workflow execution to ERROR | 08:11 |
| rakhmerov | (in some cases) | 08:11 |
| rakhmerov | then a client makes a conscious decision (this is important!) to rerun the workflow | 08:11 |
| vgvoleg | in the state machine there would be an arrow from ERROR to RUNNING, so the output state could be changed after some time | 08:12 |
| rakhmerov | and the client knows what workflow it decided to rerun | 08:12 |
| rakhmerov | wait a sec.. | 08:12 |
| rakhmerov | and what is the problem for this client to keep track of what workflows can and can't be rerun anymore? | 08:12 |
| rakhmerov | it's completely the responsibility of the client | 08:13 |
| vgvoleg | because there could be many clients | 08:13 |
| rakhmerov | ok, what is the formal criteria on how we decide if a workflow can be rerun or not? | 08:14 |
| vgvoleg | it's really a headache | 08:14 |
| vgvoleg | this criteria is error state | 08:14 |
| rakhmerov | no | 08:14 |
| rakhmerov | I mean something different | 08:14 |
| rakhmerov | for example, we added this truly terminal ERROR state | 08:14 |
| vgvoleg | ok | 08:15 |
| rakhmerov | what will be the semantical difference between it and the rerunable ERROR state? | 08:15 |
| rakhmerov | how do you reply a question: how do we decide what can be rerun or not? | 08:16 |
| rakhmerov | based on what? | 08:16 |
| vgvoleg | if we understand that this execution is failed and we agree with this and are not going to do anything about it | 08:16 |
| vgvoleg | so we can take it manually to read-only | 08:16 |
| rakhmerov | who agrees? | 08:16 |
| rakhmerov | a human? | 08:16 |
| vgvoleg | yes | 08:16 |
| rakhmerov | aah... | 08:17 |
| rakhmerov | just do it on the client side, that's it | 08:17 |
| akovi | my feeling is that you are kind of trying to integrate a higher level abstract state into the current state model | 08:17 |
| rakhmerov | if you have many clients they can exchange this info | 08:17 |
| rakhmerov | via DB, MQ, no matter what.. | 08:17 |
| rakhmerov | akovi: yes, exactly | 08:17 |
| akovi | the "granite ERROR" will be set only from clients or will we need to extend the language too? | 08:18 |
| rakhmerov | it's not consistent with the set (you can treat in a mathematical sense) of states that currently exist | 08:18 |
| vgvoleg | In my point of view, mistral is positioned as fully controlled state machine | 08:19 |
| rakhmerov | akovi: if we decide to add it, it will be echoing everywhere | 08:19 |
| vgvoleg | and in our state machine only success state is terminal | 08:19 |
| rakhmerov | vgvoleg: how is this important? I don't understand. | 08:20 |
| vgvoleg | so we can't really "forget" about failed executions - they could be rerunned, skipped or something more that we create in the future | 08:20 |
| vgvoleg | and we should keep them in mind | 08:20 |
| rakhmerov | keep track of them on the client side | 08:20 |
| rakhmerov | may be we you can just add some info into the execution description | 08:21 |
| rakhmerov | as an option | 08:21 |
| rakhmerov | just to mark it somehow | 08:22 |
| vgvoleg | every mistral user should create an additional logic to handle this "nearly terminal" error | 08:22 |
| rakhmerov | "NOTE: it can't be rerun!" | 08:22 |
| vgvoleg | please don't bind it to rerun only Renat | 08:22 |
| rakhmerov | vgvoleg: you're the first one who's raising it ) | 08:22 |
| vgvoleg | There could be a lot of different functionality | 08:22 |
| *** d0ugal has quit IRC | 08:23 | |
| rakhmerov | vgvoleg: would it be an option just to change a description? | 08:23 |
| rakhmerov | there's such field | 08:23 |
| rakhmerov | it's an arbitrary text field | 08:23 |
| rakhmerov | you can put there anything you need | 08:23 |
| *** d0ugal has joined #openstack-mistral | 08:23 | |
| rakhmerov | any kind of interpretation of the state | 08:23 |
| vgvoleg | And I see our inability to "forget" error execution the same way as we "forget" success | 08:24 |
| vgvoleg | is a gap | 08:24 |
| rakhmerov | I guess now we can't change the description at any time but we can allow this easily in the REST controller | 08:24 |
| vgvoleg | description? what to you mean? | 08:24 |
| rakhmerov | when you fetch an execution via REST | 08:24 |
| rakhmerov | you get "description" among other execution fields | 08:25 |
| rakhmerov | it's an arbitrary text | 08:25 |
| rakhmerov | we can allow to change it via PUT /v2/executions/<id> | 08:25 |
| rakhmerov | another strong argument against this new state is the following... | 08:26 |
| rakhmerov | Imagine a human (say some operator) makes a decision to put a workflow in this ERROR_TERMINAL | 08:26 |
| rakhmerov | so he/she does that.. | 08:26 |
| rakhmerov | the next day a different person (say his/her boss) looks at this workflow and says "Oohh, you made a mistake! We can actually rerun it" | 08:27 |
| rakhmerov | what are you going to do? ) | 08:27 |
| vgvoleg | you mix our responsibility and client responsibility | 08:27 |
| rakhmerov | allow to change it back to ERROR? Then it's not terminal in any way | 08:27 |
| rakhmerov | what do you call "our" and "client" | 08:28 |
| rakhmerov | ? | 08:28 |
| vgvoleg | provide an ability to make failed execution read-only is our responsibility | 08:28 |
| rakhmerov | I'm operating here with Mistral and some client | 08:28 |
| vgvoleg | and your strong argument is client responsibility | 08:28 |
| rakhmerov | and a human | 08:28 |
| rakhmerov | vgvoleg: no | 08:29 |
| rakhmerov | I'm talking about the "fakeness" of this approach | 08:29 |
| rakhmerov | because since a human makes this decision he may want to change it | 08:29 |
| rakhmerov | just like to make a decision to rerun anything | 08:29 |
| rakhmerov | something | 08:29 |
| rakhmerov | I'm saying that semantically it doesn't have any differences from the regular ERROR state | 08:30 |
| rakhmerov | you may want to change both | 08:30 |
| vgvoleg | is there anyone else? | 08:30 |
| vgvoleg | we are stucked with this | 08:31 |
| rakhmerov | vgvoleg: we need to distinguish clearly between automaticly processed executions and operations initiated by the client | 08:31 |
| rakhmerov | from the 1st thing's perspective ERROR is 100% terminal | 08:32 |
| rakhmerov | it's a finite state machine, no doubts | 08:32 |
| rakhmerov | but then there's a reality: users sometimes want to do some additional processing on some workflows despite they are in terminal state | 08:32 |
| vgvoleg | my idea - the only "truly terminal" state is SUCCESS, and our clients should always keep in mind that ERROR is not so terminal, so I suggest to make an extension with some additional state/attribute to make ERROR terminal by human | 08:33 |
| rakhmerov | btw, we're not considering SUCCESS here just because it is trivial: there's nothing more to want from it, it's supposed to do what's needed | 08:33 |
| vgvoleg | that's all | 08:33 |
| rakhmerov | but we could have let users change even SUCCESS state in some cases | 08:33 |
| rakhmerov | Oleg, no | 08:33 |
| rakhmerov | I just explain about SUCCESS | 08:34 |
| rakhmerov | it's a coincidence | 08:34 |
| rakhmerov | vgvoleg: just use the "description" field | 08:34 |
| rakhmerov | it's more than enough to keep any information that you need | 08:34 |
| vgvoleg | rakhmerov: what if we see that success execution didn't make it's work, so we decide to move is to ERROR? \O/ \O/ \O/ | 08:34 |
| rakhmerov | vgvoleg: we could allow that, yes | 08:35 |
| rakhmerov | probably | 08:35 |
| vgvoleg | OMG we don't have any attribute that marks execution's state as terminal or not | 08:35 |
| rakhmerov | although it's probably pointless because it would mean that the workflow is not designed properly | 08:35 |
| vgvoleg | even success now is terminal only because there is no operations we can do | 08:36 |
| rakhmerov | vgvoleg: put the mark "Truly terminal" into the description :) | 08:36 |
| rakhmerov | vgvoleg: nobody cares if something is terminal or not (and again, in what sense? I just explained about terminality) | 08:37 |
| rakhmerov | it's more important that the user understand what states the workflow can be at when it's given to the automatic processing | 08:37 |
| rakhmerov | so all the transitions | 08:37 |
| vgvoleg | do you sure that nobody cares if something is read-only or not? | 08:37 |
| rakhmerov | once it reaches either SUCCESS or ERROR, it's now turn of the user to do something about it | 08:37 |
| rakhmerov | vgvoleg: yes, quite sure | 08:38 |
| rakhmerov | it's easy to implement on the client side | 08:38 |
| vgvoleg | why do programming languages have immutable types? | 08:38 |
| rakhmerov | we can't push absolutely anything into the project, for every specific use case | 08:38 |
| vgvoleg | what's the problem? | 08:38 |
| vgvoleg | human can keep in mind what is changed | 08:39 |
| vgvoleg | and handle it | 08:39 |
| vgvoleg | why there are these limitations? | 08:39 |
| rakhmerov | I explained what the problem is | 08:39 |
| rakhmerov | we can't push it | 08:39 |
| rakhmerov | it's easy to do w/o changing anything | 08:40 |
| rakhmerov | on the client side | 08:40 |
| rakhmerov | it's what I would call "a client-specific interpretation of the state" | 08:40 |
| rakhmerov | not more | 08:40 |
| rakhmerov | or you can use an execution description if that doesn't work for you | 08:40 |
| rakhmerov | Oleg, we are spending too much time on it. I heard all the arguments and my answer is "no", I won't let it it | 08:41 |
| rakhmerov | in | 08:41 |
| vgvoleg | okay | 08:41 |
| rakhmerov | sorry | 08:41 |
| vgvoleg | np | 08:41 |
| vgvoleg | it would be great to listen to someone else | 08:42 |
| vgvoleg | that's why I emphasize it today | 08:42 |
| rakhmerov | ok | 08:43 |
| rakhmerov | no problem, we can discuss it again with a larger group of people, if needed | 08:43 |
| vgvoleg | I'll write a mail | 08:43 |
| rakhmerov | ok | 08:44 |
| vgvoleg | sorry for spent time | 08:44 |
| rakhmerov | that's ok | 08:44 |
| rakhmerov | I know you want it very much ) | 08:44 |
| rakhmerov | but try to put yourself in my shoes | 08:44 |
| vgvoleg | it's not like I want something | 08:44 |
| rakhmerov | there's been A LOT of people who proposed all kind of stuff to lang in Mistral | 08:44 |
| vgvoleg | I feel that there is a gap in our state machine and would like to fix it | 08:45 |
| rakhmerov | and in many-many cases it's hard to explain that it's not aligned with the project vision | 08:45 |
| vgvoleg | the main difference between mistral and python script is state machine | 08:45 |
| vgvoleg | that's why I think it is important | 08:45 |
| rakhmerov | If I let all that stuff in we'll get a pain of thrash very soon | 08:45 |
| rakhmerov | Oleg, I explained it, we need to distinguish between different phases: automatic processing (it's a 100% finite state machine) and human interaction | 08:47 |
| vgvoleg | that's all | 08:47 |
| rakhmerov | ok, let's finish it for now | 08:47 |
| vgvoleg | I understand you | 08:47 |
| vgvoleg | thank you | 08:47 |
| rakhmerov | np | 08:47 |
| rakhmerov | #endmeeting | 08:47 |
| *** openstack changes topic to "Mistral the Workflow Service for OpenStack. https://docs.openstack.org/mistral/latest/" | 08:47 | |
| openstack | Meeting ended Wed Sep 18 08:47:42 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 08:47 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/mistral/2019/mistral.2019-09-18-08.04.html | 08:47 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/mistral/2019/mistral.2019-09-18-08.04.txt | 08:47 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/mistral/2019/mistral.2019-09-18-08.04.log.html | 08:47 |
| rakhmerov | vgvoleg: just checked, you can change an execution description via PUT /v2/executions/<id> | 08:49 |
| rakhmerov | it's already allowed | 08:49 |
| openstackgerrit | Artem Lapin proposed openstack/mistral master: New alembic migration to support namespaces in postgresql https://review.opendev.org/675361 | 08:51 |
| *** d0ugal has quit IRC | 09:54 | |
| *** pgaxatte has quit IRC | 10:03 | |
| *** openstackgerrit has quit IRC | 10:06 | |
| *** d0ugal has joined #openstack-mistral | 10:10 | |
| *** vgvoleg has quit IRC | 10:14 | |
| *** pgaxatte has joined #openstack-mistral | 10:14 | |
| *** pgaxatte has quit IRC | 10:30 | |
| *** pgaxatte has joined #openstack-mistral | 12:03 | |
| *** openstackgerrit has joined #openstack-mistral | 13:08 | |
| openstackgerrit | Merged openstack/mistral master: Use v2 designate client instead of v1 https://review.opendev.org/682785 | 13:08 |
| *** ricolin_ has joined #openstack-mistral | 13:08 | |
| *** akovi has quit IRC | 13:11 | |
| *** ricolin has quit IRC | 13:11 | |
| *** ricolin_ is now known as ricolin | 13:12 | |
| *** zhubx has quit IRC | 14:16 | |
| *** zhubx has joined #openstack-mistral | 14:17 | |
| *** eyalb1 has quit IRC | 14:18 | |
| *** openstackgerrit has quit IRC | 14:21 | |
| *** pgaxatte has quit IRC | 14:27 | |
| *** gkadam has joined #openstack-mistral | 14:54 | |
| *** gkadam_ has joined #openstack-mistral | 14:55 | |
| *** gkadam has quit IRC | 14:56 | |
| *** gkadam_ has quit IRC | 15:04 | |
| *** openstackgerrit has joined #openstack-mistral | 16:01 | |
| openstackgerrit | Bo Tran proposed openstack/mistral-dashboard master: Fix error when use keystone federation https://review.opendev.org/682940 | 16:01 |
| *** mgariepy has quit IRC | 17:16 | |
| *** mgariepy has joined #openstack-mistral | 17:22 | |
| *** ricolin has quit IRC | 17:27 | |
| *** jtomasek has quit IRC | 17:43 | |
| *** mmethot_ has joined #openstack-mistral | 17:57 | |
| *** mmethot_ has quit IRC | 17:58 | |
| *** mmethot_ has joined #openstack-mistral | 17:59 | |
| *** mmethot has quit IRC | 18:00 | |
| *** mmethot_ has quit IRC | 18:06 | |
| *** mmethot has joined #openstack-mistral | 18:08 | |
| *** mmethot has quit IRC | 18:11 | |
| *** zhubx has quit IRC | 18:15 | |
| *** boxiang has joined #openstack-mistral | 18:15 | |
| *** mmethot has joined #openstack-mistral | 18:16 | |
| *** openstackgerrit has quit IRC | 18:37 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!