Open Stack

On 06/04/2016 01:53 AM, Morgan Fainberg wrote:
> 
> On Jun 3, 2016 12:42, "Lance Bragstad" <lbragstad at gmail.com
> <mailto:lbragstad at gmail.com>> wrote:
>>
>>
>>
>> On Fri, Jun 3, 2016 at 11:20 AM, Henry Nash <henrynash9 at mac.com
> <mailto:henrynash9 at mac.com>> wrote:
>>>
>>>
>>>> On 3 Jun 2016, at 16:38, Lance Bragstad <lbragstad at gmail.com
> <mailto:lbragstad at gmail.com>> wrote:
>>>>
>>>>
>>>>
>>>> On Fri, Jun 3, 2016 at 3:20 AM, Henry Nash <henrynash9 at mac.com
> <mailto:henrynash9 at mac.com>> wrote:
>>>>>
>>>>>
>>>>>> On 3 Jun 2016, at 01:22, Adam Young <ayoung at redhat.com
> <mailto: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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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.

I agree.

This would break code that exists currently. A microversion is fine for
creating a new api call. A microversion is not ok for fundamentally
breaking the semantics of an existing API. This would be a major API
version bump. It would break existing users with existing code, and
since there _is_ another option on the table that does not break
existing users with existing code, I believe that it is imperative to
select the non-breaking option.

> 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.

End users work by name - but yes, I agree the impact cross-openstack is
unlikely.