Open Stack

On 4 December 2015 at 13:33, Neil Jerram <Neil.Jerram at metaswitch.com> wrote:

> Really?  I don't want to escalate, but I  think that I'm entitled:
>
>
> - to have an opinion on this, regardless of how much of the history I've
> read
>
>
> - to express that opinion in response to an explicit request for "any
> feedback", particularly when no one else had responded to that call for
> nearly 24 hours.
>
> FWIW, it's also fine with me that there is apparently a strong consensus
> _for_ this change, and I'm happy to reflect and ponder that my intuition
> might be wrong.  I'd rather have stuck my neck out and contributed to a
> discussion, than be asked later "why did no one say anything?"
>

Of course you're entitled to an opinion, no-one is taking that away from
you. All I am saying is that things may not sound so silly as you claim if
you knew the whole story, that's all!

>
>     Neil
>
> ------------------------------
> *From:* Armando M. <armamig at gmail.com>
> *Sent:* 04 December 2015 21:01
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron] Rename tenant to project:
> discussion
>
>
>
> On 4 December 2015 at 08:46, Neil Jerram <Neil.Jerram at metaswitch.com>
> wrote:
>
>> I'm new to this discussion, but you did ask for any feedback, so ...
>>
>> On 03/12/15 18:29, Smigiel, Dariusz wrote:
>> > Hey Neutrinos (thanks armax for this word :),
>> > Keystone is planning to deprecate V2 API (again :). This time in Mitaka
>> [6], and probably forever. It will stay at least four releases, but we need
>> to decide, how to conquer problem of renaming...
>> > And more important: consider if it's a problem for Neutron?
>> >
>> > I'm looking at blueprint [1] about renaming all occurrences of 'tenant'
>> to 'project', and trying to find out all the details.
>> > First attempt to solve this problem was raised in November 2013 [4][5]
>> but unfortunately, no one finished it. Although Keystone V3 API is already
>> supported in Neutron client [2], there are still some unknowns about
>> Neutron server side. Monty Taylor is trying to address necessary (if any)
>> changes [3].
>> >
>> > Findings:
>> > I've focused on two projects: python-neutronclient and neutron.
>> > grep found 429 occurrences of 'tenant' in Client while Server has 3021
>> of it. Some of them are just documentation and docstrings, but there are a
>> lot of places, where variables are tangled: defined in DB, used in server,
>> accessed by client. Most of places are just internal usages. The only thing
>> where I've found 'public' information about tenants is 'help' command in
>> neutron client.
>> >
>> > Suggested plan for conquer:
>> > 1. First step would be to deal with neutronclient. It's much smaller
>> amount of code to look through, update all places and be successful :)
>> > 2. Bigger challenge will be to change server side code. I'd suggest to
>> start with renaming db columns. It affects a lot of places, so when
>> finished should significantly lower number of remained "tenants".
>> > 3. Deal with all other places.
>> >
>> > Pros:
>> > - variable names unification in OpenStack code base. Someone needs to
>> start this job.
>> > - one way to describe the same thing, instead of:
>> tenant/account/project. Helpful, especially for newcomers.
>> > - alignment with Keystone V3 API
>> >
>> > Cons:
>> > - A. Lot. Of. Work.
>> > - dealing with DB migrations
>> > - about 2-4 weeks of work for every part of code. Additional, a lot of
>> patchsets to be reviewed.
>> >
>> > What do you think about this? About proposed way of dealing with all
>> changes?
>> > Is this change necessary?
>>
>> My intuition is that we should just not do this change.  The whole world
>> says 'tenant' for the 'tenant' concept, particularly in the context of
>> networking.  Changing to a different term is just silly.
>>
>>
> If you don't know the whole story why are you making these remarks?
>
>
>> But I haven't looked into the history.  Perhaps there's some reason we
>> need to anyway.
>
>
>>     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
>>
>
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151204/b108b9d8/attachment.html>