| *** zhurong has joined #openstack-karbor | 01:09 | |
| *** dixiaoli has joined #openstack-karbor | 01:11 | |
| *** edisonxiang has quit IRC | 01:12 | |
| *** liujiong has joined #openstack-karbor | 01:18 | |
| *** dims has quit IRC | 01:21 | |
| *** dims has joined #openstack-karbor | 01:33 | |
| *** jiaopengju has joined #openstack-karbor | 01:50 | |
| *** zhurong_ has joined #openstack-karbor | 03:23 | |
| *** zhurong_ has quit IRC | 03:25 | |
| *** zhurong has quit IRC | 03:56 | |
| *** gouthamr has quit IRC | 05:41 | |
| jiaopengju | hi chenying yuval, if you have time, please help review this patch, thank you. https://review.openstack.org/#/c/500371/ | 06:04 |
|---|---|---|
| *** zhurong has joined #openstack-karbor | 06:08 | |
| chenying | jiaopengju: Ok I will. | 06:10 |
| jiaopengju | chenying: thank you :) | 06:11 |
| jiaopengju | chenying yuval: for this bug , “Failed to restore server if the network rebuild ”, https://bugs.launchpad.net/karbor/+bug/1713887 , do you have any ideas? | 06:13 |
| openstack | Launchpad bug 1713887 in Karbor "Failed to restore server if the network rebuild" [Undecided,New] | 06:13 |
| openstackgerrit | Merged openstack/karbor master: Fix checkpoints pagination error https://review.openstack.org/500371 | 06:16 |
| chenying | jiaopengju: IMO, by default, the usecase of restoring the server, the network of this server will be same as the nova plugin do now. | 06:24 |
| jiaopengju | chenying: I agree with you | 06:24 |
| chenying | jiaopengju: There may be another usecase, restore servers to another OpenStack environment,. | 06:25 |
| jiaopengju | chenying: Yes, should we add parameters for this usecase? | 06:25 |
| chenying | jiaopengju: restore servers to another OpenStack environment is more like the usecase about restore cross-site, we may need think carefully about it. | 06:27 |
| chenying | jiaopengju: In this usecase, the network topology will be rebuild. | 06:28 |
| chenying | ping yuval | 06:28 |
| jiaopengju | chenying: For the usecase of in one environment, if the users delete the private network, all the servers based on the deleted private network will be invalid | 06:30 |
| jiaopengju | s/all the servers/all the servers backup | 06:31 |
| chenying | jiaopengju: For the usecase of in one environment, I think we can pass the network as the parameters of this server in plan. | 06:34 |
| jiaopengju | chenying: ok, get it | 06:34 |
| yuval | hey chenying | 06:43 |
| * yuval is reading https://bugs.launchpad.net/karbor/+bug/1713887 | 06:44 | |
| openstack | Launchpad bug 1713887 in Karbor "Failed to restore server if the network rebuild" [Undecided,New] | 06:44 |
| chenying | hi yuval Good morning. | 06:45 |
| yuval | chenying: good afternoon :) | 06:45 |
| chenying | yuval Now I have a question about k8s protectable want to discuss with you. | 06:45 |
| yuval | chenying: sure, one sec, I'm reading https://bugs.launchpad.net/karbor/+bug/1713887 | 06:46 |
| openstack | Launchpad bug 1713887 in Karbor "Failed to restore server if the network rebuild" [Undecided,New] | 06:46 |
| chenying | yuval: OK | 06:46 |
| yuval | jiaopengju: chenying: regarding https://bugs.launchpad.net/karbor/+bug/1713887 | 06:48 |
| openstack | Launchpad bug 1713887 in Karbor "Failed to restore server if the network rebuild" [Undecided,New] | 06:48 |
| jiaopengju | hi yuval | 06:49 |
| yuval | jiaopengju: chenying: we have no way to know if the restored network A is the same as the original network A. Maybe some time passed and user made many changes to the restored network A? | 06:49 |
| yuval | jiaopengju: chenying: therefor, I think we should let the server be restored even if we cannot connect it to the network | 06:49 |
| chenying | yuval: I discuss it with jiaopengju now. | 06:49 |
| yuval | jiaopengju: chenying: and let the user specify in the parameter to which network to attach, in case it is a different one | 06:50 |
| chenying | yuval jiaopengju: Yes | 06:50 |
| chenying | For the usecase of in one environment, I think we can pass the network as the parameters of this server in plan. | 06:50 |
| jiaopengju | yuval chenying: this solution is ok. | 06:51 |
| chenying | yuval jiaopengju: let the server be restored even if we cannot connect it to the network ------Does it means that the user also can configure the network of the restored server manually? | 06:51 |
| yuval | chenying: after the server is restored, the user can do whatever they want | 06:52 |
| chenying | yuval jiaopengju: and let the user specify in the parameter to which network to attach, in case it is a different one --------The network that the user want to use can be as the parameters of this server in plan. | 06:53 |
| yuval | chenying: yes | 06:53 |
| jiaopengju | yuval chenying: It seems that this is the only way, because we can not change the network id | 06:54 |
| chenying | jiaopengju: It seems that this is the only way, because we can not change the network id -----sorry, what do you mean? the new network whatever they want can be as the the parameters of this server in plan. | 06:55 |
| jiaopengju | chenying: I means we can not change the restored network id | 06:56 |
| jiaopengju | chenying: but we can specify the server’s attach network id | 06:56 |
| chenying | jiapengju: Yes we don't need change the restore network id. | 06:59 |
| jiaopengju | :) | 07:00 |
| chenying | jiapengju: So are we all clear about the solution about this bug? do you have any other question? | 07:00 |
| jiaopengju | chenying: I’m clear. I will try to fix this bug soon. | 07:01 |
| chenying | yuval: Are you free now? So can we continue discussing the pod protectable? | 07:01 |
| yuval | chenying: yes | 07:02 |
| chenying | yuval: Although the uid of pod resource can be returned from the k8s cluster. But the k8s only expose a get pod API with the parameter pod name. | 07:03 |
| chenying | yuval: The pod( like other resources) name and the namespace are the only key for the pod resource. | 07:03 |
| yuval | chenying: umm, ok? | 07:05 |
| chenying | yuval: After I have a look at some discussion about the api about the resource uid in k8s community. The uid will not be used for the resource operation in api. | 07:05 |
| chenying | yuval: In karbor protectable, the show api . The parameter of show_resource method is resource_id. | 07:06 |
| *** zhurong has quit IRC | 07:08 | |
| chenying | yuval: So I am thinking about fill the Resource id with the pod name? Do you have any idea about it? | 07:12 |
| yuval | chenying: I'm reading https://kubernetes.io/docs/api-reference/v1.7/#objectmeta-v1-meta | 07:12 |
| yuval | chenying: and it says: UID is the unique in time and space value for this object. It is typically generated by the server on successful creation of a resource and is not allowed to change on PUT operations. Populated by the system. | 07:12 |
| yuval | chenying: on a second look, yes, it seems like name is unique and it used for read/update operations | 07:13 |
| chenying | yuval: yes but the uid as the resource key is not used in any restfull api of the k8s. | 07:14 |
| chenying | yuval: So the uid of pod in protectable response is useless. https://review.openstack.org/#/c/499047/4/karbor/services/protection/protectable_plugins/pod.py | 07:17 |
| yuval | chenying: I understand. Is there a problem using namespace + name? | 07:22 |
| yuval | chenying: get this: | 07:26 |
| yuval | Objectives for names and UIDs: | 07:26 |
| yuval | Uniquely identify (via a UID) an object across space and time. | 07:26 |
| yuval | Uniquely name (via a name) an object across space | 07:26 |
| yuval | chenying: name should be used and not uid | 07:27 |
| yuval | (taken from https://github.com/kubernetes/community/blob/master/contributors/design-proposals/identifiers.md ) | 07:27 |
| chenying | yuval: using namespace + name is better. The size of resource id field in datbase is only considering option. | 07:27 |
| yuval | chenying: let's change it then | 07:27 |
| yuval | chenying: not sure, but maybe there are validations protectable id to be like uuid | 07:27 |
| yuval | chenying: (which is not good) | 07:28 |
| chenying | yuval: As I know, there is not validations protectable id to be like uuid about the preotectable show api. | 07:29 |
| yuval | chenying: I said maybe, I'm not sure :) | 07:29 |
| chenying | yuval: So namespace + name will be used for pod resource_id in pod protectable plugin. | 07:30 |
| chenying | yuval: I will update the patch. | 07:30 |
| chenying | yuval: I find that there are much difference about concept design and api design between openstacl and k8s community. T.T | 07:32 |
| chenying | S/openstacl/openstack | 07:33 |
| yuval | chenying: yep, there are similiarities but also many dissimilarities | 07:33 |
| chenying | yuval: Using namespace + name as the resource_id of pod. There may be a problom in plan API. There are validations resource id to be like uuid. | 07:36 |
| chenying | yuval: The validations about resource_id is in karborclient. | 07:37 |
| chenying | ping yuval | 07:43 |
| chenying | yuval: Now only the proectable show api need the namespace and name as the api request, how about add some messages about it in karborclient. | 07:47 |
| chenying | yuval: We don't change the uid value as the resource id field for pod resouce. In karbor protection service, in pod protect plugins, we also can get the pod name and namepsace from the plan via the uid of this pod. | 07:49 |
| yuval | chenying: don't understand. What do you mean in "add some messages about it"? | 07:50 |
| yuval | chenying: can you take a look at: https://review.openstack.org/#/c/500449/ | 07:51 |
| chenying | yuval: OK. | 07:51 |
| chenying | yuval: Add add some messages about the pod protectable show api. Like "Pass the name of the pod as the protectable_id" | 07:55 |
| chenying | yuval: I worry about that changing the resource_id format of the pod will bring lots of change about karbor protection server not only the validations protectable id to be like uuid. | 07:57 |
| chenying | yuval: For example: | 07:57 |
| chenying | yuval: We can pass the pod name as the resource_id of protectable-show-instance cmd. | 07:57 |
| chenying | root@ubuntu:/opt# karbor protectable-list-instances OS::Kubernetes::Pod | 07:58 |
| chenying | +--------------------------------------+---------------------+--------------+---------------------+----------------------------+ | 07:58 |
| chenying | | Id | Type | Name | Dependent resources | Extra info | | 07:58 |
| chenying | +--------------------------------------+---------------------+--------------+---------------------+----------------------------+ | 07:58 |
| chenying | | 128caf07-9124-11e7-a930-fa163e18e097 | OS::Kubernetes::Pod | busybox-test | [] | {u'namespace': u'default'} | | 07:58 |
| chenying | +--------------------------------------+---------------------+--------------+---------------------+----------------------------+ | 07:58 |
| chenying | root@ubuntu:/opt# karbor protectable-show-instance OS::Kubernetes::Pod | 07:58 |
| chenying | usage: karbor protectable-show-instance | 07:58 |
| chenying | [--parameters [<key=value> [<key=value> ...]]] | 07:58 |
| chenying | <protectable_type> <protectable_id> | 07:58 |
| chenying | karbor protectable-show-instance: error: too few arguments | 07:58 |
| chenying | root@ubuntu:/opt# karbor protectable-show-instance OS::Kubernetes::Pod busybox-test | 07:58 |
| chenying | +---------------------+--------------------------------------+ | 07:58 |
| chenying | | Property | Value | | 07:58 |
| chenying | +---------------------+--------------------------------------+ | 07:58 |
| chenying | | dependent_resources | [] | | 07:58 |
| chenying | | extra_info | {u'namespace': u'default'} | | 07:58 |
| chenying | | id | 128caf07-9124-11e7-a930-fa163e18e097 | | 07:58 |
| chenying | | name | busybox-test | | 07:58 |
| chenying | | type | OS::Kubernetes::Pod | | 07:58 |
| chenying | +---------------------+--------------------------------------+ | 07:58 |
| chenying | S/server/service | 07:59 |
| yuval | why the id is 128caf07-9124-11e7-a930-fa163e18e097 and not "default:busybox-test"? | 08:00 |
| chenying | yuval: Now the implementation of the protectable plugin has not been changed[1]. https://review.openstack.org/#/c/499047/4/karbor/services/protection/protectable_plugins/pod.py | 08:02 |
| chenying | yuval: I worry about that changing the resource_id format of the pod will bring lots of change about karbor protection server not only the validations protectable id to be like uuid. | 08:02 |
| yuval | chenying: like what? | 08:04 |
| chenying | yuval: Or skip the validations resource id to be like uuid about the pod resource firstly? I know there are some validations resource id about plan API. | 08:06 |
| yuval | chenying: if we don't allow names as uuid, is there another way? | 08:07 |
| chenying | yuval: In karbor protection service, in pod protect plugins, we also can get the pod name and namepsace from the plan via the uid of this pod. | 08:08 |
| yuval | chenying: I have to go, be back later | 08:09 |
| yuval | chenying: sorry | 08:09 |
| chenying | yuval: When will you come back? We can discuss it then. | 08:09 |
| yuval | chenying: ~2 hours | 08:10 |
| chenying | yuval: sure. | 08:10 |
| *** yamamoto has quit IRC | 08:35 | |
| *** edisonxiang has joined #openstack-karbor | 08:44 | |
| *** yamamoto has joined #openstack-karbor | 08:46 | |
| jiaopengju | ping edisonxiang | 08:49 |
| edisonxiang | jiaopengju: hey | 08:56 |
| jiaopengju | edisonxiang: I’m trying to fix a bug in dashborad: “checkpoints listing”. But I don’t know where prev_marker = self.request.GET.get( | 08:58 |
| jiaopengju | tables.CheckpointsTable._meta.prev_pagination_param, None) was initialized. | 08:58 |
| jiaopengju | the code is in checkpoints/views.py | 08:59 |
| *** yamamoto has quit IRC | 08:59 | |
| jiaopengju | edisonxiang: the code is in checkpoints/views.py | 08:59 |
| edisonxiang | jiaopengju: OK. Good Catch. I will check it and response to you. | 09:00 |
| jiaopengju | edisonxiang: thank you | 09:00 |
| jiaopengju | edisonxiang: I want to find where the valume of prev_pagination_param was seted. | 09:01 |
| jiaopengju | s/valume/value/ | 09:01 |
| edisonxiang | understood | 09:02 |
| *** yamamoto has joined #openstack-karbor | 09:11 | |
| *** yamamoto has quit IRC | 09:13 | |
| jiaopengju | edisonxiang: you can see the bug description here https://bugs.launchpad.net/karbor-dashboard/+bug/1714909 | 09:14 |
| openstack | Launchpad bug 1714909 in karbor-dashboard "Previous page in checkpoints pagination not work " [Undecided,In progress] - Assigned to jiaopengju (pj-jiao) | 09:14 |
| edisonxiang | thanks | 09:15 |
| openstackgerrit | Merged openstack/karbor master: Add kubernetes client to Karbor https://review.openstack.org/498779 | 09:20 |
| *** liujiong has quit IRC | 09:35 | |
| *** liujiong has joined #openstack-karbor | 09:35 | |
| *** dixiaoli has quit IRC | 09:38 | |
| edisonxiang | hello jiaopengju | 09:45 |
| jiaopengju | hi edisonxiang | 09:45 |
| edisonxiang | "tables.CheckpointsTable._meta.prev_pagination_param" default value is "prev_marker" | 09:46 |
| edisonxiang | (Pdb) p tables.CheckpointsTable._meta.prev_pagination_param | 09:46 |
| edisonxiang | 'prev_marker' | 09:46 |
| jiaopengju | where to change it after the listing? | 09:47 |
| edisonxiang | you can set it at https://github.com/openstack/karbor-dashboard/blob/master/karbor_dashboard/checkpoints/tables.py#L137 | 09:49 |
| edisonxiang | like this https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/snapshots/tables.py#L196 | 09:50 |
| edisonxiang | the default value is "pre_marker". | 09:52 |
| edisonxiang | self.request.GET.get( | 09:52 |
| edisonxiang | tables.CheckpointsTable._meta.prev_pagination_param, None) this values is used for "sort" | 09:52 |
| jiaopengju | where to change ‘self.request.GET.get(‘pre_marker’)’ | 09:53 |
| jiaopengju | ? | 09:53 |
| edisonxiang | two chioces: asc or des (https://github.com/openstack/karbor-dashboard/blob/master/karbor_dashboard/api/karbor.py#L401) | 09:53 |
| edisonxiang | I think we did not use it | 09:54 |
| jiaopengju | https://github.com/openstack/karbor-dashboard/blob/master/karbor_dashboard/checkpoints/views.py#L137 | 09:55 |
| edisonxiang | the value is always none | 09:56 |
| edisonxiang | so line 146 is none too, https://github.com/openstack/karbor-dashboard/blob/master/karbor_dashboard/checkpoints/views.py#L146 | 09:56 |
| jiaopengju | no, if the length of the checkpoint list is more than 20, the valume will not be none | 09:56 |
| jiaopengju | I have tested it. | 09:57 |
| edisonxiang | :( | 09:57 |
| jiaopengju | So my doubt is who changes the prev_marker value here? | 09:58 |
| edisonxiang | i will send a snapshot to you | 09:59 |
| edisonxiang | please accept it | 10:00 |
| edisonxiang | I think when the user click the title colume, it will trigger it | 10:00 |
| jiaopengju | I cannot download it :( | 10:02 |
| edisonxiang | I send to your email box | 10:03 |
| edisonxiang | jiaopengju@cmss.chinamobile.com | 10:03 |
| jiaopengju | get it, thank you | 10:03 |
| edisonxiang | you are welcome | 10:03 |
| *** yamamoto has joined #openstack-karbor | 10:04 | |
| jiaopengju | I have some ideas now through your post links, I will try to find the reason later. | 10:04 |
| *** jiaopengju has quit IRC | 10:10 | |
| *** liujiong_lj has joined #openstack-karbor | 10:57 | |
| *** liujiong has quit IRC | 11:00 | |
| *** liujiong_lj has quit IRC | 11:44 | |
| openstackgerrit | chenying proposed openstack/karbor master: Add kubernetes pod protectable plugin to Karbor https://review.openstack.org/499047 | 11:50 |
| chenying | ping yuval | 11:50 |
| yuval | hey chenying | 11:50 |
| chenying | hi I have updated the pod protectable patch. Could you pleas review it? | 11:51 |
| chenying | yuval: I have thinked carefully about allowing the namespace+name as the the resource_id of the pod, we just need skip some validations resource id about pod in plan and restore API. I worry about it will bring other changes, it seem not. | 11:51 |
| yuval | chenying: we can not do selective validations | 11:52 |
| chenying | yuval: So dou you have any idea? | 11:52 |
| chenying | yuval: Or we delete the validations resource id to be like uuid | 11:53 |
| yuval | chenying: any implications for removing these validations | 11:53 |
| yuval | ? | 11:53 |
| chenying | yuval: By defaut, we think the resource are all from the openstack project, like cinder, nova, manila. So all these resouces in these project have a resouce id uuid like. | 11:55 |
| yuval | chenying: btw, what if the namespace + name are very very long? | 11:56 |
| chenying | yuval: But as you know, not only the resouce in openstack are supportted by karbor. We also need to conisder some resouces not in uuid like the pod in k8s. | 11:56 |
| yuval | chenying: I have another idea | 11:57 |
| yuval | chenying: make the uuid some kind of hash of the namespace + name, and add the detailed namespace and name in extra_info | 11:57 |
| yuval | chenying: therefor the uuid is the same if namespace + name is the same, and we don't need to change the db | 11:57 |
| yuval | chenying: makes sense? | 11:58 |
| chenying | yuval: The namespace have already in the extra_info. | 11:58 |
| chenying | yuval: make the uuid some kind of hash of the namespace + name. ---I am not very clear about it. | 11:58 |
| chenying | yuval: make the uuid some kind of hash of the namespace + name----- what is the difference with just using the uid of the pod? | 11:59 |
| yuval | chenying: uuid of pod might change over time | 11:59 |
| chenying | yuval: As you know, we don't really use the uid in karbor. we just use the namespace and the name in karbor service. here uid just a symbol. | 12:00 |
| chenying | yuval: Even the uid of pod is changed in k8s. We also can get the pod using the namepsace +name form karbor. | 12:01 |
| yuval | chenying: but that means the same pod over time might show as two different resources | 12:02 |
| yuval | chenying: if we add one pod to the plan, it might have a different uuid later | 12:02 |
| yuval | chenying: not good for the user | 12:02 |
| yuval | chenying: if we create a uuid-like string which comprises of a hash of the name+namespace, it is unique | 12:02 |
| chenying | yuval: if we add one pod to the plan, it might have a different uuid later--- we just only add the uid to plan, we also can add namespace+ name to the resouce in plan. The uid of pod will never be used by karbor. just a symbol. | 12:04 |
| chenying | we not only add the uid to plan | 12:04 |
| yuval | chenying: we need to keep this invariant: same pod = same karbor id | 12:04 |
| chenying | yuval: a uuid-like string which comprises of a hash of the name+namespace ---- can we parse the namespace and name value from this a uuid-like hash string? | 12:07 |
| chenying | yuval: not only the uid of the pod, even the a uuid-like hash string which comprises of a hash of the name+namespace. They are all can not used for getting pod from k8s. Only the namespace and name can be used for getting pod form K8S. | 12:11 |
| chenying | yuval: They are all can not used for getting pod from k8s directly. | 12:11 |
| chenying | yuval: ? | 12:14 |
| chenying | yuval: You mean that want to keep invariant: a pod with same namespace and name = same resouce id (uuid) in karbor plan? even this uuid is not used for getting pod from k8s? | 12:17 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/karbor master: Updated from global requirements https://review.openstack.org/500004 | 12:17 |
| chenying | ping yuval | 12:20 |
| yuval | chenying: we can't parse it from the hash, but it will be in the extra_info | 12:24 |
| yuval | chenying: look, two things, which must be together: 1) keep the namespace AND name in extra_info 2) the pod id will be a uuid-like hash of the name+namespace | 12:24 |
| chenying | yuval: 1) keep the namespace AND name in extra_info ---when we design the extra_info for protectable resouce, we limit that the extra_info can not be used in karbor protection service. It is only used for showing the detail of resocuce. | 12:26 |
| chenying | yuval: How about add namespace+name to the name filed of resouce? So that it can be used in workflow and plugin of karbor. | 12:27 |
| yuval | chenying: what do you mean they are not used in the protection service? | 12:32 |
| yuval | chenying: do you mean that you can not access them in protect/restore ops? | 12:32 |
| chenying | yuval: Yes. | 12:33 |
| yuval | chenying: any problem changing that? | 12:33 |
| chenying | yuval: The extra_info can not be accessed. | 12:33 |
| yuval | chenying: any problem changing that? | 12:33 |
| chenying | yuval: :/ | 12:34 |
| yuval | chenying: what? | 12:34 |
| yuval | chenying: can we make extra_info accessible to protect/restore? | 12:35 |
| chenying | yuval: Yes It can be changed. Another idea is that adding namespace+name to the name filed of resouce. | 12:35 |
| yuval | chenying: well, that's ok, but we still have to make the id of the resource unique | 12:35 |
| yuval | chenying: so that id resource1 == resource2, resource1.id == resource2.id | 12:36 |
| yuval | chenying: and if resource1 != resource2, resource1.id != resource2.id\ | 12:36 |
| chenying | yuval: OK 1) adding namespace+name to the name filed of resouce. 2) the pod id will be a same uuid-like hash of the same name+namespace | 12:36 |
| yuval | chenying: sounds good? | 12:37 |
| yuval | chenying: sounds good to me | 12:37 |
| chenying | yuval: One problem about protectable-show-instance cmd. | 12:39 |
| yuval | chenying: ? | 12:39 |
| chenying | root@ubuntu:/opt# karbor protectable-show-instance OS::Kubernetes::Pod | 12:39 |
| chenying | usage: karbor protectable-show-instance | 12:39 |
| chenying | [--parameters [<key=value> [<key=value> ...]]] | 12:39 |
| chenying | <protectable_type> <protectable_id> | 12:39 |
| yuval | whats the problem? | 12:40 |
| chenying | yuval: This cmd, only pass the protectable_id of the pod, we can not get the pod from this api. | 12:40 |
| yuval | chenying: what are the parameters for? | 12:40 |
| chenying | yuval: we may need pass the name and namsspace from the parameters. | 12:40 |
| yuval | chenying: if that solution is not good, we'll have to make the id not be uuid, but name+namespace | 12:42 |
| chenying | yuval: if that solution is not good----- do you think there are something that we have not considered? | 12:45 |
| yuval | chenying: resource graph for protect | 12:45 |
| chenying | yuval: the uuid is unique and the name field (namespace+name) is unique. I think the resouce graph is OK. | 12:46 |
| openstackgerrit | chenying proposed openstack/karbor master: Add kubernetes pod protectable plugin to Karbor https://review.openstack.org/499047 | 13:21 |
| chenying | ping yuval | 13:22 |
| chenying | yuval: According to our discussion, the pod protectable patch has been updated. Could you please review it? | 13:22 |
| chenying | yuval: I will test the resouce graph of protect/restore with pod resouces tomorrow. | 13:23 |
| *** jiaopengju has joined #openstack-karbor | 13:24 | |
| chenying | yuval: http://paste.openstack.org/show/620338/ The uuid is unique and same from get and list api about the pod. | 13:32 |
| yuval | chenying: looks good | 13:40 |
| chenying | yuval In the later patch, I will test the resouce graph of protect/restore ASAP. | 13:42 |
| *** jiaopengju has quit IRC | 15:33 | |
| *** gouthamr has joined #openstack-karbor | 15:37 | |
| *** gouthamr has quit IRC | 18:19 | |
| *** gouthamr has joined #openstack-karbor | 18:20 | |
| *** zhonghua has joined #openstack-karbor | 18:32 | |
| *** zhonghua2 has quit IRC | 18:35 | |
| *** dims has quit IRC | 18:44 | |
| *** dims has joined #openstack-karbor | 18:47 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!