| *** jiaopengju has joined #openstack-karbor | 00:31 | |
| *** zhurong has quit IRC | 01:28 | |
| *** liujiong has joined #openstack-karbor | 01:51 | |
| *** yamamoto has joined #openstack-karbor | 02:38 | |
| *** zhurong has joined #openstack-karbor | 02:39 | |
| *** yamamoto has joined #openstack-karbor | 02:43 | |
| openstackgerrit | chenying proposed openstack/karbor master: Spec: Add Quotas to Karbor https://review.openstack.org/496579 | 03:24 |
|---|---|---|
| openstackgerrit | chenying proposed openstack/karbor master: Spec: Add Quotas to Karbor https://review.openstack.org/496579 | 03:45 |
| *** lihi has joined #openstack-karbor | 06:16 | |
| jiaopengju | ping yuval chenying | 06:51 |
| yuval | ping jiaopengju | 07:34 |
| jiaopengju | hi yuval, I saw your comments about the network conflict patch | 07:35 |
| jiaopengju | The network protection plugin is orthogonal to the server protection plugin. It protects and restores the network topology. If you do not wish to protect or restore the network topology, don't protect it. — what do you think about adding a mechanism to avoid network conflict? | 07:37 |
| yuval | jiaopengju: which kind of mechanism have you thought about? | 07:41 |
| jiaopengju | yuval: as I write in the comments, network resource is not very similar with glance image or cinder volume. So before the restore, we should check if the live resources are conflict with the backup data. | 07:43 |
| yuval | jiaopengju: fair enough. and if there is a conflict? | 07:44 |
| jiaopengju | yuval: IMO, if there is a conflict, no need to do the restore. | 07:45 |
| yuval | jiaopengju: currently, the network protectable includes not only neutron networks, but also subnets, routers, security groups, etc | 07:46 |
| jiaopengju | yuval: yes, I saw that | 07:46 |
| yuval | jiaopengju: some of these may be changed, deleted, or added in relation to the protected network | 07:47 |
| yuval | jiaopengju: that means that we need to do 'contextual' restore - understand which were deleted, which were added, and resolve the diff between changed resources | 07:47 |
| yuval | jiaopengju: that's something we shouldn't do without the user | 07:47 |
| yuval | jiaopengju: I can understand if your argument is to split the network protectable into 'networks', 'routers', 'security groups', etc | 07:48 |
| yuval | jiaopengju: however, there are down sides to that as well | 07:48 |
| jiaopengju | yuval: I mean that we only restore the changed network resources. If the resources are not changed, we just keep it. | 07:50 |
| yuval | jiaopengju: what if I changed the dhcp server on a subnet? or the default gateway? or the dns? how can you resolve the changes? | 07:52 |
| yuval | jiaopengju: since you can't understand the intent of the user in this case, the only way is to offer the merge conflict to the user to resolve as done in get merge conflict, for example | 07:52 |
| yuval | jiaopengju: and that's something we wouldn't like to do | 07:53 |
| yuval | *in merge conflict | 07:53 |
| yuval | *in git merge conflict | 07:53 |
| chenying | hi jiaopengju | 07:53 |
| jiaopengju | yuval: We can check the subnet information. For example, a user have a subnet s1, he do the backup, then change the subnet to s11. Now if he do the restore, karbor need to create a new subnet same as s1. | 07:56 |
| jiaopengju | hi chenying | 07:56 |
| yuval | jiaopengju: do you suggest merging the conflict using the resources' names? | 07:57 |
| chenying | I try to get what you talk about. | 07:57 |
| yuval | chenying: restoring a network (including subnets, routers, sgs) where the network is already there | 07:58 |
| yuval | chenying: there are probably ip addresses conflicts | 07:58 |
| yuval | jiaopengju: how about when restoring the network, give parameters for each subnet, in order to create them with different addresses? | 07:59 |
| jiaopengju | yuval: currently, we use same resources’ names if we do a restore | 07:59 |
| yuval | jiaopengju: we can make the restore parameters dynamic per resource | 07:59 |
| yuval | jiaopengju: I think.. | 08:02 |
| jiaopengju | yuval: “in order to create them with different addresses”, we can’t know what addresses that the users want to use. Or in other words, if we give a new addresses, but users do not want to use them. | 08:02 |
| yuval | jiaopengju: that's why I'm talking about letting the user choose using parameters | 08:02 |
| chenying | yuval jiaopengju Most of time, we think that the usecase of restoring the network resource is that restoring the whole network topology to a new site. So all the resoure including the subnets, routers, security groups is one resource type. | 08:03 |
| chenying | yuval jiaopengju: So about the possible ip addresses conflicts, what are your oppions about it? | 08:03 |
| yuval | chenying: jiaopengju: also, maybe a user doesn't want the restore to interfere with a running production deployment | 08:04 |
| chenying | yvual: maybe a user doesn't want the restore to interfere with a running production deployment. -----IMO, in this usecase the user may don't need to restore the whole network topology. | 08:06 |
| jiaopengju | yuval chenying: the ip conflicts only occurs when users do the restore more than one times. | 08:06 |
| yuval | jiaopengju: are you familiar with the restore parameters? | 08:06 |
| jiaopengju | yuval: not very familiar with them, I just use them by default. | 08:09 |
| jiaopengju | yuval: and found this issue with using dashboard | 08:09 |
| chenying | jiaopengju yuval: yuval Do you mean that when user restoring a server, user can pass some value like the ip address with the restore parameters? | 08:09 |
| yuval | chenying: yes, and when restoring a network, the user can decide subnet range | 08:10 |
| chenying | jiaopengju: the ip conflicts only occurs when users do the restore more than one times. The reason is that the value about some resource will be checked about when creating a new one like cidr? | 08:12 |
| jiaopengju | chenying: yes | 08:13 |
| chenying | yvual: By default the network plugins is retoring the whole network topology belong to one tenant. We may think about this usecase: when restore a server, the network resource also the sub resource of server. We also need restoring the whole network topology as the sub resource? | 08:17 |
| chenying | yuval: The parent resource types of network are SERVER_RESOURCE_TYPE, PROJECT_RESOURCE_TYPE. The network plugin do the same thing when as a independent resoure of a project or the sub resource of a server. | 08:19 |
| jiaopengju | chenying yuval: IMO, when users doing server backup with network, they just want to use the same ip address or make the restore server in same ip range with the backup one. So we may not need to backup the whole network topology. | 08:19 |
| yuval | jiaopengju: why would you protect the network topology then? you can protect the server and on restore attach it to the existing network | 08:20 |
| yuval | chenying: do you suggest making the network protectable's parent only project? | 08:20 |
| chenying | yuval jiaopengju: The network plugin is retoring the whole network topology belong to one tenant. so we don't need restore a new whole network topology when restoring a server. | 08:21 |
| chenying | yuval: Yes | 08:21 |
| yuval | chenying: interesting | 08:21 |
| chenying | jiaopengju: Why jiaopengju get some error about conflicts. Because the network is the sub resource of server. When restoring the server for several times, the network topology will be restoring every time. The restore task about subresore network of the server will be created automatically by workflow of karbor. | 08:25 |
| yuval | chenying: well, you don't have to protect the network | 08:26 |
| chenying | jiaopengju yuval: So in this usecase, we don't need restoring the whole network topology every time. | 08:26 |
| yuval | chenying: I don't agree with that conclusion | 08:26 |
| yuval | we can not resolve a 'merge conflict' on resources, including network | 08:26 |
| chenying | yuval: When user explicitly add the network resource to the plan. | 08:27 |
| jiaopengju | yuval: Maybe because I’m not very familar with karbor dashboard. when I doing the backup in the dashboard, I found two network options，one outside the server resource, one in the server resource. So I choice the server resource (contains image and network) | 08:27 |
| chenying | yuval I don't think this is the problom about the conflict. The network resource as the whole network topology about a project being one subresource of a (every) server is not unreasonable. | 08:28 |
| yuval | chenying: alright, I agree with removing the server -> network dependency | 08:29 |
| yuval | chenying: also, as jiaopengju, it maybe very confusing for resources that have more than 1 dependency (i.e volume depends on server and project, etc) | 08:30 |
| yuval | chenying: maybe for usability, if a volume is attached, show it only below the server | 08:30 |
| yuval | chenying: that requires more thinking in the case of image and network | 08:31 |
| chenying | yuval why would you protect the network topology then? you can protect the server and on restore attach it to the existing network ------------I agree with you, when user resore one server, he only need care about the network about itself. | 08:32 |
| yuval | chenying: any possible implications if we remove the server -> network dependency? | 08:33 |
| chenying | yuval jiaopengju maybe for usability, if a volume is attached, show it only below the server---- sound good. | 08:33 |
| jiaopengju | yuval chenying agree | 08:34 |
| chenying | yuval jiaopengju any possible implications if we remove the server -> network dependency? -----NO. | 08:35 |
| yuval | chenying: can't think of any as well | 08:35 |
| yuval | chenying: let's do it | 08:35 |
| chenying | jiaopengju: After remove the server -> network dependency, do you have any other questions about restoring the network of a server? | 08:37 |
| jiaopengju | chenying yuval: we should do a tenant filter for admin users | 08:37 |
| jiaopengju | chenying yuval: Command 'neutron net-list' or 'openstack network list' seems return all tenants' net info when using admin tenant | 08:38 |
| yuval | jiaopengju: currently the network protection plugin protects all the networks, including admin? | 08:38 |
| chenying | jiaopengju yuval: IMO, the netwokr being filtered by a tenant is needed. | 08:38 |
| yuval | chenying: yes, very important | 08:39 |
| jiaopengju | yuval: I mean that, I did this test with admin user and found all tenants network info were included. | 08:39 |
| yuval | jiaopengju: that's a bug | 08:40 |
| chenying | yuval: Yes, by default the neutron network get method is not filtered by the tennet. | 08:40 |
| chenying | so jiaopengju, you could fix it. | 08:40 |
| jiaopengju | chenying ok | 08:40 |
| yuval | found the issue | 08:41 |
| jiaopengju | yuval chenying: thank you very much for your suggestions. | 08:41 |
| yuval | jiaopengju: probably need to pass 'project_id' in 'args' in clients/neutorn.py | 08:41 |
| yuval | jiaopengju: maybe | 08:42 |
| chenying | jiaopengju You are welcome. Passing the 'project_id' to the neutron client net-list methlod maybe can solve the problem. | 08:43 |
| jiaopengju | chenying yuval: I wll try | 08:43 |
| yuval | jiaopengju: seems like some other clients are not doing it, so if you fix it, it could be nice if you fix it for them as well | 08:44 |
| jiaopengju | yuval: :) | 08:44 |
| chenying | yuval jiaopengju: As I know, by dafault the resouces in nova/cinder/manial are filtered by the tenant. : ) | 08:46 |
| jiaopengju | chenying: yes | 08:47 |
| chenying | yuval: Are you free now? | 08:47 |
| yuval | chenying: no, I'll be available later | 09:31 |
| *** liujiong has quit IRC | 09:59 | |
| *** jiaopengju has quit IRC | 10:20 | |
| *** yamamoto has quit IRC | 11:15 | |
| *** yamamoto has joined #openstack-karbor | 11:16 | |
| *** yamamoto has joined #openstack-karbor | 11:31 | |
| *** zhurong has quit IRC | 12:23 | |
| *** gouthamr has quit IRC | 12:24 | |
| *** jiaopengju has joined #openstack-karbor | 12:37 | |
| *** gouthamr has joined #openstack-karbor | 12:45 | |
| openstackgerrit | Yuval Brik proposed openstack/karbor master: Neutron: create client with project from context https://review.openstack.org/498462 | 13:37 |
| openstackgerrit | Pengju Jiao proposed openstack/karbor master: Remove network dependency of server resource https://review.openstack.org/498255 | 14:13 |
| *** jiaopengju has quit IRC | 14:58 | |
| openstackgerrit | melissaml proposed openstack/karbor master: Fix to use "." to source script files https://review.openstack.org/498522 | 16:52 |
| *** lihi has quit IRC | 18:11 | |
| *** yamamoto has quit IRC | 21:09 | |
| *** gouthamr has quit IRC | 21:23 | |
| *** yamamoto_ has joined #openstack-karbor | 21:38 | |
| *** yamamoto_ has quit IRC | 22:04 | |
| *** yamamoto_ has joined #openstack-karbor | 22:35 | |
| *** yamamoto_ has quit IRC | 22:43 | |
| *** yamamoto_ has joined #openstack-karbor | 22:49 | |
| *** yamamoto_ has quit IRC | 22:59 | |
| *** yamamoto_ has joined #openstack-karbor | 23:06 | |
| *** yamamoto_ has quit IRC | 23:47 | |
| *** gouthamr has joined #openstack-karbor | 23:53 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!