Re: [openstack-dev] Hierarchical administrative boundary [keystone]

[joehuang]

Hi All, 

Totally agree with Allamaraju. Only hierarchical administrative boundary is not 
enough, the definition of internal network architecture within one domain is 
very important. The networking among projects in one domain could be isolated 
or not, the access to external network may be not only controlled at domain 
level, but also at project level. Allamaraju's proposal can solve these issues 
well.

My question is how to solve multi-region scenario?  May the VPC cross multiple 
OpenStack instances?

The role for different resources visibility is also need to be defined for the 
VPC solution.

Best Regards
Chaoyi Huang( Joe Huang)


-邮件原件-
发件人: Allamaraju, Subbu [mailto:su...@subbu.org] 
发送时间: 2014年5月13日 20:55
收件人: OpenStack Development Mailing List (not for usage questions)
主题: Re: [openstack-dev] Hierarchical administrative boundary [keystone]

Hi Arvind,

This seems to be covering one of the use cases listed by 
https://wiki.openstack.org/wiki/Blueprint-VPC. Others to isolate between VPCs 
include shared resources like networks, images, roles, and other configuration. 

Subbu

On May 8, 2014, at 7:55 PM, Tiwari, Arvind  wrote:

> Hi All,
>  
> Below is my proposal to address VPC use case using hierarchical 
> administrative boundary. This topic is scheduled in Hierarchical 
> Multitenancysession of Atlanta design summit.
>  
> https://wiki.openstack.org/wiki/Hierarchical_administrative_boundary
>  
> Please take a look.
>  
> Thanks,
> Arvind
>  
> ___
> 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] Hierarchical administrative boundary [keystone]

[Allamaraju, Subbu]

Hi Arvind,

This seems to be covering one of the use cases listed by 
https://wiki.openstack.org/wiki/Blueprint-VPC. Others to isolate between VPCs 
include shared resources like networks, images, roles, and other configuration. 

Subbu

On May 8, 2014, at 7:55 PM, Tiwari, Arvind  wrote:

> Hi All,
>  
> Below is my proposal to address VPC use case using hierarchical 
> administrative boundary. This topic is scheduled in Hierarchical 
> Multitenancysession of Atlanta design summit.
>  
> https://wiki.openstack.org/wiki/Hierarchical_administrative_boundary
>  
> Please take a look.
>  
> Thanks,
> Arvind
>  
> ___
> 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] Hierarchical administrative boundary [keystone]

[Yaguang Tang]

Tiwari,

Could you elaborate how to solve the issue by using unique role names ?
With domain model, services like nova have to be aware of domain admin user
and cloud admin user by roles.  domain admin
manage IAM resources and non-IAM resources by inheriting  roles to
projects, cloud admin have additional privilege to enable/disable
OpenStack services. But the "admin" role can be granted by a domain user to
its own  user. How nova api identity a user is real admin
 user that in admin domain?


2014-05-10 2:23 GMT+08:00 Tiwari, Arvind :

>  Hi All,
>
>
>
> Thanks for looking in to my proposal. Below are my comments and answers to
> questions which is based on “my personal opinion”.
>
>
>
> *Why domain hierarchy, why not project hierarchy? *Because project
> hierarchy is more impactful and need cross project changes.
>
>
>
> As per my understanding we all are trying to solve one business use
> problem, which is “how to support VPC or Reseller” model on OS based cloud
> deployment.  As per problem described in different proposals, it is purely
> a IAM use case, where different identities (users, admins, reseller ….) has
> different perception about the system/resources (IAM and non IAM) and they
> want ability to manage them.
>
>
>
> Keystone (OS IAM service) abstracts all the IAM complexity  from lower
> level services (Nova, Swift, cinder …) by providing unified integration
> model (auth token and verification by auth middleware). Lover level
> services trusts Keystone and allow access (for particular requests) to
> actual resource based on subject’s roles provided by keystone.
>
>
>
> Each service supports multi tenancy and tenancy mapping is establish by
> keystone through projects.  If hierarchy enforced at project level then we
> need to propagate the hierarchy info to all lower level services, where the
> hierarchy  info is not serving any good purpose but just used to map one
> tenant. Enforcing the hierarchy at project level is more impactful because
> all services have to change their implementation to consume the notion of
> hierarchy. Propagating project hierarchy to services would make sense if
> end resources (VMs, cinder volumes , swift resource ….) does obey the
> hierarchy based on projects, I think that is not the case.
>
>
>
> As per definition domains are container for projects, users and groups and
> maps well with a business entities (ProductionIT, SuperDevShop,
> WidgetMaster, SPI, reseller .). Using domain to establish hierarchy (as
> per my design) will abstract the complexity from lower level services.
> Services don’t have to worry about the domain hierarchy and we can retain
> the current integration (Keystone project <-> service Tenant ) model and no
> need to make big change in different service. Mostly one place change which
> is Keystone.
>
>
>
> *Services has to be domain aware*
>
>
>
> IMO services (Nova, Swift …) don’t have to be domain aware (Unless I am
> missing something) as they manage resources for keystone projects. Domain
> is IAM concept which used to scope IAM resources and not very useful for
> end services. I think what we are lacking is unique role (role name) per
> service, having unique role names for each service (IAM, Nova, Swift ….)
>  will resolve the problem mentioned below by  Yaguang Tang.
>
>
>
> Please let me know why services have to be domain aware?
>
>
>
> Thoughts?
>
>
>
> Thanks,
>
> Arvind
>
>
>
> Note:
>
> IAM Resources – Users, groups, projects …
>
> Non IAM resources – VMs, Swift objects, …….
>
>
>
> *From:* Yaguang Tang [mailto:yaguang.t...@canonical.com]
> *Sent:* Friday, May 09, 2014 4:33 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
>
> *Subject:* Re: [openstack-dev] Hierarchical administrative boundary
> [keystone]
>
>
>
> *Frittoli,*
>
>
>
> I think for other services we could achieve that by  modifying  the
> policy.json( add domain admin role and control what the cloud admin can do
> ) so that domain admin user is able to manage resources belong to
>
> users and projects in that domain.
>
>
>
> 2014-05-09 15:24 GMT+08:00 Frittoli, Andrea (HP Cloud) :
>
> *From:* Adam Young [mailto:ayo...@redhat.com]
> *Sent:* 09 May 2014 04:19
> *To:* openstack-dev@lists.openstack.org
> *Subject:* Re: [openstack-dev] Hierarchical administrative boundary
> [keystone]
>
>
>
> On 05/08/2014 07:55 PM, Tiwari, Arvind wrote:
>
>  Hi All,
>
>
>
> Below is my proposal to address VPC use case using hierarchical
> administrative boundary. This topic is scheduled in Hierarchical
> Multitenancy<http://junodesignsummit.sched.org/even

Re: [openstack-dev] Hierarchical administrative boundary [keystone]

[Tiwari, Arvind]

Hi All,

Thanks for looking in to my proposal. Below are my comments and answers to 
questions which is based on “my personal opinion”.

Why domain hierarchy, why not project hierarchy? Because project hierarchy is 
more impactful and need cross project changes.

As per my understanding we all are trying to solve one business use problem, 
which is “how to support VPC or Reseller” model on OS based cloud deployment.  
As per problem described in different proposals, it is purely a IAM use case, 
where different identities (users, admins, reseller ….) has different 
perception about the system/resources (IAM and non IAM) and they want ability 
to manage them.

Keystone (OS IAM service) abstracts all the IAM complexity  from lower level 
services (Nova, Swift, cinder …) by providing unified integration model (auth 
token and verification by auth middleware). Lover level services trusts 
Keystone and allow access (for particular requests) to actual resource based on 
subject’s roles provided by keystone.

Each service supports multi tenancy and tenancy mapping is establish by 
keystone through projects.  If hierarchy enforced at project level then we need 
to propagate the hierarchy info to all lower level services, where the 
hierarchy  info is not serving any good purpose but just used to map one 
tenant. Enforcing the hierarchy at project level is more impactful because all 
services have to change their implementation to consume the notion of 
hierarchy. Propagating project hierarchy to services would make sense if end 
resources (VMs, cinder volumes , swift resource ….) does obey the hierarchy 
based on projects, I think that is not the case.

As per definition domains are container for projects, users and groups and maps 
well with a business entities (ProductionIT, SuperDevShop, WidgetMaster, SPI, 
reseller .). Using domain to establish hierarchy (as per my design) will 
abstract the complexity from lower level services. Services don’t have to worry 
about the domain hierarchy and we can retain the current integration (Keystone 
project <-> service Tenant ) model and no need to make big change in different 
service. Mostly one place change which is Keystone.

Services has to be domain aware

IMO services (Nova, Swift …) don’t have to be domain aware (Unless I am missing 
something) as they manage resources for keystone projects. Domain is IAM 
concept which used to scope IAM resources and not very useful for end services. 
I think what we are lacking is unique role (role name) per service, having 
unique role names for each service (IAM, Nova, Swift ….)  will resolve the 
problem mentioned below by  Yaguang Tang.

Please let me know why services have to be domain aware?

Thoughts?

Thanks,
Arvind

Note:
IAM Resources – Users, groups, projects …
Non IAM resources – VMs, Swift objects, …….

From: Yaguang Tang [mailto:yaguang.t...@canonical.com]
Sent: Friday, May 09, 2014 4:33 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Hierarchical administrative boundary [keystone]

Frittoli,

I think for other services we could achieve that by  modifying  the 
policy.json( add domain admin role and control what the cloud admin can do ) so 
that domain admin user is able to manage resources belong to
users and projects in that domain.

2014-05-09 15:24 GMT+08:00 Frittoli, Andrea (HP Cloud) 
mailto:fritt...@hp.com>>:
From: Adam Young [mailto:ayo...@redhat.com<mailto:ayo...@redhat.com>]
Sent: 09 May 2014 04:19
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] Hierarchical administrative boundary [keystone]

On 05/08/2014 07:55 PM, Tiwari, Arvind wrote:
Hi All,

Below is my proposal to address VPC use case using hierarchical administrative 
boundary. This topic is scheduled in Hierarchical 
Multitenancy<http://junodesignsummit.sched.org/event/20465cd62e9054d4043dda156da5070e#.U2wYXXKLR_9>
 session of Atlanta design summit.

https://wiki.openstack.org/wiki/Hierarchical_administrative_boundary

Please take a look.

Thanks,
Arvind




___

OpenStack-dev mailing list



OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Looks very good.  One question:  Why hierarchical domains and not Projects.  
I'm not disagreeing, mind you, just that I think the Nova team is going for 
hierarchical Projects.


Looks good, thank you!

But for this to be even more interesting nova (and other services) should be 
domain aware – e.g. so that a domain admin could have control on all resources 
which belong to users and projects in that domain.

andrea


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.opens

Re: [openstack-dev] Hierarchical administrative boundary [keystone]

[Yaguang Tang]

Frittoli,

I think for other services we could achieve that by  modifying  the
policy.json( add domain admin role and control what the cloud admin can do
) so that domain admin user is able to manage resources belong to
users and projects in that domain.


2014-05-09 15:24 GMT+08:00 Frittoli, Andrea (HP Cloud) :

> *From:* Adam Young [mailto:ayo...@redhat.com]
> *Sent:* 09 May 2014 04:19
> *To:* openstack-dev@lists.openstack.org
> *Subject:* Re: [openstack-dev] Hierarchical administrative boundary
> [keystone]
>
>
>
> On 05/08/2014 07:55 PM, Tiwari, Arvind wrote:
>
> Hi All,
>
>
>
> Below is my proposal to address VPC use case using hierarchical
> administrative boundary. This topic is scheduled in Hierarchical
> Multitenancy<http://junodesignsummit.sched.org/event/20465cd62e9054d4043dda156da5070e#.U2wYXXKLR_9>session
>  of Atlanta design summit.
>
>
>
> https://wiki.openstack.org/wiki/Hierarchical_administrative_boundary
>
>
>
> Please take a look.
>
>
>
> Thanks,
>
> Arvind
>
>
>
>
>
>
> ___
>
> OpenStack-dev mailing list
>
> OpenStack-dev@lists.openstack.org
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> Looks very good.  One question:  Why hierarchical domains and not
> Projects.  I'm not disagreeing, mind you, just that I think the Nova team
> is going for hierarchical Projects.
>
>
> *--*
>
> Looks good, thank you!
>
>
>
> But for this to be even more interesting nova (and other services) should
> be domain aware – e.g. so that a domain admin could have control on all
> resources which belong to users and projects in that domain.
>
>
>
> andrea
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Tang Yaguang

Canonical Ltd. | www.ubuntu.com | www.canonical.com
Mobile:  +86 152 1094 6968
gpg key: 0x187F664F
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Hierarchical administrative boundary [keystone]

[Frittoli, Andrea (HP Cloud)]

From: Adam Young [mailto:ayo...@redhat.com] 
Sent: 09 May 2014 04:19
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Hierarchical administrative boundary [keystone]

 

On 05/08/2014 07:55 PM, Tiwari, Arvind wrote:

Hi All,

 

Below is my proposal to address VPC use case using hierarchical
administrative boundary. This topic is scheduled in Hierarchical
Multitenancy
<http://junodesignsummit.sched.org/event/20465cd62e9054d4043dda156da5070e#.U
2wYXXKLR_9>  session of Atlanta design summit.

 

https://wiki.openstack.org/wiki/Hierarchical_administrative_boundary

 

Please take a look.

 

Thanks,

Arvind

 






___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org <mailto:OpenStack-dev@lists.openstack.org>

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Looks very good.  One question:  Why hierarchical domains and not Projects.
I'm not disagreeing, mind you, just that I think the Nova team is going for
hierarchical Projects. 

 

  _  

Looks good, thank you!

 

But for this to be even more interesting nova (and other services) should be
domain aware - e.g. so that a domain admin could have control on all
resources which belong to users and projects in that domain.

 

andrea

 



smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Hierarchical administrative boundary [keystone]

[Adam Young]

On 05/08/2014 07:55 PM, Tiwari, Arvind wrote:


Hi All,

Below is my proposal to address VPC use case using hierarchical 
administrative boundary. This topic is scheduled in Hierarchical 
Multitenancy 
 
session of Atlanta design summit.


https://wiki.openstack.org/wiki/Hierarchical_administrative_boundary

Please take a look.

Thanks,

Arvind



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Looks very good.  One question:  Why hierarchical domains and not 
Projects.  I'm not disagreeing, mind you, just that I think the Nova 
team is going for hierarchical Projects.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Hierarchical administrative boundary [keystone]

[Tiwari, Arvind]

Hi All,

Below is my proposal to address VPC use case using hierarchical administrative 
boundary. This topic is scheduled in Hierarchical 
Multitenancy
 session of Atlanta design summit.

https://wiki.openstack.org/wiki/Hierarchical_administrative_boundary

Please take a look.

Thanks,
Arvind

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