22:00:06 <armax> #startmeeting neutron_drivers
22:00:07 <openstack> Meeting started Thu Apr 14 22:00:06 2016 UTC and is due to finish in 60 minutes.  The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:10 <amotoki_> hi
22:00:11 <openstack> The meeting name has been set to 'neutron_drivers'
22:00:18 <HenryG> o/
22:00:22 <salv-orl_> aloha
22:01:12 <njohnston> o/
22:01:18 <jschwarz> o/
22:01:22 <amuller> hiho
22:01:26 <nmagnezi> o/
22:01:34 <armax> amuller, dougw2 ping
22:01:45 <amuller> armax: pong
22:01:46 <dougw2> o/
22:01:58 <armax> before we dive in into the meat of the meeting
22:02:00 <armax> carl_baldwin: ping?
22:02:17 <carl_baldwin> armax: pong!
22:02:20 * carl_baldwin here
22:02:29 <armax> I would like to ask members of the team to go over https://review.openstack.org/#/c/286413/ one more time and seal its fate
22:02:30 <patchbot> armax: patch 286413 - neutron-specs - Provide a release postmortem
22:03:34 <carl_baldwin> aye aye
22:04:15 <ihrachys> armax: hasn't timestamp thing landed in M?
22:04:21 <ihrachys> it's incomplete as per the doc though
22:04:54 <armax> ihrachys: it should have, if it’s marked incomplete, it’s an oversight, that’s why I need people’s help to get it to closure
22:05:00 <armax> we’re well in Newton
22:05:12 <ihrachys> yeah, service plugin in stable/mitaka
22:06:01 <armax> ihrachys: you’re talking about line 278, correct?
22:06:16 <armax> ihrachys: this must be a brainfart of mine, as the whole thing is marked complete
22:06:37 <ihrachys> 287, 288 etc.
22:07:05 <armax> ihrachys: fixed
22:08:23 <armax> I would like to get this doc to be sealed, if the lack of +1/+2 is an indication that no-one cares about this, then I am gonna scrap the whole thing and move on
22:08:48 <armax> this is the n-th kind reminder
22:09:13 <amotoki_> re: L.296 of address scope,  the status is complete, but the docs status is incomplete.
22:09:39 <carl_baldwin> amotoki_: The reference below that shows the docs in review.
22:09:39 <armax> amotoki_: the patch might have not merged at the time I looked at this
22:09:55 <carl_baldwin> amotoki_: I'm working on some updates but have been swamped.
22:10:43 <armax> I assume a doc complete when there’s a substantial patch in for review
22:11:22 <armax> amotoki_: though as carl_baldwin pointed out, the patch is not quite there yet
22:11:46 <amotoki_> i found the docs review https://review.openstack.org/286294
22:12:19 <amotoki_> docs patch of address scope. thanks
22:12:27 <carl_baldwin> armax: I thought that the use_default_subnetpool extension was in here.  But, I'm not seeing it.
22:12:40 <armax> carl_baldwin: it might have not have been tracked as rfe
22:12:53 <armax> carl_baldwin: but simple bug fix
22:12:57 <carl_baldwin> armax: ok
22:13:09 <carl_baldwin> I'm okay with that.
22:13:21 <ihrachys> armax: side note while others read the doc thru: I should probably add that postmortem thing to my pre-release check list? and do you have the script somewhere to generate the stub?
22:13:33 <HenryG> How about we just +A the postmortem now and any remaining tweaks can be done as follow-ups?
22:14:01 <dougwig> NO, IT MUST BE PERFECT, AS ALL OF NEUTRON.
22:14:04 <armax> ihrachys: I thought I have commented on your checklist
22:14:16 <armax> ihrachys: and yes, let me polish the script up and I’ll commit it to the specs repo
22:14:48 <armax> dougw2, HenryG I am easy either so long we can have this published on specs.openstack.org
22:14:48 <HenryG> dougwig: HIT THE +A NOW!!!
22:14:57 <armax> right now it’s the time when people do check out the website
22:15:06 <ihrachys> armax: oh I realize I actually have it in there. just not the script.
22:15:25 <armax> the more time passes, the more residual the value of this doc becomes
22:15:38 <kevinbenton> dougwig: +A +A +A
22:16:20 <armax> ihrachys: yup, let me clean it up before pushing it
22:16:35 <carl_baldwin> HenryG: dougwig:  Do you need to be sent to the office?  All this yelling.
22:17:00 <dougwig> carl_baldwin: it's passion.
22:17:10 <armax> carl_baldwin: perhaps they hit caps-lock accidentally?
22:17:24 <ihrachys> http://i0.kym-cdn.com/entries/icons/original/000/019/304/old.jpg
22:17:50 <carl_baldwin> ihrachys: rofl
22:17:51 <dougwig> honestly, the content looks good enough to me to not wait.  i agree with HenryG
22:18:00 <armax> #action armax to kick out all members of the drivers team if the postmortem doesn’t merge by the end of the week
22:18:12 <armax> ok, let’s move on
22:18:13 <armax> :)
22:18:18 <ihrachys> pathetic. please press the button already.
22:18:26 <armax> and thanks for putting up with me
22:18:32 <amuller> armax: that's an empty threat as we can just approve it =p
22:18:46 <armax> amuller: so long as I get my way, I’m fine with that
22:19:05 <armax> jokes aside
22:19:08 <HenryG> Did you hear about the job opening for assistant to the one-armed typist? It's shift work.
22:19:33 <armax> let’s dive in the list of triaged bugs of the week
22:19:45 <armax> but before we do
22:19:57 <armax> I wonder if you guys want to have the meeting the next three weeks
22:20:05 <armax> the one prior, during and after the summit
22:20:22 <armax> that doesn’t mean we should not look at RFE and specs mind yo
22:20:22 <armax> u
22:21:01 <dougwig> prior and during should be canceled, IMO, unless we want to use the time to go over sessions.
22:21:08 <carl_baldwin> Well, not during.  We have sessions. I'm okay missing the one before as I'll be preparing last minute things and resting up.
22:21:16 <carl_baldwin> I'm not sure about the one after.
22:21:45 <armax> carl_baldwin: perhaps the one after is the only week where I can put my feet up
22:21:55 <amuller> I'm on PTO the week before, during doesn't seem realistic, I'm here the week after
22:22:08 <ihrachys> I am on PTO two weeks after the summit. but who cares.
22:22:15 <armax> or at least stop pretending to look like I am busy
22:22:49 <armax> boden: btw I swapped your session
22:23:02 <boden> armax: yea I saw that... thank you!
22:23:04 <armax> boden: you’d better show up and sit in the first row
22:23:16 <armax> boden: you’ve been warned :)
22:23:44 <boden> I'll sit front stage need be
22:23:50 <armax> ok, I’d say let’s cancel the next three meetings
22:24:13 <carl_baldwin> +1
22:24:16 <armax> as for the team meetings, it’s probably safe to keep the next one and skip the other two
22:24:54 <armax> ok, let’s use the remaining time to chew on the list
22:25:07 <armax> bug 1468366
22:25:08 <openstack> bug 1468366 in neutron "[RFE] (Operator-only) Logging API for security group rules" [Wishlist,Triaged] https://launchpad.net/bugs/1468366
22:25:11 <armax> this actually is not new
22:25:26 <armax> we blessed in the past but we struggled to get the spec in a good shape
22:25:37 <armax> and the effort died out
22:25:47 <armax> I know that some monasca folks showed some interest
22:26:20 <armax> if no-one is willing to help these guys put a solid proposal in place, this is most likely gonna start in newton too
22:26:41 <armax> if you have friends and families or general walks of life who are interested in this one
22:26:47 <armax> that’s the time to speak up
22:27:12 <carl_baldwin> (crickets)
22:27:32 <HenryG> (more crickets)
22:27:32 <dougwig> this spec looks useful, but also like a giant landmine.
22:27:55 <armax> I suppose we’ll keep it on the backburner
22:28:02 <kevinbenton> yeah, this is something i wouldn't mine seeing done, but I don't have the bandwidth to put any dev effort into it
22:28:10 <armax> I should probably add a link on the drivers page
22:28:16 <armax> called ‘RFE graveyard’
22:28:19 <amuller> And that is officially the first time I've ever seen Kevin say no
22:28:32 <amuller> This is truly a historical day
22:28:45 <salv-orl_> I don't think he said no
22:28:54 <dougwig> there's probably a russian mafia guy with a bat standing behind him.
22:28:59 <amuller> salv-orl_: Don't ruin this for me I'm in tears
22:28:59 <ihrachys> amuller: it's not about what he says, it's about what he ends up doin'
22:29:02 <armax> salv-orl_: if you have minions who what to help here
22:29:05 <boden> I'll help with it if you guys help get the troubleshooting spec through /wink
22:29:07 <armax> salv-orl_: that’s your chance
22:29:10 <salv-orl_> we just need to give him more bandwidth... kevinbenton: ever heard of LSD?
22:29:29 <kevinbenton> salv-orl_: i don't think that's the one that gives you bandwidth
22:29:31 <armax> boden: being part of the community is providing unconditional and uninterested love :)
22:29:39 * carl_baldwin thinks kevinbenton must be moonlighting somewhere else sucking his bandwidth away.
22:29:48 <boden> sounds like you just signed me up!
22:29:53 <kevinbenton> cloudstack is making a comeback!
22:30:05 <salv-orl_> kevinbenton: I see you are already an expert. I have nothing to add then
22:30:14 * dougwig whispers, "blink three times if you need rescuing"
22:30:15 <kevinbenton> salv-orl_: you trapped me! :)
22:30:30 <armax> ok, let’s see if we can resurrect this one, if not, tough love
22:30:41 <armax> on the triaged bug list
22:30:46 <armax> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe
22:30:55 <armax> there’s a string of BGP related RFE
22:30:58 <armax> bugs
22:30:59 <armax> now
22:31:08 <dougwig> holy bgp.
22:31:10 <armax> as I expressed on the bug reports
22:31:33 <armax> I defer to tidwellr, carl_baldwin and whoever else is the L3 dude in charge
22:32:00 <armax> so I leave the vetting to them during the L3 meeting or whathaveyou
22:32:01 <carl_baldwin> I'll go through these with Ryan.
22:32:25 <armax> carl_baldwin: if you make the transition, please remember to record blueprints etc, if you need help reach out to me
22:32:31 <kevinbenton> i fear with this BGP stuff that we are going to end up with an incoherrent set of things built on top of BGP that are incompatible if we don't have some kind of standard layer they all talk to
22:32:41 <armax> bear in mind that the team should be busy to stand up the bgp repo first
22:32:51 <kevinbenton> will they all build on top of the BGP stuff that merged at least?
22:33:04 <carl_baldwin> kevinbenton: I think that is the idea.
22:33:07 <carl_baldwin> armax: ack
22:33:08 <armax> and taht reminds me that I have to look at https://review.openstack.org/#/c/268726/
22:33:09 <patchbot> armax: patch 268726 - openstack-infra/project-config - Adding neutron-dynamic-routing as neutron's stadiu...
22:33:21 <dougwig> do we have a bgp czar to keep things on a uniform footing?
22:33:40 <dougwig> nvm, i read slowly.
22:34:55 <armax> once we take BGP-related RFE's
22:35:01 <armax> the list shrinks dramatically
22:35:10 <armax> and we hve the following:
22:35:14 <armax> bug 1552680
22:35:15 <openstack> bug 1552680 in neutron "[RFE] Add support for DLM" [Wishlist,Triaged] https://launchpad.net/bugs/1552680 - Assigned to John Schwarz (jschwarz)
22:35:25 <armax> no-one had any spare cycles to come back to the report
22:35:39 <armax> we need to figure out a way forward for this one
22:35:56 <jschwarz> I just posted on that RFE - I think the idea dougwig? had of using DLMs mainly on new features as a starting point is a good idea
22:35:59 <armax> amuller, kevinbenton can you please work together?
22:36:08 <armax> with jschwarz to figure a path forward?
22:36:11 <jschwarz> this will allow us to ease into DLMs and make sure this is a good idea
22:36:27 <armax> jschwarz: that was MY idea!
22:36:36 <armax> or dougwig stole it from me
22:36:36 <amuller> kevinbenton: jschwarz: I think the intent is for John to organize a Friday session about this
22:36:38 <jschwarz> armax, apologies, dear master!
22:36:49 <amuller> As long as we get the participants that are invested in this I'm sure we can reach a concensus
22:36:56 <amuller> kevinbenton: How does that sound?
22:36:56 <armax> jschwarz: that’s fine, it’s possible I am mistaken!
22:37:07 <dougwig> apparently i can steal things i don't even remember.  sweet.  :)
22:37:16 <armax> dougwig: love you man, don’t worry
22:37:28 <kevinbenton> it sounds scary to me
22:37:35 <dougwig> i think my suggestion was to make it optional, which I just commented on the RFE.
22:37:36 <armax> kevinbenton: what does?
22:37:39 <kevinbenton> DLM
22:37:45 <kevinbenton> we should chat about it at the summit
22:37:46 <dougwig> armax: tough love?  like, stick with nails in it?
22:37:59 <kevinbenton> come up with a nice use case of something that it drastically simplifies
22:38:01 <armax> dougwig: I leave the interpretation open
22:38:03 * salv-orl_ kevinbenton is from the lock free school
22:38:18 <dougwig> kevinbenton: shall we talk about using DLM via a docker container to allocate and wire ports for nova?
22:38:24 <dougwig> with flavors and chaining?
22:38:24 <armax> ok, now that I mastered the art of delegation, let’s move on
22:38:27 <armax> bug 1554869
22:38:28 <openstack> bug 1554869 in neutron "[RFE] Make API errors conform to API working group schema" [Wishlist,Triaged] https://launchpad.net/bugs/1554869
22:38:33 <amuller> salv-orl_: Will you be at the summit on Friday?
22:38:38 <armax> this one is sensible
22:38:54 <salv-orl_> amuller: yes because all the friday flights were full when I booked
22:38:55 <armax> though I am not sure it’s considered one of the worst pain points of our API
22:38:59 <kevinbenton> except we have no way to do it without microversioning, right?
22:39:04 <amuller> salv-orl_: Good! :)
22:39:10 <amuller> salv-orl_: I'm counting on you for the DLM discussion
22:39:24 <armax> kevinbenton: there’s a way
22:39:27 <carl_baldwin> armax: The ML discussion kind of blew this up to a big task.
22:39:39 <armax> carl_baldwin: care to provide a link?
22:39:44 <armax> carl_baldwin: I might have missed that one
22:40:04 <armax> carl_baldwin: but yeah, this is no small feat of engineering, despite how simple the objective is
22:40:07 <kevinbenton> armax: how do we remove our current errors without a backward incompatible change?
22:40:09 <dougwig> well, the ML went full-dogmatic. though i still don't like this one except for new apis.
22:40:37 <armax> kevinbenton: the client opts in to get new errors by specifying a HEADER
22:40:40 <amotoki_> the link is http://lists.openstack.org/pipermail/openstack-dev/2016-April/091949.html and related stuffs
22:40:53 <armax> kevinbenton: which is effectively what a micro-versioned api
22:41:02 <armax> kevinbenton: where the version is passed as a header
22:41:11 <kevinbenton> armax: i thought that was deemed entirely evil by the API people?
22:41:19 <carl_baldwin> amotoki_: thanks.
22:41:32 <salv-orl_> kevinbenton: proliferation of headers is abhorred
22:41:42 <armax> kevinbenton: I hear you
22:41:42 <salv-orl_> but maybe you can be forgiven for a single header
22:41:51 <ihrachys> I think it's not a critical thing to rush, and we should instead suggest people to act on microversioning. I also believe it's actually against some API-WG guidelines. so it's trading one thing for another. that said, when we suggest people to act, we need someone to own it from the core team, otherwise it does not happen. :-|
22:42:07 <armax> ihrachys: yes, that’s what I am trying to get at
22:42:24 <armax> I think we as a team should figure out once and for all what we want to do with the api we got
22:42:36 <armax> we have deferred way to many things up until now
22:42:51 <armax> filtering, sorting, pagination, now better error handling
22:43:17 <salv-orl_> ihrachys: I'd love to hear what the community think now of microversioning, in particular when it comes to extensions. But this discussion can happen on the mailing list.
22:43:27 <armax> if we decide to stick with this api for ever, then this bug bug makes sense, if we do want to switch
22:43:43 <dougwig> armax: sounds like you're lobbying for api v3, when we could break all the things and not screw people over.
22:43:47 <amuller> salv-orl_: I agree. Nova had it in for a couple of cycles now (?), I'd like to see how operators like it
22:43:52 <kevinbenton> we can have our traditional microversioning discussion at the summit in which we conclude that vendors like extensions and that's not really compatible with microversioning
22:44:21 <salv-orl_> well then start fresh with a v3 - and define a strategy to get off v2 eventually
22:44:33 <kevinbenton> i think that's best at this point
22:44:48 <kevinbenton> also lets us address lots of warts that we couldn't do anything about because of backward compat
22:44:57 <salv-orl_> but if the strategy is to keep evolving v2 until you see v3 fit, then just don't bother doing v3
22:45:27 <armax> either way we look at it, this bug is predicated on the fact that the v2 is not going away as it is
22:45:30 <salv-orl_> because you will focus 90% of your energy onto evolving v2 and v3 would be a thing that is forever under development
22:45:41 <kevinbenton> meh, we should discuss more at the summit
22:45:49 <dougwig> everyone likes extensions, and they really aren't.  we have never cracked that nut, nor will we while we refuse to let any meta-data go from top to bottom in the name of "interchangeable apis" (that aren't), or we bring our fist down.
22:46:15 <amotoki_> we might be able to do API microversioning in API side, but we need to define plugin API for passing what APi version is called...
22:46:17 <dougwig> they really aren't compatible with microversioning, i mean.  typing too slow.
22:46:21 <armax> dougwig: perhaps there’s a middle ground
22:46:29 <armax> where we can have microversioned extensions? :)
22:46:39 <kevinbenton> or microextended versions
22:46:50 <salv-orl_> in a container
22:46:59 <dougwig> that'd work, if folks could live with it.  if we could even decide that we wanted extensions, which always raises a big fuss.
22:47:02 <salv-orl_> with uri chaining and microservices
22:47:11 <kevinbenton> which runs a unikernel
22:47:23 <kevinbenton> So has Nova completely abandoned extensions now?
22:47:30 <armax> kevinbenton: yes
22:47:41 <dougwig> kevinbenton: yes.
22:47:44 <dougwig> violently opposed.
22:47:56 <armax> so if I were to sum this discussion, it’s fair to say that we wouldn’t want to solve this bug on top of the existing bug framework
22:47:59 <armax> am I right?
22:48:08 <armax> dougwig: hang on
22:48:12 <kevinbenton> well it depends on what our timeline is for microversioning
22:48:24 <armax> dougwig: what they are saying is that any new behavior must be added in tree in nova and by means of microversions
22:48:39 <kevinbenton> i think we should discuss it in teh API session before deciding
22:48:54 <dougwig> that's the same as saying extensions are the devil, but breaking backwards compat is just slightly more so.
22:49:10 <armax> dougwig: have a read through this one https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/comment-page-1/#comment-64463
22:49:44 <armax> #link v
22:49:46 <armax> #undo
22:49:48 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0x89b28d0>
22:49:48 <armax> #link https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/
22:50:02 <armax> so before we go to the next one
22:50:27 <armax> is it fair to say that we wouldn’t want to solve this bug on top of the existing bug framework?
22:50:29 <dougwig> reading.  i often wonder if the goal of "interoperable" clouds is worth the hand tying we do to ourselves and operators.
22:50:54 * armax hangs by a thread
22:51:02 <dougwig> armax: i'd be fine enforcing it on new apis, but in general, i concur.
22:51:18 <armax> dougwig: ok, anyone else?
22:51:20 <armax> amotoki_: ?
22:51:22 <amotoki_> armax: fair enough
22:51:29 <armax> ok
22:51:39 <kevinbenton> dougwig: yes, i think so. a big mess of incompatible openstack clouds really devalues openstack from a user's perspective
22:51:48 <kevinbenton> dougwig: it's just vendor lockin to another provider
22:52:02 <armax> bug  1565801
22:52:04 <openstack> bug 1565801 in neutron "[RFE] Add process monitor for haproxy" [Wishlist,Triaged] https://launchpad.net/bugs/1565801 - Assigned to Nir Magnezi (nmagnezi)
22:52:07 <armax> I see that dougwig replied
22:52:36 <dougwig> kevinbenton: i'm already dealing with AWS vs DO vs OS, as a user.  and as an operator, i want my product to be what i want it to be, dangit.  if i choose interoperability as a selling point, fine.  if not, get off my lawn.
22:52:37 <nmagnezi> armax, dougwig, a question if I may
22:52:49 <armax> are you saying that you’re provisionally saying no, unless the code looks nice and clean and merging is a breeze?
22:52:53 <dougwig> armax: yes, i commented during BGP-alooza.
22:52:57 <ihrachys> dougwig: how is it a new feature though?
22:53:03 <armax> nmagnezi seems to be lurking in this room
22:53:08 <nmagnezi> so just to confirm (since it's the first drivers meeting for me), If I submit a patch for it one, will it get a chance to get a review depending on the size of that change?
22:53:10 <kevinbenton> sounds like a bug fix
22:53:15 <nmagnezi> armax, indeed :)
22:53:23 <armax> dougwig: if he hasn’t started coding already what would your suggestion be?
22:53:30 <armax> kevinbenton: agreed
22:53:53 <dougwig> if nmagnezi is willing to support haproxy namespace driver bugfixes (all of them), then i welcome his reviews and *cough* bugfixes.
22:53:55 <dougwig> :)
22:54:10 * amuller wonders if nmagnezi gets brownie points for it being 2AM on a weekend
22:54:14 <kevinbenton> dougwig: if you want to write a proprietary cloud, fine. but it's just not that interesting to me (and i suspect some other users)
22:54:18 <armax> nmagnezi: your order has suddenly began a tall one
22:54:47 <ihrachys> there are lots of deficiencies in the reference backend (octavia), I don't see how we can meaningfully stop haproxy maintenance
22:54:51 <nmagnezi> dougwig didn't you tell me you guys keep haproxy around anyways? :)
22:55:27 <amuller> dougwig: I don't know if signing up nmagnezi to fix *all* haproxy impl. bugs is reasonable? I think he'd be happy to fix bugs in new functionality he adds
22:55:31 <dougwig> to be fair, there are absurd deficiencies in both. that is not an argument to continue maintaining both.
22:55:44 <dougwig> but this does seem small enough to be worth putting in.
22:55:49 <nmagnezi> amuller, indeed.
22:56:16 <ihrachys> indeed, it doesn't even seem like a feature to me. just common sense fix to make the service recover as most other services do.
22:56:17 <armax> ok, because the scope of this is small, let’s treat this a best effort bug fix
22:56:22 <dougwig> that'd be fine.  at some point haproxy is gonna rot, and without a champion, get the boot.  anyone with a dog in that race is encouraged to keep that from happening, i'd think.
22:56:43 <amuller> dougwig: Looking at the latest user surveys, most folks are still on I/J/K/L where Octavia is not even a possibility, so fixing some stuff and backporting it seems reasonable to me
22:56:51 <armax> we’re not past the point where we stopped caring on one solution over another
22:57:05 <dougwig> ihrachys: that bugfix road is long.  how about when you overload that agent?  it doesn't track that.  how about when you need to move agents?  nope.  the list of brokenness there is LONG.
22:57:06 <nmagnezi> the main reason i submitted this it is because it is complementary to bug 1565511
22:57:08 <openstack> bug 1565511 in neutron "Loadbalancers should be rescheduled when a LBaaS agent goes offline" [Wishlist,In progress] https://launchpad.net/bugs/1565511 - Assigned to Nir Magnezi (nmagnezi)
22:57:20 <armax> and the incremental change has enough value to be considered useful
22:57:27 <armax> that one I demoted to regular bug fix
22:58:10 <armax> I think the wider question to be asked is: how much review bandwidth there is for this driver?
22:58:14 <kevinbenton> which is actually a promotion from a process perspective :)
22:58:18 <armax> if there is, then any contribution should be welcome
22:58:23 <dougwig> this class of broken is part of why we wanted to abandon it.  but if it has someone interested and working on it, so be it.  it may well end up in a separate repo if its a different set of people.
22:58:25 <armax> if there isn’t, then there’s no point
22:59:00 <dougwig> armax: it'll get bandwidth on smaller patches.  a large patch would whither, i expect.
22:59:33 <armax> dougwig: ok, it sounds fair to me
22:59:48 <kevinbenton> MEETING TIME IS OUT!
22:59:49 <amotoki_> dougwig: do we accept lbaas-agent related patch which requires API changes?
22:59:50 <armax> dougwig: there’s no plan to deprecate this driver in the short term
22:59:56 <carl_baldwin> dougwig: true for practically any patch
23:00:16 <nmagnezi> i don't expect this to be a huge patch since i presume some decant amount of code might be reused from the neutron codebase (process monitor exists for things like keepalived dnsmasq etc)
23:00:17 <armax> #endmeeting