18:01:37 <heckj> #startmeeting keystone
18:01:38 <openstack> Meeting started Tue Feb 19 18:01:37 2013 UTC.  The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:40 <dolphm> o/
18:01:42 <openstack> The meeting name has been set to 'keystone'
18:01:52 <heckj> agenda at #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Agenda_for_next_meeting
18:01:58 <heckj> If you haven't noticed, we have a whole new WIki
18:02:04 <heckj> (going to take some getting used to)
18:02:12 <spzala> Hi all!
18:02:20 <topol> hi
18:02:47 <dolphm> awesome
18:02:49 <heckj> I know we're all crankin' busy with code reviews and hacking and the like, so I'll keep this as quick as I can
18:03:05 <heckj> #topic high priority issues/bugs/etc
18:03:30 <gyee> heckj, /auth/tokens vs /auth
18:03:34 <heckj> We've got some security CVE's getting announced to the public today - in general, I think we're looking pretty good there, but there's also the new EC2 issue that gyee spotted
18:03:41 <heckj> gyee: will add to list
18:04:04 <heckj> dolphm: you've been cranking on resolving that bug - anything pending/outstanding? help needed?
18:05:15 <dolphm> this is the nasty part https://review.openstack.org/#/c/22327/
18:05:44 <dolphm> in short, our tests don't always create the default domain ID, so they won't pass if we enable domain validation ... so i'm trying to resolve that
18:06:06 <heckj> word
18:06:25 <heckj> dolphm: can any of us help, or just keep an eye to help review https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Agenda_for_next_meeting?
18:06:28 <heckj> damnit
18:06:36 <heckj> review: https://review.openstack.org/#/c/22327/
18:06:39 <heckj> #link https://review.openstack.org/#/c/22327/
18:06:41 <dolphm> if anyone else has any test infrastructure updates in review to make that happen, i'd appreciate them being pointed out to me :)
18:06:51 <dolphm> would love to steal them and get them merged :P
18:07:41 <heckj> Ok - so let's move on and run through the feature freeze updates
18:07:46 <heckj> ayoung: around?
18:08:10 <heckj> let's start with gyee's "/auth/tokens vs /auth"
18:08:17 <heckj> gyee: what's the summary?
18:08:55 <dolphm> #link https://review.openstack.org/#/c/21943/
18:09:31 <dolphm> ayoung wants to change /v3/auth to /v3/auth/tokens in order to support, for example, an x509 authentication response
18:09:32 <gyee> ayoung wants /auth/tokens for HATEOAS support
18:10:10 <gyee> I am fine with that, just want to make sure we are doing the right thing
18:10:12 <dolphm> i'm not confident that changing the resource is the best approach for supporting that
18:10:39 <dolphm> if you're providing the same request in either case, and you want a different response back, you would normally provide a different Accept header
18:11:32 <heckj> dolphm: that's definitely the more formal way of doing with REST, but we haven't been very strict on that point up until now.
18:11:49 <dolphm> i'm a little lost on how this is different from the UUID -> PKI change
18:12:15 <dolphm> if it's even feasible to replace tokens within openstack with something else
18:12:34 <heckj> from my perspective, the UUID -> PKI change didn't change anything except config on the server, leaving the resource with the exact same content types if I recall
18:12:42 <dolphm> and lastly, if it would be expected for the client to make the determination of what they get back, rather than the server's implementation
18:12:48 <dolphm> heckj: correct
18:13:00 <dolphm> heckj: i'm not clear from ayoung on what exactly x509 would be replacing
18:13:11 <dolphm> heckj: or if it's something that's in addition to tokens
18:13:13 <gyee> yeah, supporting multiple token format at the same time sound dangerous
18:13:41 <gyee> ayoung around?
18:13:45 <heckj> I think it's perfectly reasonable if it's clear what we're intending, but it's obviously not at this point.
18:14:14 <dolphm> bottom line is that i'm not clear on the end goal or how the API is currently incompatible with that end goal, so i'm not comfortable in approving API-level changes to accommodate the unknown
18:14:19 <heckj> he was earlier - dunno - maybe grabbing lunch of something
18:14:43 <dolphm> i keep saying ayoung hoping he'll get a ping :)
18:14:49 <heckj> yeah :-)
18:15:05 <heckj> Okay - we clearly need ayoung's input here to help describe, so we'll shelve this for the moment
18:15:06 <gyee> /auth/tokens is standing in between a -1 and +2 from ayoung right now :)
18:15:38 <dolphm> regardless of all this discussion, i don't think gyee's feature-add should be blocked on the issue
18:15:43 <dwchadwick> dolphm: if you are not clear on the end goal, then perhaps it would help to write up what the model for tokens currently is, and what it should be in the future
18:15:55 <gyee> dolphm, agreed
18:16:05 <dolphm> if we want to change the API, and we consider it to be long-term broken at a fundamental level, we can change it and make a follow up patch after feature freeze
18:16:08 <heckj> agreed as well
18:16:28 <dwchadwick> this issue is not an API issue at heart. It is a conceptual model issue
18:16:32 <heckj> gyee: does this solve your issue?
18:17:11 <gyee> heckj, yeah, now I just need some +1s or 2s :)
18:17:15 <heckj> kk
18:17:20 <heckj> Henry - let's switch to you
18:17:26 <henrynash> ok
18:17:31 <heckj> henrynash: what's the word on policy engine and namespaces
18:17:31 <dolphm> gyee: just noticed you pushed another patch, will review asap
18:17:38 <topol> gyee, you are close to a +1 from me. did you see my comments
18:18:02 <gyee> topol, yes, I addressed them in configuration.rst and the handler interface
18:18:09 <dolphm> henrynash's test failure on https://review.openstack.org/#/c/22109/ is apparently reproducible -- is it legit?
18:18:14 <gyee> made it clear how the plugins are being invoked
18:18:17 <topol> gyee, OK, cool. I will re-review
18:18:35 <henrynash> so both are either approved or just need the final button pressed…but both are failing with random failures in jenkings/gate
18:18:55 <henrynash> the same code passed yesterday...
18:19:01 <YorikSar> dolphm: It's some PyPI fail.
18:19:06 <heckj> submit a recheck on those - saw a comment in #infra earlier this morning that said the testing was infra and fixed/working now
18:19:07 <henrynash> yep
18:19:16 <YorikSar> I had my change request failed as well.
18:19:42 <henrynash> heckj: did that earlier, and email from ci folks said not to do that anymore while they reolve
18:19:53 <heckj> ah - oops :-)
18:20:03 <heckj> I guess we'll just wait for the word then
18:20:17 <heckj> still, sounds like it's all headed in the right direction there. Any issues?
18:20:20 <henrynash> heckj: indeed, although annoying timing (as it alwayys is)
18:20:55 <henrynash> only thing I haven't done was on the query filters…dolph you were saying you would rather it be two consecutive decorators...
18:21:27 <henrynash> ….which I had trouble making work….I fixed up all the other suhhestions (including pushing the filtering into the wrap_collection)
18:21:31 <heckj> separate protect and fileter?
18:21:36 <dolphm> heckj: yes
18:21:48 <dolphm> henrynash: i wouldn't block on that
18:22:02 <dolphm> henrynash: i think it'd be semantically clearer and easier to maintain
18:22:32 <dolphm> henrynash: it'd be nice if they shared code at the very least, as someone pointed out
18:22:52 <henrynash> dolphm: well i split out all the common code into a submodule they both call
18:23:03 <dolphm> henrynash: cool
18:23:53 <henrynash> only other one of me is whether Guang, you need me to layer some domain token issuing on top of your v3 auth change?
18:24:15 <henrynash> i had kinda assumed that it would come out in the wash!
18:24:29 <henrynash> but if I need to do something, let me know and I'm on it
18:25:01 <gyee> henrynash, yeah, I left that part to you
18:25:35 <henrynash> gyee: ok, no problem….I saw where you planned it to be
18:25:39 <dolphm> henrynash: your tests pass offline, correct?
18:25:51 <gyee> henrynash, thanks
18:26:03 <henrynash> dolphm: yes…and passed online last night
18:26:14 <dolphm> henrynash: if we approve, ci team appears to be following up and ensuring things merge
18:26:23 <dolphm> jeblair specifically (thanks!)
18:27:18 <heckj> Okay - next topic then
18:27:24 <YorikSar> Can I propose another change request to be merged before feature freeze? https://review.openstack.org/20928 has been reviewed, had to be rebased and cleaned and now looks like ready.
18:27:40 <heckj> Was just going to ask if there was any other reviews that wanted/needed attention
18:28:19 <YorikSar> I felt it
18:28:26 <heckj> heh
18:28:28 <dolphm> that one should be easy to get in
18:29:00 <heckj> I'd think so too - the nasty remaining item seems to be the trusts work, and ayound is hiding from us
18:29:20 <YorikSar> We had some discussion with Brant here and even he gave me +1
18:29:22 <heckj> request to review #link https://review.openstack.org/#/c/20928 please
18:29:23 <dolphm> hopefully he's grinding through API changes :)
18:30:00 <heckj> Okay - I'll be updating the blueprints page on various pieces in a few, and we've got the release meeting.
18:30:22 <heckj> Right now, I'm planning on requesting the we hold the cut for keystone until these biggies are all merged in.
18:30:58 <heckj> trusts is the only one that I see at significant risk right now
18:31:17 <dwchadwick> trusts is intertwined with tokens.
18:31:24 <gyee> heckj, they need to get in by today or 21st?
18:31:29 <dolphm> gyee: today
18:31:34 <gyee> sheet!
18:31:49 <heckj> yeah, ttx had requested today - I'll be requesting an extension at the release meeting
18:31:58 <dolphm> gyee: jenkins issues are causing a delay
18:32:37 <heckj> heh - they always do...
18:33:35 <heckj> #topic open discussion
18:34:26 <topol> heckj, for us new folks can you explain the ramifications of the feature freeze date?
18:34:39 <topol> how rigid??
18:34:56 <dolphm> topol: quite rigid -- nothing but bug fixes and docs can merge to master for the next few weeks
18:35:23 <heckj> topol: we basically have bug fixes, integration tests to run, and docs to tweak up between here and the grizzly RC
18:35:47 <topol> so the ldap group stuff for example. Is that considered stuff we will fix via bugs or is it deferred to havana?
18:36:03 <YorikSar> topol reads my mind
18:36:08 <heckj> if you want to add a new capability somewhere, we've generally done that in a feature branch or side branch, which we'll accept for general merging after we cut the branches and open for development for Havanna
18:36:51 <heckj> topol: Given that's not new functionality from the API/external perspective, I think you can easily fill that in, but be ready to make dual patches - merge to master and then backport to RC candidates
18:36:52 <dolphm> topol: if implementation isn't going to land before feature freeze, implement it ASAP and we'll work it out case by case? anything that smells like a feature must be incredibly well justified as being necessary
18:38:40 <heckj> looks like that one may be a jump ball :-)
18:39:13 * heckj is going to be distracted for a few… bbiab
18:40:00 <topol> Well,  https://review.openstack.org/#/c/21327/13  is muddying the waters for me.  Its not clear to me what we want the backend LDAP structure to look like
18:40:28 <dolphm> topol: how does that impact things?
18:40:46 <topol> Need ayoung here :-)
18:40:53 <dolphm> lol k
18:40:53 <YorikSar> topol: tenant_id was something strange in LDAP from the beginning.
18:41:07 <ayoung> sorry, I am here
18:41:11 <ayoung> was busy coding
18:41:13 <dolphm> yay
18:41:19 <topol> Yay ayoung
18:41:26 <YorikSar> I don't see how this change does something to LDAP structure.
18:41:27 <dolphm> also yay for code
18:41:39 <dolphm> brb
18:41:53 * ayoung reads up
18:42:18 <YorikSar> The only change is that we can let projects be something simpler than groupOfNames now.
18:42:32 <ayoung> ugh
18:42:33 <topol> ayoung,  its not clear to me what the ldap structure should look like. given our conversation last night it appeared stuff was changin
18:42:37 <ayoung> OK,  so X509....
18:42:41 <ayoung> tokens suck
18:42:46 <ayoung> to use an industry term
18:42:55 <ayoung> and what I want to do, but am not ready to propose
18:43:00 <ayoung> is to replace tokens with X509
18:43:31 <ayoung> they can have a private key in them that can be used to both secure the connection and ensure the id of the user....you ll know this...
18:43:43 <gyee> yay on PKI :)
18:43:44 <ayoung> so, if we do X509, or some other format
18:43:50 <dwchadwick> ayoung. you mean public key
18:43:58 <ayoung> say openID, oauth, saml ,cameleoparduck whatever
18:44:04 <ayoung> dwchadwick, don't start
18:44:12 <ayoung> yes, I mean publich key
18:44:26 <ayoung> the short of it
18:44:39 <ayoung> is that they may all come in as content tyep HTML or whatever
18:44:51 <ayoung> but we need to distinguish based on the objet itself
18:45:05 <ayoung> so auth was supposed to be a container, with token just the first impl
18:45:17 <ayoung> kapish?
18:45:45 <ayoung> dwchadwick, and, btw, I love your input, just not when I have code freeze in a couple hours. :)
18:45:53 <gyee> ayoung, dolphm was arguing why can't we do Content: application/x509 or something
18:46:13 <ayoung> gyee, because openid and oath will both probably come in as http
18:46:33 <ayoung> and because we don't want to mix tokens with X509s
18:46:36 <dolphm> "what I want to do is to replace tokens with X509" completely totally abandon X-Auth-Token, X-Subject-Token, etc?
18:46:38 <ayoung> in revocation lists
18:46:52 <dwchadwick> ayoung: we have already  catered for this in our design. We now support various incoming token formats
18:46:59 <ayoung> dolphm, yes
18:47:13 <dolphm> ayoung: +2 for /auth/tokens then -- that's the clarification i was looking for
18:47:15 <ayoung> dwchadwick, and I think this is where your design would slot int
18:47:22 <ayoung> whew
18:47:32 <ayoung> ok,  so on to ldap....
18:47:47 <ayoung> LDAP sucks
18:48:02 <ayoung> I think I am going to start all my speeches that way
18:48:06 <topol> ayoung, but not going anywhere
18:48:07 <YorikSar> Not that much  :)
18:48:09 <ayoung> heh
18:48:22 <ayoung> ok,  proeject don't have members anymore
18:48:40 <ayoung> projects are really just a container for resources and those containers are controlled outside of keystone
18:48:49 <ayoung> all we do is privide roles for users in containers
18:48:58 <ayoung> users belong to groups and user belong to domain, but not projects
18:49:04 <dolphm> ayoung: all that depends on the use case :(
18:49:13 <ayoung> so groupOfName no longer is required
18:49:27 <YorikSar> We can change it to organizationalUnit
18:49:33 <dolphm> ayoung: e.g. some deployments want keystone to handle domains, projects and roles but not users
18:49:36 <ayoung> YorikSar, yeah, probably makes sense
18:49:51 <ayoung> dolphm, right, but we still need a user record locally
18:50:02 <ayoung> dolphm, for the full ldap use case
18:50:04 <ayoung> we need
18:50:06 <YorikSar> And purge all code that deals with members
18:50:15 <ayoung> to be able to specify how to populat the local users
18:50:16 <topol> ayoung, so I have no idea what the ldap structure should look like and I need to verify it wont blow chunks like it does now
18:50:30 <ayoung> for example, not all users in the corporate LDAP are going to have access to keystone at all
18:51:21 <YorikSar> We can isolate them by some subtree, attribute or just take all users from some collection.
18:51:22 <ayoung> YorikSar, organizationalUnit  for the project, and then roles done as organizationalROles as they are now is probably the right fit.  Might be worth running past the AD smart people though
18:51:58 <topol> ayoung, a sample ldap structure would help me
18:52:10 <dwchadwick> Ayoung: you dont alter the LDAP structure to give people permissions, but rather you give them appropriate attributes
18:52:15 <YorikSar> I don't think that AD cares about this.
18:52:29 <dwchadwick> The LDAP structure should be irrelevant
18:52:47 <dwchadwick> And anyway if you want to use corporate LDAPs, they will all have different structures
18:53:01 <gyee> dwchadwick, agreed
18:53:08 <ayoung> dwchadwick, so there are two competing things here, one of which is the default schema that we support, and which I am trying to make as inclusive as possible,  the second is what do we do to adapt to other peoples LDAP schems.
18:53:24 <topol> ayoung, +1
18:53:25 <ayoung> so topol is dealing with the first issue first
18:53:32 <ayoung> how to represent projects
18:53:39 <ayoung> we were doing it as group of names
18:53:46 <ayoung> but I think that is problematic
18:53:47 <dwchadwick> I suggest you use attribute mappings for this
18:53:59 <YorikSar> btw, groupOfNames was broken for AD iirc
18:54:06 <ayoung> dwchadwick, not between now and code freeze, but YES YES YES for Havana
18:54:11 <ayoung> I'd argue it is priority
18:54:17 <ayoung> YorikSar, yes it was
18:54:20 <YorikSar> Because AD does not allow subentries for groupOfNames.
18:54:25 <ayoung> you can't put roles under them
18:54:26 <YorikSar> ou will work even better.
18:54:41 <gyee> AD is not LDAP :)
18:54:54 <YorikSar> LDAP is a protocol and AD supprots it ;)
18:54:55 <dwchadwick> gyee: +10000
18:55:11 <ayoung> YorikSar, and LDAP embraces and extends it
18:55:19 <topol> groupOfNames is giving me fits even with openldap
18:55:19 <ayoung> dolphm, you back yet?
18:55:24 <ayoung> OK,  so on trusts
18:55:36 <ayoung> one issue I just hit
18:55:42 <ayoung> deleting a trust using DELETE.
18:55:58 <YorikSar> tpool: Huh? We ran tempest with OpenLDAP and it was fine.
18:56:07 <dolphm> yes, i'm following along
18:56:13 <ayoung> I was origianlly going to mark these fields as invisible in the DB, but now I m being asked to list enabled and disabld trusts
18:56:18 <dolphm> < 4 minutes
18:56:33 <ayoung> I want trusts to be immutable so i would rather not support PATCH
18:56:37 <dolphm> ayoung: what do you mean invisible?
18:56:44 <ayoung> so do I make a delete be a real delete,
18:56:58 <ayoung> dolphm, actually, like tokes
18:57:01 <dwchadwick> I would say yes
18:57:02 <dolphm> ayoung: that's fine, but you originally proposed enabled and disabled listing?
18:57:03 <ayoung> enables means returns in list
18:57:09 <dwchadwick> You dont want zombie trusts hanging around
18:57:14 <ayoung> and disabled means  they don't show up
18:57:21 <dwchadwick> You do want audit trails, but this is a different issue
18:57:44 <ayoung> dwchadwick, so, on the audit trail thing, I was thinking that people need a way to query the disabled trusts
18:57:51 <dolphm> ayoung: so you're looking for a soft delete behavior?
18:57:56 <ayoung> and administrators need to be able to purge disabled trusts
18:58:01 <ayoung> dolphm, yeah
18:58:05 <dwchadwick> you can have the concept of suspend and resume
18:58:17 <dwchadwick> revoke though is a different issue
18:58:38 <topol> YorikSar, what I meant is GroupOfNames requires some attributes that werent coming in and matching the ProjectAPI attributes
18:59:11 <dolphm> ayoung: side note, definitely add a comment on immutability and lack of PATCH support to your API Conventions section
18:59:16 <dolphm> err API Resources
18:59:28 <dolphm> exceptions need to be explicitly noted
18:59:36 <YorikSar> topol: Does they require something besides at least one member? It was solved long ago with dumb_member.
18:59:43 <ayoung> dolphm, I'va added immutabilty.  I WIll explicily referene PATCH
19:00:05 <dwchadwick> You could use Patch for suspend and resume trusts
19:00:23 <dwchadwick> even for extending the lifetime of a trust
19:00:33 <ayoung> dolphm, so, for now, is DELETE -> disabled ok?
19:00:36 <topol> YorikSar, devstack was not sending in a description.  But it sounds like you can point me in the right direction
19:00:45 <heckj> gotta wrap this
19:00:50 <topol> member was an issue as well
19:00:55 <heckj> #endmeeting