18:00:21 <heckj> #startmeeting keystone
18:00:22 <openstack> Meeting started Tue Nov 13 18:00:21 2012 UTC.  The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:23 <gyee> \o
18:00:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:24 <ayoung> /O/
18:00:25 <openstack> The meeting name has been set to 'keystone'
18:00:25 <heckj> Ola y'all
18:00:39 <dolphm> hola
18:00:46 <dwchadwick> hello
18:00:47 <heckj> Did I catch it correctly that we have a David Chadwick lurking here today?
18:00:50 <heckj> Yeah!!!!
18:00:54 <heckj> #link Agenda: http://wiki.openstack.org/Meetings/KeystoneMeeting
18:00:54 <ayoung> gyee,
18:00:59 <gyee> yo
18:01:00 <dwchadwick> for the first time, yes
18:01:07 <dolphm> dwchadwick: welcome!
18:01:09 <Kristy> hello
18:01:15 <heckj> dwchadwick: glad you could make it
18:01:19 <heckj> Kristy: awesome! Welcome!
18:01:30 <dwchadwick> the full monty today
18:02:12 <heckj> #topic Burning/Exploding/Supernova issues?
18:02:28 <heckj> So, let's get rolling - anything broken or severely on fire that needs immediate attention?
18:02:50 * dolphm readies a fire extenguisher
18:02:59 * dolphm and a crowbar
18:03:37 <heckj> I like the sound of that silence
18:04:13 <heckj> #topic keystoneclient - version, releasin', etc
18:04:36 <ayoung> All quiet on the Western front
18:04:36 <heckj> So we've *just* landed the auth_token bits into keystoneclient with henrynash' work
18:04:51 <heckj> The current released version of keystoneclient is 0.1.3
18:05:17 <heckj> We also dropped in the AccessInfo base pieces, to start allowing authorization to be cached, etc.
18:05:29 <heckj> It's time for a new release there, and a new number
18:05:41 <dolphm> 0.1.3 is ~3 months old!
18:05:44 <heckj> Any qualms with 0.2.0? I'm open to suggestions here
18:05:56 <gyee> keyring after that?
18:06:02 <dolphm> heckj: +1
18:06:20 <ayoung> sounds good
18:06:26 <heckj> gyee: sure - or if we can wrap it up in the next day or so, we can get it in with
18:06:45 <ayoung> keysring  in 2 would be a good feature
18:06:46 <gyee> k
18:06:54 <dolphm> cool
18:06:59 <heckj> ayoung: agreed, and it's close
18:07:05 <henrynash> oops. sorry, was sitting openstack-dev
18:07:29 <heckj> I'll plan on cutting a release of the keystoneclient end of this week (Thursday evening, Fri morning) with whatever we have in there now
18:07:32 <ayoung> henrynash,  we were just suggesting upping the version number in client,  due to your recent work landing there.  we are going to get the keysringh stuff in as well and go 2.0
18:07:45 <ayoung> henrynash, do you have any changes outstanding to get into client before 2.0?
18:07:45 <heckj> (also note that keystoneclient has initial V3 api support in there too)
18:07:54 <henrynash> yes, sounds like a good idea
18:08:10 <dolphm> heckj: keystoneclient vs openstack-manuals -- when can a new version be documented there?
18:08:11 <henrynash> no, client, I think, is done…..
18:08:19 * gyee is going to pull an all nighter on keyring after we agree on the interface
18:08:38 <ayoung> henrynash, did you get all of the cms changes that , for example ,vishy posted late last week?
18:08:44 <henrynash> (side question: just checking we don't need to move ec2, swift middleware to client?)
18:08:55 <henrynash> ayoung: yes
18:08:58 <annegentle_> dolphm: we have a stable/folsom branch cut for openstack-manuals now
18:08:58 <heckj> dolphm: good question - I believe after we release it, we should help get those docs updated
18:09:09 <dolphm> heckj: already documented in openstack manuals master: --os-token / --os-endpoint; pending docs: keyring / auth_token / bootstrap
18:09:30 <heckj> dolphm: then yeah - just after release
18:09:47 <heckj> ayoung: what's the state of the signing code? When are you planning on getting that into common or keystoneclient?
18:10:25 <heckj> (or did all that we need  come in with henrynash's changes?)
18:10:49 <ayoung> heckj, good question.  I haven't started on that yet.  the cms piece should be there, but nothing uses it
18:11:17 <ayoung> I've been in SQL land
18:11:24 <heckj> ayoung: Ok - so maybe a point release after 0.2.0 or something to add in that functionality, assuming it won't break any existing methods
18:11:27 <henrynash_> (sorry, lost connection for sec)
18:11:55 <heckj> #topic V3 Keystone API
18:11:58 <ayoung> heckj, should not break anything.  It will just be additional functionality as far as I can see for now
18:12:05 <heckj> ayoung: cool
18:12:19 <heckj> V3 API pieces are still landing policies is pending review
18:12:39 <heckj> dolphm: saw a note about skipped tests in there that I think can be removed and those tests run on the last review
18:12:42 <dwchadwick> what is the planned date for v3 api release
18:12:42 <ayoung> heckj, BTW, we are going to start deprecating KVS, to start with not including it in the policy
18:13:15 <ayoung> We can always get KVS like behavior using the SQL backends and SQLite in-memory
18:13:23 <dolphm> heckj: on your question regarding test_policy_crud in test_keystoneclient ... that was actually written against the client-side policy implementation when policies was implemented on v2... so i'm thinking create a whole new test_keystoneclient_v3 suite that runs against keystoneclient.v3?
18:13:30 <gyee> when can I start on the stop-token-in-uris bp?
18:13:51 <heckj> dwchadwick: initial "tech preview" as soon as we can get all the changes merged in
18:14:20 <heckj> dolphm: setting up the new tests sounds good
18:14:31 <dolphm> heckj: so remove for now, setup new test suite asap?
18:15:04 <heckj> dolphm: sounds good. Need help putting this into place? (can it be parallelized at all?)
18:15:28 <dolphm> gyee: are you happy with the identity api v3 spec for auth? (everything on /v3/tokens)
18:16:09 <dolphm> heckj: gyee's help implementing /tokens stuff would be a pre-req for a true v3 test suite
18:16:15 <gyee> dolphm, we would like to make more changes, like service/endpoint scoping
18:16:23 <dolphm> gyee: propose asap?
18:16:27 <heckj> dolphm: based on the emails recently, I think we might need to tweak up tokens to allow user-scoped (called "unscoped" previously) tokens as well as tenant-scoped
18:16:28 <gyee> but I am not sure about the timing
18:16:51 <dolphm> heckj: #todo catch up on mailing list :)
18:16:56 <heckj> gyee: your additional scope restriction to endpoints would be great to land in there at the same time
18:17:22 <gyee> we have a bp on service/endpoint scoping and service role delegation
18:17:31 <gyee> not sure if everyone have a chance to read up on it yet
18:17:35 <ayoung> gyee, yep. its on the agenda
18:17:37 <ayoung> https://blueprints.launchpad.net/keystone/+spec/service-isolation-and-roles-delegation
18:17:43 <heckj> heh - nice segway
18:17:49 <dolphm> heckj: i might be able to get rolling on a test framework in the mean time, although i doubt it'll be able to test much without auth
18:17:52 <gyee> I am sure david have more stuff to add :)
18:18:00 <heckj> gyee: any chance you can help dolph with some of the token implemenation bits?
18:18:14 <gyee> heckj, absolutely
18:18:18 <gyee> love to help
18:18:18 <dwchadwick> I think we need to agree on the design as we are now doing via email before finalising the implementation
18:18:26 <dolphm> gyee: thanks
18:18:51 <dolphm> dwchadwick: +1, and agree on hard spec changes as well
18:19:05 <dwchadwick> I would like to agree the concepts first
18:19:18 <gyee> yeah, lets create an etherpad on the bp
18:19:18 <dwchadwick> then proceed to the api and coding
18:19:25 <heckj> gyee: +1
18:19:58 <dwchadwick> Sorry but can you explain etherpad and bp to a newbie
18:19:59 <heckj> gyee: set one up now? I'll link into meeting notes
18:20:11 <gyee> gimme a min
18:20:23 <heckj> dwchadwick: etherpad is a collaborative text editor - see "http://etherpad.openstack.org"
18:20:28 <dolphm> dwchadwick: agree, although it's worth pointing out that if the implementation is do & easy to read, the openstack community will generally provide feedback much more readily
18:20:32 <dwchadwick> ok thanks
18:20:36 <heckj> dwchadwick: great for writing together, sharing notes, highly, highly editable
18:20:38 <dolphm> implementation is easy to do & easy to read*
18:20:46 <heckj> dwchadwick: bp is shorthand for a blueprint in launchpad
18:21:09 <heckj> much less editable, kind of a pain in the butt, but what we have as a mechanism to talk about about prioritize feature work
18:21:33 <gyee> https://etherpad.openstack.org/service-endpoint-isolation-role-delegation
18:21:34 <heckj> dolphm: 100% agree - makes a HUGE difference
18:21:44 <heckj> #link https://etherpad.openstack.org/service-endpoint-isolation-role-delegation
18:21:50 <dwchadwick> so we work on a document in etherpad then publish the agreed one as bp
18:22:53 <dwchadwick> I have quite a lot of comments to make on the current delegation bp that was published today
18:23:17 <gyee> dwchadwick, let have all your comments in the etherpad
18:23:41 <heckj> dwchadwick: you can just leave the etherpad up as a blueprint link, it's handy - but the place we'll need to publish the final spec is in the github repo identity-api - the spec is documented there and effectively published
18:23:53 <heckj> let's definitely start out on the etherpad though
18:24:01 <dolphm> general etherpad advice to EVERYONE: mark your comments/feedback in etherpad with your name! e.g. (dolph): my comment
18:24:14 <dwchadwick> I have just opened up the link but the current bp is not there. its more or less a blank page
18:24:41 <heckj> dwchadwick: refresh or re-open https://etherpad.openstack.org/service-endpoint-isolation-role-delegation
18:24:48 <heckj> I just put in some text, you should see it
18:24:57 <dwchadwick> I expected to see the current bp in etherpad so that it could be edited or commented on
18:25:10 <heckj> I see 7 collaborators connected right now there
18:25:32 <heckj> Nobody has added it yet :-) If you ahve the link handy, put it in there at the top
18:25:59 <heckj> blueprint https://blueprints.launchpad.net/keystone/+spec/service-isolation-and-roles-delegation pasted in there - see it?
18:26:02 <heckj> dwchadwick: ^^
18:26:24 <heckj> guessing so - the whole content of the blueprint just appeared! :-)
18:26:31 <gyee> nice
18:26:40 <heckj> Okay - let's head to that topic
18:26:45 <marek_> Without pictures
18:26:51 <heckj> #topic: https://blueprints.launchpad.net/keystone/+spec/service-isolation-and-roles-delegation
18:26:54 <heckj> marek_: ?
18:27:06 <heckj> gyee - take it away!
18:27:18 <gyee> hey everybody, marek_'s the author of the bp
18:27:22 <ayoung> so, the problem with the name service isolation is that we really want endpoint isolation
18:27:31 <ayoung> service is the Kerberos name for endpoint
18:27:54 <ayoung> so we have effectively chose the *best* name to rain confusion down upon our own users head
18:27:55 <ayoung> s
18:28:16 <gyee> we need to be able to scope it down to services and endpoints so that your token can not be reuse/abuse if the intended service happened to be compromised
18:29:04 <ayoung> gyee, does it really make sense to limit it to services?  Or is that required for when you don't know what service will be ultimately used?
18:29:11 <dwchadwick> If a token is targeted then it cannot be reused anywhere else (unless the accepting party does not care)
18:29:18 <ayoung> er..what endpoint will be ultimately used
18:29:47 <gyee> any endpoint
18:30:10 <dwchadwick> On Ethterpad one of my comments isIt is always a bad idea to give a capability token to anyone you do not trust.
18:30:10 <gyee> if your token is scoped to an endpoint, it cannot be used anywhere other than that endpoint
18:30:13 <ayoung> gyee, I am almost prone to say that tokens should be scoped to endpoints
18:30:23 <ayoung> gyee, yep
18:30:28 <dwchadwick> agreed
18:30:43 <gyee> but service should be an option as well
18:30:52 <dwchadwick> and confidentiality is separate to targeting
18:31:05 <gyee> right
18:31:16 <gyee> using PKI, we can issue a cert for that endpoint
18:31:17 <dwchadwick> So encryption is not the solution to targeting
18:31:19 <ayoung> gyee, why service?  Are there cases where we know that it can be scoped to a service, but don'
18:31:21 <ayoung> t
18:31:27 <gyee> and encrypt the token for that endpoint only
18:31:32 <ayoung> know what endpoint it will ultimately be used on?
18:31:41 <dwchadwick> No because you can still have surreptitious forwarding
18:32:16 <gyee> forwarding?
18:32:17 <heckj> ayoung: for service targeting - if your endpoints are all round-robin to a single service, it would be relevant
18:32:18 <ayoung> If an endpoint is compromised, we want to make sure no tokens from there can be reused
18:32:23 <ayoung> heckj, OK
18:32:32 <gyee> heckj, exactly
18:32:48 <marek_> A service might have a few endpoints in different zones  and you would like to have a single token that can be used for all its endpoints
18:33:00 <ayoung> heckj, that seems to call for some abstraction between service and endpoint,  or, probably more correctly, a token scoped to a set of endpoints
18:33:08 <dwchadwick> if the signed token is not targeted but only encrypted for the service, then the service can decrypt it and re-encrypt it for another service
18:33:13 <heckj> we've got a little blind spot in the service/endpoint setup - unclear relations between endpoints and how they're used by implementations, means the solution gets more complicated to cover the generalized cases
18:33:58 <marek_> It can be scoped to a service or one with higher granularity to one or more endpoints of this service
18:34:00 <ayoung> I think I would prefer to state "tokens can be scoped to one or more endpoints"  unless we are forced to go "service wide"
18:34:05 <dwchadwick> this is why we need a clear conceptual specification first :-)
18:34:41 <dwchadwick> Why not have the targeting at service level plus optional endpoints
18:34:42 <gyee> a service is one or more endpoints right?
18:35:05 <dwchadwick> if there are no endpoints specified it means all endpoints of this service
18:35:06 <ayoung> gyee, more correct to say a service is a powertype of an endpoint
18:35:11 <heckj> gyee: I think more appropriately a service has one or more endpoints, but technically a servcice can have no endpoints according to the current spec
18:35:12 <gyee> dwchadwick, yes, we need the flexibility for both services and endpoints
18:35:20 <heckj> ayoung: WTF is a powertype?
18:35:30 <ayoung> heckj, I'll find a link
18:35:31 <dolphm> ... powertype?
18:35:32 <dwchadwick> black and decker?
18:35:38 <dolphm> dwchadwick: +1
18:35:43 <heckj> I see chainsaws coming next...
18:35:45 <gyee> nice
18:35:47 <ayoung> http://en.wikipedia.org/wiki/Powertype_%28UML%29
18:35:48 <marek_> That is proposed in BP, service scoping with option to scope to endpoint
18:36:15 <ayoung> heckj, its like a baseclass, but the term is better used in the cases of databases and things like this
18:36:27 <heckj> #link this is a powertype: http://en.wikipedia.org/wiki/Powertype_%28UML%29
18:36:50 <dwchadwick> So its a superclass?
18:36:51 <gyee> WTF's UML? :)
18:37:00 <heckj> gyee: +1 :-)
18:37:20 <ayoung> Its an organization for Mixed Martial Arts, I think
18:37:24 <dwchadwick> So you can scope a token to a service type, and the type of service forms a class hierarchy
18:37:47 <gyee> not service type, just service
18:37:56 <dolphm> by service id?
18:37:58 <dwchadwick> eg. I scope a token for banking service and it can be used at BoA, Citibank, Barclays etc
18:38:00 <heckj> dwchadwick: except nothing is really inherited here, so that metaphor breaks down a bit
18:38:05 <ayoung> right
18:38:06 <marek_> We need the ability to scope to a service instance not a type
18:38:34 <dwchadwick> How many endpoints does a service instance have?
18:38:42 <ayoung> marek_, the phrase "a service instance not a type" does not compute
18:38:49 <marek_> 0...*
18:39:19 <dolphm> marek_: 0? not 1-3?
18:39:47 <dwchadwick> These are fine details that should be in the conceptual document
18:39:48 <gyee> let just call it service
18:39:52 <gyee> plain and simple
18:40:07 <ayoung> again, I'm not convince that  "all endpoints of a service" is a safe abstraction for tokens
18:40:20 <ayoung> I would much rather say "this set of endpoints"
18:40:25 <marek_> A service has a t least 1 endpoint. But there is no upper limit.
18:40:47 <dwchadwick> a service (type) has many service instances
18:40:54 <dolphm> marek_: okay, yeah (i think the current client will choke on an additional set of endpoints, but that's not an API issue)
18:40:56 <dwchadwick> a service instance has one or many endpoint
18:41:20 <marek_> correct
18:41:44 <dwchadwick> So we could agree to scope a token to a service type, service instance or set of endpoints
18:41:52 <heckj> ayoung: I'm good with asserting sets of endpoints - makes it very explicit
18:41:57 <dwchadwick> That is the full range of flexibility
18:42:12 <marek_> I do not see a benefit of scoping to service type
18:42:13 <heckj> ayoung: trick will be asserting that and coordinating that with the endpoint itself, which currently doesn't know or much care about it's endpoint ID
18:42:27 <dwchadwick> However, regardless of the scoping of the token, it has to be sent to an actual endpoint
18:43:09 <ayoung> heckj, that will need to be solved anyway
18:43:10 <dwchadwick> So each endpoint can send the token to Keystone and it can validate whether the token is valid at that endpoint or not
18:43:19 <marek_> The user may choose to scope to a service level or narrow down to a particular endpoint of this service
18:43:25 <heckj> ayoung: yep, just calling it out as an issue to be solved
18:43:25 <ayoung> dwchadwick, that is my understanding as well
18:43:36 <dwchadwick> Hence each endpoint must know its lineage (service type, service instance)
18:43:49 <ayoung> dwchadwick, just service
18:44:09 <heckj> dwchadwick: once the endpoint is correlated with it's relevant endpoint ID, lineage is explorable
18:44:11 <ayoung> there is no "service type" or , "service instance" abstraction in our dictionary
18:44:27 <gyee> just service
18:44:55 <dwchadwick> there must be the concept of service type and instance since you can have multiple copies of one service running in the cloud
18:45:03 <marek_> There is no need for adding service type, unless you want to add common  roles per service  type
18:45:37 <dwchadwick> And you have already said that a service instance can have one or many endpoints
18:46:23 <dwchadwick> Presumably there will be a service factory that can spawn instances of the service on demand
18:46:49 <heckj> dwchadwick: I think the translation that's reasonable close: service_type ==> what we're calling 'service', service_instance => what we're calling 'endpoint'
18:46:54 <dwchadwick> the scope of roles is another issue to be discussed
18:47:05 <marek_> We already  have service types like Nova, Swift. Do you mean  another type classification?
18:47:06 <ayoung> dwchadwick, "instances of the service" are endpoints
18:47:31 <dwchadwick> heckj -> I dont think so since a service can have multiple endpoints
18:47:58 <heckj> dwchadwick: you're assuming more and deeper structure in your definitions than we have in reality
18:48:08 <dwchadwick> Maybe
18:48:21 <dwchadwick> But say a service has an admin endpoint and a user endpoint
18:48:27 <heckj> they aren't today classes and instances, they're a composition of REST objects with attributes on them that we can manipulate
18:48:57 <heckj> there's no factory, only API's to create services or create endpoints at the moment
18:49:06 <dwchadwick> Are these different services in your world view? Because ultimately they should be the same object
18:49:56 <ayoung> dwchadwick, they are the same endpoint.
18:49:59 <heckj> dwchadwick: today, and with the current API, they're treated as 3 separate objects - a service and two endpoints with a relation between them from the endpoint pointing to the service to which they're related
18:50:16 <heckj> ayoung: more correct
18:50:18 <ayoung> heckj, do we put admin and public as 2 endpoints in keystone?
18:50:45 <heckj> ayoung: no, we shimmed in some attributes on the endpoint so we could differentiate "public", "internal", and "admin"
18:50:46 <gyee> ayoung, we have the 'facing' attr
18:51:04 <dolphm> an endpoint is a pointer to an instance of a service, two endpoints may point to the same instance, a service is useless without at least one endpoint because you can't use it :P
18:51:46 <dwchadwick> agreed that zero endpoints makes no sense. But what about multiple endpoints
18:52:00 <marek_> Well, you can still use the service with hidden/private/disabled endpoints to assigne roles and status of service
18:52:25 <dwchadwick> like an admin endpoint for the service
18:53:08 <dwchadwick> Sorry guys but I have to go now. I really enjoyed my first meeting with you via IRC
18:53:22 <dwchadwick> I can continue on the Etherpad later tonight or tomorrow
18:53:32 <heckj> dwchadwick: thanks for joining us
18:53:38 <heckj> Kristy: thanks for being here as well
18:53:49 <marek_> You can define a Nova service in Keystone and use it as target for roles grants. Then later on you add /enable/ or just publish  or more endpoints  of this service
18:54:08 <heckj> FYI: We've seven more minutes
18:54:21 <Kristy> Thanks :)
18:54:40 <heckj> gyee: what's your schedule today? I've got another meeting right after this that just smacked me
18:54:43 <henrynash> are we ready for aob?
18:54:48 <heckj> aob?
18:54:56 <henrynash> any Other Business
18:55:03 <heckj> #topic open discussion
18:55:09 <gyee> heckj, how about I ping you later in the afternoon?
18:55:22 <heckj> gyee: sounds good - I'll be offline for a while, but back in within a few hours
18:55:24 <dolphm> marek_: when you say enable the endpoint -- are you referring to the v3 definition of enable/disabling endpoints?
18:55:32 <gyee> I just need to know what are we going to do with the authenticate() interface for keyrig stuff
18:55:34 <henrynash> so wanted to let you know that I will complete the bp for groups of suers tonight
18:55:43 <henrynash> https://blueprints.launchpad.net/keystone/+spec/user-groups
18:55:55 <heckj> henrynash: sounds good - looking forward to readin git
18:56:02 <gyee> henrynash, I plan on commenting on your bp later today as well
18:56:03 <henrynash> will hook up the api design doc for it later tonight
18:56:08 <ayoung> gyee, continue the "authenticate()" discussion in #openstack-dev after the meeting.
18:56:14 <marek_> dolphm: yes
18:56:27 <gyee> ayoung, sure
18:56:39 <heckj> ayoung: wo'nt work for me- I need to run to other meetings, but will be back in a few hours
18:56:46 <henrynash> I also plan to complete the bp for private name spaces this week: https://blueprints.launchpad.net/keystone/+spec/domain-name-spaces
18:57:21 <ayoung> heckj, that is OK,  we'll have a solution for you by the time you are done
18:57:28 <heckj> ayoung: yeah, good luck with that
18:57:43 <gyee> :)
18:59:53 <heckj> Wrapping up for now
18:59:56 <heckj> #endmeeting