14:00:21 <slaweq> #startmeeting neutron_drivers
14:00:22 <openstack> Meeting started Fri Apr 24 14:00:21 2020 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:25 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:28 <mlavalle> o/
14:00:32 <njohnston> o/
14:00:33 <yamamoto> hi
14:00:38 <slaweq> Good Morning/Afternoon/Evening :)
14:00:42 <haleyb> hi
14:01:32 <slaweq> before we start, short announcement
14:01:51 <slaweq> today ussuri-rc1 was releases for neutron
14:02:03 <slaweq> so we have stable/ussuri branches created already
14:02:23 <slaweq> if we will need anything to get there before GA, we will have to backport
14:02:36 <slaweq> end of announcement :)
14:03:19 <slaweq> let's wait 2-3 more minutes for amotoki
14:03:22 <slaweq> and we will start
14:04:41 <ralonsoh> hi
14:05:13 <slaweq> ok, lets start
14:05:22 <slaweq> #topic RFEs
14:05:26 <slaweq> we have one RFE for today
14:05:35 <slaweq> https://bugs.launchpad.net/neutron/+bug/1616208
14:05:35 <openstack> Launchpad bug 1616208 in neutron "[RFE] Support creating a subnet without an allocation pool" [Wishlist,Confirmed]
14:06:43 <slaweq> it's an old rfe but seems that it's still not implemented, and owner of it is still interested in doing that
14:07:26 <mlavalle> is he going to implement it?
14:07:51 <slaweq> mlavalle: I know only as much as is in his last comment
14:08:29 <slaweq> but if he don't have time to implement that, I can spend some time on it if needed
14:09:43 <slaweq> it seems for me that this is pretty simple modification of our API
14:10:18 <slaweq> as Neutron already supports empty allocation pools if You will do PUT to remove any pool which was created for subnet
14:18:13 * haleyb wonders if he was disconnected
14:18:29 <mlavalle> who, slaweq ?
14:18:38 <ralonsoh> I thought the same
14:18:40 <haleyb> it's just been 8 minutes
14:18:57 <slaweq> no, I'm still here
14:19:18 <slaweq> but I'm waiting for any responses to what I wrote :)
14:20:22 <haleyb> the API supports an [] so i'm ok with the change to the client, and i guess whatever fallout there is where the server code isn't expecting it maybe
14:21:41 <njohnston> I have no problem with this
14:21:52 <slaweq> haleyb: we will need to add some tempest tests to cover that but I think it shouldn't be really an issue :)
14:22:21 <haleyb> slaweq: sounds good to me
14:22:31 <ralonsoh> (now we can create a subnet /31 --> this won't create an allocation pool, but then will fail assigning an IP)
14:23:36 <slaweq> ralonsoh: but I think the issue of this failure is slightly different than what this rfe is trying to solve/change
14:23:47 <ralonsoh> yes, agree
14:24:48 <slaweq> and IIRC bcafarel was going to report and fix issue with /31 subnets
14:26:22 <mlavalle> I am also ok with it
14:26:32 <bcafarel> actually there is already old bug about it https://bugs.launchpad.net/neutron/+bug/1580927
14:26:32 <openstack> Launchpad bug 1580927 in neutron "spans beyond the subnet reported incorrectly in ipam" [Low,In progress] - Assigned to Tyler Britten (9-me-9)
14:27:08 <ralonsoh> welcome to Mitaka cycle!
14:27:10 <bcafarel> currently there is no allocation pool for /31 as they are not properly handled in code (fun fact /32 have one properly filled)
14:27:15 <bcafarel> back to the future :)
14:27:50 <slaweq> :)
14:28:47 <slaweq> yamamoto: any thoughts about such API/client change to allow None or [] as allocation pool for subnets in POST?
14:29:21 <yamamoto> [] has a different meaning already, doesn't it?
14:29:57 <slaweq> I think so, that why I said None or [] because it has to be checked to be sure
14:30:10 <slaweq> but probably we will need to use None as new value
14:30:31 <yamamoto> i'm fine with the rfe as far as the api change will be backward compatible
14:30:54 <slaweq> ok
14:30:55 <slaweq> thx
14:30:57 <yamamoto> i guess the no_allocation_pools approach in the proposed patch is safer
14:31:22 <slaweq> but that's for client's side, right?
14:31:36 <mlavalle> https://review.opendev.org/#/c/433234/
14:35:16 <ralonsoh> so the idea is to add a new attribute? no_allocation_pools
14:35:21 <ralonsoh> is that the idea?
14:35:49 <ralonsoh> and in the DB
14:36:16 <slaweq> I'm not sure if that is something what we really need
14:36:20 <slaweq> and for sure not for PUT
14:36:39 <slaweq> as this should IMO just tell server to not create allocation pool for subnet at all
14:37:04 <slaweq> in PUT You can already do that by sending [] in allocation_pool IIUC comments to this RFE
14:38:04 <haleyb> https://docs.openstack.org/api-ref/network/v2/?expanded=create-subnet-detail#subnets says "allocation_pools (Optional)"
14:38:31 <slaweq> haleyb: yes
14:38:35 <slaweq> and docs says "If allocation_pools are not specified, OpenStack Networking automatically allocates pools for covering all IP addresses in the CIDR"
14:39:15 <slaweq> IIUC this rfe is about adding some option to tell neutron-server "don't create this pool with whole CIDR"
14:40:31 <haleyb> ah, right, the API doesn't know we don't want that even when passing [] I guess?
14:41:07 <slaweq> that's my understanding of this RFE at least
14:41:09 <haleyb> although "not specified" != []
14:44:34 <slaweq> yes, I just tried
14:45:37 <slaweq> http://paste.openstack.org/show/792669/
14:46:18 <slaweq> and when I sent None as "allocation_pools" I got error BadRequest
14:48:59 <slaweq> so are we all fine to add possibility to send None as allocation_pools in POST to tell neutron to not create any allocation pool for this subnet?
14:49:20 <slaweq> IMO that's the main goal of this RFE
14:49:57 <yamamoto> do you mean null?
14:50:31 <njohnston> yes I am good with that
14:50:36 <haleyb> is it None or [] ?  since a PUT with [] works i would think the POST with it should do the same thing?
14:50:46 <slaweq> yamamoto: yes
14:51:04 <njohnston> +1 for null
14:51:21 <slaweq> haleyb: but changing to [] to not create any pool wouldn't be backward compatible
14:51:37 <slaweq> so I think that we should left it as it is now
14:51:53 <slaweq> and add null to explicity say "I don't want allocation pools"
14:52:03 <njohnston> right
14:52:59 <yamamoto> i'm ok with either ways (null or a new attribute)
14:53:09 <haleyb> i get it, just stinks that being explicit with [] doesn't work, but saying null gets you []
14:53:41 <slaweq> haleyb: I see Your point
14:53:53 <slaweq> and it would be better to do it Your way
14:54:03 <slaweq> but we have to be backward compatible :/
14:54:06 <haleyb> but then we break backwards-compat?
14:54:06 <ralonsoh> haleyb, agree but we should keep [] current behaviour, I think so
14:54:51 <mlavalle> yes
14:55:35 <haleyb> who wants api/v3, we can fix all the bugz :)
14:55:42 <ralonsoh> hehehe
14:55:45 <slaweq> haleyb: :)
14:56:04 <slaweq> or microversioning :P
14:56:31 <haleyb> i'm fine will null, it just gets back at last week's meeting where the info on the POST != the info on the GET wrt security groups
14:57:55 <haleyb> so +1 from me since we're running out of time
14:58:09 <njohnston> +1
14:58:16 <ralonsoh> +1 to null
14:58:44 <slaweq> mlavalle: You ok with it too?
14:59:04 <mlavalle> yes
14:59:13 <slaweq> ok, thx for all comments
14:59:19 <slaweq> I will mark this RFE as approved
14:59:27 <slaweq> have a great weekend
14:59:31 <mlavalle> o/
14:59:33 <slaweq> and see You all next week
14:59:37 <njohnston> o/
14:59:38 <slaweq> ahh, one thing
14:59:55 <slaweq> next week is 1st of May and it's public holiday in Poland
15:00:02 <slaweq> so I'm going to cancel this meeting
15:00:19 <slaweq> see You in 2 weeks on drivers meeting than :)
15:00:24 <slaweq> *then
15:00:26 <ralonsoh> see you then!
15:00:28 <slaweq> #endmeeting