[openstack-dev] [magnum][osc] What name to use for magnum commands in osc?
madhuri.kumari at intel.com
Tue Mar 21 17:27:55 UTC 2017
It seems the term COE is a valid term now. I am in favor of having “openstack coe cluster” or “openstack container cluster”.
Using the command “infra” is too generic and doesn’t relate to what Magnum is doing exactly.
From: Spyros Trigazis [mailto:strigazi at gmail.com]
Sent: Tuesday, March 21, 2017 7:25 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?
IMO, coe is a little confusing. It is a term used by people related somehow
to the magnum community. When I describe to users how to use magnum,
I spent a few moments explaining what we call coe.
I prefer one of the following:
* openstack magnum cluster create|delete|...
* openstack mcluster create|delete|...
* both the above
It is very intuitive for users because, they will be using an openstack cloud
and they will be wanting to use the magnum service. So, it only make sense
to type openstack magnum cluster or mcluster which is shorter.
On 21 March 2017 at 02:24, Qiming Teng <tengqim at linux.vnet.ibm.com<mailto:tengqim at linux.vnet.ibm.com>> wrote:
On Mon, Mar 20, 2017 at 03:35:18PM -0400, Jay Pipes wrote:
> On 03/20/2017 03:08 PM, Adrian Otto wrote:
> >Stephen Watson has been working on an magnum feature to add magnum commands to the openstack client by implementing a plugin:
> >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.
Well, I believe the name and namespaces used by Senlin is very clean.
Please see the following outputs. All commands are contained in the
cluster namespace to avoid any conflicts with any other projects.
On the other hand, is there any document stating that Magnum is about
providing clustering service? Why Magnum cares so much about the top
level noun if it is not its business?
From magnum's wiki page :
"Magnum uses Heat to orchestrate an OS image which contains Docker
and Kubernetes and runs that image in either virtual machines or bare
metal in a cluster configuration."
Many services may offer clusters indirectly. Clusters is NOT magnum's focus,
but we can't refer to a collection of virtual machines or physical servers with
another name. Bay proven to be confusing to users. I don't think that magnum
should reserve the cluster noun, even if it was available.
$ openstack --help | grep cluster
cluster action list List actions.
cluster action show Show detailed info about the specified action.
cluster build info Retrieve build information.
cluster check Check the cluster(s).
cluster collect Collect attributes across a cluster.
cluster create Create the cluster.
cluster delete Delete the cluster(s).
cluster event list List events.
cluster event show Describe the event.
cluster expand Scale out a cluster by the specified number of nodes.
cluster list List the user's clusters.
cluster members add Add specified nodes to cluster.
cluster members del Delete specified nodes from cluster.
cluster members list List nodes from cluster.
cluster members replace Replace the nodes in a cluster with
cluster node check Check the node(s).
cluster node create Create the node.
cluster node delete Delete the node(s).
cluster node list Show list of nodes.
cluster node recover Recover the node(s).
cluster node show Show detailed info about the specified node.
cluster node update Update the node.
cluster policy attach Attach policy to cluster.
cluster policy binding list List policies from cluster.
cluster policy binding show Show a specific policy that is bound to
the specified cluster.
cluster policy binding update Update a policy's properties on a
cluster policy create Create a policy.
cluster policy delete Delete policy(s).
cluster policy detach Detach policy from cluster.
cluster policy list List policies that meet the criteria.
cluster policy show Show the policy details.
cluster policy type list List the available policy types.
cluster policy type show Get the details about a policy type.
cluster policy update Update a policy.
cluster policy validate Validate a policy.
cluster profile create Create a profile.
cluster profile delete Delete profile(s).
cluster profile list List profiles that meet the criteria.
cluster profile show Show profile details.
cluster profile type list List the available profile types.
cluster profile type show Show the details about a profile type.
cluster profile update Update a profile.
cluster profile validate Validate a profile.
cluster receiver create Create a receiver.
cluster receiver delete Delete receiver(s).
cluster receiver list List receivers that meet the criteria.
cluster receiver show Show the receiver details.
cluster recover Recover the cluster(s).
cluster resize Resize a cluster.
cluster run Run scripts on cluster.
cluster show Show details of the cluster.
cluster shrink Scale in a cluster by the specified number of nodes.
cluster template list List Cluster Templates.
cluster update Update the cluster.
> >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:
> >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.
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStackemail@example.com?subject:unsubscribe>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev