18:01:51 <dolphm> #startmeeting keystone
18:01:51 <amakarov> hi
18:01:52 <openstack> Meeting started Tue Oct 21 18:01:51 2014 UTC and is due to finish in 60 minutes.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:56 <lhcheng> hello
18:01:57 <openstack> The meeting name has been set to 'keystone'
18:02:16 <dolphm> so, morganfainberg asked me to skip the blueprint review for the moment, which is at the top of the agenda
18:02:23 <dolphm> so i'm going to jump straight into nkinder's topic
18:02:25 <dolphm> #topic Additional LDAP Attribute Mappings
18:02:26 <rharwood> o/
18:02:26 <dolphm> nkinder: o/
18:02:50 <nonameentername> o/
18:03:02 <nkinder> So a recent simple patch to update some doc comments in the config file uncovered some things I wanted to discuss
18:03:33 <nkinder> We need to determine how the additional LDAP attribute mapping code should work
18:03:41 <nkinder> Let me grab some links...
18:04:03 <dolphm> nkinder: i was about to ask - the meeting agenda mentions "a change" in juno and icehouse, have a link to that specifically?
18:04:16 <nkinder> #link https://bugs.launchpad.net/keystone/+bug/1293698
18:04:17 <uvirtbot> Launchpad bug 1293698 in keystone/icehouse "Can't map user description using LDAP" [Wishlist,Fix released]
18:04:29 <topol> nkinder whata dditional attrribute maapings are we missing?
18:04:29 <nkinder> So that was a bug that was fixed in Juno and backported to stable/icehouse
18:04:45 <nkinder> Well, let's step back and talk about the purpose of the mappings
18:04:49 <ayoung> https://review.openstack.org/#/c/118590/
18:05:08 <nkinder> When creating an entry in LDAP, there are going to be certain required attributes based on the objectclass used
18:05:26 <nkinder> So a user might require cn, sn, and uid
18:06:01 <nkinder> The LDAP entry requirements might hve more attributes that Keystone's definition of a user does (id,name,mail,description,enabled)
18:06:04 <henrynash> nkinder: so this if for R/W LDAP?
18:06:06 <ayoung> nkinder, I'm wondering if this really should be LDAP specific.  I could see an argument that a SQL backend, not the one managed by Keystone, could be used for Authentication as well, like the mod_authn_mysql approach
18:06:12 <nkinder> henrynash: Yes, exactly
18:06:19 <ayoung> and in that case, it might have this same restriction
18:06:29 <nkinder> ayoung: don't cloud matters here (yet)
18:06:50 <ayoung> well, it does argue that both should be done via the same  mapping mechanism as we are using for Federation
18:07:07 <ayoung> andthat ties in with the LDAP rewrite that bknudson wants to do
18:07:10 <ayoung> right bknudson ?
18:07:13 <ayoung> Heh
18:07:18 <morganfainberg> This is an artifact of keeping r/o and rw leap the same driver. It sounds like.
18:07:27 <gyee> are the non-standard attributes got stashed into 'extra' when it returns?
18:07:30 <nkinder> so if Keystone needs to create a user in LDAP for the R/W case, we might need to supply some additional attributes to satisfy the objectclass requirements
18:07:35 <ayoung> morganfainberg, its a non issue for r/o
18:07:37 <bknudson> ayoung: it might be better to use middleware for r/o LDAP rather than what we're doing.
18:07:51 <gyee> so as long as we don't break the API spec we should be fine
18:07:51 <morganfainberg> Right. In. R/w config we could provide a schema
18:08:12 <bknudson> ayoung:  it is an issue for r/o ldap. The change that I made to fix the bug was only for reading... write wasn't involved.
18:08:24 <ayoung> bknudson, additional attribute mapping?
18:08:26 <topol> I thought r/w LDAP had serialization issues
18:08:31 <morganfainberg> And not be constrained by ldap schema requirements like this.
18:08:36 <bknudson> ayoung: yes, in https://review.openstack.org/#/c/81041/6/keystone/tests/test_backend_ldap.py
18:08:40 <nkinder> yes, bknudson is correct
18:08:45 <bknudson> https://review.openstack.org/#/c/81041/6/keystone/common/ldap/core.py
18:08:48 <nkinder> So, back to the main issue...
18:09:11 <bknudson> r/w ldap isn't all that interesting imo.
18:09:11 <nkinder> The additional mapping code was designed to only be used when adding a new entry to LDAP (for the objectclass requirements I mentioned)
18:09:23 <topol> bknudson+++
18:09:29 <bknudson> other than it makes our impl more complicated.
18:09:29 <ayoung> bknudson, that is not an "additional attribute"  but rather a core attribute
18:09:35 <ayoung> description is a required field
18:10:01 <nkinder> The fix that bknudson made causes us to pull in any other LDAP attribute and map it to on-the-fly additional attributes in the keystone user object
18:10:25 <dolphm> bknudson: ++
18:10:27 <nkinder> This leads towards things like adding "employeeNumber" to a keystone user object, which is returned by a user get
18:10:40 <nkinder> I really think that's the wrong direction
18:10:47 <gyee> return in where? 'extra'?
18:10:50 <ayoung> right, which is why the check was there in the first place
18:11:02 <dolphm> gyee: extra is not an API attribute
18:11:17 <nkinder> It starts to promote keystone as a general user/group management solutiuon (which it's not)
18:11:33 <gyee> dolphm, it we return employeeId in user ref, we would break the API spec isn't it?
18:11:34 <lbragstad> we're trying to move away from that
18:11:53 <dolphm> gyee: no, that would be backwards compatible, but also useless
18:12:05 <ayoung> ldap_attr, attr_map = item.split(':') was supposed to be a reverse mapping, from the LDAP attribute to the Keystone, if I recall correctly
18:12:05 <dolphm> nkinder: yeah, none of that stuff is necessary for openstack
18:12:08 <morganfainberg> nkinder: ++
18:12:13 <nkinder> So, I'd like to rip it out
18:12:25 <nkinder> The question is is we need tpo go through a deprecation cycle
18:13:01 <jamielennox> you want to rip out the entire concept of having 'extra' data for users? or just the LDAP bit/
18:13:05 <nkinder> bknudson and I had some discussion on this here - https://review.openstack.org/#/c/118590/18/keystone/tests/test_backend_ldap.py
18:13:15 <morganfainberg> nkinder, i think there is a better way - avoiding breaking people
18:13:18 <jsavak> other openstack services enable meta data (see http://docs.openstack.org/admin-guide-cloud/content/section_metadata-service.html) which contains stuff not exactly necessary for openstack but helps with integration & user experience
18:13:21 * morganfainberg is back to desk
18:13:25 <nkinder> jamielennox: I think we need to leave it in for the "create" case only
18:13:35 <nkinder> jamielennox: or come up with a suitable replacement
18:13:38 <morganfainberg> nkinder, i think this is where we look at splitting r/w ldap from r/o
18:13:40 <dolphm> nkinder: can you clarify what you want to rip out?
18:13:48 <dolphm> nkinder: a patch would be ideal :P
18:13:54 <morganfainberg> we can then really optimise the r/o ldap [most people don't use r/w]
18:14:02 <gyee> morganfainberg, ++
18:14:05 <dolphm> morganfainberg: +++
18:14:21 <henrynash> morganfainberq: + * shoesize
18:14:27 <gyee> heh
18:14:28 <morganfainberg> the r/w ldap can start looking like something we can migrate to a custom schema being provided as well
18:14:29 <ayoung> morganfainberg, the code that does this kind of logic is core to LDAP.  I really don't think splitting the driver will fundamentally help.
18:14:30 <bknudson> I guess the question is do we need a solution for Juno?
18:14:34 <dolphm> henrynash wins
18:14:38 <morganfainberg> which then *solve* the extra attr wierdness
18:14:40 <dolphm> (i did the math)
18:14:48 <bknudson> and I would assume that changing the functionality for juno isn't going to be possible
18:15:00 <morganfainberg> bknudson, thats the point of my recommendation
18:15:15 <henrynash> dolphm: you know that they say big shoes big…..
18:15:22 <henrynash> dolphm: feet
18:15:28 <bknudson> right, so I think morganfainberg and others are saying rather than a patch we want to rewrite ldap
18:15:30 <gyee> you really have to go there?
18:15:41 <morganfainberg> henrynash, exactly
18:15:42 <nkinder> dolphm: searching for the link...
18:15:58 <morganfainberg> bknudson, and that is because we are going to have a hard time "fixing" juno. so to speak
18:16:03 <ayoung> bknudson, what criteria are we going to use for the new design?
18:16:04 <henrynash> sl
18:16:06 <lbragstad> so we are still going to keep r/o ldaP, right?
18:16:12 <jamielennox_> we've hated the 'extra' stuff in the API for a while now though - is it time we can put it in aflag and kill it off?
18:16:19 <dolphm> lbragstad: yes
18:16:20 <nkinder> #link https://git.openstack.org/cgit/openstack/keystone/commit/?id=ebfdab034f2b35074f1645b70c1f07d0c4dfd337
18:16:21 <morganfainberg> ayoung, i was even open to looking at SSSD as a migration path.
18:16:29 <ayoung> we can't kill r/w LDAP, can we?
18:16:32 <morganfainberg> ayoung, among other options.
18:16:45 <dolphm> jamielennox_: we're pretty close to being able to do that with jsonschema validation
18:17:00 <ayoung> I'm assuming that even if Identity is read only WRT LDAP, assignment needs to be R/W
18:17:07 <dolphm> jamielennox_: a bunch of booleans get flipped and you raise 400's everwhere
18:17:10 <henrynash> so what’s the argument *against* creating two ldap backends….other than we’d want to try and make the common code shared
18:17:12 <lbragstad> jamielennox_: right now we allow additionalAttributes on requests.
18:17:13 <jamielennox_> dolphm: kind of, we're not changing the schema with jsonschema at all
18:17:19 <henrynash> (one r/o, one r/w)
18:17:25 <morganfainberg> we can't kill it, we can work to make most deployments better. and if we're able to convince the hold outs that there are better options (read: split Identity into it's own API that can manage LDAP w/ a schema and a migration path) down the line, we could make r/o ldap the *only* keystone deployment mode that we care about from assignmenty
18:17:27 <dolphm> lbragstad: additionalAttributes=False ftw
18:17:29 <ayoung> jsavak, you guys use LDAP for Identity in R/W or R/O mode?
18:17:32 <jamielennox_> dolphm: ++
18:17:36 <lbragstad> dolphm: yep
18:17:39 <jsavak> ayoung r/w
18:17:41 <jsavak> for now
18:18:04 <morganfainberg> dolphm, and i'd like that option *across* the board
18:18:07 <nkinder> dolphm: it's pretty much backing out the fixes for https://bugs.launchpad.net/keystone/+bug/1293698 (with the exception of introducing a new config setting to allow mapping of the description attr)
18:18:08 <uvirtbot> Launchpad bug 1293698 in keystone/icehouse "Can't map user description using LDAP" [Wishlist,Fix released]
18:18:10 <morganfainberg> don't want it in sql either.
18:18:11 <ayoung> jsavak, thanks
18:18:19 <dolphm> morganfainberg: yeah, i'd want one global control for that
18:18:30 <dolphm> strict_api = true # the new defaultness
18:18:31 <jamielennox_> yea, this doesn't work if it's backend specific
18:18:38 <ayoung> LDAP has a very nice replication story, which makes it the preferred multi-site Identity solution
18:18:50 <ayoung> Lets not do this
18:18:58 <bknudson> so what if we were to split out the identity provider into its own service?
18:19:00 <ayoung> leave LDAP as a single driver
18:19:14 <ayoung> lets fix what is broken with it
18:19:38 <bknudson> then the identity part can evolve in its own way (become a full user solution) and keystone can keep evolving with federation
18:19:48 <lbragstad> bknudson: I think gyee had a nice list at the summit on that process?
18:19:51 <morganfainberg> so, how likely is it someone is going to use the new functionality that bknudson 's patch provided?
18:20:03 <ayoung> bknudson, that is fine, again except for CERN and Assignments in LDAP
18:20:04 <morganfainberg> bknudson, i am thinking that is the long term goal
18:20:06 <topol> whatever we do please lets end up with a better user experience and not a worse user experience in the next release
18:20:13 <ayoung> But....
18:20:15 <gyee> ++ for identity separation
18:20:16 <bknudson> morganfainberg: one of our products requested the fix... not sure if they're using it or not.
18:20:23 <nkinder> morganfainberg: I think it's pretty unlikely since you can't use the keystone or openstack CLI to actually see those additional attributes
18:20:30 <morganfainberg> bknudson, then i think we can't *fix* this, we shipped it.
18:20:31 <ayoung> and that is, I think, a mess worth addressing in its own right
18:20:33 <jamielennox_> gyee: ++ you were keen on it in atlanta - did you ever get anywhere?
18:20:39 <nkinder> bknudson: I think they needed to map the description attribute though, right?
18:20:44 <nkinder> bknudson: that part is valid
18:20:47 <morganfainberg> nkinder, cli isn't that important on that front.
18:20:55 <bknudson> these products don't use the cli.
18:20:58 <dolphm> bknudson: the bug report is just for description
18:20:59 <gyee> jamielennox_, haven't found the time
18:21:06 <jamielennox_> gyee: thought so
18:21:08 <ayoung> the issue with LDAP assignment, though, is that it assumes it is in the same LDAP server as identity.  Can we change that without breaking it?  We don't have LDAP migrations
18:21:13 <nkinder> bknudson: The fact that we had no config setting to allow that led to an attempt to use the additional mappings to map the description attribute
18:21:14 <dolphm> bknudson: http api, then, i hope?
18:21:23 <bknudson> dolphm: yes, they use the REST API.
18:21:26 <morganfainberg> my concern is we shipped this capability. *waves hands* implicit contract *more hand waving*
18:21:49 <topol> user experience *waves hand*
18:21:54 <morganfainberg> topol, shhh :)
18:21:55 * jsavak waves back
18:22:01 <jamielennox_> topol: i'm not sure we ever shipped that
18:22:04 * gyee wave his fingers
18:22:13 <topol> breaking contract kills user experience
18:22:14 <ayoung> If we can make the LDAP assignment case work without breaking things, I think having Identity as a separate service  from Assignment would work fine
18:22:14 <nkinder> gyee: how many fingers....?
18:22:18 <gyee> ha
18:22:35 <morganfainberg> ayoung, i think we can avoid breaking that. it's a *very* special case.
18:23:08 <ayoung> morganfainberg, and...I think we can actually do that.  So long as they both talk to the same LDAP, assignemtn should be fine with Identity in a separate service
18:23:12 <nkinder> bknudson: would you be able to find out if the driver for that fix was only the need to map the description attribute?
18:23:26 <morganfainberg> i think we need to know how many people actually use ldap assignment, if it's just cern... I am happy to say lets work with them to help them out [if there is anything we can do to make life better for them]
18:23:49 <ayoung> its little things like assuming the "pointers" to users is the users DN in the members attribute of the Role
18:23:50 <bknudson> nkinder: I'll find out and get back to you.
18:24:11 <nkinder> bknudson: thanks
18:24:29 <ayoung> morganfainberg, lets assume it is CERN plus one other site that we won't ever hear from unless we break it
18:25:00 <ayoung> but we'd hear from CERN first anyway
18:25:13 <dolphm> marekd: you're up ^
18:25:24 <bknudson> move it into stackforge.
18:25:33 <morganfainberg> bknudson, that was kindof the next thought i had.
18:25:39 <bknudson> I don't think it's even tested by tempest
18:25:40 <marekd> dolphm: yep, but for ldap matters  you'd better hit jose.
18:25:43 <morganfainberg> but we need to make our internal API a stable contract then.
18:26:02 <morganfainberg> i think we should be moving that direction
18:26:05 <dolphm> marekd: doesn't look like he's on now, right?
18:26:07 <morganfainberg> but it is an added concern
18:26:14 <ayoung> Ugh...LDAP works.  Why break it.  These are minute deatils.
18:26:18 <ayoung> details even
18:26:20 <marekd> dolphm: i doubt it.
18:26:22 <jamielennox_> morganfainberg: i don't think this is an internal API right? it'd be some sort of federated deal
18:26:30 <morganfainberg> jamielennox_, identity_api
18:26:32 <breton> hi. Sorry, I'm late.
18:26:34 <morganfainberg> jamielennox_, assignment_api
18:26:41 <ayoung> Cern would be OK with Identity in a separate service
18:26:52 <ayoung> they need LDAP due to scale and replication
18:26:57 <marekd> ayoung: through 'federation
18:27:00 <marekd> ' ?
18:27:09 <ayoung> marekd, yep
18:27:12 <marekd> ayoung: yes, that would rather be fine
18:27:16 <gyee> ayoung, separate identity service back by LDAP make a lot of sense
18:27:25 <morganfainberg> the other *big* win about moving identity to a separate service we can explicitly avoid PII data leakage into openstack
18:27:27 <ayoung> marekd, its rather the assignment side in LDAP that is the sticking point
18:27:35 <ayoung> and Rack using LDAP in R/W mode
18:27:50 <jsavak> morganfainberg +1
18:27:51 <dolphm> morganfainberg: =D
18:27:56 <morganfainberg> never ask for the data (which is a very very large win hooking up to a corp ldap or even in rax use case)
18:27:57 <ayoung> pretty sure CERN is using AD for LDAP, and not writing user data into it...due to the whole additional_attributes issue
18:28:11 <topol> morganfainberg great point!!!
18:28:40 <marekd> ayoung: afair we use ro ldap.
18:29:03 <morganfainberg> and then r/w for ldap assignment marekd ?
18:29:10 <amakarov> marekd, some still use rw
18:29:24 <ayoung> marekd, except for role assignments
18:30:16 <morganfainberg> nkinder, unfortunately, i realyl don't think we can back out bknudson's change [even parts of it]. i want to get back on topic
18:30:18 <marekd> morganfainberg: ayoung: i don't work on that so i'd better not talk too much as i may simply lie to you. I don't know detailed ocnfiguration
18:30:26 <ayoung> LDAP  follows the two laws of thermo-dynamics.  1. We can't win, the best we can do is break even. 2.  We can't break even.
18:30:38 <morganfainberg> nkinder, we shipped it, i am sure we're going to run into bad (very bad) UX issues if we do.
18:30:47 <nkinder> morganfainberg: do we want to deprecate it though?
18:30:49 <marekd> morganfainberg: ayoung: we had some constraints when openstack was deployed and some parts are non standard.
18:30:51 <morganfainberg> nkinder, because someone is going to use it in Juno "cause it's there"
18:31:10 <ayoung> maybe?
18:31:12 <bknudson> So what I'm not sure about is what is the bug that's being fixed now?
18:31:22 <dolphm> and juno will be supported for a long while
18:31:23 <ayoung> morganfainberg, I think we can limit the LDAP fetch to the attributes we know about
18:31:23 <morganfainberg> nkinder, i think we need to say "HEY DONT DO THIS" but i am very concerned about removing it. i think we should work on the overall UX and as we improve identity use cases it might fall to the wayside with better options
18:31:36 <ayoung> never fetch all attributes
18:31:44 <bknudson> Here's the bug: https://bugs.launchpad.net/keystone/+bug/1336769
18:31:47 <uvirtbot> Launchpad bug 1336769 in keystone "LDAP additional attribute mappings description do not specify that they are for creation only" [Low,In progress]
18:31:57 <morganfainberg> ayoung, thats fine. only fetch "known" attributes, that is a change i think we can get away with (classify it as a backport and get it in stable asap)
18:32:04 <nkinder> morganfainberg: ok, makes sense.  I just don't want to see it expanded to start covering update operations, CLI changes to show additional attrs, etc.
18:32:05 <morganfainberg> but we can't rip all of it out
18:32:28 <ayoung> that would be a change on get and list...
18:33:02 <bknudson> but we still support additional attributes in SQL?
18:33:13 <bknudson> why is sql / ldap special?
18:33:13 <morganfainberg> bknudson, i think we should put a toggle in to disable that.
18:33:36 <bknudson> clients don't know what the backend is so they don't know what will be accepted or rejected.
18:33:47 <lbragstad> toggle or deprecate and move towards not supporting additional attributes?
18:33:53 <morganfainberg> lbragstad, thats my thought
18:34:00 <nkinder> lbragstad++
18:34:01 <morganfainberg> lbragstad, or come up with a better story for it
18:34:15 * topol getting depressed. thought we had LDAP integration covered a few releaseas ago :-)
18:34:16 <bknudson> I'd rather we moved towards moving identity into its own service
18:34:21 <morganfainberg> as in.. identity split, look at shipping a schema that can support extra attrs
18:34:24 <morganfainberg> for ldap
18:34:27 <morganfainberg> sql can stay the same
18:34:30 <bknudson> then we can deprecate identity in keystone
18:34:36 <morganfainberg> r/o ldap .. hah no updates anyway who cares.
18:34:59 <henrynash> morganfainberg: so we will need to signal that strongly if we take that approach…I know of a number of products that rely on storing additional attributes with users, for instance
18:35:03 <jamielennox_> i think even in a new service we don't expose extra mappings - i don't think they are a benefit as no other service can rely on them anyway
18:35:09 <morganfainberg> bknudson, it should be easy to proxy keystone identity -> new service [i'd do it in middleware]
18:35:11 <morganfainberg> henrynash, yes.
18:35:39 <morganfainberg> jamielennox_, in new service if there is a *real* demand for it we can make it really work, not be a weird bolt-on
18:36:37 <morganfainberg> jamielennox_, the issue is we're trying to make 2 use cases work in a "standard" schema way in LDAP, if we're doing read-write ldap, we are in our rights to say "use our schema" which would solve that issue rather than needing to do custom weird mappings
18:36:38 <dstanek> when we say new service we are talking about another executable running on another port right?
18:36:45 <bknudson> dstanek: yes
18:36:47 <morganfainberg> dstanek, yes.
18:37:12 <morganfainberg> jamielennox_, making read-only ldap and r/w ldap work like they do has resulted in compromises on both sides.
18:37:14 <ayoung> http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/ldap/core.py#n1426
18:37:21 <ayoung> doesn't look like it takes an attribute list
18:37:22 <jamielennox_> morganfainberg: would be a discussion for if and when we get it split
18:37:45 <morganfainberg> jamielennox_, yes. it would be a "if we need this, we can really support it" vs. "oh this hack to make it work"
18:37:58 <jamielennox_> but i'd say lowest common denominator - and it's very low
18:37:59 <ayoung> but http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/ldap/core.py#n1438  sure enough, it does.
18:38:21 <morganfainberg> dstanek, and if you don't support read/write identity in theory you could avoid running it all together [something to explore]
18:38:30 <ayoung> nkinder, so,  how are we returning values other than those that are explicitly mapped?  I don't see it
18:38:39 <nkinder> ayoung: http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/ldap/core.py#n1459
18:38:53 <nkinder> ayoung: those are the additional mapped attributes
18:39:14 <dstanek> morganfainberg: i'd love to see a good write up on what the proposed split looks like - architecturally it just seems like it will complicate things
18:39:39 <nkinder> ayoung: do you mean in terms of shoving them into the user object on the keystone side?
18:39:40 <morganfainberg> dstanek, fair enough.
18:39:48 <bknudson> dstanek: the goal is to eventually simplify by using federation for all users.
18:39:51 <ayoung> nkinder, so they have to be explicitly added in order to be fetched, right?
18:39:53 <nkinder> ayoung: probably best to discuss more after the meeting
18:39:54 <morganfainberg> bknudson, ++
18:39:57 <ayoung> ++
18:40:17 <dolphm> (20 min left)
18:40:41 <ayoung> 1.2.1 Review of Keystone Blueprints for "Trivial" Status  ?
18:40:49 <dstanek> bknudson: that i like; i guess the split is fuzzy to me
18:40:52 <morganfainberg> ayoung, skip till next week.
18:40:56 <ayoung> Deal
18:41:00 <morganfainberg> ayoung, i'm still cleaning up the bp list
18:41:10 <dolphm> morganfainberg: schedule then?
18:41:13 <dstanek> bknudson: 2 ports -> 1 port and back to 2
18:41:28 <morganfainberg> dolphm, just a note: review the schedule, let me know if there are any issues with time/descriptions/etc
18:41:42 <dolphm> #topic Tentative Schedule on Sched.org for Kilo Design summit
18:41:43 <morganfainberg> or if we *want* to drop one of the sessions
18:41:45 <dolphm> #link http://kilodesignsummit.sched.org/type/keystone
18:41:51 <morganfainberg> please review it
18:41:58 <morganfainberg> let me know if anything is "wrong"
18:41:59 <bknudson> do other projects have their schedules?
18:42:01 <morganfainberg> we might get a session back
18:42:08 <morganfainberg> depending on the "ops summit" stuff
18:42:17 <dolphm> bknudson: http://kilodesignsummit.sched.org/
18:42:34 <morganfainberg> if we get a dedicated session back i'll swap our ops one over to ops summit and add the split identity (seems like a reasonable topic) in it's place?
18:42:43 <dolphm> lots of TBD slots
18:43:11 <ayoung> hard to say without http://kilodesignsummit.sched.org/type/horizon
18:43:26 <morganfainberg> ayoung, the horizon session right before our SSO one should be a cross-project session too
18:43:35 <morganfainberg> ayoung, already talked to david-lyle about that
18:43:39 <ayoung> I know of at least three things that will need Horizon buy in
18:43:57 <morganfainberg> and our SSO one will have horizon folks at it (it doesn't overlap with their sessions)
18:44:15 <ayoung> morganfainberg, jamielennox_ and I have been discussing the KC DOA integration, too
18:44:22 <marekd> morganfainberg: ++
18:44:34 <ayoung> Horizon right now is the limiting factor on a lot of the stuff we do
18:44:50 <morganfainberg> so in short, keep your eyes on the schedule, let me know if anything needs to be changed (i'm also looking)
18:44:55 <morganfainberg> it doesn't have to be during this irc meeting :)
18:45:00 <bknudson> we shouldn't have to design anything around horizon
18:45:04 <dolphm> hopefully by friday this schedule will be totally fleshed out, so everyone should check in later this week and look for conflicts (plan your days!)
18:45:10 <bknudson> just use the standard rest stuff and any client can use it
18:45:31 <bknudson> horizon isn't the only UI
18:45:35 <morganfainberg> bknudson, in an ideal world, but we should make sure our APIs make sense for horizon and/or provide them any support they need
18:45:42 <morganfainberg> other UIs will likely benefit
18:46:06 <topol> are stuff really needs to work with horizon. its embarassing when it doesnt
18:46:07 <lhcheng> morganfainberg ++
18:46:13 <bknudson> well, let's not assume everyone is using django
18:46:24 * topol *User experience*
18:46:24 <dolphm> bknudson: ++
18:46:26 <gyee> bkundson, API and UX, Horizon is just a side-effect :)
18:46:27 <morganfainberg> bknudson, DoA is only one mechanism.
18:46:51 <morganfainberg> this is more about "do our REST APIs work for this, if not, what needs to change"
18:46:55 <morganfainberg> not "how do we make DOA work"
18:47:09 <morganfainberg> that former topic can be in the horizon side of the session(s)
18:47:14 <morganfainberg> erm latter
18:47:29 <gyee> morganfainberg, speaking of which, ain't they just form a API working group or something?
18:47:40 <morganfainberg> gyee, yes. there is a thread on ML on the meeting(s)
18:48:20 <stevemar> gyee, meetings are thursdays at 0000 utc (likely) for api working group
18:48:20 <morganfainberg> #link http://lists.openstack.org/pipermail/openstack-dev/2014-October/048144.html
18:48:22 <morganfainberg> it's long
18:48:32 <gyee> I am guessing we'll have to throw in our fifty cents
18:48:36 <morganfainberg> yes
18:48:48 <bknudson> here comes v4.
18:48:49 <gyee> stevemar, thanks
18:48:56 <morganfainberg> bknudson, unlikely.
18:49:15 <morganfainberg> bknudson, microversioning [yes]
18:49:16 <gyee> ya think? :)
18:49:44 <lbragstad> stevemar: gyee in #openstack-meeting-3
18:49:50 <morganfainberg> but v3 has been enough hassle to get support, lets not do v4... ever* ... [ *= anytime soon ]
18:49:59 <bknudson> we keep changing the api but we don't ever update the version, even minor version.
18:50:06 <jamielennox_> i'm sceptical that microversioning will work, we've not successully actually removed any api calls
18:50:08 <bknudson> at least in a way that clients can get at
18:50:10 <gyee> lbragstad, thanks, on my cal now
18:50:22 <morganfainberg> bknudson, i think we need to solve that. but i don't think we can major version rev.
18:50:25 <morganfainberg> bknudson, tbh.
18:50:26 <bknudson> jamielennox_: they really don't seem to be thinking about the APIs.
18:50:30 <jamielennox_> bknudson: found that today - a whole bunch of my session stuff assumed that i could rely on the minor version
18:50:50 <jamielennox_> bknudson: what are they thinking then?
18:51:02 <lbragstad> gyee: #link https://wiki.openstack.org/wiki/API_Working_Group
18:51:04 <bknudson> jamielennox_: they're thinking about how to implement it in the server
18:51:05 <ayoung> accepts header with the micro version?
18:51:28 <jamielennox_> by a whole bunch i have a couple of calls that i know don't exist in early versions of keystone so i can not make the call if the minor version is correct
18:51:29 <bknudson> I meant they're not thinking about the python sdks.
18:51:46 <dolphm> jamielennox_: that should be a safe client side behavior
18:52:00 <jamielennox_> dolphm: yet i checked and we still advertise v3.0
18:52:07 <jamielennox_> but don't change that cause we'll break auth_token
18:52:14 <dolphm> jamielennox_: oooh, right.
18:52:17 <morganfainberg> so, lets rev the minor version per release
18:52:18 * jamielennox_ needs a holiday
18:52:21 <morganfainberg> simple for now.
18:52:25 <dolphm> jamielennox_: auth_token needs a patch asap :(
18:52:34 <ayoung> lets open a bug in Auth token saying v 3.X  at least
18:52:37 <dstanek> jamielennox_: this highlights the problem we have in general - we don't advertise capabiltiies in our APIs yet
18:52:37 <dolphm> morganfainberg: we do, in the api doc
18:52:45 <dolphm> morganfainberg: but auth_token is hardcoded to look for .0
18:52:56 <dolphm> morganfainberg: so the server has been stuck for several releases
18:52:59 <morganfainberg> dolphm, sure, but we need to fix the server too.
18:53:00 <bknudson> that's what json-home can do
18:53:01 <dolphm> advertising .0
18:53:04 <morganfainberg> bknudson, ++
18:53:07 <morganfainberg> yay json-home!
18:53:08 <dolphm> bknudson: ++
18:53:08 <ayoung> version >=  3.0  && version < 4.0
18:53:31 * ayoung opening bug now
18:53:32 <jamielennox_> morganfainberg: so the auth_version param in auth_token only checks that the value is v3.0, and so it will revert to v2 if we update the minor version :'(
18:53:40 <morganfainberg> jamielennox_, so lets fix that
18:53:50 <lbragstad> ~ 7 minutes left
18:53:54 <jamielennox_> morganfainberg: yea, was looking at it just a few hours ago
18:54:15 <gyee> ouch
18:54:24 <morganfainberg> jamielennox_, i'm willing to cut a new middleware *asap* if we get that fixed to do like 3.0 <= KS API version <= 4.0
18:54:42 <bknudson> morganfainberg: there's a revert that should get in before a new middleware
18:54:49 <ayoung> #link https://bugs.launchpad.net/keystonemiddleware/+bug/1383853
18:54:50 <uvirtbot> Launchpad bug 1383853 in keystonemiddleware "auth_token middleware hard coded to check for version 3.0" [Undecided,New]
18:54:53 <morganfainberg> bknudson, lets make sure it lands then.
18:55:18 <bknudson> https://review.openstack.org/#/c/129551/ is the revert (from jamielennox_ ).
18:55:24 <bknudson> jamielennox_ is going to fix it for real.
18:55:46 <morganfainberg> bknudson, +3 on that one
18:55:58 <jamielennox_> i've been looking at it this afternoon and it's a PITA but it'll work somehow
18:56:24 <morganfainberg> bknudson, easy sell since there wasn't a realse with it
18:57:13 <morganfainberg> oh, last quick note: Check for untriaged bugs - please triage them if you can
18:57:25 <morganfainberg> i'll run the report to the #openstack-keystone channel here post meeting.
18:57:32 * morganfainberg hasn't setup a cron job for this yet
18:59:16 <dolphm> \o/
18:59:18 <dolphm> #endmeeting