14:00:09 <dougwig> #startmeeting neutron lbaas
14:00:10 <openstack> Meeting started Thu Oct  2 14:00:09 2014 UTC and is due to finish in 60 minutes.  The chair is dougwig. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:14 <rm_mobile> o/
14:00:14 <openstack> The meeting name has been set to 'neutron_lbaas'
14:00:15 <sballe> \o/
14:00:18 <sbalukoff> Morning!
14:00:20 <blogan> \o/
14:00:22 <dougwig> #topic roll call
14:00:34 <johnsom> o/
14:00:38 <rm_mobile> o/
14:00:39 <dougwig> rm_work wanted to start with a short hello session today
14:00:55 <rm_mobile> Every day :P
14:01:02 <dougwig> ha
14:01:04 <sballe> :-)
14:01:31 <dougwig> #topic Announcements
14:01:35 <dougwig> v2 reviews
14:01:41 <dougwig> #link https://etherpad.openstack.org/p/lbaas_reviews
14:01:48 <dougwig> we need some + or -1's on the first couple reviews.
14:01:55 <dougwig> Kilo Design Summit
14:01:59 <dougwig> #link https://etherpad.openstack.org/p/kilo-neutron-summit-topics
14:02:05 <evgenyf> Hi
14:02:21 <dougwig> any other announcements?
14:03:13 <dougwig> moving on to a couple of items from this week's neutron meeting...
14:03:14 <evgenyf> I would like to know if there is some documentation how to use/develop project which is in inqubation
14:03:38 <blogan> evgenyf: neutron lbaas v2 isn't in incubator anymore, its in a feature branch
14:03:59 <dougwig> evgenyf: https://wiki.openstack.org/wiki/Neutron/FeatureBranch
14:04:07 <sballe> evgenyf: yeah the whole Neutron incubation thingy has gone away
14:04:16 <evgenyf> blogan: thanks, is there any difference from developers perspective?
14:04:23 <blogan> i believe they're going to reintroduce it for kilo
14:04:24 <dougwig> that wiki is pretty weak, but it's basically the same as before, but use a branch.
14:04:50 <evgenyf> dougwig:thanks
14:04:58 <rm_mobile> Evgeny, can you abandon the TLS CR's? They've been copied over to the new branch
14:05:12 <sballe> dougwig: so this is still true: https://wiki.openstack.org/wiki/Neutron/LBaaS/DeployWithDevstack right?
14:05:48 <evgenyf> rm_mobile: will do for L7 and TLS
14:05:52 <blogan> sballe: i updated that page with the correct reviews now
14:06:00 <rm_mobile> Doug, can you put the new CR for TLS as WIP?
14:06:06 <sballe> blogan: thanks
14:06:12 <dougwig> sballe: yes, though it needs to be updated with the new gerrit review #'s
14:06:22 <dougwig> #action blogan update deploywithdevstack lbaas wiki
14:06:30 <blogan> i ddi that
14:06:35 <dougwig> oh, sweet.
14:06:38 <sballe> ;-)
14:06:47 <blogan> #action dougwig undo that action
14:06:53 <sballe> blogan: dougwig Thanks
14:06:54 <dougwig> #undo
14:06:54 <rm_mobile> Lol
14:06:55 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x28efb50>
14:07:16 <blogan> #undo
14:07:21 <blogan> :(
14:07:29 <dougwig> evgenyf: does that answer your question?
14:07:37 <rm_mobile> They forgot item.get text()
14:07:48 <rm_mobile> Darn autocorrect
14:08:03 <dougwig> #undo
14:08:04 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x28ef1d0>
14:08:07 <evgenyf> dougwig: I think yes, thank you
14:08:36 <dougwig> #topic Kilo Specs repo is now open
14:08:42 <dougwig> #link http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/kilo
14:08:50 <dougwig> i expect that we need to resubmit our v2 specs.
14:09:01 <dougwig> i won't auto-move those, since rm_mobile might kill me if i do so.  :)
14:09:08 <blogan> lol
14:09:15 <rm_mobile> Lol
14:09:24 <rm_mobile> Nah, just nag you a lot
14:09:31 <dougwig> oh, that might be worth it.
14:09:39 <blogan> the lbaas v2 spec could definitely use some updating, probably a good time to do that
14:09:57 <xgerman> +1
14:10:41 <dougwig> one more tidbit from neutron:
14:10:42 <dougwig> #topic Juno Docs contributions
14:10:48 <dougwig> #link https://wiki.openstack.org/wiki/NetworkingGuide/TOC
14:10:52 <ptoohill> mornin'
14:11:10 <dougwig> if you have content for the network guide, you can edit that wiki, and the docs folks will move it to the right place.  there are several lbaas subsections.
14:12:20 <dougwig> #topic Requiring keystone v3? (rm_work)
14:12:24 <TrevorV> Forgive me, but what does TOC stand for?
14:12:24 <dougwig> rm_mobile: take it away
14:12:27 <rm_mobile> Uhh
14:12:30 <dougwig> #undo
14:12:30 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x25c7ed0>
14:12:33 <rm_mobile> Uhh skip me and come back
14:12:35 <dougwig> table of contents
14:13:05 <dougwig> now they're starting to fill in the content.
14:13:14 <dougwig> ok, skipping rm_mobile brings us to...
14:13:18 <dougwig> #topic Open discussion
14:13:44 <blogan> evgenyf: is sam around?
14:13:44 <rm_mobile> Lol
14:14:14 <evgenyf> blogan: around, not on this IRC mmeting
14:14:18 <sballe> Do we know who will be in Paris? I am hoping we can get some good discussions and resolution done while we are there face to face.
14:14:41 <blogan> evgenyf: okay ill have to send him an email
14:14:48 <rm_mobile> Any chance HP wants to sponsor me? :P
14:14:53 <blogan> sballe: from rax it will just be ptoohill and I
14:15:03 * rm_mobile nudges sballe
14:15:08 <ptoohill> yay :/
14:15:08 <sballe> rm_mobile: Sorry HP already cur down on our attendance :-(
14:15:11 <dougwig> sballe: i'll be there
14:15:22 <rm_mobile> Sad :(
14:15:32 <sballe> xgerman and I will be there too
14:15:51 <sballe> rm_mobile: Anybody from Rackspace?
14:15:58 <xgerman> rm_work did yoiunapply for the travel program?
14:16:12 <xgerman> also Cisco gas one person less to pay for
14:16:17 <rm_work> xgerman: no because I thought I was going via rackspace until after it closed
14:16:33 <rm_work> I literally already had a plane ticket and hotel reservations
14:16:45 <rm_work> then they said "nevermind cancel those" <_<
14:16:51 <blogan> you still have both!
14:16:55 <rm_work> true
14:16:59 <blogan> you can pay it out of pocket
14:17:08 <blogan> how committed are you to this project?
14:17:13 <sballe> blogan: that is going to be expensive
14:17:20 <rm_work> not quite that much <_<
14:17:30 <dougwig> rm_work: do you just want to wear the minimum pieces of flare?
14:17:35 <blogan> sballe: good way to weed out those who aren't committed fully
14:17:47 <sballe> blogan: you are mean ;-)
14:17:56 <blogan> i know :(
14:18:02 <blogan> or :)
14:18:28 <ptoohill> blogan wouldnt pay for it himself, js
14:18:45 <rm_work> oh, uhh
14:18:48 <blogan> im not crazy!
14:18:50 <rm_work> dougwig: you can come back to me i think
14:18:55 <ptoohill> not committed
14:18:59 <rm_work> since it looks like there's literally nothing else >_>
14:19:04 <dougwig> #topic Requiring keystone v3? (rm_work)
14:19:15 <rm_work> Ok so
14:19:45 <rm_work> Keystone versioning is confusing, but, it looks like Trusts is actually an extension, and is TECHNICALLY available via v2 Identity API
14:20:03 <rm_work> so if you don't expose Identity v3, but you do have the Trusts extension, it should be fine
14:20:16 <rm_work> though it is slightly less efficient (two round-trips instead of one)
14:21:00 <rm_work> and as far as Horizon, it looks like via Horizon it will use an actual key (since the user has just given it -- Horizon does a key-hijack essentially, it seems)
14:21:11 <dougwig> as long as we hide that nuance in a library call, creating LB's isn't a common operation, so i don't care if it's five round trips.
14:21:22 <rm_work> so creating a Trust via a Horizon popup if necessary shouldn't be a big deal
14:21:41 <rm_work> dougwig: kk, assuming we don't have to fetch TLS info on EVERY update
14:21:43 <dougwig> does that mean horizon will submit a key instead of a barbican id?
14:21:44 <xgerman> oh, ok, so they just hijack the ticket
14:21:57 <xgerman> ah key
14:22:00 <rm_work> dougwig: no, I mean
14:22:21 <rm_work> Horizon hijacks the user token from the user's login to the UI, and uses that
14:22:42 <rm_work> the concern was possibly only having access to a Trust token (which wouldn't be able to create further Trusts)
14:22:49 <rm_work> anywho
14:22:58 <dougwig> ahh, got it.
14:23:08 <rm_work> Hopefully everyone involved has the Trust extension in keystone available in their deployments, or can make that so?
14:23:19 <xgerman> that is a good question
14:23:20 <rm_work> If so, we shouldn't have a problem
14:23:30 <dougwig> i don't see a problem making trusts a requirement for tis support.  does anyone else?
14:23:31 <xgerman> sballe and I will check
14:23:49 <rm_work> Also, the authing is going to be a little bit complicated, it's going to have to be a plugin system anyway just to do this auth
14:23:58 <rm_work> since Rackspace doesn't technically use Keystone in our deployment <_<
14:24:10 <rm_work> and some people will use v2 and some will use v3 of Keystone Identity API
14:24:17 <dougwig> does this all work with heat?
14:24:46 <rm_work> if the user has set up Heat, they've already created one Trust for Heat, so we'll have to assume they are capable enough to create a second for us
14:24:53 <rm_work> Heat won't be able to automatically create a Trust for us
14:25:16 <rm_work> so any Heat templates will just have to assume the Trust was created and fail if not
14:25:26 <rm_work> since it's a once-per-account thing it shouldn't be a huge deal I think
14:25:37 <morganfainberg> rm_work, Trusts in Keystone V2 are not *really* well supported
14:25:53 <rm_work> morganfainberg: yeah, I'm relying on info from https://bugs.launchpad.net/keystone/+bug/1331884
14:25:55 <uvirtbot> Launchpad bug 1331884 in keystone "A V2 token from trust cannot be generated with user/pass" [Wishlist,In progress]
14:26:04 <morganfainberg> rm_work, just as a quick bit of insight, they are there, but have oddities. V3 is the right answer.
14:26:18 <morganfainberg> rm_work, that bug is on my short list of "probably don't want to accept it"
14:26:25 <rm_work> morganfainberg: ok... well, there are a lot of things that are the "right answer", but I don't know if we can manage all of them :)
14:26:45 <rm_work> morganfainberg: definitely value further input though, if you have ideas...
14:27:01 <morganfainberg> i tend to view v2 as frozen, no new features. that falls into the category of new features. i've held off on squashing it though for a bit.
14:27:03 <rm_work> so we have one recommendation for Keystone Identity v3 API requirement
14:27:22 <rm_work> morganfainberg: so that doesn't *actually* work yet?
14:27:38 <morganfainberg> v2 tokens directly from username/password in trusts?
14:27:39 <morganfainberg> no.
14:27:39 <rm_work> morganfainberg: i think I read the bug as "you have to do it this slow way, could you fix it so it's one call"
14:27:54 <rm_work> ok, so it's *not possible* yet, and *would* look like that, if implemented
14:27:56 <morganfainberg> you can't do it as 1 call, you need token and then exchange the token for the trust
14:28:01 <rm_work> whelp, back to v3 req
14:28:13 <rm_work> morganfainberg: err wait, so was I correct or not?
14:28:23 <morganfainberg> ok, sorry :)
14:28:39 <morganfainberg> you *can* uses trusts with V2, you cannot do it as one pass
14:28:42 <rm_work> right
14:28:51 <morganfainberg> you can only get trust tokens via a token.
14:29:00 <rm_work> so that's "fine" if it's what it takes to keep from introducing a hard requirement on Identity v3 in Neutron
14:29:11 <rm_work> I think we'd all probably like to avoid that if possible
14:29:23 <rm_work> since this isn't just for neutron-lbaas, it's going into neutron/common
14:29:26 <morganfainberg> we're talking for Kilo cycle right?
14:29:33 <rm_work> yes
14:29:50 <dougwig> i'm thinking a broader audience with the ML might be warranted here.  i know you got very few replies with your first open ended query, but maybe a focused question/warning along the lines of 'lbaas/tls is going to require the user to set a trust just for lbaas, is this a problem?", targeted at neutron/heat/keystone, will get more eyeballs on it.
14:30:09 <morganfainberg> ok. well quick recommendation, V3, if you're using trusts is a much better target
14:30:10 <rm_work> yeah I'll include like, every tag I can think of
14:30:30 <rm_work> and basically just resend that email with a few updates about the v3 req
14:30:48 <morganfainberg> and for Kilo my expectation is we will get everyone off V2, i am hoping V2 can be deprecated formally within the nex cycle or two
14:31:05 <blogan> rm_work: make it as brief as you can, people tend to not read lengthy emails
14:31:13 <dougwig> blogan: +1
14:31:14 <morganfainberg> but that is a lofty goal, so, whatever you're deciding I recomment you make sure it works both v2/v3
14:31:25 <morganfainberg> if at all possible.
14:31:38 <rm_work> k...
14:31:43 <rm_work> funtimes
14:31:51 <rm_work> that's it for me then I think
14:32:01 <xgerman> back top Open Discussion
14:32:04 <rm_work> morganfainberg: though if you wanted to accept that bug, i wouldn't complain :)
14:32:09 <dougwig> #topic Open discussion
14:32:26 <xgerman> rm_work you might want to start a kickstarter for your Paris trip
14:32:32 <rm_work> lol
14:32:41 <rm_work> xgerman: I don't know if that's against their EULA
14:32:47 <morganfainberg> rm_work, i've been waiting on it, i honestly don't want to encourage new "functionality" to v2. but it's on my list for needs eval. can't just squash it
14:32:51 <morganfainberg> rm_work, gofundme ;)
14:32:53 <rm_work> but if not.... maybe? :P
14:32:57 <morganfainberg> rm_work, or indigogo instead :P
14:33:01 <rm_work> heh
14:33:14 <rm_work> morganfainberg: i'm +1ing it
14:34:06 <morganfainberg> so in short, go ahead and use v2 trusts, but it is highly highly recommended you use v3 instead :). [next cycle or two for formal deprecation means likely L or M]
14:34:26 * morganfainberg lets you guys get back to your discussion.
14:34:55 <xgerman> thanks morganfainberg, very good info!
14:34:55 <dougwig> thanks for your input today morganfainberg
14:35:12 <dougwig> any other topics to discuss besides rm_work's paris woes?  if not, we'll end early today.
14:36:00 <dougwig> ok, bye folks...
14:36:01 <ptoohill> Guess I may have missed the answer, but are we re-creating the CR's?
14:36:03 <sballe> bye
14:36:06 <ptoohill> srry, im slow ><
14:36:26 <dougwig> ptoohill: most have been carried over: https://etherpad.openstack.org/p/lbaas_reviews
14:36:28 <blogan> ptoohill yes
14:36:30 <xgerman> it looks to me like we are resetting the clock
14:36:34 <dougwig> drivers and specs need to be done by their original authors
14:37:09 <ptoohill> k, got further details from aharwell. Thanks guys
14:37:21 <dougwig> cool
14:37:28 <dougwig> anything else from folks?
14:37:35 <ptoohill> rm_mobile* :P
14:37:46 <TrevorV> \o
14:37:50 <xgerman> bye
14:37:59 <johnsom> bye
14:38:02 <dougwig> bye
14:38:06 <ptoohill> adios
14:38:09 <dougwig> #endmeeting