Monday, 2017-02-13

*** thorst_ has joined #openstack-watcher00:10
*** thorst_ has quit IRC00:12
*** thorst_ has joined #openstack-watcher01:19
*** thorst_ has quit IRC01:19
*** thorst_ has joined #openstack-watcher01:45
*** thorst_ has quit IRC01:45
*** thorst_ has joined #openstack-watcher02:19
*** thorst_ has quit IRC02:19
*** thorst_ has joined #openstack-watcher03:20
*** thorst_ has quit IRC03:25
*** openstackgerrit has joined #openstack-watcher03:37
openstackgerritlicanwei proposed openstack/watcher-specs master: Support Description For Dynamic Action
openstackgerritlicanwei proposed openstack/watcher master: Add SUPERSEDED description
*** thorst_ has joined #openstack-watcher04:21
*** thorst_ has quit IRC04:26
*** openstackgerrit has quit IRC04:32
*** adisky_ has joined #openstack-watcher05:00
*** diga has joined #openstack-watcher05:58
*** openstackgerrit has joined #openstack-watcher06:17
openstackgerritaditi sharma proposed openstack/watcher-specs master: specs for blueprint stop action plan
*** thorst_ has joined #openstack-watcher06:22
*** thorst_ has quit IRC06:26
openstackgerritlicanwei proposed openstack/watcher-specs master:     Define when an action plan is stale/invalid
*** alexchadin has joined #openstack-watcher07:51
*** vincentfrancoise has joined #openstack-watcher08:21
*** thorst_ has joined #openstack-watcher08:22
*** thorst_ has quit IRC08:27
adisky_vincentfrancoise: hii08:56
vincentfrancoiseadisky_: hi08:56
vincentfrancoiseadisky_: I'll be back in half an hour08:57
adisky_vincentfrancoise: ok08:57
*** acabot has joined #openstack-watcher09:16
vincentfrancoiseadisky_: I'm back09:16
vincentfrancoiseadisky_: just going back to your comment about the action plan's state machine09:18
adisky_vincentfrancoise: u there??10:06
vincentfrancoiseadisky_: yep10:06
adisky_this is about the pending_stop state10:07
adisky_so you want to say, we should update "STOPPING" to api level only??10:07
vincentfrancoiseadisky_: or CANCELLING if we keep the current naming10:08
adisky_vincentfrancoise: sorry10:08
vincentfrancoiseadisky_: not worries10:08
vincentfrancoiseadisky_: yes, but this is a suggestion only10:09
adisky_vincentfrancoise: if we do so, then where we update the status to "CANCELLED" after successfull completion of action plan10:09
vincentfrancoiseadisky_: my objective is to make it as simple as possible because maintaining too many states can become really complicated10:09
adisky_vincentfrancoise: i agreed with you too many states is complicated10:10
vincentfrancoiseadisky_: exactly, CANCELLED would be the equivalent of you STOPPED state10:10
adisky_vincentfrancoise: I am ok with CANCELLED10:11
adisky_but if we avoid pending_cancelled, then we will updated cancelling at watcher-api level only, and will not trigger any rpc message to watcher applier10:12
adisky_but problem is, where we will update the final status after action plan stop success??10:12
vincentfrancoiseadisky_: changing the namings might mean we break someone's script or plugin that was based on Watcher10:12
adisky_vincentfrancoise: ok10:13
adisky_vincentfrancoise: i think its better to call action plan cancel??10:14
vincentfrancoiseadisky_: probably yes10:14
adisky_vincentfrancoise: ok i will rename the blueprint as well10:14
vincentfrancoiseadisky_: for the pending_cancellation thing, that's why I told you that it's "passive" system10:15
vincentfrancoiseadisky_: I may have not understand you10:15
adisky_vincentfrancoise: same here10:15
vincentfrancoiseadisky_: hence me asking for a diagram of the state machine for the action :p10:16
adisky_do you want not to trigger any message to watcher-applier for action-plan cancel??10:16
vincentfrancoiseadisky_: the way I understand it is the following10:16
vincentfrancoisethe operator uses the CLI to send: watcher actionplan cancel10:17
vincentfrancoisethis cancel tries to update the action plan state to CANCELLING10:17
vincentfrancoise2- the Watcher applier/taskflow gets to execute a new task10:17
vincentfrancoiseadisky_: it pulls the state of the action plan and detects that it is now in CANCELLING state10:18
adisky_vincentfrancoise: correct10:18
vincentfrancoiseso it then changes all subsequent actions of this action PLAN to CANCELLED and starts the revert procedure10:19
vincentfrancoiseactually it waits for the revert procedure to finish before changing the action plan state to CANCELLED10:20
adisky_ok, i thought of the follwing flow10:23
*** thorst_ has joined #openstack-watcher10:23
adisky_but your way is good though, i just only dont know, how to change the state to "cancelled" after all succesfull reverts.10:24
vincentfrancoiseadisky_: ok so the point we see differently is how we propagate the cancelling order to the applier10:25
adisky_after finish of all revert procedure, do you any point from where we can take control and update the status to CANCELLED??10:26
vincentfrancoiseadisky_: fair point :p10:28
*** thorst_ has quit IRC10:28
adisky_vincent: although if you want to completely avoid pending_cancelled10:29
adisky_we can only do this, we will trigger the rpc message to watcher-applier but it will not update any status??10:30
vincentfrancoiseadisky_: IMHO, no need for an RPC call10:30
vincentfrancoiseadisky_: the API receives the call and updates the DB10:31
adisky_vincentfrancoise:  and API will update cancelled also??10:31
vincentfrancoiseadisky_: then the task checks itself before starting which will trigger the revert process10:31
vincentfrancoiseadisky_: no, that's the "fair point" answer I'm currently reflecting on :p10:32
adisky_vincentfrancoise: may i am not able to get what your saying, but i have only q. how to update to cancelled?? , the cancel operation i know can be triggered without rpc message.10:33
vincentfrancoiseadisky_: I know that workflow management can become a humongous beast so that's why I want to keep it very simple10:33
adisky_vincentfrancoise: ok10:34
adisky_vincentfrancoise: can i add uml diagrams to watcher-specs??10:37
vincentfrancoiseadisky_: of course you can10:37
adisky_vincentfrancoise: ok10:37
vincentfrancoiseadisky_: that's event better actually10:37
vincentfrancoiseadisky_: we usually use plantuml digram just like in the main watcher doc10:38
adisky_vincentfrancoise: ok10:38
vincentfrancoiseadisky_: I'm doing some quick digging and if I find something good I'll come back to you10:42
adisky_vincentfrancoise: thanks :)10:42
vincentfrancoiseadisky_: according to this example
vincentfrancoiseadisky_: when taskflow finishes to revert all tasks, it still goes into the Exception block10:55
vincentfrancoiseadisky_: which means we can change its state to CANCELLED in the except block here:
adisky_vincentfrancoise: yes this is the good idea :)10:58
adisky_and it will save us from overheading of periodic check, which i thought10:59
vincentfrancoiseadisky_: exactly10:59
adisky_vincentfrancoise:  I will test it, and update the specs accordingly.10:59
vincentfrancoiseadisky_: but the issue I see coming is that we need to handle the resume of action plans as well to make it fully resilient11:00
adisky_vincentfrancoise: resuming?? i think if we suspend the action plan then we need to resume11:01
adisky_here we are cancelling it11:01
vincentfrancoiseadisky_: ah yeah I mean resuming if the process is restarted11:02
vincentfrancoiseadisky_: with the persistence of the workflow and so on11:02
adisky_vincentfrancoise: i think it can be done, admin need to re launch the action plan11:02
vincentfrancoiseadisky_: things to do in the future I mean11:02
adisky_vincentfrancoise: there is a seperate blueprint for suspend11:03
adisky_by hidekazu11:03
vincentfrancoiseadisky_: not related to your BP in particular but that I keep in mind11:03
adisky_vincentfrancoise: ok11:03
vincentfrancoiseadisky_: hidekazu works on pause/resume and you on cancel/revert11:04
adisky_vincentfrancoise: yes11:04
vincentfrancoiseadisky_: but my question is: what happens if the applier fails during the execution of an action plan11:05
vincentfrancoiseadisky_: that that we have complex workflows at the applier level, how will we be able to resume them once we will get to persist them?11:05
vincentfrancoiseadisky_: just trying to figure out if what we do now will be re-usable for this next step ;)11:06
adisky_vincentfrancoise: yes it is difficult though, we need to save lot of things for suspend/resume11:07
vincentfrancoiseadisky_: yeah it's a difficult matter but we need it if we want to achieve high availability and a good resilience11:07
adisky_vincentfrancoise: I think, it is possible that we can complete the ongoing actions, and suspend only not started actions11:07
vincentfrancoiseadisky_: if you want to have fun and write the BP for what we are discussing, feel free to do so BTW :D11:08
adisky_and on resume the pending actions will start11:08
adisky_it is difficult to implement suspend for ongoing actions.🤔11:09
vincentfrancoiseadisky_: yeah I guess that may work11:09
adisky_vincentfrancoise: for suspend the blueprint is already there.11:10
vincentfrancoiseadisky_: we shouldn't do it too because we often delegate the actual task to the right service like nova so we do not fully own the execution of the task11:11
adisky_vincentfrancoise: yes, actually for action plan cancel i want to include ongoing actions as well, because NOVA exposes abort api directly.11:11
vincentfrancoiseadisky_: anyhow, I'll review your spec once you update it with the suggestion I gave you ;)11:12
adisky_vincentfrancoise: :)11:12
vincentfrancoiseadisky_: yes but what about cinder or neutron that we will integrate at some point in the future11:13
vincentfrancoiseadisky_: unless really necessary, let's keep it simple11:13
vincentfrancoiseadisky_: or implement it in 2 steps11:13
adisky_vincentfrancoise: I dont have any idea on neutron, but in cinder they can.11:13
vincentfrancoiseadisky_: if these 2 can do it, then it should be ok to support it I guess11:14
vincentfrancoiseadisky_: I'm off for lunch, see you later maybe ;)11:16
adisky_vincentfrancoise: ok i will dig on ONGOING part more. :)11:16
*** openstackgerrit has quit IRC11:18
*** diga has quit IRC12:17
*** thorst_ has joined #openstack-watcher12:48
*** danpawlik has quit IRC14:04
*** jwcroppe has quit IRC14:13
*** jwcroppe has joined #openstack-watcher14:27
*** alexchadin has quit IRC14:29
*** danpawlik has joined #openstack-watcher14:32
*** openstackgerrit has joined #openstack-watcher14:48
openstackgerritMerged openstack/watcher-dashboard master: Updated from global requirements
chrisspencero/ hi all15:25
*** wootehfoot has joined #openstack-watcher18:09
*** adisky_ has quit IRC21:19
*** thorst_ has quit IRC22:03
*** thorst_ has joined #openstack-watcher22:33
*** thorst_ has quit IRC22:38
*** thorst_ has joined #openstack-watcher23:01
*** jwcroppe has quit IRC23:26
*** jwcroppe has joined #openstack-watcher23:27
*** edleafe has quit IRC23:30
*** edleafe has joined #openstack-watcher23:30
*** jwcroppe has quit IRC23:31
*** edleafe has quit IRC23:34
*** edleafe has joined #openstack-watcher23:37
*** edleafe has quit IRC23:37
*** edleafe has joined #openstack-watcher23:40
*** wootehfoot has quit IRC23:50
*** edleafe has quit IRC23:54
*** edleafe has joined #openstack-watcher23:56

Generated by 2.14.0 by Marius Gedminas - find it at!