| *** hongbin has quit IRC | 00:10 | |
| *** tonanhngo has quit IRC | 00:10 | |
| *** oanson has quit IRC | 00:16 | |
| *** tonanhngo has joined #openstack-kuryr | 00:20 | |
| *** tonanhngo has quit IRC | 00:25 | |
| *** limao has joined #openstack-kuryr | 00:32 | |
| *** tonanhngo has joined #openstack-kuryr | 01:12 | |
| *** tonanhngo has quit IRC | 01:12 | |
| *** huikang has joined #openstack-kuryr | 02:08 | |
| *** yedongcan has joined #openstack-kuryr | 02:34 | |
| *** yuanying has quit IRC | 02:52 | |
| *** huikang has quit IRC | 03:29 | |
| *** tonanhngo has joined #openstack-kuryr | 03:34 | |
| *** tonanhngo has quit IRC | 03:39 | |
| *** yuanying has joined #openstack-kuryr | 03:50 | |
| *** yedongcan has quit IRC | 04:20 | |
| *** tonanhngo has joined #openstack-kuryr | 04:44 | |
| *** tonanhngo has quit IRC | 04:48 | |
| *** yedongcan has joined #openstack-kuryr | 05:10 | |
| *** tonanhngo has joined #openstack-kuryr | 05:28 | |
| *** tonanhngo has quit IRC | 05:32 | |
| *** yedongcan has quit IRC | 05:36 | |
| *** irenab has joined #openstack-kuryr | 05:59 | |
| *** yedongcan has joined #openstack-kuryr | 06:04 | |
| *** irenab has quit IRC | 06:43 | |
| *** oanson has joined #openstack-kuryr | 06:44 | |
| *** janki has joined #openstack-kuryr | 06:53 | |
| *** janki has quit IRC | 06:56 | |
| *** dimak has joined #openstack-kuryr | 08:16 | |
| apuimedo | mchiappero: hi | 08:41 |
|---|---|---|
| *** janki has joined #openstack-kuryr | 08:50 | |
| *** janki has quit IRC | 08:58 | |
| apuimedo | vikasc: I think we can take https://review.openstack.org/#/c/397201/1 in' | 09:09 |
| vikasc | apuimedo, sure Toni, let me take a look. | 09:10 |
| apuimedo | cool | 09:11 |
| mchiappero | hi apuimedo! | 09:12 |
| apuimedo | limao: mchiappero: it really looks like we need to cut a release of kuryr-lib | 09:12 |
| apuimedo | :-) | 09:12 |
| mchiappero | need to have a quick chat with you, but I have a meeting in 15 mins | 09:12 |
| apuimedo | I'll diff 0.1.0..master to come up with the next version | 09:12 |
| mchiappero | will you be around at 11? | 09:12 |
| apuimedo | mchiappero: at 11:10 probably | 09:13 |
| mchiappero | np | 09:13 |
| mchiappero | well, if you are available now I can actually talk | 09:13 |
| limao | hello, mchiappero, apuimedo | 09:14 |
| mchiappero | hi limao | 09:14 |
| apuimedo | better 11:10, now I'm expecting some repairman | 09:14 |
| mchiappero | better for me too anyway :) | 09:15 |
| *** lmdaly has joined #openstack-kuryr | 09:18 | |
| mchiappero | BTW a guy from docker I guess told me that they have been busy with the new release and that will reply soon to my issue (https://github.com/docker/libnetwork/issues/1520) | 09:28 |
| *** garyloug has joined #openstack-kuryr | 09:30 | |
| *** janki has joined #openstack-kuryr | 09:31 | |
| *** janki has quit IRC | 09:35 | |
| *** oanson has quit IRC | 09:42 | |
| *** oanson has joined #openstack-kuryr | 09:47 | |
| *** limao has quit IRC | 09:57 | |
| vikasc | apuimedo, WDYT on this https://review.openstack.org/#/c/397057/2 | 10:02 |
| vikasc | apuimedo, why does this line is required in localrc for q-qos enabling, enable_plugin neutron https://git.openstack.org/openstack/neutron | 10:04 |
| vikasc | apuimedo, i tried without this and it seems to be enabling qos | 10:05 |
| apuimedo | mchiappero: cool | 10:23 |
| apuimedo | vikasc: not sure, I assumed they must have some newer code on the plugin but if it works without, -1 and get limao to verify | 10:23 |
| vikasc | apuimedo, cool, let me confirm with limao then | 10:24 |
| vikasc | apuimedo, i would love to have your opinion on https://review.openstack.org/#/c/361993/11 before i start working on unit tests | 10:25 |
| apuimedo | ok. Will check, thanks\ | 10:25 |
| mchiappero | one question, will the trunk approach have the same behaviour as the IPVLAN one for the nested case? | 10:27 |
| apuimedo | mchiappero: in which sense? | 10:27 |
| mchiappero | Is the code path the same, same need for an updated allowed_pairs | 10:28 |
| vikasc | apuimedo, and this one also please https://review.openstack.org/#/c/397057/2 :) | 10:28 |
| mchiappero | I'm reasoning a bit on the driver model on kuryr-libnetwork, and I'm trying to understand whether there are commonalities across macvlan/ipvlan and trunk | 10:29 |
| vikasc | mchiappero, nope | 10:29 |
| mchiappero | ok | 10:29 |
| vikasc | mchiappero, allowed-address-pair wont be required in trunk port case | 10:29 |
| apuimedo | mchiappero: there's actually two different ways to do the trunk mode | 10:29 |
| apuimedo | so two trunk modes | 10:29 |
| apuimedo | a) One vlan per network -> needs to touch allowed address pairs | 10:30 |
| mchiappero | so, in the end the plugins should be bridge (Bare Metal), nested ipvlan/macvlan, nested trunk | 10:30 |
| vikasc | mchiappero, i can see commonality in binding part | 10:30 |
| apuimedo | b) one vlan per container -> no need to touch allowed address pairs | 10:30 |
| mchiappero | oooh ok, got it | 10:30 |
| vikasc | apuimedo, hmm | 10:30 |
| apuimedo | veth, ipvlan/macvlan, trunknet, trunkcont | 10:30 |
| vikasc | apuimedo, i was thinking on 'b' approach | 10:31 |
| mchiappero | so, the a) case is in theory more flexible than ipvlan | 10:31 |
| mchiappero | but how do we want to handle the fact that ipvlan could be working on BM and nested? | 10:32 |
| vikasc | apuimedo, how do you compare 'a' and 'b' ? | 10:32 |
| apuimedo | vikasc: in (a) you can have many more containers per VM | 10:33 |
| apuimedo | and communication inside a network does not go all the way down to the host | 10:33 |
| mchiappero | but single tenant per VM, right? | 10:33 |
| apuimedo | mchiappero: right | 10:33 |
| apuimedo | brb | 10:33 |
| mchiappero | ok | 10:34 |
| mchiappero | but I think I'm still not too clear with the approach you had in mind, so let's continue whenever you can :) | 10:34 |
| vikasc | mchiappero, can you add a bit more on "single tenant per VM" | 10:35 |
| vikasc | mchiappero, please | 10:35 |
| mchiappero | so, my understanding is that internally every container will be part of the same network, like in the IPVLAN/MACVLAN case | 10:36 |
| vikasc | and .. | 10:36 |
| mchiappero | so basically it's a single admin domain, single tenant | 10:36 |
| vikasc | you talking about 'a'? | 10:37 |
| mchiappero | while for the b) case the VM will transparently let the containers join separate networks | 10:37 |
| mchiappero | yes, sorry | 10:37 |
| mchiappero | let's wait for apuimedo to confirm though :) | 10:37 |
| vikasc | mchiappero, sure :) | 10:38 |
| mchiappero | I'm trying to understand whether there are commonalities, so rather a BM plugin, a nested one (ipvlan, macvlan, trunk case a?), maybe another for special cases (e.g. trunk case b) | 10:40 |
| vikasc | mchiappero, do we have an etherpad or shared doc for discussion on this? | 10:43 |
| mchiappero | uhm... not sure, I guess so | 10:44 |
| apuimedo | I do not think we do | 10:45 |
| vikasc | mchiappero, will it be productive to start one | 10:45 |
| apuimedo | we usually use the mailing list for these things | 10:45 |
| mchiappero | ok, even though it's faster to have a chat here if it's ok with you | 10:45 |
| mchiappero | what was the approach you had in mind apuimedo? | 10:46 |
| apuimedo | in the b) case IIRC, and ltomasbo can correct me if I'm wrong, unless the actions are performed by the admin, you can only make subports for trunk ports of your same tenant | 10:46 |
| vikasc | apuimedo, i am still not getting why --allowed-address pair is needed in (a) .. because trunk-port will pass the tagged traffic through | 10:46 |
| apuimedo | vikasc: are you sure about that? | 10:46 |
| vikasc | apuimedo, not sure.. | 10:46 |
| apuimedo | because I thought that the untagging ovs bridge with patch ports to the br-int | 10:47 |
| apuimedo | just gets stuff to br-int, and there the rules for anti ip spoofing could still apply | 10:47 |
| ltomasbo | hi, let me read what is the discussion about | 10:47 |
| *** yedongcan has left #openstack-kuryr | 10:47 | |
| apuimedo | ltomasbo: vikasc was wondering if it is necessary to touch allowed address pairs when you use one subport per container network | 10:48 |
| ltomasbo | I think so, that would be pretty much the ipvlan case | 10:48 |
| ltomasbo | as you need to create a subport for the trunk | 10:48 |
| ltomasbo | and then a port (with an IP) which will be used for each container | 10:49 |
| ltomasbo | i.e., one extra port per container | 10:49 |
| ltomasbo | this is for the 1 vlan per network, and many container sharing the same subport | 10:50 |
| apuimedo | mchiappero: vikasc: implicit into that is that you get a vlan device in the VM and then you need to put an ipvlan device from it into each container | 10:50 |
| *** dimak has quit IRC | 10:51 | |
| apuimedo | ltomasbo: did you already try to make ipvlan linked to vlan device? | 10:51 |
| ltomasbo | didn't spend that much time on in lately, but I tried manually on top of lmdaly ipvlan implementation | 10:51 |
| ltomasbo | just by changing the iface name from eth0 to eth0.101 | 10:52 |
| ltomasbo | and that already works | 10:52 |
| ltomasbo | need to make that parametrizable though | 10:52 |
| vikasc | apuimedo, because the network of vm will be different from network of containers in case (a), anti ip spoofing rules will not impact container traffic and we might need not require allowed address pair.. thats how i was thinking | 10:52 |
| vikasc | apuimedo, will give it a try | 10:53 |
| *** dimak has joined #openstack-kuryr | 10:53 | |
| apuimedo | vikasc: don't you think it will impact if there's containers on the same network in different VMs? | 10:53 |
| ltomasbo | casa a was 1vlan per network, right? | 10:53 |
| vikasc | ltomasbo, yes | 10:53 |
| ltomasbo | I can remove the allowed address pair and see if the VM gets connectivity | 10:53 |
| ltomasbo | I already have a devstack with that working | 10:54 |
| vikasc | ltomasbo, great | 10:54 |
| vikasc | apuimedo, thinking on your point | 10:54 |
| mchiappero | mmm another question I have is: shouldn't be kuryr-libnetwork in charge of picking up the right kyrur-lib driver? | 10:55 |
| vikasc | apuimedo, i might be missing something. Would explore more at my end. | 10:56 |
| mchiappero | I mean, reading the configuration and asking kuryr-lib for the right driver, by whatever mean, e.g. a factory | 10:56 |
| apuimedo | mchiappero: you mean so we don't need to configuration settings? | 10:56 |
| apuimedo | my idea was that if some kuryr-libnetwork can only work with one kuryr-lib driver, that it will just use it, without checking the kuryr-lib conf | 10:57 |
| mchiappero | to avoid having a config option for the kuryr-libnetwork side and another for kuryr-lib, and avoid any coherency issues | 10:58 |
| mchiappero | I'm not sure I got what you mean | 10:58 |
| apuimedo | let me rephrase | 11:00 |
| mchiappero | so, say you want veths on BM, libnetwork will know from the config file an ask kuryr-lib to get such a driver and will take the codepath that skips the allowed-address-pairs and so on | 11:00 |
| apuimedo | there is kuryr-lib driver setting in kuryr.conf | 11:00 |
| apuimedo | there is also kuryr-libnetwork driver setting in kuryr.conf | 11:00 |
| mchiappero | exactly, I'm wondering whether this is a good approach | 11:01 |
| apuimedo | my thought was that some selections in kuryr-libnetwork make the kuryr-lib setting unnecessary | 11:01 |
| mchiappero | or is anyway the approach we want | 11:01 |
| apuimedo | but for some cases, you may need a choice | 11:01 |
| ltomasbo | it does not work without the allowed-ip-address | 11:01 |
| apuimedo | ltomasbo: thanks for checking! | 11:01 |
| vikasc | thanks ltomasbo and apuimedo | 11:01 |
| ltomasbo | I need to catch a flight now, so leaving in 10 mintues | 11:02 |
| mchiappero | sure, but what I'm asking is: shouldn't all the config options be read by k-libnetwork? | 11:02 |
| mchiappero | ltomasbo: bye! :) | 11:02 |
| ltomasbo | apuimedo: I found a workaround for the QoS + Trunk ports that could be interesting for kuryr | 11:02 |
| ltomasbo | https://bugs.launchpad.net/neutron/+bug/1639186 | 11:02 |
| openstack | Launchpad bug 1639186 in neutron "qos max bandwidth rules not working for neutron trunk ports" [Low,Confirmed] - Assigned to Luis Tomas Bolivar (ltomasbo) | 11:02 |
| ltomasbo | it is not the right solution | 11:02 |
| ltomasbo | but at least it may allow us to try QoS while waiting for a more decent solution (OVS new functionality) | 11:03 |
| apuimedo | mchiappero: they will all be read by k-libnetwork, we only have a single kuryr.conf | 11:04 |
| mchiappero | ok, if I'm not wrong currently kuryr-lib parses its own options | 11:04 |
| apuimedo | mchiappero: it does. I cheated a bit on the definition | 11:05 |
| apuimedo | what I meant it's that the kuryr-libnetwork process includes kuryr-lib | 11:05 |
| apuimedo | and they all read their part of kuryr.conf | 11:05 |
| mchiappero | yes I know | 11:05 |
| mchiappero | but still, I don't understand how you plan to guarantee the driver-to-driver coherency | 11:06 |
| mchiappero | :) | 11:06 |
| apuimedo | well, I planned to have kuryr-libnetwork manage that | 11:06 |
| apuimedo | by whitelisting in the driver modules | 11:06 |
| apuimedo | which kuryr-lib drivers it can work with | 11:06 |
| mchiappero | ok, so that's what I was thinking about, but kuryr-lib shouldn't create any driver by itself | 11:06 |
| apuimedo | mchiappero: what do you mean with 'create'? | 11:07 |
| mchiappero | apuimedo: how would you implement that? | 11:07 |
| mchiappero | sorry, s/create/load/g | 11:07 |
| mchiappero | probably this wording was confusing | 11:07 |
| apuimedo | well | 11:08 |
| apuimedo | I wanted to take a usability approach | 11:08 |
| apuimedo | let's see if I can explain | 11:08 |
| apuimedo | so each driver would have | 11:08 |
| apuimedo | ALLOWED_BINDING_DRIVERS tuple | 11:08 |
| apuimedo | like for example | 11:08 |
| apuimedo | ('ipvlan', 'veth') | 11:08 |
| apuimedo | unless the kuryr-lib binding driver config option specifies a full path to a binding driver, only ipvlan and veth can be used in this example | 11:09 |
| apuimedo | and the setting can be filled with 'ipvlan' or 'veth', no need for the whole path when you select an allowed one | 11:09 |
| mchiappero | I'm still not sure whether we are saying the same thing or not :D | 11:10 |
| apuimedo | :O | 11:10 |
| apuimedo | :P | 11:10 |
| mchiappero | ok ok :) | 11:10 |
| apuimedo | wrong emoji the first time | 11:10 |
| apuimedo | I meant :P because my lack of sleep must have been impairing my explanation | 11:10 |
| apuimedo | let me put it in this way | 11:10 |
| apuimedo | kuryr-libnetwork reads kuryr.conf to see which port handling driver it should use | 11:11 |
| mchiappero | my idea was that a driver in kuryr-libnetwork will be allowed to request kuryr-lib to load drivers specific to it | 11:11 |
| apuimedo | this loads a driver module in kuryr-libnetwork | 11:11 |
| mchiappero | exactely | 11:11 |
| apuimedo | this driver has a constant with which modules it whitelists | 11:11 |
| mchiappero | will also determine/validate the driver for kuryr-lib | 11:11 |
| mchiappero | exactly what I'm saying | 11:12 |
| mchiappero | but currently the driver in kuryr-lib get loaded by kuryr-lib itself | 11:12 |
| apuimedo | it will still read the kuryr.conf binding driver config option to check if the operator specified a full path to an external driver. If that is not the case, only the whitelisted ones can be selected | 11:12 |
| apuimedo | mchiappero: we can fix it to be done/overriden by kuryr-libnetwork | 11:12 |
| apuimedo | probably | 11:13 |
| mchiappero | yeah ok, that's what I wanted to check with you :) | 11:13 |
| apuimedo | kuryr-libnetwork and CNI pieces choose the binding from their own information | 11:13 |
| apuimedo | and from whatever was on kuryr.conf about the binding driver | 11:13 |
| mchiappero | I would probably create a function to request the loading of a specific driver in kuryr-lib... kind of a factory method in OOP | 11:14 |
| mchiappero | just to double check we are on the same page | 11:15 |
| apuimedo | mchiappero: as long as it is not called factory and it doesn't smeel too much of oop | 11:16 |
| * apuimedo has severe allergies :P | 11:16 | |
| apuimedo | s/smeel/smell/ | 11:16 |
| mchiappero | whatever, just to check we are talking about the same things :) | 11:17 |
| mchiappero | I'll get unpopular but I don't have any allergies :p | 11:18 |
| apuimedo | lucky you... Every spring fscking pollen tries to kill me | 11:18 |
| mchiappero | well, no, I do have the same problem, even though in Ireland it has reduced significantly | 11:20 |
| mchiappero | but my background is way more on staticly typed languages, much much less on python/ruby | 11:22 |
| apuimedo | I exorcised the Java demons | 11:27 |
| mchiappero | well, this conversation can be very dangerous :P | 11:29 |
| mchiappero | but I've worked a lot wit C/C++/Java, all of them have things I don't like | 11:30 |
| mchiappero | I have little experience with Python, but I would say the same | 11:30 |
| mchiappero | when I'll write the perfect language I'll let you know though :P | 11:31 |
| apuimedo | I'm on the same boat | 11:39 |
| apuimedo | :P | 11:39 |
| apuimedo | so far I like what I see in Rust | 11:39 |
| apuimedo | but the worst thing I ever saw was embedded Java (javacard) | 11:39 |
| mchiappero | I've never tried Rust, I would still like to learn golang first, but sooner or later I'll have a look :) | 11:40 |
| mchiappero | I guess RH is working on projects in pretty much every common language | 11:42 |
| apuimedo | yes, pretty much | 11:50 |
| *** pc_m has quit IRC | 12:14 | |
| *** pc_m has joined #openstack-kuryr | 12:16 | |
| openstackgerrit | Ilya Chukhnakov proposed openstack/kuryr-kubernetes: Pod subnet driver and os-vif utils https://review.openstack.org/398324 | 12:27 |
| openstackgerrit | Ilya Chukhnakov proposed openstack/kuryr-kubernetes: Pod subnet driver and os-vif utils https://review.openstack.org/398324 | 12:36 |
| *** dimak has quit IRC | 12:36 | |
| *** irenab has joined #openstack-kuryr | 12:39 | |
| *** irenab has quit IRC | 12:44 | |
| *** lmdaly has quit IRC | 12:56 | |
| *** garyloug has quit IRC | 13:02 | |
| *** dimak has joined #openstack-kuryr | 13:56 | |
| *** dimak has quit IRC | 14:03 | |
| *** dimak has joined #openstack-kuryr | 14:17 | |
| *** dimak has quit IRC | 14:22 | |
| *** dimak has joined #openstack-kuryr | 14:24 | |
| *** tonanhngo has joined #openstack-kuryr | 14:51 | |
| *** lmdaly has joined #openstack-kuryr | 14:52 | |
| *** hongbin has joined #openstack-kuryr | 14:58 | |
| *** garyloug has joined #openstack-kuryr | 14:58 | |
| *** dimak has quit IRC | 15:07 | |
| *** oanson has quit IRC | 15:51 | |
| *** david-lyle has quit IRC | 17:48 | |
| *** david-lyle has joined #openstack-kuryr | 17:48 | |
| *** tonanhngo has quit IRC | 17:51 | |
| *** garyloug has quit IRC | 17:58 | |
| *** lmdaly has quit IRC | 18:12 | |
| *** diogogmt has joined #openstack-kuryr | 18:13 | |
| *** tonanhngo has joined #openstack-kuryr | 18:32 | |
| *** tonanhngo has quit IRC | 18:36 | |
| *** tonanhngo has joined #openstack-kuryr | 18:38 | |
| *** tonanhngo has quit IRC | 18:39 | |
| *** tonanhngo has joined #openstack-kuryr | 18:39 | |
| *** oanson has joined #openstack-kuryr | 19:50 | |
| *** irenab has joined #openstack-kuryr | 21:50 | |
| *** irenab has quit IRC | 21:55 | |
| *** tonanhngo_ has joined #openstack-kuryr | 21:58 | |
| *** tonanhngo has quit IRC | 22:01 | |
| *** tonanhngo_ has quit IRC | 22:03 | |
| *** tonanhngo has joined #openstack-kuryr | 22:26 | |
| *** tonanhngo has quit IRC | 22:30 | |
| *** oanson has quit IRC | 22:41 | |
| *** diogogmt has quit IRC | 23:25 | |
| *** irenab has joined #openstack-kuryr | 23:38 | |
| *** irenab has quit IRC | 23:43 | |
| *** david-lyle_ has joined #openstack-kuryr | 23:50 | |
| *** david-lyle has quit IRC | 23:51 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!