14:00:04 <mlavalle> #startmeeting neutron_drivers
14:00:05 <openstack> Meeting started Fri Aug  9 14:00:04 2019 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:08 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:14 <yamamoto> hi
14:00:22 <haleyb> hi
14:01:09 <mlavalle> let's give the others some time to congregate
14:02:00 <slaweq> hi
14:02:05 <mlavalle> amotoki is off on PTO
14:02:13 <mlavalle> here's slaweq
14:02:22 <slaweq> sorry for being late
14:02:29 <mlavalle> np
14:02:35 <mlavalle> #topic RFEs
14:03:05 <mlavalle> last week we left off talking about https://bugs.launchpad.net/neutron/+bug/1838621
14:03:06 <openstack> Launchpad bug 1838621 in neutron "[RFE] Configure extra dhcp options via API and per network" [Wishlist,Triaged] - Assigned to Slawek Kaplonski (slaweq)
14:03:36 <slaweq> sorry but I totally didn't have time to work on this
14:03:39 <mlavalle> did you have time to ponder about the extra dhcp options extensions and decide whether you want to pursue this RFE
14:03:44 <mlavalle> ?
14:03:53 <slaweq> so it's still waiting
14:03:55 <mlavalle> that's cool... not a problem
14:04:08 <mlavalle> so you want to leave for next week?
14:04:15 <slaweq> mlavalle: maybe lets mark it as postponed for now and I will ping You when I will be ready with this
14:04:16 <slaweq> ok?
14:04:27 <mlavalle> perfectly fine
14:04:30 <slaweq> it's not very urgent for me :)
14:04:33 <slaweq> thx
14:04:56 <mlavalle> done, postponed
14:05:06 <slaweq> thx a lot
14:05:19 <mlavalle> I'll also leave a comment that the next step is to compare your proposal with the extra dhcp options
14:05:30 <mlavalle> so you have a reminder of what the next step is
14:05:30 <slaweq> ok, sounds good for me
14:06:15 <mlavalle> next (and last) for today is https://bugs.launchpad.net/neutron/+bug/1837847
14:06:16 <openstack> Launchpad bug 1837847 in neutron "[RFE] neutron-vpnaas OpenVPN driver" [Wishlist,Triaged]
14:10:09 <mlavalle> the submitter seems to need guidance with the implementation, but in principle I don't see how an OpenVPN driver implementation can hurt
14:11:06 <slaweq> is my understanding correct that this will require some "extensions" (hook scripts) which will work on OpenVPN client's side and will talk with Neutron via API?
14:11:29 <mlavalle> that's the way he has implemented it so far, yes
14:12:22 <slaweq> ok, thx for confirmation
14:12:43 <slaweq> will those scripts be in neutron-vpnaas repo somewhere? Or somewhere else? Do You know?
14:13:13 <mlavalle> I would assume under the new drivers folder in the repo
14:13:23 <mlavalle> dirver's^^^
14:13:39 * mlavalle can't type
14:14:31 <slaweq> ok
14:20:29 <slaweq> TBH I don't have any really strong opinion about this RFE
14:20:40 <slaweq> I'm not vpnaas expert at all
14:21:00 <slaweq> but it looks for me that it may be quite complicated workflow to implement
14:21:32 <slaweq> so maybe some spec with more details could be useful also
14:22:39 <mlavalle> yes, I think we can question the implementation approach and a spec would be good
14:22:56 <slaweq> e.g. it says that vpn secrets will be stored in Barbican, but what if there will be no Barbican in the cloud? will it just fail to create it or will store secrets in some "fallback" mode?
14:23:22 <mlavalle> but in principle the proposal of an OpenVPN driver seems ok to me
14:23:56 <slaweq> for me too
14:24:16 <mlavalle> the Barbican stuff came about from the previous attempt 4 years ago to implement an OpnVPN driver
14:24:49 <mlavalle> the administration of the time -2ed the patch indicating that we needed to wait for Barbican to store the secrets
14:26:04 <slaweq> ok, so it seems that using Barbican should be mandatory when OpenVPN driver is used
14:26:24 <mlavalle> a pre-requisite that can be documented
14:27:12 <slaweq> yes, ok
14:28:00 <yamamoto> i guess we should discuss about api/semantics more than impl details
14:28:15 <mlavalle> fair point
14:28:28 <yamamoto> the submitter is saying it's using vpnservice object
14:28:53 <yamamoto> i'm not sure how it's used to describe l2 vpn
14:28:59 <yamamoto> (i haven't read the patch)
14:31:33 <mlavalle> so your concern is that the vpnservice object might not be sufficient to descrive a L2 vpn and therefore API changes might be required?
14:31:50 <yamamoto> yes
14:32:14 <mlavalle> describe^^^^
14:32:43 * mlavalle can't spell properly today either
14:33:35 <yamamoto> as he already has an impl, i guess we can just ask how vpnservice object looks like
14:33:44 <mlavalle> that's a very good point. What if the next step if to ask that question in the RFE and see what response we get?
14:34:04 <yamamoto> i'm interested in how/if vpnservice.router_id is used
14:34:49 <mlavalle> do you want to ask those questions directly in the RFE?
14:34:55 <yamamoto> yes
14:35:39 <mlavalle> great! let's ask those questions and we come back to this RFE next week
14:35:55 <slaweq> +1
14:36:40 <mlavalle> in that case, we are done for today unless there is some other RFE that I'm not aware of.....
14:37:33 <slaweq> not from me :)
14:38:14 <mlavalle> ok, let's call this a meeting...
14:38:18 <yamamoto> i put a question on the rfe
14:38:31 <mlavalle> thanks yamamoto
14:38:40 <mlavalle> have a great weekend
14:38:49 <slaweq> thx, have a great weekend :)
14:38:53 <mlavalle> and we'll do it all over again next week
14:38:59 <yamamoto> good night
14:39:03 <mlavalle> #endmeeting