Open Stack

Hongbin,

> On Mar 20, 2017, at 1:10 PM, Hongbin Lu <hongbin.lu at huawei.com> wrote:
> 
> Zun had a similar issue of colliding on the keyword "container", and we chose to use an alternative term "appcontainer" that is not perfect but acceptable. IMHO, this kind of top-level name collision issue would be better resolved by introducing namespace per project, which is the approach adopted by AWS.

Can you explain this further, please? My understanding is that the AWS cli tool has a single global namespace for commands in the form:

aws [options] <command> <subcommand> [parameters]

the <command> argument is actually the service name, such as “ec2”. This is the same way the openstack cli works. Perhaps there is another tool that you are referring to. Have I misunderstood something?

We could so the same thing and use the text “container_infra”, but we felt that might be burdensome for interactive use and wanted to find something shorter that would still make sense.

Thanks,

Adrian

> 
> Best regards,
> Hongbin
> 
>> -----Original Message-----
>> From: Jay Pipes [mailto:jaypipes at gmail.com]
>> Sent: March-20-17 3:35 PM
>> To: openstack-dev at lists.openstack.org
>> Subject: Re: [openstack-dev] [magnum][osc] What name to use for magnum
>> commands in osc?
>> 
>> On 03/20/2017 03:08 PM, Adrian Otto wrote:
>>> Team,
>>> 
>>> Stephen Watson has been working on an magnum feature to add magnum
>> commands to the openstack client by implementing a plugin:
>>> 
>>> 
>> https://review.openstack.org/#/q/status:open+project:openstack/python-
>>> magnumclient+osc
>>> 
>>> In review of this work, a question has resurfaced, as to what the
>> client command name should be for magnum related commands. Naturally,
>> we’d like to have the name “cluster” but that word is already in use by
>> Senlin.
>> 
>> Unfortunately, the Senlin API uses a whole bunch of generic terms as
>> top-level REST resources, including "cluster", "event", "action",
>> "profile", "policy", and "node". :( I've warned before that use of
>> these generic terms in OpenStack APIs without a central group
>> responsible for curating the API would lead to problems like this. This
>> is why, IMHO, we need the API working group to be ultimately
>> responsible for preventing this type of thing from happening. Otherwise,
>> there ends up being a whole bunch of duplication and same terms being
>> used for entirely different things.
>> 
>>> Stephen opened a discussion with Dean Troyer about this, and found
>> that “infra” might be a suitable name and began using that, and
>> multiple team members are not satisfied with it.
>> 
>> Yeah, not sure about "infra". That is both too generic and not an
>> actual "thing" that Magnum provides.
>> 
>>> The name “magnum” was excluded from consideration because OSC aims
>> to be project name agnostic. We know that no matter what word we pick,
>> it’s not going to be ideal. I’ve added an agenda on our upcoming team
>> meeting to judge community consensus about which alternative we should
>> select:
>>> 
>>> https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2017-
>> 03
>>> -21_1600_UTC
>>> 
>>> Current choices on the table are:
>>> 
>>>  * c_cluster (possible abbreviation alias for
>> container_infra_cluster)
>>>  * coe_cluster
>>>  * mcluster
>>>  * infra
>>> 
>>> For example, our selected name would appear in “openstack …” commands.
>> Such as:
>>> 
>>> $ openstack c_cluster create …
>>> 
>>> If you have input to share, I encourage you to reply to this thread,
>> or come to the team meeting so we can consider your input before the
>> team makes a selection.
>> 
>> What is Magnum's service-types-authority service_type?
>> 
>> Best,
>> -jay
>> 
>> _______________________________________________________________________
>> ___
>> 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