20:00:57 <jraim> #startmeeting barbican 20:00:57 <openstack> Meeting started Mon Feb 17 20:00:57 2014 UTC and is due to finish in 60 minutes. The chair is jraim. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:00 <openstack> The meeting name has been set to 'barbican' 20:01:09 <jraim> Alright, who all is here for the barbican meeting? 20:01:10 <reaperhulk> o/ 20:01:13 <jvrbanac> o/ 20:01:16 <redrobot> o/ 20:01:40 <jraim> hgedikli1: you around? 20:01:41 <kris_h> o/ 20:01:54 <jraim> chadlung codekobe 20:02:20 <hockeynut> o/ 20:02:37 <codekobe> o? 20:02:39 <chadlung> o/ 20:02:41 <codekobe> o/ 20:02:43 <SheenaG> o/ 20:02:53 <jraim> codekobe: shouldn't you be rearing your child? :) 20:02:56 <jraim> or sleeping 20:03:00 <dstufft> o/ 20:03:10 <reaperhulk> Yeah, can that kid code yet or what. She's gotta earn her keep. 20:03:15 <hockeynut> ZZZzzz,,,… 20:03:19 <codekobe> haha i logged on to out baby on my insurance, and still had irc open 20:03:30 <chadlung> <codekobe> Diapers, go change diapers and get off IRC 20:03:36 <codekobe> bye! 20:03:37 <lisaclark1> o/ 20:03:40 <woodster2> see ya 20:03:48 <jraim> Now that he's gone, we can get started :) 20:03:51 <dstufft> Maybe codekobe needs diaper changing put on scrumdo :3 20:03:53 <jraim> Here is the agenda I have for today 20:03:57 <jraim> * devstack gate integration 20:03:57 <jraim> * containers status 20:03:57 <jraim> * rub-tenant rbac 20:04:07 <jraim> #topic devstack 20:04:19 <jraim> Alright, I think we have this pretty locked down now 20:04:36 <jraim> #action jraim to talk with TC to see if the current code is right, or if we need to change to using solum's approach 20:04:37 <jraim> correct? 20:04:46 <chadlung> correct 20:04:57 <jraim> easy one 20:04:59 <chadlung> Solum like changes for us can be seen here: https://gist.github.com/chadlung/8964037 20:05:14 <jraim> #link https://gist.github.com/chadlung/8964037 20:05:30 <chadlung> Otherwise, like Marconi we do this: https://git.openstack.org/cgit/openstack-infra/devstack-gate/commit/?id=0d9f4f37d689fbab89980a49155dc328a012c50c 20:05:33 <jraim> cool. I'll try to get an answer today 20:06:16 <jraim> anyone have a preference on approach? Chad and I have been leading towards the marconi way as it doesn't require us putting devstack code in our repo 20:06:24 <lisaclark1> chadlung: once we have the decision, you still have about 30 min of work and a PR to submit? 20:06:28 * reaperhulk is agnostic. Whatever way they want 20:06:56 <redrobot> my preference would be for the TC and the DevStack folks to get on the same page :) 20:06:59 <chadlung> <lisaclark1> yes, either PR won't take me long to do. Its more just then waiting for approval and making any further changes they want 20:07:09 <reaperhulk> If they don't care then let's keep devstack out of our repo I guess? 20:07:23 <jraim> that's my thinking, let's see what they want 20:07:41 <jraim> #topic containers 20:07:45 <woodster2> as long as they are cool with having a stackforge project in the mix, Marchoni seems like the easiest way 20:08:01 <jraim> So I think we are getting close on landing this? 20:08:05 <jraim> hgedikli1: you around? 20:08:06 <chadlung> the namespace I think would be an issue, but thats just a guess 20:08:28 <reaperhulk> I think we're missing hgedikli1 today, but I can provide a status update 20:08:36 <jraim> go for it 20:09:23 <reaperhulk> hgedikli1's containers PR is mostly ready now. We've settled on an immutable approach that only handles the current case (RSA) but is extensible for other fixed set groupings. We'll have to revisit this for arbitrary groups, but that's okay. 20:09:32 <reaperhulk> There is one outstanding TODO in the current PR, so we need that to be resolved 20:09:59 <jraim> reaperhulk: anything large? 20:10:01 <reaperhulk> atiwari has a -1 on it as well at the moment, but I'm not sure I agree with his objections (or at least I believe they are better addressed in a future PR) so if all goes well hopefully we can land containers tomorrow 20:10:15 <reaperhulk> No it's a small todo 20:10:19 <jraim> atiwari doens't appear to be online now 20:10:42 <jraim> okay, let's see if we can get it landed soon as IIRC it is blocking some other work on asym 20:10:58 <jraim> everyone else okay with landing the work with the last todo fixed? 20:11:21 <woodster2> lgtm 20:11:24 * redrobot is behind on that review 20:11:32 <jraim> alright, let's move on to the last agenda item 20:11:39 <jraim> #topic sub-tenant rbac 20:11:48 <jraim> so we have a question from someone named kfox 20:11:54 <jraim> who doesn't appear to be online now 20:12:05 <jraim> about limiting access to secrets to individual users (or agents) 20:12:17 <jraim> I've thought about this a bit with respect to the postern work 20:12:24 <jraim> but it hasn't gotten past PoC stage 20:12:41 <jraim> the issue seems to be that keystone doesn't really seem to offer any low level access control options 20:12:55 <jraim> so if we want to offer it, we'll need to work with them and / or build something oursleves 20:13:09 <woodster2> was that one purpose of that tenant-secret relationship in barbican? 20:13:13 <jraim> anyone have thoughts on this? something we want? should it be in keystone? or do we need to do it? 20:13:27 <redrobot> my thoughts on this issue is that authZ/authN belongs in Keystone, not Barbican. I think the keystone model is flexible enough to allow any possible scenario you can think of 20:13:51 <redrobot> kfox's questions was not necessarily that Barbican needs it, but rather wanting a guideline on how to approach his scenario 20:14:04 <jraim> so all secrets should be owned by a tenant, they question is if we could allow limited access to a single secret to a particular user / agent without granting access to the rest of the secrets for that tenant/project 20:14:29 <jraim> redrobot: from what I can tell, keystone only allows access on a project level. 20:14:41 <jraim> so you woudl have to create projects for every secret grouping you wanted to share 20:14:45 <jraim> that seems like it would get cumbersone 20:15:07 <redrobot> jraim, yeah, it could also cause problems with cloud providers who don't have a flexible role/project setup 20:15:23 <jraim> it feels like the first step here might be to talk with the keystone folks to see if they have ideas on how we coudl do this 20:15:59 <chadlung> this seems like something that must've been brought up before with Keystone 20:16:05 <jraim> that's what I'm thinking 20:16:21 <jraim> I have some ideas, but it might be nice to see what dolphm and company think 20:16:52 <jraim> #action jraim to reach out to keystone team to see what they think about sub-tenant access control 20:16:57 <jraim> any other thoughts on this one? 20:17:23 <redrobot> maybe a wiki entry with ideal keystone/barbican configurations to achieve different scenarios would be helpful 20:17:34 <jraim> redrobot: that seems useful 20:17:42 <jraim> something to poke at 20:18:11 <jraim> cool. Anyone have any topics they like to bring up while we are all here? 20:19:05 <jraim> okay. Let's call this one. If you have topics you'd like on the agenda, toss me an email or hit me up in #openstack-barbican 20:19:07 <jraim> thanks all 20:19:11 <jraim> #endmeeting