| *** chenying_ has quit IRC | 00:03 | |
| *** chenying has joined #openstack-smaug | 00:04 | |
| *** yinwei has joined #openstack-smaug | 01:01 | |
| *** c00281451 is now known as chenzeng | 01:23 | |
| openstackgerrit | chenying proposed openstack/smaug: basic protection service: Implement a runnable service https://review.openstack.org/261590 | 02:39 |
|---|---|---|
| *** chenzeng has quit IRC | 03:15 | |
| chenying | saggi: hi saggi | 06:10 |
| *** gampel has joined #openstack-smaug | 07:07 | |
| yinweiishere | hi Eran | 07:28 |
| *** saggi has quit IRC | 08:46 | |
| chenying | Hi everyone I have gathered the comments about the schedule service name and listed them in the patch. | 09:15 |
| chenying | 09:15 | |
| chenying | Could we figure out the name by taking a voting? | 09:15 |
| gampel | whats your vote | 09:16 |
| gampel | yinweiishere: hi | 09:17 |
| *** saggi has joined #openstack-smaug | 09:26 | |
| yinweiishere | hi, saggi and Eran | 09:30 |
| saggi | yinweiishere: Hey | 09:31 |
| yinweiishere | could anyone of you two take an example of the dependency defined in bank.md, which seems to be a field of protection_definition value | 09:31 |
| yinweiishere | I thought it means the metadata of VM, like the volumes attached to VM. But Eran responded in comment, it's not. | 09:32 |
| yinweiishere | any example of this dependency? | 09:32 |
| yinweiishere | ### Protection definition directory | 09:33 |
| yinweiishere | `/checkpoints/<checkpoint_id>/<resource_id>/index.json` | 09:33 |
| yinweiishere | #### Example content | 09:33 |
| yinweiishere | ```json | 09:33 |
| yinweiishere | { | 09:33 |
| yinweiishere | "name": "vm", | 09:33 |
| yinweiishere | "id": "8a562ed6-81ff-4bda-9672-2a8c49f130c3", | 09:33 |
| yinweiishere | "dependent_resources": [ | 09:33 |
| yinweiishere | "92b022d9-cca4-4d02-b7fb-6cec9183d9f2", | 09:33 |
| yinweiishere | "b081d472-023c-4a98-b57b-f2013996739b" | 09:33 |
| yinweiishere | ] | 09:33 |
| yinweiishere | } | 09:34 |
| yinweiishere | what does this dependent_resources mean? | 09:34 |
| yinweiishere | Eran said: The mapping is the dependencies and the tag we add to it for multiple dependency's of the same type. | 09:35 |
| yinweiishere | saggi, what's your opinion? as you're the author? | 09:37 |
| saggi | yinweiishere: dependent_resources are the resources that were under it in the graph when the checkpoint was created. | 09:38 |
| saggi | These are the resource IDs. | 09:39 |
| chenying | a suggestion from saggi, I think PolicyEngine is ok. My vote is PolicyEngine. | 09:49 |
| gampel | I am for operationEngine operation_engine | 09:57 |
| gampel | this way we do not introduce another name "Policy" | 09:58 |
| gampel | yinweiishere: in the current design we leave the internal mapping of this two volumes to the VM to be stored by the VM plug in metadata/data | 09:59 |
| gampel | does this make sense ? | 09:59 |
| yinweiishere | gampel, but as you told in comment response, it's vm plugin who will be responsible for persisting the metadata (two volumes attached to it, and which the device paths are). How could it be persisted in bank? | 10:07 |
| yinweiishere | Discussed the procedure with chenying, it seems that each VM plugin protect() function would return a byte buffer, which is serialized with schema understood by this plugin. The caller (protection service workflow) will only persist the value under each protection definition. | 10:09 |
| yinweiishere | which means, the vm plugin will serialize the dependency into its own protection definition value. Protection service doesn't need understand or define the schema of each protection definition value. When restore is called, protection service workflow just pass the value to each vm plugin. | 10:11 |
| yinweiishere | 'Policy' is known in many storage products, like policy driven configuration. IMHO, both the time schedule or event trigger could be taken as a policy, user could configure the policy to schedule our plans. | 10:13 |
| yinweiishere | what do you think? In protect, we have vm plugin itself to define its value schema, including the metadata (dependency is one field of the metadata), protection service just persist it into bank. In restore, we pass the value to plugin, and have plugin to understand its dependency and other fields in the value. | 10:17 |
| gampel | yinweiishere: are you still here , i was out | 11:44 |
| openstackgerrit | Eran Gampel proposed openstack/smaug: Add Smaug spec directory https://review.openstack.org/261913 | 12:19 |
| *** saggi has quit IRC | 13:54 | |
| *** gampel has quit IRC | 16:24 | |
| *** gsagie_ has joined #openstack-smaug | 16:49 | |
| *** gsagie_ has left #openstack-smaug | 16:49 | |
| openstackgerrit | Saggi Mizrahi proposed openstack/smaug: Pluggable protection provider doc https://review.openstack.org/262264 | 17:06 |
| openstackgerrit | Merged openstack/smaug: basic API service: Create the base DAL into the DB https://review.openstack.org/259311 | 17:35 |
| *** gampel has joined #openstack-smaug | 18:30 | |
| *** gampel has quit IRC | 18:33 | |
| *** openstack has joined #openstack-smaug | 20:36 | |
| *** openstack has joined #openstack-smaug | 21:06 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!