Open Stack

On Jun 3, 2016 12:42, "Lance Bragstad" <lbragstad at gmail.com> wrote:
>
>
>
> On Fri, Jun 3, 2016 at 11:20 AM, Henry Nash <henrynash9 at mac.com> wrote:
>>
>>
>>> On 3 Jun 2016, at 16:38, Lance Bragstad <lbragstad at gmail.com> wrote:
>>>
>>>
>>>
>>> On Fri, Jun 3, 2016 at 3:20 AM, Henry Nash <henrynash9 at mac.com> wrote:
>>>>
>>>>
>>>>> On 3 Jun 2016, at 01:22, Adam Young <ayoung at redhat.com> wrote:
>>>>>
>>>>> On 06/02/2016 07:22 PM, Henry Nash wrote:
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>> As you know, I have been working on specs that change the way we
handle the uniqueness of project names in Newton. The goal of this is to
better support project hierarchies, which as they stand today are
restrictive in that all project names within a domain must be unique,
irrespective of where in the hierarchy that projects sits (unlike, say, the
unix directory structure where a node name only has to be unique within its
parent). Such a restriction is particularly problematic when enterprise
start modelling things like test, QA and production as branches of a
project hierarchy, e.g.:
>>>>>>
>>>>>> /mydivsion/projectA/dev
>>>>>> /mydivsion/projectA/QA
>>>>>> /mydivsion/projectA/prod
>>>>>> /mydivsion/projectB/dev
>>>>>> /mydivsion/projectB/QA
>>>>>> /mydivsion/projectB/prod
>>>>>>
>>>>>> Obviously the idea of a project name (née tenant) being unique has
been around since near the beginning of (OpenStack) time, so we must be
cautions. There are two alternative specs proposed:
>>>>>>
>>>>>> 1) Relax project name constraints:
https://review.openstack.org/#/c/310048/
>>>>>> 2) Hierarchical project naming:
https://review.openstack.org/#/c/318605/
>>>>>>
>>>>>> First, here’s what they have in common:
>>>>>>
>>>>>> a) They both solve the above problem
>>>>>> b) They both allow an authorization scope to use a path rather than
just a simple name, hence allowing you to address a project anywhere in the
hierarchy
>>>>>> c) Neither have any impact if you are NOT using a hierarchy - i.e.
if you just have a flat layer of projects in a domain, then they have no
API or semantic impact (since both ensure that a project’s name must still
be unique within a parent)
>>>>>>
>>>>>> Here’s how the differ:
>>>>>>
>>>>>> - Relax project name constraints (1), keeps the meaning of the
‘name’ attribute of a project to be its node-name in the hierarchy, but
formally relaxes the uniqueness constraint to say that it only has to be
unique within its parent. In other words, let’s really model this a bit
like a unix directory tree.
>>>
>>> I think I lean towards relaxing the project name constraint. The reason
is because we already expose `domain_id`, `parent_id`, and `name` of a
project. By relaxing the constraint we can give the user everything the
need to know about a project without really changing any of these. When
using 3.7, you know what domain your project is in, you know the identifier
of the parent project, and you know that your project name is unique within
the parent.
>>>>>>
>>>>>> - Hierarchical project naming (2), formally changes the meaning of
the ‘name’ attribute to include the path to the node as well as the node
name, and hence ensures that the (new) value of the name attribute remains
unique.
>>>
>>> Do we intend to *store* the full path as the name, or just build it out
on demand? If we do store the full path, we will have to think about our
current data model since the depth of the organization or domain would be
limited by the max possible name length. Will performance be something to
think about building the full path on every request?
>>
>> I now mention this issue in the spec for hierarchical project naming
(the relax naming approach does not suffer this issue). As you say, we’ll
have to change the DB (today it is only 64 chars) if we do store the full
path . This is slightly problematic since the maximum depth of hierarchy is
controlled by a config option, and hence could be changed. We will
absolutely have be able to build the path on-the-fly in order to support
legacy drivers (who won’t be able to store more than 64 chars). We may need
to do some performance tests to ascertain if we can get away with building
the path on-the-fly in all cases and avoid changing the table.  One
additional point is that, of course, the API will return this path whenever
it returns a project - so clients will need to be aware of this increase in
size.
>
>
> These are all good points that continue to push me towards relaxing the
project naming constraint :)
>>>>>>
>>>>>>
>>>>>> While whichever approach we chose would only be included in a new
microversion (3.7) of the Identity API, although some relevant APIs can
remain unaffected for a client talking 3.6 to a Newton server, not all can
be. As pointed out be jamielennox, this is a data modelling problem - if a
Newton server has created multiple projects called “dev” in the hierarchy,
a 3.6 client trying to scope a token simply to “dev” cannot be answered
correctly (and it is proposed we would have to return an HTTP 409 Conflict
error if multiple nodes with the same name were detected). This is true for
both approaches.
>>>>>>
>>>>>> Other comments on the approaches:
>>>>>>
>>>>>> - Having a full path as the name seems duplicative with the current
project entity - since we already return the parent_id (hence parent_id +
name is, today, sufficient to place a project in the hierarchy).
>>>>>
>>>>>
>>>>> The one thing I like is the ability to specify just the full path for
the OS_PROJECT_NAME env var, but we could make that a separate variable.
Just as DOMAIN_ID + PROJECT_NAME is unique today, OS_PROJECT_PATH should be
able to fully specify a project unambiguously.  I'm not sure which would
have a larger impact on users.
>>>>>
>>>> Agreed - and this could be done for both approaches (since this is all
part of the “auth data flow").
>>>>>
>>>>>
>>>>>> - In the past, we have been concerned about the issue of what we do
if there is a project further up the tree that we do not have any roles on.
In such cases, APIs like list project parents will not display anything
other than the project ID for such projects. In the case of making the name
the full path, we would be effectively exposing the name of all projects
above us, irrespective of whether we had roles on them. Maybe this is OK,
maybe it isn’t.
>>>>>
>>>>>
>>>>> I think it is OK.  If this info needs to be hidden from a user, the
project should probably be in a different domain.
>>>>>
>>>>>> - While making the name the path keeps it unique, this is fine if
clients blindly use this attribute to plug back into another API to call.
However if, for example, you are Horizon and are displaying them in a UI
then you need to start breaking down the path into its components, where
you don’t today.
>>>>>> - One area where names as the hierarchical path DOES look right is
calling the /auth/projects API - where what the caller wants is a list of
projects they can scope to - so you WANT this to be the path you can put in
an auth request.
>>>>>>
>>>>>> Given that neither can fully protect a 3.6 client, my personal
preference is to go with the cleaner logical approach which I believe is
the Relax project name constraints (1), with the addition of changing GET
/auth/projects to return the path (since this is a specialised API that
happens before authentication) - but I am open to persuasion (as the song
goes).
>>>>>>
>>>>>> There are those that might say that perhaps we just can’t change
this. I would argue that since this ONLY affects people who actually create
hierarchies and that today such hierarchical use is in its infancy, then
now IS the time to change this. If we leave it too long, then it will
become really hard to change what will by then have become a tough
restriction.
>>>>>>
>>>>>> Henry
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
__________________________________________________________________________
>>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>>> Unsubscribe:
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>>
__________________________________________________________________________
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>>
>>>>
__________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>>
__________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
__________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

My main concern with relaxing the uniqueness is you now have a significant
issue with auth changing. Fundamentally you cannot scope to a project under
a domain by name and domain name alone. This will break current auth paths
and auth mechanisms.

I personally think we are a bit wedged even with microversions without
providing the full path as a name for projects created as such (and current
projects retaining the uniqueness or if created via the old api maintaining
the uniqueness constraint and new api projects not being represented at
all).

So in short, I am strongly against relaxing uniqueness.

New (microversion) would make projects that are only represented by full
path. Old projects could be represented either way. (For auth/crud that
uses project names).

Old microversion api (today) would require uniqueness constraint and not
show/allow full pathname projects.

This way we do not break auth that works today.

Most everyone consumes and stores by id (nova, cinder, etc) so we likely
won't break much with extended project names.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160603/eda3d7e2/attachment.html>