| *** thorst_ has joined #openstack-watcher | 00:10 | |
| *** thorst_ has quit IRC | 00:12 | |
| *** thorst_ has joined #openstack-watcher | 01:19 | |
| *** thorst_ has quit IRC | 01:19 | |
| *** thorst_ has joined #openstack-watcher | 01:45 | |
| *** thorst_ has quit IRC | 01:45 | |
| *** thorst_ has joined #openstack-watcher | 02:19 | |
| *** thorst_ has quit IRC | 02:19 | |
| *** thorst_ has joined #openstack-watcher | 03:20 | |
| *** thorst_ has quit IRC | 03:25 | |
| *** openstackgerrit has joined #openstack-watcher | 03:37 | |
| openstackgerrit | licanwei proposed openstack/watcher-specs master: Support Description For Dynamic Action https://review.openstack.org/401111 | 03:37 |
|---|---|---|
| openstackgerrit | licanwei proposed openstack/watcher master: Add SUPERSEDED description https://review.openstack.org/432835 | 03:53 |
| *** thorst_ has joined #openstack-watcher | 04:21 | |
| *** thorst_ has quit IRC | 04:26 | |
| *** openstackgerrit has quit IRC | 04:32 | |
| *** adisky_ has joined #openstack-watcher | 05:00 | |
| *** diga has joined #openstack-watcher | 05:58 | |
| *** openstackgerrit has joined #openstack-watcher | 06:17 | |
| openstackgerrit | aditi sharma proposed openstack/watcher-specs master: specs for blueprint stop action plan https://review.openstack.org/432264 | 06:17 |
| *** thorst_ has joined #openstack-watcher | 06:22 | |
| *** thorst_ has quit IRC | 06:26 | |
| openstackgerrit | licanwei proposed openstack/watcher-specs master: Define when an action plan is stale/invalid https://review.openstack.org/432193 | 06:58 |
| *** alexchadin has joined #openstack-watcher | 07:51 | |
| *** vincentfrancoise has joined #openstack-watcher | 08:21 | |
| *** thorst_ has joined #openstack-watcher | 08:22 | |
| *** thorst_ has quit IRC | 08:27 | |
| adisky_ | vincentfrancoise: hii | 08:56 |
| vincentfrancoise | adisky_: hi | 08:56 |
| vincentfrancoise | adisky_: I'll be back in half an hour | 08:57 |
| adisky_ | vincentfrancoise: ok | 08:57 |
| *** acabot has joined #openstack-watcher | 09:16 | |
| vincentfrancoise | adisky_: I'm back | 09:16 |
| vincentfrancoise | adisky_: just going back to your comment about the action plan's state machine | 09:18 |
| adisky_ | vincentfrancoise: u there?? | 10:06 |
| vincentfrancoise | adisky_: yep | 10:06 |
| adisky_ | this is about the pending_stop state | 10:07 |
| adisky_ | so you want to say, we should update "STOPPING" to api level only?? | 10:07 |
| vincentfrancoise | adisky_: or CANCELLING if we keep the current naming | 10:08 |
| adisky_ | vincentfrancoise: sorry | 10:08 |
| adisky_ | yes | 10:08 |
| vincentfrancoise | adisky_: not worries | 10:08 |
| adisky_ | ?? | 10:09 |
| vincentfrancoise | adisky_: yes, but this is a suggestion only | 10:09 |
| adisky_ | vincentfrancoise: if we do so, then where we update the status to "CANCELLED" after successfull completion of action plan | 10:09 |
| vincentfrancoise | adisky_: my objective is to make it as simple as possible because maintaining too many states can become really complicated | 10:09 |
| adisky_ | vincentfrancoise: i agreed with you too many states is complicated | 10:10 |
| vincentfrancoise | adisky_: exactly, CANCELLED would be the equivalent of you STOPPED state | 10:10 |
| adisky_ | vincentfrancoise: I am ok with CANCELLED | 10: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 applier | 10:12 |
| adisky_ | but problem is, where we will update the final status after action plan stop success?? | 10:12 |
| vincentfrancoise | adisky_: changing the namings might mean we break someone's script or plugin that was based on Watcher | 10:12 |
| adisky_ | vincentfrancoise: ok | 10:13 |
| adisky_ | vincentfrancoise: i think its better to call action plan cancel?? | 10:14 |
| vincentfrancoise | adisky_: probably yes | 10:14 |
| adisky_ | vincentfrancoise: ok i will rename the blueprint as well | 10:14 |
| adisky_ | pending_cancelled?? | 10:15 |
| vincentfrancoise | adisky_: for the pending_cancellation thing, that's why I told you that it's "passive" system | 10:15 |
| vincentfrancoise | adisky_: I may have not understand you | 10:15 |
| adisky_ | vincentfrancoise: same here | 10:15 |
| vincentfrancoise | adisky_: hence me asking for a diagram of the state machine for the action :p | 10:16 |
| adisky_ | do you want not to trigger any message to watcher-applier for action-plan cancel?? | 10:16 |
| vincentfrancoise | adisky_: the way I understand it is the following | 10:16 |
| vincentfrancoise | the operator uses the CLI to send: watcher actionplan cancel | 10:17 |
| vincentfrancoise | this cancel tries to update the action plan state to CANCELLING | 10:17 |
| adisky_ | ok | 10:17 |
| vincentfrancoise | 2- the Watcher applier/taskflow gets to execute a new task | 10:17 |
| vincentfrancoise | adisky_: it pulls the state of the action plan and detects that it is now in CANCELLING state | 10:18 |
| adisky_ | vincentfrancoise: correct | 10:18 |
| vincentfrancoise | so it then changes all subsequent actions of this action PLAN to CANCELLED and starts the revert procedure | 10:19 |
| vincentfrancoise | actually it waits for the revert procedure to finish before changing the action plan state to CANCELLED | 10:20 |
| adisky_ | ok, i thought of the follwing flow | 10:23 |
| adisky_ | https://www.irccloud.com/pastebin/abMRIlpd/ | 10:23 |
| *** thorst_ has joined #openstack-watcher | 10: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 |
| vincentfrancoise | adisky_: ok so the point we see differently is how we propagate the cancelling order to the applier | 10: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 |
| vincentfrancoise | adisky_: fair point :p | 10:28 |
| *** thorst_ has quit IRC | 10:28 | |
| adisky_ | vincent: although if you want to completely avoid pending_cancelled | 10: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 |
| vincentfrancoise | adisky_: IMHO, no need for an RPC call | 10:30 |
| vincentfrancoise | adisky_: the API receives the call and updates the DB | 10:31 |
| adisky_ | vincentfrancoise: and API will update cancelled also?? | 10:31 |
| vincentfrancoise | adisky_: then the task checks itself before starting which will trigger the revert process | 10:31 |
| vincentfrancoise | adisky_: no, that's the "fair point" answer I'm currently reflecting on :p | 10: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 |
| vincentfrancoise | adisky_: I know that workflow management can become a humongous beast so that's why I want to keep it very simple | 10:33 |
| adisky_ | vincentfrancoise: ok | 10:34 |
| adisky_ | vincentfrancoise: can i add uml diagrams to watcher-specs?? | 10:37 |
| vincentfrancoise | adisky_: of course you can | 10:37 |
| adisky_ | vincentfrancoise: ok | 10:37 |
| vincentfrancoise | adisky_: that's event better actually | 10:37 |
| vincentfrancoise | adisky_: we usually use plantuml digram just like in the main watcher doc | 10:38 |
| adisky_ | vincentfrancoise: ok | 10:38 |
| vincentfrancoise | adisky_: I'm doing some quick digging and if I find something good I'll come back to you | 10:42 |
| adisky_ | vincentfrancoise: thanks :) | 10:42 |
| vincentfrancoise | adisky_: according to this example http://docs.openstack.org/developer/taskflow/examples.html#making-phone-calls-automatically-reverting | 10:55 |
| vincentfrancoise | adisky_: when taskflow finishes to revert all tasks, it still goes into the Exception block | 10:55 |
| vincentfrancoise | adisky_: which means we can change its state to CANCELLED in the except block here: https://github.com/openstack/watcher/blob/master/watcher/applier/workflow_engine/default.py#L94-L95 | 10:57 |
| adisky_ | vincentfrancoise: yes this is the good idea :) | 10:58 |
| adisky_ | and it will save us from overheading of periodic check, which i thought | 10:59 |
| vincentfrancoise | adisky_: exactly | 10:59 |
| adisky_ | vincentfrancoise: I will test it, and update the specs accordingly. | 10:59 |
| vincentfrancoise | adisky_: but the issue I see coming is that we need to handle the resume of action plans as well to make it fully resilient | 11:00 |
| adisky_ | vincentfrancoise: resuming?? i think if we suspend the action plan then we need to resume | 11:01 |
| adisky_ | here we are cancelling it | 11:01 |
| vincentfrancoise | adisky_: ah yeah I mean resuming if the process is restarted | 11:02 |
| vincentfrancoise | adisky_: with the persistence of the workflow and so on | 11:02 |
| adisky_ | vincentfrancoise: i think it can be done, admin need to re launch the action plan | 11:02 |
| vincentfrancoise | adisky_: things to do in the future I mean | 11:02 |
| adisky_ | vincentfrancoise: there is a seperate blueprint for suspend | 11:03 |
| adisky_ | by hidekazu | 11:03 |
| vincentfrancoise | adisky_: not related to your BP in particular but that I keep in mind | 11:03 |
| adisky_ | vincentfrancoise: ok | 11:03 |
| vincentfrancoise | adisky_: hidekazu works on pause/resume and you on cancel/revert | 11:04 |
| adisky_ | vincentfrancoise: yes | 11:04 |
| adisky_ | :) | 11:04 |
| vincentfrancoise | adisky_: but my question is: what happens if the applier fails during the execution of an action plan | 11:05 |
| vincentfrancoise | adisky_: 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 |
| vincentfrancoise | adisky_: 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/resume | 11:07 |
| vincentfrancoise | adisky_: yeah it's a difficult matter but we need it if we want to achieve high availability and a good resilience | 11:07 |
| adisky_ | vincentfrancoise: I think, it is possible that we can complete the ongoing actions, and suspend only not started actions | 11:07 |
| vincentfrancoise | adisky_: if you want to have fun and write the BP for what we are discussing, feel free to do so BTW :D | 11:08 |
| adisky_ | and on resume the pending actions will start | 11:08 |
| adisky_ | it is difficult to implement suspend for ongoing actions.🤔 | 11:09 |
| vincentfrancoise | adisky_: yeah I guess that may work | 11:09 |
| adisky_ | vincentfrancoise: for suspend the blueprint is already there. | 11:10 |
| vincentfrancoise | adisky_: 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 task | 11: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 |
| vincentfrancoise | adisky_: anyhow, I'll review your spec once you update it with the suggestion I gave you ;) | 11:12 |
| adisky_ | vincentfrancoise: :) | 11:12 |
| vincentfrancoise | adisky_: yes but what about cinder or neutron that we will integrate at some point in the future | 11:13 |
| vincentfrancoise | adisky_: unless really necessary, let's keep it simple | 11:13 |
| vincentfrancoise | adisky_: or implement it in 2 steps | 11:13 |
| adisky_ | vincentfrancoise: I dont have any idea on neutron, but in cinder they can. | 11:13 |
| vincentfrancoise | adisky_: if these 2 can do it, then it should be ok to support it I guess | 11:14 |
| vincentfrancoise | adisky_: 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 IRC | 11:18 | |
| *** diga has quit IRC | 12:17 | |
| *** thorst_ has joined #openstack-watcher | 12:48 | |
| *** danpawlik has quit IRC | 14:04 | |
| *** jwcroppe has quit IRC | 14:13 | |
| *** jwcroppe has joined #openstack-watcher | 14:27 | |
| *** alexchadin has quit IRC | 14:29 | |
| *** danpawlik has joined #openstack-watcher | 14:32 | |
| *** openstackgerrit has joined #openstack-watcher | 14:48 | |
| openstackgerrit | Merged openstack/watcher-dashboard master: Updated from global requirements https://review.openstack.org/432124 | 14:48 |
| chrisspencer | o/ hi all | 15:25 |
| *** wootehfoot has joined #openstack-watcher | 18:09 | |
| *** adisky_ has quit IRC | 21:19 | |
| *** thorst_ has quit IRC | 22:03 | |
| *** thorst_ has joined #openstack-watcher | 22:33 | |
| *** thorst_ has quit IRC | 22:38 | |
| *** thorst_ has joined #openstack-watcher | 23:01 | |
| *** jwcroppe has quit IRC | 23:26 | |
| *** jwcroppe has joined #openstack-watcher | 23:27 | |
| *** edleafe has quit IRC | 23:30 | |
| *** edleafe has joined #openstack-watcher | 23:30 | |
| *** jwcroppe has quit IRC | 23:31 | |
| *** edleafe has quit IRC | 23:34 | |
| *** edleafe has joined #openstack-watcher | 23:37 | |
| *** edleafe has quit IRC | 23:37 | |
| *** edleafe has joined #openstack-watcher | 23:40 | |
| *** wootehfoot has quit IRC | 23:50 | |
| *** edleafe has quit IRC | 23:54 | |
| *** edleafe has joined #openstack-watcher | 23:56 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!