18:01:56 <dolphm> #startmeeting keystone
18:01:57 <openstack> Meeting started Tue Apr 30 18:01:56 2013 UTC.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:00 <openstack> The meeting name has been set to 'keystone'
18:02:16 <dolphm> #topic New core reviewers
18:02:23 <dolphm> yay for termie and bknudson!
18:02:28 <bknudson> dolphm: thanks
18:02:34 <topol> congratulations!!!
18:02:36 <stevemar> congrats
18:02:40 <bknudson> I +2d this one: https://review.openstack.org/#/c/27832/
18:02:43 <spzala> Congratulations!
18:02:51 <bknudson> what's the "Approve" section? we don't have that in our internal gerrit.
18:03:24 <dolphm> bknudson: marking as Approved starting the gating & merge process
18:03:35 <dolphm> bknudson: wait until you're the second +2 to mark Approve
18:03:54 <dolphm> #topic High priority bugs or immediate issues?
18:03:55 <bknudson> dolphm: ok. on our internal gerrit there's a submit button.
18:04:33 <dolphm> keystone gate seems to have been gunked up all week? this should fix it according to bknudson https://review.openstack.org/#/c/27832/
18:04:50 <dolphm> not sure what the underlying problem is there, but i'd prefer an actual fix rather than a revert if anyone has looked into it
18:05:52 <bknudson> Here's the original: https://review.openstack.org/#/c/20231/
18:06:29 <dolphm> someone pinged the mailing list about the same issue last week, not sure who that was?
18:08:31 <dolphm> (any other fires?)
18:09:25 <dolphm> #topic Havana blueprints
18:09:28 <dolphm> #link https://blueprints.launchpad.net/keystone/havana
18:09:29 <spzala> dolphm: no sissue here but this backporting candidate needs to be reviewed https://review.openstack.org/#/c/27364/   ayoung is fine with changes (and had +1 it) and I had addressed some some of henry nash's comments.
18:10:00 <dolphm> spzala: cool, let's get jenkins to +1 first and then circle back :)
18:10:05 <dolphm> spzala: ping me about it later today
18:10:12 <spzala> dolphm: ha ha
18:10:23 <spzala> dolphm: OK sounds good. thanks!
18:10:23 <ayoung> Keystone!
18:10:36 <dolphm> regarding havana blueprints, that's the list of blueprints i opened or approved as a direct result of conversations at the summit
18:11:25 <dolphm> if there are any other outstanding blueprints that you or someone you love are personally planning on pursing in Havana, let me know because i'd like to add them to that list
18:11:30 <dolphm> ayoung: welcome!
18:11:59 <bknudson> dolphm: one thing we'd like to add is support for IBM DB2 as database.
18:12:01 <ayoung> dolphm, cool.  You've probably seen a lot of churn from me on blueprints.  I'm trying to use it as a way to provide common conversation around these things.  I'll ping you when I think anything is close to ready for approve/deny
18:12:17 <dolphm> ayoung: thanks
18:12:51 <dolphm> ayoung: let me know if the opposite is true as well (if a blueprint doesn't look like it's going to result in a change, we can mark it as obsolete)
18:12:52 <jaypipes> hi all...
18:12:57 <dolphm> jaypipes: o/
18:13:00 <ayoung> bknudson, is DB2 completely Free and Open Source available these days?
18:13:11 <bknudson> it's not open source.
18:13:24 <jaypipes> https://review.openstack.org/#/c/27563/ <-- Proposed Regions CRUD extension for v3.1 API...
18:13:25 <bknudson> there's a free version available.
18:13:43 <ayoung> bknudson, that is free as in "free fousand quid, govnuh."
18:14:06 <bknudson> http://www-01.ibm.com/software/data/db2/express-c/download.html
18:14:20 <topol> bknudson, clarify what you mean. you want to add a driver to allow for integration?
18:14:31 <dolphm> blueprints that must be completed by havana-m2 or they won't land in havana: bp inherited-domain-roles, bp store-quota-data, bp first-class-regions, bp notifications, bp catalog-optional, bp endpoint-filtering
18:14:45 <dolphm> these are all API-affecting blueprints
18:15:01 <ayoung> bknudson, I would state that you should make sure any patches that go in to the SQL layer work against DB2, but I don't think we should add it to gate.
18:15:10 <bknudson> topol: just like you can configure keystone to work with mysql or postgresql, should work with DB2.
18:15:20 <dolphm> jaypipes: thanks, will review today
18:15:25 <bknudson> ayoung: that's fine.
18:15:39 <topol> dolphm, I added a blueprint today https://blueprints.launchpad.net/keystone/+spec/keystone-ldap-anonymous-binding  how do I get it to show up on your havana radar?
18:15:43 <bknudson> maybe we could add it as a nongating test sometime.
18:16:03 <ayoung> bknudson, it might be worthwhile to look at the things that we are starting to do per db type and make sure that there is a reasonable catchall, that covers Oracle and DB2, but we won't explicitly reference them
18:16:18 <ayoung> topol, let me look at it first
18:16:20 <dolphm> topol: that list is based on the Series Goal option -- do you have access to that?
18:16:37 <termie> topol: the db stuff is pretty straightforward to add as contrib, too
18:16:48 <termie> topol: for example i have a cassandra backend that is going that route
18:17:08 <topol> dolphm, no just have milestone target
18:17:12 <ayoung> topol, needs to be fleshed out first.  I assume you mean that LDAP is read only, and there is no simple bind done for the manager account to read the user list etc?
18:17:26 <dolphm> topol: k, i set it for you -- any others?
18:18:06 <topol> ayoung, its easy, wanting to do an anonymous simple bind, obviously read only
18:18:37 <dolphm> topol: sounds easy; priority?
18:18:43 <ayoung> topol, write the spec in order to explain it to someone that doesn't understand the LDAP backend.
18:19:01 <dolphm> topol: sounds like a low to me
18:19:31 <dolphm> it's also linking to a blank etherpad, but i'm not sure it needs a spec link at all?
18:19:33 <topol> ayoung, will do.  dolphm, priority can be whatever you like. I will get it done for havana.
18:19:51 <dolphm> something should also specify what new config options will be introduced, and how they'll be used, etc
18:19:58 <topol> yes, was in the middle of updating and got sidetracked. will complete it today
18:20:18 <gyee> topol, you need a bp for anonymous bind?
18:20:23 <topol> dolphm, agreed. I will add the details
18:20:26 <gyee> you can just add it right?
18:20:40 <topol> gyee,  as a bug instead of bp?
18:20:48 <ayoung> topol, so we want to support multiple ways of authing to LDAPO, with simple bind just being the frist implemented.  Kerberos is important as well.  The way of specifying how to configure the LDAP connection should not be hard coded to 'basic' or 'anonymous'
18:20:50 <gyee> bug
18:21:06 <dolphm> gyee: blueprints are handy to tell people "hey i'm working on this" and even more handy come Havana release when we can pull up a list of bp
18:21:13 <dolphm> 's and see what new features merged
18:21:24 <dolphm> gyee: it's definitely NOT a bug
18:21:26 <topol> Im happy to write the BP. it will be short
18:21:39 <dolphm> we have too many bugs that are feature requests as it stands
18:21:54 <topol> 3 more BPs and I get an instagram account :-)
18:22:47 <topol> and a $5 steam gift card
18:22:53 <ayoung> BTW, might I suggest that you assign yourself as the assignee on a blueprint, or we will close it after a month assuming it is abandoned?  No sense in writing one assuming someone is just going to pick it up to implement
18:23:03 <gyee> dolphm, already then
18:23:14 <topol> ayoung I did. I thought I did
18:23:24 <gyee> bp for a one line change :)
18:23:26 <ayoung> topol, speaking to the larger audience
18:24:00 <topol> gyee.... shhhhh  and hey its needs a config option added too
18:24:03 <dolphm> gyee: yep, plus docs and tests
18:24:28 <topol> yeah that stuff too
18:24:48 <gyee> damn straight
18:24:59 <dolphm> ayoung: that makes sense for very specific use case driven bp's, but some bp's are very broad and deserve to remain open until someone comes along and commits themselves to it
18:25:19 <ayoung> dolphm, then they can hand it off, I think.
18:25:25 <dolphm> ayoung: s/broad//generally useful/
18:25:29 <ayoung> I own it until someone takes mine of my hands.
18:26:05 <dolphm> ayoung: as the person who opened it, you will always be the stakeholder
18:26:05 <ayoung> dolphm, do you know if the UI can somehow list the drafter?
18:26:22 <dolphm> ayoung: yes, that's dead center on the bp page
18:26:34 <ayoung> dolphm, yeah, there is just no way to sort the list by anything other than assigned
18:27:21 <ayoung> dolphm, when you create the blueprint, you can list yourself as the drafter, or to change it once you've found, but there is no way to manage those that you have drafted
18:28:02 <ayoung> ah...if you go to the assignments page...
18:28:05 <ayoung> https://blueprints.launchpad.net/keystone/+assignments
18:28:17 <ayoung> #link https://blueprints.launchpad.net/keystone/+assignments
18:28:54 <topol> ayoung, so I got a concern on your json config bp.  I have been told you cant put comments in json.   That makes it a bad choice for config options.
18:29:08 <topol> plz tell me Im wrong
18:29:29 <dolphm> topol: +1
18:29:32 <gyee> topol, good point
18:29:37 <dolphm> json is absolutely horrible for config
18:29:57 <ayoung> topol, you are not wrong.
18:30:02 <gyee> why do we want json config?
18:30:37 <ayoung> gyee, not necessarily json, just a way to split out the LDAP config into its own piec,as it is getting huge, but there might be better approaches
18:31:04 <ayoung> The Attribute Mapping piece might make sense having a file backing as opposed to a database, for example, and that would fall into the same category
18:31:31 <ayoung> #link https://blueprints.launchpad.net/keystone/+spec/json-for-ldap
18:32:02 <dolphm> ayoung: "
18:32:15 <dolphm> ayoung: "big" isn't a good reason to change the config format at all
18:32:26 <ayoung> gyee, also, if we support multiple LDAP backends, the configuration will start to get confusing as well.
18:32:26 <dolphm> that's just a pointless breaking change
18:32:32 <topol> Ideally all the ldap related config will be in a single file.  I prefer to have in a single place
18:32:36 <bknudson> maybe ldap section needs more structure.
18:32:38 <gyee> ini format will do fine
18:33:10 <ayoung> gyee, that may be...I just wanted JSON to be the starting point for the discussion, not YAML
18:33:24 <ayoung> There are many ways to skin it,
18:33:25 <gyee> ayoung, I prefer ASN.1 :)
18:33:42 <bknudson> we could store the config in an ldap directory
18:33:48 <topol> maybe move it to the bottom of keystone.conf if we think it will clutter stuff?
18:34:20 <bknudson> maybe have sections like [ldap.user] for all the user_ options, etc.
18:34:36 <ayoung> topol, so, I think the LDAP config is probably going to merge with the Kent teams attribute mapping work.  And I want it to be revision control-able.  Doesn't have to be JSON, but we need a reasonable file format for it.
18:34:57 <gyee> ayoung, what's wrong with ini
18:35:09 <ayoung> But lets not have adesign discussion here...25 minutes less
18:35:10 <dolphm> ayoung: we have a oslo.config, i'd suggest we work with that
18:35:18 <gyee> +1
18:35:19 <ayoung> dolphm, sounds good
18:35:28 <topol> +1
18:37:46 <atiwari> are we looking for run time config change? in that case JSON would better work
18:38:03 <ayoung> so...one issue I think worth addressing that might affect several blueprints is the size and scope of the identity backend.  I think we should conisder splitting it.  I think that the project and roles piece can easily be separate from users and groups.  And then the mapping piece ties the two together
18:38:50 <bknudson> ayoung: sounds good
18:38:53 <ayoung> I think that projects are openstack specific concepts, as are roles, whereas users and groups come from an Identity store like LDAP
18:39:01 <gyee> atiwari, LDAP config is static
18:39:24 <topol> ayoung domains goes with the projects and roles, correct?
18:39:26 <ayoung> we can state that if no explicit backend is specified for projects, it defaults to the identity backend
18:39:35 <morganfainberg> ayoung: ooh i like that.
18:40:07 <ayoung> topol, domains are potentiall separate.  The chain of domains thing.  But even if we don't do that, we can still allow this split
18:40:27 <ayoung> topol, but if domains stay, they would stay in the identity piece and be consumed by the projects side
18:40:50 <topol> ayoung, what would be an explicit backend?  As opposed to the default identity backend?
18:41:32 <topol> we have an sql identity backend. an ldap identity backend.  what are you referring too?
18:41:36 <ayoung> projects
18:42:08 <topol> OK
18:42:35 <ayoung> back in a minute..real world interrupt
18:42:41 <dolphm> ayoung: interesting logic to split the backend on
18:43:10 <dolphm> i'd put domains with projects, as both are openstack concerns
18:43:19 <dolphm> or have domains be discrete
18:43:41 <bknudson> I like discrete domains.
18:43:51 <dolphm> termie would too
18:44:00 <topol> dolphm +1
18:44:20 <dolphm> 'default'
18:44:50 <dolphm> oops... the default domain driver could literally just provide a static 'default' domain
18:45:04 <dolphm> satisfies the ldap issue
18:45:07 <ayoung> dolphm, I like discrete domains
18:45:31 <ayoung> dolphm, there is an argument in favor of that from the LDAP side, too
18:45:40 <dolphm> ayoung: have you already filed a bp on this split somewhere?
18:45:43 * termie looks for something called "discrete domains"
18:45:50 <ayoung> say you are doing what the IBMers are pushing for, which is keystone fronting multiple LDAP servers
18:46:02 <bknudson> the config entries for domain_driver could point to the same identity driver anyways.
18:46:03 <dolphm> termie: moving domains into their own driver
18:46:09 <dolphm> termie: ... or extension
18:46:16 <ayoung> then each is adomain, but neither can provide the enumeratation of the overall domain list
18:46:30 <ayoung> and, people like rackspace still need the ability to create one domain per customer
18:46:42 <termie> dolphm: +1, mostly i think it should be applied in an AO kind of way rather than interjected all over
18:46:52 <ayoung> dolphm, I wrote an etherpad, not quite blueprint yet, as it was just brainstorming, on the domain thing
18:47:18 <ayoung> #link https://etherpad.openstack.org/chain-of-domains
18:47:35 <gyee> how do you provide cross-domain permissions
18:47:51 <gyee> federation?
18:47:53 <ayoung> I was thinking file for the domains, but should be a driver arch like the other backends
18:48:21 <ayoung> gyee, you could say "this domain is external and provided by that keystone over there..."
18:48:54 <topol> Im concerned I couldnt find a stakeholder for chain of domains.  Can we point to anyone who wants this?
18:48:55 <ayoung> Wouldn't call it Federation, though
18:49:06 <ayoung> topol, chain of domains is the etherpad name
18:49:07 <dolphm> gyee: it could be implemented as federation from the same keystone endpoint?
18:49:16 <ayoung> the bp would be "split domains from identity"
18:49:20 <ayoung> but probably now
18:49:36 <ayoung> "split identity into separate backends"
18:49:37 <gyee> and we need to have user that is visible to all domains
18:49:46 <gyee> this is important for public cloud, for support and auditing
18:49:58 <dolphm> gyee: explain?
18:50:09 <dolphm> "visbile to all domains"?
18:50:12 <ayoung> gyee, visible is different from assigned
18:50:19 <gyee> accessible to all domains
18:50:25 <ayoung> gyee,  a user in one domain can be provided access to a project in another
18:50:37 <ayoung> that doesn't change
18:50:44 <Sameer> .
18:51:04 <termie> ayoung: i don't think this blueprint is organized enough to warrant much discussion at this point
18:51:05 <gyee> ayoung, I thought you mean there's no way to list all the domains
18:51:27 <gyee> yeah, lets write something up and discuss
18:51:38 <ayoung> termie, yep, just wanted it on people's radar.  We can have the dicussion out of the meeting
18:52:00 <ayoung> #action ayoung write up blueprint for splitting identity
18:52:03 <termie> ayoung: well, you are going to discuss it for ever if you don't add some structure that people can reference
18:52:21 <termie> ayoung: i am not sure that "splitting identity" has anything to do with this "cbhain of domains" idea
18:52:36 <termie> ayoung: but kudos to you for coming up with the vaguest name today
18:52:56 <ayoung> termie, it can be two blueprints that reference each other, either way
18:53:20 <gyee> ayoung was just trying to fillerbust the meeting :)
18:53:22 <termie> ayoung: lulz, now you have two problems
18:53:29 <dolphm> ooh circular references in bp's!
18:54:05 <ayoung> OK...so I create one blueprint that is an abstract base class....
18:54:11 <ayoung> anyway, next agenda item?
18:54:19 <dolphm> #topic open discussion
18:54:29 <dolphm> i think we're already at open discussion anyway
18:54:35 <termie> when are having a keystoners offsite?
18:54:40 <ayoung> ah, cool.
18:54:51 <dolphm> termie: november 4th?
18:54:55 <topol> whats that?
18:54:59 <gyee> in Hong Hong
18:55:00 <ayoung> termie, lets have it in Yosemite
18:55:13 <gyee> Kong Kong
18:55:20 <gyee> Hong Kong
18:55:47 <termie> ayoung: yosemite is pretty nice, but november might be late, maybe sept?
18:55:52 <termie> er
18:55:55 <termie> dolphm: ^
18:55:57 <ayoung> how many people thing that they are actually going to be headed to HK?  Seems like it might be poorly attended.
18:56:04 <topol> is this a prevacation before the next summit?
18:56:07 <termie> ayoung: i'll be there
18:56:09 <ayoung> Sept is Big wall season.  Works for me
18:56:18 <topol> Im hoping to goto Hong Kong
18:56:35 <dolphm> i'll definitely be there
18:56:54 <stevemar> is there usually something in between summits?
18:56:59 <topol> usually Hong Kong events on cloud stuff get big crowds
18:57:01 <termie> stevemar: no, but we're cool
18:57:03 <dolphm> stevemar: we can start a new tradition
18:57:14 <dolphm> the pre-summit offsite
18:57:22 <ayoung> I'm planning on it, too, but the travel budget is tight, and we have a lot of people on Open Stack.  Need to make the argument to the decision makers that I should go.
18:57:34 <termie> ayoung: don't tell them you work on keystone
18:57:40 <dolphm> termie: +1
18:57:47 <termie> ayoung: sure way to be sidelined
18:58:03 <topol> what??? Keystone gets big respect over here in big blue land
18:58:04 <ayoung> termie, heh, they know already.
18:58:45 <topol> its not like its ceilometer or something...
18:58:47 <termie> topol: orly? all that most people i know want out of keystone is to make the validate call faster
18:59:00 <termie> topol: which is why it is so easy for me to say no to things all the time
18:59:00 <dolphm> heat
18:59:12 <topol> (Just kidding,  I have folks working on ceilometer)
18:59:25 <termie> topol: you are some sort of puppetmaster
18:59:36 <stevemar> termie: so many puppets!
18:59:39 <termie> Brad "I've got people on that" Topol
18:59:46 <topol> termie, its called LEADERSHIP
18:59:47 <stevemar> topol: kidding :P
19:00:04 <ayoung> termie, so I wonder if the PKI token in memory validation means that we have made it faster or slower.
19:00:12 <termie> Steve "Yes sir!" Martinelli
19:00:21 <ayoung> stilltrying to get some performance numbers on that
19:00:27 <termie> ayoung: v3 api means you have made it slower ;)
19:00:45 <ayoung> termie, PKI went in prior to that, though, and auth_token middleware doesn't use v3
19:01:05 <ayoung> but actually, it shouldn't matter, as validation is kindof agnostic to the token format
19:01:37 <ayoung> OK, we're over time
19:01:45 <termie> would love if somebody wanted to set up more perf stuff, btw, otherwise i'll eventually have to get off my ass and do it
19:01:50 <termie> EVERYBODY OUT
19:02:49 <dolphm> #endmeeting