20:00:36 <johnsom> #startmeeting Octavia
20:00:37 <openstack> Meeting started Wed Mar 23 20:00:36 2016 UTC and is due to finish in 60 minutes.  The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:40 <openstack> The meeting name has been set to 'octavia'
20:00:42 <sbalukoff> Howdy folks!
20:00:43 <johnsom> Hi folks
20:00:44 <xgerman> p/
20:00:45 <ajmiller_> o/
20:00:52 <bana_k> hi
20:01:11 <eranra_> hello
20:01:15 <dougwig> o/
20:01:16 <johnsom> #topic Announcements
20:01:29 <johnsom> #link http://lists.openstack.org/pipermail/openstack-announce/2016-March/001018.html
20:01:44 <johnsom> In case you missed it, the LBaaS v2 horizon panels did a release
20:02:01 <sbalukoff> Nice!
20:02:08 <johnsom> So good stuff there
20:02:10 <TrevorV> o/
20:02:12 <minwang2> o/
20:02:33 <rm_work> o/
20:03:00 <johnsom> Another announcement is dougwig was kind enough to hook us up with a vt-x host for a third party gate.
20:03:05 <johnsom> Thanks dougwig
20:03:23 <xgerman> also amax stays PTL
20:03:26 <Aish> o/
20:03:28 <johnsom> Any other announcements?
20:03:30 <xgerman> all bow to the new/old leader
20:03:33 <kong> hi
20:03:34 <sbalukoff> Haha
20:03:43 <mhayden> o/
20:03:46 <xgerman> he ran un-opposed so remains king
20:03:48 <Apsu> o/
20:03:52 <dougwig> newton is open, so expect a respin of the "kill v1" patch.
20:03:59 <Apsu> Meet the new boss, same as the old boss
20:04:03 <sbalukoff> dougwig: Yay!
20:04:13 <xgerman> dougwig: aweosme
20:04:26 <johnsom> Ah yes, newton is open, so stuff that didn't make mitaka should be checked
20:04:48 <minwang2> nice
20:04:49 <sbalukoff> What are the RC deadlines for the rest of Mitaka?
20:05:09 <ptoohill> o/
20:05:24 <kong> sbalukoff: this week will be rc-2, i guess
20:05:33 <sbalukoff> Ok.
20:05:53 <johnsom> #topic Docu-geddon
20:06:04 <sbalukoff> Haha
20:06:06 <xgerman> sbalukoff #link http://releases.openstack.org/mitaka/schedule.html
20:06:09 <sbalukoff> Lots to do here.
20:06:21 <dougwig> one more announcement, if you fix any mitaka bugs on master, please remember to backport them to stable.
20:06:25 <johnsom> So as you may know, docs team nuked a bunch of Octavia docs from the Mitaka release.
20:06:25 <blogan> ./
20:06:39 <blogan> i mean o/
20:06:52 <TrevorV> johnsom "nuked"?
20:06:58 <TrevorV> Like, made them disappeared?
20:06:58 <johnsom> nuked == deleted
20:07:17 <TrevorV> Is that because they were improperly formatted...?  Was it an accident?
20:07:23 <johnsom> So, sbalukoff and I have been trying to figure out how to get them back, add new, etc.
20:07:37 <TrevorV> Sorry, we can side-line, I'll catch up later
20:07:38 <rm_work> we got caught in a spring cleaning that should maybe have not caught us, but it did :/
20:08:09 <ptoohill> they didnt like the name amphora
20:08:10 <johnsom> TrevorV The statement I got was "We don't want to migrate format (docbook->rst) for all of this stuff, so we are removing "third party drivers" from the docs"
20:08:23 <rm_work> so, I was ok with your patch to move them into our repo, i just hadn't had time to actually verify they are CORRECT yet :P
20:08:25 <sbalukoff> And nobody heard about the spring cleaning for several months because when the talked about us on the mailing list, they used a regular expression to mention our project. And by the time we noticed, it was too late to do a roll-back.
20:08:33 <rm_work> since we should probably correct them while we're adding them back
20:09:16 <johnsom> Yeah, so, we would like to take a different approach and move our docs into the repos so that we can not only keep an eye on them, but make sure folks update them.
20:09:30 <sbalukoff> Yep!
20:09:33 <johnsom> #link https://bugs.launchpad.net/octavia/+bugs?field.tag=docs
20:09:49 <sbalukoff> To this end, I created a bunch of docs tickets last week, and johnsom prioritized them today.
20:09:50 <TrevorV> So in that note, we ARE sticking to rst format right?
20:10:00 <johnsom> sbalukoff was kind enough to setup a etherpad to collect thoughts on what we need and then he moved them over to bugs.
20:10:02 <sbalukoff> TrevorV: Yes.
20:10:15 <sbalukoff> Also--
20:10:27 <TrevorV> Alright, cuz that statement johnsom got could also be construed as "make this docbook" but that's good news
20:10:55 <sbalukoff> If you do diagrams, word from the docs team is that binary formats (ie. png) are OK, so long as you include the source file for generating that (eg. if you did it in omnigraffle... include the omnigraffle file as well).
20:11:12 <sbalukoff> At least, that's the convention.
20:11:17 <sbalukoff> We don't necessarily have to follow it.
20:11:30 <TrevorV> Awe!  I just realized, that means my super sick diagrams disappeared, huh!
20:11:35 <TrevorV> Cmon man, I liked those...
20:11:38 <johnsom> Personally, I was put off by the "delete instead of fix", lack of support in us trying to get them back/fix, and the fact that we put effort into those docs.
20:11:39 <sbalukoff> But given the other choices for diagrams (ie. blockdiagram, graphviz, etc.) it's not a bad convention. :P
20:12:10 <blogan> neutron-lbaas is broke, delete it
20:12:15 <blogan> i like that method
20:12:30 <sbalukoff> TrevorV: if you still have those diagrams around, please add them back in!
20:12:37 <sbalukoff> Only in our own repos now.
20:12:52 <sbalukoff> By "our own" I mean neutron-lbaas and octavia, in the docs/sources subdir.
20:13:06 <johnsom> Yeah, so I have started by putting the octavia config options into our repo.
20:13:29 <sbalukoff> I am resurrecting that old operators installation guide I started last fall.
20:13:32 <johnsom> I am also working on diagramming the flows. (automated if I'm lucky)
20:13:37 <sbalukoff> Hoping to actually complete it this time.
20:13:50 <sbalukoff> johnsom: Ooh! Please let us know if you figure out how to automate that.
20:14:02 <TrevorV> sbalukoff I don't think I have them anymore, since I remember having them in tree already, but I guess that changed?
20:14:03 <johnsom> I have a semi-working script
20:14:40 <sbalukoff> Just to emphasize: Getting these docs done is kind of a big deal...
20:14:47 <johnsom> Please take a look at the bugs, grab one, and help us build up some useful docs!
20:14:50 <johnsom> #link https://bugs.launchpad.net/octavia/+bugs?field.tag=docs
20:15:08 <sbalukoff> Because without them, we're beholden to neutron leadership as to what to do with neutron-lbaas if there aren't docs enough for people to figure out how to use this stuff.
20:15:24 <mhayden> the lbaasv2 docs in the networking guide merged into mitaka/liberty, fwiw
20:16:25 <kong> yeah, http://docs.openstack.org/liberty/networking-guide/adv-config-lbaas.html
20:16:49 <xgerman> wow, faas has better docs then us :-(
20:16:52 <xgerman> fwaas
20:16:57 <blogan> :(
20:17:12 <johnsom> Along these lines, does anyone know if there is a way to get www.octavia.io to render a proposed patch?
20:17:13 <kong> lol
20:17:23 <blogan> johnsom: should just put the reivew # in
20:17:26 <blogan> the url
20:17:32 <sbalukoff> blogan: example?
20:17:40 * blogan verifies first
20:17:44 <mhayden> xgerman: looks like the red hat docs folks worked on the fwaas docs :)
20:17:53 <ptoohill> octavia.io/278830
20:18:10 <xgerman> mhayden maybe they can do the same for LBaaS?
20:18:19 * mhayden sniffles
20:18:21 <blogan> ptoohill: got it
20:18:31 <blogan> so for johnsom's review
20:18:33 <blogan> http://octavia.io/294338
20:18:37 <mhayden> xgerman: let me know what's missing on the lbaas docs there and i can try to add a bit more
20:18:38 <johnsom> Review ID not found for Octavia in Gerrit.
20:18:40 <sbalukoff> Sweet!
20:18:52 <sbalukoff> D'oh!
20:18:57 <blogan> ideally though, octavia should hve a docs job and we can just click on that link
20:19:01 <johnsom> That would be super awesome for reviews
20:19:07 <johnsom> Ok, second time it worked!
20:19:09 <ptoohill> keep in mind, this tool was never worked on after the initial 'we got it doing stuff' so there may be some bugs :)
20:34:50 <TrevorV> Yeah, so I guess the reason I'm bringing this up again is it seems as though that list has been relatively ignored (but I could be missing progress on some of those points)
20:34:51 <johnsom> My key things in newton: Docs, scenario test coverage
20:34:52 <blogan> a good first step would be to have a spec that lists all the things needed to achieve parity with neutron-lbaas, then after that we can break each one of those up into its own task and get each one done
20:34:57 <xgerman> I think it warrants some summit discussion
20:35:00 <blogan> while also maintaining neutron-lbaas
20:35:10 <TrevorV> I want a solid answer on when someone/anyone/we should start prioritizing that list and make a real effort towards
20:35:11 <TrevorV> it
20:35:21 <sbalukoff> If we want, I can go through my camera to find the picture I took and open bugs for each of the things Octavia lacks in order to become sand-alone. Then we can prioritize them as we see fit. But at least they'll be on the radar.
20:35:31 <blogan> TrevorV: make a spec and enumerate the items needed to get parity with neutron-lbaas
20:35:34 <blogan> tahts a godo first step
20:35:46 <johnsom> sbalukoff That would be great.  I think you had an etherpad too.
20:35:49 <xgerman> I am with blogan - let’s make a spec and get some input from the community
20:35:51 <blogan> sbalukoff: i think a spec would be better so we can all comment on it
20:36:01 <xgerman> blogan +1
20:36:04 <sbalukoff> Ok.
20:36:06 <dougwig> since octavia as its own endpoint is effectively a new major api version, should we consider dropping the single object calls at the same time?
20:36:07 <TrevorV> sbalukoff I can take that on if you can send me that image as well, but if you want to jump on that we can prioritize accordingly as well.
20:36:08 <sbalukoff> I'll create a spec then.
20:36:09 <blogan> sbalukoff: image would still be useful though
20:36:21 <blogan> dougwig: dropping? removing them you mean?
20:36:27 <dougwig> yep.
20:36:34 <blogan> dougwig: why?
20:36:37 <sbalukoff> dougwig: I think we need single-object calls if we're going to do updates.
20:36:44 <xgerman> dogging loves SOAP
20:36:56 <blogan> dougwig = dogging
20:37:09 <dougwig> xgerman: those are fighting words.
20:37:20 <TrevorV> That's great, I'm really in favor of prioritizing those things above all else so we can start maintaining one code base instead of two.
20:37:24 <blogan> i've smelled dougwig, he doesn't like SOAP
20:37:33 <johnsom> I thought it was corba
20:37:41 <xgerman> he seems to be in favor of PATCH for updates
20:37:42 <sbalukoff> #action sbalukoff to create spec for adding functionality to Octavia so that it can be stand-alone if people want to use it that way.
20:37:57 <sbalukoff> blogan: Haha!
20:38:02 <dougwig> so, neutron-lbaas becomes a direct pass-through as-is to octavia, in the brave new world?  all drivers or vm drivers live in octavia?
20:38:19 <dougwig> because i don't want to maintain both long-term.
20:38:21 <xgerman> that’s what the spec is for to discuss
20:38:25 <dougwig> and we have a user base.
20:38:30 <blogan> dougwig: yes, until one day neutron-lbaas just goes away, but in a graceful non-gtfo way
20:38:31 <johnsom> dougwig +1
20:38:51 <sbalukoff> dougwig: Possibly? It will probably be a few cycles at least before that happens, though.
20:39:21 <sbalukoff> That's the problem with things that are stable in production: People don't want to move.
20:39:35 <sbalukoff> And I can't really blame them.
20:39:36 <blogan> we could still have octavia's api be a part of neutron's, just do an L7 rule to point neutron/v2.0/lbaas to octavia's endpoint
20:39:40 <sbalukoff> Though I will definitely try. ;)
20:39:46 <blogan> but that'd be a deployer thing more
20:39:58 <xgerman> well, it would need to be 1:1 for it to work
20:40:00 <dougwig> i'd like to stop loading ourselves into the guts of neutron-server
20:40:05 <xgerman> which it currently is not
20:40:13 <sbalukoff> dougwig: +1
20:40:26 <xgerman> dougwig wasn’t neutron lib supposed to fix that?
20:40:46 <dougwig> xgerman: that stabilizes the entrail entry, but it's still an in-process extension.
20:40:46 <sbalukoff> blogan: A translation layer would be necessary in any case. It's possible that neutron-lbaas API just becomes an... API driver for Octavia, though. XD
20:40:53 <sbalukoff> Man, I felt dirty saying that.
20:41:10 <blogan> yes
20:41:10 <dougwig> sbalukoff: entrails are dirty.
20:41:12 <blogan> yes you should
20:41:26 <xgerman> well, once we remove the namespace driver how much is left to support?
20:41:52 <johnsom> We really need to get rid of the dual database situation
20:41:56 <blogan> anyway all of this can be discussed int he spec, if the spec outlines what needs to be done to get parity with neutron-lbaas and also a rough roadmap of the future of both, that'd be great
20:42:09 <blogan> johnsom: yes we do
20:42:09 <xgerman> yep
20:42:10 <johnsom> blogan +1
20:42:12 <dougwig> are the API's 1:1?  will we forever supports backwards compat?  which db is the source of truth?  where do the hw drivers live?
20:42:13 <sbalukoff> xgerman: We can get rid of 80% of it right away. As is usual with these sorts of things, I would be surprised if the last 20% doesn't hang around for a long while.
20:42:19 <dougwig> xgerman: ^^ those are a few of the questions.
20:42:55 <blogan> spec should have those qeustions and/or answers
20:43:00 <xgerman> +1
20:43:18 <sbalukoff> Right.
20:43:27 <sbalukoff> I'm not volunteering to write that one, eh. ;)
20:43:37 <xgerman> I just saw you put an action in
20:43:38 <dougwig> that's fine, i'm happy to discuss there. i, personally, feel pretty strongly that we should achieve these goals in a way that isn't painful for our users.
20:43:52 <blogan> dougwig: agree on that
20:43:52 <xgerman> dougwig +1 and also vendors
20:44:02 <johnsom> dougwig +1
20:44:08 <dougwig> vendors feeling pain is mangeable; that's a known quantity.
20:44:09 <sbalukoff> Well...  at painless as we can make it for vendors.
20:44:15 <sbalukoff> Some of those drivers, though....
20:44:24 <xgerman> dougwig the pain comes back to me… so
20:44:25 <TrevorV> dougwig is "EOL"-ing something painful for users if we provide a migration mechanism?
20:44:27 <blogan> i think we can make the vendor pain pretty painless, maybe a little pin prick
20:44:41 <dougwig> TrevorV: even EOL'ing v1 has been painful.
20:44:45 <sbalukoff> TrevorV: Yep.
20:44:50 <blogan> v1 is still around
20:44:58 <blogan> my goal is to have a v1, v2, and v3 active all at the same time
20:44:59 <sbalukoff> Sadly.
20:45:03 <xgerman> well, if we make octavia v2 compatible we don’t need to EOL
20:45:04 <blogan> i guess that'd be microversioning
20:45:05 <johnsom> Yes, I can think of a vendor that still only has v1 dirvers
20:45:56 <johnsom> Well, v1 is done, so game over on that one.  Do we need v3?  Not sure
20:45:59 <dougwig> this might be a good time to get vendor drivers as shim only, too.  i'm a vendor, and i don't like spending time maintaining silly things like py3 in other vendor code.
20:46:06 <sbalukoff> dougwig: +1000
20:46:26 <xgerman> so we move them out of tree like the rest of neutron
20:47:01 <sbalukoff> Yep. But in a more friendly way than, say the neutron-lbaas docs were moved out of the openstack manual. XD
20:47:14 <blogan> moved out to the trash
20:47:29 <dougwig> i'd be in favor of shims, just not full code.  there's an element of discoverability from the shims that i like.
20:47:31 <sbalukoff> Circular filed.
20:47:41 <johnsom> On the corner with a sign, "free to good home"
20:47:43 <blogan> anyway, the spec is probably something i can start on after April 1
20:47:49 <blogan> if yall dont mind waiting until then
20:47:59 <sbalukoff> dougwig: Cool. I have no idea how that works, so I'm hoping you can show us. :)
20:48:00 <blogan> sbalukoff if you could dig up that whiteboard picture
20:48:12 <sbalukoff> blogan: That's my plan, eh!
20:48:31 <sbalukoff> blogan: I was going to base the spec on that. But if you'd rather fill out the spec, that's fine.
20:48:31 <blogan> am i able to #action myself? or does it have to be the chair?
20:48:46 <sbalukoff> blogan: Oh sweet, are you volunteering to write the spec?
20:48:47 <xgerman> you can do that yourself
20:48:53 <dougwig> chair
20:48:53 <xgerman> yep, he did
20:48:53 <blogan> sbalukoff: yeah give it to me, this has been my goal all along anyway, i should birth the thing
20:48:54 <sbalukoff> I think you can action yourself.
20:49:04 <sbalukoff> blogan: Ok, will do!
20:49:18 <dougwig> #action go back to remedial chair school
20:49:18 <johnsom> #link https://etherpad.openstack.org/p/lbaas-mitaka-midcycle
20:49:31 <johnsom> this also has a list we came up with at the mid-cycle
20:49:45 <blogan> #action blogan create spec mapping out octavia and neutron-lbaas tasks to achieve parity and roadmap for the future
20:50:03 <johnsom> #action blogan Create the spec
20:50:04 <blogan> oh tahts exactly what i needed johnsom
20:50:37 <blogan> sbalukoff: if the whiteboard doesn't have anything different than the etherpad, just add it to the etherpad if you dont mind
20:50:48 <sbalukoff> Ok.
20:51:14 <johnsom> It was #6 in the etherpad.  Pretty high level.
20:51:30 <dougwig> the summit etherpad also had a list. i don't remember if the midcycle was a cut/paste and then changes.
20:51:31 <johnsom> Ok, any other topics in our nine minutes left?
20:51:37 <dougwig> the whiteboard list was from the summit etherpad
20:52:37 <johnsom> I don't think I have that link
20:52:51 <blogan> i wish etherpads were searchable by title
20:53:04 <xgerman> well, there is a new summit ether pad we can add topics for design sessions to
20:53:20 <xgerman> that octavia standalone might be good topic
20:53:57 <johnsom> #link https://etherpad.openstack.org/p/mitaka-neutron-next-adv-services
20:54:06 <johnsom> Ok, searchable via google...  grin
20:54:24 <xgerman> and the austin one #link https://etherpad.openstack.org/p/newton-neutron-summit-ideas
20:55:37 <sbalukoff> Oh, we should get on that list again.
20:56:45 <johnsom> Feel free to add something if you have a topic you want to cover in a wider session
20:57:25 <johnsom> Ok, anything else?
20:57:33 <sbalukoff> Thanks folks!
20:57:39 <blogan> aye, thanks
20:57:51 <johnsom> #endmeeting