Re: [openstack-dev] Hierarchicical Multitenancy Discussion

2014-05-09 Thread Raildo Mascena
Hello Vish,

The implementation was done that way because it would facilitating
compatibility of hierarchical projects with Keystone, for example to get a
token, I would have to change the whole implementation to get the inherited
roles, or for example to list roles, among other features,  for this POC
this was a quick and simple, but i believe that we can discuss the best
solution.


2014-05-06 20:08 GMT-03:00 Vishvananda Ishaya vishvana...@gmail.com:

 This is a bit different from how I would have expected it to work. It
 appears that you are adding the role assignment when the project is
 created. IMO the role should be added to the list when the roles are
 checked. In other words, when getting the list of roles for a user/project,
 it walks up the tree to find all parent projects and creates a list of
 roles that includes all of the parent roles for that user that are marked
 inheritable. The implementation you made seems very fragile if parent
 projects are changed etc.

 Vish

 On Apr 14, 2014, at 12:17 PM, Raildo Mascena rail...@gmail.com wrote:

 Hi all,

 As I had promised, here is the repository of Telles Nobrega (
 https://github.com/tellesnobrega/keystone/tree/multitenancy) updated now
 with inherited roles working with hierarchical projects.

 How ​does ​it work​​?

 ​I​nherited roles operate in the following way:
 - It should be added​ a role ​to​ be inherited to a domain using the api
 PUT
 localhost:35357/v3/OS-INHERIT/domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited_to_projects.
 - It should be create​d​ a hierarchical project as described above for
 Telles.
 - List the assignments roles GET localhost: 35357/v3/role_assignments
  and check that the role inherited is already associated with this new
 project.

 What was implemented?
 The implementation consists of filter​ing​ roles which are associated with
 the parent project to be inherited (this is done by checking the assigment
 table) for them to be added to the child project. Also a filter has been
 created to ensure that a role inherited from another domain does not
 interfere in the inheritance of this project.

 What remains to implement?

 Role inherit​ance​ has been implemented to work with domains, so the role
 will be inherited to all projects contained this domain, ie, a role that is
 marked to be inherited, even if it is not associated with the parent
 project, will be inherited to the child project. In my opinion, should ​be
 ​create​d​ a project column in the assignment that would indicate where
 to start inheritance projects, it would be possible to finish this feature.
 (This is just a suggestion, I believe ​there are other ways to make it
 work).


 2014-03-17 8:04 GMT-03:00 Telles Nobrega tellesnobr...@gmail.com:

 That is good news, I can have both information sent to nova really easy.
 I just need to add a field into the token, or more than one if needed.
 RIght now I send Ids, it could names just as easily and we can add a new
 field so we can have both information sent. I'm not sure which is the best
 option for us but i would think that sending both for now would keep the
 compatibility and we could still use the names for display porpuse


 On Sun, Mar 16, 2014 at 9:18 AM, Jay Pipes jaypi...@gmail.com wrote:

 On Fri, 2014-03-14 at 13:43 -0700, Vishvananda Ishaya wrote:
  Awesome, this is exactly what I was thinking. I think this is really
  close to being usable on the nova side. First of all the
  dot.sperated.form looks better imo, and I think my code should still
  work that way as well. The other piece that is needed is mapping ids
  to names for display purposes. I did something like this for a
  prototype of names in dns caching that should work nicely. The
  question simply becomes how do we expose those names. I’m thinking we
  have to add an output field to the display of objects in the system
  showing the fully qualified name.  We can then switch the display in
  novaclient to show names instead of ids.  That way an admin listing
  all the projects in orga would see the owner as orga.projb instead of
  the id string.
 
  The other option would be to pass names instead of ids from keystone
  and store those instead. That seems simpler at first glance, it is not
  backwards compatible with the current model so it will be painful for
  providers to switch.

 -1 for instead of. in addition to would have been fine, IMO.

 Best,
 -jay



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 --
 Telles Mota Vidal Nobrega
 Bsc in Computer Science at UFCG
 Software Engineer at PulsarOpenStack Project - HP/LSD-UFCG

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Raildo Mascena
 Bachelor of 

Re: [openstack-dev] Hierarchicical Multitenancy Discussion

2014-05-06 Thread Vishvananda Ishaya
This is a bit different from how I would have expected it to work. It appears 
that you are adding the role assignment when the project is created. IMO the 
role should be added to the list when the roles are checked. In other words, 
when getting the list of roles for a user/project, it walks up the tree to find 
all parent projects and creates a list of roles that includes all of the parent 
roles for that user that are marked inheritable. The implementation you made 
seems very fragile if parent projects are changed etc.

Vish

On Apr 14, 2014, at 12:17 PM, Raildo Mascena rail...@gmail.com wrote:

 Hi all,
 
 As I had promised, here is the repository of Telles Nobrega 
 (https://github.com/tellesnobrega/keystone/tree/multitenancy) updated now 
 with inherited roles working with hierarchical projects.
 
 How ​does ​it work​​?
 
 ​I​nherited roles operate in the following way:
 - It should be added​ a role ​to​ be inherited to a domain using the api PUT 
 localhost:35357/v3/OS-INHERIT/domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited_to_projects.
 - It should be create​d​ a hierarchical project as described above for Telles.
 - List the assignments roles GET localhost: 35357/v3/role_assignments  and 
 check that the role inherited is already associated with this new project. 
 
 What was implemented? 
 The implementation consists of filter​ing​ roles which are associated with 
 the parent project to be inherited (this is done by checking the assigment 
 table) for them to be added to the child project. Also a filter has been 
 created to ensure that a role inherited from another domain does not 
 interfere in the inheritance of this project.
 
 What remains to implement?
 
 Role inherit​ance​ has been implemented to work with domains, so the role 
 will be inherited to all projects contained this domain, ie, a role that is 
 marked to be inherited, even if it is not associated with the parent project, 
 will be inherited to the child project. In my opinion, should ​be ​create​d​ 
 a project column in the assignment that would indicate where to start 
 inheritance projects, it would be possible to finish this feature. (This is 
 just a suggestion, I believe ​there are other ways to make it work).
 
 
 2014-03-17 8:04 GMT-03:00 Telles Nobrega tellesnobr...@gmail.com:
 That is good news, I can have both information sent to nova really easy. I 
 just need to add a field into the token, or more than one if needed. RIght 
 now I send Ids, it could names just as easily and we can add a new field so 
 we can have both information sent. I'm not sure which is the best option for 
 us but i would think that sending both for now would keep the compatibility 
 and we could still use the names for display porpuse 
 
 
 On Sun, Mar 16, 2014 at 9:18 AM, Jay Pipes jaypi...@gmail.com wrote:
 On Fri, 2014-03-14 at 13:43 -0700, Vishvananda Ishaya wrote:
  Awesome, this is exactly what I was thinking. I think this is really
  close to being usable on the nova side. First of all the
  dot.sperated.form looks better imo, and I think my code should still
  work that way as well. The other piece that is needed is mapping ids
  to names for display purposes. I did something like this for a
  prototype of names in dns caching that should work nicely. The
  question simply becomes how do we expose those names. I’m thinking we
  have to add an output field to the display of objects in the system
  showing the fully qualified name.  We can then switch the display in
  novaclient to show names instead of ids.  That way an admin listing
  all the projects in orga would see the owner as orga.projb instead of
  the id string.
 
  The other option would be to pass names instead of ids from keystone
  and store those instead. That seems simpler at first glance, it is not
  backwards compatible with the current model so it will be painful for
  providers to switch.
 
 -1 for instead of. in addition to would have been fine, IMO.
 
 Best,
 -jay
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 -- 
 --
 Telles Mota Vidal Nobrega
 Bsc in Computer Science at UFCG
 Software Engineer at PulsarOpenStack Project - HP/LSD-UFCG
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 -- 
 Raildo Mascena
 Bachelor of Computer Science. 
 Software Engineer at Laboratory of Distributed Systems - UFCG
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list

Re: [openstack-dev] Hierarchicical Multitenancy Discussion

2014-04-14 Thread Raildo Mascena
Hi all,

As I had promised, here is the repository of Telles Nobrega (
https://github.com/tellesnobrega/keystone/tree/multitenancy) updated now
with inherited roles working with hierarchical projects.

How ​does ​it work​​?

​I​nherited roles operate in the following way:
- It should be added​ a role ​to​ be inherited to a domain using the api
PUT
localhost:35357/v3/OS-INHERIT/domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited_to_projects.
- It should be create​d​ a hierarchical project as described above for
Telles.
- List the assignments roles GET localhost: 35357/v3/role_assignments
 and check that the role inherited is already associated with this new
project.

What was implemented?
The implementation consists of filter​ing​ roles which are associated with
the parent project to be inherited (this is done by checking the assigment
table) for them to be added to the child project. Also a filter has been
created to ensure that a role inherited from another domain does not
interfere in the inheritance of this project.

What remains to implement?

Role inherit​ance​ has been implemented to work with domains, so the role
will be inherited to all projects contained this domain, ie, a role that is
marked to be inherited, even if it is not associated with the parent
project, will be inherited to the child project. In my opinion, should ​be
​create​d​ a project column in the assignment that would indicate where
to start inheritance projects, it would be possible to finish this feature.
(This is just a suggestion, I believe ​there are other ways to make it
work).


2014-03-17 8:04 GMT-03:00 Telles Nobrega tellesnobr...@gmail.com:

 That is good news, I can have both information sent to nova really easy. I
 just need to add a field into the token, or more than one if needed. RIght
 now I send Ids, it could names just as easily and we can add a new field so
 we can have both information sent. I'm not sure which is the best option
 for us but i would think that sending both for now would keep the
 compatibility and we could still use the names for display porpuse


 On Sun, Mar 16, 2014 at 9:18 AM, Jay Pipes jaypi...@gmail.com wrote:

 On Fri, 2014-03-14 at 13:43 -0700, Vishvananda Ishaya wrote:
  Awesome, this is exactly what I was thinking. I think this is really
  close to being usable on the nova side. First of all the
  dot.sperated.form looks better imo, and I think my code should still
  work that way as well. The other piece that is needed is mapping ids
  to names for display purposes. I did something like this for a
  prototype of names in dns caching that should work nicely. The
  question simply becomes how do we expose those names. I’m thinking we
  have to add an output field to the display of objects in the system
  showing the fully qualified name.  We can then switch the display in
  novaclient to show names instead of ids.  That way an admin listing
  all the projects in orga would see the owner as orga.projb instead of
  the id string.
 
  The other option would be to pass names instead of ids from keystone
  and store those instead. That seems simpler at first glance, it is not
  backwards compatible with the current model so it will be painful for
  providers to switch.

 -1 for instead of. in addition to would have been fine, IMO.

 Best,
 -jay



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 --
 Telles Mota Vidal Nobrega
 Bsc in Computer Science at UFCG
 Software Engineer at PulsarOpenStack Project - HP/LSD-UFCG

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Raildo Mascena
Bachelor of Computer Science.
Software Engineer at Laboratory of Distributed Systems - UFCG
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Hierarchicical Multitenancy Discussion

2014-03-17 Thread Telles Nobrega
That is good news, I can have both information sent to nova really easy. I
just need to add a field into the token, or more than one if needed. RIght
now I send Ids, it could names just as easily and we can add a new field so
we can have both information sent. I'm not sure which is the best option
for us but i would think that sending both for now would keep the
compatibility and we could still use the names for display porpuse


On Sun, Mar 16, 2014 at 9:18 AM, Jay Pipes jaypi...@gmail.com wrote:

 On Fri, 2014-03-14 at 13:43 -0700, Vishvananda Ishaya wrote:
  Awesome, this is exactly what I was thinking. I think this is really
  close to being usable on the nova side. First of all the
  dot.sperated.form looks better imo, and I think my code should still
  work that way as well. The other piece that is needed is mapping ids
  to names for display purposes. I did something like this for a
  prototype of names in dns caching that should work nicely. The
  question simply becomes how do we expose those names. I'm thinking we
  have to add an output field to the display of objects in the system
  showing the fully qualified name.  We can then switch the display in
  novaclient to show names instead of ids.  That way an admin listing
  all the projects in orga would see the owner as orga.projb instead of
  the id string.
 
  The other option would be to pass names instead of ids from keystone
  and store those instead. That seems simpler at first glance, it is not
  backwards compatible with the current model so it will be painful for
  providers to switch.

 -1 for instead of. in addition to would have been fine, IMO.

 Best,
 -jay



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
--
Telles Mota Vidal Nobrega
Bsc in Computer Science at UFCG
Software Engineer at PulsarOpenStack Project - HP/LSD-UFCG
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Hierarchicical Multitenancy Discussion

2014-03-16 Thread Jay Pipes
On Fri, 2014-03-14 at 13:43 -0700, Vishvananda Ishaya wrote:
 Awesome, this is exactly what I was thinking. I think this is really
 close to being usable on the nova side. First of all the
 dot.sperated.form looks better imo, and I think my code should still
 work that way as well. The other piece that is needed is mapping ids
 to names for display purposes. I did something like this for a
 prototype of names in dns caching that should work nicely. The
 question simply becomes how do we expose those names. I’m thinking we
 have to add an output field to the display of objects in the system
 showing the fully qualified name.  We can then switch the display in
 novaclient to show names instead of ids.  That way an admin listing
 all the projects in orga would see the owner as orga.projb instead of
 the id string.
 
 The other option would be to pass names instead of ids from keystone
 and store those instead. That seems simpler at first glance, it is not
 backwards compatible with the current model so it will be painful for
 providers to switch.

-1 for instead of. in addition to would have been fine, IMO.

Best,
-jay



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Hierarchicical Multitenancy Discussion

2014-02-20 Thread John Dennis
On 02/19/2014 08:58 PM, Adam Young wrote:
 Can you give more detail here? I can see arguments for both ways of
 doing this but continuing to use ids for ownership is an easier
 choice. Here is my thinking:

 1. all of the projects use ids for ownership currently so it is a
 smaller change
 That does not change.  It is the hierarchy that is labeled by name.
 
 2. renaming a project in keystone would not invalidate the ownership
 hierarchy (Note that moving a project around would invalidate the
 hierarchy in both cases)

 Renaming would not change anything.
 
 I would say the rule should be this:  Ids are basically uuids, and are
 immutable.  Names a mutable.  Each project has a parent Id.  A project
 can either be referenced directly by ID, oir hierarchically by name.  In
 addition, you can navigate to a project by traversing the set of ids,
 but you need to know where you are going.  THus the array
 
 ['abcd1234',fedd3213','3e3e3e3e'] would be a way to find a project, but
 the project ID for the lead node would still be just '3e3e3e3e'.

The analogy I see here is the unix file system which is organized into a
tree structure by inodes, each inode has a name (technically it can have
more than one name). But the fundamental point is the structure is
formed by id's (e.g. inodes), the path name of a file is transitory and
depends only on what name is bound to the id at the moment. It's a very
rich and powerful abstraction. The same concept is used in many database
schemas, an object has a primary key which is numeric and a name. You
can change the name easily without affecting any references to the id.



-- 
John

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Hierarchicical Multitenancy Discussion

2014-02-14 Thread Vishvananda Ishaya
Hi Vinod!

I think you can simplify the roles in the hierarchical model by only passing 
the roles for the authenticated project and above. All roles are then inherited 
down. This means it isn’t necessary to pass a scope along with each role. The 
scope is just passed once with the token and the project-admin role (for 
example) would be checking to see that the user has the project-admin role and 
that the project_id prefix matches.

There is only one case that this doesn’t handle, and that is when the user has 
one role (say member) in ProjA and project-admin in ProjA2. If the user is 
authenticated to ProjA, he can’t do project-adminy stuff for ProjA2 without 
reauthenticating. I think this is a reasonable sacrifice considering how much 
easier it would be to just pass the parent roles instead of going through all 
of the children.

Vish

On Feb 13, 2014, at 2:31 AM, Vinod Kumar Boppanna 
vinod.kumar.boppa...@cern.ch wrote:

 Dear All,
 
 At the meeting last week we (myself and Ulrich) have been assigned the task 
 of doing POC for Quota Management in the Hierarchical Multitenancy setup. 
 
 So, here it is:
 
 Wiki Page - https://wiki.openstack.org/wiki/POC_for_QuotaManagement   
 (explained here an example setup and my thoughts)
 
 Code - 
 https://github.com/vinodkumarboppanna/POC-For-Quotas/commit/391e9108fa579d292880c8836cadfd7253586f37
 
 Please post your comments or any inputs and i hope this POC will be discussed 
 in this weeks meeting on Friday at 1600 UTC.
 
 
 In addition to this, we have completed the implementation the Domain Quota 
 Management in Nova with V2 APIs, and if anybody interested, please have a look
 
 BluePrint - 
 https://blueprints.launchpad.net/nova/+spec/domain-quota-driver-api
 Wiki Page - https://wiki.openstack.org/wiki/APIs_for_Domain_Quota_Driver
 GitHub Code - https://github.com/vinodkumarboppanna/DomainQuotaAPIs
 
 
 Thanks  Regards,
 Vinod Kumar Boppanna
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Hierarchicical Multitenancy Discussion

2014-02-13 Thread Vinod Kumar Boppanna
Dear All,

At the meeting last week we (myself and Ulrich) have been assigned the task of 
doing POC for Quota Management in the Hierarchical Multitenancy setup.

So, here it is:

Wiki Page - https://wiki.openstack.org/wiki/POC_for_QuotaManagement   
(explained here an example setup and my thoughts)

Code - 
https://github.com/vinodkumarboppanna/POC-For-Quotas/commit/391e9108fa579d292880c8836cadfd7253586f37

Please post your comments or any inputs and i hope this POC will be discussed 
in this weeks meeting on Friday at 1600 UTC.


In addition to this, we have completed the implementation the Domain Quota 
Management in Nova with V2 APIs, and if anybody interested, please have a look

BluePrint - https://blueprints.launchpad.net/nova/+spec/domain-quota-driver-api
Wiki Page - https://wiki.openstack.org/wiki/APIs_for_Domain_Quota_Driver
GitHub Code - https://github.com/vinodkumarboppanna/DomainQuotaAPIs


Thanks  Regards,
Vinod Kumar Boppanna

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Hierarchicical Multitenancy Discussion

2014-02-05 Thread Vishvananda Ishaya

On Feb 5, 2014, at 6:54 AM, Florent Flament florent.flament-...@cloudwatt.com 
wrote:

 Vish:
 
 I agree that having roles associated with projects may complicate
 policy rules (although we may find ways to simplify the syntax?). It
 may be a sound choice to stick to a single scope for a given token.
 
 +1 for your quotas tree proposal. Maybe ensuring that the sum of
 subprojects quotas is lower (or equal) than the parent quota will be
 enough for most use cases.
 
 So far, I don't see any issue against your hierarchical projects
 proposal. IMHO, domains would not be much useful anymore.
 
 
 Vinod:
 
 I agree that you raised the same issue that I did. I needed some
 clarification.
 
 Regarding names (or IDs) that Nova uses, it would have to be full
 project names to avoid conflicts.

to be clear, I was not proposing at any point that we actually use
project names internally in the service databases, just that the names
are easier for humans to understand them for discussion. So when we
use:

orga.projecta

the database actually contains something like:

b04f9ea01a9944ac903526885a2666de.c45674c5c2c6463dad3c0cb9d7b8a6d8

That said, the full hierarchical is necessary for quotas to ensure
that we don’t exceed any of the parent quotas for a project.

 
 
 Tiago, Vinod, Vish:
 
 I agree with Tiago that having policy files spread on every node
 doesn't look easy to maintain. I don't think that the service
 centralizing RBAC would have to know about the services sets of
 operations. It could work by checking some tuple (action, context)
 against a set a rules, and answering whether the action is authorized
 or not.
 
 Moreover, if the same service were to centralize both RBAC and Quotas,
 then both could be checked in a row, for the provided tuple. The thing
 about Quotas, is that it requires the service to track resources
 usage, which can be done by the service providing RBAC, since each
 action would have to be authorized (and possibly tracked) by the RBAC
 engine.
 
 This is why I would argue in favor of a unique service providing RBAC
 and Quotas enforcement together.
 
 I don't know much about Gantt, so I guess that potential candidate for
 such service would be Keystone, Gantt, Ceilometer ? (which already
 agregates information about resources usage), a new service?.
 
 I have seen that some work had been started to centralize Quotas, but
 abandonned:
 * https://review.openstack.org/#/c/44878/
 * https://review.openstack.org/#/c/40568/
 
 There's also Identity API V3 providing (centralized?) policies
 management:
 * http://api.openstack.org/api-ref-identity.html#identity-v3
 
 I think it would be worth to try to clarify/simplify/rationalize the
 way RBAC/Quotas are working. Or am I missing something ?
 
 Although, I think this might be out of scope of the initial
 Hierachical Multitenancy Discussion. Should it be moved to a new
 thread?

I vote for new thread. I’m not sure that policy and quota enforcement
can be done in a separate service for performance reasons. Even if we
can’t move enforcement into a central service like gantt or keystone, there
could still be a central location to store policy rules and quota values.

Vish

 
 Florent Flament
 
 snip



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Hierarchicical Multitenancy Discussion

2014-01-30 Thread Henry Nash
Vish,

Excellent idea to discuss this more widely.  To your point about domains not 
being well understood and that most policy files being just admin or not, the 
exception here is, of course, keystone itself - where we can use domains to 
support enable various levels of cloud/domain  project level admin type of 
capability via the policy file.  Although the default policy file we supply is 
a bit like the admin or not versions, we also supply a much richer sample for 
those who want to do admin delegation via domains:

https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json

The other point is that one thing we did introduce in Havana was the concept of 
domain inheritance (where a role assigned to a domain could be specified to be 
inherited by all projects within that domain).  This was an attempt to provide 
an rudimentary multi-ownership capability (within our current token formats 
and policy capabilities).

https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3-os-inherit-ext.md

I'm not suggesting these solve all the issues, just that we should be aware of 
these in the upcoming discussions.

Henry
On 28 Jan 2014, at 18:35, Vishvananda Ishaya vishvana...@gmail.com wrote:

 Hi Everyone,
 
 I apologize for the obtuse title, but there isn't a better succinct term to 
 describe what is needed. OpenStack has no support for multiple owners of 
 objects. This means that a variety of private cloud use cases are simply not 
 supported. Specifically, objects in the system can only be managed on the 
 tenant level or globally.
 
 The key use case here is to delegate administration rights for a group of 
 tenants to a specific user/role. There is something in Keystone called a 
 “domain” which supports part of this functionality, but without support from 
 all of the projects, this concept is pretty useless.
 
 In IRC today I had a brief discussion about how we could address this. I have 
 put some details and a straw man up here:
 
 https://wiki.openstack.org/wiki/HierarchicalMultitenancy
 
 I would like to discuss this strawman and organize a group of people to get 
 actual work done by having an irc meeting this Friday at 1600UTC. I know this 
 time is probably a bit tough for Europe, so if we decide we need a regular 
 meeting to discuss progress then we can vote on a better time for this 
 meeting.
 
 https://wiki.openstack.org/wiki/Meetings#Hierarchical_Multitenancy_Meeting
 
 Please note that this is going to be an active team that produces code. We 
 will *NOT* spend a lot of time debating approaches, and instead focus on 
 making something that works and learning as we go. The output of this team 
 will be a MultiTenant devstack install that actually works, so that we can 
 ensure the features we are adding to each project work together.
 
 Vish
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Hierarchicical Multitenancy Discussion

2014-01-30 Thread Soren Hansen
2100 UTC is 1 PM Pacific. :-)
Den 29/01/2014 17.01 skrev Vishvananda Ishaya vishvana...@gmail.com:

 I apologize for the confusion. The Wiki time of 2100 UTC is the correct
 time (Noon Pacific time). We can move tne next meeting to a different
 day/time that is more convienient for Europe.

 Vish


 On Jan 29, 2014, at 1:56 AM, Florent Flament 
 florent.flament-...@cloudwatt.com wrote:

  Hi Vishvananda,
 
  I would be interested in such a working group.
  Can you please confirm the meeting hour for this Friday ?
  I've seen 1600 UTC in your email and 2100 UTC in the wiki (
 https://wiki.openstack.org/wiki/Meetings#Hierarchical_Multitenancy_Meeting). 
 As I'm in Europe I'd prefer 1600 UTC.
 
  Florent Flament
 
  - Original Message -
  From: Vishvananda Ishaya vishvana...@gmail.com
  To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
  Sent: Tuesday, January 28, 2014 7:35:15 PM
  Subject: [openstack-dev] Hierarchicical Multitenancy Discussion
 
  Hi Everyone,
 
  I apologize for the obtuse title, but there isn't a better succinct term
 to describe what is needed. OpenStack has no support for multiple owners of
 objects. This means that a variety of private cloud use cases are simply
 not supported. Specifically, objects in the system can only be managed on
 the tenant level or globally.
 
  The key use case here is to delegate administration rights for a group
 of tenants to a specific user/role. There is something in Keystone called a
 “domain” which supports part of this functionality, but without support
 from all of the projects, this concept is pretty useless.
 
  In IRC today I had a brief discussion about how we could address this. I
 have put some details and a straw man up here:
 
  https://wiki.openstack.org/wiki/HierarchicalMultitenancy
 
  I would like to discuss this strawman and organize a group of people to
 get actual work done by having an irc meeting this Friday at 1600UTC. I
 know this time is probably a bit tough for Europe, so if we decide we need
 a regular meeting to discuss progress then we can vote on a better time for
 this meeting.
 
 
 https://wiki.openstack.org/wiki/Meetings#Hierarchical_Multitenancy_Meeting
 
  Please note that this is going to be an active team that produces code.
 We will *NOT* spend a lot of time debating approaches, and instead focus on
 making something that works and learning as we go. The output of this team
 will be a MultiTenant devstack install that actually works, so that we can
 ensure the features we are adding to each project work together.
 
  Vish
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Hierarchicical Multitenancy Discussion

2014-01-30 Thread Vishvananda Ishaya
Thanks Soren, you are correct! Yay Timezones

Vish

On Jan 30, 2014, at 10:39 AM, Soren Hansen so...@linux2go.dk wrote:

 2100 UTC is 1 PM Pacific. :-)
 
 Den 29/01/2014 17.01 skrev Vishvananda Ishaya vishvana...@gmail.com:
 I apologize for the confusion. The Wiki time of 2100 UTC is the correct time 
 (Noon Pacific time). We can move tne next meeting to a different day/time 
 that is more convienient for Europe.
 
 Vish
 
 
 On Jan 29, 2014, at 1:56 AM, Florent Flament 
 florent.flament-...@cloudwatt.com wrote:
 
  Hi Vishvananda,
 
  I would be interested in such a working group.
  Can you please confirm the meeting hour for this Friday ?
  I've seen 1600 UTC in your email and 2100 UTC in the wiki ( 
  https://wiki.openstack.org/wiki/Meetings#Hierarchical_Multitenancy_Meeting 
  ). As I'm in Europe I'd prefer 1600 UTC.
 
  Florent Flament
 
  - Original Message -
  From: Vishvananda Ishaya vishvana...@gmail.com
  To: OpenStack Development Mailing List (not for usage questions) 
  openstack-dev@lists.openstack.org
  Sent: Tuesday, January 28, 2014 7:35:15 PM
  Subject: [openstack-dev] Hierarchicical Multitenancy Discussion
 
  Hi Everyone,
 
  I apologize for the obtuse title, but there isn't a better succinct term to 
  describe what is needed. OpenStack has no support for multiple owners of 
  objects. This means that a variety of private cloud use cases are simply 
  not supported. Specifically, objects in the system can only be managed on 
  the tenant level or globally.
 
  The key use case here is to delegate administration rights for a group of 
  tenants to a specific user/role. There is something in Keystone called a 
  “domain” which supports part of this functionality, but without support 
  from all of the projects, this concept is pretty useless.
 
  In IRC today I had a brief discussion about how we could address this. I 
  have put some details and a straw man up here:
 
  https://wiki.openstack.org/wiki/HierarchicalMultitenancy
 
  I would like to discuss this strawman and organize a group of people to get 
  actual work done by having an irc meeting this Friday at 1600UTC. I know 
  this time is probably a bit tough for Europe, so if we decide we need a 
  regular meeting to discuss progress then we can vote on a better time for 
  this meeting.
 
  https://wiki.openstack.org/wiki/Meetings#Hierarchical_Multitenancy_Meeting
 
  Please note that this is going to be an active team that produces code. We 
  will *NOT* spend a lot of time debating approaches, and instead focus on 
  making something that works and learning as we go. The output of this team 
  will be a MultiTenant devstack install that actually works, so that we can 
  ensure the features we are adding to each project work together.
 
  Vish
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Hierarchicical Multitenancy Discussion

2014-01-30 Thread David Stanek
That's why I love this site:
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140130T2100


On Thu, Jan 30, 2014 at 1:46 PM, Vishvananda Ishaya
vishvana...@gmail.comwrote:

 Thanks Soren, you are correct! Yay Timezones

 Vish

 On Jan 30, 2014, at 10:39 AM, Soren Hansen so...@linux2go.dk wrote:

 2100 UTC is 1 PM Pacific. :-)
 Den 29/01/2014 17.01 skrev Vishvananda Ishaya vishvana...@gmail.com:

 I apologize for the confusion. The Wiki time of 2100 UTC is the correct
 time (Noon Pacific time). We can move tne next meeting to a different
 day/time that is more convienient for Europe.

 Vish


 On Jan 29, 2014, at 1:56 AM, Florent Flament 
 florent.flament-...@cloudwatt.com wrote:

  Hi Vishvananda,
 
  I would be interested in such a working group.
  Can you please confirm the meeting hour for this Friday ?
  I've seen 1600 UTC in your email and 2100 UTC in the wiki (
 https://wiki.openstack.org/wiki/Meetings#Hierarchical_Multitenancy_Meeting). 
 As I'm in Europe I'd prefer 1600 UTC.
 
  Florent Flament
 
  - Original Message -
  From: Vishvananda Ishaya vishvana...@gmail.com
  To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
  Sent: Tuesday, January 28, 2014 7:35:15 PM
  Subject: [openstack-dev] Hierarchicical Multitenancy Discussion
 
  Hi Everyone,
 
  I apologize for the obtuse title, but there isn't a better succinct
 term to describe what is needed. OpenStack has no support for multiple
 owners of objects. This means that a variety of private cloud use cases are
 simply not supported. Specifically, objects in the system can only be
 managed on the tenant level or globally.
 
  The key use case here is to delegate administration rights for a group
 of tenants to a specific user/role. There is something in Keystone called a
 domain which supports part of this functionality, but without support
 from all of the projects, this concept is pretty useless.
 
  In IRC today I had a brief discussion about how we could address this.
 I have put some details and a straw man up here:
 
  https://wiki.openstack.org/wiki/HierarchicalMultitenancy
 
  I would like to discuss this strawman and organize a group of people to
 get actual work done by having an irc meeting this Friday at 1600UTC. I
 know this time is probably a bit tough for Europe, so if we decide we need
 a regular meeting to discuss progress then we can vote on a better time for
 this meeting.
 
 
 https://wiki.openstack.org/wiki/Meetings#Hierarchical_Multitenancy_Meeting
 
  Please note that this is going to be an active team that produces code.
 We will *NOT* spend a lot of time debating approaches, and instead focus on
 making something that works and learning as we go. The output of this team
 will be a MultiTenant devstack install that actually works, so that we can
 ensure the features we are adding to each project work together.
 
  Vish
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
www: http://dstanek.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Hierarchicical Multitenancy Discussion

2014-01-29 Thread Florent Flament
Hi Vishvananda,

I would be interested in such a working group.
Can you please confirm the meeting hour for this Friday ?
I've seen 1600 UTC in your email and 2100 UTC in the wiki ( 
https://wiki.openstack.org/wiki/Meetings#Hierarchical_Multitenancy_Meeting ). 
As I'm in Europe I'd prefer 1600 UTC.

Florent Flament

- Original Message -
From: Vishvananda Ishaya vishvana...@gmail.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Sent: Tuesday, January 28, 2014 7:35:15 PM
Subject: [openstack-dev] Hierarchicical Multitenancy Discussion

Hi Everyone,

I apologize for the obtuse title, but there isn't a better succinct term to 
describe what is needed. OpenStack has no support for multiple owners of 
objects. This means that a variety of private cloud use cases are simply not 
supported. Specifically, objects in the system can only be managed on the 
tenant level or globally.

The key use case here is to delegate administration rights for a group of 
tenants to a specific user/role. There is something in Keystone called a 
“domain” which supports part of this functionality, but without support from 
all of the projects, this concept is pretty useless.

In IRC today I had a brief discussion about how we could address this. I have 
put some details and a straw man up here:

https://wiki.openstack.org/wiki/HierarchicalMultitenancy

I would like to discuss this strawman and organize a group of people to get 
actual work done by having an irc meeting this Friday at 1600UTC. I know this 
time is probably a bit tough for Europe, so if we decide we need a regular 
meeting to discuss progress then we can vote on a better time for this meeting.

https://wiki.openstack.org/wiki/Meetings#Hierarchical_Multitenancy_Meeting

Please note that this is going to be an active team that produces code. We will 
*NOT* spend a lot of time debating approaches, and instead focus on making 
something that works and learning as we go. The output of this team will be a 
MultiTenant devstack install that actually works, so that we can ensure the 
features we are adding to each project work together.

Vish

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Hierarchicical Multitenancy Discussion

2014-01-29 Thread Ulrich Schwickerath

Hi,

I'm working with Vinod. We'd like to join as well. Same issue on our 
side: 16:00 UTC is better for us.


Ulrich and Vinod

On 29.01.2014 10:56, Florent Flament wrote:

Hi Vishvananda,

I would be interested in such a working group.
Can you please confirm the meeting hour for this Friday ?
I've seen 1600 UTC in your email and 2100 UTC in the wiki ( 
https://wiki.openstack.org/wiki/Meetings#Hierarchical_Multitenancy_Meeting ). 
As I'm in Europe I'd prefer 1600 UTC.

Florent Flament

- Original Message -
From: Vishvananda Ishaya vishvana...@gmail.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Sent: Tuesday, January 28, 2014 7:35:15 PM
Subject: [openstack-dev] Hierarchicical Multitenancy Discussion

Hi Everyone,

I apologize for the obtuse title, but there isn't a better succinct term to 
describe what is needed. OpenStack has no support for multiple owners of 
objects. This means that a variety of private cloud use cases are simply not 
supported. Specifically, objects in the system can only be managed on the 
tenant level or globally.

The key use case here is to delegate administration rights for a group of 
tenants to a specific user/role. There is something in Keystone called a 
“domain” which supports part of this functionality, but without support from 
all of the projects, this concept is pretty useless.

In IRC today I had a brief discussion about how we could address this. I have 
put some details and a straw man up here:

https://wiki.openstack.org/wiki/HierarchicalMultitenancy

I would like to discuss this strawman and organize a group of people to get 
actual work done by having an irc meeting this Friday at 1600UTC. I know this 
time is probably a bit tough for Europe, so if we decide we need a regular 
meeting to discuss progress then we can vote on a better time for this meeting.

https://wiki.openstack.org/wiki/Meetings#Hierarchical_Multitenancy_Meeting

Please note that this is going to be an active team that produces code. We will 
*NOT* spend a lot of time debating approaches, and instead focus on making 
something that works and learning as we go. The output of this team will be a 
MultiTenant devstack install that actually works, so that we can ensure the 
features we are adding to each project work together.

Vish

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Hierarchicical Multitenancy Discussion

2014-01-29 Thread Telles Nobrega
Hi,

I'm also working with multitenancy and I would like to join this working
group.

Telles Nóbrega


On Wed, Jan 29, 2014 at 9:14 AM, Ulrich Schwickerath 
ulrich.schwicker...@cern.ch wrote:

 Hi,

 I'm working with Vinod. We'd like to join as well. Same issue on our side:
 16:00 UTC is better for us.

 Ulrich and Vinod


 On 29.01.2014 10:56, Florent Flament wrote:

 Hi Vishvananda,

 I would be interested in such a working group.
 Can you please confirm the meeting hour for this Friday ?
 I've seen 1600 UTC in your email and 2100 UTC in the wiki (
 https://wiki.openstack.org/wiki/Meetings#Hierarchical_
 Multitenancy_Meeting ). As I'm in Europe I'd prefer 1600 UTC.

 Florent Flament

 - Original Message -
 From: Vishvananda Ishaya vishvana...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Tuesday, January 28, 2014 7:35:15 PM
 Subject: [openstack-dev] Hierarchicical Multitenancy Discussion

 Hi Everyone,

 I apologize for the obtuse title, but there isn't a better succinct term
 to describe what is needed. OpenStack has no support for multiple owners of
 objects. This means that a variety of private cloud use cases are simply
 not supported. Specifically, objects in the system can only be managed on
 the tenant level or globally.

 The key use case here is to delegate administration rights for a group of
 tenants to a specific user/role. There is something in Keystone called a
 domain which supports part of this functionality, but without support
 from all of the projects, this concept is pretty useless.

 In IRC today I had a brief discussion about how we could address this. I
 have put some details and a straw man up here:

 https://wiki.openstack.org/wiki/HierarchicalMultitenancy

 I would like to discuss this strawman and organize a group of people to
 get actual work done by having an irc meeting this Friday at 1600UTC. I
 know this time is probably a bit tough for Europe, so if we decide we need
 a regular meeting to discuss progress then we can vote on a better time for
 this meeting.

 https://wiki.openstack.org/wiki/Meetings#Hierarchical_
 Multitenancy_Meeting

 Please note that this is going to be an active team that produces code.
 We will *NOT* spend a lot of time debating approaches, and instead focus on
 making something that works and learning as we go. The output of this team
 will be a MultiTenant devstack install that actually works, so that we can
 ensure the features we are adding to each project work together.

 Vish

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
--
Telles Mota Vidal Nobrega
Bsc in Computer Science at UFCG
Developer at PulsarOpenStack Project - HP/LSD-UFCG
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Hierarchicical Multitenancy Discussion

2014-01-29 Thread Vishvananda Ishaya
I apologize for the confusion. The Wiki time of 2100 UTC is the correct time 
(Noon Pacific time). We can move tne next meeting to a different day/time that 
is more convienient for Europe.

Vish


On Jan 29, 2014, at 1:56 AM, Florent Flament 
florent.flament-...@cloudwatt.com wrote:

 Hi Vishvananda,
 
 I would be interested in such a working group.
 Can you please confirm the meeting hour for this Friday ?
 I've seen 1600 UTC in your email and 2100 UTC in the wiki ( 
 https://wiki.openstack.org/wiki/Meetings#Hierarchical_Multitenancy_Meeting ). 
 As I'm in Europe I'd prefer 1600 UTC.
 
 Florent Flament
 
 - Original Message -
 From: Vishvananda Ishaya vishvana...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Tuesday, January 28, 2014 7:35:15 PM
 Subject: [openstack-dev] Hierarchicical Multitenancy Discussion
 
 Hi Everyone,
 
 I apologize for the obtuse title, but there isn't a better succinct term to 
 describe what is needed. OpenStack has no support for multiple owners of 
 objects. This means that a variety of private cloud use cases are simply not 
 supported. Specifically, objects in the system can only be managed on the 
 tenant level or globally.
 
 The key use case here is to delegate administration rights for a group of 
 tenants to a specific user/role. There is something in Keystone called a 
 “domain” which supports part of this functionality, but without support from 
 all of the projects, this concept is pretty useless.
 
 In IRC today I had a brief discussion about how we could address this. I have 
 put some details and a straw man up here:
 
 https://wiki.openstack.org/wiki/HierarchicalMultitenancy
 
 I would like to discuss this strawman and organize a group of people to get 
 actual work done by having an irc meeting this Friday at 1600UTC. I know this 
 time is probably a bit tough for Europe, so if we decide we need a regular 
 meeting to discuss progress then we can vote on a better time for this 
 meeting.
 
 https://wiki.openstack.org/wiki/Meetings#Hierarchical_Multitenancy_Meeting
 
 Please note that this is going to be an active team that produces code. We 
 will *NOT* spend a lot of time debating approaches, and instead focus on 
 making something that works and learning as we go. The output of this team 
 will be a MultiTenant devstack install that actually works, so that we can 
 ensure the features we are adding to each project work together.
 
 Vish
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Hierarchicical Multitenancy Discussion

2014-01-29 Thread Vishvananda Ishaya
For those of you in Europe, I would appreciate your attendance at 2100 UTC if 
you can make it. I know this is a bad time for you, so I will also jump in 
#openstack-meeting-alt on Friday at 1600 UTC. We can have an impromptu 
discussion there so I can incorporate your knowledge and feedback into the 2100 
meeting.

Thanks!

Vish

On Jan 29, 2014, at 7:59 AM, Vishvananda Ishaya vishvana...@gmail.com wrote:

 I apologize for the confusion. The Wiki time of 2100 UTC is the correct time 
 (Noon Pacific time). We can move tne next meeting to a different day/time 
 that is more convienient for Europe.
 
 Vish
 
 
 On Jan 29, 2014, at 1:56 AM, Florent Flament 
 florent.flament-...@cloudwatt.com wrote:
 
 Hi Vishvananda,
 
 I would be interested in such a working group.
 Can you please confirm the meeting hour for this Friday ?
 I've seen 1600 UTC in your email and 2100 UTC in the wiki ( 
 https://wiki.openstack.org/wiki/Meetings#Hierarchical_Multitenancy_Meeting 
 ). As I'm in Europe I'd prefer 1600 UTC.
 
 Florent Flament
 
 - Original Message -
 From: Vishvananda Ishaya vishvana...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Tuesday, January 28, 2014 7:35:15 PM
 Subject: [openstack-dev] Hierarchicical Multitenancy Discussion
 
 Hi Everyone,
 
 I apologize for the obtuse title, but there isn't a better succinct term to 
 describe what is needed. OpenStack has no support for multiple owners of 
 objects. This means that a variety of private cloud use cases are simply not 
 supported. Specifically, objects in the system can only be managed on the 
 tenant level or globally.
 
 The key use case here is to delegate administration rights for a group of 
 tenants to a specific user/role. There is something in Keystone called a 
 “domain” which supports part of this functionality, but without support from 
 all of the projects, this concept is pretty useless.
 
 In IRC today I had a brief discussion about how we could address this. I 
 have put some details and a straw man up here:
 
 https://wiki.openstack.org/wiki/HierarchicalMultitenancy
 
 I would like to discuss this strawman and organize a group of people to get 
 actual work done by having an irc meeting this Friday at 1600UTC. I know 
 this time is probably a bit tough for Europe, so if we decide we need a 
 regular meeting to discuss progress then we can vote on a better time for 
 this meeting.
 
 https://wiki.openstack.org/wiki/Meetings#Hierarchical_Multitenancy_Meeting
 
 Please note that this is going to be an active team that produces code. We 
 will *NOT* spend a lot of time debating approaches, and instead focus on 
 making something that works and learning as we go. The output of this team 
 will be a MultiTenant devstack install that actually works, so that we can 
 ensure the features we are adding to each project work together.
 
 Vish
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Hierarchicical Multitenancy Discussion

2014-01-29 Thread demontie

Hi,

I'm working with multitenancy and I also wanna join this working group, 
but I'm not sure whether I can attend the meeting this Friday.


Demontiê Santos

Em 2014-01-29 12:59, Vishvananda Ishaya escreveu:

I apologize for the confusion. The Wiki time of 2100 UTC is the
correct time (Noon Pacific time). We can move tne next meeting to a
different day/time that is more convienient for Europe.

Vish


On Jan 29, 2014, at 1:56 AM, Florent Flament
florent.flament-...@cloudwatt.com wrote:

Hi Vishvananda,

I would be interested in such a working group.
Can you please confirm the meeting hour for this Friday ?
I've seen 1600 UTC in your email and 2100 UTC in the wiki ( 
https://wiki.openstack.org/wiki/Meetings#Hierarchical_Multitenancy_Meeting 
). As I'm in Europe I'd prefer 1600 UTC.


Florent Flament

- Original Message -
From: Vishvananda Ishaya vishvana...@gmail.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org

Sent: Tuesday, January 28, 2014 7:35:15 PM
Subject: [openstack-dev] Hierarchicical Multitenancy Discussion

Hi Everyone,

I apologize for the obtuse title, but there isn't a better succinct 
term to describe what is needed. OpenStack has no support for multiple 
owners of objects. This means that a variety of private cloud use cases 
are simply not supported. Specifically, objects in the system can only 
be managed on the tenant level or globally.


The key use case here is to delegate administration rights for a group 
of tenants to a specific user/role. There is something in Keystone 
called a “domain” which supports part of this functionality, but 
without support from all of the projects, this concept is pretty 
useless.


In IRC today I had a brief discussion about how we could address this. 
I have put some details and a straw man up here:


https://wiki.openstack.org/wiki/HierarchicalMultitenancy

I would like to discuss this strawman and organize a group of people to 
get actual work done by having an irc meeting this Friday at 1600UTC. I 
know this time is probably a bit tough for Europe, so if we decide we 
need a regular meeting to discuss progress then we can vote on a better 
time for this meeting.


https://wiki.openstack.org/wiki/Meetings#Hierarchical_Multitenancy_Meeting

Please note that this is going to be an active team that produces code. 
We will *NOT* spend a lot of time debating approaches, and instead 
focus on making something that works and learning as we go. The output 
of this team will be a MultiTenant devstack install that actually 
works, so that we can ensure the features we are adding to each project 
work together.


Vish

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Hierarchicical Multitenancy Discussion

2014-01-29 Thread Dolph Mathews
CC'd Adam Young

Several of us were very much in favor of this around the Folsom release,
but we settled on domains as a solution to the most immediate use case
(isolation between flat collections of tenants, without impacting the rest
of openstack). I don't think it has been discussed much in the keystone
community since, but it's still a concept that I'm very much interested in,
as it's much more powerful than domains when it comes to issues like
granular delegation.


On Tue, Jan 28, 2014 at 12:35 PM, Vishvananda Ishaya
vishvana...@gmail.comwrote:

 Hi Everyone,

 I apologize for the obtuse title, but there isn't a better succinct term
 to describe what is needed. OpenStack has no support for multiple owners of
 objects. This means that a variety of private cloud use cases are simply
 not supported. Specifically, objects in the system can only be managed on
 the tenant level or globally.

 The key use case here is to delegate administration rights for a group of
 tenants to a specific user/role. There is something in Keystone called a
 “domain” which supports part of this functionality, but without support
 from all of the projects, this concept is pretty useless.

 In IRC today I had a brief discussion about how we could address this. I
 have put some details and a straw man up here:

 https://wiki.openstack.org/wiki/HierarchicalMultitenancy

 I would like to discuss this strawman and organize a group of people to
 get actual work done by having an irc meeting this Friday at 1600UTC. I
 know this time is probably a bit tough for Europe, so if we decide we need
 a regular meeting to discuss progress then we can vote on a better time for
 this meeting.

 https://wiki.openstack.org/wiki/Meetings#Hierarchical_Multitenancy_Meeting

 Please note that this is going to be an active team that produces code. We
 will *NOT* spend a lot of time debating approaches, and instead focus on
 making something that works and learning as we go. The output of this team
 will be a MultiTenant devstack install that actually works, so that we can
 ensure the features we are adding to each project work together.

 Vish

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Hierarchicical Multitenancy Discussion

2014-01-28 Thread Chmouel Boudjnah
On Tue, Jan 28, 2014 at 7:35 PM, Vishvananda Ishaya
vishvana...@gmail.comwrote:

 The key use case here is to delegate administration rights for a group of
 tenants to a specific user/role. There is something in Keystone called a
 domain which supports part of this functionality, but without support
 from all of the projects, this concept is pretty useless.



FYI: swift and keystoneauth allow to have cross project ACLs

Chmouel.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev