18:02:12 #startmeeting 18:02:14 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:18 Howdy all! 18:02:32 o/ 18:02:45 Sorry for missing the last meeting - thank you Dolph for coordinating it! 18:03:46 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 #topic New Issues? 18:04:31 Any production issues? 18:05:33 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 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 heckj, sounds good... If you want, you can assign it to me, and I will take a stab at it... 18:07:21 liemmn: thanks, will do 18:07:32 gracias 18:08:17 #action heckj to create blueprint to track doc updates on how to deploy - policy.json, suggested role names, etc 18:08:28 o/ 18:08:40 anything else in new topics? 18:09:24 termie: you around? 18:09:47 heading to V3 API feedback & questions 18:09:52 #topic V3 API feedback 18:10:01 #link https://docs.google.com/document/d/1s9C4EMxIZ55kZr62CKEC9ip7He_Q4_g1KRfSk9hY-Sg/edit# 18:10:50 Is there going to be a draft#2, or is that it? 18:11:14 I sent an email out sunday with open questions and general notes from the feedback. 18:11:19 yeah the date wasn't updated either :P 18:11:31 ahh... gotcha ;) 18:11:38 liemmn: I aimed at creating another draft, but focused on small questions this past weekend from the coffee shop 18:12:02 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 gyee: you around? 18:12:18 o/ 18:13:02 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 I am connecting from a coffee shop this time too :) 18:13:14 MFA 18:13:38 like half-token 18:13:42 heckj: i think a token just needs to be able to say "I exist, but I'm not valid, yet" 18:13:48 status = 'incomplete' or something 18:15:09 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 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 yes, hopefully the auth modules will update token status accordingly 18:16:26 could we accomplish this with status codes? (http 206 partial content) 18:16:40 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 right now, its going to be 'enabled' or 'incomplete' 18:17:25 (i think 206 is totally wrong, btw) 18:18:22 case-insensitive :) 18:19:07 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 heckj: not sure what you're asking for? a use case for /versions? 18:20:54 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 i am here now, ping pong game was won 18:21:24 yeah!!! 18:22:40 termie, dolphm_, et al - I'm intentionally flattening the endpoints (or suggesting it). Bad idea? 18:22:43 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 it related to some of termie's comments about mapping policy to endpoints as well... 18:23:26 dolphm_: yeah - that's driven by the VersionController in keystone today 18:23:47 heckj: and you're proposing to move it to /v3/versions? 18:24:06 lulz 18:24:08 (if so, that seems to defeat the point?) 18:24:17 nobody uses it to begin with 18:24:26 termie: that's because we only have 1 version in openstack 18:24:36 nope, it is because people only write code that talks to one version 18:24:40 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 rmeove 18:25:08 or run two instances of keystone! :) 18:25:16 gyee: not a solution 18:25:25 gyee: but i like the joke 18:26:07 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 ideally you wouldn't have to specify versions in the catalog, it'd just be http://identity:5000/ 18:27:27 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 no chance that any developer would ever write code to discover versions and do compat 18:28:03 I do if I am writing a 3rd client 18:28:04 dolphm: +1 18:28:08 gyee: no you don't 18:28:21 gyee: a website gives you an endpoint for the version you want to use 18:28:32 gyee: not an api 18:28:34 termie: certainly not if the server doesn't provide the necessary info to write an intelligent client 18:28:43 dolphm_: there are no intelligent clients 18:29:09 termie: i'm not saying there are 18:30:13 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 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 liemmn: pipe dream 18:31:12 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 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 leave it in the api but don't implement it? 18:32:12 heckj: i think the service as a first class citizen allows us to do things that reference services 18:32:25 termie: what's the value of referencing a service without an endpoint? 18:32:32 heckj: as in,right now we create users for a service and make them an admin for operations under that service 18:33:09 s/user for a service/the service itself (actual service not in keystone) uses a user to do its operations 18:33:40 termie: so you'd prefer to stay with service and endpoint as separate REST resources? 18:33:51 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 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 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 heckj: but i think the concepts are now ingrained in the system 18:34:54 termie: gotcha. In the next draft I'll revert back to separate service+endpoint. 18:35:15 dolphm_: what about what part of the public api / catalog ? 18:35:24 you mean how they are represented in teh catalog? 18:35:28 termie: I'll also link suggest a link on policy to service instead of endpoint 18:35:29 termie: right 18:35:34 termie: what do you want the catalog to look like 18:36:16 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 dolphm_: off hand i think it was service -> region -> endpoint or something of that nature 18:36:46 i don't think flattening helps us too much 18:37:05 i am being dragged away from the computer at this point 18:37:09 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 damn 18:37:21 region -> service_type -> {adminUrl, internalUrl, name, publicUrl} 18:37:25 I'll follow up with termie in email 18:37:33 (and on mailing list) 18:37:50 heckj: see get_catalog() in keystone.catalog.core 18:37:55 #action heckj follow up on service catalog and CRUD API for service and endpoints 18:38:45 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 no preference from me 18:39:12 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 user access key auth? 18:39:19 not me 18:39:23 I think optional 18:39:45 allows for other credential type that do not need to be scoped to tenant 18:39:54 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 liemmn: So for the impl of EC2 creds, throw a failure when creating when not linking to a tenant? 18:40:35 we can infer with the default tenant id thingy from the user, if a tenant is not specified. 18:40:50 wait, didn't someone suggested user passwords management using credential APIs 18:41:36 gyee: o/ 18:41:42 liemmn: we're definitely heading towards a "default tenant" concept on the user based on the feedback I've been seeing. 18:41:59 dolphm_ so in that case, cred is linked to user not tenant right? 18:42:10 gyee: for that case, yes 18:42:22 gyee: creds have always been linked to use - the question is do we also link them explicitly to tenant. 18:42:41 heckj, i c 18:42:48 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 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 that's a use case for something that wouldn't be linked to tenant, but would be for user 18:44:59 make sense 18:45:55 Ok - I'll go with optional in the next draft. 18:45:55 heckj: a tenant reference IS required for ec2 credentials, correct? 18:46:12 I'm aiming to make a new draft (#2) this weekend and get it published. 18:46:15 dolphm_: yes 18:46:26 #topic open discussion 18:47:08 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 i like it 18:47:24 etherpad? 18:47:28 +1 18:47:40 -1 for etherpad in this case :( 18:47:47 +1 (for googledocs) 18:47:48 gyee: I specifically didn't want etherpad because it was too easy for everything to change the content we're discussing 18:47:58 i like the limited control over the doc, and discussion notifications 18:48:17 I love etherpad for immediate collaboration, but Q&A over time has (to be) been immensely painful 18:48:20 and etherpad might complement google docs fairly well 18:48:29 or wiki 18:48:54 hard to follow google doc sometime, I had to go back to emails 18:48:59 especially if there are so many comments 18:49:04 but no big deal 18:49:14 gyee: I found the same, which is why I got aggressive about resolving some of the comments. 18:49:15 i do think we need to resolve comments more frequently 18:49:39 +1 18:49:52 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 heckj: speaking of which, i think i just accidentally resolved a discussion lol 18:50:13 heh 18:50:42 time check: 10 minutes left - any other topics? 18:50:50 is the keystone RBAC impl be similar to Nova 18:51:22 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 gotcha 18:51:42 gyee: right now there's a binary "is_admin" check getting used. Needs to get updated 18:51:43 CRUD on /policy vs /actions ... we're leaning on /policy blobs, correct? 18:51:58 I was mocking with that code for the domain stuff 18:52:04 had to fix a few bugs 18:52:20 for example, is_admin:1 doesn't work 18:52:26 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 backend is returning is_admin:True 18:53:15 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 heckj: i still don't have a solution/understanding for matching the current feature set of rules 18:53:25 (or put it in keystone and then use in nova, glance, etc) 18:53:32 heckj, agreed 18:54:07 dolphm_, it would be nice if RBAC and do object matching 18:54:09 dolphm_: I'm being dense, didn't grok your last sentence. What don't you have a solution for? 18:54:18 like serialize the object, then string comparison 18:54:52 dolphm_: nm, just got it 18:57:07 anything else? 18:57:21 gyee: not sure if i follow your last two comments 18:57:31 #action heckj to publish draft2 of V3 API this weekend 18:57:37 is_admin:1 != is_admin:True 18:57:38 YAY 18:57:48 if we serialize it and compare apple to apple 18:58:02 if ... then what? 18:58:16 then is_admin:1 == is_admin:True 18:58:41 what's is_admin? 18:58:51 a string 18:59:00 in RBAC 18:59:24 what kind of string 18:59:27 a role name? 18:59:33 admin? 18:59:43 keystone middleware sets it I think 18:59:48 when it sees that ADMIN token 18:59:52 we don't have rbac today 19:00:08 oh that's in the wsgi env? 19:00:08 I know, I was mocking with that code 19:00:23 I'm wrappin' this up - continue until Monty kicks you :-) 19:00:30 heckj: /salute 19:00:31 I think so 19:00:34 #endmeeting