| *** chenhuayi has joined #openstack-smaug | 02:04 | |
| openstackgerrit | zengchen proposed openstack/smaug: Implement time trigger with Eventlet https://review.openstack.org/296880 | 02:34 |
|---|---|---|
| openstackgerrit | zengchen proposed openstack/smaug: Implement rpc interfaces of OperationEngine https://review.openstack.org/299739 | 02:34 |
| openstackgerrit | zengchen proposed openstack/smaug: Implement time trigger with Eventlet https://review.openstack.org/296880 | 02:50 |
| openstackgerrit | smile-luobin proposed openstack/smaug: Fix serialized_meta in SwiftBankPlugin https://review.openstack.org/301427 | 03:29 |
| *** zhangshuai has joined #openstack-smaug | 04:41 | |
| *** zhangshuai has quit IRC | 04:42 | |
| xiangxinyong | saggi: good morning | 04:58 |
| *** xiangxinyong456 has joined #openstack-smaug | 05:17 | |
| xiangxinyong | saggi: hello | 05:22 |
| *** xiangxinyong456 has quit IRC | 05:24 | |
| *** saggi_class has joined #openstack-smaug | 05:24 | |
| saggi_class | ping xiangxinyong | 05:24 |
| xiangxinyong | morning | 05:24 |
| saggi_class | sorry I'm late | 05:25 |
| saggi_class | I'm actually in class | 05:25 |
| xiangxinyong | you are welcome | 05:25 |
| saggi_class | I'll try and be brief | 05:25 |
| saggi_class | Your idea is good. | 05:25 |
| xiangxinyong | http://paste.openstack.org/show/492976/ | 05:25 |
| saggi_class | The only issue is that you put the properties in the resource "struct" | 05:25 |
| saggi_class | And that will give us issues when deserializing it | 05:26 |
| saggi_class | since it's not a field of the resource class inside the code | 05:26 |
| saggi_class | So you just need to put it somewhere else | 05:27 |
| xiangxinyong | so do you have suggestion? | 05:27 |
| saggi_class | What about: {"resource": {...}, "parameters": {...} } | 05:27 |
| saggi_class | For every item in the list | 05:27 |
| saggi_class | ? | 05:28 |
| xiangxinyong | saggi i paste the code into here. https://etherpad.openstack.org/p/createplan | 05:28 |
| xiangxinyong | could you adjust the format you suggest. | 05:29 |
| xiangxinyong | thanks | 05:29 |
| saggi_class | I changed the first one | 05:31 |
| saggi_class | what do you think? | 05:31 |
| xiangxinyong | i see it. i am ok | 05:32 |
| xiangxinyong | i add a name property. | 05:33 |
| xiangxinyong | what do you think about it? | 05:33 |
| saggi_class | great | 05:33 |
| saggi_class | did you see I sent the API change patch yesterday? | 05:33 |
| xiangxinyong | yeah. i review the two patches. very good and very important | 05:34 |
| xiangxinyong | saggi: if we agree with json format about create plan, we can notify chenying and yinwei | 05:35 |
| saggi_class | yes, just check with them that they are OK with it as well | 05:35 |
| xiangxinyong | They will do some changes in the create plan workflow | 05:35 |
| saggi_class | They have a good eye for such stuff | 05:35 |
| xiangxinyong | ok. i will | 05:36 |
| saggi_class | thanks | 05:36 |
| xiangxinyong | saggi: i have the similar question about the restore flow | 05:36 |
| xiangxinyong | https://etherpad.openstack.org/p/restorecheckpoint | 05:36 |
| xiangxinyong | please take a look at it | 05:37 |
| xiangxinyong | As we discuss it yesterday, we need to edit the resource parameters when we restore from a checkpoint | 05:38 |
| xiangxinyong | we think we need to add some parameter so that we can launch a restore workflow. | 05:39 |
| saggi_class | Yes, the original plan was to have paramters be able to specify ID in the type. | 05:39 |
| saggi_class | check out https://etherpad.openstack.org/p/restorecheckpoint | 05:41 |
| saggi_class | But not that we decided to change that for backup | 05:43 |
| saggi_class | we might need to change it also for restore | 05:43 |
| xiangxinyong | oh | 05:43 |
| xiangxinyong | i add new restore json in the end of file. | 05:45 |
| xiangxinyong | https://etherpad.openstack.org/p/restorecheckpoint | 05:46 |
| * saggi_class is checking it | 05:47 | |
| xiangxinyong | ok. i finish to modify it | 05:48 |
| xiangxinyong | i combine the default parameters | 05:49 |
| xiangxinyong | username and resource default parameters | 05:50 |
| saggi_class | The thing I'm thinking about is whether this is really better than the old notation | 05:50 |
| saggi_class | Why do we need the type in the parameters per resource? | 05:51 |
| saggi_class | We know the type of the resource | 05:51 |
| saggi_class | when can just put them | 05:51 |
| saggi_class | when=ew | 05:51 |
| saggi_class | ew=we | 05:51 |
| saggi_class | xiangxinyong: ? | 05:53 |
| xiangxinyong | so your opinion is that we only need resource id? | 05:53 |
| saggi_class | no | 05:53 |
| saggi_class | 1 sec | 05:53 |
| xiangxinyong | ok | 05:53 |
| saggi_class | https://etherpad.openstack.org/p/restorecheckpoint | 05:54 |
| xiangxinyong | so you mean we have the same struct as the plan create | 05:56 |
| saggi_class | that was what you suggested | 05:56 |
| saggi_class | What I removed is the type of the parameters part | 05:56 |
| saggi_class | back in 5 | 05:57 |
| xiangxinyong | ok saggi | 05:58 |
| chenying_ | Hi | 05:58 |
| chenying_ | xinyong you change the struct of plan How to store this parameters to db? do you consider this? | 06:06 |
| saggi_class | chenying_: It shouldn't change much | 06:07 |
| xiangxinyong | chengying: what do you think about it? | 06:08 |
| chenying_ | adding a parameters to resource is ok | 06:10 |
| chenying_ | resource: | 06:10 |
| chenying_ | { | 06:10 |
| chenying_ | "id": "64e51e85-4f31-441f-9a5d-6e93e3196628", | 06:10 |
| chenying_ | "type": "OS::Nova::Server", | 06:10 |
| chenying_ | "name": "Saggi's computer" | 06:10 |
| chenying_ | }, | 06:10 |
| chenying_ | "parameters": { | 06:10 |
| chenying_ | "consistency": "os" | 06:10 |
| chenying_ | } | 06:10 |
| chenying_ | }, | 06:10 |
| chenying_ | }, | 06:10 |
| chenying_ | i don't understand this | 06:10 |
| saggi_class | It puts it next to it instead of inside it so we don't change the resource serialize | 06:11 |
| saggi_class | \deserialize for this | 06:11 |
| chenying_ | You can check the db structure plan : resource -> 1:n | 06:11 |
| saggi_class | the old way was to just put it in the key "OS::Server::Nova;id00-000000-000-0000" | 06:12 |
| chenying_ | imo the parameters of a resource is defined by a resource type. don't need define by a instance. | 06:14 |
| *** gampel1 has joined #openstack-smaug | 06:16 | |
| gampel | we need global default and specific settings | 06:17 |
| yinwei_computer | hi guys | 06:22 |
| saggi_class | chenying_: this is why I removed the type | 06:22 |
| saggi_class | It's just the parameters for that type | 06:22 |
| saggi_class | hi yinwei_computer | 06:22 |
| yinwei_computer | go ahead | 06:23 |
| yinwei_computer | trying to catch up with you | 06:23 |
| chenying_ | you have another parameter field in the plan structure. does it for resource type ? | 06:25 |
| saggi_class | xiangxinyong: Why not just leave it as it was. With the seperator for cases where we want to define for specific resource. It's like a very simple css selector from html. | 06:25 |
| xiangxinyong | saggi: Do you mean we can add the special resource into the default parameters when we create the plan? | 06:28 |
| saggi_class | No use the format: "<TYPE>" for type default and "<TYPE>;<RESOURCE_ID>" for resource specific. | 06:30 |
| xiangxinyong | like this one: https://etherpad.openstack.org/p/createplannew | 06:31 |
| xiangxinyong | ? | 06:31 |
| chenying_ | It puts it next to it instead of inside it. how to organize the data in db table. Imo add a parameter for a resoure, I just add a parameter field to the database resources. | 06:33 |
| saggi_class | xiangxinyong: yes | 06:33 |
| saggi_class | chenying_: You need a general place to put default anyway. | 06:34 |
| chenying_ | default parameter for a type will be added to the database table paln. | 06:35 |
| saggi_class | chenying_: Default parametrs for tpe | 06:35 |
| saggi_class | So you can use this key format | 06:35 |
| saggi_class | But thinking about it | 06:36 |
| saggi_class | you both are working on both ends of this code | 06:36 |
| saggi_class | if you think it's better for you | 06:36 |
| saggi_class | Then it's OK | 06:36 |
| saggi_class | Just remove the type from the parameters in the resource | 06:37 |
| saggi_class | since it makes no sense to put it twice | 06:37 |
| chenying_ | I see the new link. | 06:37 |
| chenying_ | Does it mean that only add a parametr field to table plan? | 06:40 |
| chenying_ | the content of the parametr dump to a string? | 06:41 |
| *** yuval has joined #openstack-smaug | 06:42 | |
| saggi_class | I really have to go | 06:42 |
| saggi_class | sorry | 06:42 |
| xiangxinyong | ok. see you/ | 06:42 |
| saggi_class | But the per resource parameters need to be stored similiarly to how type defaults are stored | 06:42 |
| *** saggi_class has quit IRC | 06:43 | |
| chenying_ | I only concern how the persistence data persistence to the database table. | 06:46 |
| chenying_ | how the parametrs data persistence to the database table. | 06:46 |
| xiangxinyong | yinwei: are you here? | 06:49 |
| openstackgerrit | Eran Gampel proposed openstack/smaug: Implement time trigger with Eventlet https://review.openstack.org/296880 | 06:51 |
| chenying_ | ping gampel1 | 06:57 |
| gampel | hi chenying_ | 07:00 |
| chenying_ | Hi Eran I have another question about restore api. | 07:00 |
| gampel | yes | 07:00 |
| chenying_ | You know, now the resore action may generate a heat template. | 07:01 |
| openstackgerrit | Yuval Brik proposed openstack/smaug: Fix python3 compatibility https://review.openstack.org/301659 | 07:01 |
| chenying_ | Do we need change or modify the restore api? generating a heat template or executing a resore action may have different parameters and responses? | 07:01 |
| gampel | I think that the heat template should be internal, not as a return value | 07:01 |
| gampel | You mean to have an option just to generate the heat template ? | 07:02 |
| chenying_ | yes | 07:02 |
| *** openstackgerrit has quit IRC | 07:02 | |
| gampel | It is problematic because some of the resources like Volume must be created on restore | 07:02 |
| *** openstackgerrit has joined #openstack-smaug | 07:03 | |
| chenying_ | restore API parameters can define generating a heat template or executing a resore action. | 07:03 |
| gampel | I think we can not generate heat template because the restore will create some of the resources and you will not know which are generated by the heat template and which are created in the restore | 07:04 |
| chenying_ | heat template should be internal you mean after generating a heat template, a new task will execute the heat template ? | 07:05 |
| chenying_ | or just generating a heat template, a user should get this template, and execute it himself. | 07:05 |
| gampel | I think so think of volume heat can not generate it some one must copy the data from the backup to the new volume | 07:05 |
| gampel | unless we using Heat to call cider backup | 07:05 |
| gampel | Some of the use cases we got form the product is restore to the same VM | 07:06 |
| chenying_ | let me see. | 07:07 |
| chenying_ | as yinwei's design a heat template is a must. all the resources are created by the heat template. | 07:09 |
| gampel | chenying_: lets talk about it latter i think we should add yinwei to this thread | 07:09 |
| yinweiishere | I'm in | 07:09 |
| yinweiishere | gampel_, even restore() produced resource, we can wait until it's available, and make it as a HeatParameter | 07:10 |
| yinweiishere | and thus have its parent to refer it in its heat resource section | 07:11 |
| gampel | to my understanding they could be referenced or created in the heat | 07:11 |
| yinweiishere | heat is able to create volume from backup which means to call cinder backup restore | 07:11 |
| gampel | Yes but we will not always have cider in the loop | 07:11 |
| yinweiishere | yes, they're two round trips | 07:11 |
| gampel | I mean you could think of image or volume backup that is not using cinder backup API | 07:12 |
| yinweiishere | first round trip: we run task flow to generate heat tempate | 07:12 |
| gampel | The question from chenying_ was if we need to return the heat template | 07:13 |
| yinweiishere | insid this trip, image/volume backup not using cinder backup API could restore resource synchronously in restore() | 07:13 |
| gampel | I think that this should be internal | 07:13 |
| yinweiishere | pls. wait for my full printing | 07:13 |
| yinweiishere | and the resource they restored in the task flow should encapsulate as a parameter and inject into a shared HeatTemplate | 07:14 |
| yinweiishere | then its parent task runs to refer the child resource created as parameter to construct parent's heat template | 07:14 |
| gampel | The question is whether a heat template is an internal mechanism or is it exposed through the API? I believe it is internal and *not* exposed | 07:15 |
| yinweiishere | hmm, I think we could offer options | 07:15 |
| yinweiishere | one option is to restore checkpoint, means generate template and restore the stack | 07:16 |
| yinweiishere | second is only export template and user could choose when to restore it. | 07:16 |
| yinweiishere | it's just an action of checkpoint | 07:16 |
| yinweiishere | should be export checkpoint | 07:16 |
| yinweiishere | export checkpoint to heat template | 07:16 |
| gampel | Let me try to explain this again since I don | 07:17 |
| gampel | 't think I am explaining myself properly | 07:17 |
| yinweiishere | ok | 07:17 |
| yinweiishere | go ahead pls. | 07:17 |
| gampel | there is an asymmetry between the volume and the resources that are created by the heat template | 07:18 |
| gampel | the process should be driven from one place | 07:18 |
| gampel | using heat templates we would get a situation where some resources are created by heat and some externally by the protection plugin | 07:18 |
| yinweiishere | got your point | 07:19 |
| gampel | what I want to reach is a design where all resources are created from the same place, otherwise we will not be able to maintain this long term | 07:19 |
| yinweiishere | so 'export checkpoint' is not simply export checkpoint into a yaml file | 07:20 |
| gampel | if heat is internal we do not have this problem | 07:20 |
| yinweiishere | but may introduce some real resource creation | 07:20 |
| yinweiishere | because we allow 2 ways to restore | 07:20 |
| yinweiishere | ok, agree | 07:20 |
| yinweiishere | so we only provide restore option | 07:21 |
| yinweiishere | we don't allow user to export checkpoint externally | 07:21 |
| gampel | that's what i think but we should add saggi and all the others to the loop and get feednacks | 07:22 |
| yinweiishere | confirm: internally we will create heat template for restore and tolerate two options for restore | 07:22 |
| gampel | chenying_: what do you think | 07:22 |
| gampel | ? | 07:22 |
| yinweiishere | yes, saggi has given me some comments on the restore spec | 07:22 |
| gampel | Ok i will try to continue going over it today | 07:23 |
| yinweiishere | thanks! | 07:23 |
| gampel | thank you | 07:23 |
| yinweiishere | we're also looking for python yaml lib to see if it could simplify our parsing work | 07:23 |
| yinweiishere | gampel | 07:24 |
| yinweiishere | one another question | 07:24 |
| yinweiishere | are you still there? | 07:24 |
| gampel | yes i am here | 07:25 |
| xiangxinyong | yinwei: PyYAML>=3.1.0 # MIT | 07:25 |
| gampel | what does heat use | 07:26 |
| chenying_ | Ok we can collect other guys's feednacks. | 07:26 |
| yinweiishere | gampel: your are asking me? | 07:27 |
| gampel | yes | 07:28 |
| yinweiishere | we will have restore() to fill a in memory object HeatResource, and HeatResource will organize fields into dict. It will use py yaml to dump the internal dict to yaml format stream | 07:29 |
| yinweiishere | xiangxinyong: thanks | 07:32 |
| gampel | ok got it | 07:32 |
| yinweiishere | we will note the version of lib | 07:32 |
| yinweiishere | gampel | 07:33 |
| gampel | any thing else we need to discuss i need to go | 07:33 |
| yinweiishere | one another question | 07:33 |
| gampel | yes sure | 07:33 |
| yinweiishere | currently our protection plugin client uses the context passed down by API | 07:33 |
| yinweiishere | including the token | 07:33 |
| gampel | yes | 07:34 |
| yinweiishere | there is one issue, that protection plugin may need check openstack resource status asynchronously | 07:34 |
| yinweiishere | it's possible that the token from API may expire | 07:34 |
| openstackgerrit | WeAreFormalGroup proposed openstack/smaug: Implement cinder protection plugin https://review.openstack.org/286458 | 07:34 |
| gampel | yes i see we discuss this with one of cinder cors | 07:34 |
| yinweiishere | yes, plus the token is per tenant while in background we may need admin token to check all resources status | 07:35 |
| gampel | I said there an option in keystone to continue renewing the keystone session | 07:35 |
| gampel | let me check and i will get back to you | 07:35 |
| yinweiishere | ok | 07:35 |
| yinweiishere | no problem | 07:35 |
| gampel | Ok we might need a special admin ctx let me check | 07:36 |
| yinweiishere | renew token doesn't work for restore, where restore heat client need token from the target keystone | 07:37 |
| yinweiishere | ok | 07:37 |
| yinweiishere | talk to you later | 07:37 |
| openstackgerrit | zengchen proposed openstack/smaug: Implement rpc interfaces of OperationEngine https://review.openstack.org/299739 | 07:38 |
| gampel | Please vote https://review.openstack.org/#/c/301659/2 we want to put the python 3 CI in palce | 07:41 |
| openstackgerrit | WeAreFormalGroup proposed openstack/smaug: Implement glance protection plugin https://review.openstack.org/295752 | 07:43 |
| xiangxinyong | ok | 08:04 |
| openstackgerrit | smile-luobin proposed openstack/smaug: Implement nova protection plugin https://review.openstack.org/295618 | 08:05 |
| openstackgerrit | chenying proposed openstack/smaug: Add name property to protectable instances model https://review.openstack.org/302086 | 08:13 |
| yuval | Hey all, please vote for the py3 CI jobs: | 08:17 |
| yuval | https://review.openstack.org/#/c/302072/ | 08:17 |
| yuval | and: | 08:18 |
| yuval | https://review.openstack.org/#/c/301659/ | 08:18 |
| openstackgerrit | Merged openstack/smaug: Fix python3 compatibility https://review.openstack.org/301659 | 08:50 |
| openstackgerrit | zengchen proposed openstack/smaug: Implement RestAPIs of trigger. https://review.openstack.org/286406 | 08:57 |
| openstackgerrit | chenying proposed openstack/smaug: Add name property to protectable instances model https://review.openstack.org/302086 | 09:12 |
| *** gampel2 has joined #openstack-smaug | 09:14 | |
| *** gampel1 has quit IRC | 09:16 | |
| gampel | Yuli: ping | 09:21 |
| openstackgerrit | yinwei proposed openstack/smaug: Restore design spec (protection service level) https://review.openstack.org/296950 | 09:33 |
| yinweiishere | ping gampel | 09:34 |
| yinweiishere | you are looking for me? | 09:34 |
| yinweiishere | Just got message on espace | 09:34 |
| openstackgerrit | chenying proposed openstack/smaug: Add show protectables instance endpoint https://review.openstack.org/302137 | 09:46 |
| openstackgerrit | chenying proposed openstack/smaug: Add show protectables instance endpoint https://review.openstack.org/302144 | 09:56 |
| openstackgerrit | zengchen proposed openstack/smaug: Implement RestAPIs of Scheduled Operation. https://review.openstack.org/287036 | 10:06 |
| xiangxinyong | hello saggi | 10:44 |
| openstackgerrit | zengchen proposed openstack/smaug: Implement RestAPIs of Scheduled Operation. https://review.openstack.org/287036 | 11:01 |
| openstackgerrit | zengchen proposed openstack/smaug: Implement rpc interfaces of OperationEngine https://review.openstack.org/299739 | 11:07 |
| openstackgerrit | zengchen proposed openstack/smaug: Implement executor of OperationEngine https://review.openstack.org/282263 | 11:30 |
| *** chenhuayi has quit IRC | 11:57 | |
| openstackgerrit | Yuval Brik proposed openstack/smaug: Add project protectable and dependencies https://review.openstack.org/302212 | 12:27 |
| yuval | CI now runs Python 3 jobs | 12:37 |
| *** xiangxinyong456 has joined #openstack-smaug | 12:56 | |
| *** xiangxinyong456 has quit IRC | 13:00 | |
| *** yuval has quit IRC | 13:30 | |
| *** Hunter has joined #openstack-smaug | 13:59 | |
| *** Hunter is now known as Guest4135 | 14:00 | |
| *** Guest4135 has quit IRC | 14:04 | |
| xiangxinyong | yuval: :) | 14:34 |
| *** chenhuayi has joined #openstack-smaug | 15:15 | |
| *** gampel2 has quit IRC | 15:22 | |
| *** chenhuayi has quit IRC | 16:52 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!