18:02:21 <dolphm> #startmeeting keystone
18:02:22 <openstack> Meeting started Tue Jun 24 18:02:21 2014 UTC and is due to finish in 60 minutes.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:26 <openstack> The meeting name has been set to 'keystone'
18:02:30 <topol> o/
18:02:35 <dolphm> nothing new on the hackathon front, so:
18:02:39 <dolphm> #topic Keystone Middleware Repo Created!
18:02:39 <gyee> \o
18:02:42 <dolphm> morganfainberg_L: o/
18:02:45 <morganfainberg_L> Middleware Repo is in!
18:02:54 <ayoung> now the real work begins
18:02:57 <morganfainberg_L> all new middleware code changes should go against keystonemiddleware
18:03:00 <stevemar> yay another thing to track in gerrit
18:03:08 <bknudson> so at some point it gets released
18:03:11 <dolphm> morganfainberg_L: do we have patches to move everything over?
18:03:16 <bknudson> any reason it can't be released today?
18:03:30 <ayoung> we need to deprecate keystoneclient.middleware.*
18:03:32 <morganfainberg_L> bknudson: i want to make sure we're not missing anything before we release
18:03:37 <morganfainberg_L> bknudson: but other than that no
18:03:46 <bknudson> personally I'd rather changes were covered by tempest before merging anything new
18:03:49 <ayoung> add to devstack
18:03:55 <morganfainberg_L> dolphm: everything should be moved over, history was preserved
18:04:05 <morganfainberg_L> ayoung: yes, i am going to be proposing that fix today
18:04:09 <ayoung> ++
18:04:14 <bknudson> I think devstack will install it once it's in requirements.txt
18:04:15 <morganfainberg_L> bknudson: tempest and stable bitrot jobs are included
18:04:28 <dolphm> morganfainberg_L: i was including that ^ in the notion of "move everything over"
18:04:34 <morganfainberg_L> bknudson: no, it needs to be sources frmo the repo, like django_openstack_auth
18:04:41 <morganfainberg_L> dolphm: ++
18:04:48 <morganfainberg_L> the initial release will be 1.0.0
18:04:49 <dolphm> swapping imports in other projects as well
18:04:56 <morganfainberg_L> we're calling this "stable" :)
18:04:57 <dolphm> morganfainberg_L: ++
18:05:14 <morganfainberg_L> LP project has been created, pypi target as well
18:05:22 <morganfainberg_L> dolphm holds the keys to release (same as ksc)
18:05:27 <bknudson> once it's released we'd change other projects to use it?
18:05:37 <dolphm> morganfainberg_L: let me know when to push buttons
18:05:40 <morganfainberg_L> bknudson: we can do an alpha release and do some initial work on that
18:05:52 <bknudson> y, i'd expect an alpha release
18:06:05 <dolphm> #action Everyone: add openstack/keystonemiddleware to your watched projects in gerrit
18:06:13 <morganfainberg_L> bknudson: basically, everyone do a once over, make sure it looks right, i'm working on the devstack front
18:06:33 <morganfainberg_L> if there are no issues we can release an alpha (and get it in global reqs) soon
18:06:59 <morganfainberg_L> #action We need tests for ec2_token middleware
18:07:03 <bknudson> http://git.openstack.org/cgit/openstack/keystonemiddleware/tree/
18:07:07 <bknudson> hehe
18:07:10 <morganfainberg_L> there weren't any afaict
18:07:24 <morganfainberg_L> so i didn't port any
18:07:24 * ayoung takes a note that we are going to need a new RPM
18:07:51 <morganfainberg_L> i verified before the repo was created docs build worked, pep8, and py27 worked
18:08:23 <dolphm> morganfainberg_L: proposed a change to openstack/governance https://review.openstack.org/#/c/102305/
18:08:25 <morganfainberg_L> once we release we can deprecate all the other middlewares. I'll be retargeting bugs in LP for ksc against middleware this week.
18:08:33 <morganfainberg_L> dolphm: ++ :)
18:09:23 <morganfainberg_L> uh.. thats it from me :)
18:10:09 <topol> so we can stop watching keystoneclient?
18:10:14 <dolphm> morganfainberg_L: danke!
18:10:15 <ayoung> topol, you can
18:10:18 <dolphm> topol: hell no
18:10:27 <ayoung> heh
18:10:28 <bknudson> keystoneclient still has the python API
18:10:45 <stevemar> topol, nope, just the middleware is being separated, still has all the library and API stuff
18:10:49 <morganfainberg_L> dolphm: i'll send a nice email to -dev mailing list today as well.
18:10:56 <dolphm> we'll have to alert packagers as well
18:10:57 <stevemar> morganfainberg, ++
18:11:11 <morganfainberg_L> dolphm: sould i x-post to main openstack list?
18:11:18 <topol> so on the keystone info page someone will update so newbies can find all the repos and what is in what?
18:11:21 <dolphm> morganfainberg_L: i'd send a different note in that direction, honestly
18:11:30 <morganfainberg_L> dolphm: ok
18:11:38 <morganfainberg_L> dolphm: maybe we should wait to send there until we release
18:11:39 <dolphm> morganfainberg_L: want to etherpad both? i could contribute a bit
18:11:43 <morganfainberg_L> dolphm: ++ will do
18:11:44 <dolphm> morganfainberg_L: ++
18:11:44 <bknudson> does keystonemiddleware have its own launchpad? (and where do bugs get reported?)
18:11:45 <topol> cause we have blossomed a little :-)
18:11:50 <morganfainberg_L> bknudson: yes it does
18:12:07 <ayoung> #action topol to update keystone info page
18:12:12 <dolphm> #action dolphm to move bugs to https://launchpad.net/keystonemiddleware
18:12:13 <bknudson> https://launchpad.net/keystonemiddleware
18:12:33 <morganfainberg_L> dolphm: let me know if you want help moving bugs around
18:12:33 <topol> ayoung, cool. folks give me authority to do that?
18:12:41 <bknudson> no bugs in keystonemiddleware now
18:12:45 <bknudson> nice
18:12:49 <topol> yep its empty
18:12:52 <topol> I checked
18:13:02 <dolphm> topol: you can grant yourself that authority i believe...
18:13:06 <topol> k
18:13:25 <dolphm> anyone have a link to the keystone bug team thing? i can't remember what it's called
18:13:27 <topol> I'll handle
18:13:28 <ayoung> #action ayoung to set all keystoneclient middleware bugs to "also affects keystonemiddleware"
18:13:33 <morganfainberg_L> keystonedrivers?
18:13:41 <lbragstad> #link https://launchpad.net/~keystone-drivers
18:13:42 <stevemar> topol, https://wiki.openstack.org/wiki/Keystone might want to add the keystone-specs too :D
18:13:45 <dolphm> morganfainberg_L: no, there's a public group
18:13:49 <morganfainberg_L> dolphm: oooh
18:13:52 <topol> stevemar ++++
18:13:53 <morganfainberg_L> dolphm: uh
18:14:24 <dolphm> i have no idea where to find it...
18:14:29 <dolphm> ooh
18:14:29 <ayoung> Current middleware bugs https://bugs.launchpad.net/python-keystoneclient/?field.searchtext=middleware&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&
18:14:29 <ayoung> field.has_no_package=
18:14:36 <dolphm> anyone can join this group https://launchpad.net/~keystone-bugs
18:14:38 <ayoung> let me try that again
18:14:45 <ayoung> https://bugs.launchpad.net/python-keystoneclient/?field.searchtext=middleware&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
18:14:50 <morganfainberg_L> the keystonedrivers group (core) should have access to update the middleware lp page as needed (Same as ksc)
18:15:01 <morganfainberg_L> dolphm: please 2x check i don't need to "fix" anything in the lp page for middleware
18:15:10 <morganfainberg_L> i think i got it all so you/other cores can fix as needed
18:15:38 <dolphm> morganfainberg_L: it all looks right to me
18:15:39 <morganfainberg_L> i also created 1.0.0 milestone pre-emptively
18:16:08 <ayoung> is it going to be a problem that it is keystonemiddleware and not python-keystonemiddleware?
18:16:14 <morganfainberg_L> ayoung: no
18:16:17 <ayoung> at least, that is what launchpad calls it
18:16:21 <dolphm> morganfainberg_L: you actually made a 1.0.0 series... which should be a 1.x.x series
18:16:30 <morganfainberg_L> dolphm: ah lets fix that then
18:16:33 <ayoung> morganfainberg_L, than can we renamte python-keystoneclient to keystoneclient?
18:16:34 <dolphm> morganfainberg_L: done
18:16:42 <ayoung> Not asking to
18:16:48 <dolphm> morganfainberg_L: you can then create a 1.0.0 milestone within that series
18:16:48 <ayoung> asking if it would be possible, or
18:16:58 <morganfainberg_L> dolphm: hm, looks like i can't remove a series?
18:17:05 <morganfainberg_L> oh you fixed:P
18:17:06 <ayoung> if something requires the python- prefix?
18:17:07 <morganfainberg_L> haha
18:17:07 <dolphm> morganfainberg_L: maybe because i just renamed it
18:17:11 <ayoung> I though it was a package thing
18:17:26 <morganfainberg_L> ayoung: nah, otherwise keystone would need it as well
18:17:55 <ayoung> morganfainberg_L, I guess we'll find out
18:17:56 * gyee planning on checking in java middleware in that repo as it longer prefix with python-
18:18:04 <bknudson> ayoung: someone might write a .NET client and call it .NET-keystoneclient
18:18:20 <topol> keystone client will eventually be depracted via openstack client correct?
18:18:23 <bknudson> unix folks would never see it
18:18:27 <morganfainberg_L> topol:  the CLI
18:18:32 <morganfainberg_L> topol:  not the library part
18:18:40 <gyee> topol, that's the rumor
18:18:41 <dolphm> i know someone has implemented c++ middleware for keystone
18:18:45 <bknudson> well, maybe the openstacksdk will make it useless
18:18:51 <ayoung> 2 bugs now
18:19:02 <topol> but the library is now going into middleware or am I confused as usal/
18:19:05 <morganfainberg_L> in theory, we could have non-python middleware in that repo eventually.
18:19:08 <dolphm> and rackspace has a java version http://openrepose.org/
18:19:17 <bknudson> then we also have the cms code in python-keystoneclient
18:19:48 <dolphm> bknudson: i think we need a python-keystonelib package for cms...
18:19:49 <ayoung> we are not targetting python 2.6 for middleware, correct?
18:20:05 <morganfainberg_L> ayoung: middleware is the same as ksc
18:20:14 <morganfainberg_L> ayoung: we haven't dropped 2.6, therefore we can't drop it here
18:20:19 <ayoung> morganfainberg_L, OK
18:20:30 <dolphm> there was a summit session on 2.6 - does anyone know the outcome?
18:20:41 <morganfainberg_L> dolphm: suse was the one up in the air still
18:21:06 <dstanek> dolphm: on dropping 2.6? i heard that we can't because of a linux distro
18:21:08 <morganfainberg_L> dolphm: everyone else was ok with dropping 2.6, long term 2.6 support will last until we EOL the last of the releases that had 2.6 support
18:21:10 <dolphm> i don't see a summit etherpad on the topic
18:21:12 <ayoung> I think that RH has pulled the requirement
18:21:28 <ayoung> we have "collections" now which lets us run python >2.6 for openstack
18:21:29 <dolphm> so where is suse at on support?
18:21:42 <morganfainberg_L> dolphm: my guess is K will be where we drop 2.6
18:22:06 <dstanek> dolphm: https://etherpad.openstack.org/p/juno-cross-project-future-of-python
18:22:10 <dolphm> dropping 2.6 support would be a huge advantage for the gate
18:22:24 <morganfainberg_L> dolphm: gate will still need to support 2.6 for EOL purposes
18:22:49 <dolphm> dstanek: thanks!
18:22:57 <dstanek> yes, they said that they'll have a very long time before they get rid of the gate support
18:22:58 <dolphm> morganfainberg_L: only on stable/ though, right?
18:23:16 <morganfainberg_L> right
18:23:33 <morganfainberg_L> middleware likely will need to remain 2.6 compat until we drop the last 2.6 capable release to EOL
18:23:40 <morganfainberg_L> (likely Juno will still be 2.6 compat)
18:23:43 <dolphm> well, then nothing to get excited about for now
18:23:54 <dolphm> #topic open discussion
18:24:20 <ayoung> morganfainberg_L, but that would be the old packages
18:24:24 <ayoung> not keystonemiddleware
18:24:31 <ayoung> just python-keystoneclient
18:24:45 <morganfainberg_L> ayoung: if juno is 2.6 compatible, middlware will need to keep it since we'll be adopting the new packaging this cycle
18:24:58 <ayoung> morganfainberg_L, we are going to need to keep the existing packageset for older releases
18:25:18 <morganfainberg_L> ayoung: yep. clients will be in the same boat
18:25:19 <ayoung> OK, so we'll get 2.6 as a req that way
18:25:25 <dstanek> dolphm: publish your secret reviewday support when you have a chance - i'd love to start trying it out
18:25:45 <dolphm> dstanek: lol ++
18:26:27 <bknudson> any specs we think are ready to go in?
18:26:45 <bknudson> if we don't get any specs in then this is going to be a pretty small release
18:26:53 <stevemar> i'd like to appeal to folks to review https://review.openstack.org/#/c/100023/ -> 'federating multiple keystone', it's getting kind of ugly and complicated
18:27:01 <morganfainberg_L> dolphm: https://etherpad.openstack.org/p/dev_keystonemiddleware_anouncement
18:27:27 <stevemar> morganfainberg, your etherpad is rather empty
18:27:32 <morganfainberg_L> stevemar: shush
18:27:35 <kwss> stevemar, I'd like to ask a question about that
18:27:36 <morganfainberg_L> :P
18:27:45 <stevemar> kwss ! go ahead
18:28:13 <kwss> Will keystone to keystone federation use the same mapping / attribute trust mechanisms as saml2 etc.?
18:28:23 <dstanek> stevemar: yes, i want to go over that again today - started looking yesterday after jsavak pushed
18:28:26 <bknudson> good question
18:28:51 <morganfainberg_L> kwss: very good question
18:29:13 <gyee> I don't see why not
18:29:17 <dolphm> stevemar: ugly and complicated sounds like you have work to do before appealing to reviewers :P
18:29:18 <dstanek> kwss: i think it should
18:29:24 <kwss> me too
18:29:36 <dstanek> i don't see the difference between k2k and federation
18:29:52 <gyee> dstanek, exactly
18:29:59 <stevemar> dolphm, actually, i wanted you to weigh in on it, its growing too big, there are too many use cases being proposed
18:30:40 <dolphm> stevemar: that's the danger with federation it seems - need to narrow the use case that we pursue to ONE, and ensure that we're making room to support the rest later
18:32:01 <dolphm> ayoung: wow, thanks for moving bugs over
18:33:04 <kwss> I think that all protocols should use the same common mechanisms
18:33:05 <bknudson> kwss & others: https://review.openstack.org/#/c/100279/ -- this spec looks like a good to me!
18:33:07 <morganfainberg_L> ayoung: i think session tokens are important if we can shore that spec up.
18:33:08 <ayoung> morganfainberg_L, wilco
18:33:09 <morganfainberg_L> bknudson: that one looks close.
18:33:09 <dstanek> stevemar: all of the use cases i have seen are very similar
18:33:10 <morganfainberg_L> bknudson: at the very least like a decent idea with a lot of thought put into it
18:33:10 <stevemar> kwss, so both keystone instances should be running something like mod_shib to talk to each other?
18:33:10 <bknudson> morganfainberg_L: I think it exposes that we've got a security issue in idps
18:33:10 <morganfainberg_L> bknudson: we do.
18:33:10 <bknudson> morganfainberg_L: more like an issue of trusting too much
18:33:10 <morganfainberg_L> bknudson: ++
18:33:11 <stevemar> bknudson, only when using regex ?
18:33:11 <bknudson> stevemar: y, the regex
18:33:11 <morganfainberg_L> bknudson: if we can narrow that down to be more restrictive it would def. be good
18:33:34 <kwss> stevemar, the actual communication between the two servers is a separate issue, I meant the same mechanisms are handling mapping / authorization
18:33:52 <ayoung> dolphm, yeah...pretty easy once I got rolling
18:34:03 <ayoung> some of those will end up falling squarely on one side or the other
18:34:27 <dolphm> ayoung: ++ i'm copying statuses over on the ones you're marking as affecting keystonemiddleware
18:34:37 <stevemar> kwss, if we can re-use them, then sure
18:34:44 <ayoung> dolphm, it does mean that all reafactorings from auth_token middleware to keystoneclient will start with adding code to the client, and then a second review to remove from the middleware
18:34:47 <ayoung> dolphm, ++
18:35:22 <bknudson> ayoung: I think there's no more changes to keystoneclient middleware except for security fixes
18:35:31 <morganfainberg_L> bknudson: ++
18:36:23 <dolphm> bknudson: we can't just do an import from keystonemiddleware ?
18:36:27 <stevemar> kwss, you mean the mapping engine, and leveraging groups and roles?
18:36:33 <ayoung> bknudson, right.  I'm talking about the keystonemiddleware version.  Now that the middleware is split from the client, and since we still have more refactoring to do, we will have to split reviews over both repos
18:36:38 <bknudson> dolphm: no, circular dependency!
18:36:49 <morganfainberg_L> ayoung:  yes.
18:36:54 <kwss> stevemar, what I'd like to see is a flow which is separated into protocol dependent i.e keystone to keystone communication and protocol independent (mapping etc.) operations
18:37:12 <morganfainberg_L> ayoung: and changes to client need a release before they can really be consumed by the middleware
18:37:27 <stevemar> kwss, i'd love to see that too! but I can't seem to get passed the darn use cases right now
18:37:38 <topol> too many use cases :-(
18:37:49 <dolphm> bknudson: that's why i'd like to have keystonelib
18:37:59 <kwss> stevemar, yea and hopefully trusted attribute filter too
18:37:59 <stevemar> kwss, topol too many voices (in my head and in the review)
18:38:14 <morganfainberg_L> dolphm: i'd be happy to do the same work to split the stuff out if we can identify what we want split
18:38:17 <topol> stevemar +++ what do you recommend
18:38:20 <morganfainberg_L> dolphm: it's not hard (just timeconsuming)
18:38:28 <kwss> stevemar, what can I do to help?
18:38:47 <dolphm> morganfainberg_L: off the top of my head, i'm only aware of keystoneclient.common.cms
18:38:53 <morganfainberg_L> dolphm: session?
18:39:19 <stevemar> kwss, in line comments in the review, and if you have time, can we chat after?
18:39:23 <dstanek> stevemar: i'm sorta interested in the higher level usecase - be able to federate keystones just like anything else
18:39:23 <dolphm> morganfainberg_L: hmmmmmmm
18:39:28 <ayoung> morganfainberg_L, ooh. that is going to be painful.  middleware will only test against a released version of the client
18:39:35 <morganfainberg_L> ayoung: yep
18:39:45 <kwss> stevemar, sure to both, I'll point David at the review too
18:39:46 <dstanek> stevemar: we seem to be making this too complicated
18:39:52 <morganfainberg_L> ayoung: though i can work aroudn that in devstack with a little magic
18:40:16 <morganfainberg_L> ayoung: i'll be putting those reviews up today.
18:40:28 <stevemar> dstanek, that was my comment about ugly and complex
18:40:57 <stevemar> though craig has a good point about the terminology, we're not being consistent right now
18:41:13 <morganfainberg_L> dolphm: if sesson and cms were not in ksc (and then auth plugins?) then we could avoid a lot of circular deps
18:41:26 <topol> could we cut federation down to 2 primary use cases?
18:41:27 <dstanek> stevemar: what is the timeline to get this approved? it seems like a good discusson for the hackathon
18:41:35 <topol> and stay focused?
18:41:36 <morganfainberg_L> dolphm: though i'd really want to talk to jamielennox before we try to split that stuff out
18:41:37 <dolphm> topol: that would be nice :)
18:41:46 <dolphm> morganfainberg_L: ++
18:42:07 <dolphm> morganfainberg_L: if the use case for cms is agreeable, i can create a spec for just that, and we can go case by case?
18:42:09 <morganfainberg_L> dolphm: but it would likely make other clients consuming session and auth plugins waaaay easier
18:42:22 <stevemar> topol, i think that is a good idea
18:42:23 <bknudson> my opinion was that we should remove the keystonemiddleware dependency from keystoneclient and do the imports
18:42:29 <bknudson> it's essentially optional
18:42:31 <stevemar> i'm a fan of the bursting one
18:42:45 <dolphm> bknudson: ? long term or immediately?
18:42:48 <stevemar> dstanek, i was really hoping to have this approved or near approved for the hackathon
18:42:50 <dstanek> topol: agreed, but i think all of the uses cases should be captured and then we can generalize that in the spec say exactly which ones will be focused on
18:43:02 <morganfainberg_L> bknudson: so if middleware is available import?
18:43:04 <stevemar> dstanek, ++
18:43:07 <bknudson> dolphm: I think we'd need to give it some small amount of time
18:43:09 <topol> we always have another release, another hackathon in SAT, unless dolphm runs out of good restaurants to take us too
18:43:13 <dolphm> bknudson: sure
18:43:30 <morganfainberg_L> bknudson: and remove the middleware in ksc completely?
18:43:36 <bknudson> morganfainberg_L: no need to check if it's available... paste isn't going to start with it.
18:43:37 <dstanek> topol: we need to start having them at a beach
18:43:50 <morganfainberg_L> bknudson: ok i'm confused.
18:44:09 <morganfainberg_L> bknudson: explain it like i'm 5 :P (ugh, i feel fogged today)
18:44:12 <topol> dstanek, shame.  we come to SAT to get things done, not see you in your speedo :-)
18:44:19 <bknudson> morganfainberg_L: no, ksc still does the imports
18:44:30 <stevemar> topol, nice visual
18:44:31 <bknudson> morganfainberg_L: the middleware is only used if you put it in your paste pipeline
18:44:35 <morganfainberg_L> right
18:44:42 <bknudson> it's not used if you're just making use of the client
18:44:57 <morganfainberg_L> so keystoneclient.middleware imports keystonemiddleware?
18:44:57 <bknudson> so regular apps aren't going to fail if they don't have the middleware around
18:45:18 <morganfainberg_L> but there isn't a dep to install keystonemiddleware explicitly
18:45:19 <morganfainberg_L> ?
18:45:26 <dolphm> dstanek: hawaii?
18:45:43 <bknudson> morganfainberg_L: right. no middleware in ksc requirements
18:45:47 <ayoung> I think that might be going too far
18:45:52 <topol> I can get myself approved for hawaii but probably not everyone else :-(
18:46:00 <ayoung> we need to package up  keystonemiddleware anyway
18:46:07 <dolphm> it's the easiest way to include both the US and australia
18:46:11 <dstanek> dolphm: sounds great!
18:46:13 <dolphm> i mean, it's only logical
18:46:23 <ayoung> and doing that implies a bunch of changes beyond the paste change
18:46:27 <lbragstad> I +1 that logic
18:46:27 <morganfainberg_L> bknudson: that would break some EOL releases with new keystoneclient releases though
18:46:38 <morganfainberg_L> bknudson: that was my only real concern. and grizzly is widely used
18:46:39 * topol face palm trying to get hawaii approvals...
18:46:45 <ayoung> yeah
18:46:48 <stevemar> i see how it is, henrynash and I aren't even included
18:46:49 <ayoung> too much to break
18:46:49 <dstanek> topol: don't worry i'll have my speedo in SAT - i'll wear it for casual Friday
18:47:10 <morganfainberg_L> bknudson: it's why the spec opted for sec-maintenance for the middleware in ksc
18:47:11 <bknudson> morganfainberg_L: y, it wouldn't affect us since we don't package that way
18:47:19 <topol> dstanek, I'll have to skip lunch to be safe then :-)
18:47:28 <morganfainberg_L> but people do use newer clients with older services
18:47:45 * dolphm hackathon update: for everyon's own safety, do not show up on friday
18:47:57 <morganfainberg_L> dolphm: ?
18:48:00 <bknudson> fri the week before?
18:48:01 <topol> joke
18:48:11 <morganfainberg_L> oh oh
18:48:12 <bknudson> is there a gun show?
18:48:12 <morganfainberg_L> damn it
18:48:13 <dstanek> lol
18:48:16 <ayoung> Ok,  any thoughts on this:  is there anyway to to endpoint binding of tokens without endpoints knowing their own ids?
18:48:19 <lbragstad> lol
18:48:25 <dolphm> morganfainberg_L: dstanek's gun show featuring speedos
18:48:27 * morganfainberg_L facepalms
18:48:33 <morganfainberg_L> i uh...
18:48:33 <bknudson> I assume we're allowed to open carry there?
18:48:34 <morganfainberg_L> no
18:48:43 <lbragstad> suns out guns out?
18:48:44 <dolphm> bknudson: conceal only in texas
18:49:09 <gyee> ayoung, sure, each endpoint have their own unique cert/private key
18:49:22 <ayoung> gyee, nope
18:49:23 <gyee> just encrypt the toke for that endpoint only
18:49:30 <ayoung> that doesn't work for multi
18:49:38 <ayoung> so token is for 3 endpoints only
18:49:45 <ayoung> that only works for one specific endpoint
18:49:55 <gyee> you issue the token for that endpoint only
18:50:17 <gyee> so encrypting it with the endpoint's public key
18:50:18 <ayoung> gyee, that is a lot of infrastrucutre
18:50:38 <gyee> ayoung, but arn't we pushing PKI already?
18:50:47 <ayoung> and it seems like a misuse of crypto.  THere is nothing wrong with othser services seeing the token contents
18:51:13 <morganfainberg_L> bknudson: largely speaking, you can use 0.9.0 keystoneclient (and middleware) as far back as you want as long as you configure it correctly
18:51:21 <gyee> why, if that token is only good for that particular endpoint
18:51:22 <topol> lbragstad... its in the constitution son
18:51:29 <ayoung> gyee, and, really, that is just replace "endpoint id" with "endpoint keypair"
18:52:02 <dolphm> it also lets endpoints share keys, which seems totally reasonable
18:52:12 <bknudson> morganfainberg_L: y, and you need to start installing all the new deps for 0.9.0... good luck!
18:52:24 <gyee> dolphm, sure, PKI is made for that stuff
18:52:27 <ayoung> dolphm, shared keys does not seem reasonable to me
18:52:38 <ayoung> you'd have to share a private key
18:52:48 <morganfainberg_L> bknudson: hm. how far have the deps changed (conflicted) since say... grizzly release (assuming no one uses folsom)
18:52:49 <ayoung> which is generally frowned upon
18:52:53 <gyee> multiple instances of an endpoint?
18:53:04 <dolphm> ayoung: if i deploy two services on the same node, i'm might not care that they share private keys, etc
18:53:20 <dolphm> ayoung: or like glance api and glance registry, for example
18:53:25 <gyee> sure multiple instances of an endpoint have to share the same keys
18:53:35 <ayoung> my thought, though, is that if we need to give each endpoint an identity of some sort, then maybe we use that identity for fetching policy after all
18:53:56 <ayoung> I really don't want to build that infrastructure unless it is well justified
18:54:00 <ayoung> I don't think it is yet
18:54:06 <gyee> endpoints should have an identity anyway
18:54:17 <ayoung> gyee, why not the service users
18:54:20 <ayoung> that seems to make more sense
18:54:29 <ayoung> but we can't bind a token to a service user
18:54:35 <gyee> they can use the service identity sure
18:54:53 <ayoung> actually, we totally could
18:54:57 <gyee> but an identity can have multiple keys
18:54:59 <bknudson> morganfainberg_L: our issue is that we need to go through legal to get new packages approved
18:55:15 <ayoung> token { "service_user":"keystone"}  means only the keystone service user should treat the token as valid
18:55:43 <gyee> endpoint-scope and service-scope, killing two birds with one stone
18:55:47 <dolphm> why can't all users just have keys?
18:55:47 <ayoung> but we'd need that information when we issued the token.  And there is no link in keystone between the service users and the endpoiints yet
18:55:53 <gyee> apologize to the animal lovers
18:56:00 <ayoung> we don't need PKI for this
18:56:01 <dolphm> and then all everything barbican everywhere
18:56:09 <ayoung> we just need to identify who can use the token
18:56:10 <morganfainberg_L> bknudson: aren't you going to have to do that anyway even with what you're proposing?
18:56:35 <gyee> dude, we are using PKI tokens already!
18:56:38 <gyee> make it count
18:56:46 <bknudson> morganfainberg_L: well, we handle new releases, but old releases use old client. we're not affected
18:56:47 <ayoung> gyee, we have one service that requires tokens,  not everywhere
18:57:04 <ayoung> lets not build things just to build them
18:57:05 <gyee> ayoung, I mean the framework is already there
18:57:10 <ayoung> people get lynched that way
18:57:10 <gyee> just make use of it
18:57:14 <ayoung> no, it really is not
18:57:25 <ayoung> I mean, I like PKI as an option
18:57:34 <ayoung> just not a hard requirement, for the endpoint to validate to keystone
18:57:45 <gyee> I think PKI is a great option for this stuff
18:57:54 <ayoung> gyee, option, yes
18:57:56 <ayoung> requirement, not
18:57:58 <morganfainberg_L> still don't see how that really affects things here. i'm thinking from the standpoint of a couple companies i know that use latest *client* + grizzly services and breaking their deployment with the next ksc relese would be ugly
18:58:04 <ayoung> and, it is beside the point
18:58:10 <ayoung> the issue is not PKI or no PKI
18:58:24 <gyee> I though you ask how to make the stuff work
18:58:26 <bknudson> morganfainberg_L: they can't install keystonemiddleware?
18:58:34 <ayoung> the issue is "do we use the endpoint id for policy fetch"  and "do we use the endpoint id for token binding"
18:58:42 <ayoung> if not, then what do we do
18:58:58 <morganfainberg_L> they can, but i am not seeing a compelling argument to break them?
18:59:04 * dolphm 1 min
18:59:13 <ayoung> and I think the policy fetch is leaning toward "use the service users context"
18:59:19 <morganfainberg_L> bknudson: i might be missing the point of ripping it out in a hurry
18:59:22 <morganfainberg_L> thats all
18:59:45 <morganfainberg_L> talk morein -keystoen after meeting
18:59:58 <gyee> ayoung, service account should be fine, services owns the endpoints anyway
19:00:15 <bknudson> morganfainberg_L: we can take as long as we think is prudent
19:00:24 <dolphm> #endmeeting