14:00:54 <slaweq> #startmeeting neutron_drivers
14:00:56 <openstack> Meeting started Fri Mar 19 14:00:54 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:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:59 <openstack> The meeting name has been set to 'neutron_drivers'
14:01:00 <mlavalle> o/
14:01:04 <johnsom> o/
14:01:07 <slaweq> o/
14:01:19 <haleyb> hi
14:01:21 <amotoki> hi
14:01:21 <johnsom> It has been a while since I attended a drivers meeting.
14:01:35 <mlavalle> we've missed you
14:01:36 <slaweq> johnsom: welcome (back) :)
14:01:40 <johnsom> lol
14:02:21 <johnsom> I thought I should join for the designate related RFE topics.
14:03:00 <slaweq> johnsom: that's great, thx for joining
14:03:23 <Carlotronics> hi
14:03:36 <lajoskatona> Hi
14:04:03 <slaweq> #topic RFEs
14:04:35 <slaweq> maybe we can wait few more minutes for amotoki yamamoto and njohnston
14:04:41 <slaweq> before we will start
14:05:25 <mlavalle> amotoki is here
14:05:27 <amotoki> hi
14:05:28 <slaweq> true
14:05:32 <slaweq> I somehow missed You
14:05:34 <slaweq> sorry amotoki
14:05:36 <amotoki> I already said here :)
14:05:37 <amotoki> np
14:05:48 <slaweq> so I think we can start
14:05:57 <slaweq> rfe to discuss today
14:06:00 <slaweq> https://bugs.launchpad.net/neutron/+bug/1904559
14:06:03 <openstack> Launchpad bug 1904559 in neutron "Designate driver: allow_reverse_dns_lookup doesn't works if dns_domain zone wasn't created" [Wishlist,New]
14:06:07 <slaweq> thx johnsom for comments there
14:07:48 <johnsom> My concern here is the current Designate integration weighs heavily on the forward zone for authorization. Decoupling that would mean we would likely want to do a significant rewrite.
14:08:32 <johnsom> Current PTR integration for neutron manages the PTR zones using the service account defined in neutron.conf [designate]
14:11:18 <mlavalle> what would be the outline of a new way to integrate with Designate?
14:11:22 <slaweq> so IIUC that rfe would require rewrite a lot of the neutron's part of dns integration, right?
14:12:01 <slaweq> but it don't require significant changes on designate side? is that correct?
14:12:42 <johnsom> Well, to avoid a case where anyone could create a port that adds a PTR record for any IP (valid)/domain, we would need to switch to validating that the user project creating the port has permission to create the PTR record in the zone in designate.
14:12:53 <johnsom> slaweq Correct.
14:13:26 <johnsom> To me, this seems to complicate the integration for the benefit of automating one PTR create call direct to designate for this edge case.
14:14:46 <johnsom> mlavalle At least that is one proposal I came up with. There may be other approaches
14:16:35 <slaweq> so based on Your comment I think that maybe we should reject that RFE
14:16:56 <slaweq> as it seems that effort and potential risks are too big according to the use case
14:16:57 <mlavalle> mhhhh
14:17:28 <mlavalle> the integration follows and extension and driver approach
14:17:32 <johnsom> It is certainly more involved than the proposed patch that decouples the forward zone.
14:18:20 <mlavalle> if we can somehow isolate the new approach in a separate driver and the submitter is willing to do the work
14:18:41 <johnsom> From a security perspective, PTR records are used to stop spam, some involved TLS certificate validation, etc.
14:19:09 <mlavalle> that way we preserve and don't put at risk what we have and let this use case go ahead
14:19:29 <johnsom> Sure, an alternate driver is an option.
14:19:35 <slaweq> mlavalle: but if that would be separate driver, it don't need to be in neutron tree, right?
14:19:49 <mlavalle> why not?
14:20:00 <mlavalle> I wouldn't mind it to be in our tree
14:20:04 <mlavalle> just isolated
14:20:04 <slaweq> ok
14:20:22 <mlavalle> self contained is a better way to put it
14:20:32 <johnsom> It could also be a setting that changes the PTR authentication model.
14:21:06 <johnsom> And lots of docs... lol
14:21:08 <mlavalle> so we could conditionally approve this RFE and make it subject to a spec
14:21:18 <mlavalle> see if we can spec it out
14:21:29 <johnsom> +1 for a spec
14:21:34 <slaweq> +!
14:21:36 <slaweq> +1
14:21:48 <mlavalle> and yes, as the wisemnan of Oregon said above, lots of docs
14:22:09 <johnsom> grin
14:22:20 <amotoki> I am okay for a spec (I am in a way to understand this)
14:22:49 <slaweq> so I will mark rfe as approved as a concept and we will continue discussion about details in the spec's review
14:22:53 <slaweq> ok for You?
14:22:58 <johnsom> +1
14:23:01 <mlavalle> +1
14:23:04 <amotoki> +1
14:23:21 <haleyb> +1
14:23:29 <slaweq> ok, that's done
14:23:31 <slaweq> thx
14:23:54 <slaweq> as we have Carlotronics here maybe we can talk als about second designate related rfe
14:23:57 <slaweq> https://bugs.launchpad.net/neutron/+bug/1918424
14:23:59 <openstack> Launchpad bug 1918424 in neutron "[RFE] RFC 2317 support in Neutron with designate provider" [Wishlist,New]
14:24:09 <slaweq> where johnsom asked some questions recently
14:24:27 <johnsom> This one I feel like I need more information about the use case.
14:26:03 <johnsom> As I mentioned above, the current Designate integration model is for PTR records to be "owned" by neutron. It abstracts the PTR zones completely and automatically creates the parent zone for an IP address if it doesn't exist today. This allows any IP to be properly handled without the RFC2317 strategy.
14:28:53 <slaweq> Carlotronics: did You saw johnsom's comments about Your RFE?
14:29:01 <slaweq> I think You were disconnected for some time
14:30:39 <Carlotronics> slaweq Yes I saw it, but I do not understand but I don't understand the relation; the problem exposed in the RFE is precisely that we can't currently have PTR on non octet-boundary zones
14:31:11 <Carlotronics> my internet connection is not very stable
14:32:09 <johnsom> Carlotronics How would you end up with a non-octet-boundary zone with the current designate integration?
14:33:37 <Carlotronics> I would let Neutron create it by specifying ipv4_ptr_zone and ipv4_ptr_record_template as stated in the rfe
14:33:38 <johnsom> The integration currently creates any required parent zone, sized to the prefix defined in the neutron.conf. You may end up with zones in Designate that a bigger than the subnet, but they are shared by the integration plugin.
14:34:28 <johnsom> I understand the proposal, I'm just not understanding the need or use case for this.
14:35:36 <Carlotronics> our use case is that our provider delegates us a /25, thus we cannot use the whole rDNS zone for it because it is already manager by our provider
14:36:39 <johnsom> Is this really about slicing up reverse zones, some are managed by neutron/Designate and some that are outside the cloud?
14:38:06 <Carlotronics> johnsom yes, and as far as I understand (but I could be wrong, I don't have much experience) rfc2317 is all about that
14:38:31 <johnsom> Ok, would you mind adding this use case example to the RFE? It was clear the proposed solution, but not the use case behind it.
14:39:19 <Carlotronics> johnsom sure, I'll do it
14:39:32 <johnsom> Carlotronics Yes. What mechanism would put the 0-25 records in the parent provider zone?
14:40:28 <johnsom> That would not be automated under this proposal right? There would be a required prerequisite step or two.
14:40:43 <Carlotronics> I hadn't thought about it. I'd be inclined to say it fills the area by hand, but maybe @Mareo could help me with that
14:41:12 <Carlotronics> johnsom no, this proposal would no be of any help on provider side (for setting CNAME and NS to 0-25 zone)
14:41:51 <johnsom> Ok, yeah. So I think we should discuss those steps.
14:42:11 <slaweq> johnsom: do You think we should have spec for that one too?
14:42:18 <johnsom> I hate to say it, but I would lean towards a spec on this one as well, just to capture the required workflow such that we can document it clearly.
14:42:34 <johnsom> slaweq You are a mind reader
14:42:45 <slaweq> :)
14:43:11 <slaweq> so I propose that we can also approve the rfe and next step will be spec with details to review
14:43:15 <slaweq> ok?
14:43:17 <johnsom> Otherwise we could have zones that don't work if the prerequisite steps were not completed.
14:43:26 <johnsom> +1 from me
14:44:19 <amotoki> yeah, +1 for a spec to clarify the whole picture including prerequisites. Prerequisites and assumptions look important part in this RFE.
14:45:20 <Mareo> johnsom, I don't understand, if you are able to put records in the parent zone, you do not need this mechanism at all
14:46:14 <Mareo> this RFE is targeted specifically for the case when the parent zone is managed by another entity than the one managing the openstack cluster
14:47:42 <Mareo> For instance wikimedia had the same issue : https://wikitech.wikimedia.org/wiki/Portal:Cloud_VPS/Admin/DNS/Designate#dns-floating-ip-updater
14:47:45 <johnsom> Mareo So, as the RFE is written,  the parent reverse zone, 2.0.192.in-addr.arpa. would require a NS record and a CNAME record for every potential IP in the /25 be pre-created. Then the integration would manage the 0-25 zone and map the IP to the xyz.example.com. reverse record.
14:48:17 <Mareo> yes, this is exactly what rfc 2317 is about
14:48:48 <johnsom> Mareo So, all of those CNAME records must be created in the parent zone my some means.
14:49:19 <risson> yes but that's the provider's job, it has nothing to do with designate/neutron
14:49:23 <risson> hi btw!
14:49:40 <johnsom> Mareo This is the prerequisite requirements I am commenting need to be captured and documented since the integration will not (per the current proposal) automate that.
14:50:01 <risson> it's virtually impossible to automate it
14:50:13 <risson> but yes, it indeed requires some documentation
14:50:26 <Mareo> I agree with the need to have some documentation
14:50:31 <johnsom> Lots of folks have interesting duct tape and bubble gum solutions to things... grin
14:51:51 <slaweq> so do we really need a spec before implementation? or simply documentation update together with implementation patch would be enough?
14:52:00 <johnsom> In my opinion, the RFE does not clearly define the "included in integration" and "prerequisites"/workflow. This is what we can clarify in the spec such that all that is needed gets documented.
14:53:23 <slaweq> I'm fine with that
14:53:44 <slaweq> so are You all ok with my earlier proposal - approve the rfe and to have spec as next step?
14:53:51 <mlavalle> +1
14:54:10 <amotoki> +1 from me
14:54:21 <amotoki> we need the whole picture in a spec to clarify what we need.
14:54:22 <johnsom> +1 I am in favor of a spec (doesn't have to be the full docs obviously)
14:54:31 <haleyb> +1
14:55:04 <johnsom> This can also solidify the changes needed on the Designate side to accommodate the hyphen, etc.
14:55:19 <slaweq> ok, thx
14:55:25 <slaweq> so we have an agreement
14:55:39 <slaweq> Carlotronics: can You write spec for that now?
14:55:58 <johnsom> Carlontronics I will help with the spec as well.
14:56:50 <slaweq> we are almost on top of the hour
14:57:02 <slaweq> so I just wanted to quickly ask You about checking https://review.opendev.org/c/openstack/neutron/+/780978
14:57:03 <Carlotronics> slaweq yes, I will work on it. thanks johnsom for the offer
14:57:07 <slaweq> Carlotronics: thx
14:57:22 <slaweq> we talked about that patch on Tuesday's meeting already
14:57:33 <slaweq> but I'm not sure if we really should relax those new policies
14:57:37 <amotoki> slaweq: I will add my reply soon. I am catching up the discussion on project with system-scoped token.
14:57:57 <slaweq> as they are "opt-in" for users, so by default old behaviour will still be the same as was until now
14:58:03 <slaweq> amotoki: thx
14:58:28 <slaweq> btw. I want to add release not to the wallaby release notes about those new secure rbac policies
14:58:42 <slaweq> but I will highlight it as experimental feature for now
14:58:50 <slaweq> I hope You are fine with it
14:59:26 <slaweq> and last think from me
14:59:31 <slaweq> please add patches from list
14:59:34 <slaweq> https://review.opendev.org/q/topic:%2522secure-rbac%2522+status:open+project:openstack/neutron
14:59:36 <slaweq> to Your review list :)
14:59:40 <slaweq> thx in advance
14:59:49 <slaweq> and that's all from me for today
14:59:53 <slaweq> thx for attending the meeting
15:00:03 <slaweq> have a great weekend
15:00:05 <slaweq> o/
15:00:09 <slaweq> #endmeeting