14:00:59 <slaweq> #startmeeting neutron_drivers
14:01:00 <openstack> Meeting started Fri Oct  4 14:00:59 2019 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:04 <openstack> The meeting name has been set to 'neutron_drivers'
14:01:07 <mlavalle> o/
14:01:09 <yamamoto> hi
14:01:14 <slaweq> hi
14:01:14 <gregoiremahe> Hello
14:01:41 <slaweq> hi gregoiremahe
14:02:09 <amotoki> hi
14:02:42 <slaweq> ok, I think we have quorum now so we can start :)
14:03:00 <slaweq> #topic RFEs
14:03:14 <slaweq> first on my list is one from last week:
14:03:22 <slaweq> https://bugs.launchpad.net/neutron/+bug/1843211
14:03:22 <openstack> Launchpad bug 1843211 in neutron "network-ip-availabilities' result is not correct when the subnet has no allocation-pool" [Wishlist,In progress] - Assigned to yangjianfeng (yangjianfeng)
14:03:30 <slaweq> thx mlavalle for Your input about that
14:04:37 <njohnston> o/
14:05:38 <slaweq> and thx amotoki for Your comment there too
14:06:06 <ileixe_> o/
14:07:07 <slaweq> personally I agree with Your comments - I first though about this as a bug because IMO we shouldn't use one attribute to provide 2 different informations conditionaly
14:07:30 <slaweq> but if You are saying that it is like that by design and we should keep it like that, than I'm ok with this
14:08:09 <slaweq> so IMO we should just update api-ref information about "total_ips" to reflect this conditional change of meaning for this attribute
14:08:11 <mlavalle> well, if you look at the code, that was clearly the intent of the developers and revieiwers who approved it
14:08:23 <slaweq> mlavalle: yes, I saw Your links :)
14:08:49 <slaweq> IMO it's more like "broken by design" but I can definitely live with it :)
14:08:56 <amotoki> I see two things: (1) the current API behavior looks intended (2) the current API response looks confusing and there is a room to add more information to provide detail information.
14:09:27 <amotoki> so I agree not to change the current behavior based on (1).
14:09:45 <mlavalle> yeah, even though the code is doing its original intent, I agree that that intent is a little confusing
14:09:59 <amotoki> what do you think about adding more attributes?
14:10:17 <slaweq> amotoki: with change proposed by You in last comment we would change current behaviour of "total_ips" value, right?
14:10:37 <slaweq> so we would do something what mlavalle didn't want to do
14:10:40 <mlavalle> in principle I'm open to it, but to be honest, I haven't seen yet a use case properly articulated
14:10:53 <amotoki> slaweq: what I think is not to touch "total_ips".
14:11:11 <amotoki> I am thinking to introduce new attributes in the response.
14:11:38 <njohnston> amotoki++ yes that is the only way to deal with developers that depend on the current behavior; Hyrum's Law strikes again
14:11:58 <slaweq> amotoki: but do You still want to keep current behaviour of total_ips, so if there is allocation pool it will have number of ips from allocation pools, and if not, number of ips based on cidr?
14:13:20 <amotoki> total_ips keep the current conditional behavior. subnet_total_ips and allocation_pools_total_ips can provide more information.
14:13:23 <slaweq> amotoki: because IIUC Your comment, first 2 proposed values from Your comment are in fact now covered by "total_ips", depends if allocation pools exists or not in subnet
14:13:44 <slaweq> ahh, ok
14:13:45 <amotoki> if allocation_pools exist total_ips will equal to allocation_pools_total_ips
14:13:50 <slaweq> amotoki: I understand now
14:14:01 <amotoki> :)
14:14:19 <slaweq> so You propose to keep total_ips as it is now, and add 2 new "total_ips_something" attributes
14:14:21 <slaweq> correct?
14:14:39 <amotoki> yes (on "total_ips" things)
14:15:01 <slaweq> ok, IMO it's very good idea
14:15:08 <amotoki> If we go to this route, "used_ips" can be improved too.
14:16:30 <slaweq> yes, I agree
14:16:55 <slaweq> so in fact we would need to add 3 new attributes according to Your proposal:
14:17:13 <slaweq> "subnet_total_ips"
14:17:19 <slaweq> "allocation_pool_total_ips"
14:17:21 <slaweq> and
14:17:31 <slaweq> "allocation_pool_used_ips"
14:17:37 <amotoki> yes
14:17:50 <slaweq> and we already have "used_ips" which is something like "subnet_used_ips"
14:18:11 <slaweq> I'm ok with this proposal
14:18:16 <slaweq> what do You all things?
14:18:23 <slaweq> *thinks
14:18:43 <amotoki> I am not sure we need "subnet_used_ips". if we need more consistent naming of attributes, "subnet_used_ips" makes sense even though it is dupicate to "used_ips".
14:19:31 <slaweq> yes, I also though that maybe we can add "subnet_used_ips" as duplicate of "used_ips" just to have more consistent naming of new attributes
14:19:36 <mlavalle> so, "total_ips" and "used_ips" refer to the entire network, eight?
14:19:43 <mlavalle> right^^^^
14:19:51 <slaweq> mlavalle: not exactly
14:20:02 <slaweq> mlavalle: total_ips would still be conditional
14:20:06 <slaweq> as it is now
14:20:31 <mlavalle> yeah, I understand that, but refer to the aggregation of the subnets in the network
14:20:49 <mlavalle> whether they have allocation pools or not
14:21:16 <amotoki> ah.. good point
14:21:35 <slaweq> yes, but I think that new attributes would also refer to aggregation of subnets in the network but would be non conditional
14:22:00 <mlavalle> I am looking at these lines: https://github.com/openstack/neutron/blob/92f7484d2a59f0ee900eca7280f92f6c1c0de35e/neutron/db/network_ip_availability_db.py#L110-L111
14:22:11 <slaweq> this whole extension is to indicate number of IPs in the network, so it aggregate values from subnets
14:22:36 <mlavalle> so yes, we are saying the same thing
14:23:47 <mlavalle> so say a network mixes subnets with allocation pools and no allocation pools
14:24:06 <slaweq> yes
14:24:28 <mlavalle> the current behavior captures correctly the total-ips and the used-ips
14:24:46 <mlavalle> at the network level
14:25:12 <amotoki> mlavalle: yes, as long as IP address outside of allocation pools are not used
14:25:37 <mlavalle> now, if we want to do this at the subnet level, I think it is a completely different extension
14:25:58 <mlavalle> otherwise we are going to make a mess of this extension
14:26:10 <slaweq> but do we want to do it "per subnet"? I thought that those new values would be also "per network"
14:26:35 <amotoki> mlavalle: what I think is to add new attributes both to network-level and subnet-level (as a new API extension)
14:27:14 <mlavalle> and I'm ok with that. do we have the use case to justify that new extension, though?
14:27:48 <mlavalle> here's how I see the current situation:
14:28:05 <slaweq> so, to be clear, do You want to have now new API like:
14:28:09 <slaweq> /v2.0/network-ip-availabilities/{subnet_id}
14:28:11 <slaweq> also?
14:28:27 <slaweq> which will provide those ip availabilities info per subnet
14:28:39 <mlavalle> 1) We have an extension that is slightly confusing because, IMO, after looking at the history, it was developed to suit the needs of a particluar operator
14:29:11 <mlavalle> 2) Since current extension is slightly confusing, we can think of ways to improve it here
14:30:09 <mlavalle> 3) But if we lack the evidence of a strong use case, aren't we risking to add to the confusion in the enitre "ip availability realm", whether at the network or the subnet level
14:30:29 <mlavalle> ?
14:30:49 <slaweq> I'm really not sure about this ip availaibility per subnet - what would be the use case for that?
14:31:10 <mlavalle> I am not opposing improving the API, but I would like to do it based on a solid use case
14:31:14 <amotoki> on 3), at least I know a few cases where operators implemented custom tools due to the confusing behavior of the current API.
14:31:19 <slaweq> Per network it may tell operator that he is going to be out of IP addresses which users can use so should add new subnet to the network
14:31:20 <mlavalle> which so far this RFE hasn't articulated
14:31:58 <amotoki> in that cases, the reason was due to "used_ips". I can add an RFE on that if you want.
14:32:10 <mlavalle> amotoki: if you have the operator level evidence, I trust you. Let's just be careful articulating it
14:32:42 <amotoki> mlavalle: okay, let me add cases I know on "used_ips".
14:32:58 <yamamoto> amotoki: does the tool query db directly?
14:33:20 <amotoki> yamamoto: no, it was thru the API but we need more query on API.
14:33:43 <amotoki> like listing ports :p
14:35:11 <mlavalle> what if we start a spec and "cook it" slowly all the way to "well done" with the community assistance?
14:35:36 <slaweq> mlavalle +1
14:35:39 <amotoki> +1
14:35:49 <slaweq> I thnink that this becoming more and more "complicated" :)
14:35:55 <slaweq> so spec would be good probably
14:36:00 <njohnston> +1
14:36:19 <yamamoto> +1
14:36:20 <slaweq> mlavalle: will You propose such spec?
14:36:58 <mlavalle> yeah I can push an inital patch. Not necessarilly by neext week, but soon
14:37:06 <slaweq> mlavalle: great, thx
14:37:24 <slaweq> so I will write comment with summary of our discussion about it in bug report
14:37:50 <slaweq> ok, I think we can move on to the next one on the list
14:37:54 <mlavalle> in the comment, ask submitter for a better articulated use case
14:38:03 <slaweq> mlavalle: sure, I will ask
14:38:09 <mlavalle> we want to know the why, not the how
14:38:22 <slaweq> yes, I agree
14:38:33 <slaweq> how is quite easy in this case IMO :)
14:38:48 <mlavalle> yeah, just read the damn code
14:38:48 <slaweq> ok, next rfe now :)
14:38:52 <slaweq> https://bugs.launchpad.net/neutron/+bug/1843218
14:38:52 <openstack> Launchpad bug 1843218 in neutron "[RFE] allow to create record on default zone from tenants" [Wishlist,Triaged] - Assigned to Gregoire Mahe (gregoiremahe)
14:39:09 <slaweq> gregoiremahe: Your turn :)
14:40:02 <gregoiremahe> Ok, so today at OVH we have many users, and we want to enable default zone for them
14:41:07 <gregoiremahe> So basically, we just want to parse domain setup on network, and replace <tenantid> by the user tenant
14:41:48 <mlavalle> I have interacted with gregoiremahe over the past few weeks over this RFE
14:42:29 <mlavalle> and it identifies correctly, IMO, a gap in the current DNS integration extension
14:43:04 <mlavalle> the current functionality was geared to tenants who have their onw networks
14:43:42 <mlavalle> and want to publish DNS records of ports and VMs in that tennt network
14:44:10 <mlavalle> gregoiremahe's use case referes to a ituation where the network is shared by all the users / tenants
14:44:25 <mlavalle> one big network or a limited number of them
14:44:31 <mlavalle> right gregoiremahe?
14:45:02 <gregoiremahe> yes, that's right, so we would like to setup <tenantid>.defaultzone.com. on the network with openstack network set --dns-domain
14:45:33 <mlavalle> --dns_domain == defaulzone.com, right?
14:46:13 <gregoiremahe> either this, either <tenantid>.defaultzone.com., and just parsing and replace <tenantid> in dns integration
14:46:44 <gregoiremahe> That's will create a better flexibility to do so
14:46:58 <mlavalle> in fact, at my employer, we have a downstream implementation that does just that
14:47:30 <mlavalle> for example, my zone is 'mlavalle01-home.bf2.ows.oath.cloud.'
14:48:15 <mlavalle> and the dns_domain attribute of the share network is 'bf2.ows.oath.cloud.'
14:48:37 <mlavalle> so I've seen it work and makes sense to me :-)
14:48:47 <amotoki> do you mean to pass some format string as "dns_domain" like <tenantid>.example.net?
14:49:08 <amotoki> or is <tenantid> part added automatically?
14:49:26 <amotoki> anyway the use case makes sense to me.
14:49:50 <gregoiremahe> amotoki : I implemented the fact to have <tenantid> in dns_domain to replace by the tenantid, but both might be okay
14:50:07 <slaweq> this makes sense for me too
14:50:12 <slaweq> one question
14:50:47 <slaweq> if You want to implement replacement of <tenant_id> with tenant_id, why not add also some other "keywords" like "user_id", or "user_name" for example?
14:51:44 <gregoiremahe> Yea, I already though about that, but the tenantid variable was directly accessible, so I first implemented a feature this way
14:52:11 <slaweq> ahh, ok
14:52:31 <slaweq> other values would require api calls to e.g. keysone
14:52:43 <gregoiremahe> yep right
14:52:53 <amotoki> perhaps we can support replacements for fields which are availabel in neutron.context.
14:52:59 <slaweq> ok, so <tenant_id> as for now makes sense
14:53:32 <slaweq> and we can always extend this list of "keywords" in the future if that will be needed
14:53:36 <yamamoto> mlavalle: where is the "mlavalle01-home" part?
14:53:40 <yamamoto> what's
14:53:51 <mlavalle> gregoiremahe: fwiw, this is an example of the A record of one of my VMs: 8e871e12.mlavalle01-home.bf2.ows.oath.cloud.
14:54:36 <mlavalle> yamamoto: mlavalle01-home is associated to my certificate
14:54:48 <gregoiremahe> mlavalle : And what is 8e871e12 ? Is that your server name ?
14:55:12 <mlavalle> x.509 certificate that we use internally to authenticate
14:55:34 <mlavalle> and yes 8e871e12 is just a VM name
14:56:28 <mlavalle> since this is for upstream, the 'mlavalle01-home' may be changed to the project id
14:56:46 <mlavalle> or tenant id, whatever your naming preference is
14:57:15 <amotoki> I think we can use these keywords https://github.com/openstack/neutron-lib/blob/master/neutron_lib/context.py#L74-L85
14:57:26 <amotoki> they looks enough for our need discussed here.
14:57:57 <slaweq> amotoki: ohh, if we have all of that available in context, that would be nice IMO :)
14:58:50 <slaweq> anyway, we are almost on time with this meeting
14:59:04 <slaweq> IMO we can approve this RFE
14:59:09 <mlavalle> +1
14:59:13 <amotoki> it looks good to me to approve this and the next step would be to write a spec on this
14:59:27 <mlavalle> yeap, a spec would be good
14:59:33 <slaweq> with either using only project_id for now, or using all those keywords pointed by amotoki if that is possible to get in extension
14:59:34 <yamamoto> +1 to have a spec
15:00:00 <slaweq> ok, so let's approve that rfe for now
15:00:09 <slaweq> gregoiremahe: will You write spec for this?
15:00:09 <amotoki> just in time :)
15:00:26 <slaweq> ok, thx for attending and have a great weekend
15:00:32 <yamamoto> good night
15:00:32 <gregoiremahe> Yep, just need to know how to do this and what format cause that will be my first one
15:00:32 <slaweq> we have to finish for today
15:00:38 <njohnston> \o
15:00:41 <slaweq> #endmeeting