[openstack-dev] [magnum][osc] What name to use for magnum commands in osc?
jaypipes at gmail.com
Tue Mar 21 14:50:13 UTC 2017
On 03/20/2017 09:24 PM, Qiming Teng 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.
Note that above I referred to the Senlin *API*:
The use of generic terms like "cluster", "node", "policy", "profile",
"action", and "event" as *top-level resources in the REST API* are what
I was warning about.
> Please see the following outputs. All commands are contained in the
> cluster namespace to avoid any conflicts with any other projects.
Right, but I was talking about the REST API.
> On the other hand, is there any document stating that Magnum is about
> providing clustering service?
What exactly is a clustering service?
I mean, Galera has a clustering service. Pacemaker has a clustering
service. k8s has a clustering service. etcd has a clustering service.
Zookeeper has a clustering service.
Senlin is an API that allows a user to group *virtual machines* together
and expand or shrink that group of VMs. It's basically the old Heat
autoscaling API done properly. There's a *lot* to like about Senlin's
API and implementation.
However, it would have been more appropriate (and forward-looking) to
call Senlin's namespace "instance group" or "server group" than the
generic term "cluster".
> Why Magnum cares so much about the top
> level noun if it is not its business?
Because Magnum uses the term "cluster" as a top-level resource in its
own REST API:
The generic term "cluster" that Magnum uses should really be called "coe
group" or "container engine group" or "container service group" or
something like that, to better indicate what exactly is being operated on.
> $ openstack --help | grep cluster
> --os-clustering-api-version <clustering-api-version>
> 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
> specified nodes.
> 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.
> - Qiming
>>> 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
More information about the OpenStack-dev