| *** WANG_Feng has quit IRC | 03:10 | |
| *** WANG_Feng has joined #openstack-smaug | 03:11 | |
| *** c00281451 has quit IRC | 03:50 | |
| *** c00281451 has joined #openstack-smaug | 03:51 | |
| *** yinweimac has joined #openstack-smaug | 08:29 | |
| *** yinweimac has quit IRC | 09:46 | |
| saggi | Hi all , I made a short document explaining how Smaug will build the dependency graph. | 11:37 |
|---|---|---|
| saggi | https://docs.google.com/document/d/1Mkd9RgUVdiRL6iei8Nqzzx4xteKIcd-yjMLEkV4Jc9s/edit?usp=sharing | 11:37 |
| *** yinweimac has joined #openstack-smaug | 12:03 | |
| yinweimac | saggi | 12:49 |
| yinweimac | there? | 12:49 |
| saggi | yinweimac: yes | 12:49 |
| saggi | how are you doing? | 12:49 |
| yinweimac | good, thanks | 12:49 |
| yinweimac | was thinking your words yesterday | 12:49 |
| saggi | which ones? | 12:49 |
| yinweimac | I'm thinking the walk function of ResourceGraphWalker should return a list of tasks or flows? | 12:50 |
| yinweimac | this is output of the graph walker, right? | 12:51 |
| saggi | No | 12:52 |
| saggi | The walker will just call the provider. The provider will call the plugin and get the task and build the task list. | 12:52 |
| saggi | The graph walker is just the mechanism | 12:53 |
| yinweimac | so you want to make the graph walker a generic one | 12:53 |
| saggi | Yes | 12:53 |
| saggi | We might need walking on the graph for other stuff | 12:53 |
| saggi | Seems like a decent assumption to me | 12:54 |
| yinweimac | hmm, so from where we can get the eventual task/flow set? | 12:55 |
| saggi | It will get queued by the provider. | 12:55 |
| yinweimac | the provider will keep this flow/task set per walk | 12:55 |
| yinweimac | ? | 12:55 |
| saggi | Per operation (protect\delete\etc) | 12:56 |
| yinweimac | So each call of walk(), we create a new instance of provider? | 12:56 |
| yinweimac | I mean, walk() should be a recursive call, you need pass the partial built task/flow set to its sub call to build the integrate one | 12:57 |
| saggi | No, the provider calls walk. It's an implementation detail. The provider gets the plan and the graph. The pluggable provider will walk the graph create contexts and queue tasks on it's own. | 12:58 |
| saggi | For delete it will build the graph from the checkpoint and walk it | 12:58 |
| yinweimac | No problem, provider calls walk. So in each recursive call of walk, we have provider as the variable to save the result as flow set. If this is true, we need create one provider instance per operation, right? | 13:01 |
| saggi | No, did you read the doc I uploaded today about how we build the graph? | 13:02 |
| yinweimac | Let me see if I missed the update | 13:03 |
| saggi | https://docs.google.com/document/d/1Mkd9RgUVdiRL6iei8Nqzzx4xteKIcd-yjMLEkV4Jc9s/edit# | 13:03 |
| saggi | I just shared it on IRC for now. Will upload it to gerrit later today | 13:03 |
| yinweimac | yes, I think we're on the same page on resource graph building | 13:12 |
| *** gampel has joined #openstack-smaug | 13:13 | |
| yinweimac | my question is where to save the result during a recursive call, where the recursive call is ResourceGraphWalker.walk(node) | 13:13 |
| saggi | It's the listeners responsibility to keep the sate. In this case it's the Provder. | 13:14 |
| saggi | The same instance | 13:15 |
| yinweimac | on enter of each node, the listener would be notified to call the plugin to generate tasks, then shall we return those tasks to its parent call? or we just keep them in a variable all recursive calls can access? | 13:15 |
| yinweimac | so your answer is we save the result in provider instance | 13:16 |
| yinweimac | then my question is, we need create new instance of provider per operation | 13:16 |
| saggi | Yes, or some other contextual instance since the same provider might be invoked multiple times. | 13:16 |
| saggi | yinweimac: Now I understand the question. No, the provider could manage different call contexts in the same instance. | 13:17 |
| yinweimac | yes, I prefer other contextual instance | 13:17 |
| saggi | yinweimac: I agree | 13:17 |
| yinweimac | we only keep one provider instance per provider | 13:18 |
| saggi | Yes | 13:18 |
| yinweimac | so you want to link those tasks during Listener.on_leave_node? | 13:18 |
| yinweimac | I suppose new task of the resource is created during listener.on_enter_node, if the node is first time visited | 13:20 |
| saggi | Yes | 13:20 |
| saggi | I still think we should allow task creation in both enter and leave | 13:20 |
| yinweimac | then we DVF walk its dependencies and build tasks of dependencies resources | 13:20 |
| saggi | DVF? | 13:21 |
| yinweimac | after that, on_leave_node, we just link the task of current node to tasks built from dependencies | 13:21 |
| yinweimac | DFS, sorry | 13:22 |
| yinweimac | DVF is a brand of dresses, forget that :) | 13:22 |
| yinweimac | why shall we allow task creation in leave? | 13:24 |
| saggi | Leave let's you know you visited all the child nodes. So if we have a plugin that is registered for VM and Cinder Volume and would like to make one operation for each VM\Volume group. It could use the on_leave_node() callback to know that there are no more volumes for that VM. | 13:28 |
| yinweimac | BTW, Provider needs one more interface like build_flow_graph(backup_plan):[]flow? | 13:44 |
| *** yinweimac has quit IRC | 13:58 | |
| saggi | yinwei: Atom could contain multiple flows by design | 14:09 |
| *** gampel has left #openstack-smaug | 14:56 | |
| *** gampel has joined #openstack-smaug | 16:08 | |
| *** gampel has quit IRC | 16:08 | |
| openstackgerrit | Saggi Mizrahi proposed openstack/smaug: Pluggable protection provider doc https://review.openstack.org/262264 | 16:11 |
| openstackgerrit | Saggi Mizrahi proposed openstack/smaug: Proposed Smaug API v1.0 https://review.openstack.org/244756 | 16:22 |
| *** wanghao has quit IRC | 18:08 | |
| *** wanghao has joined #openstack-smaug | 18:23 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!