18:03:58 <heckj> #startmeeting 18:03:59 <openstack> Meeting started Tue Feb 21 18:03:58 2012 UTC. The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:04:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic. 18:04:16 <heckj> #topic state and progress - bugs, bugs bugs 18:04:27 <heckj> I'm working from http://wiki.openstack.org/Meetings/KeystoneMeeting 18:04:49 <heckj> dolph went through an cleaned out a pile of bugs 18:04:53 <termie> i've been on vacation pretty much since the merge and just got into the office so catching up quickly 18:05:11 <heckj> And likewise, I added a pile more - marked with "redux" for the KSL branch work, and "python-keystoneclient" for the client work pending 18:05:16 <anotherjesse> the review queue is pretty small - https://review.openstack.org/#q,status:open+project:openstack/keystone,n,z 18:05:42 <dolphm_> do we need to continue using redux tags? 18:05:46 <heckj> Ive been using: "https://review.openstack.org/#q,status:open+keystone,n,z" 18:05:49 <heckj> #link https://review.openstack.org/#q,status:open+keystone,n,z 18:05:58 <ayoung> I was talking over the Idaccca93 and I94e89271 bugs with the fedora packagers 18:05:59 <bcwaldon> dolphm_: its a good hint at what's not a ks heavy bug, for your triaging effort 18:06:04 <heckj> That's giving a broader picture with the client there too 18:06:06 <anotherjesse> dolphm_: I think tagging legacy bugs "legacy" instead of using redux in the future? 18:06:09 <termie> dolphm_: i'd say no, but we do want to kill off n/a bugs before we get rid of it 18:06:18 <dolphm_> legacy makes more sense, it's now the exception 18:06:21 <ayoung> it seems that the migrate.cfg isn't getting into the right place, and both of those tickets are surrounding it 18:06:29 <bcwaldon> can't we just invalidate legacy bugs? 18:06:38 <bcwaldon> there is no codebase in which to fix them 18:06:43 <dolphm_> or tagging them with a more specific release / milestone 18:06:48 <heckj> bcwaldon: we pretty much did such that for quite a number of them 18:07:19 <heckj> bcwaldon: some of them are related to the V2 API which isn't clear - part of our topic for later this meeting 18:07:36 <bcwaldon> kk 18:07:39 <bcwaldon> moving on 18:07:51 <anotherjesse> dtroyer has been doing a lot of work filing new bugs 18:08:18 <heckj> he's also been cranking on fixes for a number of them :-) Really good work dtroyer! 18:08:35 <dtroyer> thanks 18:08:52 <heckj> #action heckj - mark all existing (non-redux) bugs as legacy with tags 18:09:10 <heckj> We'll stop using redux for new tags, and I'll mark through the exceptions 18:09:27 <heckj> ayoung - were you good on the bugs related to the migrate.cfg for packaging? 18:09:39 <dolphm_> i don't think there are any remaining legacy bugs 18:09:45 <ayoung> heckj, still don't know exactly what the right fix is 18:09:49 <dolphm_> but new ones will surely appear 18:09:52 <ayoung> we are getting close 18:10:22 <heckj> #topic triaging bugs going forward 18:10:33 <termie> MARK ALL BUGS AS INVALID 18:10:45 <termie> and we'll just fix things if they get submitted often 18:10:49 <heckj> heh 18:11:07 <bcwaldon> #seconded 18:11:07 <termie> alright, only a randomly selected 50% of bugs each week 18:11:13 <bcwaldon> #seconded 18:11:27 <anotherjesse> ok, back to the meeting 18:11:33 <heckj> My point was more that "is anyone interested in helping define the priority"? 18:12:00 <heckj> I can take a swag at it to start, and you all can yell at me if you disagree for a first step, but I wanted to be inclusive in that delightful process if anyone wanted to step up there 18:12:02 <dolphm_> priority of new bugs? or what 18:12:57 <heckj> silence == agreement then? 18:13:00 <termie> my general thoughts on priority: critical == blocker, anything else but low == we should do this, low == nice to have 18:13:02 <littleidea> heckj: you are looking for principles to prioritize by or volunteers? 18:13:19 <anotherjesse> E4 is 10 days away 18:13:22 <heckj> volunteers - I'm right with termie on philosphy 18:13:33 <termie> i'm often more concerned about naming the bugs appropriately, it can be pretty narly trying to remember what all the misnamed bugs really are 18:13:52 <termie> s/narly/gnarlh/ 18:13:54 <termie> ... 18:13:55 <heckj> termie - and convention you want to stick with that would make it easier>? 18:13:56 <dolphm_> there's also wishlist for nice to have 18:13:57 <anotherjesse> termie - agree - updating bug titles is important 18:14:08 <termie> heckj: no convention, just try to clean them up when prioritizing 18:14:21 <termie> heckj: if they seem low on info or relevance 18:14:39 <dolphm_> like "keystone does not start" 18:14:47 <heckj> kk - I'll see what I can do when going through them. If you want to volunteer to help with that effort, ping me. 18:14:58 <heckj> dolphm_ yeah I liked that one 18:15:09 <termie> i'll be going through them all to take a look today also to catch up 18:15:14 <dolphm_> == "RHEL packaging?" 18:15:17 <dolphm_> or something 18:15:26 <heckj> I'm aiming to do a triage weekly going forward 18:15:31 <termie> dolphm_: yeah 18:15:41 <ayoung> RHEL packaging one should probably be fixed with my LDAP patch 18:15:46 <littleidea> how about if there is too much for you to handle, you ping someone 18:15:48 <heckj> termie - wait until you see the keystone+horizon bug that devin and im root went on about yesterday, very amusing from the side 18:15:50 <ayoung> as what is missing is the pip include for ldap 18:16:03 <termie> yeah 18:16:05 <termie> just renamed it 18:16:10 <heckj> littleidea - oh, don't worry - I'll be screaming if I need help 18:16:20 <littleidea> :) 18:16:37 <heckj> #topic - status of current work 18:16:51 <heckj> Dolph - how's XML coming along (then I'll ask ayoung about LDAP) 18:16:55 <dolphm_> xml support proposed -- needs reviews 18:17:08 <heckj> termie - that's one I'd really like your eyes on 18:17:13 <dolphm_> https://review.openstack.org/#change,4297 18:17:54 <ayoung> dolphm_, is there a good way to test from, say curl? 18:18:08 <anotherjesse> dolphm_: are you using the soapui stuff? 18:18:14 <dolphm_> ayoung: yep, just -H 'Accept: application/xml' 18:18:16 <termie> i'll be pretty much on reviews and bugs all day, so yeah, your xml patch is on deck 18:18:20 <dolphm_> anotherjesse: no, it's all python 18:18:26 <ayoung> dolphm_, sounds good. I can give it a once over as well 18:18:54 <heckj> ayoung: LDAP work? 18:19:02 <heckj> #link https://review.openstack.org/#change,4331 18:19:05 <ayoung> so LDAP code has been submitted for review 18:19:06 <anotherjesse> dolphm_: related to the xml, are you also working on the WADLs -> docs.openstack.org? 18:19:20 <ayoung> the most questionable piece is probably the inclusion of the modules 18:19:21 <heckj> Oops - sorry, didn't wait long enough 18:19:28 * ayoung waits 18:19:35 <dolphm_> anotherjesse: i've been working with anne on that, i think she's taking over the bug though 18:19:48 <anotherjesse> cool - go on ayoung 18:20:00 <dolphm_> i'm helping her with the merge, she's organizing it all, etc 18:20:14 <ayoung> so the modules are, as I see it, the contract of the documentation of the objects returned from the Identity API 18:20:25 <ayoung> we need to document that somehow, and doing it in code is prefered 18:20:50 <ayoung> but the SQL etc Identity backends don't use that code. 18:21:21 <termie> ayoung: is there a piece of code you are referring to specifcially? i haven't looked at your patch in review yet 18:21:21 <heckj> ayoung - sorry, I'm being dense - can you give me a reference or link to the "modules" - I'm not sure what that means 18:21:29 <ayoung> Also, I need to submit at least one small update to the LDAP patch, to make the LDAP calls go via a threadpool 18:21:44 <ayoung> termie, the file in the patchedcode is 18:21:55 <anotherjesse> termie: it seems like identity backends don't have a list_tenants - intended (or should I file a bug?) 18:22:04 <ayoung> keystone/identity/models.py 18:22:30 <dolphm_> anotherjesse: i think dtroyer proposed a patch for that? 18:23:14 <ayoung> heckj, the modules.py file was in the old keystone code base 18:23:21 <ayoung> my version looks like this 18:23:34 <ayoung> http://fpaste.org/PkT6/ 18:24:38 <ayoung> hmm, might have had git issues, that file looks larger than what I had...let me find the right version 18:24:43 <dtroyer> anotherjesse: get_tenants_for_token is what list_tenants should do, but without the tenant filter 18:24:55 <heckj> ayoung: I'm not entirely sure we care so much about that original setup, that seems to be a hold-over of an older application structure. Am I missing something? 18:25:07 <ayoung> https://github.com/admiyo/keystone/blob/ldap4/keystone/identity/models.py 18:25:08 <anotherjesse> dtroyer/termie: I'll look up what I was thinking 18:25:13 <termie> dtroyer, anotherjesse: talking about doing both of those was discussed a bit previously, to support legacy behavior 18:25:19 <ayoung> heckj, thing is, we need to document what you get back from get_user 18:25:46 <termie> dtroyer, anotherjesse: i think gabriel hurley was going to go add the list_tenants version in addition to the get_tenants_for_user 18:26:02 <anotherjesse> termie: I'm referring to backend api, not http api 18:26:08 <termie> anotherjesse: i know 18:26:13 <anotherjesse> will discuss in #openstack-dev after meeting 18:26:19 <ayoung> heckj, otherwise, if you want to add a new backend you need to reverse engineer it from the SQL alchemy code, which is wrong 18:26:22 <termie> anotherjesse: there are two different backend paths for the same frontend call depending on context 18:26:40 <termie> ayoung, heckj: agreed, we've discussed this before, is it a bug yet? 18:26:42 <dtroyer> termie: I proposed a get_tenants_for_user yesterday. My list_tenants (equivalent) depends on some other props to land first 18:26:51 <heckj> termie - I think it is 18:26:52 * heckj looks 18:26:56 <ayoung> termie, no. The change should be going in the LDAP code to start 18:27:19 <termie> dtroyer: you propossed get_tenant_by_name perhaps? get_tenants_for_user already exists 18:27:26 <ayoung> er...actually, yes it is a bug. 18:27:59 <heckj> #link https://bugs.launchpad.net/keystone/+bug/928441 18:28:01 <heckj> found it 18:28:02 <uvirtbot`> Launchpad bug 928441 in keystone "document base model types for key elements within Keystone API" [High,Confirmed] 18:28:02 <ayoung> termie, so is adding the models.py file OK, and we'll just use that as a startuing point for the other stuff? 18:28:05 <dolphm_> .mkv 18:28:06 <termie> dtroyer: https://github.com/openstack/keystone/blob/master/keystone/identity/core.py#L127 18:28:16 <dolphm_> (wrong window) 18:28:46 <termie> ayoung: sure, but it'll probably get ignored until there is something actually using it (if it is only for doc purposes) 18:28:56 <ayoung> termie, LDAP code uses it 18:29:14 <termie> ayoung: then what is the question? 18:29:20 <dtroyer> termie: then it was get_users_for_tenant… too little sleep... 18:29:23 <termie> ayoung: will be part of your review, no? 18:29:29 <ayoung> termie, yes 18:29:39 <heckj> Let's call it good there - 18:29:40 <termie> ayoung: then we'll sort it htere 18:29:47 <ayoung> OK 18:29:58 <heckj> so state for XML and LDAP is both are under review and moving forward 18:30:20 <anotherjesse> with the goal of landing before E4? (Mar 1) 18:30:31 <heckj> ideally 18:30:46 <heckj> #topic - E4 18:31:19 <heckj> So related there - E4 is coming up damn quick, and I'd like to have us all focus exclusively on bug fixes and doc updates in E4. Any qualms? 18:31:31 <heckj> Call it a feature freeze on the code side after E4? 18:32:06 <ayoung> IPv6 is probably not going to be E4 ready, as it is dependant on an Upstream eventlet change. Recommend we postpone it. 18:32:24 <ayoung> upstream eventlet change that is not yet submitted upstream, that is 18:32:30 <heckj> ayoung - is that linked as a bug? blueprint? 18:32:34 <anotherjesse> ayoung: I agree since if someone needs ipv6 they can use an http proxy? 18:32:34 <heckj> (I agree, btw) 18:32:42 <ayoung> heckj, it is in the IPv6 bug 18:33:02 <anotherjesse> (and it is the same issue for all the other openstack components) 18:33:27 <heckj> ayoung: retagged it to folsom-1 18:34:13 <heckj> any qualms with "feature freeze" for Essex4+? (going twice) 18:34:49 <termie> nope 18:34:50 <heckj> #agreed keystone to feature freeze - exclusive focus on bugs and docs for post essex4 milestone 18:35:07 <heckj> #topic tenants & users - should all 'users' have a default client 18:35:18 <anotherjesse> do you mean default tenant? 18:35:34 <termie> we've discussed default tenant quite a bit on my team and we've wanted it since pretty much day one 18:35:37 <heckj> Yeah - and the expected and needed interactions between all these guys. 18:35:57 <anotherjesse> right now horizon doesn't expect a default tenant to exist 18:36:06 <termie> we pushed off doing it pre-merge so as not to mess with stuff, but i think we'd still like it 18:36:07 <heckj> Key question - does anyone know of a use case where you'd want to have a user *without* a tenant, let alone a default tenant? 18:36:23 * termie looks at dolphm_ 18:36:27 <anotherjesse> heckj - you can have a backend (like LDAP) where you don't know the default tenant 18:36:37 <anotherjesse> heckj - if you are mapping into an existing LDAP/AD/... 18:36:51 <termie> in practice people are selecting the first tenant from a list in those cases 18:37:21 <heckj> anotherjesse: is that a desired feature though? Why would you want to auth them to do anything if they weren't related to a block of "ownership of resources" (what I think a tenant represents)? 18:38:13 <anotherjesse> termie: it could be that there is no tenant (you are backending to a corporate LDAP - you have a user — but no tenant memberships exist for you yet) 18:38:32 <anotherjesse> I think we want to design it so a user could come back with no tenant membership 18:38:39 <anotherjesse> which wouldn't let them do much 18:38:43 <anotherjesse> but wouldn't blow up 18:38:55 <termie> anotherjesse: that seems opposite to your previous statements 18:39:12 <ayoung> anotherjesse, you mean where you are pulling in a large user list from some external identity mangement system? 18:39:14 <termie> anotherjesse: do you have a use case for a non-tenanted user? 18:39:16 <dolphm_> this all makes more sense to me if you can have a list of default tenants, and tokens can be scoped to multiple tenants as well 18:39:28 <heckj> anotherjesse: that's not a great UX for the user - it means someone else has to intervene to get them functional. I think we should ideally default to a flow that gets someone functional right off the bat, or deny then auth. 18:39:31 <dolphm_> but that doesn't fit the spec at all 18:39:55 <anotherjesse> let's move this to the mailing list? 18:40:03 <anotherjesse> or #dev after the meeting 18:40:31 <heckj> anotherjesse: want more time to think on it? 18:40:47 <anotherjesse> heckj: let's talk in #dev in 20 minutes 18:41:00 <heckj> I'd like to try and drive to some conclusions pretty quick here, as the docs are incomplete here, and there are bugs that are dependent on the answers 18:41:09 <heckj> anotherjesse: Ok, I'm good with that 18:41:35 <heckj> #action: resume discussion in #openstack-dev after meeting 18:41:48 <heckj> last topic - 18:42:02 <heckj> (Am I going to fast for folks?) 18:42:14 <bcwaldon> nope, you're fine 18:42:15 <dolphm_> nope 18:42:18 <heckj> #topic collection of use cases - designing v.Next 18:42:29 <dolphm_> yay 18:42:37 <heckj> I started a wiki page to collect use cases 18:42:39 <heckj> #link http://wiki.openstack.org/KeystoneUseCases 18:42:58 <heckj> termie and I are both in agreement we want to keep this as close to rubber on the road as possible 18:43:26 <heckj> I'm hoping that using this as a baseline, we can drive out more discussion at the Design Summit on the next gen of the API and the key constructs 18:44:04 <anotherjesse> heckj we need to add one about adding an experimental/third party service - and supporting it without giving it complete power to do everythign (eg if we send it a user token, they can send it to all the other services and act as the user) 18:44:19 <anotherjesse> (service = new cloud service to the catalog) 18:44:50 <heckj> For some of the fundamental changes that were originally planned in essex, there were side-effects that I don't think were clearly communicated to all the other projects (nova, glance, swift, horizon). My goal is to have a basis to do that at the summit, talking in concrete terms 18:45:04 <heckj> anotherjesse: can you add that in to the wiki page? 18:45:14 <anotherjesse> sure 18:45:18 <heckj> or send me an email with the details, and I can pester you until I understand and I'll add it :-) 18:45:38 <anotherjesse> it is in the folsom summit topics as "Trust & Service" 18:45:44 <anotherjesse> it does need fleshed out 18:46:03 <heckj> anotherjesse: I think that's reasonably well defined in your head, and at the moment, not at all in mine 18:46:13 <termie> heckj: nice 18:46:33 <anotherjesse> heckj - perhaps we should focus on these post march 1st? 18:46:39 <heckj> ayee also has the desire for a domain (the HP domain thing from earlier) that I needs to get nailed down into more concrete terms 18:46:58 <anotherjesse> heckj - you mean gyee 18:47:02 <anotherjesse> ? 18:47:03 <heckj> anotherjesse: good by me - just wanted to start the ball rolling for anyone interested in looking forward 18:47:11 <heckj> anotherjesse: ^^ gyee, yes, sorry 18:47:15 <heckj> (crappy typist) 18:47:58 <anotherjesse> general discussion time? 18:48:20 <heckj> #topic - open discussion 18:48:27 <gyee> I was half way there, implementing domains for the fat Keystone, till KSL came along 18:48:29 <gyee> :) 18:48:39 <heckj> anotherjesse: made a quick note in the wiki so I wouldn't forget it 18:48:51 <heckj> gyee: yeah, sorry about that. 18:49:16 <anotherjesse> notmyname just gave https://review.openstack.org/#change,3712 a +2 (that is dtroyer's patch for common keystone configuration of cli tools) 18:49:44 <anotherjesse> anyone been around swift enough to know if they wait for another +2 before approval? 18:49:54 <notmyname> yes they do 18:50:23 <anotherjesse> cool - was going to ask if we knew anyone else to reach out to, to get the other review ;) 18:50:40 <gyee> btw, we do have SSL hookup for the LDAP backend right? 18:50:46 <heckj> gyee: I know there was prior discussion on domains, but it's very wide impacting and needs to be discussed with it's impact to the broader project. I'm concerned that the impact flow into other projects isn't well understood or represented as (blueprints) in those projects (nova, swift, glance, etc). 18:51:00 <heckj> gyee: take a look at ayoung's code in https://review.openstack.org/#change,4331 18:51:06 <gyee> k 18:51:26 <ayoung> gyee, not yet 18:51:29 <anotherjesse> notmyname: do you have a recommendation of who we can ask to review the cli patch? 18:51:41 <ayoung> first hack is using LDAP, Have not test ldaps 18:51:52 <gyee> ayoung, SSL is a must have, LDAP cache is good to have since LDAP data are highly static 18:52:21 <notmyname> anotherjesse: nothing more specific than "any of the other core devs" 18:52:21 <ayoung> gyee, I'll give it a test. Need to set up my openldap setup for ldaps. THink it should work 18:52:59 <heckj> notmyname: put more bluntly, can we ask for your help in digging up another core reviewer? 18:53:06 <anotherjesse> notmyname: can you ask in your swift channel - we would like essex to have a standard way of configuring clients and I know you guys do releases a little different - so the sooner the better :) 18:53:14 <notmyname> heckj: heh 18:53:26 <notmyname> ya, I'll ask the other devs to take a look :-) 18:53:34 <anotherjesse> thanks! 18:53:37 <heckj> notmyname: thank you! 18:54:25 <anotherjesse> has anyone reached out to the fedora guys about packaging? 18:54:45 <termie> not i 18:54:46 <anotherjesse> chuck is already working on it for ubuntu 18:54:49 <heckj> I've been talking with Josh Harlow a bit - can reach out to Kiall 18:55:00 <heckj> I don't know who's really doing that side of the work though 18:55:12 <heckj> (also submitted a few packaging patches to chuck yesterday) 18:55:26 <anotherjesse> heckj - markmc might be a good person to ask 18:55:29 * zul ears perk up 18:55:31 <heckj> anotherjesse: do you know who to contact? 18:55:36 <heckj> ^^ thanks 18:55:37 <uvirtbot`> heckj: Error: "^" is not a valid command. 18:55:43 <heckj> damn bot 18:56:05 <heckj> zul: just tossed you a few patches to look at re: packaging - actually on several projects 18:56:21 <zul> heckj: yep they all got merged this morning 18:56:43 <heckj> Oh - sweet. 18:57:06 <heckj> Anything else? Anyone else? 18:57:14 <anotherjesse> so - resume talk in #dev about default tenants in 5 minutes (bio break) 18:57:18 <termie> k, i am about to adjourn from this to go talk about default tenants with jesse so we can have something for the channel 18:57:21 <heckj> sounds good 18:57:29 <termie> (after bio, not during) 18:57:41 <heckj> Thanks all - if you want something in the agenda for next week, ping me. 18:57:44 <heckj> #endmeeting