19:01:16 <notmyname> #startmeeting swift
19:01:17 <openstack> Meeting started Wed Feb 20 19:01:16 2013 UTC.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:20 <openstack> The meeting name has been set to 'swift'
19:01:35 <notmyname> I've got a short agenda for this week:
19:02:02 <notmyname> report from chmouel about what he has found about keystone and details of changes (if any) needed
19:02:05 <notmyname> summit talks
19:02:09 <notmyname> and any open questions
19:02:23 <notmyname> I've got to be done in 30 minutes
19:02:33 <notmyname> #topic keystone v3 changes?
19:02:40 <notmyname> chmouel: what do you have for us?
19:02:57 <chmouel> so henrynash was kind of enough to send a message resuming the problem
19:03:01 <chmouel> available here http://pastie.org/private/ndyxib6ire3y2bbxvqim4q
19:03:10 <chmouel> from the look of it i don't think this is going to cause problem
19:03:15 <chmouel> it only acls works
19:03:24 <chmouel> and that should be backward compatible
19:03:56 <notmyname> ok, so we may have some patches to the keystone middleware, but nothing beyond that?
19:04:06 <chmouel> that's correct AFAICS
19:04:18 <notmyname> great. I think that's the right answer anyway :-)
19:04:51 <notmyname> anyone have any questions/comments?
19:05:08 <davidha> chmouel: now thatther eare projectId and domainID in keystone - which will map to an account?
19:05:45 <chmouel> davidha: I believe the projectid would do since they are unique
19:05:47 <clayg> should still be tenant's (now called projects)
19:05:50 <dolphm> chmouel: +1
19:05:58 <clayg> ohai dolphm!
19:06:01 <dolphm> clayg: o/
19:06:05 <chmouel> here is THE man speaking!
19:06:10 <clayg> lol
19:06:11 <davidha> +1 projectID == account
19:06:19 <davidha> is domain a reseller prefix?
19:06:39 <chmouel> that i am not totally sure since they have different use
19:06:41 <notmyname> no. the reseller prefix is swift-specific
19:06:42 <clayg> davidha: don't go involving swift terms like reseller prefix in keystone - it'll just get confusing :P
19:06:47 <notmyname> heh
19:07:07 <davidha> ther eis a concept pof domains in keystone v3
19:07:19 <davidha> differen tpepole think differently about it
19:07:21 <clayg> "pof"?
19:07:22 <chmouel> we could potentially have urls which include domains
19:07:32 <chmouel> and the default would be the same as now
19:07:41 <chmouel> (default being as well keystone domain default)
19:07:54 <clayg> chmouel: as long as the auth middleware is doing the remapping, the url of the data makes a difference to the ring, there's shoudln't be a data migration
19:08:13 <notmyname> keystone can map their users to swift endpoints however they want, but the important point is that it doesn't affect anything in swift
19:08:15 <davidha> Is the use pepole do with reseller prefix essentially different from whet domains will be in keystone?
19:08:33 <chmouel> clayg: well not for the domain specifics domains which woudl not need migration
19:08:35 <notmyname> davidha: ya. a reseller prefix is for swift deployments with more than one auth system
19:08:36 <chmouel> since introduced in v3
19:09:05 <chmouel> clayg: i mean domain specifics urls
19:09:07 <clayg> "doamin specifics domains"!?
19:09:16 <dolphm> i'm concerned that swift acl's wont be able to support two projects with the same name - yes it looks like it'll correctly detect that the second project is a mismatch, but that's not the same as supporting it
19:09:32 <davidha> notmyname: I am not saying anything should change in swift - but maybe the keystone middleware should have an option for mapping keystone domains to reseller prefix
19:09:40 <clayg> chmouel: oh... like *another* swift account for the domain globally instead of "just" a project?
19:09:41 <dolphm> (i'm reading the link above)
19:10:14 <chmouel> well no, but the way I sees it it's by default we have:
19:10:20 <clayg> davidha: I think that would overload what swift currently does with reseller prefix, and cause problems for people using more than one authorizer to their swift cluster
19:10:26 <chmouel> http://url/AUTH_tenantid
19:10:29 <clayg> ... but may there's room in the middle
19:10:32 <chmouel> and if we are getting from auth_token a domain
19:10:33 <notmyname> dolphm: the ACLs are opaque to swift and only matter to the auth middleware. if that needs to change to better match keystone v3, that's ok
19:10:42 <dolphm> notmyname: cool
19:10:45 <chmouel> we can have instead http://url/AUTH_tenantid@domain
19:10:53 <chmouel> or whatever url
19:11:07 <davidha> chmouel: are you sure that projectID is unqie between ketstone domains?
19:11:10 <notmyname> dolphm: the only concern (and mostly on the keystone side rather than swift) is that there is a migration path
19:11:13 <dolphm> davidha: yes
19:11:20 <chmouel> it's uuid
19:11:32 <davidha> such that we do not have domain1-project_jack and domain2-project-jack
19:11:44 <clayg> chmouel: how would the @doamin disambiguate the globally unique teantid?  AUTH_tenantid@a_different_domain wouldn't make any sense to me?
19:11:52 <davidha> chmouel: well there is a project name and ther eis a uuid
19:12:01 <davidha> the project name I think is not unique
19:12:09 <chmouel> davidha: it's not using project_name but only project_id
19:12:20 <clayg> chmouel: +1
19:12:37 <clayg> that's KEY
19:12:37 <davidha> Maybe the middleware should ofer more than option for mapping to solve different use cases
19:12:38 <dolphm> names are user-defined in keystone, and now may conflict across domains; ID's are UUID's provided by keystone and therefore safe to use unencoded in URL's and stuff
19:12:38 <clayg> ;)
19:13:06 <chmouel> yep using the tenantid would ensure uniqueness and no conflict
19:13:21 <clayg> davidha: enumerate the use cases, if there's something missed there's probably time to fill the gaps
19:13:21 <davidha> if account  = project uuid - we loose this nice swift charactaristic that users can define their URLs
19:13:38 <chmouel> davidha: well it never was able with keystoneauth
19:13:44 <caitlin-nexenta> UUIDs might be unique, but no user is going to want to enter them in an ACL.
19:14:06 <chmouel> because keystone could not give have endpoint url wiht %(tenant_name)
19:14:12 <dolphm> caitlin-nexenta: i'd personally like to make the default ID length configurable to ease that
19:14:13 <chmouel> only tenant_id
19:14:31 <davidha> AUTH_TEST/y387437434632643648736487326487364/mycontainer/myfile is not as good as AUTH_TEST/myaccount/mycontainer/myfile
19:14:32 <chmouel> dolphm: +1
19:14:52 <chmouel> davidha: well i think there is the keystone side to fix first if we wanted that
19:15:18 <chmouel> but i think we may work on that further when the v3 imp is stable
19:15:35 <notmyname> dolphm: so it sounds like there are a few things to discuss, but those will probably come up in patches to the keystone middleware. correct?
19:15:37 <davidha> chmouel: unless we use domain = prefix ,  such that the project ud becomes unique within that prefix - this still can allow using adifferent prefix to direct to a different auth system
19:15:55 <dolphm> notmyname: i think so
19:16:02 <davidha> (or that we have a configuration option for the middleware mapping - both are fine)
19:16:06 <dolphm> notmyname: auth_token isn't consuming v3 yet anyway
19:16:18 <chmouel> davidha:  yes but prefix has not been designed to do that
19:16:28 <notmyname> ok. I think that would be our timeframe
19:16:42 <notmyname> dolphm: is that anticipated before girzzly or in H?
19:17:17 <davidha> notmyname: I also think it is all solvable in the middleware
19:17:30 <dolphm> notmyname: H
19:17:36 <notmyname> dolphm: ok.
19:17:38 <chmouel> davidha: +1
19:17:39 <notmyname> let's move on then
19:17:47 <notmyname> #topic summit talks
19:18:06 <notmyname> submissions for talks in the swift track (and all the others) are open at http://summit.openstack.org
19:18:24 <davidha> This will probably my first visit to portland :)
19:18:33 <notmyname> if you have something to talk about (code, designs, other technical content), please submit a talk
19:18:41 <chmouel> done!
19:18:49 <cschwede> is this still open?
19:18:50 <notmyname> the goal is not for presentations (lectures) but for conversations
19:19:07 <davidha> notmyname: deadline for submitting items?
19:19:27 <cschwede> @notmyname: ah, ok.
19:19:38 <notmyname> I don't know the deadline, but it should be after the PTL elections, I'd imagine (since the PTLs set the schedules)
19:19:53 <notmyname> so I'd guess you have a few weeks
19:20:30 <notmyname> any other questions about the summit?
19:20:59 <notmyname> #topic open discussion
19:21:18 <notmyname> any other issues that need addressing? patches that need discussion that can't happen in gerrit?
19:21:36 <davidha> I would need some assistance and guiding reg doubling the ring
19:22:24 <davidha> any volenteers?
19:22:56 <torgomatic> davidha: I should have some time to start looking at patches again soon
19:23:09 <davidha> torgomatic: Thanks
19:23:24 <notmyname> I'd like to see if your latest patch set addresses the concerns gholt has (his -2 is still there)
19:23:25 <torgomatic> I've been quite busy with other, non-Swift stuff, but that should be slowing down soonish
19:23:41 <notmyname> torgomatic: not slower, just refocused on swift things :-)
19:24:10 <davidha> notmyname: gholt indicted later that he think the ideas in the patch seem to address teh main isues
19:24:22 <davidha> but it is not a done deal yet
19:24:29 <notmyname> davidha: ya, I remember seeing something like that
19:24:59 <notmyname> he's not in here, so someone who sits near him at RAX should ask him if his -2 still stands
19:25:23 <clayg> davidha: gholt's last comment seemed to just be "please set this to work in progress" - which is a neat trick for patches you're still making changes too
19:25:27 <notmyname> davidha: if your patch is still a work in progress, cna you please mark it as such
19:25:37 <notmyname> ya. what clayg said :-)
19:25:46 <redbo> I think he meant gholt's comments on the blueprint
19:25:53 <clayg> oh yeah those!
19:26:09 <clayg> for the love of god just link an etherpad.openstack.org and get off that horrid thing
19:26:10 <davidha> yes on the blueprint
19:26:58 <notmyname> any other things to bring up today?
19:27:17 <cschwede> I'd like to know if someone is interested in a shared container approach (ie you see shared containers from other users and access them with your own storage URL). I have a working draft and would appreciate any comments
19:27:38 <chmouel> would be nice if we can get https://review.openstack.org/#/c/21563/ reviewed
19:27:52 <notmyname> cschwede: interesting. as something different than ACLs?
19:27:52 <chmouel> cschwede: what would be different to ACLs ?
19:28:13 <caitlin-nexenta> Who would control access to a shared container?
19:28:14 <cschwede> no, using current acls. We will use it as an internal dropbox for large data sets
19:28:47 <notmyname> cschwede: have you published your draft anywhere?
19:29:10 <davidha> cschwede:  what does it add beyond what can be done today with ACLs
19:29:12 <davidha> ?
19:29:18 <cschwede> @chmouel: you see shared containers in your container listing, without need for the storage url from other users
19:29:51 <cschwede> @notnmyname: https://github.com/cschwede/swift-containerlist
19:29:52 <chmouel> cschwede: so is that .rlistings on ACLs ?
19:30:16 <clayg> chmouel: can you set .rlisting on your account
19:30:24 <chmouel> clayg: oh correct
19:30:26 <cschwede> @davidha: easier to use for your users
19:30:58 <chmouel> but isn't that something that can be extended in auth middlewares/acl.parse_acl?
19:31:29 <clayg> cschwede: I think it's as least an interesting idea as allowing keystone domain & project names in the url instead of tenant_id's
19:32:18 <cschwede> sorry, I meant containers from other accounts, not other users
19:32:28 <notmyname> unfortunately, I've got to run now. there's nothign scheduled in here for the next 30 minutes, so please keep discussing if you'd like
19:32:45 <clayg> I've acctually noted that not having a way to enumerate a users's permissions is sort of a hassle from a design perspective
19:32:49 <notmyname> cschwede: I'd also suggest getting feedback from devs in #openstack-swift or comments on the mailing list
19:33:06 <chmouel> clayg: +1
19:33:13 <notmyname> next meeting in two weeks
19:33:15 <notmyname> #endmeeting