14:00:10 <mlavalle> #startmeeting neutron_drivers
14:00:11 <openstack> Meeting started Fri Sep 28 14:00:10 2018 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:15 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:21 <slaweq> hi
14:00:23 <yamamoto> hi
14:00:34 <mlavalle> hi everyone
14:00:50 <mlavalle> let's give a couple of minutes to others to show up
14:00:57 <njohnston> o/
14:01:04 <mlavalle> amotoki won't join, since he is off on vacation this week
14:01:36 <mlavalle> how was your month long vacation, yamamoto?
14:01:43 <haleyb> hi
14:02:21 <mlavalle> ok, let's get going
14:02:25 <yamamoto> mlavalle: exausted playing with my son
14:02:54 <mlavalle> yamamoto: yeap, that's what parenting is all about. They have endless energy, and we don't anymore ;-)
14:03:02 <mlavalle> LOL
14:03:05 <slaweq> :)
14:03:20 <mlavalle> #topic RFEs
14:03:37 <mlavalle> so let's pick up where we left off last time....
14:03:47 <mlavalle> https://bugs.launchpad.net/neutron/+bug/1785213
14:03:47 <openstack> Launchpad bug 1785213 in neutron "[RFE] Automatically allow incoming DHCP traffic for networks which uses external dhcp server" [Wishlist,Triaged] - Assigned to Slawek Kaplonski (slaweq)
14:04:39 <slaweq> I added some comment today to it, if there are any questions I can try to answer them now :)
14:05:58 <njohnston> I commented on it: for customers that use fwaas, I was wondering if you see this as something that can be communicated to fwaas, or will it just be incompatible with fwaas?
14:06:49 <slaweq> njohnston: I think that it depends on fwaas - there can be same thing done there as in security groups driver if this flag is set for subnet
14:08:58 <mlavalle> so really the attribute you propose has only effect on the "walls", be it security groups or fwaas. nothing else is changed
14:09:12 <slaweq> mlavalle: yes
14:09:20 <slaweq> all of that can be achieved now also
14:09:30 <mlavalle> yes
14:09:34 <mlavalle> but manually
14:09:41 <slaweq> but I had such request that it would be more "user friendly" to have such additional flag to set
14:09:42 <mlavalle> you are proposing a shortcut
14:09:48 <slaweq> exactly :)
14:10:06 <njohnston> OK.  So if this flag gets set for an existing subnet then that would generate an RPC message to the agent to adjust the fw rules.  That part of the code would need to include a notification to the fwaas plugin so it could generate an fwaas RPC message.
14:10:55 <mlavalle> njohnston: would that be too much of a problem in fwaas?
14:11:35 <njohnston> I think fwaas could handle it without any issue, it's just something that would need to be built in at the api server
14:12:15 <slaweq> njohnston: yes, so we have to keep it in mind that there is fwaas also, thx for pointing that
14:12:33 <yamamoto> is there a plan for "how to make external dhcp server aware of what IPs should be assigned to OS instances" part?
14:12:42 <slaweq> yamamoto: no
14:13:06 <slaweq> yamamoto: basically this rfe assumes that operator knows what he is doing by using this
14:13:13 <slaweq> and what can be consequences
14:14:20 <yamamoto> having only this shortcut seems a little strange for me. is this a scenario common enough to warrant the shortcut?
14:15:03 <slaweq> I had such request from our customer, I don't know if that is very common use case, probably not
14:15:28 <mlavalle> yeah, we cannot assume is very common
14:15:29 <yamamoto> one customer?
14:15:44 <mlavalle> we would have heard of it before, I would think
14:15:47 <slaweq> yep
14:17:01 <mlavalle> maybe it is too much just for one customer / user
14:17:18 <slaweq> it may be like that
14:17:51 <mlavalle> I propose one of two option (or a combination of both): leave this rfe pending until somone shows up. and / or ask in the ML
14:17:55 <slaweq> so let's maybe postpone it for now and if there will be some new requests for this, we can return it
14:18:00 <njohnston> Is this something where it would be good to solicit feedback from the openstack-ops list?
14:18:22 <mlavalle> yeah, ^^^^ that's what I meant by the ML
14:18:41 <slaweq> ok, I will send email about that to operators ML then
14:18:46 <mlavalle> let's postpone it and ask the operators
14:19:26 * mlavalle leaving comment and marking rfe postponed
14:19:58 <slaweq> ok, thx
14:21:06 <mlavalle> Done
14:21:12 <njohnston> last question on this: does turning things over to an external dhcp server assume disabling all ipam functionality for that subnet?
14:21:49 <slaweq> njohnston: no, I didn't think about that
14:21:53 <njohnston> nm, I'll ask on launchpad and if we reveve it we can figure it out then :-)
14:22:03 <njohnston> *revive
14:22:06 <slaweq> njohnston: but maybe we can think about it later
14:22:40 <mlavalle> ok, let's move on
14:22:49 <mlavalle> https://bugs.launchpad.net/neutron/+bug/1784879
14:22:49 <openstack> Launchpad bug 1784879 in neutron "Neutron doesn't update Designate with some use cases" [Wishlist,Triaged]
14:24:45 <slaweq> so if I understood corectly last comments, it would be added to network and all ports from such network will have this option turned on, right?
14:24:57 <mlavalle> yes
14:25:38 <mlavalle> that's what the suggestion is to hit a middleground in terms of not too little, not too much granularity
14:26:55 <slaweq> IMO it sounds reasonable for the beginning, if later will be need to add it on port level, it can be added easily, right?
14:28:05 <mlavalle> I think so. At that point we wiull need to think about whose atribute overrides other attributes. Probabble, the more granular the resource, the higher the priority
14:28:49 <slaweq> yes, but I think that doing (later) network and port level could be enough
14:29:02 <slaweq> and then port attribute would override network attribute
14:29:11 <mlavalle> yeap
14:29:22 <slaweq> because problem with subnets is that one port can have more than one subnet so here it would be tricky
14:29:37 <slaweq> but port and network should be easy (as it is in e.g. QoS now)
14:29:41 <mlavalle> that was exactly my thinking
14:30:14 <mlavalle> the way it is implemented today, we take all the ip addresses form the port and create a recordset for all of them
14:30:37 <mlavalle> well, one ipv4 recordset and one ipv6 recordsert
14:30:58 <yamamoto> as it's about ip addresses, i tend to think subnet is a more natural choice than network
14:33:04 <mlavalle> from the tcp / ip layers logic point of view, you are right. ip addresses are a layer above network....
14:33:38 <mlavalle> is that what you meant?
14:33:43 <yamamoto> i even feel it has some correlations with service_types
14:35:22 <mlavalle> would you elaborate?
14:35:52 <yamamoto> i meant subnet is more natural for this specific feature
14:36:15 <mlavalle> would you elaborate the service types idea?
14:36:23 <yamamoto> as a user would set up a subnet routable from outside
14:37:24 <yamamoto> service_types describe the purpose of subnet. this new field does similar.
14:37:46 <mlavalle> and that signals that we want that fixed ips from that range should be sent to the external DNS service
14:38:24 <mlavalle> right?
14:38:33 <yamamoto> yes
14:38:54 <mlavalle> IMO, it is an excellent proposal
14:39:05 <mlavalle> what do others think?
14:39:09 <slaweq> so yamamoto You propose to use service_types field instead of adding new one somewhere?
14:39:17 <slaweq> am I understand correctly?
14:39:18 <yamamoto> well, i'm not suggesting to unify it with service types. (i'm not sure if it should)
14:39:26 <mlavalle> yes, with a new service type
14:39:28 <yamamoto> i'm suggesting it belongs to subnet
14:40:13 <mlavalle> but that's exactly the purpose of service types
14:40:25 <mlavalle> to indicate that a subnet has a special treatment
14:40:31 <mlavalle> given its service type
14:40:36 <mlavalle> right?
14:40:53 <slaweq> ok, but then how it would work if port would have IPs from two subnets and one would have this enabled and second no? we would need to change existing logic to create recordsets not for all IPs from port but only for some of them, right?
14:41:22 <mlavalle> yes, but I don't think that is a big deal
14:41:24 <yamamoto> maybe. but service type is just a string. it might not be descriptive enough for some use cases.
14:41:30 <slaweq> I'm fine with it but just asking to understand correctly what will be to do
14:42:17 <mlavalle> haleyb, you are "mr service type". what do you think?
14:42:24 <haleyb> service type is also a subset of device_owner values
14:42:36 <haleyb> yes, i was re-educating myself
14:42:41 <mlavalle> LOL
14:43:29 <mlavalle> so, do you think service type is appropriate for this rfe?
14:43:51 <haleyb> so i'm not sure how it would work given it's a device_owner, or empty
14:45:02 <haleyb> doesn't seem to fit the model to me at least
14:45:04 <mlavalle> well, any other potential attribute would be the same. either the user specifeid it or it is empty / NOne
14:45:53 <mlavalle> fair enough
14:46:47 <mlavalle> based on the discussion, I suggest go back to the rfe and propose dns_publish_fixed_ip at the subnet level....
14:46:51 <mlavalle> opinions?
14:47:02 <slaweq> but can't it be something like e.g. "compute:dns_publish_fixed_ip" as service type?
14:47:23 <haleyb> mlavalle: the service_type is a list, so can contain multiple things
14:47:31 <haleyb> and yes, it can be any string we want
14:47:32 <slaweq> which would means that compute ports will have published IPs
14:48:05 <mlavalle> that's what I understood^^^^^ when yamamoto originally brought up service types
14:48:16 <yamamoto> i didn't know it was a list
14:48:44 <slaweq> https://github.com/openstack/neutron/blob/master/neutron/extensions/subnet_service_types.py#L37 <-- here is validator of this attribute
14:48:53 <haleyb> the intention was for IP allocation on a network based on ports getting attached
14:49:54 <haleyb> so startswith('compute') is all it's matching in most cases
14:50:16 <mlavalle> haleyb: so we only refere to it in the IPAM code?
14:51:17 <haleyb> mlavalle: it's been a while, but yes from what i remember it's IPAM where we actually use the type
14:53:04 <yamamoto> at this point i feel a separate boolean field in subnet would be simpler than overloading service types with a magic owner value
14:53:36 <haleyb> i'd have to think some more on implementation, the [] is a wildcard match and if it's ['compute:dns_publish'] what would break?
14:54:11 <mlavalle> from the docs: "Service subnets enable operators to define valid port types for each subnet on a network...."
14:54:42 <mlavalle> so based on this definition, I agree with yamamoto's latest statement
14:54:53 <munimeha1> hi
14:54:59 <munimeha1> sorry got late
14:55:01 <slaweq> we can then break allocation of IPs from such subnet
14:55:07 <slaweq> yamamoto++
14:55:34 <mlavalle> https://docs.openstack.org/neutron/latest/admin/config-service-subnets.html
14:56:07 <haleyb> "Creating a subnet with a service type requires administrative privileges." - that might also be a problem
14:56:21 <mlavalle> yeah
14:57:28 <mlavalle> so I propose I go back to the RFE, and propose dns_publish_fixed_ip at the subnet level
14:57:37 <mlavalle> and we retake the discussion next meeting
14:57:52 <slaweq> fine for me
14:57:57 <yamamoto> +1
14:58:05 <mlavalle> ok
14:58:52 <mlavalle> munimeha1: We won't have time to discuss your RFE, we are 2 minutes away from end of meeting. slaweq and I left some comments in your new RFE. Let's discuss there over the next few days
14:59:10 <mlavalle> Thanks for attending guys. Have a very nice weekend!
14:59:12 <munimeha1> thats fine  I opened the RFEhttps://bugs.launchpad.net/neutron/+bug/1794771
14:59:12 <openstack> Launchpad bug 1794771 in neutron "SRIOV trunk port - multiple vlans on same VF" [Wishlist,New]
14:59:23 <slaweq> thx, have a good weekend!
14:59:24 <munimeha1> https://bugs.launchpad.net/neutron/+bug/1794771
14:59:36 <mlavalle> munimeha1: yes, that where we left comments / question
14:59:43 <mlavalle> #endmeeting