14:01:07 <slaweq> #startmeeting neutron_drivers
14:01:08 <openstack> Meeting started Fri Mar 12 14:01:07 2021 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:11 <openstack> The meeting name has been set to 'neutron_drivers'
14:01:14 <slaweq> hi
14:01:15 <mlavalle> o/
14:01:19 <amotoki> hi
14:02:19 <haleyb> hi
14:02:25 <slaweq> lets wait few more minutes for ralonsoh, haleyb, njohnston and yamamoto
14:02:32 <ralonsoh> hi sorry
14:02:35 <carlotronics_> hi
14:02:43 * haleyb must be invisible :)
14:02:56 <slaweq> haleyb: I see You, hi
14:03:12 <slaweq> I just hit enter almost in same time when You said hi :)
14:03:36 <slaweq> nate and yamamoto don't seems to be available so I think we can start
14:03:40 <slaweq> #topic RFEs
14:04:18 <slaweq> we have 2 rfes to discuss today
14:04:26 <slaweq> first one can be https://bugs.launchpad.net/neutron/+bug/1918424
14:04:27 <openstack> Launchpad bug 1918424 in neutron "[RFE] RFC 2317 support in Neutron with designate provider" [Wishlist,New]
14:04:30 <slaweq> as carlotronics_ is here
14:05:03 <slaweq> both of them aren't really triaged and maybe we will simply have more questions to ask therte
14:05:05 <slaweq> *there
14:05:22 <slaweq> but I wasn't able to triage it on my own as I'm not expert on dns stuff
14:05:50 <slaweq> so sorry, if RFEs aren't really ready but I was hoping to triage them together maybe
14:05:52 <slaweq> :)
14:06:10 <mlavalle> not a problem
14:10:41 <ralonsoh> can we have any class with dns_domain extension? just asking, I really need to check the code
14:10:52 <ralonsoh> clash*
14:11:38 <mlavalle> I don't think we would
14:12:23 <mlavalle> I think he poses a valid use case. I have two questions, though:
14:12:23 <slaweq> this would probably be new dns extension, maybe something what would even extend existing one
14:13:33 <mlavalle> 1) We should preserve current behaviour. In other words, deployers using dns integration as it is today shouldn't be required to do any additional configuration
14:13:52 <mlavalle> 2) How common is this use case?
14:14:26 <amotoki> I have an experience with this use case (in non-OpenStack deploymets).
14:14:43 <amotoki> In my understanding, It is needed when an operator would like to delegate address management to a use AND they also would like to delegate PTR management to a user.
14:15:09 <amotoki> If an operator manages /24 PTR (for example) it is not needed.
14:15:10 <carlotronics_> regarding 1), the proposals would not introduce any change in current configuration, only the ability to precise the zone name
14:15:23 <mlavalle> well, he states that PTR zone creation should be controlled by admins
14:16:05 <risson> creation of those zones by an admin doesn't mean you can't delegate creation of records in them by users
14:16:31 <mlavalle> agree
14:16:48 <amotoki> risson: right. it is my understanding
14:17:00 <mlavalle> risson: agree
14:17:29 <risson> for the use case, our provider only delegates us a /25, so we currently need to set the PTR records manually
14:18:31 <mlavalle> and that's a problem. I can see that
14:18:56 <Mareo> Afaik the Wikimedia fondation used to maintain a set of scripts to handle ptr record creation in a similar situation
14:19:26 <Mareo> (on their OpenStack clusters)
14:22:02 <mlavalle> Mareo: would it be a better dns / neutron integration if we implemented this proposal or something based on it?
14:24:04 <slaweq> one question, in rfe You mentioned something like "When absent, the old behavior of `ipv4_ptr_zone_prefix_size` or `ipv6_ptr_zone_prefix_size` is kept."
14:24:12 <mlavalle> carlotronics_: do you have a sense of what might be the answer to question 2. Given Mareo 's comment, it may be somewhat common
14:24:23 <slaweq> shouldn't we maybe consider deprecation of those old options in the future?
14:24:29 <slaweq> if we will implement the new one
14:24:31 <slaweq> ?
14:25:58 <Mareo> the old mecanism shoult not be deprecated imo, because it allow a form of implicit configuration. The new one is introduced to handle a specific use-case and it is more likelly to be set by IP Pool rather than globally on the cluster
14:26:18 <slaweq> k, got it
14:26:20 <slaweq> thx
14:26:23 <carlotronics_> slaweq: I think they are complementary
14:26:42 <mlavalle> yeah, that was my pioint in my comment number 1 above
14:27:02 <amotoki> i have another question: if we support this proposal, do we need some change in designate side or does designate already support this?
14:27:30 <slaweq> amotoki: yesterday I asked johnsom to take a look at it from the designate PoV
14:27:35 <mlavalle> amotoki: good question. I was going to ask it earlier and got derailed
14:27:35 <carlotronics_> no change absolutely needed, but one that would help: adding '/' in dns zone regex
14:27:36 <slaweq> I hope he will help us with it :)
14:28:31 <amotoki> carlotronics_: nice. it would be nice to mention it in the RFE.
14:28:36 <mlavalle> when I originally implemented dns integration, I always kep the Designate team involved. In fact, I attended their weekly meeting
14:28:39 <Mareo> yes the rfc suggest the use of '/' in the zone names, and the RE_ZONENAME variable in designate restrict the character set that can be used
14:28:55 <Mareo> we plan to submit a proposal to designate if this one is accepted
14:29:30 <Mareo> It already have been requested, but it didn't go anywhere (no formal refusal, but not approval neither)
14:30:36 <mlavalle> I see this proposal as a natural evolution of dns integration as it gets used in real situations. I say +1 to move ahead to a spec
14:31:43 <ralonsoh> +1 to this RFE
14:32:25 <slaweq> so, as ralonsoh already started :) are we ready to vote for this rfe, or do we want some more details to ask and get back to it next week maybe?
14:32:35 <slaweq> or maybe You have more questions now
14:32:40 <mlavalle> I already voted ^^^
14:32:56 <slaweq> true mlavalle  :)
14:33:02 <slaweq> so +1 from me too
14:33:08 <slaweq> amotoki, haleyb
14:33:24 <Mareo> if this was not perfectly clear already, carlotronics_ is willing to submit a patch for this proposal
14:33:28 <carlotronics_> one precision, I am willing to code this proposition
14:33:34 <carlotronics_> thanks Mareo
14:33:39 <amotoki> It sounds reaosnable to me. only question is whether we wait feedbacks from designate side like johnsom.
14:33:43 <slaweq> that is great, thx carlotronics_ :)
14:34:13 <haleyb> slaweq: i was going to mention making sure johnsom is aware as well, but fine with rfe
14:34:42 <slaweq> so, lets assume we are ok with it but I will not mark it as approved until we will have some feedback from johnsom
14:34:53 <slaweq> and if he will be ok, I will mark it as approved
14:34:56 <slaweq> is that ok for You?
14:35:00 <amotoki> +1
14:35:01 <mlavalle> +1
14:35:28 <Mareo> (to add a little bit of context, carlotronics_ is a student I supervize and he chose this RFE as a semester assignement, freely I swear!)
14:36:02 <mlavalle> carlotronics_: where are you going to school? What degree are your working towards?
14:36:09 <slaweq> nice
14:36:15 <amotoki> Mareo: carlotronics_: really nice.
14:36:17 <slaweq> I like school with such semester tasks :)
14:36:29 <slaweq> I wish I had similar when I was at school
14:37:04 <carlotronics_> mlavalle: EPITA, which is an engineering school in France
14:37:54 <mlavalle> carlotronics_: cool. We'll try to help you. Are there any timing constraints as far as finishing the project from the school point of view?
14:38:37 <Mareo> ideally it should be over before the end of june, but I can grade an incomplete project, so no pressure
14:38:48 <carlotronics_> I am quite free on timing; I should have until June to finish it, which should be ok
14:39:44 <mlavalle> Mareo, carlotronics_: This is really cool. Thanks for the proposal
14:39:45 <slaweq> carlotronics_: that should be totally fine :)
14:40:14 <slaweq> ok, I think we can move on to the second RFE now
14:40:17 <slaweq> https://bugs.launchpad.net/neutron/+bug/1904559
14:40:20 <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:40:29 <slaweq> also related to the PTR records and designate integration
14:42:36 <mlavalle> this one proposes to implement exactly what carlotronics_ and Mareo warned us against in their RFE
14:43:03 <mlavalle> in terms of security considerations
14:43:21 <ralonsoh> exactly and Jens' comment c#4 makes sense
14:43:54 <slaweq> true
14:43:59 <mlavalle> in fact, when I originally implemented dns integration I was loudly reminded by mugsie not to do it
14:44:06 <amotoki> mlavalle: but the RFE does not mention anything about classless PTR thing. I am not sure both are totally same.
14:44:23 <mlavalle> amotoki: I'm not saying they are the same
14:44:41 <amotoki> mlavalle: ah. it is just one case.
14:44:56 <mlavalle> I was just pointing to the security warning against letting user create ptr zones
14:45:22 <amotoki> got it
14:46:19 <mlavalle> imo, the next step is to have johnsonm look at it and see what he thinks. It is really something the DNS experts don't want us to do
14:46:36 <mlavalle> it's not that we cannot do it
14:46:56 <mlavalle> in fact, at some point during the original implementation, I was doing it
14:46:58 <mugsie> fwiw, designate already allows this weith the reverse DNS api
14:47:07 <mugsie> with*
14:47:27 <mugsie> so I don't think there would be a  huge issue with doing it automatically
14:48:00 <mugsie> (there is an API to set the PTR for any floating IP a project owns, without requiring that DNS Zone be hosted in Designate at all)
14:48:09 <mlavalle> mugsie: so why didn't we do it originally?
14:48:27 <mugsie> I am not sure - I think there was some timing issues?
14:49:04 <mugsie> https://docs.openstack.org/api-ref/dns/?expanded=set-floatingip-s-ptr-record-detail,list-floatingip-s-ptr-record-detail#floatingips is the API
14:49:27 <mlavalle> maybe this specific api didn't exist at the time
14:50:00 <mugsie> yeah, I think we were planning this when you were writing the integration, and we didn't want to hold up the integration for another cycle
14:50:45 <mlavalle> mugsie: thanks for jumping in !
14:50:50 <mugsie> np
14:51:17 <mlavalle> I propose having johnosonm take a look at it and go from there
14:51:37 <slaweq> ok, I can ask johnsom to take a look at it too
14:52:31 <slaweq> and we can get back to this next week
14:52:39 <slaweq> is that ok for all of You?
14:52:40 <mlavalle> +1
14:52:45 <amotoki> sounds good
14:52:48 <ralonsoh> ok
14:53:31 <slaweq> thx
14:53:34 <amotoki> my question was already covered by the above discussion and it was more than what I expected :)
14:53:49 <slaweq> I have one more heads up for You
14:54:01 <slaweq> lbragstad recently found bug https://bugs.launchpad.net/neutron/+bug/1918506 in Neutron
14:54:03 <openstack> Launchpad bug 1918506 in neutron "Neutron doesn't honor system-scope" [High,In progress] - Assigned to Slawek Kaplonski (slaweq)
14:54:11 <slaweq> I proposed fix for it https://bugs.launchpad.net/neutron/+bug/1918506
14:54:28 <slaweq> but it is in neutron-lib and needs to bumps few requirements
14:54:46 <slaweq> we are already after final release of the libs for Wallaby
14:54:55 <slaweq> but IMHO would be good to get this one in still
14:55:05 <ralonsoh> yes but this is a bug in W
14:55:13 <ralonsoh> we need to get it in this cycle
14:55:16 <mlavalle> yeah, otherwise we don't meet the community gosal
14:55:18 <mlavalle> goal
14:55:20 <slaweq> so I wanted to ask all of You to check that ASAP so we can eventualy as for exception
14:55:28 <ralonsoh> yes, should be
14:55:41 <slaweq> mlavalle: it's not community goal strictly but yes, many projects are implementing that this cycle
14:55:42 <amotoki> presicely speaking, secure RBAC is not the community gaol though :p
14:56:00 <ralonsoh> it is not?
14:56:04 <slaweq> nope
14:56:10 <ralonsoh> ok, thanks!
14:56:25 <slaweq> it is very important rfe for Red Hat for next OSP version :)
14:56:32 <mlavalle> still, we want to finish it, don't we?
14:56:36 <slaweq> mlavalle: yes
14:56:43 <slaweq> we did a lot of work already
14:56:50 <amotoki> even if we have a new release of neutron-lib, it just only affects neutron and other projects still can use the current release of neutron-lib.
14:56:56 <slaweq> and TBH requirements bumps are just to make them equal with neutron
14:57:02 <amotoki> so the impact of neutron-lib bump would be smaller.
14:57:06 <ralonsoh> agree
14:57:14 <slaweq> so in fact when neutron-lib is installed with neutron we already use those new versions
14:57:42 <slaweq> anyway, just a heads up and ask for quick review :)
14:58:13 <slaweq> it has -1 from zuul now but last PS already passed most of the jobs (lower-constraints for example)
14:58:18 <slaweq> so seems to be good now :)
14:58:34 <slaweq> ok, we are almost on top of the hour
14:58:41 <slaweq> thx for attending the meeting
14:58:45 <ralonsoh> have a nice weekend
14:58:49 <slaweq> and have a great weekend :)
14:58:55 <amotoki> you too all. thanks!
14:58:56 <slaweq> o/
14:59:00 <slaweq> #endmeeting