14:00:54 #startmeeting neutron_drivers 14:00:56 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:59 The meeting name has been set to 'neutron_drivers' 14:01:00 o/ 14:01:04 o/ 14:01:07 o/ 14:01:19 hi 14:01:21 hi 14:01:21 It has been a while since I attended a drivers meeting. 14:01:35 we've missed you 14:01:36 johnsom: welcome (back) :) 14:01:40 lol 14:02:21 I thought I should join for the designate related RFE topics. 14:03:00 johnsom: that's great, thx for joining 14:03:23 hi 14:03:36 Hi 14:04:03 #topic RFEs 14:04:35 maybe we can wait few more minutes for amotoki yamamoto and njohnston 14:04:41 before we will start 14:05:25 amotoki is here 14:05:27 hi 14:05:28 true 14:05:32 I somehow missed You 14:05:34 sorry amotoki 14:05:36 I already said here :) 14:05:37 np 14:05:48 so I think we can start 14:05:57 rfe to discuss today 14:06:00 https://bugs.launchpad.net/neutron/+bug/1904559 14:06:03 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 thx johnsom for comments there 14:07:48 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 Current PTR integration for neutron manages the PTR zones using the service account defined in neutron.conf [designate] 14:11:18 what would be the outline of a new way to integrate with Designate? 14:11:22 so IIUC that rfe would require rewrite a lot of the neutron's part of dns integration, right? 14:12:01 but it don't require significant changes on designate side? is that correct? 14:12:42 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 slaweq Correct. 14:13:26 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 mlavalle At least that is one proposal I came up with. There may be other approaches 14:16:35 so based on Your comment I think that maybe we should reject that RFE 14:16:56 as it seems that effort and potential risks are too big according to the use case 14:16:57 mhhhh 14:17:28 the integration follows and extension and driver approach 14:17:32 It is certainly more involved than the proposed patch that decouples the forward zone. 14:18:20 if we can somehow isolate the new approach in a separate driver and the submitter is willing to do the work 14:18:41 From a security perspective, PTR records are used to stop spam, some involved TLS certificate validation, etc. 14:19:09 that way we preserve and don't put at risk what we have and let this use case go ahead 14:19:29 Sure, an alternate driver is an option. 14:19:35 mlavalle: but if that would be separate driver, it don't need to be in neutron tree, right? 14:19:49 why not? 14:20:00 I wouldn't mind it to be in our tree 14:20:04 just isolated 14:20:04 ok 14:20:22 self contained is a better way to put it 14:20:32 It could also be a setting that changes the PTR authentication model. 14:21:06 And lots of docs... lol 14:21:08 so we could conditionally approve this RFE and make it subject to a spec 14:21:18 see if we can spec it out 14:21:29 +1 for a spec 14:21:34 +! 14:21:36 +1 14:21:48 and yes, as the wisemnan of Oregon said above, lots of docs 14:22:09 grin 14:22:20 I am okay for a spec (I am in a way to understand this) 14:22:49 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 ok for You? 14:22:58 +1 14:23:01 +1 14:23:04 +1 14:23:21 +1 14:23:29 ok, that's done 14:23:31 thx 14:23:54 as we have Carlotronics here maybe we can talk als about second designate related rfe 14:23:57 https://bugs.launchpad.net/neutron/+bug/1918424 14:23:59 Launchpad bug 1918424 in neutron "[RFE] RFC 2317 support in Neutron with designate provider" [Wishlist,New] 14:24:09 where johnsom asked some questions recently 14:24:27 This one I feel like I need more information about the use case. 14:26:03 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 Carlotronics: did You saw johnsom's comments about Your RFE? 14:29:01 I think You were disconnected for some time 14:30:39 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 my internet connection is not very stable 14:32:09 Carlotronics How would you end up with a non-octet-boundary zone with the current designate integration? 14:33:37 I would let Neutron create it by specifying ipv4_ptr_zone and ipv4_ptr_record_template as stated in the rfe 14:33:38 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 I understand the proposal, I'm just not understanding the need or use case for this. 14:35:36 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 Is this really about slicing up reverse zones, some are managed by neutron/Designate and some that are outside the cloud? 14:38:06 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 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 johnsom sure, I'll do it 14:39:32 Carlotronics Yes. What mechanism would put the 0-25 records in the parent provider zone? 14:40:28 That would not be automated under this proposal right? There would be a required prerequisite step or two. 14:40:43 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 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 Ok, yeah. So I think we should discuss those steps. 14:42:11 johnsom: do You think we should have spec for that one too? 14:42:18 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 slaweq You are a mind reader 14:42:45 :) 14:43:11 so I propose that we can also approve the rfe and next step will be spec with details to review 14:43:15 ok? 14:43:17 Otherwise we could have zones that don't work if the prerequisite steps were not completed. 14:43:26 +1 from me 14:44:19 yeah, +1 for a spec to clarify the whole picture including prerequisites. Prerequisites and assumptions look important part in this RFE. 14:45:20 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 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 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 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 yes, this is exactly what rfc 2317 is about 14:48:48 Mareo So, all of those CNAME records must be created in the parent zone my some means. 14:49:19 yes but that's the provider's job, it has nothing to do with designate/neutron 14:49:23 hi btw! 14:49:40 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 it's virtually impossible to automate it 14:50:13 but yes, it indeed requires some documentation 14:50:26 I agree with the need to have some documentation 14:50:31 Lots of folks have interesting duct tape and bubble gum solutions to things... grin 14:51:51 so do we really need a spec before implementation? or simply documentation update together with implementation patch would be enough? 14:52:00 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 I'm fine with that 14:53:44 so are You all ok with my earlier proposal - approve the rfe and to have spec as next step? 14:53:51 +1 14:54:10 +1 from me 14:54:21 we need the whole picture in a spec to clarify what we need. 14:54:22 +1 I am in favor of a spec (doesn't have to be the full docs obviously) 14:54:31 +1 14:55:04 This can also solidify the changes needed on the Designate side to accommodate the hyphen, etc. 14:55:19 ok, thx 14:55:25 so we have an agreement 14:55:39 Carlotronics: can You write spec for that now? 14:55:58 Carlontronics I will help with the spec as well. 14:56:50 we are almost on top of the hour 14:57:02 so I just wanted to quickly ask You about checking https://review.opendev.org/c/openstack/neutron/+/780978 14:57:03 slaweq yes, I will work on it. thanks johnsom for the offer 14:57:07 Carlotronics: thx 14:57:22 we talked about that patch on Tuesday's meeting already 14:57:33 but I'm not sure if we really should relax those new policies 14:57:37 slaweq: I will add my reply soon. I am catching up the discussion on project with system-scoped token. 14:57:57 as they are "opt-in" for users, so by default old behaviour will still be the same as was until now 14:58:03 amotoki: thx 14:58:28 btw. I want to add release not to the wallaby release notes about those new secure rbac policies 14:58:42 but I will highlight it as experimental feature for now 14:58:50 I hope You are fine with it 14:59:26 and last think from me 14:59:31 please add patches from list 14:59:34 https://review.opendev.org/q/topic:%2522secure-rbac%2522+status:open+project:openstack/neutron 14:59:36 to Your review list :) 14:59:40 thx in advance 14:59:49 and that's all from me for today 14:59:53 thx for attending the meeting 15:00:03 have a great weekend 15:00:05 o/ 15:00:09 #endmeeting