Hongbin, > On Mar 20, 2017, at 1:10 PM, Hongbin Lu <hongbin...@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:jaypi...@gmail.com] >> Sent: March-20-17 3:35 PM >> To: openstack-dev@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- >> 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
