18:02:12 <heckj> #startmeeting
18:02:14 <openstack> Meeting started Tue Jun 12 18:02:13 2012 UTC.  The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:18 <heckj> Howdy all!
18:02:32 <liemmn> o/
18:02:45 <heckj> Sorry for missing the last meeting - thank you Dolph for coordinating it!
18:03:46 <heckj> I've got some specific pieces to go over for the API review, but first I figured I'd hit any hot topics
18:03:53 <heckj> #topic New Issues?
18:04:31 <heckj> Any production issues?
18:05:33 <liemmn> Not really new issue; but, I asked on the list if we can include an RBAC example for how to isolate users that are created in one domain from being modifiable by a domain admin in another domain... I think it is doable.
18:06:09 <heckj> liemmn: agreed. I think I'm going to create a blueprint to do some of this, because we're not tracking it otherwise
18:06:47 <liemmn> heckj, sounds good...  If you want, you can assign it to me, and I will take a stab at it...
18:07:21 <heckj> liemmn: thanks, will do
18:07:32 <liemmn> gracias
18:08:17 <heckj> #action heckj to create blueprint to track doc updates on how to deploy - policy.json, suggested role names, etc
18:08:28 <dolphm_> o/
18:08:40 <heckj> anything else in new topics?
18:09:24 <heckj> termie: you around?
18:09:47 <heckj> heading to V3 API feedback & questions
18:09:52 <heckj> #topic V3 API feedback
18:10:01 <heckj> #link https://docs.google.com/document/d/1s9C4EMxIZ55kZr62CKEC9ip7He_Q4_g1KRfSk9hY-Sg/edit#
18:10:50 <liemmn> Is there going to be a draft#2, or is that it?
18:11:14 <heckj> I sent an email out sunday with open questions and general notes from the feedback.
18:11:19 <dolphm_> yeah the date wasn't updated either :P
18:11:31 <liemmn> ahh... gotcha ;)
18:11:38 <heckj> liemmn: I aimed at creating another draft, but focused on small questions this past weekend from the coffee shop
18:12:02 <heckj> I have a list of questions I thought I'd bring up here - most related to Andy's feedback, but some others as well.
18:12:12 <heckj> gyee: you around?
18:12:18 <gyee> o/
18:13:02 <heckj> gyee: you asked about adding a status field into the token attributes - could you illuminate a bit more what's going on there? I made a suggestion in feedback, but I'm not clear on what multifactor auth needs
18:13:02 <gyee> I am connecting from a coffee shop this time too :)
18:13:14 <gyee> MFA
18:13:38 <gyee> like half-token
18:13:42 <dolphm_> heckj: i think a token just needs to be able to say "I exist, but I'm not valid, yet"
18:13:48 <gyee> status = 'incomplete' or something
18:15:09 <heckj> gyee: I got that bit. I guess here's the question - right now a token is expected to be fully there if it's there
18:15:46 <heckj> so if we add a partial field, do we want to specify some specific values there so we can update auth_token to know how to validate a partial token correctly?
18:16:10 <gyee> yes, hopefully the auth modules will update token status accordingly
18:16:26 <dolphm_> could we accomplish this with status codes? (http 206 partial content)
18:16:40 <heckj> gyee: since you know a touch more about multifactor, could you suggest possible values there? (and lets limit in in the spec)
18:17:11 <gyee> right now, its going to be 'enabled' or 'incomplete'
18:17:25 <dolphm_> (i think 206 is totally wrong, btw)
18:18:22 <gyee> case-insensitive :)
18:19:07 <heckj> dolphm_: switching topics - the /versions thing. I'm afraid I never quite groked the original setup, so I wasn't clear on how to assert what capabilities the backends provide. How can we do that reasonably with the /versions API setup?
18:19:46 <dolphm_> heckj: not sure what you're asking for? a use case for /versions?
18:20:54 <heckj> dolphm_: sorry - what more definition should we add to a V3 draft 2 to be explicit about backends? resource attributes, etc? I don't have a sense of what gets returned when you do a GET /versions now...
18:21:04 <termie> i am here now, ping pong game was won
18:21:24 <heckj> yeah!!!
18:22:40 <heckj> termie, dolphm_, et al - I'm intentionally flattening the endpoints (or suggesting it). Bad idea?
18:22:43 <dolphm_> well, i actually don't know what /versions is ... i assume you mean / (the multiple choice response, containing links to available api versions) or /v#/extensions ?
18:23:02 <heckj> it related to some of termie's comments about mapping policy to endpoints as well...
18:23:26 <heckj> dolphm_: yeah - that's driven by the VersionController in keystone today
18:23:47 <dolphm_> heckj: and you're proposing to move it to /v3/versions?
18:24:06 <termie> lulz
18:24:08 <dolphm_> (if so, that seems to defeat the point?)
18:24:17 <termie> nobody uses it to begin with
18:24:26 <dolphm_> termie: that's because we only have 1 version in openstack
18:24:36 <termie> nope, it is because people only write code that talks to one version
18:24:40 <heckj> dolphm_: I don't know what to do with / that whole version, extension thing - I never understood it, so I'm looking for what we *should* do with it in V3 API
18:24:52 <termie> rmeove
18:25:08 <gyee> or run two instances of keystone! :)
18:25:16 <termie> gyee: not a solution
18:25:25 <termie> gyee: but i like the joke
18:26:07 <termie> the point is, if you are using v1 api or whatever, you give htem the endpoint that starts with /v1 and they do what they expect to be in v1
18:27:01 <dolphm_> ideally you wouldn't have to specify versions in the catalog, it'd just be http://identity:5000/
18:27:27 <dolphm_> and the client would take that, discover what versions are supported by the endpoint, compromise on compatiblity/stability, and talk to that api endpoint
18:27:46 <termie> no chance that any developer would ever write code to discover versions and do compat
18:28:03 <gyee> I do if I am writing a 3rd client
18:28:04 <liemmn> dolphm: +1
18:28:08 <termie> gyee: no you don't
18:28:21 <termie> gyee: a website gives  you an endpoint for the version you want to use
18:28:32 <termie> gyee: not an api
18:28:34 <dolphm_> termie: certainly not if the server doesn't provide the necessary info to write an intelligent client
18:28:43 <termie> dolphm_: there are no intelligent clients
18:29:09 <dolphm_> termie: i'm not saying there are
18:30:13 <liemmn> There are no intelligent clients out there because in general, APIs suck....  but, with better adoption of concepts like HATEOAS, it will make it easier to write one.
18:30:14 <termie> dolphm_: i'm saying there never will be because it isn't worth the effort, y'all act as if the rest of the world is somehow better at this than we are, they aren't they are just as lazy
18:30:27 <termie> liemmn: pipe dream
18:31:12 <heckj> Okay - I think we're at a dead end on that point. Won't hurt to add, but there's little confidence (from Andy) that it would ever be actually useful.
18:31:15 <heckj> termie - switching back to feedback on service & endpoints: what do you think about modeling endpoints as a single layer instead of modelling service and endpoint separately and linking them?
18:31:35 <dolphm_> leave it in the api but don't implement it?
18:32:12 <termie> heckj: i think the service as a first class citizen allows us to do things that reference services
18:32:25 <dolphm_> termie: what's the value of referencing a service without an endpoint?
18:32:32 <termie> heckj: as in,right now we create users for a service and make them an admin for operations under that service
18:33:09 <termie> s/user for a service/the service itself (actual service not in keystone) uses a user to do its operations
18:33:40 <heckj> termie: so you'd prefer to stay with service and endpoint as separate REST resources?
18:33:51 <termie> so if we want to allow that user to have control only over things for a service, it is helpful to keep it as a first-class citizen
18:34:05 <dolphm_> termie: so you want to preserve services + endpoints on the management api, which i think we're all fine with ... what about the public api (catalog)?
18:34:17 <termie> heckj: yes, i'm not happy with how they are exactly used right now (it wasn't previously clear their connection with generating the catalog)
18:34:50 <termie> heckj: but i think the concepts are now ingrained in the system
18:34:54 <heckj> termie: gotcha. In the next draft I'll revert back to separate service+endpoint.
18:35:15 <termie> dolphm_: what about what part of the public api / catalog ?
18:35:24 <termie> you mean how they are represented in teh catalog?
18:35:28 <heckj> termie: I'll also link suggest a link on policy to service instead of endpoint
18:35:29 <dolphm_> termie: right
18:35:34 <dolphm_> termie: what do you want the catalog to look like
18:36:16 <termie> dolphm_: i already wrote the catalog how i wanted it to look and then wrote a translation to the format defined tby the api
18:36:39 <termie> dolphm_: off hand i think it was service -> region -> endpoint or something of that nature
18:36:46 <termie> i don't think flattening helps us too much
18:37:05 <termie> i am being dragged away from the computer at this point
18:37:09 <heckj> termie: do you want to change the V3 API to present it in your prefered format? I don't recall what you wanted there, but happy to
18:37:11 <heckj> damn
18:37:21 <dolphm_> region -> service_type -> {adminUrl, internalUrl, name, publicUrl}
18:37:25 <heckj> I'll follow up with termie in email
18:37:33 <heckj> (and on mailing list)
18:37:50 <dolphm_> heckj: see get_catalog() in keystone.catalog.core
18:37:55 <heckj> #action heckj follow up on service catalog and CRUD API for service and endpoints
18:38:45 <heckj> liemmn, dolphm_: for credentials - should those be linked to tenant, or is there a use case to have them be specific to just a user?
18:38:59 <dolphm_> no preference from me
18:39:12 <heckj> I was thinking of EC2 credentials, which I thought was linked to tenant - but I think one of you two brough up that it should be optional.
18:39:15 <gyee> user access key auth?
18:39:19 <dolphm_> not me
18:39:23 <liemmn> I think optional
18:39:45 <liemmn> allows for other credential type that do not need to be scoped to tenant
18:39:54 <heckj> I could see that for general credentials, but wasn't sure how to deal with the EC2 case (create EC2 creds) if the tenant wasn't provided. Today EC2 creds infer a tenant automatically
18:40:25 <heckj> liemmn: So for the impl of EC2 creds, throw a failure when creating when not linking to a tenant?
18:40:35 <liemmn> we can infer with the default tenant id thingy from the user, if a tenant is not specified.
18:40:50 <gyee> wait, didn't someone suggested user passwords management using credential APIs
18:41:36 <dolphm_> gyee: o/
18:41:42 <heckj> liemmn: we're definitely heading towards a "default tenant" concept on the user based on the feedback I've been seeing.
18:41:59 <gyee> dolphm_ so in that case, cred is linked to user not tenant right?
18:42:10 <dolphm_> gyee: for that case, yes
18:42:22 <heckj> gyee: creds have always been linked to use - the question is do we also link them explicitly to tenant.
18:42:41 <gyee> heckj, i c
18:42:48 <heckj> I'm wanting to be as explicit about links as possible through the APIs to avoid some of the pain we hit with the earlier v1 and v2 api impls.
18:43:51 <heckj> theoretically, we could have the keystone service also store/serve SSH keys for use in images when they're created as well (i.e. look towards moving keypairs into keystone from currently in nova)
18:44:04 <heckj> that's a use case for something that wouldn't be linked to tenant, but would be for user
18:44:59 <gyee> make sense
18:45:55 <heckj> Ok - I'll go with optional in the next draft.
18:45:55 <dolphm_> heckj: a tenant reference IS required for ec2 credentials, correct?
18:46:12 <heckj> I'm aiming to make a new draft (#2) this weekend and get it published.
18:46:15 <heckj> dolphm_: yes
18:46:26 <heckj> #topic open discussion
18:47:08 <heckj> What do you all think about the feedback mechanism (google docs) for the API? I think it's been reasonably good - not sure of anything better out there, but would love to have alternate suggestions for the future
18:47:19 <dolphm_> i like it
18:47:24 <gyee> etherpad?
18:47:28 <liemmn> +1
18:47:40 <dolphm_> -1 for etherpad in this case :(
18:47:47 <liemmn> +1 (for googledocs)
18:47:48 <heckj> gyee: I specifically didn't want etherpad because it was too easy for everything to change the content we're discussing
18:47:58 <dolphm_> i like the limited control over the doc, and discussion notifications
18:48:17 <heckj> I love etherpad for immediate collaboration, but Q&A over time has (to be) been immensely painful
18:48:20 <dolphm_> and etherpad might complement google docs fairly well
18:48:29 <dolphm_> or wiki
18:48:54 <gyee> hard to follow google doc sometime, I had to go back to emails
18:48:59 <gyee> especially if there are so many comments
18:49:04 <gyee> but no big deal
18:49:14 <heckj> gyee: I found the same, which is why I got aggressive about resolving some of the comments.
18:49:15 <dolphm_> i do think we need to resolve comments more frequently
18:49:39 <gyee> +1
18:49:52 <heckj> dolphm_: my bad on some of that - was very distracted last week and didn't get a chance to read much until this past weekend
18:49:53 <dolphm_> heckj: speaking of which, i think i just accidentally resolved a discussion lol
18:50:13 <heckj> heh
18:50:42 <heckj> time check: 10 minutes left - any other topics?
18:50:50 <gyee> is the keystone RBAC impl be similar to Nova
18:51:22 <heckj> gyee: yes, identical in fact. It's not that way now, but that would be my choice. Same policy engine code that it's nova, glance, (soon quantum), etc.
18:51:36 <gyee> gotcha
18:51:42 <heckj> gyee: right now there's a binary "is_admin" check getting used. Needs to get updated
18:51:43 <dolphm_> CRUD on /policy vs /actions ... we're leaning on /policy blobs, correct?
18:51:58 <gyee> I was mocking with that code for the domain stuff
18:52:04 <gyee> had to fix a few bugs
18:52:20 <gyee> for example, is_admin:1 doesn't work
18:52:26 <heckj> dolphm_: I'm not leaning on anything there as yet, I just don't have a good sense of what will make the most sense near and longer term. Looking for a way to make a reasonable decision.
18:52:30 <gyee> backend is returning is_admin:True
18:53:15 <heckj> gyee: the policy engine bits and decorators are in several places in nova & glance - though we might consolidate that into openstack-common and then use it in keystone as well.
18:53:21 <dolphm_> heckj: i still don't have a solution/understanding for matching the current feature set of rules
18:53:25 <heckj> (or put it in keystone and then use in nova, glance, etc)
18:53:32 <gyee> heckj, agreed
18:54:07 <gyee> dolphm_, it would be nice if RBAC and do object matching
18:54:09 <heckj> dolphm_: I'm being dense, didn't grok your last sentence. What don't you have a solution for?
18:54:18 <gyee> like serialize the object, then string comparison
18:54:52 <heckj> dolphm_: nm, just got it
18:57:07 <heckj> anything else?
18:57:21 <dolphm_> gyee: not sure if i follow your last two comments
18:57:31 <heckj> #action heckj to publish draft2 of V3 API this weekend
18:57:37 <gyee> is_admin:1 != is_admin:True
18:57:38 <dolphm_> YAY
18:57:48 <gyee> if we serialize it and compare apple to apple
18:58:02 <dolphm_> if ... then what?
18:58:16 <gyee> then is_admin:1 == is_admin:True
18:58:41 <dolphm_> what's is_admin?
18:58:51 <gyee> a string
18:59:00 <gyee> in RBAC
18:59:24 <dolphm_> what kind of string
18:59:27 <dolphm_> a role name?
18:59:33 <dolphm_> admin?
18:59:43 <gyee> keystone middleware sets it I think
18:59:48 <gyee> when it sees that ADMIN token
18:59:52 <dolphm_> we don't have rbac today
19:00:08 <dolphm_> oh that's in the wsgi env?
19:00:08 <gyee> I know, I was mocking with that code
19:00:23 <heckj> I'm wrappin' this up - continue until Monty kicks you :-)
19:00:30 <dolphm_> heckj: /salute
19:00:31 <gyee> I think so
19:00:34 <heckj> #endmeeting