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 <[email protected] > <mailto:[email protected]>> 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/ > <https://governance.openstack.org/tc/goals/> > > On Tue, Jun 20, 2017 at 11:15 AM, Valeriy Ponomaryov > <[email protected] <mailto:[email protected]>> 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 > <https://bugs.launchpad.net/nova/+bug/1699060> > > -- > Kind Regards > Valeriy Ponomaryov > www.mirantis.com <http://www.mirantis.com> > [email protected] <mailto:[email protected]> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > [email protected]?subject:unsubscribe > <http://[email protected]?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <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: > [email protected]?subject:unsubscribe > <http://[email protected]?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > > > > > -- > Kind Regards > Valeriy Ponomaryov > www.mirantis.com <http://www.mirantis.com> > [email protected] <mailto:[email protected]> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
