Wednesday, 2019-09-18

*** apetrich has quit IRC02:10
zhubxrakhmerov: ok, I will try to confirm it whether can fix my issue thanks :)03:11
zhubxhello rakhmerov03:14
zhubxI read the issue https://bugs.launchpad.net/mistral/+bug/179682003:14
openstackLaunchpad 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
zhubxand the patch https://review.opendev.org/#/c/594187/03:14
zhubxbut I found that it is not the issue I met03:15
zhubxBut from the launchpad I found the same issue I met03:15
zhubxThe link is https://bugs.launchpad.net/mistral/+bug/172150803:15
openstackLaunchpad bug 1721508 in Mistral "Cannot create cron-trigger using trust-scoped token" [High,Confirmed]03:16
zhubxBut noone has fixed it03:16
zhubxrakhmerov ^03:16
zhubxthanks03:16
openstackgerritRenat Akhmerov proposed openstack/mistral master: Optimize creation of language specs  https://review.opendev.org/68202403:24
rakhmerovzhubx: hi03:30
rakhmerovso should I restore this ticket?03:32
rakhmerovzhubx: ^03:32
zhubxyes03:51
zhubxhttps://bugs.launchpad.net/mistral/+bug/1721508 this ticket03:51
openstackLaunchpad bug 1721508 in Mistral "Cannot create cron-trigger using trust-scoped token" [High,Confirmed]03:51
*** ricolin has joined #openstack-mistral03:54
rakhmerovzhubx: ok, thanks03:54
rakhmerovzhubx: hey, by the way, do you use happen to use openstack actions with Mistral?03:54
rakhmerovwe now have one failing test in CI03:55
rakhmerovseems like something has changed and we need to create a client for some libs in a different way now03:55
rakhmerove.g. designate03:55
zhubxyes, I use openstack actions with mistral03:56
rakhmerovok03:56
rakhmerovso if you have some time may be you could help with this issue03:57
zhubxok but sorry, now I have few time to fix this issue :(03:58
rakhmerovthat's ok03:58
openstackgerritRenat Akhmerov proposed openstack/mistral master: Use v2 designate client instead of v1  https://review.opendev.org/68278504:19
openstackgerritRenat Akhmerov proposed openstack/mistral master: Use v2 designate client instead of v1  https://review.opendev.org/68278504:35
*** eyalb has joined #openstack-mistral05:09
*** jtomasek has joined #openstack-mistral05:13
openstackgerritRenat Akhmerov proposed openstack/mistral master: Use v2 designate client instead of v1  https://review.opendev.org/68278505:18
*** pgaxatte has joined #openstack-mistral06:13
*** eyalb1 has joined #openstack-mistral06:27
*** eyalb has quit IRC06:30
*** eyalb has joined #openstack-mistral06:48
*** eyalb1 has quit IRC06:50
*** eyalb1 has joined #openstack-mistral06:59
*** apetrich has joined #openstack-mistral06:59
*** eyalb has quit IRC07:01
openstackgerritRenat Akhmerov proposed openstack/mistral master: Use v2 designate client instead of v1  https://review.opendev.org/68278507:46
*** akovi has joined #openstack-mistral07:54
*** vgvoleg has joined #openstack-mistral07:54
rakhmerovhi08:02
rakhmerovanybody wants to discuss anything?08:02
vgvoleghi!08:03
vgvolegone question08:03
akovihi08:03
akoviwe have a failing test08:03
rakhmerovakovi: fixing it08:03
rakhmerovhttps://review.opendev.org/68278508:03
rakhmerovhopefully it's going to work now08:03
rakhmerov#startmeeting Mistral08:04
openstackMeeting 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
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.08:04
*** openstack changes topic to " (Meeting topic: Mistral)"08:04
openstackThe meeting name has been set to 'mistral'08:04
rakhmerovso hi :)08:04
rakhmerovvgvoleg: go ahead08:04
vgvoleghellllllo08:04
vgvolegI'm again with non-terminal error... :D08:04
vgvolegWe want to have an ability to cancel executions in error state08:04
rakhmerov🤟08:04
rakhmerovvgvoleg: why do you want it? )08:05
rakhmerovakovi: Andras, btw, can you take a look please at https://review.opendev.org/#/c/682785/ ?08:05
vgvolegso it is probably a good compromise to make execution in error state in something terminal08:05
akovirakhmerov: done08:06
rakhmerovakovi: the tests now are OK but I have doubts if initialization of the client is right08:06
rakhmerovI'm not too good at all these keystone related stuff08:06
akovias long as it accepts session, it should be ok08:06
rakhmerovyes, that was my thinking too08:07
rakhmerov🤦‍♀️08:08
rakhmerovvgvoleg: ^08:08
rakhmerov:))08:08
vgvoleg'=(08:08
rakhmerovvgvoleg: why do you keep talking so desperately about terminal states? :)08:08
vgvolegBecause we need to make executions in error state read-only08:09
rakhmerovonly read them when they are in ERROR state :)08:09
vgvolegI really can't understand why do you think it is not a gap08:09
rakhmerovI'm failing to understand that this is a gap08:10
vgvolegso the alternative is to let us transfer ERROR to CANCELLED08:10
rakhmerovOleg08:10
rakhmerovI'll raise my point again08:10
rakhmerovwe have some functionality that automatically moves a workflow execution to ERROR08:11
rakhmerov(in some cases)08:11
rakhmerovthen a client makes a conscious decision (this is important!) to rerun the workflow08:11
vgvolegin the state machine there would be an arrow from ERROR to RUNNING, so the output state could be changed after some time08:12
rakhmerovand the client knows what workflow it decided to rerun08:12
rakhmerovwait a sec..08:12
rakhmerovand what is the problem for this client to keep track of what workflows can and can't be rerun anymore?08:12
rakhmerovit's completely the responsibility of the client08:13
vgvolegbecause there could be many clients08:13
rakhmerovok, what is the formal criteria on how we decide if a workflow can be rerun or not?08:14
vgvolegit's really a headache08:14
vgvolegthis criteria is error state08:14
rakhmerovno08:14
rakhmerovI mean something different08:14
rakhmerovfor example, we added this truly terminal ERROR state08:14
vgvolegok08:15
rakhmerovwhat will be the semantical difference between it and the rerunable ERROR state?08:15
rakhmerovhow do you reply a question: how do we decide what can be rerun or not?08:16
rakhmerovbased on what?08:16
vgvolegif we understand that this execution is failed and we agree with this and are not going to do anything about it08:16
vgvolegso we can take it manually to read-only08:16
rakhmerovwho agrees?08:16
rakhmerova human?08:16
vgvolegyes08:16
rakhmerovaah...08:17
rakhmerovjust do it on the client side, that's it08:17
akovimy feeling is that you are kind of trying to integrate a higher level abstract state into the current state model08:17
rakhmerovif you have many clients they can exchange this info08:17
rakhmerovvia DB, MQ, no matter what..08:17
rakhmerovakovi: yes, exactly08:17
akovithe "granite ERROR" will be set only from clients or will we need to extend the language too?08:18
rakhmerovit's not consistent with the set (you can treat in a mathematical sense) of states that currently exist08:18
vgvolegIn my point of view, mistral is positioned as fully controlled state machine08:19
rakhmerovakovi: if we decide to add it, it will be echoing everywhere08:19
vgvolegand in our state machine only success state is terminal08:19
rakhmerovvgvoleg: how is this important? I don't understand.08:20
vgvolegso we can't really "forget" about failed executions - they could be rerunned, skipped or something more that we create in the future08:20
vgvolegand we should keep them in mind08:20
rakhmerovkeep track of them on the client side08:20
rakhmerovmay be we you can just add some info into the execution description08:21
rakhmerovas an option08:21
rakhmerovjust to mark it somehow08:22
vgvolegevery mistral user should create an additional logic to handle this "nearly terminal" error08:22
rakhmerov"NOTE: it can't be rerun!"08:22
vgvolegplease don't bind it to rerun only Renat08:22
rakhmerovvgvoleg: you're the first one who's raising it )08:22
vgvolegThere could be a lot of different functionality08:22
*** d0ugal has quit IRC08:23
rakhmerovvgvoleg: would it be an option just to change a description?08:23
rakhmerovthere's such field08:23
rakhmerovit's an arbitrary text field08:23
rakhmerovyou can put there anything you need08:23
*** d0ugal has joined #openstack-mistral08:23
rakhmerovany kind of interpretation of the state08:23
vgvolegAnd I see our inability to "forget" error execution the same way as we "forget" success08:24
vgvolegis a gap08:24
rakhmerovI guess now we can't change the description at any time but we can allow this easily in the REST controller08:24
vgvolegdescription? what to you mean?08:24
rakhmerovwhen you fetch an execution via REST08:24
rakhmerovyou get "description" among other execution fields08:25
rakhmerovit's an arbitrary text08:25
rakhmerovwe can allow to change it via PUT /v2/executions/<id>08:25
rakhmerovanother strong argument against this new state is the following...08:26
rakhmerovImagine a human (say some operator) makes a decision to put a workflow in this ERROR_TERMINAL08:26
rakhmerovso he/she does that..08:26
rakhmerovthe 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
vgvolegyou mix our responsibility and client responsibility08:27
rakhmerovallow to change it back to ERROR? Then it's not terminal in any way08:27
rakhmerovwhat do you call "our" and "client"08:28
rakhmerov?08:28
vgvolegprovide an ability to make failed execution read-only is our responsibility08:28
rakhmerovI'm operating here with Mistral and some client08:28
vgvolegand your strong argument is client responsibility08:28
rakhmerovand a human08:28
rakhmerovvgvoleg: no08:29
rakhmerovI'm talking about the "fakeness" of this approach08:29
rakhmerovbecause since a human makes this decision he may want to change it08:29
rakhmerovjust like to make a decision to rerun anything08:29
rakhmerovsomething08:29
rakhmerovI'm saying that semantically it doesn't have any differences from the regular ERROR state08:30
rakhmerovyou may want to change both08:30
vgvolegis there anyone else?08:30
vgvolegwe are stucked with this08:31
rakhmerovvgvoleg: we need to distinguish clearly between automaticly processed executions and operations initiated by the client08:31
rakhmerovfrom the 1st thing's perspective ERROR is 100% terminal08:32
rakhmerovit's a finite state machine, no doubts08:32
rakhmerovbut then there's a reality: users sometimes want to do some additional processing on some workflows despite they are in terminal state08:32
vgvolegmy 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 human08:33
rakhmerovbtw, 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 needed08:33
vgvolegthat's all08:33
rakhmerovbut we could have let users change even SUCCESS state in some cases08:33
rakhmerovOleg, no08:33
rakhmerovI just explain about SUCCESS08:34
rakhmerovit's a coincidence08:34
rakhmerovvgvoleg: just use the "description" field08:34
rakhmerovit's more than enough to keep any information that you need08:34
vgvolegrakhmerov: 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
rakhmerovvgvoleg: we could allow that, yes08:35
rakhmerovprobably08:35
vgvolegOMG we don't have any attribute that marks execution's state as terminal or not08:35
rakhmerovalthough it's probably pointless because it would mean that the workflow is not designed properly08:35
vgvolegeven success now is terminal only because there is no operations we can do08:36
rakhmerovvgvoleg: put the mark "Truly terminal" into the description :)08:36
rakhmerovvgvoleg: nobody cares if something is terminal or not (and again, in what sense? I just explained about terminality)08:37
rakhmerovit's more important that the user understand what states the workflow can be at when it's given to the automatic processing08:37
rakhmerovso all the transitions08:37
vgvolegdo you sure that nobody cares if something is read-only or not?08:37
rakhmerovonce it reaches either SUCCESS or ERROR, it's now turn of the user to do something about it08:37
rakhmerovvgvoleg: yes, quite sure08:38
rakhmerovit's easy to implement on the client side08:38
vgvolegwhy do programming languages have immutable types?08:38
rakhmerovwe can't push absolutely anything into the project, for every specific use case08:38
vgvolegwhat's the problem?08:38
vgvoleghuman can keep in mind what is changed08:39
vgvolegand handle it08:39
vgvolegwhy there are these limitations?08:39
rakhmerovI explained what the problem is08:39
rakhmerovwe can't push it08:39
rakhmerovit's easy to do w/o changing anything08:40
rakhmerovon the client side08:40
rakhmerovit's what I would call "a client-specific interpretation of the state"08:40
rakhmerovnot more08:40
rakhmerovor you can use an execution description if that doesn't work for you08:40
rakhmerovOleg, we are spending too much time on it. I heard all the arguments and my answer is "no", I won't let it it08:41
rakhmerovin08:41
vgvolegokay08:41
rakhmerovsorry08:41
vgvolegnp08:41
vgvolegit would be great to listen to someone else08:42
vgvolegthat's why I emphasize it today08:42
rakhmerovok08:43
rakhmerovno problem, we can discuss it again with a larger group of people, if needed08:43
vgvolegI'll write a mail08:43
rakhmerovok08:44
vgvolegsorry for spent time08:44
rakhmerovthat's ok08:44
rakhmerovI know you want it very much )08:44
rakhmerovbut try to put yourself in my shoes08:44
vgvolegit's not like I want something08:44
rakhmerovthere's been A LOT of people who proposed all kind of stuff to lang in Mistral08:44
vgvolegI feel that there is a gap in our state machine and would like to fix it08:45
rakhmerovand in many-many cases it's hard to explain that it's not aligned with the project vision08:45
vgvolegthe main difference between mistral and python script is state machine08:45
vgvolegthat's why I think it is important08:45
rakhmerovIf I let all that stuff in we'll get a pain of thrash very soon08:45
rakhmerovOleg, I explained it, we need to distinguish between different phases: automatic processing (it's a 100% finite state machine) and human interaction08:47
vgvolegthat's all08:47
rakhmerovok, let's finish it for now08:47
vgvolegI understand you08:47
vgvolegthank you08:47
rakhmerovnp08:47
rakhmerov#endmeeting08:47
*** openstack changes topic to "Mistral the Workflow Service for OpenStack. https://docs.openstack.org/mistral/latest/"08:47
openstackMeeting ended Wed Sep 18 08:47:42 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)08:47
openstackMinutes:        http://eavesdrop.openstack.org/meetings/mistral/2019/mistral.2019-09-18-08.04.html08:47
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/mistral/2019/mistral.2019-09-18-08.04.txt08:47
openstackLog:            http://eavesdrop.openstack.org/meetings/mistral/2019/mistral.2019-09-18-08.04.log.html08:47
rakhmerovvgvoleg: just checked, you can change an execution description via PUT /v2/executions/<id>08:49
rakhmerovit's already allowed08:49
openstackgerritArtem Lapin proposed openstack/mistral master: New alembic migration to support namespaces in postgresql  https://review.opendev.org/67536108:51
*** d0ugal has quit IRC09:54
*** pgaxatte has quit IRC10:03
*** openstackgerrit has quit IRC10:06
*** d0ugal has joined #openstack-mistral10:10
*** vgvoleg has quit IRC10:14
*** pgaxatte has joined #openstack-mistral10:14
*** pgaxatte has quit IRC10:30
*** pgaxatte has joined #openstack-mistral12:03
*** openstackgerrit has joined #openstack-mistral13:08
openstackgerritMerged openstack/mistral master: Use v2 designate client instead of v1  https://review.opendev.org/68278513:08
*** ricolin_ has joined #openstack-mistral13:08
*** akovi has quit IRC13:11
*** ricolin has quit IRC13:11
*** ricolin_ is now known as ricolin13:12
*** zhubx has quit IRC14:16
*** zhubx has joined #openstack-mistral14:17
*** eyalb1 has quit IRC14:18
*** openstackgerrit has quit IRC14:21
*** pgaxatte has quit IRC14:27
*** gkadam has joined #openstack-mistral14:54
*** gkadam_ has joined #openstack-mistral14:55
*** gkadam has quit IRC14:56
*** gkadam_ has quit IRC15:04
*** openstackgerrit has joined #openstack-mistral16:01
openstackgerritBo Tran proposed openstack/mistral-dashboard master: Fix error when use keystone federation  https://review.opendev.org/68294016:01
*** mgariepy has quit IRC17:16
*** mgariepy has joined #openstack-mistral17:22
*** ricolin has quit IRC17:27
*** jtomasek has quit IRC17:43
*** mmethot_ has joined #openstack-mistral17:57
*** mmethot_ has quit IRC17:58
*** mmethot_ has joined #openstack-mistral17:59
*** mmethot has quit IRC18:00
*** mmethot_ has quit IRC18:06
*** mmethot has joined #openstack-mistral18:08
*** mmethot has quit IRC18:11
*** zhubx has quit IRC18:15
*** boxiang has joined #openstack-mistral18:15
*** mmethot has joined #openstack-mistral18:16
*** openstackgerrit has quit IRC18:37

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!