08:04:02 <rakhmerov> #startmeeting Mistral
08:04:03 <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:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:04:07 <openstack> The meeting name has been set to 'mistral'
08:04:10 <rakhmerov> so hi :)
08:04:13 <rakhmerov> vgvoleg: go ahead
08:04:14 <vgvoleg> hellllllo
08:04:29 <vgvoleg> I'm again with non-terminal error... :D
08:04:54 <vgvoleg> We want to have an ability to cancel executions in error state
08:04:59 <rakhmerov> 🤟
08:05:13 <rakhmerov> vgvoleg: why do you want it? )
08:05:46 <rakhmerov> akovi: Andras, btw, can you take a look please at https://review.opendev.org/#/c/682785/ ?
08:05:48 <vgvoleg> so it is probably a good compromise to make execution in error state in something terminal
08:06:02 <akovi> rakhmerov: done
08:06:11 <rakhmerov> akovi: the tests now are OK but I have doubts if initialization of the client is right
08:06:27 <rakhmerov> I'm not too good at all these keystone related stuff
08:06:58 <akovi> as long as it accepts session, it should be ok
08:07:50 <rakhmerov> yes, that was my thinking too
08:08:03 <rakhmerov> 🤦‍♀️
08:08:07 <rakhmerov> vgvoleg: ^
08:08:09 <rakhmerov> :))
08:08:34 <vgvoleg> '=(
08:08:43 <rakhmerov> vgvoleg: why do you keep talking so desperately about terminal states? :)
08:09:11 <vgvoleg> Because we need to make executions in error state read-only
08:09:46 <rakhmerov> only read them when they are in ERROR state :)
08:09:47 <vgvoleg> I really can't understand why do you think it is not a gap
08:10:17 <rakhmerov> I'm failing to understand that this is a gap
08:10:37 <vgvoleg> so the alternative is to let us transfer ERROR to CANCELLED
08:10:42 <rakhmerov> Oleg
08:10:50 <rakhmerov> I'll raise my point again
08:11:16 <rakhmerov> we have some functionality that automatically moves a workflow execution to ERROR
08:11:21 <rakhmerov> (in some cases)
08:11:58 <rakhmerov> then a client makes a conscious decision (this is important!) to rerun the workflow
08:12:17 <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:20 <rakhmerov> and the client knows what workflow it decided to rerun
08:12:23 <rakhmerov> wait a sec..
08:12:59 <rakhmerov> and what is the problem for this client to keep track of what workflows can and can't be rerun anymore?
08:13:07 <rakhmerov> it's completely the responsibility of the client
08:13:26 <vgvoleg> because there could be many clients
08:14:13 <rakhmerov> ok, what is the formal criteria on how we decide if a workflow can be rerun or not?
08:14:16 <vgvoleg> it's really a headache
08:14:33 <vgvoleg> this criteria is error state
08:14:37 <rakhmerov> no
08:14:43 <rakhmerov> I mean something different
08:14:59 <rakhmerov> for example, we added this truly terminal ERROR state
08:15:09 <vgvoleg> ok
08:15:27 <rakhmerov> what will be the semantical difference between it and the rerunable ERROR state?
08:16:07 <rakhmerov> how do you reply a question: how do we decide what can be rerun or not?
08:16:18 <rakhmerov> based on what?
08:16:21 <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:45 <vgvoleg> so we can take it manually to read-only
08:16:46 <rakhmerov> who agrees?
08:16:48 <rakhmerov> a human?
08:16:51 <vgvoleg> yes
08:17:01 <rakhmerov> aah...
08:17:13 <rakhmerov> just do it on the client side, that's it
08:17:23 <akovi> my feeling is that you are kind of trying to integrate a higher level abstract state into the current state model
08:17:27 <rakhmerov> if you have many clients they can exchange this info
08:17:34 <rakhmerov> via DB, MQ, no matter what..
08:17:50 <rakhmerov> akovi: yes, exactly
08:18:38 <akovi> the "granite ERROR" will be set only from clients or will we need to extend the language too?
08:18:47 <rakhmerov> it's not consistent with the set (you can treat in a mathematical sense) of states that currently exist
08:19:17 <vgvoleg> In my point of view, mistral is positioned as fully controlled state machine
08:19:25 <rakhmerov> akovi: if we decide to add it, it will be echoing everywhere
08:19:41 <vgvoleg> and in our state machine only success state is terminal
08:20:34 <rakhmerov> vgvoleg: how is this important? I don't understand.
08:20:41 <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:55 <vgvoleg> and we should keep them in mind
08:20:55 <rakhmerov> keep track of them on the client side
08:21:55 <rakhmerov> may be we you can just add some info into the execution description
08:21:58 <rakhmerov> as an option
08:22:03 <rakhmerov> just to mark it somehow
08:22:06 <vgvoleg> every mistral user should create an additional logic to handle this "nearly terminal" error
08:22:12 <rakhmerov> "NOTE: it can't be rerun!"
08:22:25 <vgvoleg> please don't bind it to rerun only Renat
08:22:34 <rakhmerov> vgvoleg: you're the first one who's raising it )
08:22:42 <vgvoleg> There could be a lot of different functionality
08:23:22 <rakhmerov> vgvoleg: would it be an option just to change a description?
08:23:27 <rakhmerov> there's such field
08:23:37 <rakhmerov> it's an arbitrary text field
08:23:45 <rakhmerov> you can put there anything you need
08:23:59 <rakhmerov> any kind of interpretation of the state
08:24:12 <vgvoleg> And I see our inability to "forget" error execution the same way as we "forget" success
08:24:17 <vgvoleg> is a gap
08:24:28 <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:30 <vgvoleg> description? what to you mean?
08:24:47 <rakhmerov> when you fetch an execution via REST
08:25:00 <rakhmerov> you get "description" among other execution fields
08:25:11 <rakhmerov> it's an arbitrary text
08:25:46 <rakhmerov> we can allow to change it via PUT /v2/executions/<id>
08:26:28 <rakhmerov> another strong argument against this new state is the following...
08:26:50 <rakhmerov> Imagine a human (say some operator) makes a decision to put a workflow in this ERROR_TERMINAL
08:26:59 <rakhmerov> so he/she does that..
08:27:31 <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:40 <rakhmerov> what are you going to do? )
08:27:54 <vgvoleg> you mix our responsibility and client responsibility
08:27:59 <rakhmerov> allow to change it back to ERROR? Then it's not terminal in any way
08:28:14 <rakhmerov> what do you call "our" and "client"
08:28:14 <rakhmerov> ?
08:28:29 <vgvoleg> provide an ability to make failed execution read-only is our responsibility
08:28:52 <rakhmerov> I'm operating here with Mistral and some client
08:28:54 <vgvoleg> and your strong argument is client responsibility
08:28:58 <rakhmerov> and a human
08:29:11 <rakhmerov> vgvoleg: no
08:29:28 <rakhmerov> I'm talking about the "fakeness" of this approach
08:29:42 <rakhmerov> because since a human makes this decision he may want to change it
08:29:52 <rakhmerov> just like to make a decision to rerun anything
08:29:55 <rakhmerov> something
08:30:27 <rakhmerov> I'm saying that semantically it doesn't have any differences from the regular ERROR state
08:30:38 <rakhmerov> you may want to change both
08:30:42 <vgvoleg> is there anyone else?
08:31:00 <vgvoleg> we are stucked with this
08:31:43 <rakhmerov> vgvoleg: we need to distinguish clearly between automaticly processed executions and operations initiated by the client
08:32:07 <rakhmerov> from the 1st thing's perspective ERROR is 100% terminal
08:32:17 <rakhmerov> it's a finite state machine, no doubts
08:32:53 <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:33:30 <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: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:33 <vgvoleg> that's all
08:33:49 <rakhmerov> but we could have let users change even SUCCESS state in some cases
08:33:58 <rakhmerov> Oleg, no
08:34:03 <rakhmerov> I just explain about SUCCESS
08:34:08 <rakhmerov> it's a coincidence
08:34:30 <rakhmerov> vgvoleg: just use the "description" field
08:34:42 <rakhmerov> it's more than enough to keep any information that you need
08:34:58 <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:35:16 <rakhmerov> vgvoleg: we could allow that, yes
08:35:26 <rakhmerov> probably
08:35:49 <vgvoleg> OMG we don't have any attribute that marks execution's state as terminal or not
08:35:54 <rakhmerov> although it's probably pointless because it would mean that the workflow is not designed properly
08:36:16 <vgvoleg> even success now is terminal only because there is no operations we can do
08:36:19 <rakhmerov> vgvoleg: put the mark "Truly terminal" into the description :)
08:37:01 <rakhmerov> vgvoleg: nobody cares if something is terminal or not (and again, in what sense? I just explained about terminality)
08:37:28 <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:34 <rakhmerov> so all the transitions
08:37:39 <vgvoleg> do you sure that nobody cares if something is read-only or not?
08:37:58 <rakhmerov> once it reaches either SUCCESS or ERROR, it's now turn of the user to do something about it
08:38:15 <rakhmerov> vgvoleg: yes, quite sure
08:38:28 <rakhmerov> it's easy to implement on the client side
08:38:45 <vgvoleg> why do programming languages have immutable types?
08:38:52 <rakhmerov> we can't push absolutely anything into the project, for every specific use case
08:38:52 <vgvoleg> what's the problem?
08:39:04 <vgvoleg> human can keep in mind what is changed
08:39:09 <vgvoleg> and handle it
08:39:30 <vgvoleg> why there are these limitations?
08:39:35 <rakhmerov> I explained what the problem is
08:39:52 <rakhmerov> we can't push it
08:40:11 <rakhmerov> it's easy to do w/o changing anything
08:40:14 <rakhmerov> on the client side
08:40:38 <rakhmerov> it's what I would call "a client-specific interpretation of the state"
08:40:40 <rakhmerov> not more
08:40:54 <rakhmerov> or you can use an execution description if that doesn't work for you
08:41:22 <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:30 <rakhmerov> in
08:41:39 <vgvoleg> okay
08:41:43 <rakhmerov> sorry
08:41:54 <vgvoleg> np
08:42:18 <vgvoleg> it would be great to listen to someone else
08:42:53 <vgvoleg> that's why I emphasize it today
08:43:12 <rakhmerov> ok
08:43:28 <rakhmerov> no problem, we can discuss it again with a larger group of people, if needed
08:43:48 <vgvoleg> I'll write a mail
08:44:02 <rakhmerov> ok
08:44:08 <vgvoleg> sorry for spent time
08:44:13 <rakhmerov> that's ok
08:44:20 <rakhmerov> I know you want it very much )
08:44:32 <rakhmerov> but try to put yourself in my shoes
08:44:50 <vgvoleg> it's not like I want something
08:44:57 <rakhmerov> there's been A LOT of people who proposed all kind of stuff to lang in Mistral
08:45:10 <vgvoleg> I feel that there is a gap in our state machine and would like to fix it
08:45:28 <rakhmerov> and in many-many cases it's hard to explain that it's not aligned with the project vision
08:45:43 <vgvoleg> the main difference between mistral and python script is state machine
08:45:52 <vgvoleg> that's why I think it is important
08:45:52 <rakhmerov> If I let all that stuff in we'll get a pain of thrash very soon
08:47:09 <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:13 <vgvoleg> that's all
08:47:17 <rakhmerov> ok, let's finish it for now
08:47:20 <vgvoleg> I understand you
08:47:24 <vgvoleg> thank you
08:47:28 <rakhmerov> np
08:47:42 <rakhmerov> #endmeeting