Open Stack

On Tue, Mar 21, 2017 at 10:50:13AM -0400, Jay Pipes wrote:
> 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:
> >>>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.
> >>
> >
> >Well, I believe the name and namespaces used by Senlin is very clean.
> 
> Note that above I referred to the Senlin *API*:
> 
> https://developer.openstack.org/api-ref/clustering/
> 
> 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.

Okay, I see where the confusion comes from. Senlin is designed to be a
*generic clustering service* that can create and manage whatever
resource types. It can create VM groups and manage the scaling of such
groups properly. It can provide VM HA based on the resource redundancy.
It models load-balancing support into a policy that can be attached to
and detached from a VM cluster.

Senlin manages "nodes" created from a "profile". A VM instance is only
one of the profile types supported. Senlin also supports clusters of
Heat stacks, clusters of docker containers today. There are also efforts
on managing bare-metal servers. 

The team also uses "resource pools" and "clusters" interchangeably,
because that IS what the service is about. Calling Senlin a resource
pool service may be more confusing, right?

- Qiming

> 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:
> 
> http://git.openstack.org/cgit/openstack/magnum/tree/magnum/api/controllers/v1/cluster.py
> 
> 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.
> 
> Best,
> -jay
> 
> >$ 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.
> >  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:
> >>>
> >>>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.