| *** zengyingzhe_ has joined #openstack-smaug | 00:38 | |
| openstackgerrit | yinwei proposed openstack/smaug: Basic design doc for Protection Service https://review.openstack.org/261455 | 04:12 |
|---|---|---|
| yinwei | guys, together with the class graph, a rst is also committed. There's more description in the rst. Pls. have a check. | 04:12 |
| *** WANG_Feng has quit IRC | 05:26 | |
| *** WANG_Feng has joined #openstack-smaug | 05:26 | |
| openstackgerrit | Merged openstack/smaug: basic OperationEngine service: Implement a runnable service https://review.openstack.org/261435 | 05:50 |
| *** WANG_Feng has quit IRC | 06:11 | |
| *** WANG_Feng has joined #openstack-smaug | 06:12 | |
| openstackgerrit | chenying proposed openstack/smaug: basic protection service: Implement a runnable service https://review.openstack.org/261590 | 06:45 |
| *** openstackgerrit has quit IRC | 08:32 | |
| *** openstackgerrit has joined #openstack-smaug | 08:32 | |
| zengyingzhe_ | yinwei, copy that. | 08:36 |
| yinwei | hi | 08:37 |
| yinwei | zengyingzhe_,what's up? | 08:38 |
| yinwei | what do you mean by copy that? | 08:38 |
| yinwei | the patch uploaded is together with rst and sequential graph, don't miss them | 08:38 |
| zengyingzhe_ | 收到 | 08:39 |
| zengyingzhe_ | Have you discussed with saggi about the pluggable provider today? | 08:40 |
| saggi | zengyingzhe_: ? | 08:40 |
| zengyingzhe_ | I saw you gave some comments in saggi's patch. | 08:41 |
| zengyingzhe_ | saggi, you there? | 08:43 |
| saggi | zengyingzhe_: Yes | 08:43 |
| zengyingzhe_ | why the resource member of Context parameter passed to get_pre_task, is ResourceGraphNode type, instead of Resource type? | 08:47 |
| zengyingzhe_ | Does this mean a protection plugin can protect a resource tree? | 08:48 |
| saggi | zengyingzhe_: If the plugin want's to protect a tree it will have to register for all sub types not just back up the tree. It's put there so that the plugin could maybe make a decision based on it's children. | 08:52 |
| zengyingzhe_ | So a plugin may protect multiple resource type? | 08:55 |
| zengyingzhe_ | Why don't let provider handle this? A protection plugin just focuses on one type resource. | 08:57 |
| saggi | The pluggable providers calls the get_(pre|post)_task() function for the plugin registered for that specific type. If you want to handle more than one type you will need to register for more than one type. By registering for a type you commit to all aspects of that type. You backup a volume no matter where it is in the tree. | 09:04 |
| saggi | On the same note, you can't really backup a subtree since it might contain types you don't know about that are part of a use defined protectable. | 09:04 |
| saggi | *user defined | 09:05 |
| yinwei | saggi, are you available 2~3 hours later? | 09:06 |
| saggi | yinwei: Yes | 09:06 |
| yinwei | I neet talk with your about the pluggable provider | 09:06 |
| yinwei | thanks. | 09:06 |
| yinwei | will ping you then | 09:06 |
| saggi | I'm here for at least 7 more hours :) | 09:06 |
| saggi | yinwei: sure | 09:07 |
| yinwei | cool | 09:07 |
| zengyingzhe_ | According to your discription, can I say that get_(pre|post)_task() function will return a task, for handling all resources of the type which current plugin supports, not just for one individual resource? | 09:19 |
| saggi | It could do either | 09:36 |
| zengyingzhe_ | Is this resource contained in Context the same as the root_resource parameter for create_checkpoint in ProtectionProvider? | 09:43 |
| zengyingzhe_ | Seems there lacks an important interface in ProtectionProvider. build_all_task or something like this, return the task list to workflow-engine to execute. | 09:52 |
| *** zengyingzhe_ has quit IRC | 10:32 | |
| openstackgerrit | wangliuan proposed openstack/smaug: Implement the basic protection service framework https://review.openstack.org/265760 | 10:42 |
| *** chenying has quit IRC | 11:36 | |
| *** chenying has joined #openstack-smaug | 11:45 | |
| *** chenying has quit IRC | 12:07 | |
| *** c00281451 has joined #openstack-smaug | 12:52 | |
| *** yinweimac has joined #openstack-smaug | 13:09 | |
| yinweimac | hi, saggi | 13:10 |
| saggi | yinweimac: hi | 13:10 |
| yinweimac | how are you doing | 13:10 |
| yinweimac | I'd like to check two scenarios with you | 13:11 |
| yinweimac | from your pluggable provider design, to make sure we're on the same page | 13:12 |
| yinweimac | first, is how to build the resource graph? | 13:12 |
| saggi | Using the ProtectableRegistery | 13:14 |
| yinweimac | yes, more details? | 13:14 |
| yinweimac | say, what we get as input in protection service is the backup plan, where the resources are aggregated into a tuple | 13:15 |
| saggi | A plan has at least one resource associated with it | 13:15 |
| yinweimac | yes | 13:15 |
| saggi | We'll call it ResourceA | 13:16 |
| saggi | you do ProtectableRegistry.get_dependent_resources(ResourceA) | 13:16 |
| saggi | get a least of dependent resources. | 13:16 |
| saggi | For each resource we have not already encountered we do the same thing | 13:17 |
| saggi | slowly building the graph | 13:17 |
| saggi | Every Protectable defines possible_parent_types | 13:17 |
| saggi | So when you register it the registry puts it in a map between a type and protectables. So whe you call fetch_dependant_resources() it will call Protectable.fetch_child_resources() for every Protectable registered for that type. | 13:18 |
| saggi | yinweimac: OK? | 13:18 |
| yinweimac | I'm reading your sentences and checking with your class file | 13:19 |
| saggi | yinweimac: I will write a short pesudo code section. 2 min. | 13:20 |
| yinweimac | yes, that's why i suggested you write a sequential graph. Yes, I guessed so, but I'm not sure how those classes talks with each other | 13:22 |
| yinweimac | so, is Protectable is abstraction of a type of resource, who will handle the potential hierarchy of resources which belongs to this type. Like, for all VMs, there's one VMProtectable class, which will handle all VM resources to fetch_child_resources of them. Sounds like Protectable a helper class of Resource class? | 13:29 |
| saggi | yinweimac: http://fpaste.org/309390/14525190/ | 13:31 |
| yinweimac | checking | 13:31 |
| yinweimac | thanks! | 13:31 |
| saggi | yinweimac: Is that clear now? | 13:36 |
| yinweimac | yes, the registry scenario is quite clear | 13:36 |
| yinweimac | for node graph building, since our input is a list of resources, say, a list of VMs, they are trees. No edges link to those independent trees. | 13:38 |
| yinweimac | one call of build_graph won't complete the graph, right? | 13:38 |
| yinweimac | we need iterate all resources of the plan's resource list and then build the whole graph, right? | 13:39 |
| yinweimac | it's not a full-connected graph, right? | 13:39 |
| saggi | No | 13:40 |
| yinweimac | why | 13:40 |
| saggi | We will run build_graph on every resource on the list | 13:40 |
| saggi | but with the same reousrces_seen map | 13:40 |
| saggi | this will make sure that if there is a connection we will find it and we will have one node per resrouces | 13:40 |
| saggi | That you run DFS on the graph which will do a topological sort of the nodes | 13:41 |
| saggi | We don't allow circles though | 13:41 |
| yinweimac | why is there a connection between two VMs | 13:41 |
| saggi | They might use the same glance image | 13:41 |
| saggi | so they will share dependencies | 13:42 |
| yinweimac | hmm | 13:42 |
| yinweimac | then VMs with different images? | 13:42 |
| yinweimac | why they're connected? | 13:42 |
| yinweimac | same network? | 13:42 |
| saggi | They are not directly connected in the graph | 13:43 |
| saggi | but you do have a shared node | 13:43 |
| saggi | Or you could have a case where nothing is shared | 13:43 |
| yinweimac | ok | 13:43 |
| yinweimac | so the graph could be a tree or a forest | 13:43 |
| yinweimac | right? | 13:43 |
| saggi | No because a tree doesn't allow having a shared node | 13:44 |
| saggi | in a tree that should only be one path between two nodes | 13:44 |
| yinweimac | could you give me a non tree example? | 13:46 |
| saggi | ProjectA->VM_A -> GlanceA | 13:47 |
| saggi | ProjectA->VM_B -> GlanceA | 13:47 |
| saggi | There are two paths between ProjectA and GlanceA so it's not a tree. | 13:47 |
| saggi | It's just a project with 2 VMs that share the same glance image. It's a pretty common use case | 13:48 |
| yinweimac | hmm, got it | 13:49 |
| yinweimac | ok, so we iterate all resources to build_graph with same resources_seen | 13:50 |
| saggi | Yes, so we don't create a node for the same resource twice | 13:50 |
| saggi | that way we get a full graph | 13:50 |
| saggi | we do a topological sort | 13:50 |
| saggi | Make sure we have no loops | 13:50 |
| yinweimac | the output would either be a full connected graph or a not connected graph | 13:50 |
| saggi | You could have any kind of graph | 13:51 |
| saggi | since you could have resources that don't share anything | 13:51 |
| yinweimac | just no cyclic | 13:51 |
| yinweimac | graph | 13:51 |
| saggi | yes | 13:52 |
| yinweimac | so how about walk through the graph to build tasks, is it necessary to get_pre_task and get_post_task? | 13:52 |
| yinweimac | do you want to get output as two parallel flows, first for pre tasks, second for post tasks? | 13:53 |
| yinweimac | those two parallel subflows will compose a sequential flow | 13:53 |
| saggi | yinweimac: I got to go for an interview. | 13:53 |
| yinweimac | ok | 13:53 |
| saggi | But the tasks relate to iteration on the graph | 13:53 |
| saggi | and creating dependencies between tasks | 13:54 |
| saggi | I admit it's not fully baked yet | 13:54 |
| saggi | So I'll\ appreciate your feedback | 13:54 |
| yinweimac | yes, I will talk with you tommorrow, to see how to align our two designs together | 13:54 |
| yinweimac | so pls feel free to go for your interview | 13:55 |
| *** yinweimac has quit IRC | 14:06 | |
| *** gampel has joined #openstack-smaug | 14:31 | |
| openstackgerrit | Merged openstack/smaug: basic protection service: Implement a runnable service https://review.openstack.org/261590 | 15:25 |
| *** gampel has quit IRC | 15:39 | |
| openstackgerrit | Saggi Mizrahi proposed openstack/smaug: Pluggable protection provider doc https://review.openstack.org/262264 | 16:35 |
| *** gampel has joined #openstack-smaug | 23:22 | |
| *** gampel has quit IRC | 23:48 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!