Re: [openstack-dev] [all] Policy rules for APIs based on "domain_id"

2017-06-20 Thread Lance Bragstad
Domain support hasn't really been adopted across various OpenStack
projects, yet. Ocata was the first release where we had a v3-only
jenkins job set up for projects to run against (domains are a v3-only
concept in keystone and don't really exist in v2.0).

I think it would be great to push on some of that work so that we can
start working the concept of domain-scope into various services. I'd be
happy to help here. John Garbutt had some good ideas on this track, too.

https://review.openstack.org/#/c/433037/
https://review.openstack.org/#/c/427872/

On 06/20/2017 08:59 AM, Valeriy Ponomaryov wrote:
> Also, one more additional kind of "feature-request" is to be able to
> filter each project's entities per domain as well as we can do it with
> project/tenant now.
>
> So, as a result, we will be able to configure different "list" APIs to
> return objects grouped by either domain or project.
>
> Thoughts?
>
> On Tue, Jun 20, 2017 at 1:07 PM, Adam Heczko  > wrote:
>
> Hello Valeriy,
> agree, that would be very useful. I think that this deserves
> attention and cross project discussion.
> Maybe a community goal process [2] is a valid path forward in this
> regard.
>
> [2] https://governance.openstack.org/tc/goals/
> 
>
> On Tue, Jun 20, 2017 at 11:15 AM, Valeriy Ponomaryov
> > wrote:
>
> Hello OpenStackers,
>
> Wanted to pay some attention to one of restrictions in OpenStack.
> It came out, that it is impossible to define policy rules for
> API services based on "domain_id".
> As far as I know, only Keystone supports it.
>
> So, it is unclear whether it is intended or it is just
> technical debt that each OpenStack project should
> eliminate?
>
> For the moment, I filed bug [1].
>
> Use case is following: usage of Keystone API v3 all over the
> cloud and level of trust is domain, not project.
>
> And if it is technical debt how much different teams are
> interested in having such possibility?
>
> [1] https://bugs.launchpad.net/nova/+bug/1699060
> 
>
> -- 
> Kind Regards
> Valeriy Ponomaryov
> www.mirantis.com 
> vponomar...@mirantis.com 
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
>
>
>
>
> -- 
> Adam Heczko
> Security Engineer @ Mirantis Inc.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
>
>
>
>
> -- 
> Kind Regards
> Valeriy Ponomaryov
> www.mirantis.com 
> vponomar...@mirantis.com 
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] Policy rules for APIs based on "domain_id"

2017-06-20 Thread Valeriy Ponomaryov
Also, one more additional kind of "feature-request" is to be able to filter
each project's entities per domain as well as we can do it with
project/tenant now.

So, as a result, we will be able to configure different "list" APIs to
return objects grouped by either domain or project.

Thoughts?

On Tue, Jun 20, 2017 at 1:07 PM, Adam Heczko  wrote:

> Hello Valeriy,
> agree, that would be very useful. I think that this deserves attention and
> cross project discussion.
> Maybe a community goal process [2] is a valid path forward in this regard.
>
> [2] https://governance.openstack.org/tc/goals/
>
> On Tue, Jun 20, 2017 at 11:15 AM, Valeriy Ponomaryov <
> vponomar...@mirantis.com> wrote:
>
>> Hello OpenStackers,
>>
>> Wanted to pay some attention to one of restrictions in OpenStack.
>> It came out, that it is impossible to define policy rules for API
>> services based on "domain_id".
>> As far as I know, only Keystone supports it.
>>
>> So, it is unclear whether it is intended or it is just technical debt
>> that each OpenStack project should
>> eliminate?
>>
>> For the moment, I filed bug [1].
>>
>> Use case is following: usage of Keystone API v3 all over the cloud and
>> level of trust is domain, not project.
>>
>> And if it is technical debt how much different teams are interested in
>> having such possibility?
>>
>> [1] https://bugs.launchpad.net/nova/+bug/1699060
>>
>> --
>> Kind Regards
>> Valeriy Ponomaryov
>> www.mirantis.com
>> vponomar...@mirantis.com
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Adam Heczko
> Security Engineer @ Mirantis Inc.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomar...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] Policy rules for APIs based on "domain_id"

2017-06-20 Thread Adam Heczko
Hello Valeriy,
agree, that would be very useful. I think that this deserves attention and
cross project discussion.
Maybe a community goal process [2] is a valid path forward in this regard.

[2] https://governance.openstack.org/tc/goals/

On Tue, Jun 20, 2017 at 11:15 AM, Valeriy Ponomaryov <
vponomar...@mirantis.com> wrote:

> Hello OpenStackers,
>
> Wanted to pay some attention to one of restrictions in OpenStack.
> It came out, that it is impossible to define policy rules for API services
> based on "domain_id".
> As far as I know, only Keystone supports it.
>
> So, it is unclear whether it is intended or it is just technical debt that
> each OpenStack project should
> eliminate?
>
> For the moment, I filed bug [1].
>
> Use case is following: usage of Keystone API v3 all over the cloud and
> level of trust is domain, not project.
>
> And if it is technical debt how much different teams are interested in
> having such possibility?
>
> [1] https://bugs.launchpad.net/nova/+bug/1699060
>
> --
> Kind Regards
> Valeriy Ponomaryov
> www.mirantis.com
> vponomar...@mirantis.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Adam Heczko
Security Engineer @ Mirantis Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [all] Policy rules for APIs based on "domain_id"

2017-06-20 Thread Valeriy Ponomaryov
Hello OpenStackers,

Wanted to pay some attention to one of restrictions in OpenStack.
It came out, that it is impossible to define policy rules for API services
based on "domain_id".
As far as I know, only Keystone supports it.

So, it is unclear whether it is intended or it is just technical debt that
each OpenStack project should
eliminate?

For the moment, I filed bug [1].

Use case is following: usage of Keystone API v3 all over the cloud and
level of trust is domain, not project.

And if it is technical debt how much different teams are interested in
having such possibility?

[1] https://bugs.launchpad.net/nova/+bug/1699060

-- 
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomar...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev