| *** macz_ has quit IRC | 00:41 | |
| *** rcernin has quit IRC | 00:44 | |
| *** manpreet has joined #openstack-meeting | 00:45 | |
| *** ircuser-1 has quit IRC | 01:12 | |
| *** timburke has quit IRC | 01:13 | |
| *** jamesmcarthur has quit IRC | 01:21 | |
| *** jamesmcarthur has joined #openstack-meeting | 01:21 | |
| *** jmasud has joined #openstack-meeting | 01:37 | |
| *** jmasud has quit IRC | 01:39 | |
| *** rcernin has joined #openstack-meeting | 01:45 | |
| *** jmasud has joined #openstack-meeting | 01:46 | |
| *** jmasud has quit IRC | 01:48 | |
| *** jmasud has joined #openstack-meeting | 01:50 | |
| *** mlavalle has quit IRC | 02:06 | |
| *** _mlavalle_1 has joined #openstack-meeting | 02:07 | |
| *** jmasud has quit IRC | 02:21 | |
| *** njohnston has quit IRC | 02:37 | |
| *** jmasud has joined #openstack-meeting | 02:37 | |
| *** jamesmcarthur has quit IRC | 02:39 | |
| *** jamesmcarthur has joined #openstack-meeting | 02:41 | |
| *** macz_ has joined #openstack-meeting | 02:42 | |
| *** jamesmcarthur has quit IRC | 02:45 | |
| *** macz_ has quit IRC | 02:47 | |
| *** jamesmcarthur has joined #openstack-meeting | 03:03 | |
| *** jamesmcarthur has quit IRC | 03:04 | |
| *** jamesmcarthur has joined #openstack-meeting | 03:04 | |
| *** jamesmcarthur has quit IRC | 03:31 | |
| *** jmasud has quit IRC | 03:35 | |
| *** jamesmcarthur has joined #openstack-meeting | 03:36 | |
| *** jamesmcarthur has quit IRC | 03:36 | |
| *** jamesmcarthur has joined #openstack-meeting | 03:36 | |
| *** rcernin has quit IRC | 03:39 | |
| *** armax has quit IRC | 03:49 | |
| *** rcernin has joined #openstack-meeting | 03:52 | |
| *** rcernin has quit IRC | 03:52 | |
| *** rcernin has joined #openstack-meeting | 03:52 | |
| *** armax has joined #openstack-meeting | 03:53 | |
| *** jmasud has joined #openstack-meeting | 03:55 | |
| *** bbowen_ has joined #openstack-meeting | 04:06 | |
| *** ircuser-1 has joined #openstack-meeting | 04:07 | |
| *** jmasud has quit IRC | 04:08 | |
| *** bbowen has quit IRC | 04:08 | |
| *** armax has quit IRC | 04:13 | |
| *** jmasud has joined #openstack-meeting | 04:15 | |
| *** jamesmcarthur has quit IRC | 04:19 | |
| *** jamesmcarthur has joined #openstack-meeting | 04:20 | |
| *** njohnston has joined #openstack-meeting | 04:22 | |
| *** jamesmcarthur has quit IRC | 04:25 | |
| *** jamesmcarthur has joined #openstack-meeting | 04:26 | |
| *** jamesmcarthur has quit IRC | 04:31 | |
| *** jamesmcarthur has joined #openstack-meeting | 04:32 | |
| *** timburke has joined #openstack-meeting | 04:43 | |
| *** macz_ has joined #openstack-meeting | 04:43 | |
| *** macz_ has quit IRC | 04:47 | |
| *** jmasud has quit IRC | 05:29 | |
| *** evrardjp has quit IRC | 05:33 | |
| *** evrardjp has joined #openstack-meeting | 05:33 | |
| *** jmasud has joined #openstack-meeting | 05:34 | |
| *** rcernin has quit IRC | 05:36 | |
| *** rcernin has joined #openstack-meeting | 05:44 | |
| *** jamesmcarthur has quit IRC | 05:55 | |
| *** rcernin has quit IRC | 05:56 | |
| *** jamesmcarthur has joined #openstack-meeting | 05:56 | |
| *** jamesmcarthur has quit IRC | 06:01 | |
| *** gyee has quit IRC | 06:11 | |
| *** jamesmcarthur has joined #openstack-meeting | 06:15 | |
| *** rcernin has joined #openstack-meeting | 06:22 | |
| *** rcernin has quit IRC | 06:23 | |
| *** rcernin has joined #openstack-meeting | 06:24 | |
| *** rcernin has quit IRC | 06:39 | |
| *** rcernin has joined #openstack-meeting | 06:44 | |
| *** jmasud has quit IRC | 06:48 | |
| *** jmasud has joined #openstack-meeting | 06:53 | |
| *** jmasud has quit IRC | 07:02 | |
| *** ralonsoh has joined #openstack-meeting | 07:03 | |
| *** jmasud has joined #openstack-meeting | 07:05 | |
| *** jmasud has joined #openstack-meeting | 07:06 | |
| *** rcernin has quit IRC | 07:14 | |
| *** timburke has quit IRC | 07:16 | |
| *** jmasud has quit IRC | 07:26 | |
| *** rcernin has joined #openstack-meeting | 07:28 | |
| *** rcernin has quit IRC | 07:43 | |
| *** jgriffit1 has quit IRC | 07:46 | |
| *** dklyle has quit IRC | 07:51 | |
| *** bbowen has joined #openstack-meeting | 08:01 | |
| *** bbowen_ has quit IRC | 08:02 | |
| *** whoami-rajat has joined #openstack-meeting | 08:03 | |
| *** jgriffith has joined #openstack-meeting | 08:07 | |
| *** jamesmcarthur has quit IRC | 08:16 | |
| *** rh-jelabarre has quit IRC | 08:19 | |
| *** rpittau|afk is now known as rpittau | 08:32 | |
| *** jamesmcarthur has joined #openstack-meeting | 08:47 | |
| *** jamesmcarthur has quit IRC | 08:52 | |
| *** tosky has joined #openstack-meeting | 08:56 | |
| *** ttx has quit IRC | 10:16 | |
| *** ttx has joined #openstack-meeting | 10:17 | |
| *** rh-jelabarre has joined #openstack-meeting | 10:22 | |
| *** ociuhandu has joined #openstack-meeting | 10:31 | |
| *** ociuhandu has quit IRC | 10:39 | |
| *** ociuhandu has joined #openstack-meeting | 10:41 | |
| *** jamesmcarthur has joined #openstack-meeting | 11:04 | |
| *** jamesmcarthur has quit IRC | 11:09 | |
| *** e0ne has joined #openstack-meeting | 11:11 | |
| *** ociuhandu has quit IRC | 11:22 | |
| *** whoami-rajat__ has joined #openstack-meeting | 11:26 | |
| *** whoami-rajat has quit IRC | 11:27 | |
| *** xinranwang has joined #openstack-meeting | 11:47 | |
| *** bbowen_ has joined #openstack-meeting | 12:10 | |
| *** bbowen has quit IRC | 12:10 | |
| *** ociuhandu has joined #openstack-meeting | 12:13 | |
| *** ociuhandu has joined #openstack-meeting | 12:15 | |
| *** ociuhandu has quit IRC | 12:26 | |
| *** SotK has quit IRC | 12:52 | |
| *** SotK has joined #openstack-meeting | 12:52 | |
| *** ociuhandu has joined #openstack-meeting | 12:53 | |
| *** ociuhandu has quit IRC | 12:58 | |
| *** ociuhandu has joined #openstack-meeting | 12:58 | |
| *** armax has joined #openstack-meeting | 13:08 | |
| *** rfolco has joined #openstack-meeting | 13:09 | |
| *** rafaelweingartne has joined #openstack-meeting | 13:52 | |
| *** _mlavalle_1 has quit IRC | 13:58 | |
| *** mlavalle has joined #openstack-meeting | 13:58 | |
| slaweq | #startmeeting neutron_drivers | 14:00 |
|---|---|---|
| openstack | Meeting started Fri Jan 8 14:00:18 2021 UTC and is due to finish in 60 minutes. The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
| *** openstack changes topic to " (Meeting topic: neutron_drivers)" | 14:00 | |
| openstack | The meeting name has been set to 'neutron_drivers' | 14:00 |
| *** gibi has joined #openstack-meeting | 14:00 | |
| mlavalle | o/ | 14:00 |
| rafaelweingartne | \o | 14:00 |
| ralonsoh | hi | 14:00 |
| yonglihe | hi | 14:00 |
| gibi | o/ | 14:00 |
| amotoki | hi | 14:00 |
| xinranwang | Hi | 14:01 |
| slaweq | haleyb: njohnston yamamoto: ping | 14:01 |
| haleyb | hi, didn't see reminder | 14:01 |
| slaweq | hello everyone on the first drivers meeting in 2021 :) | 14:01 |
| slaweq | first of all Happy New Year! | 14:01 |
| yonglihe | Happy New Year | 14:02 |
| *** lajoskatona has joined #openstack-meeting | 14:02 | |
| lajoskatona | o/ | 14:02 |
| amotoki | happy new year | 14:02 |
| ralonsoh | hny! | 14:02 |
| slaweq | and now lets start as we have couple of topics to discuss | 14:02 |
| slaweq | #topic RFEs | 14:02 |
| *** openstack changes topic to "RFEs (Meeting topic: neutron_drivers)" | 14:02 | |
| slaweq | first one: | 14:02 |
| slaweq | https://bugs.launchpad.net/neutron/+bug/1909100 | 14:02 |
| openstack | Launchpad bug 1909100 in neutron "[RFE]add new vnic type "cyborg"" [Wishlist,Confirmed] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez) | 14:02 |
| *** jawad_axd has joined #openstack-meeting | 14:03 | |
| ralonsoh | I think xinranwang could explain this RFE a bit | 14:03 |
| xinranwang | sure | 14:03 |
| xinranwang | We hope to add a new vnic type for port to indicate that the port has a backend managed by cyborg | 14:04 |
| xinranwang | so that nova can trigger the interaction with cyborg according to this vnic type | 14:04 |
| slaweq | based on last comments by gibi and ralonsoh in the LP I'm not sure we really need to add such new vnic type | 14:06 |
| ralonsoh | and amotoki's comment | 14:06 |
| slaweq | right | 14:06 |
| ralonsoh | this port is almost a "direct" port | 14:06 |
| ralonsoh | actually this is a PCI device | 14:06 |
| gibi | if there is no new vnic_type then nova will either ignor the vnic_type for these ports or neutron should enforce vnic_type=direct | 14:07 |
| gibi | or direct-physical | 14:07 |
| gibi | ignoring incoming vnic_type seems hackish | 14:07 |
| ralonsoh | agree | 14:07 |
| yonglihe | yeah, it should behave like this. | 14:07 |
| amotoki | vnic types are used to determine how neutron handles the port. my concern is what happens if two or more vnic types which are backed by cyborg. | 14:08 |
| yonglihe | maybe should limited it's should not be normal in neutron? after all neutron know what network should like. | 14:08 |
| yonglihe | for now, direct is supported, and for future the direct-physical is candidate. | 14:09 |
| *** sean-k-mooney has joined #openstack-meeting | 14:09 | |
| amotoki | so does it mean you need more vnic type for cybord backed ports? | 14:10 |
| sean-k-mooney | the intent was to have a sperate vnic type dedicated to device that were managed by cyborg and not support the device-procfile with other vnic types | 14:10 |
| ralonsoh | but this is not needed in the nova side | 14:11 |
| sean-k-mooney | on the nova side we wanted a clear way to differenciate between hardwar offloaded ovs and ovs with cyborg ports or similar for ml2/sriov nic agent | 14:11 |
| ralonsoh | and neutron can limit the device-profile to direct ports | 14:11 |
| yonglihe | sean, we had to use sriov agent | 14:12 |
| ralonsoh | this can be done reading the port definition, with the "device_profile" extension | 14:12 |
| sean-k-mooney | then we cant have colocation of hardware offloaded ovs and cyborg on the same compute | 14:12 |
| sean-k-mooney | right? | 14:12 |
| xinranwang | we should limit that only new vnic type should have device -profile filled, if we have new vnic type. | 14:12 |
| sean-k-mooney | we dont want to assume that any exssiting ml2 driver that support ovs will work with cyborg | 14:12 |
| sean-k-mooney | * not support ovs support vnic type direct | 14:13 |
| yonglihe | sean, sure, only sriov-agent working, not support ovs managed vf | 14:13 |
| sean-k-mooney | right but ml2/ovs support direct as does ovn for hardware offloaded ovs | 14:13 |
| sean-k-mooney | we did not want those ml2 drivers to be bind the port in that case correct | 14:14 |
| ralonsoh | OVN direct is for external ports (sriov) | 14:14 |
| sean-k-mooney | ralonsoh: that will taken the hardware offloaded ovs codepath in os-vif | 14:14 |
| yonglihe | how ml2/ovs differentiate it from normal sriov direct | 14:15 |
| sean-k-mooney | depending on the vif_type that is returned | 14:15 |
| sean-k-mooney | speerat topic i guess | 14:15 |
| yonglihe | so the if no new vinc, neutron should limited the backend not been set if it's belong to ovs | 14:15 |
| yonglihe | base on vif_type | 14:16 |
| ralonsoh | neutron folks? | 14:16 |
| sean-k-mooney | yes so there are 2 things nova would have to treat the port as a normal sriov port | 14:16 |
| sean-k-mooney | e.g. not attempt to add it to ovs but if its bound by the ml2/ovs dirver then we woudl try to add it to ovs | 14:17 |
| sean-k-mooney | the only thing that would prevent that today woudl be the check for swtidev api | 14:17 |
| sean-k-mooney | presumably the cyborg VF would not have that enable but they could in theory | 14:17 |
| slaweq | so IIUC new vnic type will be mostly useful for nova, right? So nova will not need to do various "if's" | 14:17 |
| slaweq | and will know that if vnic_type=='cyborg' then device_profile is needed also | 14:18 |
| sean-k-mooney | slaweq: its also useful for neturon so existing ml2 dirver dont have to be modifed to filter out cyborg ports if they dont supprot them | 14:18 |
| slaweq | is that correct? | 14:18 |
| sean-k-mooney | yes | 14:18 |
| slaweq | sean-k-mooney: right | 14:18 |
| sean-k-mooney | we could technically make this work i without the new vnic type | 14:19 |
| slaweq | and without this new type both, nova and neutron will need to do some if vnic_type=='direct' and device_profile not None, then "it's cyborg port" | 14:19 |
| sean-k-mooney | but we felt being explicit as simpler | 14:19 |
| slaweq | or something like that | 14:19 |
| slaweq | correct? | 14:19 |
| sean-k-mooney | yes | 14:19 |
| yonglihe | what about new vif? | 14:19 |
| yonglihe | just like ml2/ovs does it | 14:19 |
| slaweq | thx sean-k-mooney for confirmation | 14:20 |
| sean-k-mooney | yonglihe: sorry im not following can you restate that again | 14:20 |
| yonglihe | use vif to mark the port is 'cyborg backend' instead of vnic. | 14:20 |
| yonglihe | vif_type vs vnic_type | 14:21 |
| sean-k-mooney | you cannot set the vif-type | 14:21 |
| yonglihe | ok | 14:21 |
| sean-k-mooney | that is chosen by the driver | 14:21 |
| sean-k-mooney | we could add a new one i guess | 14:21 |
| mlavalle | vif type is an output of the binding process | 14:21 |
| yonglihe | so that's now working | 14:21 |
| yonglihe | thanks | 14:21 |
| slaweq | so, one more question - about amotoki's concern regarding name of the new vnic_type | 14:21 |
| sean-k-mooney | so we could use vnic direct with vif-type cyborg | 14:21 |
| sean-k-mooney | that would allow use to resus macvtap or direct-phsyical if we wanted too | 14:22 |
| slaweq | can it be something else, to reflect " correspoding functionality rather than who implements the functionality."? | 14:22 |
| amotoki | if we assume 'direct' vnic type with cybord support, isn't better to name it sa direct-cybord or direct-<....> with more functional name? | 14:22 |
| slaweq | or "accelerator" maybe? | 14:23 |
| yonglihe | ok for me | 14:23 |
| amotoki | if so, if you want to support cybord support with other vnic, we can name it as XXX-cybord/accerlarator. | 14:23 |
| sean-k-mooney | amotoki: that came up in the ptg and i belive sylvain had a similar concern basicaly suggesting do not include the project name | 14:23 |
| mlavalle | that's a good idea IMO | 14:23 |
| yonglihe | accelerator-x might be nice | 14:23 |
| sean-k-mooney | slaweq: acclerator and device-profile were both suggested before | 14:23 |
| slaweq | :) | 14:24 |
| sean-k-mooney | i have no strong feeling either way | 14:24 |
| yonglihe | acclerator-direct acclerator-direct-phy | 14:24 |
| mlavalle | let's not use the project name | 14:24 |
| yonglihe | agree | 14:24 |
| gibi | yonglihe: +1 | 14:24 |
| amotoki | +1 for yonglihe's idea | 14:24 |
| slaweq | that is fine for me | 14:24 |
| sean-k-mooney | yep accelerato-<connection mechanium> sound good to me | 14:24 |
| slaweq | +1 | 14:24 |
| yonglihe | nice | 14:24 |
| xinranwang | yonglihe: +1 | 14:24 |
| mlavalle | +1 | 14:25 |
| ralonsoh | +1 | 14:25 |
| ralonsoh | I'll amend the patch today | 14:25 |
| slaweq | haleyb: njohnston: any thoughts? | 14:25 |
| haleyb | +1 from me | 14:25 |
| yonglihe | ralonsoh, thanks , i gonna verify that patch 3 days later | 14:26 |
| slaweq | I will mark that rfe as approved | 14:26 |
| sean-k-mooney | by the way we are avoiding the exsiting smartnic vnic type because that is used for ironic already. | 14:26 |
| sean-k-mooney | https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/portbindings.py#L119 | 14:26 |
| slaweq | with note about naming change | 14:26 |
| slaweq | next RFE now | 14:27 |
| xinranwang | slaweq ralonsoh thanks | 14:27 |
| slaweq | https://bugs.launchpad.net/neutron/+bug/1900934 | 14:27 |
| openstack | Launchpad bug 1900934 in neutron "[RFE][DHCP][OVS] flow based DHCP" [Wishlist,New] - Assigned to LIU Yulong (dragon889) | 14:27 |
| slaweq | thank You xinranwang for proposal | 14:27 |
| slaweq | regarding LP 1900934 - this was already discussed few times | 14:27 |
| slaweq | liuyulong proposed spec already https://review.opendev.org/c/openstack/neutron-specs/+/768588 | 14:28 |
| slaweq | but rfe is still not decided | 14:28 |
| slaweq | so I think we should decide if we want to go with this solution, and continue discussion about details in the review of spec or if we don't want it in neutron at all | 14:28 |
| sean-k-mooney | slaweq: i assume this is doing dhcp via openflow rules similar ot ovn with ml2/ovs? | 14:29 |
| slaweq | sean-k-mooney: yes | 14:29 |
| slaweq | exactly | 14:29 |
| *** rafaelweingartne has quit IRC | 14:29 | |
| *** lajoskatona has left #openstack-meeting | 14:29 | |
| sean-k-mooney | cool that would be nice espcially for routed networks | 14:29 |
| sean-k-mooney | since each l2 agent could provide dhcp for the segment | 14:29 |
| mlavalle | I also have to say that my employer might be interested on this | 14:30 |
| sean-k-mooney | assumign it was done as an l2 agent exteion rather then in the dhcp agent | 14:30 |
| ralonsoh | I'm ok with the RFE, just some comments in the spec (we can move the discussion there) | 14:30 |
| slaweq | sean-k-mooney: that is original proposal IIRC | 14:30 |
| ralonsoh | just wondering the gaps between DHCP agent and OVS DHCP | 14:30 |
| slaweq | ralonsoh: one of the gaps will be for sure that there will be no dns names resolving in such case | 14:31 |
| slaweq | only dhcp | 14:31 |
| ralonsoh | yeah | 14:31 |
| amotoki | how about extra dhcp optios? | 14:31 |
| slaweq | also, I'm not sure if all extra-dhcp-options will work | 14:32 |
| slaweq | amotoki++ | 14:32 |
| slaweq | probably some of them may not work, I'm not sure | 14:32 |
| slaweq | but IMHO that | 14:32 |
| amotoki | anyway it can be covered by documentation on feature differences between flow-based dhcp and dhcp-agent | 14:32 |
| slaweq | that is fine as long as it will be documented | 14:32 |
| slaweq | amotoki: You are faster than me again :P | 14:32 |
| mlavalle | and will serve a lot of "plain vanilla' dhcp cases | 14:32 |
| amotoki | I think it is better to call it as "flow-based dhcp agent" rather than distributed dhcp agent. slaweq's rfe covers distributed agent in some way too. | 14:33 |
| slaweq | amotoki: technically it's not even "agent" but dhcp-extension | 14:34 |
| amotoki | slaweq: correct. I know it is not an agent. | 14:35 |
| amotoki | I spelled "dhcp AGENT" too many times :( | 14:35 |
| slaweq | :) | 14:35 |
| mlavalle | so let's approve it and move on with the RFE | 14:37 |
| mlavalle | +1 from me | 14:37 |
| ralonsoh | +1 | 14:37 |
| amotoki | i'm fine to approve it | 14:37 |
| haleyb | +1 from me | 14:37 |
| slaweq | mlavalle: that is also my vote - lets approve rfe and continue discussion about details in spec review | 14:37 |
| slaweq | so +1 | 14:37 |
| slaweq | I will mark this rfe as approved | 14:38 |
| slaweq | thx | 14:38 |
| slaweq | last rfe for today | 14:38 |
| slaweq | https://bugs.launchpad.net/neutron/+bug/1910533 | 14:38 |
| openstack | Launchpad bug 1910533 in neutron "[RFE] New dhcp agents scheduler - use all agents for each network" [Wishlist,New] - Assigned to Slawek Kaplonski (slaweq) | 14:38 |
| slaweq | I proposed that RFE but ralonsoh may have more details about use case | 14:39 |
| ralonsoh | I can confirm this is a source of problems in some deployments | 14:39 |
| slaweq | as he was recently "impacted" by this limitation :) | 14:39 |
| *** jgriffith has quit IRC | 14:39 | |
| ralonsoh | if you have several leafs in a deployment and networks across those leafs | 14:39 |
| ralonsoh | if you don't specify the correct number of DHCP agents, some leafs won't have a DHCP agent running | 14:40 |
| ralonsoh | and the VMs won't have IP | 14:40 |
| amotoki | ralonsoh: is a broadcast domain separeted? | 14:40 |
| ralonsoh | yes | 14:40 |
| amotoki | to overcome it we need to use dhcp-relay or deploy dhcp agents per broadcast domain | 14:41 |
| amotoki | this request sounds reasonable to me | 14:42 |
| haleyb | ralonsoh: so when you add a leaf/site but don't increase the agents it doesn't get an agent? | 14:42 |
| ralonsoh | exactly this is the problem | 14:42 |
| haleyb | ack, thanks | 14:42 |
| slaweq | haleyb: right as number of agents per network isn't related to sites at all | 14:43 |
| slaweq | so such new scheduler could be simply "workaround" of that problem | 14:43 |
| sean-k-mooney | ralonsoh: technically you could deploy 1 dhcp instance per network segment | 14:44 |
| ralonsoh | yes, that's a possibility | 14:44 |
| sean-k-mooney | at least for routed networks | 14:44 |
| ralonsoh | but you need to know where is each agent | 14:44 |
| sean-k-mooney | you kind of already do | 14:44 |
| sean-k-mooney | you know its hosts and the segment mappings | 14:45 |
| sean-k-mooney | but again only in the routed networks case | 14:45 |
| *** rpittau is now known as rpittau|afk | 14:46 | |
| sean-k-mooney | increasing the dhcp agent count would not guarenttee it is on the leaf site right | 14:47 |
| sean-k-mooney | it could add another instnace to the central site in principal | 14:47 |
| ralonsoh | ok, I was looking for the BZ | 14:47 |
| ralonsoh | https://bugzilla.redhat.com/show_bug.cgi?id=1886622 | 14:47 |
| openstack | bugzilla.redhat.com bug 1886622 in openstack-neutron "Floating IP assigned to an instance is not accessible in scale up Multistack env with spine& leaf topology" [High,Assigned] - Assigned to ralonsoh | 14:47 |
| ralonsoh | it has public information about this error | 14:47 |
| amotoki | we can assume a deployment knows which network node belongs to which segment | 14:48 |
| slaweq | sean-k-mooney: right, that's why we propose to add scheduler which will schedule network to all dhcp agents | 14:48 |
| sean-k-mooney | so really when adding a new leaf site today you would have to expcitly add an instnace to the new agent deployed at that site | 14:48 |
| ralonsoh | amotoki, yes, that's correct | 14:48 |
| amotoki | if we deploy dhcp agent per segment, scheduling a netwokr to all dhcp agents will be a workaround | 14:48 |
| sean-k-mooney | amotoki: you could do both. all agent if not a routed network and per segment if it is. but per segement is just an optimisation really | 14:49 |
| amotoki | sean-k-mooney: yes, that's right | 14:49 |
| slaweq | TBH Liu's proposal about distributed dhcp would solve this use case also | 14:50 |
| ralonsoh | right (for OVS) | 14:50 |
| slaweq | ralonsoh: yep | 14:50 |
| ralonsoh | but would be desirable to have this dhcp scheduler to avoid the need of setting the exact number of DHCP agents needed | 14:51 |
| amotoki | yeah agree. deployments can continue to use DHCP agent they are familiar with too. | 14:52 |
| amotoki | I am not sure we need a new dhcp agent scheduler for this. | 14:52 |
| amotoki | Another option is to modify the current dhcp agent scheduler to accept an option like dhcp_agent_per_network=all | 14:52 |
| ralonsoh | agree | 14:53 |
| slaweq | amotoki: that may be good idea | 14:53 |
| *** e0ne has quit IRC | 14:54 | |
| ralonsoh | do you prefer to explore this idea? the change in the code will be smaller | 14:54 |
| slaweq | ralonsoh: I can | 14:54 |
| slaweq | and we will get back to that in next weeks | 14:54 |
| amotoki | anyway I am okay with the basic idea to assign a network to all agents. | 14:55 |
| ralonsoh | +1 to this idea | 14:55 |
| slaweq | so do You want to vote on approval rfe as an idea today, or wait more for some PoC code? | 14:55 |
| slaweq | (I will not vote as I proposed rfe) | 14:56 |
| mlavalle | +1 | 14:56 |
| ralonsoh | I can wait for a POC | 14:56 |
| amotoki | i am okay with either way | 14:56 |
| mlavalle | but we can surely approve the RFE | 14:56 |
| haleyb | +1 from me | 14:56 |
| mlavalle | if the PoC is not satusfactory, we can scrap it | 14:57 |
| mlavalle | I think we can trust slaweq | 14:57 |
| slaweq | thx :) | 14:57 |
| mlavalle | can't we? | 14:57 |
| ralonsoh | maybe... | 14:57 |
| ralonsoh | hehehehe | 14:57 |
| slaweq | :P | 14:57 |
| amotoki | hehe :) | 14:57 |
| slaweq | I don't trust myself so I'm not sure ;) | 14:57 |
| slaweq | but thank You | 14:57 |
| slaweq | I will mark this one as approved also | 14:57 |
| slaweq | this was really effective meeting | 14:57 |
| slaweq | 3 rfes approved | 14:58 |
| ralonsoh | sure | 14:58 |
| slaweq | thank You | 14:58 |
| mlavalle | o/ | 14:58 |
| slaweq | I think we can call it a meeting now | 14:58 |
| ralonsoh | bye! | 14:58 |
| slaweq | have a great weekend and see You online | 14:58 |
| amotoki | o/ | 14:58 |
| slaweq | o/ | 14:58 |
| slaweq | #endmeeting | 14:58 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings/" | 14:58 | |
| openstack | Meeting ended Fri Jan 8 14:58:33 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:58 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/neutron_drivers/2021/neutron_drivers.2021-01-08-14.00.html | 14:58 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/neutron_drivers/2021/neutron_drivers.2021-01-08-14.00.txt | 14:58 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/neutron_drivers/2021/neutron_drivers.2021-01-08-14.00.log.html | 14:58 |
| *** jamesmcarthur has joined #openstack-meeting | 15:06 | |
| *** jamesmcarthur has quit IRC | 15:10 | |
| *** TrevorV has joined #openstack-meeting | 15:22 | |
| *** e0ne has joined #openstack-meeting | 15:27 | |
| *** macz_ has joined #openstack-meeting | 15:46 | |
| *** macz_ has quit IRC | 15:46 | |
| *** macz_ has joined #openstack-meeting | 15:47 | |
| *** dklyle has joined #openstack-meeting | 15:49 | |
| *** jgriffith has joined #openstack-meeting | 16:00 | |
| *** jamesmcarthur has joined #openstack-meeting | 16:01 | |
| *** trandles has left #openstack-meeting | 16:12 | |
| *** ociuhandu_ has joined #openstack-meeting | 16:28 | |
| *** ircuser-1 has quit IRC | 16:29 | |
| *** ociuhandu has quit IRC | 16:31 | |
| *** ociuhandu_ has quit IRC | 16:33 | |
| *** ociuhandu has joined #openstack-meeting | 16:38 | |
| *** whoami-rajat__ has quit IRC | 16:39 | |
| *** timburke has joined #openstack-meeting | 16:42 | |
| *** ociuhandu has quit IRC | 16:44 | |
| *** gyee has joined #openstack-meeting | 16:58 | |
| *** jamesmcarthur has quit IRC | 17:04 | |
| *** jmasud has joined #openstack-meeting | 17:31 | |
| *** jmasud has quit IRC | 17:47 | |
| *** jmasud has joined #openstack-meeting | 17:57 | |
| *** jawad_axd has quit IRC | 18:05 | |
| *** xinranwang has quit IRC | 18:16 | |
| *** ralonsoh has quit IRC | 18:17 | |
| *** ociuhandu has joined #openstack-meeting | 18:48 | |
| *** ociuhandu has quit IRC | 18:53 | |
| *** jamesmcarthur has joined #openstack-meeting | 19:23 | |
| *** jmasud has quit IRC | 19:33 | |
| *** jawad_axd has joined #openstack-meeting | 19:38 | |
| *** jmasud has joined #openstack-meeting | 19:58 | |
| *** jamesmcarthur has quit IRC | 20:11 | |
| *** jamesmcarthur has joined #openstack-meeting | 20:22 | |
| *** e0ne has quit IRC | 20:24 | |
| *** jamesmcarthur has quit IRC | 20:39 | |
| *** diablo_rojo__ has joined #openstack-meeting | 20:59 | |
| *** rfolco has quit IRC | 21:11 | |
| *** afazekas has quit IRC | 21:12 | |
| *** slaweq has quit IRC | 21:13 | |
| *** jmasud has quit IRC | 21:20 | |
| *** jawad_axd has quit IRC | 21:20 | |
| *** TrevorV has quit IRC | 21:26 | |
| *** jmasud has joined #openstack-meeting | 21:29 | |
| *** jmasud has quit IRC | 21:31 | |
| *** jmasud_ has joined #openstack-meeting | 21:31 | |
| *** jmasud_ has quit IRC | 21:47 | |
| *** jamesmcarthur has joined #openstack-meeting | 22:14 | |
| *** jamesmcarthur has quit IRC | 22:17 | |
| *** timburke_ has joined #openstack-meeting | 22:31 | |
| *** timburke has quit IRC | 22:34 | |
| *** jmasud has joined #openstack-meeting | 23:50 | |
| *** jmasud has quit IRC | 23:54 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!