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