18:03:51 <dolphm> #startmeeting keystone
18:03:51 <openstack> Meeting started Tue Oct 29 18:03:51 2013 UTC and is due to finish in 60 minutes.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:03:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:03:55 <openstack> The meeting name has been set to 'keystone'
18:04:04 <dolphm> openstack: thanks for the tips
18:04:10 <dolphm> \o/
18:04:12 <joesavak> keystone dance!
18:04:13 <bknudson> hi
18:04:14 <stevemar> marking meeting... psssh
18:04:23 <stevemar> marketing*
18:04:32 <gyee> \o\
18:04:36 <dolphm> i haven't prepared much of anything for this meeting, as i mostly have my head in the summit
18:04:44 <joesavak> gross.
18:04:45 <stevemar> /o/
18:04:49 <dolphm> seriously
18:04:50 <dolphm> #link http://icehousedesignsummit.sched.org/overview/type/keystone
18:04:51 <ayoung> dolphm, kick-a$$ job on that BTW
18:04:56 <topol> same here
18:05:02 <dolphm> this is the current summit schedule ^
18:05:08 <gyee> you need to prepare for the summit?
18:05:10 <dolphm> we're still seeing some scheduling flux as we discover conflicts
18:05:12 <ayoung> http://icehousedesignsummit.sched.org/adam.m.young
18:05:16 <ayoung> :)
18:05:25 <dolphm> so if you notice one, stab me or ttx asap and we'll look for a solution
18:05:43 <topol> so this time we are spread out over some days, correct
18:05:48 <dolphm> topol: yes!
18:05:51 <stevemar> topol yep
18:05:55 <bknudson> wasn't there a security track last time?
18:05:58 <dolphm> we have an entire DAY for the client
18:06:02 <dolphm> an entire DAY for federation
18:06:08 <ayoung> the dev conf and maion conf are on two different schedules
18:06:20 <gyee> dolphm, the keystone sessions starting at 4:30pm
18:06:23 <gyee> ?
18:06:29 <bknudson> we can sleep in
18:06:30 <ayoung> gyee, and go until we are done
18:06:33 <dolphm> the first and last days are a bit mixed, but the theme is that the first day is largely keystone-internals, and the last day will largely have stakeholders from outside keystone
18:06:35 <topol> when will the schedule be finalized
18:06:45 <dolphm> gyee: yeah, we're afternoon everyday at the moment
18:06:48 <gyee> 4:30pm usually nap time
18:06:50 <ayoung> topol, after the summit
18:06:52 <dolphm> topol: next tuesday?
18:07:22 <ayoung> topol, we are going to have a session at the summit where we finalize the schedule for the summit.  THat session is on Friday at 4 PM
18:07:45 <dolphm> #topic icehouse summit schedule
18:08:37 <dolphm> bknudson: there was a security track last time, yes
18:08:41 <topol> K,, I need to attend some heat and ceilometer so trying to plan this time
18:08:54 <dolphm> also, if everyone hasn't noticed yet... there are TWO schedules
18:08:57 <dolphm> the design summit: http://icehousedesignsummit.sched.org/
18:09:02 <dolphm> and the conference: http://openstacksummitnovember2013.sched.org/
18:09:07 <dolphm> apologies if you want to attend both
18:09:13 <joesavak> that's not confusing
18:09:24 <ayoung> joesavak, not at all
18:09:25 <dolphm> recommend importing both into your ical or something to look for conflicts / keep one schedule
18:10:38 <topol> Im just happy if I see a final design summit schedule.  Thats where all the cool people are
18:10:48 <dolphm> for the most part, those who attend talks don't have much interest in attending open discussions, and vice versa
18:11:17 <topol> dolphm, agreed
18:11:21 <ayoung> topol, even when it is final, expect it to change somewhat.  Last year (San Diego) had changes right up to the hour before.  Semper Gumby
18:11:24 <bknudson> probably good to have stakeholders at the open discussions
18:11:26 <dolphm> i trust that those who are interested in both are fully capable of juggling calendars already
18:12:04 <ayoung> Last year they had a smartphone app.  Wonder if that wil deal with both, or just the Main summit
18:12:17 <dolphm> with regard to unconference sessions, we've never had a great way to coordinate attendance, as they're generally last minute
18:12:18 <topol> design has a smartphone app
18:12:37 <topol> installed it today. dont know how accurate it is
18:12:42 <dolphm> i'm curious as to how ya'll would like to be informed of unconference sessions, beyond being expected to skim the unconference whiteboard a few times a day
18:12:51 <morganfainberg> ayoung, the app will be split like the schedules.
18:12:54 <morganfainberg> ayoung, likely
18:13:07 <stevemar> looking at the whiteboard works
18:13:09 <morganfainberg> dolphm, (don't hurt me) twitter?
18:13:15 <gyee> dolphm, us that bird thingy
18:13:18 <dolphm> topol: you can also just import a calendar feed from sched.org
18:13:22 <gyee> I think they call it twitter
18:13:30 * morganfainberg almost feels dirty recommending it.
18:13:39 <stevemar> almost?
18:14:01 <morganfainberg> stevemar, i am waiting for it to sink in.
18:14:11 <stevemar> i think we're all sync'ed up in twitter for the most part
18:14:17 * dolphm shrugs
18:14:18 <dolphm> works for me
18:14:39 <topol> gonna miss not seeing termie. I assume hes not coming
18:14:56 <dolphm> topol: i wouldn't bet against him
18:14:58 <gyee> topol, which part? the beard?
18:15:07 <dolphm> gyee: mustache?
18:15:14 <gyee> yeah that :)
18:15:18 <stevemar> he's unpredictable, maybe he'll just show up
18:15:20 <topol> the part when he tells me he will crush my soul... then buy me a beer
18:15:23 <morganfainberg> topol, he's been lurking around in irc again...
18:15:30 <morganfainberg> topol, hehe
18:15:30 <joesavak> lol
18:15:33 <topol> really, cool
18:16:05 <topol> making fun of my old laptop... the whole megillah
18:16:09 <joesavak> new topic for next meeting - termie recovery anonymous
18:16:21 <dolphm> #topic open discussion
18:16:40 <stevemar> joesavak, topol will chair that group :P
18:16:44 <gyee> anybody trying running keystone tests in mac os 10.9?
18:16:53 <gyee> oslo config failed me
18:17:03 <bknudson> if people have time to review changes, they're starting to pile up.
18:17:04 <gyee> 124 test failures
18:17:10 <morganfainberg> lots of test cleanup, dstanek is awesome (among other people jamielennox) for working on it.  just wanted to give props to him on that.
18:17:17 <ayoung> termie, stated that he was coming back when HK was announced as the Venue.  His input, while caustic online, is surprisingly valuable when delivered in person
18:17:21 <dolphm> gyee: 10.9 worked for me for about 48 hours and then i upgraded xcode tools i think
18:17:26 * dstanek blushes
18:17:31 <dolphm> gyee: now i'm going to wipe my laptop and install 10.9 fresh
18:17:34 <ayoung> dolphm, jaypipes wanted to talk regions
18:17:38 <gyee> dolphm, oslo config failed to read some files at the end
18:17:46 <dolphm> ayoung: cool
18:17:48 <gyee> I still haven't been able to pinpoint the problem yet
18:17:50 <dolphm> ayoung: unconference?
18:17:54 <dolphm> ayoung: or here?
18:17:57 <gyee> I am using homebrew python and everything
18:17:59 <ayoung> dolphm, it was about the id thing...here I think
18:18:10 <dstanek> if you guys get a chance take a look at the test reviews ... i'd like to get them in sooner rather than later since they'll be a pain to keep rebasing
18:18:14 <ayoung> should be a short discussion.
18:18:16 <topol> gyee is out of the groove...
18:18:47 <dolphm> gyee: me too
18:18:49 <ayoung> jaypipes posted a review, and the question was whether a region needed a UUID based Id.  I suspect that it does not
18:18:55 <dolphm> ayoung: id vs name?
18:19:00 <ayoung> dolphm, right
18:19:30 <ayoung> #link https://review.openstack.org/#/c/54215/
18:19:37 <gyee> man we should really think about organizing catalogs into trees
18:19:41 <dstanek> gyee: you may need to up your file descriptors per process
18:19:44 <gyee> similiar to LDAP DIT
18:19:49 <gyee> catalog is made for that
18:20:00 <joesavak> gyee +1
18:20:00 <dolphm> ayoung: i suggested the other day that user's specify a region name, and the system define the region ID based on the name such that id == urlencoded(name)
18:20:00 <gyee> lookup will be super easy
18:20:20 <gyee> you can filter it anyway you want
18:20:28 <dolphm> ayoung: in practice, it might be better to do if name != urlencoded(name): raise BadRequest
18:20:44 <dolphm> ayoung: so id == name
18:20:52 <gyee> dstanek, good point!
18:20:52 <morganfainberg> for the test reviews:
18:20:58 <ayoung> dolphm, I think that is the right approach, too.
18:21:00 <morganfainberg> #link https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:fix-all-the-tests,n,z
18:21:27 <gyee> dstanek, I remember someone mentioned it was leaking file descriptors
18:21:27 <dstanek> gyee: i have a patch that dramatically reduces used file descriptors during a test run :-)
18:21:45 <dstanek> gyee: i should be able to get that up today too
18:21:59 <gyee> dstanek, you are the wind beneath my wings
18:22:45 <joesavak> ...
18:23:06 <joesavak> gyee, i think you killed the meeting
18:23:08 <dolphm> dstanek: morganfainberg: thanks
18:23:13 <gyee> oh damn
18:23:27 <dolphm> dstanek: where was the leak??
18:23:33 <dstanek> gyee: awkward...
18:23:35 <dolphm> dstanek: i've been on the lookout for that for like a year
18:24:18 <dstanek> dolphm: two leaks; one was the inprocess server leaking sockets and the other was handles to the tmp database
18:24:48 <ayoung> gyee, I see you havebeen disregarding the Pythagorean Maxim
18:24:52 <gyee> oslo basically said it can't find keystone.conf.sample after some test runs
18:25:00 <dolphm> i always assumed there was an issue with the tmp database, but couldn't figure it out
18:25:03 <dstanek> dolphm: i just ran the full test quite and was checking it periodically with lsof
18:25:17 <dolphm> gyee: i may have heard someone else complain of the same
18:25:27 <gyee> dolphm, I think it was termie
18:25:41 <gyee> I just can't remember if was fixed
18:25:49 <dstanek> gyee: try raising your fd limit to 1024 and run the tests again
18:26:26 <dolphm> gyee: oh! what i'm thinking of might have been yesterday lol
18:26:32 <dolphm> gyee: and it was a fd limit issue
18:26:42 <gyee> wow
18:26:54 <dolphm> gyee: oslo.config was suppressing the error on open() and replacing it with 'file not found'
18:27:01 <dolphm> i opened a bug against oslo for that
18:27:05 <morganfainberg> if i can start running tests natively on mac, i'll be even happier. i should set that up
18:27:08 <gyee> dolphm, yep, that's what I was seeing
18:27:27 <dolphm> https://bugs.launchpad.net/oslo/+bug/1244674
18:27:30 * jaypipes doesn't care which way... just wants a decision. :)
18:28:12 <dolphm> jaypipes: can we start with `if name == urlencoded(name): id = name; else: HTTP 400`
18:28:57 <jaypipes> dolphm: that is pretty much what I submitted. jamie did not like that.
18:29:02 <dolphm> jaypipes: urllib.quote(name, safe='')
18:29:05 <dolphm> jaypipes: link?
18:29:35 <jaypipes> https://review.openstack.org/#/c/54215/2/openstack-identity-api/v3/src/markdown/identity-api-v3.md
18:29:49 <jaypipes> dolphm: ^^
18:29:55 * topol jaypipes needs to show up in Hong Kong and demand a decision...
18:33:27 <ayoung> jaypipes, in general I think I am OK with the patch as is.   Let me give it another close read through, but I think you addressed all of my concerns
18:34:08 <ayoung> Since creating a region is an admin task, and a rare one at that, I think autogenerated UUIDs are not called for
18:35:35 <stevemar> ayoung: does anything else exist in keystone that doesn't have a UUID as an id?
18:35:49 <morganfainberg> stevemar, LDAP backed Identity
18:36:00 <morganfainberg> stevemar, ldap backed assignment
18:37:01 <stevemar> morganfainberg, i meant keystone entities (as far the api spec is concerned)
18:37:13 <morganfainberg> stevemar, sorry, feeling a little punchy
18:37:24 <stevemar> morganfainberg, i figured ;)
18:37:34 <morganfainberg> stevemar, no, but we do support username and project name in lieu of the id in cases.
18:37:38 <morganfainberg> stevemar, same with domain
18:37:44 <topol> morganfainberg needs a vacation
18:37:52 <dolphm> jaypipes: posting some comments in a minute, let me know if you have questions
18:38:14 <morganfainberg> stevemar, it isn't a massive departure, and i think in this case, name == id is more friendly/usable
18:38:23 <stevemar> ayoung: awaiting your input on https://review.openstack.org/#/c/51980/7 btw
18:38:35 <topol> morganfainberg +1
18:38:37 <dolphm> jaypipes: on patchset 3
18:38:52 <stevemar> morganfainberg, i'm cool with name == id for this case, was just playing devil's advocate :)
18:38:52 <morganfainberg> no reason to overload having multiple ways to handle regions since they will be (as ayoung said) not made as often as projects... or instances even.
18:39:30 <morganfainberg> stevemar, fair enough :)
18:40:10 <dolphm> morganfainberg: i played around with the idea of project & user id's being based on the name ... that's difficult with URL encoding & domain scope
18:40:18 <dolphm> i don't have a good solution at all
18:40:31 <dolphm> service name can be id
18:40:33 <morganfainberg> dolphm, i would actually like that if it can be viable.
18:40:36 <dolphm> domain name can be id
18:40:43 <morganfainberg> id based on name that is (project/user)
18:40:46 <dolphm> morganfainberg: me too, but encoding get's nasty
18:40:57 <dolphm> morganfainberg: or you need to reserve a character as a seperator
18:41:03 <morganfainberg> dolphm, it's the issue we are trying to handl with DNs as IDs ;)
18:41:05 <dolphm> morganfainberg: and there's unicode support
18:41:46 <morganfainberg> dolphm, yeah.  *shudder* unicode an py27.  it makes me sad (and longing for full py3k support)
18:42:02 <dolphm> i'm totally ready to switch lol
18:42:04 <morganfainberg> still doesn't solve urlencoding though.
18:42:16 <jamielennox> ... sorry i'm late - i miss anything particular for me?
18:42:35 <ayoung> LDAP user ids are going to be a tricky.  I had thought we weould use the DN, but even there we are not going to be globally unique
18:42:52 <ayoung> Ids should ideally embed the domain in them
18:43:00 <ayoung> @ sign is the defacto standard
18:43:07 <ayoung> jamielennox, yeah
18:43:10 <gyee> ayoung, huh?
18:43:16 <ayoung> jamielennox, we are discussing naming and the regions patch
18:43:21 <gyee> DNs are meant to be globally unique
18:43:25 <dolphm> ayoung: @ is not url friendly
18:43:33 <ayoung> gyee, @ sign is what people expect for username and domain
18:43:35 <ayoung> dolphm, I know
18:43:59 <ayoung> I am just pointed out that it is typically how this is done, not that it works for us
18:44:01 <dolphm> user%40domain
18:44:31 <ayoung> dolphm, and it also breaks if people are using email addresses as usernames, very common practice
18:45:19 <dolphm> you almost have to encode twice to be able to avoid reserved chars and allow predictable decoding, e.g. encode(encode(user_name) + '@' + encode(domain_name))
18:45:24 <jaypipes> so... back to the region name vs. region ID thing...
18:45:30 <morganfainberg> dolphm, not fun.
18:45:32 <ayoung> I don't have a good answer, unfortunately.  the LDAP approach os DN=ayoung,CN=redhat,CN=com
18:45:52 <bknudson> DC=redhat,DC=com
18:45:59 <morganfainberg> ayoung, are there reserved characters in LDAP DNs?
18:46:07 <morganfainberg> eg. things that can't go in them?
18:46:07 <ayoung> right, right
18:46:08 <bknudson> , is reserved!
18:46:11 <dolphm> jaypipes: follow up question?
18:46:13 <jaypipes> any way we can get back on track here? :)
18:46:21 <dolphm> jaypipes: it's open discussion ;)
18:46:24 <ayoung> jaypipes, no, we love it in the weeds
18:46:29 <morganfainberg> bknudson, haha if only that was more helpful ;)
18:46:30 <jaypipes> I noticed ;)
18:46:38 <ayoung> jaypipes, short of it is, I think that region names can be user assigned
18:46:43 <morganfainberg> jaypipes, join us in the weeds.
18:46:48 <morganfainberg> (you know you want to)
18:46:49 <ayoung> and id == name is a good rule
18:46:54 <morganfainberg> ayoung ++
18:47:01 <jaypipes> ayoung: as opposed to assigned by The Creator?
18:47:13 <ayoung> I don't think UUID region IDs buys us anything
18:47:21 <jamielennox> i know i probably missed this, but if id == name, why do i want both?
18:47:23 <ayoung> jaypipes, as opposed to assigned by the server...
18:47:32 <jaypipes> ayoung: there was actually nothing in the original proposal that said anything about UUIDs, but whatevs :)
18:48:02 <jaypipes> ayoung: OK, so shall I remove the entire notion of region ID then, and just say region name must be unique within a deployment and be URL-safe?
18:48:07 <ayoung> jaypipes, hey, I am pulling this out of long term memory...I wasn't the one that Red Xed the original proposal.
18:48:18 <jaypipes> ayoung: yes, I know :)
18:49:04 <dolphm> jaypipes: you'll still have a region ID in the spec, per API Conventions
18:49:17 <dolphm> jaypipes: all resources have an 'id' attribute
18:49:28 <jaypipes> dolphm: OK... so is there a reason to have name then?
18:49:34 <ayoung> jaypipes, why not name be the segment, and ID be the full path?
18:49:54 <morganfainberg> ayoung, didn't that break down with filtering and moving regions around?
18:49:59 <morganfainberg> i might be mis-remembering
18:50:00 <dolphm> jaypipes: per convention, names are specified by the client, and id's are specified by the service
18:50:21 <jaypipes> morganfainberg: correct, though I think a better reason not to do that is just for simplicity's sake
18:50:45 <dolphm> jaypipes: if the client is going to specify the ID directly, i think it should be a PUT on the final resource location
18:50:52 <dolphm> jaypipes: not a POST with an id attribute
18:51:13 <ayoung> morganfainberg, I am a fan of immutable objects...but, yeah, there was a sense that region ID was like INODE and region name was like dentry
18:51:16 <morganfainberg> jaypipes, i'll buy doing it for simplicity as a means to an end (and avoid the other issues as a byproduct)
18:51:31 <jaypipes> dolphm: ok, so my proposal as it stands right now would work for you, then? both an ID and a name field, with the ID being generated rfom the name, with name being unique within a deployment?
18:51:37 <ayoung> morganfainberg, too long since we had the original conversation
18:51:43 <dolphm> jaypipes: yes
18:51:45 <bknudson> can I change the name?
18:51:54 <dolphm> bknudson: good question
18:52:00 <morganfainberg> ayoung, yah.
18:52:00 <dolphm> bknudson: id's are immutable, i forgot about that
18:52:08 <ayoung> jaypipes, is moving a region around in the hierarchy an essential feature?
18:52:24 <dolphm> ayoung: seems like a simple feature - why do you ask?
18:52:31 <dolphm> PATCH to parent_region_id
18:52:37 <morganfainberg> jaypipes, would it make more sense to be able to move other objects to another region vs change a region?
18:52:47 <ayoung> dolphm, then the ID needs to be separate from the name
18:53:00 <jaypipes> morganfainberg: the only other object to move to another region is a another region
18:53:07 <bknudson> SQL queries of hierarchical data are typically slow... requires looping
18:53:14 <morganfainberg> maybe even support a "redirect" concept "oh that object is now in region <blah>" instead of "renaming" the region itself.
18:53:16 <jaypipes> bknudson: nested set model.
18:53:19 <dolphm> ayoung: because why? i don't follow
18:53:30 <morganfainberg> jaypipes, right
18:53:41 <jaypipes> bknudson: single non-looping query over the (small) dataset
18:53:54 <jaypipes> bknudson: can return descendants of any level
18:54:04 <bknudson> a small dataset makes it easier.
18:54:10 <dolphm> bknudson: it'd be easier to construct it in python and cache the result in dogpile :)
18:54:34 <dolphm> bknudson: i.e. select all from sql, then build a deep dict in python
18:54:36 <jaypipes> ok, so back to the name vs ID thing...
18:54:38 <ayoung> dolphm, say a region has 13 endpoints.  If you want to move that reqion with all the endpoints around in the hierarchy, you need to maintain the id to maintain the relationships...or update each individual record.  THere was some problem with the latter as I recall
18:55:18 <dolphm> what jaypipes said
18:55:40 <dolphm> ayoung: you just need update one region to achieve that
18:55:49 <gyee> jaypipes, looks like I can create a circular reference with the current spec? parent_region_id pointing to a child region id?
18:55:52 <dolphm> ayoung: and it doesn't require mutable ID's
18:56:12 <dolphm> gyee: ++
18:56:14 <jaypipes> gyee: sure, I can add a note about that.
18:56:21 <bknudson> gyee: that's another problem with moving subtrees, can get disconnected.
18:56:21 <dolphm> gyee: impl should maybe validate that on POST ?
18:56:33 <morganfainberg> gyee, nice catch
18:56:43 <jaypipes> dolphm: yes.
18:56:44 <morganfainberg> no circular deps please ;)
18:56:53 <morganfainberg> or references...
18:56:54 <jaypipes> but can we make a decision on the ID vs. name thing?
18:57:05 <gyee> well, impl will have to fix that
18:57:10 <ayoung> dolphm, if I move a region from one parent region to another, I am, in effect creating a new region object, and moving all of the endpoints.  Assuming an endpoint has a link to its region, the endpoint objects need to be updated.  So, yeah, region is technically immutable, but due to a lot of copying etc
18:57:21 <ayoung> jaypipes, ^^ is the heart of the problem
18:57:37 <jaypipes> ayoung: wouldn't be a problem if ID were a UUID.
18:57:44 <dolphm> jaypipes: is anyone opposed to id == name per http://pasteraw.com/hh7sz3rfnk6fyn9zes1wcahqcov0o7j
18:57:46 <morganfainberg> ayoung, the easiest solution is uuid
18:57:50 <ayoung> jaypipes, do we need an immutable id in order to move regions around?
18:58:04 <dolphm> ayoung: but you don't have to create a new region object to do that
18:58:11 <jaypipes> ayoung: yes. at least, without some code gymnastics
18:58:16 <dolphm> endpoint objects don't need to be updated
18:58:29 <jaypipes> dolphm: they would if the ID changed.
18:58:37 <jaypipes> dolphm: which would happen if the name == ID.
18:58:42 <ayoung> dolphm, they do if they contain a link to their region, which is what i am trying to ascertain
18:59:20 <dolphm> jaypipes: immutable name and address it later?
19:00:08 <jaypipes> dolphm: ?
19:00:09 <ayoung> dolphm, server assigned ID, UUID, is probably most appropriate.  Ugly, but it matches how people need to think about regions
19:00:28 <jaypipes> ayoung: it also matches every other resource in the Keystone API.
19:00:38 <ayoung> jaypipes, I'll add ^^ to the reveiw request so we don't lose this logic again
19:00:57 <jaypipes> that said, I wouldn't mind going with jamielennox's suggestion of "display_name" instead of just "name"
19:00:59 <morganfainberg> ayoung, unless region "names" aren't fully qualified.  more like a linked list.  but i think that is an ugly approach.  uuid is least resistance
19:01:07 <morganfainberg> ayoung, and makes the most sense in this context.
19:01:15 <jamielennox> i'm not sure i see the usecase for moving regions
19:01:41 <jamielennox> why would someone want thatt?
19:01:53 <dolphm> jaypipes: in all your examples, you're duplicating the parental relationship in the region names themselves, right?
19:01:54 <bknudson> earthquake?
19:02:13 <jamielennox> bknudson: that's a definite region deletion
19:02:17 <jamielennox> time guys
19:02:46 <dolphm> jamielennox: say an entire rack was upgraded to SSD's, it now belongs in a different sub region?
19:02:50 <dolphm> jamielennox: ah, thanks
19:02:52 <dolphm> #endmeeting