15:03:41 <armax> #startmeeting neutron_drivers
15:03:42 <openstack> Meeting started Tue Dec  8 15:03:41 2015 UTC and is due to finish in 60 minutes.  The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:45 <openstack> The meeting name has been set to 'neutron_drivers'
15:04:01 <armax> just to provide a snapshot
15:04:05 <armax> we have 0 new RFE
15:04:13 <armax> 19 confirmed RFE
15:04:22 <armax> and 10 triaged
15:04:45 <armax> we’ve been going over the triaged ones over this meeting
15:05:00 <armax> for anyone who is not familiar with the format of this meeting
15:05:25 <armax> we assume that the triaged ones are those that have had a reasonable offline discussion already
15:05:40 <armax> and we make a synchronous decision during the online meeting
15:05:50 <armax> we go over bugs in the order they have been received
15:06:19 <armax> the members of the drivers team process the confirmed bugs offline and move them to triaged when there’s been enough offline discussion
15:06:33 <armax> anyone is welcome to attend and contribute
15:06:37 <armax> ok
15:06:40 <armax> let’s dive in
15:07:07 <armax> you guys with me?
15:07:29 <dougwig> With bells on
15:07:34 <armax> bug 1464465
15:07:34 <openstack> bug 1464465 in neutron "binding_type improvements to simplify Nova interactions" [Wishlist,Triaged] https://launchpad.net/bugs/1464465
15:07:35 * carl_baldwin didn't know all of that. now he does
15:08:03 <armax> this was reported by ianw a while back
15:08:16 * njohnston is appreciative for the process clarification, thanks armax
15:08:27 <armax> I recall kevinbenton making positive comments on this
15:08:34 <armax> unfortunately most of the heavy lifting is in nova
15:08:48 <armax> read comment #3
15:08:55 <armax> https://bugs.launchpad.net/neutron/+bug/1464465/comments/3
15:08:55 <openstack> Launchpad bug 1464465 in neutron "binding_type improvements to simplify Nova interactions" [Wishlist,Triaged]
15:09:34 <HenryG> Wrong ian FYI
15:09:41 <armax> HenryG: thanks
15:09:50 <armax> HenryG: I knew the irc looked funky
15:10:22 <carl_baldwin> anyone know if progress was made on the nova spec?
15:10:27 <armax> nova is in freeze right now
15:10:34 <armax> carl_baldwin: I don’t think it made it
15:10:41 <armax> I spoke with the Nova ptl
15:10:45 <dougwig> is this similar to the vif library stuff?
15:10:55 <armax> and they will be accepting only exception for priority items
15:10:59 <armax> dougwig: no
15:11:03 <amotoki> how is os-vif effort going? I think it is related too.
15:11:06 <armax> but the sounds of it
15:11:11 <armax> amotoki: yes
15:11:17 <armax> amotoki: it is tangentially related
15:11:47 <armax> so I’d be tempted to say: any effort at simplying the interface betweeren nova and neutron is +2 from me
15:11:48 <armax> but
15:11:53 <armax> the devils is in the details
15:12:13 * kevinbenton arrives late
15:12:18 <armax> kevinbenton: there you are!
15:12:30 <amotoki> agree. it would be nice if we can sync with nova progress.
15:12:34 <armax> anyhow let’s follow dougwig’s suggestion to time box bug discussion
15:12:47 <carl_baldwin> It kind of seems there isn't much we can do about this one until it is a Nova priority.
15:12:49 <armax> amotoki: I’ll sync up with nova
15:13:35 <armax> carl_baldwin: right, let me comment on this one, I think we should approve in principle, meaning we’ll give it enough attention at least from a specification point of view
15:13:52 <armax> the actual work may end up starting post-mitaka
15:13:53 <carl_baldwin> ++
15:13:59 <dougwig> +1
15:14:02 <amotoki> +1
15:14:28 <armax> #bug 1468236
15:14:28 <openstack> bug 1468236 in neutron "enable neutron support distributed DHCP agents" [Wishlist,Triaged] https://launchpad.net/bugs/1468236 - Assigned to shihanzhang (shihanzhang)
15:14:37 <armax> this is a tough nut to crack
15:14:54 <armax> there’s been a long discussion
15:14:56 <armax> two camps afaik
15:15:35 <armax> one that says: going fully distributed may be overkill and raise more problems than it solves
15:15:56 <armax> the other: ‘we gotta distributed all the things because it’s the right thing to do no matter what'
15:16:04 <armax> sorry for oversimplifying
15:16:14 <neiljerram> I guess that's me; but I was just trying to add useful info; not really in any 'camp'
15:16:29 <armax> neiljerram: your input was highly appreciated
15:16:32 <shz> thx neil
15:16:36 <armax> and I agree with most of your points
15:16:46 <HenryG> I am no dhcp expert but it seems to me dnsmasq is a constraint for doing distribution nicely
15:16:59 <armax> the problem I personally see is that dhcp is not really where the pain point lies from a scale perspective
15:17:14 <armax> dhcp gets out of the way relatively quickly
15:17:31 <armax> we have a somewhat nice HA dhcp story
15:17:37 <dougwig> where does it bottleneck?
15:17:47 <kevinbenton> (as long as you have them spread across enough agents)
15:18:03 <armax> kevinbenton: we have load based scheduling now
15:18:17 <armax> and distributing dhcp over computes with an agent based approach is a huge no-no from me
15:18:38 <kevinbenton> armax: right, but people that host 10000 networks on two agents run into issues
15:18:45 <armax> if DVR taught us anything is that we should be very careful on disseminating control plane logic all over the code base
15:18:54 <armax> kevinbenton: so run more
15:19:17 <kevinbenton> armax: that's what I was saying
15:19:24 <shz> the centralized dhcp service haa same problems
15:20:05 <armax> kevinbenton: adding more agents should address the scaling need
15:20:08 <armax> kevinbenton: no?
15:20:12 <armax> isn’t that what you’re saying?
15:20:18 <kevinbenton> Yes
15:20:34 <kevinbenton> Run it on every compute node and you won't have an issue
15:20:44 <amotoki> why can't we run multiple agents on compute node the current way?
15:20:47 <armax> kevinbenton: right, but you could do that already
15:20:51 <armax> no changes whatsoever
15:20:55 <amotoki> it's same as what kevin says
15:21:20 <armax> there’s nothing today in the neutron archicteture that prevents you from running a dhcp agent on every host of your cloud
15:21:25 <armax> and I know of customers who do
15:21:34 <amotoki> i know too.
15:21:47 <armax> so as far as I am concerned, if you do want to use a dhcp-based approach to distribute dhcp agents
15:21:56 <armax> you can do that already
15:21:57 <armax> now
15:22:09 <armax> that can bring the control plane issues that neiljerram mentioned
15:22:28 <dougwig> we're past the timebox on this one, fyi.
15:22:30 <armax> but I really don’t want to go down the path of optimizing a deployment architecture that’s atypical anyway
15:22:32 <kevinbenton> armax: right. I'm saying I don't think this is a high priority because we can schedule multiple per network and have agents on every node
15:22:36 <armax> dougwig: thanks dougwig
15:22:43 <armax> kevinbenton: indeed
15:22:57 <armax> kevinbenton: in other words we already have building blocks to address the concerns being reaised
15:23:04 <armax> kevinbenton: is there a fair statemnt?
15:23:30 <kevinbenton> armax: yes. Need a better justification for where current fails
15:23:49 <armax> kevinbenton: I’ll provide feedback on this one
15:24:03 <armax> bug 1508243
15:24:03 <openstack> bug 1508243 in neutron "Store Private Key Passphrase in Neutron-LBaaS for TLS Terminations" [Wishlist,Triaged] https://launchpad.net/bugs/1508243
15:24:07 <armax> we talked about this one
15:24:11 <armax> but said we’ll defer to the meetup
15:24:16 <armax> that’s happening for lbaas
15:24:23 <armax> dougwig: can you remind us of the dates?
15:24:29 <dougwig> jan 12th.
15:24:34 <armax> ok
15:24:40 <armax> we’ll keep it warm until them
15:24:41 <armax> then
15:24:50 <armax> bug 1508997
15:24:51 <openstack> bug 1508997 in neutron "Reusable firewall rules" [Wishlist,Invalid] https://launchpad.net/bugs/1508997
15:24:58 <armax> this is invalid
15:24:59 <armax> next
15:25:00 <armax> :)
15:25:16 <armax> bug 1516195
15:25:17 <openstack> bug 1516195 in neutron "Push all object information in AMQP notifications" [Wishlist,Triaged] https://launchpad.net/bugs/1516195
15:25:56 <armax> has anyone had a chance to review the spec proposal?
15:26:02 <kevinbenton> That sounds like a spec I wrote
15:26:08 <armax> yes
15:26:24 <dougwig> the initial description sounds counter to how you usually make an event stream scale.
15:26:29 <carl_baldwin> I gave it a once over.  Sounds like it is dependent on some versioning.
15:27:03 <armax> we need eyes on the spec
15:27:09 <armax> to make sure that kevinbenton is not rambling
15:27:17 <armax> but he may be onto something
15:27:31 <kevinbenton> dougwig: you make an event stream scale by not providing enough information to be useful? :)
15:27:31 <armax> the internal bus communitation is far from perfect
15:27:33 <dougwig> https://review.openstack.org/#/c/225995/
15:27:43 <armax> so I
15:27:48 <dougwig> kevinbenton: exactly, i'll take it to the spec. plus you get upgrade issues galore.
15:27:54 <armax> so I’d say, let’s read the spec, see how sounds it is
15:28:03 <armax> and then we make an executive decision
15:28:15 <kevinbenton> dougwig: upgrade is dealt with with objects
15:28:32 <armax> I think it’s premature to make a decision now
15:28:58 <kevinbenton> QoS already took this path, so we need to fix them either way
15:29:19 <dougwig> kevinbenton: i need to read your spec. i'm talking out of my ass right now.
15:29:53 <armax> kevinbenton: there’s enough flexibility for any feature to take its own path in having agent synchronize with the server
15:30:30 <dougwig> armax: you really want every agent making up its own rpc? that sounds like madness.
15:30:34 <armax> kevinbenton: as much as I love consistency, that doesn’t necessarily mean that we should go over and flip everything
15:30:42 <amotoki> we need to break down rpc call from server to agent. there are a lot of mess in rpc versioning in this direction.
15:30:51 <armax> dougwig: no, I am talking about the existing realitiy
15:31:03 <kevinbenton> armax: this isn't for consistency, it's because I think it's a better pattern
15:31:05 <amotoki> i think we need some preparetion before doing it. but i need to read the spec.
15:31:15 <armax> kevinbenton: and I don’t disagree
15:31:32 <armax> kevinbenton: all I am saying, let’s spend some time going over the details
15:31:45 <kevinbenton> But they have a race condition right now, which is what I was referring to when I said they needed to be fixed
15:31:49 <armax> kevinbenton: I see that we hardly had any meaningful discussion on this one
15:32:08 <armax> to make an informed decision
15:33:02 <dougwig> past the timebox.  punt and review spec?
15:33:09 * carl_baldwin will review spec
15:33:18 <armax> dougwig: let’s make sure we review the spec this week
15:33:36 <armax> dougwig: I am in favor of revisiting the communication pattern
15:33:36 <dougwig> armax: +1
15:34:08 <armax> but I don’t want to replace a set of problems with another
15:34:47 <armax> bug 1518087
15:34:47 <openstack> bug 1518087 in neutron "[RFE] security group event need be enforced by at least one mech driver" [Wishlist,Triaged] https://launchpad.net/bugs/1518087
15:35:19 <armax> so I have kept an eye on this one ever since it was submitted
15:35:44 <armax> and I am honestly not sold on the rationale
15:36:07 <armax> in the latest form of the RFE
15:36:39 <armax> the author is advocating for overhauling the MD mechanism to allow for enforcement of security groups
15:36:45 <armax> by at least one mech driver
15:37:56 <armax> my feedback was two-fold: a) today network creation is fully delagated to MD’s just as well and there’s no mechanism for enforcing the creation on at least by one driver, so this RFE should not be limited to SG only
15:38:22 <kevinbenton> So making port binding fail if nobody reported they applied security groups
15:38:29 <kevinbenton> armax: that's not the same though
15:38:34 <dougwig> are sg's an l2 or l3 construct? i guess i never really considered them as l2 related from a high-level.
15:38:42 <armax> b) actually, this sounds like overengineering, because any deployer who wants to use more than one mech-driver will have to know in advance if the two mech drivers are really compatible
15:39:04 <armax> by ranning some validation tests before going to prod
15:39:25 <amotoki> i think it is the role of MD which makes the lowest level binding.
15:39:26 <armax> dougwig: agreed, but ML2 is anything but
15:39:43 <kevinbenton> armax: Yeah, saying 'run tempest' seems legitimate
15:40:26 <armax> I am arguing whether careful planning would allow for this issue not to show up in prod
15:40:49 <armax> it sounds too little too late to detect this issue at run time
15:41:38 <dougwig> i think the point of the rfe is that there's too much magic that you have to *just know* before prod, and we should start enforcing some of it, like, SG's that actually work as advertised.
15:41:46 <dougwig> i may be reading between the lines too much.
15:41:53 <armax> dougwig: that
15:41:58 <kevinbenton> But that's what tempest will tell you
15:41:59 <armax> dougwig: that’s a fair point
15:42:32 <armax> dougwig: but what does enforcement tell you? That your MD’s of choice don’t work together well?
15:42:49 <armax> dougwig: you don’t go to prod willy nilly do you?
15:42:49 <armax> :)
15:43:06 <amotoki> it sounds a reasonable assumption that operators do some functional tests in advance :)
15:43:13 <dougwig> i certainly don't run tempest first, but then, i'm not an operator.  :)
15:43:29 <armax> dougwig: either tempest of your validation suite of choice
15:43:42 <dougwig> still, i can't think of any software package off the top of my head that gives the advice of, "stuff might work. run some test frameworks first to make sure."
15:43:48 <armax> dougwig: I’d argue that you go and make sure your expectations are met before handing over the environment to your user
15:43:49 <armax> s
15:44:04 <armax> dougwig: you just described openstack!
15:44:15 <kevinbenton> dougwig: you've never used linux device drivers have you :)
15:44:15 * armax teases
15:44:16 <dougwig> armax: i'm not debating that point; just the degree to which we expect our ops to basically be devs.
15:44:37 <dougwig> past double timebox on this one so far, btw.
15:44:54 <HenryG> can something be done in sanity_check.py?
15:45:37 <armax> ok, I’ll go over the spec one more time and perhaps dougwig can do the same
15:45:57 <kevinbenton> HenryG: the issue is that a combination of drivers could fail to do it
15:45:59 <armax> we can talk about this again next week, but I am provisionally not in favor of this one
15:46:17 <kevinbenton> Sriov won't have sg, but OVS will
15:46:29 <armax> bug #1521291
15:46:29 <openstack> bug 1521291 in neutron "[RFE] Transition neutron CLI from python-neutronclient to python-openstackclient" [Wishlist,Triaged] https://launchpad.net/bugs/1521291
15:46:30 <kevinbenton> So you can't know until after a port is bound
15:47:38 <dougwig> so, you're provisionally not in favor based on implementation flaws, or the use case being bad? because i think the rfe should focus on the latter, whereas we're all looking at this and groaning, "oh boy, that'd suck in ml2."
15:48:00 <dougwig> will take it to the spec.
15:48:30 <armax> dougwig: ack
15:48:39 <HenryG> I get the impression the osc folks have got quite far along with supporting neutron. amotoki, what do you think?
15:48:49 <armax> as for bug 1521291, I think we’re all universally in favor of some progress on this front
15:48:49 <openstack> bug 1521291 in neutron "[RFE] Transition neutron CLI from python-neutronclient to python-openstackclient" [Wishlist,Triaged] https://launchpad.net/bugs/1521291
15:49:12 <amotoki> i think we can move forward osc implementation
15:49:16 <armax> I checked with nova what the latest is on the novaclient integration
15:49:31 <amotoki> but it needs more time until it becomes mature.
15:49:48 <armax> we need to make sure we don’t overlap with their client, because it also allows for some networking related operations
15:49:50 <amotoki> I think there is no need to block the effort from our side.
15:49:56 <armax> amotoki: agreed
15:50:09 <armax> amotoki: one point I’d like to make though is: we need to set expectations
15:50:46 <amotoki> the first milestone is feature parity to the current neutronclient.
15:50:52 <armax> amotoki: because I think it’s not clear where the OSC starts and where it ends, and whether it’s meant to make the native client superseded
15:51:57 <amotoki> i understand your point.
15:52:01 <dougwig> amotoki: feature parity with or without extensions? is there a similar mechanism? is there a shim to use old extensions?
15:52:28 <amotoki> osc natively supports the extension mechanism thru entry_points.
15:52:41 <armax> amotoki: I would like to see some document, either a spec or a devref, probably a devref that explain what the future for the clients looks like
15:52:49 <amotoki> armax: totally agree.
15:53:07 <dougwig> +1
15:53:08 <amotoki> there are sevearl points to be clarified before moving it forward.
15:53:25 <armax> amotoki: and that should serve developers so that they redirected correctly for their client efforts
15:53:50 <amotoki> in neutron devref?
15:53:55 <armax> then we’d need to have user docs, but that’s for later when things have reached maturity
15:54:00 <armax> amotoki: best in the client devref
15:54:21 <amotoki> got it. sounds good.
15:54:23 <armax> amotoki: btw I don’t think that that has an entry point on docs.o.o
15:54:42 <dougwig> in that doc, i'd like to see, when do they expect 1.0, when will docs support it, what is the deprecation plan for the old neutronclient, in addition to the 'how'.
15:55:01 <armax> I’ll comment on the RFE, but I think we all agree some progress here is in order and if we have volunteers we should encourage to work on it
15:55:18 <amotoki> for client, documents on docs.o.o are for released version.
15:55:33 <armax> amotoki: I’ll have a look last time I checked I couldnt’ find it
15:55:50 <armax> amotoki: you happy to sponsor this initiative?
15:55:55 <amotoki> armax: sure
15:56:01 <armax> amotoki: good stuff
15:56:28 <amotoki> armax: you need to follow "Language Bindings and Python Clients" instead of "python developer documentation".
15:56:55 <armax> ok I’ll look it up
15:57:09 <armax> next we have 3 bugs that apparently have both tags RFE and RFE-APPROVED
15:57:17 <armax> dougwig I think is at fault for that :)
15:57:26 <armax> bug 1523219
15:57:26 <openstack> bug 1523219 in neutron "[RFE] Support X-Forwarded-For header in LBaaSv2" [Wishlist,Triaged] https://launchpad.net/bugs/1523219 - Assigned to Kobi Samoray (ksamoray)
15:57:31 <armax> bug 1523222
15:57:31 <openstack> bug 1523222 in neutron "LBaaSv2 TLS support is limited to offloading" [Wishlist,Triaged] https://launchpad.net/bugs/1523222 - Assigned to Kobi Samoray (ksamoray)
15:57:31 <armax> and
15:57:37 <armax> bug 1523231
15:57:37 <openstack> bug 1523231 in neutron "LBaaSv2 HTTP, HTTPS health monitor validates only return code" [Wishlist,Triaged] https://launchpad.net/bugs/1523231 - Assigned to Kobi Samoray (ksamoray)
15:58:09 <armax> if these are turned out these quickly they probably shouldn’t be RFE
15:58:13 <dougwig> i think they're all no brainers if they have a resource.  constrained, make sense, widely used in industry, don't bring up any general neutron issues.
15:58:28 <armax> these basically overtook a lot of bugs that have been in the pile for a while
15:58:30 <armax> and that’s not fair
15:59:04 <dougwig> hmm, i may have gorked the process, but i thought we could punt the drivers meeting for the obvious stuff? i was trying to save time.
15:59:12 <armax> so, they are minor enhancement, well scoped things that fix something that you think it’s broken
15:59:24 <armax> they are probably not RFE in the first place
15:59:56 <dougwig> wait, isn't that exactly what an rfe is?  not a bug, needs to be tracked?
15:59:56 <armax> we can discuss this offline
15:59:58 <armax> #endmeeting