Open Stack

>Do you mean OpenStack developers, OpenStack customers, or OpenStack code?

All of them. Lots of us still say 'tenant' because that's what it was for
quite a while. However, with keystone and the other projects referring to
'projects' which have 'project_ids', it creates inconsistency when Neutron
is still based on 'tenant_id' (e.g. "does tenant_id mean user_id or
project_id?").

>I'm not sure what you mean here.

Neutron is inconsistent with openstack now. We can't claim we are striving
for consistency when using the term 'tenant', which is what you were
implying with the reference to the rest of the networking world.

>Dariusz asked for feedback, and I believe it's valid and useful for me to
give my intuitive feedback without having to read up on the history first.

It wasn't just the history, it's the whole justification for the move. I
can definitely see why you would be against it though if you thought it was
for no reason.


>and noted a couple of points:

>1. The text here twice says "multi-tenant isolation", not "multi-project
isolation".

>2. This whole renaming proposal apparently stems from an internal
confusion in keystone?

None of this matters. It was decided a long time ago to use 'project' and
the other projects have switched.


On Fri, Dec 4, 2015 at 10:23 AM, Neil Jerram <Neil.Jerram at metaswitch.com>
wrote:

> On 04/12/15 18:03, Kevin Benton wrote:
> > >The whole world says 'tenant' for the 'tenant' concept, particularly
> > in the context of networking.  Changing to a different term is just
> > silly.
> >
> > Except for the rest of OpenStack.
>
> Do you mean OpenStack developers, OpenStack customers, or OpenStack code?
>
> OpenStack developers mostly say 'tenant', I'd say from my following of
> the ML.
>
> All the OpenStack users/operators/customers that I've interacted with,
> say 'tenant'.
>
> As far as code is concerned, I'm fine with any initiative to align the
> Neutron code better with other OpenStack code - but only so long as this
> is change that doesn't cause pain and loss of back-compatibility.  Even
> the merge pain from this change may be substantial, let alone that from
> API changes.
>
> > Consistency is the one argument we can't use as a reason not to switch
> > to project.
>
> I'm not sure what you mean here.
>
> > Please read the blueprint and the email it links
> > to:
> https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project
>
> Dariusz asked for feedback, and I believe it's valid and useful for me
> to give my intuitive feedback without having to read up on the history
> first.
>
> Also it seems likely to me that the fact that this work hasn't happened,
> for two years, is a reflection of most people not really wanting it.  I
> thought it might be helpful to get that out in the open.
>
> That said, I did look at some of the history -
>
> https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg09709.html
> :
>
> > +1 for using the term "project" across all services. Projects provide
> > multi-tenant isolation for resources across the cloud. Part of the reason
> > we prefer "projects" in keystone is that "domains" conceptually provide
> > multi-tenant isolation within keystone itself, so the overloaded "tenant"
> > terminology gets really confusing.
>
> and noted a couple of points:
>
> 1. The text here twice says "multi-tenant isolation", not "multi-project
> isolation".
>
> 2. This whole renaming proposal apparently stems from an internal
> confusion in keystone?
>
> Regards,
>     Neil
>
>
> __________________________________________________________________________
> 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
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151204/f54a3993/attachment.html>