16:07:23 <schwicke> #startmeeting hierarchical_multitenancy
16:07:24 <openstack> Meeting started Fri Jun 27 16:07:23 2014 UTC and is due to finish in 60 minutes.  The chair is schwicke. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:07:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:07:26 <raildo> no problem
16:07:27 <openstack> The meeting name has been set to 'hierarchical_multitenancy'
16:07:49 <schwicke> let's start with a review of the action items from the last meeting
16:07:55 <schwicke> #topic action items review
16:08:32 <schwicke> Sajeesh had a look at the blue print from you.
16:08:44 <schwicke> Me as well. I saw a couple of comments
16:08:55 <raildo> I included what was discussed at the last meeting in keystone-spec
16:08:58 <raildo> #link https://review.openstack.org/#/c/101017
16:09:08 <schwicke> excellent !
16:09:18 <schwicke> Did you recieve the document from Sajeesh ?
16:09:31 <raildo> no
16:09:55 <raildo> he don't send to me
16:10:56 <raildo> he didn't to me*
16:12:05 <schwicke> just wondering if he used an internal list. We need to check with him when he's connected
16:12:44 <schwicke> on his blue print there was one comment from a person saying that it depends on non-implemented features.
16:12:56 <schwicke> I think we should just point him to your blue print.
16:13:08 <Sajeesh> Hi
16:13:19 <raildo> hi Sajeesh
16:13:23 <Sajeesh> Sorry for beign late
16:13:27 <Sajeesh> hi raildo
16:13:30 <raildo> no problem
16:13:36 <schwicke> hi Sajeesh
16:13:52 <Sajeesh> hi shcwicke
16:13:53 <schwicke> we are reviewing the action items
16:13:58 <Sajeesh> ok
16:14:06 <schwicke> seems you did not send the document to Raildo, did you ?
16:14:18 <Sajeesh> no sorry
16:14:37 <schwicke> any objections to resend the latest draft ?
16:14:50 <Sajeesh> no problem
16:15:29 <schwicke> #AGREED: resend latest draft of the design document to Raildo
16:15:30 <raildo> Sajeesh: No problem, do you have any estimate of when you can send the document?
16:15:41 <schwicke> I will forward it to you nowish
16:15:49 <Sajeesh> just now
16:15:59 <raildo> great
16:16:49 <schwicke> did you receive it ?
16:17:23 <raildo> yes, I will read the document later.
16:17:35 <Sajeesh> https://review.openstack.org/#/c/102201/
16:17:42 <schwicke> ok, great. Sorry about taht
16:17:54 <Sajeesh> This is the latest blueprint
16:18:02 <raildo> no problem
16:18:18 <schwicke> raildo: let's discuss the document via e-mail when you have read it
16:18:53 <raildo> #action raildo make review of https://review.openstack.org/#/c/102201/
16:18:58 <raildo> schwicke: ok
16:19:18 <schwicke> Sajeesh: second action item was on you as well. Did you have any comments on raildos blue print ?
16:19:52 <schwicke> raildo: any comments from the community on your blue print that you want to discuss ?
16:19:54 <Sajeesh> Actually I wanted send a detailed mail to raildo
16:20:12 <Sajeesh> For the time being I want to ask about role inheritance
16:20:22 <schwicke> ok
16:21:07 <Sajeesh> what about overriding the roles
16:21:23 <schwicke> that is what we stopped at last week I think
16:21:26 <raildo> Haneef Ali asked a question:"Is this true for all the services? How about swift? Is Parent allowed to access child's container? How about neutron? Is parent allowed to open a firewall in child's network? ( child --> re-seller)"
16:21:34 <schwicke> #topic role inheritance
16:22:45 <raildo> schwicke: I believe that will work for all services provided there their contributions, correct?
16:23:18 <schwicke> yes, that is my understanding
16:23:25 <schwicke> these are actually very valid comments
16:23:25 <raildo> about role inheritance, Some members of my team started to implement the function on the list of inherited roles.
16:23:40 <schwicke> great!
16:24:18 <schwicke> I wonder if we can adress those questions if the child has a way to forbid the parent to do certain actions
16:24:50 <Sajeesh___> we have to see it
16:25:07 <schwicke> raildo: would that be difficult to implement ?
16:25:11 <raildo> schwicke:  what are the use cases?
16:26:05 <raildo> schwicke: i believe it would be simple to implement.
16:26:13 <schwicke> raildo: thinking about storage, if the parent would be allowed to access the childs storage that might be a problem for users who have some secrets there
16:26:46 <schwicke> for Nova it is possibly not that much of an issue I believe but for other services it may be relevant
16:27:07 <raildo> but it is not a little weird to a child have "powers" about his father?
16:27:21 <schwicke> So the default would be as decided but then the child could stop the parent from doing certain actions.
16:27:53 <schwicke> I see your point.
16:28:40 <schwicke> We could have the default to be open and everything inherited but allow the children to blacklist certain actions by the father
16:28:54 <raildo> for example, if I create an inheritable role, I hope he's inherited to all children (because that's how it works today).
16:29:27 <schwicke> yes
16:29:59 <schwicke> if the child decides to prevent you from doing something it is the responsibility of the child
16:30:07 <raildo> To be clear, we are not implementing inherited roles, because it is already implemented. we'll just list these roles.
16:30:48 <schwicke> sure
16:30:58 <Sajeesh> in sensitive organisations even certain projects and the users associated with those projecst are kept confidential
16:31:27 <Sajeesh> whether low level project can avoid that to happen by a top level use
16:31:32 <Sajeesh> whether low level project can avoid that to happen by a top level user
16:31:47 <raildo> I believe that his point can be discussed with the keystone guys, I will take this idea to them, ok?
16:31:59 <Sajeesh> thanks
16:32:03 <schwicke> sounds very reasonable.
16:32:55 * schwicke redirect questions on protection of children in other services to the  keystone guys
16:33:01 <raildo> I believe that this issue goes beyond the question of hierarchy. this is a issue about inherited roles .
16:33:17 <Sajeesh> sorry there was a misunderstanding...I though that would circulate the latest design document...I will circulate now itself
16:33:30 <raildo> Sajeesh: ok
16:34:05 <schwicke> any other comments that we should discuss today ?
16:34:07 <Sajeesh> raildo, domain will be the root right
16:34:16 <raildo> Sajeesh: yes
16:34:45 <raildo> Sajeesh: I plan to implement this in the coming weeks.
16:34:55 <Sajeesh> great
16:35:03 <schwicke> is there any impact on quota ?
16:35:50 <schwicke> I think the conclusion from the summit was that nova does not care about domains
16:36:27 <raildo> at first I did not believe, as Nova do not know domains
16:37:10 <Sajeesh> For the time being in nova I am using v2 tokens
16:37:40 <raildo> the hierarchy that will be sent to the other services will only contains projects.
16:38:01 <schwicke> Sajeesh: for keystone you mean ?
16:38:20 <Sajeesh> yes ...t
16:39:11 <schwicke> does that work properly for role inheritance ?
16:39:28 <Sajeesh> raildo....will it ?
16:40:28 <Sajeesh> I can use v3 also,but I am worried whether community will accept that
16:40:56 <raildo> I believe only work at Keystone v3, but I will confirm this, waiting 1 minute please.
16:41:05 <Sajeesh> ok
16:42:09 <raildo> yes, just Keystone v3
16:42:31 <Sajeesh> ok ,then I will use v3 token
16:42:34 <raildo> #link http://docs.openstack.org/api/openstack-identity-service/3/content/openstack-identity-api-v3-os-inherit-extension.html
16:42:46 <Sajeesh> ok
16:43:00 <morganfainberg> Sajeesh, the whole hiearchical set was specified as being v3 only to begin with
16:43:15 <Sajeesh> ok
16:43:33 <schwicke> Sajeesh: that is what I remember from the work that Vinod did on domain quotas as well
16:43:39 <schwicke> so it needs to be V3
16:43:57 <raildo> schwicke: +1
16:44:05 <Sajeesh> ok
16:44:06 <schwicke> #agreed nova code needs to use keystone V3
16:44:39 <Sajeesh> +1
16:44:45 <schwicke> one issue that we faced with the code were comments from the community arguing that everything in Nova should move to keystone V3 systematically
16:44:59 <schwicke> so we will have to adress that as well ?
16:45:17 <schwicke> IMO this sounds dangerous because it might stop us.
16:45:25 <Sajeesh> yes that happened
16:45:40 <Sajeesh> that was why I thought of v2
16:45:59 <raildo> that's a good question
16:46:11 <Sajeesh> comunity was not ready to accept the use of v3 in nova
16:46:31 <schwicke> unless everything was moved consistently
16:46:52 <Sajeesh> exactly
16:46:53 <raildo> I believe this is a good topic for the next summit. hahaha
16:46:56 <schwicke> we got stuck at the point where somebody would have had to open a blue print to work on this
16:47:05 <Sajeesh> yes
16:47:18 <schwicke> Is Vishy online
16:47:57 <schwicke> I think this needs urgent clarification with the nova folks
16:48:03 <Sajeesh> sure
16:48:30 <Sajeesh> I am afraid that after doing everything,they may reject
16:49:17 <schwicke> #action move the hierarchical project nova code to keystone V3
16:49:32 <schwicke> if we need it we need it ...
16:49:39 <Sajeesh> +1
16:49:54 <raildo> #link https://blueprints.launchpad.net/nova/+spec/support-keystone-v3-api
16:50:01 <raildo> #link https://review.openstack.org/#/c/85920
16:50:34 <schwicke> Ah great! I was not aware of that!
16:51:10 <raildo> I think that's blueprint is about what we are discussing.
16:51:19 <schwicke> so we may have a dependency on this one
16:51:23 <Sajeesh> yes
16:51:39 <raildo> schwicke: i agree
16:52:08 <schwicke> hmm, any action item to be derived from that ?
16:53:05 <raildo> not for me
16:53:24 <schwicke> #action monitor progress on https://blueprints.launchpad.net/nova/+spec/support-keystone-v3-api
16:53:50 <schwicke> I think we should just proceed with the implementation and see which comments we will get for now
16:54:00 <raildo> schwicke: +1
16:54:11 <Sajeesh> +1
16:55:11 <schwicke> #agreed focus on code implementation and see which comments we get when the code is released with respect to the use of keystone V3
16:55:24 <schwicke> Time is running away.
16:55:27 <schwicke> Any other urgent issue
16:55:36 <raildo> no
16:55:47 <schwicke> We actually have something
16:56:00 <schwicke> #topic staffing
16:56:30 <schwicke> Sajeesh stay at CERN is coming to an end today. He'll go back to India
16:56:55 <schwicke> On the good side we have another person working full time on the project as of next week.
16:57:03 <raildo> Sajeesh: :(
16:57:27 <Sajeesh_> raildo...I will be working from India
16:57:48 <raildo> schwicke: have a vacancy for me? hahahah
16:58:00 <schwicke> :)
16:58:12 <Sajeesh_> schwicke...I have just send the design documentation to you and raildo
16:58:40 <schwicke> we should start the discussion offline via e-mail and summarize next week.
16:58:42 <schwicke> OK ?
16:58:46 <raildo> In my team has two more engineers to work with this project
16:58:55 <schwicke> Great!
16:58:57 <raildo> schwicke: ok
16:58:59 <schwicke> that's good news
16:59:00 <Sajeesh_> ok
16:59:19 <Sajeesh_> raildo,kindly check my blueprint
16:59:32 <raildo> Sajeesh: i will
16:59:38 <schwicke> so keep in touch and see you next week then. Time is over AFAIK
16:59:57 <raildo> bye guys
17:00:01 <schwicke> #endmeeting