On 4 December 2015 at 13:33, Neil Jerram <neil.jer...@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. <arma...@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.jer...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
