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