| *** tonanhngo has quit IRC | 00:01 | |
| *** tonanhngo has joined #openstack-kuryr | 00:06 | |
| *** tonanhngo has quit IRC | 00:10 | |
| *** diogogmt has quit IRC | 00:15 | |
| *** tonanhngo has joined #openstack-kuryr | 00:39 | |
| *** hongbin has quit IRC | 00:52 | |
| *** limao has joined #openstack-kuryr | 00:54 | |
| *** diogogmt has joined #openstack-kuryr | 01:13 | |
| *** yamamoto_ has joined #openstack-kuryr | 01:47 | |
| *** hongbin has joined #openstack-kuryr | 03:22 | |
| *** yamamoto_ has quit IRC | 03:26 | |
| *** yedongcan has joined #openstack-kuryr | 03:34 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/fuxi: Updated from global requirements https://review.openstack.org/373745 | 03:46 |
|---|---|---|
| openstackgerrit | OpenStack Proposal Bot proposed openstack/kuryr: Updated from global requirements https://review.openstack.org/411063 | 03:48 |
| *** yamamoto_ has joined #openstack-kuryr | 04:08 | |
| *** saneax-_-|AFK is now known as saneax | 04:46 | |
| *** tonanhngo has quit IRC | 04:56 | |
| *** hongbin has quit IRC | 05:10 | |
| *** saneax is now known as saneax-_-|AFK | 05:12 | |
| *** saneax-_-|AFK is now known as saneax | 05:17 | |
| *** irenab_ has joined #openstack-kuryr | 05:25 | |
| *** tonanhngo has joined #openstack-kuryr | 05:38 | |
| openstackgerrit | Dongcan Ye proposed openstack/kuryr-libnetwork: Fix misleading info in CreateNetwork https://review.openstack.org/411115 | 05:41 |
| openstackgerrit | Ilya Chukhnakov proposed openstack/kuryr-kubernetes: [DRAFT] devref: binding drivers https://review.openstack.org/411116 | 05:42 |
| ivc_ | irenab irenab_ apuimedo vikasc FYI very early devref draft about binding drivers for Kuryr-K8s: https://review.openstack.org/#/c/411116/ | 05:45 |
| vikasc | thanks ivc_ | 05:46 |
| vikasc | ivc_, there are two points regarding binding driver porting patch: | 05:47 |
| vikasc | 1. osvif.plug is not needed to be called for nested-container interfaces eg. vlan | 05:48 |
| vikasc | 2. For passing binding info for a vlan interface, as we discussed yesterday, there is no specific vif type in os-vif. I was thinking to use VIFBridge only somehow. | 05:49 |
| vikasc | VIFBridge has variables for all details except vlanid | 05:49 |
| ivc_ | vikasc yeah that 'draft' specifically mentions several times that we only need NOOPPlugin for os-vif :) | 05:50 |
| ivc_ | vikasc no, pls dont use VIFBridge | 05:50 |
| vikasc | ivc_, i dont think plugn is required in os-vif for vlan case for plug() is not needed | 05:50 |
| ivc_ | it has nothing to do with bridge and that would be confusing | 05:50 |
| ivc_ | vikasc well we want to keep it generic, don't we? if you set VIF.plugin to "noop" and implement a NOOPPlugin, you don't have to care about it | 05:51 |
| ivc_ | and by 'implement' i mean ... just subclass and define some empty "pass" methods (you only need to implement 'describe') | 05:52 |
| vikasc | ivc_, i havent gone through your draft yet | 05:53 |
| vikasc | ivc_, but i agree with your generic point. | 05:53 |
| ivc_ | vikasc take a look, it is essentially a how-to | 05:54 |
| vikasc | ivc_, i am just thinking can i avoid creating a new vif type in os-vif | 05:54 |
| ivc_ | vikasc why? | 05:54 |
| vikasc | ivc_, it would add an extra delay for the change in os-vif to get merged | 05:55 |
| ivc_ | vikasc it's just one type you define in kuryr_kubernetes.objects | 05:55 |
| ivc_ | vikasc it does not need to go to os-vif | 05:55 |
| ivc_ | vikasc we define it in our repo, just use os_vif.VIFBase for a base class | 05:56 |
| vikasc | ivc_, ok ok.. got it | 05:56 |
| ivc_ | :) | 05:56 |
| vikasc | ivc_, :) thanks | 05:56 |
| ivc_ | vikasc it might look complicated at first, but it's all quite simple in fact | 05:57 |
| ivc_ | just not everything documented... yet :) | 05:57 |
| vikasc | ivc_, would you mind if i rework my patch as per your "how-to" | 05:58 |
| ivc_ | vikasc why would i? :) | 05:58 |
| vikasc | ivc_, great ! | 05:58 |
| vikasc | :) | 05:58 |
| vikasc | ivc_, let me go through it and will get back | 05:59 |
| ivc_ | vikasc ping me if you find something confusing or not quite clear (it might be the case as its just a draft/some scraps) | 05:59 |
| vikasc | ivc_, sure | 05:59 |
| vikasc | ivc_, thanks | 06:00 |
| ivc_ | vikasc np :) | 06:01 |
| irenab_ | ivc_, thanks for sharing, checking it now | 06:03 |
| irenab_ | ivc_, one point that I was thinking is that with ov_vif we are limiting the options to aoly the interfaces that are supported by ov_vif | 06:05 |
| ivc_ | irenab_ nope we do not :) | 06:05 |
| ivc_ | irenab_ we can define our own types | 06:05 |
| ivc_ | irenab_ in kuryr_kubernetes.objects | 06:06 |
| ivc_ | irenab_ there's one thing about os-vif you can find in that 'devref draft' - it literally does almost nothing outside of 'ovs-hybrid' case | 06:07 |
| irenab_ | ivc_, still will require new code to be added | 06:07 |
| ivc_ | irenab_ we can have NOOPPlugin that does nothing and can use it for most cases i think | 06:07 |
| ivc_ | irenab_ and we'll need to define the VIF model anyway to store data | 06:08 |
| irenab_ | ivc_, correct, but if its not something too coupled with vif type, then it can serve different options without adding new object | 06:09 |
| ivc_ | irenab_ what do you mean? | 06:10 |
| irenab_ | that we probably can make Controller part generic with regards to vif_type | 06:11 |
| ivc_ | irenab_ we can't. only controller knows what kind of port it created | 06:11 |
| irenab_ | and the binding driver can adjust object to its case | 06:12 |
| ivc_ | think about trunk/sub ports | 06:12 |
| ivc_ | you can't bind with OVS binding driver into linuxbridge port | 06:13 |
| irenab_ | but we can propogate vif_type to the CNI | 06:13 |
| ivc_ | my point is that the port and the binding driver are tied together | 06:13 |
| ivc_ | propagate how? | 06:13 |
| irenab_ | metadata | 06:14 |
| ivc_ | CNI.json? | 06:14 |
| irenab_ | annotation | 06:14 |
| irenab_ | lets say we want to add support for new neutron backend | 06:15 |
| ivc_ | well we already using annotation | 06:15 |
| ivc_ | yes, for new backend you need a binding driver, right? | 06:15 |
| ivc_ | that binding driver requires some sort of information | 06:15 |
| ivc_ | so we need to keep that information somewhere right? | 06:16 |
| ivc_ | and thats why we use VIF objects - they have 'type', common part (see VIFBase) and driver-specific parts (see VIFBridge or VIFOpenVSwitch) | 06:17 |
| ivc_ | am i missing something? | 06:17 |
| * ivc_ might be as he have not slept today | 06:18 | |
| ivc_ | irenab_ oh and the Controller part is generic in regards to Neutron client use (thus the Generic in GenericPodVIFDriver as it is equivalent to neutron port-create and allows neutron to fill needed vif_details with backend-specific data) | 06:20 |
| ivc_ | irenab_ so only the 'vif_translator' is needed to convert neutron port data into VIF object | 06:21 |
| irenab_ | ivc_, give a min to read, was distracted to some office disscussion | 06:22 |
| irenab_ | ivc_, yes, so we have to deal with translation to add support to new vif type, and this is not pluggable | 06:23 |
| ivc_ | irenab_ it is pluggable :) | 06:23 |
| ivc_ | :P | 06:24 |
| irenab_ | sort of .. now the translation is in ovs_vif_utils | 06:24 |
| ivc_ | yes, but it is called through stebedore driver | 06:25 |
| ivc_ | irenab_ https://github.com/openstack/kuryr-kubernetes/blob/master/setup.cfg | 06:25 |
| ivc_ | look for 'kuryr_kubernetes.vif_translators' | 06:26 |
| ivc_ | irenab_ also, the VIF type is directly mapped to the binding driver in 'kuryr_kubernetes.cni.binding' | 06:26 |
| irenab_ | so for adding new vif type, it looks like need either modify or add new vif_translator + binding driver | 06:27 |
| ivc_ | irenab_ i'd say to add a binding driver you most likely need a new VIFType+translator | 06:28 |
| irenab_ | ivc_, I think its just the matter who is doing the translation. Currently its up to controller | 06:29 |
| ivc_ | irenab_ yes, because only controller knows what kind of port it created | 06:30 |
| ivc_ | if you move it to cni (why?), you'd have to pass some additional info | 06:30 |
| irenab_ | ivc_, its true only for trunk/regular, vif_type is determined by neutron | 06:30 |
| ivc_ | right now for cni part you only need a driver | 06:30 |
| ivc_ | irenab_ what exactly do you suggest | 06:32 |
| irenab_ | ivc_, just thinking for now. Maybe we can delegate the neutron port -> VIF translation to CNI | 06:33 |
| irenab_ | so when we want to support new vif_type, changes are only for one component | 06:34 |
| irenab_ | when we have CNI Daemon | 06:34 |
| irenab_ | ivc_, not something to change now, lets see how the new types additions go | 06:35 |
| ivc_ | irenab_ but that means storing neutron-client port dict in annotation | 06:39 |
| ivc_ | irenab_ and thats one thing i don't like | 06:40 |
| ivc_ | irenab_ also regarding 'changes for one component' - the component is kuryr-kubernetes (or kuryr-lib eventually) so it is still one component | 06:41 |
| irenab_ | ivc_, maybe we can have generic vif annotation, just not converted to specific type. It usually vif type and binding:vif_details that should be needed for binding | 06:42 |
| ivc_ | irenab_ and then you'd have to special-case trunk ports somehow | 06:42 |
| irenab_ | you are right about the trunk case, this will require different translation, then it sort of makes sense to modify controller | 06:43 |
| ivc_ | with current approach there's no special casing at all | 06:43 |
| ivc_ | VIF passed to CNI only contains the data necessary to perform binding | 06:45 |
| irenab_ | I understand this, its just matter of who is responsible for getting the needed data | 06:45 |
| irenab_ | in nova, its done by compute node? | 06:46 |
| irenab_ | or controller? | 06:46 |
| ivc_ | irenab_ neutron -> os.vif translation you mean? | 06:48 |
| irenab_ | yes | 06:48 |
| openstackgerrit | Merged openstack/kuryr: Links do not point to any document https://review.openstack.org/373014 | 06:51 |
| irenab_ | ivc_, devref is very good, just made me think about several places to modify to add new binding driver. | 06:52 |
| ivc_ | irenab_ afaik nova's computes do not talk directly to neutron, do they? | 06:52 |
| ivc_ | irenab_ what do you want to modify? | 06:53 |
| irenab_ | vif translator and then new/modified binding driver | 06:57 |
| ivc_ | irenab_ yup, thats just 2 things you need to add for ovs-native | 06:57 |
| ivc_ | irenab_ i've forgot to add the driver in 'howto' part but covered it in Components/VIF binding | 06:58 |
| ivc_ | irenab_ or not necessary ovs-native, but you mean dragonflow, right? | 06:59 |
| irenab_ | nothing specific, it can be any other supported neutron binding backend: midonet, iovisor, .. | 07:00 |
| irenab_ | dragonflow and ovn are ovs-native | 07:00 |
| ivc_ | irenab_ you mean anything that uses VIFOpenVSwitch? | 07:00 |
| irenab_ | yes | 07:01 |
| ivc_ | irenab_ i mean the VIFOpenVSwitch model fits all those backends, right? | 07:01 |
| ivc_ | so back to initial discussion regarding CNI/COntroller responsibilities, that means we'll have the same code in CNI and will only define different translators for different backends | 07:03 |
| ivc_ | i was hoping we can do so but was not certain | 07:03 |
| irenab_ | what do you mean by same code in CNI, same binding driver? | 07:04 |
| ivc_ | irenab_ yes, since the binding driver is directly mapped to VIF type | 07:05 |
| irenab_ | ivc_, yes, makes sense to have one ovs binding driver | 07:10 |
| ivc_ | cool | 07:11 |
| vikasc | irenab, ivc_ : write up makes sense to me and i am going to update my existing patch as per the mentioned approach and new vif type, 'vlan'. | 07:12 |
| vikasc | VIFDirect does not have 'vlan_id' and 'network' fields which are needed for passing required data for binding | 07:13 |
| ivc_ | vikasc pls note that 'network' field is present in all VIFs | 07:14 |
| irenab_ | vikasc, maybe vif_type should be nested_vlan | 07:15 |
| vikasc | ivc_, oops yes | 07:15 |
| ivc_ | vikasc its a feature of oslo.VersionedObject - you get all 'fields' of the parent class inherited in subclasses | 07:15 |
| vikasc | ivc_, its in base | 07:15 |
| ivc_ | irenab_ +1 was about to say the same. i'm not sure if it can be used with 'bare-metal' vlan or not | 07:16 |
| vikasc | nope | 07:16 |
| ivc_ | irenab_ but maybe it could and the only difference would be VIF.plugin | 07:16 |
| vikasc | intention was just to share about my view on native vif-type creation, had not given a thought on name | 07:17 |
| vikasc | +1 for nested_vlan | 07:17 |
| vikasc | ivc_, vlan_id still seems to be missing though | 07:18 |
| ivc_ | we can always rename it if it will work with hardware vlans | 07:18 |
| ivc_ | vikasc yes, you need to define your new type :P | 07:18 |
| vikasc | thanks irenab and ivc_ | 07:19 |
| *** janki has joined #openstack-kuryr | 07:22 | |
| openstackgerrit | Dongcan Ye proposed openstack/kuryr-libnetwork: [WIP] Delete kuryr-subnet in existing Neutron network https://review.openstack.org/411144 | 07:23 |
| ivc_ | irenab_ btw, does dragonflow use neutron's port binding extension (i.e. 'binding:host_id')? | 07:44 |
| vikasc | ivc_, what is your timezone btw | 07:50 |
| irenab_ | its ml2 driver, so must be supported | 07:50 |
| ivc_ | vikasc utc+3 | 07:50 |
| vikasc | ivc_, great! mine is utc + 5.30 | 07:51 |
| ivc_ | vikasc but my 'internal' timezone is kinda random :D | 07:51 |
| vikasc | ivc_, :D i read 'dint sleep today' | 07:52 |
| ivc_ | xD | 07:52 |
| *** tonanhngo has quit IRC | 07:54 | |
| yedongcan | apuimedo, vikasc, irenab_: Hi, could you help confirm this bug: https://bugs.launchpad.net/kuryr-libnetwork/+bug/1650130 | 07:57 |
| openstack | Launchpad bug 1650130 in kuryr-libnetwork "Can't delete subnetpool when deleting network" [Undecided,In progress] - Assigned to Dongcan Ye (hellochosen) | 07:57 |
| irenab_ | yedongcan, will check a bit later, currently at the meeting | 08:01 |
| *** tonanhngo has joined #openstack-kuryr | 08:02 | |
| ltomasbo | hi mchiappero, I updated the PS https://review.openstack.org/#/c/402462 | 08:04 |
| *** tonanhngo has quit IRC | 08:04 | |
| ltomasbo | and had to move some extra functionality from controller.py to the drivers | 08:04 |
| yedongcan | irenab_, thanks, not urgent | 08:05 |
| ltomasbo | due to the problem we discussed in previous versions of my PS | 08:05 |
| ltomasbo | could you please take a look | 08:05 |
| vikasc | yedongcan, it is because in delete-network, because it is pre-existing network, it is returning before deleting subnets. And when libnetwork asks neutron to delete subnetpool, it fails because that subnet is referring to it. | 08:14 |
| vikasc | yedongcan, Not sure but may be in delete_network, subnets deletion should happen even though network deletion is skipped for neutron pre-existing networks. Because this subnet was created by Kuryr, so it should be able to delete also and then subnetpool deletion will also succeed | 08:16 |
| yedongcan | vikasc, yes, so do we need to delete the subnet created by kuryr? | 08:17 |
| *** dimak has joined #openstack-kuryr | 08:18 | |
| vikasc | yedongcan, i think we should because Kuryr only created that | 08:18 |
| yedongcan | vikasc, Okay, got it. I had mark the kuryr created subnet as "kuryr-subnet", maybe we need to using tags as network, but it seems subnet doesn't support tags extension(not sure about it) | 08:20 |
| vikasc | yedongcan, can kuryr use existing subnets? | 08:22 |
| vikasc | yamamoto_, i mean the one that are not created by kuryr | 08:22 |
| vikasc | oops | 08:22 |
| vikasc | wrong nick | 08:22 |
| yamamoto_ | heh | 08:23 |
| vikasc | yamamoto_, sorry :) | 08:23 |
| yamamoto_ | np! | 08:23 |
| vikasc | yedongcan, i mean the one that are not created by kuryr | 08:23 |
| yedongcan | vikasc: not using it | 08:23 |
| vikasc | yedongcan, then i guess no need to think about tagging them | 08:24 |
| vikasc | yedongcan, we need tagging on networks because they can be pre-existed. do i make sense? | 08:24 |
| yedongcan | vikasc: yes, currently we only support using existing network | 08:25 |
| vikasc | yep | 08:25 |
| yedongcan | vikasc: thanks | 08:27 |
| vikasc | yedongcan, np ! | 08:27 |
| *** pcaruana has joined #openstack-kuryr | 08:37 | |
| ltomasbo | hi folks, I've been talking with yedongcan about a problem with ports not being deleted when removing the container if the net/subnet was created with neutron (after patch: https://review.openstack.org/#/c/401874/5/kuryr_libnetwork/controllers.py), and then use it in docker | 09:02 |
| ltomasbo | the main problem is the neutron subnet does not have any subnetpool associated | 09:03 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/kuryr: Updated from global requirements https://review.openstack.org/411063 | 09:04 |
| ltomasbo | and after the 'docker network create -d kuryr --ipam-driver=kuryr --subnet=10.0.10.0/24 --gateway=10.0.10.1 --o neutron.net.name=net10 kuryr-net10' | 09:04 |
| ltomasbo | the subnetpool is created but not included into the subnet | 09:04 |
| ltomasbo | there exists the limitation when subnets have same/overlapping cidr, and perhaps the pools need to be used | 09:05 |
| ltomasbo | but I understood that that was needed when you want to use the same network from dockers at different servers | 09:05 |
| ltomasbo | not for the first server using docker and joining an existing neutron network | 09:06 |
| ltomasbo | anyone knows if that is like this, are we always need to use the neutron.pool.name and -ipam-opt options when using an already existing neutron network? | 09:06 |
| limao | ltomasbo: hi | 09:06 |
| ltomasbo | hi limao | 09:06 |
| limao | "but I understood that that was needed when you want to use the same network from dockers at different servers" <-- I did not get this use case | 09:07 |
| ltomasbo | ok, let me re-phrase it | 09:07 |
| limao | ltomasbo: you mean you use etcd on different server with docker ? | 09:08 |
| ltomasbo | you have a controller and a couple of worker nodes in openstack | 09:08 |
| ltomasbo | and a neutron network, let's name it net0 | 09:08 |
| limao | ltomasbo: yeah | 09:08 |
| ltomasbo | if you want to create a couple of containers in that neutron network | 09:08 |
| ltomasbo | and one container is in compute-node1 | 09:09 |
| ltomasbo | and the other in compute-node2 | 09:09 |
| ltomasbo | then, in each one of those compute nodes you need to do: | 09:09 |
| ltomasbo | docker network create ... | 09:09 |
| ltomasbo | to be able to later do the | 09:09 |
| ltomasbo | docker run --net=net0 ... | 09:09 |
| limao | ltomasbo: wait a min, do you mean veth mode or macvlan mode? | 09:09 |
| ltomasbo | I discover this with vlan mode, but it is independent of that | 09:10 |
| ltomasbo | as I then tried to with veth mode and the same problem arise | 09:10 |
| ltomasbo | just using raw docker, no kubernetes or docker-swarm | 09:10 |
| limao | ltomasbo: ok | 09:11 |
| limao | ltomasbo: then you should use import neutron existed network | 09:11 |
| ltomasbo | with is with the -o option when using 'docker network create...'? | 09:12 |
| ltomasbo | or there is something else? | 09:12 |
| limao | Yes, https://github.com/openstack/kuryr/blob/master/doc/source/specs/existing-neutron-network.rst | 09:13 |
| limao | I was thought we should use etcd to store network info when you run docker+kuryr on multi-host | 09:14 |
| limao | then you only need to create network one time on any of the host node | 09:15 |
| *** roeyc has joined #openstack-kuryr | 09:15 | |
| limao | ltomasbo: I tested docker+kuryr with etcd before. I did not tested import neutron existed network on every node | 09:18 |
| limao | I think there would be problem maybe, because when you import neutron neutwork into docker, kuryr will update the tag of the neutron network | 09:19 |
| ltomasbo | regardless of the multi site node, where I agree the subpools needs to be use | 09:20 |
| ltomasbo | and the etcd would be nice | 09:20 |
| limao | limao: when you import it in second node, the tag will be overwrited by that node... it should will impact the first node | 09:20 |
| ltomasbo | the problem I'm facing is in a single node | 09:20 |
| ltomasbo | that was just the explanation for the text I did not explain properly | 09:20 |
| ltomasbo | what I'm facing is the next: | 09:20 |
| limao | ltomasbo :) | 09:20 |
| ltomasbo | create network and subnet with neutron | 09:20 |
| ltomasbo | then, I want to create a container in that netowrk | 09:21 |
| ltomasbo | I do the 'docker network create ....' | 09:21 |
| ltomasbo | with the -o neutron.net.name=net0 | 09:21 |
| ltomasbo | then, create the docker container with | 09:21 |
| ltomasbo | docker run -it --net=net0 ... | 09:21 |
| limao | ltomasbo: yeah | 09:22 |
| ltomasbo | that works, but, when I exit the container | 09:22 |
| ltomasbo | the neutron port created for the container is not removed | 09:22 |
| limao | ltomasbo: oh, then it should be bug... | 09:23 |
| ltomasbo | and I was wondering, if there is a need of include subnetpool option when triggering the | 09:23 |
| limao | ltomasbo: I tested with neutron.net.uuid , it should work in my mind. | 09:23 |
| ltomasbo | docker network create command | 09:23 |
| ltomasbo | the very same process works perfectly fine if the network is directly created by kuryr instead of already being created by neutron | 09:24 |
| *** garyloug has joined #openstack-kuryr | 09:24 | |
| ltomasbo | this is what I found in the logs when triggering the docker network create command: | 09:24 |
| ltomasbo | 2016-12-15 08:25:01.302 22269 INFO kuryr_libnetwork [-] Creating subnetpool with the given pool CIDR | 09:26 |
| ltomasbo | 2016-12-15 08:25:01.798 22269 WARNING kuryr_libnetwork [-] There is already existing subnet for the same cidr. Please check and specify pool name in Options. | 09:26 |
| ltomasbo | 2016-12-15 08:25:01.950 22269 INFO werkzeug [-] 127.0.0.1 - - [15/Dec/2016 08:25:01] "POST /IpamDriver.RequestPool HTTP/1.1" 200 - | 09:26 |
| ltomasbo | 2016-12-15 08:25:02.129 22269 INFO werkzeug [-] 127.0.0.1 - - [15/Dec/2016 08:25:02] "POST /IpamDriver.RequestAddress HTTP/1.1" 200 - | 09:26 |
| ltomasbo | 2016-12-15 08:25:02.638 22269 INFO kuryr_libnetwork [-] Using existing network None successfully | 09:26 |
| ltomasbo | 2016-12-15 08:25:02.761 22269 INFO werkzeug [-] 127.0.0.1 - - [15/Dec/2016 08:25:02] "POST /NetworkDriver.CreateNetwork HTTP/1.1" 200 - | 09:26 |
| ltomasbo | so, it seems you always needs to use the subnetpool option when the network is already existing | 09:27 |
| ltomasbo | just wanting to know if that is true or not | 09:27 |
| ltomasbo | and if that so, why? as kuryr actually automatically created a kuryrPool-xxx, why not using it right away | 09:28 |
| *** jchhatbar has joined #openstack-kuryr | 09:28 | |
| limao | ltomasbo: oh, wait a min , Let me find out the background | 09:30 |
| *** janki has quit IRC | 09:31 | |
| limao | ltomasbo : https://bugs.launchpad.net/kuryr-libnetwork/+bug/1626011 | 09:34 |
| openstack | Launchpad bug 1626011 in kuryr-libnetwork "Container boot failed: new subnet created with missing subnetpool" [Undecided,Fix released] - Assigned to Dongcan Ye (hellochosen) | 09:34 |
| ltomasbo | umm, I have no problem creating the container | 09:35 |
| ltomasbo | and even with the warning in the network create | 09:35 |
| ltomasbo | the container is booted and plugged properly | 09:35 |
| ltomasbo | the only problem is the hanging port | 09:35 |
| limao | the port did not been deleted in neutron, right? | 09:36 |
| ltomasbo | yep, that is the problem | 09:36 |
| ltomasbo | since now, to delete the port | 09:36 |
| ltomasbo | we check if: | 09:36 |
| ltomasbo | tmp_subnet['subnetpool_id'] == pool_id | 09:37 |
| ltomasbo | while before, if there was only one subnet (as in my csae) | 09:37 |
| ltomasbo | if was selected, and then deleted from there | 09:37 |
| ltomasbo | https://review.openstack.org/#/c/401874/5/kuryr_libnetwork/controllers.py | 09:37 |
| ltomasbo | this is what creates the port not to be deleted, but maybe the problem is that subnetpool_id is not properly updated when creating the network | 09:38 |
| limao | Yeah, maybe, I fixed a bug related this before, but it should not be your problem. because you are using existed neutron network: https://github.com/openstack/kuryr-libnetwork/commit/93db824cf64ae63fde5bb55206b3651763ec9ed3 | 09:39 |
| limao | are you using latest master code? | 09:40 |
| limao | Let me try to reproduce the problem in my environment | 09:40 |
| ltomasbo | yes, I'm using the master code | 09:41 |
| ltomasbo | and I do have that patch merged | 09:41 |
| ltomasbo | steps to reproduce: | 09:41 |
| ltomasbo | openstack network create net0 | 09:42 |
| ltomasbo | openstack subnet create --network net0 --subnet-range 10.0.4.0/24 subnet0 | 09:42 |
| ltomasbo | docker network create -d kuryr --ipam-driver=kuryr --subnet=10.0.4.0/24 --gateway=10.0.4.1 -o neutron.net.name=net0 kuryr-net0 | 09:42 |
| ltomasbo | docker run -it --net=kuryr-net0 busybox | 09:42 |
| yedongcan | ltomasbo, limao: ltomasbo's case is: 1.neutron create network 2.neutron create-subnet 3.kuryr create network with the same cidr with step two, this will hits There is already existing subnet for the same cidr. Please check and specify pool name in Options. | 09:42 |
| ltomasbo | and exit the container | 09:43 |
| limao | get it ltomasbo, hi yedongcan | 09:43 |
| yedongcan | ltomasbo, limao: but if we pass another subnet in step 3, we will hit: Error response from daemon: NetworkDriver.CreateNetwork: Subnets hosted on the same network must be allocated from the same subnet pool. | 09:43 |
| yedongcan | Neutron server returns request_ids: ['req-55035146-bdf8-460a-8467-8be031968158'] | 09:43 |
| yedongcan | ltomasbo, limao: I just test another case: 1.neutron create network 2.docker create network using existing network then I got the subnetpool_id | 09:46 |
| ltomasbo | yep, but to me the interesting case is when there is already subnets (and VMs connected to) in the neutron net | 09:48 |
| ltomasbo | I notice that, even if you include the -o neutron.pool.name and the --ipam-opt | 09:50 |
| ltomasbo | the subnetpool_id is not appearing in the neutron subnet-show net0 | 09:50 |
| ltomasbo | although the port is deleted in that case | 09:50 |
| yedongcan | umm, that means subnetpool_id not update? | 09:51 |
| ltomasbo | no idea | 09:51 |
| ltomasbo | maybe we do not update the subnet info... | 09:52 |
| yedongcan | umm, I will leave now, and will check that later. | 09:54 |
| *** yedongcan has left #openstack-kuryr | 09:55 | |
| apuimedo | ivc_: irenab_: vikasc: That's some intense early morning discussion (for eu tz) | 09:56 |
| apuimedo | :P | 09:56 |
| vikasc | :D | 09:56 |
| vikasc | ivc_ dont sleep so thats the result | 09:57 |
| apuimedo | ltomasbo: limao: only etcd/consul/zk is supported when using kuryr with docker swarm. Creating the same libnetwork net on each host is a way to die an early death due to stress | 10:00 |
| ltomasbo | :D | 10:00 |
| limao | ;-) | 10:01 |
| ltomasbo | but this is the case when you create it with neutron, and then just in 1 host for docker | 10:01 |
| apuimedo | ltomasbo: if your one docker host engine is pointing to a cluster store, it will still go and define it in etcd | 10:06 |
| ltomasbo | I'm just using docker, without swarm or kubernetes, so not using etcd at all (for now) | 10:07 |
| ltomasbo | but I fully agree, for a multi node etcd is a must | 10:08 |
| apuimedo | well, when you move to use more hosts, please use the cluster store :-) | 10:08 |
| ltomasbo | :-) | 10:09 |
| *** yamamoto_ has quit IRC | 10:15 | |
| *** openstackgerrit has quit IRC | 10:18 | |
| limao | ltomasbo: I think this is bug, when kuryr input existed network, the exist subnet do not have subnetpool id... when kuryr delete port, it will check subnet has subnetpool | 10:28 |
| *** garyloug has quit IRC | 10:28 | |
| ltomasbo | yep | 10:28 |
| limao | ltomasbo: and I think maybe neutron subnet-update do not support update subnetpool id | 10:30 |
| limao | ltomasbo: so when after kuryr create subnet pool, it can't update the existed subnet.. | 10:30 |
| ltomasbo | ok, anyway, even if that info does not appear in neutron subnet-list | 10:34 |
| limao | ltomasbo: or maybe when we release port if the subnet is in existed network, then we do not check subnetpool id. | 10:34 |
| limao | ltomasbo: yeah, I thought after subnet is created subnetpool_id is unchangable... | 10:35 |
| ltomasbo | if the net is created with the ipam-opt it is accessible | 10:35 |
| limao | ltomasbo: I have to go now... let's check more later :-) | 10:36 |
| *** jchhatbar is now known as janki | 10:37 | |
| *** janki has left #openstack-kuryr | 10:37 | |
| *** limao has quit IRC | 10:37 | |
| ltomasbo | ok, thanks! | 10:37 |
| *** yamamoto has joined #openstack-kuryr | 11:27 | |
| *** yamamoto_ has joined #openstack-kuryr | 11:28 | |
| *** yamamoto has quit IRC | 11:32 | |
| *** openstackgerrit has joined #openstack-kuryr | 11:43 | |
| openstackgerrit | Merged openstack/kuryr-libnetwork: Temporary cleanup remove_container method in Rally job https://review.openstack.org/404591 | 11:43 |
| apuimedo | mchiappero: ping | 11:53 |
| *** yamamoto_ has quit IRC | 11:53 | |
| openstackgerrit | Antoni Segura Puimedon proposed openstack/kuryr-libnetwork: [WIP] Driver based model for kuryr-libnetwork https://review.openstack.org/400365 | 11:54 |
| apuimedo | mchiappero: ltomasbo: I solved the nameless TODO in the patch. Now it should pass the pep8 | 11:55 |
| apuimedo | https://review.openstack.org/#/c/400365/27..26/kuryr_libnetwork/tests/unit/port_driver/drivers/test_nested.py | 11:56 |
| *** tonanhngo has joined #openstack-kuryr | 11:56 | |
| *** yamamoto has joined #openstack-kuryr | 11:56 | |
| ltomasbo | great! I will rebase mine | 12:02 |
| ltomasbo | and I will add unit tests too | 12:02 |
| *** david-lyle has quit IRC | 12:05 | |
| *** david-lyle has joined #openstack-kuryr | 12:05 | |
| *** tonanhngo_ has joined #openstack-kuryr | 12:06 | |
| *** fkautz has quit IRC | 12:07 | |
| *** fkautz has joined #openstack-kuryr | 12:07 | |
| *** tonanhngo has quit IRC | 12:08 | |
| apuimedo | thanks ltomasbo | 12:21 |
| *** garyloug has joined #openstack-kuryr | 12:24 | |
| *** garyloug has quit IRC | 12:31 | |
| *** yamamoto has quit IRC | 13:05 | |
| *** saneax is now known as saneax-_-|AFK | 13:23 | |
| *** yamamoto has joined #openstack-kuryr | 13:24 | |
| *** yamamoto has quit IRC | 13:30 | |
| *** yamamoto has joined #openstack-kuryr | 13:31 | |
| *** yamamoto has quit IRC | 13:35 | |
| openstackgerrit | vikas choudhary proposed openstack/kuryr-kubernetes: [WIP] Refactor for porting of binding drivers from kuryr-lib https://review.openstack.org/410578 | 13:36 |
| *** limao has joined #openstack-kuryr | 13:37 | |
| *** irenab_ has quit IRC | 14:08 | |
| *** ashb_ has joined #openstack-kuryr | 14:14 | |
| *** oanson has quit IRC | 14:15 | |
| *** garyloug has joined #openstack-kuryr | 14:27 | |
| *** gsagie has joined #openstack-kuryr | 14:46 | |
| *** tonanhngo_ has quit IRC | 15:16 | |
| apuimedo | mchiappero: ping | 15:27 |
| *** hongbin has joined #openstack-kuryr | 15:28 | |
| *** gsagie has quit IRC | 15:38 | |
| *** ashb_ has quit IRC | 15:56 | |
| *** garyloug has quit IRC | 16:04 | |
| *** hongbin has quit IRC | 16:05 | |
| *** garyloug has joined #openstack-kuryr | 16:06 | |
| *** diogogmt has quit IRC | 16:12 | |
| *** roeyc has quit IRC | 16:14 | |
| *** yamamoto has joined #openstack-kuryr | 16:20 | |
| *** yamamoto has quit IRC | 16:21 | |
| *** dimak has quit IRC | 16:33 | |
| mchiappero | apuimedo: pong | 16:40 |
| mchiappero | today I'm extremely busy, sorry :( | 16:40 |
| *** pcaruana has quit IRC | 16:42 | |
| *** yamamoto has joined #openstack-kuryr | 16:42 | |
| *** hongbin has joined #openstack-kuryr | 16:43 | |
| *** yamamoto has quit IRC | 16:49 | |
| *** yamamoto has joined #openstack-kuryr | 16:50 | |
| *** limao has quit IRC | 17:00 | |
| *** diogogmt has joined #openstack-kuryr | 17:04 | |
| *** tonanhngo has joined #openstack-kuryr | 17:25 | |
| *** tonanhngo has quit IRC | 17:29 | |
| *** tonanhngo has joined #openstack-kuryr | 17:38 | |
| *** garyloug has quit IRC | 17:47 | |
| *** neiljerram has quit IRC | 18:33 | |
| apuimedo | mchiappero: still around? | 20:20 |
| *** jgriffith is now known as jgriffith_AutoAw | 21:40 | |
| *** jgriffith_AutoAw is now known as jgriffith | 21:52 | |
| *** saneax-_-|AFK is now known as saneax | 22:40 | |
| *** yamamoto has quit IRC | 22:40 | |
| *** jgriffith is now known as jgriffith_AutoAw | 22:47 | |
| *** jgriffith_AutoAw is now known as jgriffith | 22:47 | |
| *** saneax is now known as saneax-_-|AFK | 22:48 | |
| *** saneax-_-|AFK is now known as saneax | 23:03 | |
| *** yamamoto has joined #openstack-kuryr | 23:40 | |
| openstackgerrit | Hongbin Lu proposed openstack/fuxi: Enable use of constraints for all tox based jobs. https://review.openstack.org/409968 | 23:47 |
| *** yamamoto has quit IRC | 23:50 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!