Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Adrian Otto]

> On Mar 22, 2017, at 5:48 AM, Ricardo Rocha  wrote:
> 
> Hi.
> 
> One simplification would be:
> openstack coe create/list/show/config/update
> openstack coe template create/list/show/update
> openstack coe ca show/sign

I like Ricardo’s suggestion above. I think we should decide between the option 
above (Option 1), and this one (Option 2):

openstack coe cluster create/list/show/config/update
openstack coe cluster template create/list/show/update
openstack coe ca show/sign

Both options are clearly unique to magnum, and are unlikely to cause any future 
collisions with other projects. If you have a preference, please express it so 
we can consider your input and proceed with the implementation. I have a slight 
preference for Option 2 because it more closely reflects how I think about what 
the commands do, and follows the noun/verb pattern correctly. Please share your 
feedback.

Thanks,

Adrian

> This covers all the required commands and is a bit less verbose. The
> cluster word is too generic and probably adds no useful info.
> 
> Whatever it is, kerberos support for the magnum client is very much
> needed and welcome! :)
> 
> Cheers,
>  Ricardo
> 
> On Tue, Mar 21, 2017 at 2:54 PM, Spyros Trigazis  wrote:
>> 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  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.
>>> 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 [1]:
>> "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.
>> 
>> [1] https://wiki.openstack.org/wiki/Magnum
>> 
>>> 
>>> 
>>> 
>>> $ openstack --help | grep cluster
>>> 
>>>  --os-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 

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Ricardo Rocha]

Hi.

One simplification would be:
openstack coe create/list/show/config/update
openstack coe template create/list/show/update
openstack coe ca show/sign

This covers all the required commands and is a bit less verbose. The
cluster word is too generic and probably adds no useful info.

Whatever it is, kerberos support for the magnum client is very much
needed and welcome! :)

Cheers,
  Ricardo

On Tue, Mar 21, 2017 at 2:54 PM, Spyros Trigazis  wrote:
> 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  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.
>> 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 [1]:
> "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.
>
> [1] https://wiki.openstack.org/wiki/Magnum
>
>>
>>
>>
>> $ openstack --help | grep cluster
>>
>>   --os-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 

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Qiming Teng]

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 
> >
> >  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 

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Kumari, Madhuri]

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.

Regards,
Madhuri

From: Spyros Trigazis [mailto:strig...@gmail.com]
Sent: Tuesday, March 21, 2017 7:25 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@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 
<teng...@linux.vnet.ibm.com<mailto:teng...@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:
> >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.
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 [1]:
"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.

[1] https://wiki.openstack.org/wiki/Magnum



$ openstack --help | grep cluster

  --os-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  Delet

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Spyros Trigazis]

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  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.
> 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 [1]:
"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.

[1] https://wiki.openstack.org/wiki/Magnum


>
>
> $ openstack --help | grep cluster
>
>   --os-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.
>   

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Jay Pipes]

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.


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 

  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 

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Anne Gentle]

On Mon, Mar 20, 2017 at 4:38 PM, Dean Troyer  wrote:

> On Mon, Mar 20, 2017 at 4:36 PM, Adrian Otto 
> wrote:
> > So, to be clear, this would result in the following command for what we
> currently use “magnum cluster create” for:
> >
> > openstack coe cluster create …
> >
> > Is this right?
>
> Yes.
>
>
This looks good to me as an OSC user.

One other question, I honestly can't remember if the projects.yaml name
needs to match the service catalog name? Might be a good time to synch
everything if so. Right now, it's "Container Infrastructure Management
service" and could be Container Orchestration Engine Management service.

Naming, it's hard.
Anne


> dt
>
> --
>
> Dean Troyer
> dtro...@gmail.com
>
> __
> 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
>



-- 

Read my blog: justwrite.click 
Subscribe to Docs|Code: docslikecode.com
__
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

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Monty Taylor]

On 03/20/2017 08:16 PM, Dean Troyer wrote:
> On Mon, Mar 20, 2017 at 5:52 PM, Monty Taylor  wrote:
>>> [Hongbin Lu]
>>> I think the style would be more consistent if all the resources are 
>>> qualified or un-qualified, not the mix of both.
> 
>> So - swift got here first, it wins, it gets container. The fine folks in
>> barbican, rather than calling a thing a container and then needing to
>> call it a secret-container - maybe could call their thing a vault or a
>> locker or a safe or a lockbox or an oubliette. (for instance)
> 
> Right, there _were_ only 5 projects when we started this and we
> re-used most of the original project-specific names.  Swift is a
> particularly fun one because both 'container' and 'object' are
> extrement useful in that context, but both are also extremely generic,
> and 'object container', well, what is that?
> 
>> I do not have any suggestions for things that actually return a resource
>> that are a single "linux container" - since swift called their thing a
>> container before docker was written and popularized the word to mean
>> something different. We might just get to be fun and different - sort of
>> like how Emacs calls cut/paste "kill" and "yank" (if you're not an Emacs
>> user, you "kill" text into the kill ring and then you "yank" from the
>> ring into the current document.
> 
> Monty, grab your Tardis and follow me around the Austin summit and
> listen to the opinions I get for doing things like this :)

Which Austin summit - haven't we been at two together now?. ;)

>> OTOH, I think Dean has talked about more verbose terms and then aliases
>> for backwards compat. So maybe a swift container is always an
>> "object_container" - but because of history it gets to also be
>> unqualified "container" - but then we could have "object container" and
>> "secret container" and "linux container" ... similarly we could have
>> "server flavor" and "volume flavor" ... etc.
> 
> Yes, we do have plans to go back and qualify some of these resource
> names to be consistent, but the current names will probably never
> change, we'll just have the qualified names for those who prefer to
> use them.
> 
> Flavor is my favorite example of this as we add network flavor, and
> others.  It also illustrates the 'it isn't a namespace' as it will
> become 'server flavor' rather than 'compute flavor'.

Yes - that's an excellent example.

I think one of the most important thing to realize is that our project
organization is much less interesting to our API consumers than it is to
developers and operators. _especially_ when some things move their
project home over time. (is it compute floating-ip? is it network
floating-ip?) And that a single project could have more than one thing
that is similar in different contexts (we have both a ComputeUsage and a
ServerUsage - with ServerUsage being the usage for a specific server
while ComputeUsage is the aggregate compute usage for a project)

Yay naming!

__
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

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Qiming Teng]

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.
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?


$ openstack --help | grep cluster

  --os-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 runRun 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 

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Dean Troyer]

On Mon, Mar 20, 2017 at 5:52 PM, Monty Taylor  wrote:
>> [Hongbin Lu]
>> I think the style would be more consistent if all the resources are 
>> qualified or un-qualified, not the mix of both.

> So - swift got here first, it wins, it gets container. The fine folks in
> barbican, rather than calling a thing a container and then needing to
> call it a secret-container - maybe could call their thing a vault or a
> locker or a safe or a lockbox or an oubliette. (for instance)

Right, there _were_ only 5 projects when we started this and we
re-used most of the original project-specific names.  Swift is a
particularly fun one because both 'container' and 'object' are
extrement useful in that context, but both are also extremely generic,
and 'object container', well, what is that?

> I do not have any suggestions for things that actually return a resource
> that are a single "linux container" - since swift called their thing a
> container before docker was written and popularized the word to mean
> something different. We might just get to be fun and different - sort of
> like how Emacs calls cut/paste "kill" and "yank" (if you're not an Emacs
> user, you "kill" text into the kill ring and then you "yank" from the
> ring into the current document.

Monty, grab your Tardis and follow me around the Austin summit and
listen to the opinions I get for doing things like this :)

> OTOH, I think Dean has talked about more verbose terms and then aliases
> for backwards compat. So maybe a swift container is always an
> "object_container" - but because of history it gets to also be
> unqualified "container" - but then we could have "object container" and
> "secret container" and "linux container" ... similarly we could have
> "server flavor" and "volume flavor" ... etc.

Yes, we do have plans to go back and qualify some of these resource
names to be consistent, but the current names will probably never
change, we'll just have the qualified names for those who prefer to
use them.

Flavor is my favorite example of this as we add network flavor, and
others.  It also illustrates the 'it isn't a namespace' as it will
become 'server flavor' rather than 'compute flavor'.

dt

-- 

Dean Troyer
dtro...@gmail.com

__
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

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Monty Taylor]

On 03/20/2017 05:39 PM, Hongbin Lu wrote:
> 
> 
>> -Original Message-
>> From: Dean Troyer [mailto:dtro...@gmail.com]
>> Sent: March-20-17 5:19 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [magnum][osc] What name to use for magnum
>> commands in osc?
>>
>> On Mon, Mar 20, 2017 at 3:37 PM, Adrian Otto <adrian.o...@rackspace.com>
>> wrote:
>>> the  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?
>>
>> I am going to jump in here and clarify one thing.  OSC does not do
>> project namespacing, or any other sort of namespacing for its resource
>> names.  It uses qualified resource names (fully-qualified even?).  In
>> some cases this results in something that looks a lot like namespacing,
>> but it isn't. The Volume API commands are one example of this, nearly
>> every resource there includes the word 'volume' but not because that is
>> the API name, it is because that is the correct name for those
>> resources ('volume backup', etc).
> 
> [Hongbin Lu] I might provide a minority point of view here. What confused me 
> is inconsistent style of the resource name. For example, there is a 
> "container" resource for a swift container, and there is "secret container" 
> resource a barbican container. I just found it odd to have both un-qualified 
> resource (i.e. container) and qualified resource name (i.e. secret container) 
> in the same CLI. It appears to me that some resources are namespaced and 
> others are not, and this kind of style provides a suboptimal user experiences 
> from my point of view.
> 
> I think the style would be more consistent if all the resources are qualified 
> or un-qualified, not the mix of both.

Yes - if we had been more forward thinking a while back, I think we
could do that. However, some things are already done and changing them
would be an incredible amount of churn.

In my happy world, we would all consider the resource names that exist
across the openstack projects before we make new ones.

So - swift got here first, it wins, it gets container. The fine folks in
barbican, rather than calling a thing a container and then needing to
call it a secret-container - maybe could call their thing a vault or a
locker or a safe or a lockbox or an oubliette. (for instance)

I do not have any suggestions for things that actually return a resource
that are a single "linux container" - since swift called their thing a
container before docker was written and popularized the word to mean
something different. We might just get to be fun and different - sort of
like how Emacs calls cut/paste "kill" and "yank" (if you're not an Emacs
user, you "kill" text into the kill ring and then you "yank" from the
ring into the current document.

OTOH, I think Dean has talked about more verbose terms and then aliases
for backwards compat. So maybe a swift container is always an
"object_container" - but because of history it gets to also be
unqualified "container" - but then we could have "object container" and
"secret container" and "linux container" ... similarly we could have
"server flavor" and "volume flavor" ... etc.

(fwiw, shade just picks winners - so "create_container" gets you a swift
container. No clue what we'll do when we add barbican or zun yet ...
mabye the same thing?)
>>
>>> 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.
>>
>> Naming resources is hard to get right.  Here's my throught process:
>>
>> For OSC, start with how to describe the specific 'thing' being
>> manipulated.  In this case, it is some kind of cluster.  In the list
>> you posted in the first email, 'coe cluster' seems to be the best
>> option.  I think 'coe' is acceptable as an abbreviation (we usually do
>> not use them) because that is a specific term used in the field and
>> satisfies the 'what kind of cluster?' question.  No underscores please,
>> and in fact no dash here, resource names have spaces in them.
>>
>> dt
>>
>> --
>>
>> Dean Troyer
>> dtro...@gmail.com
>>
>> ___
>> ___
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-
>> requ...@lists.openstack.org?subject:uns

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Hongbin Lu]

> -Original Message-
> From: Dean Troyer [mailto:dtro...@gmail.com]
> Sent: March-20-17 5:19 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum][osc] What name to use for magnum
> commands in osc?
> 
> On Mon, Mar 20, 2017 at 3:37 PM, Adrian Otto <adrian.o...@rackspace.com>
> wrote:
> > the  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?
> 
> I am going to jump in here and clarify one thing.  OSC does not do
> project namespacing, or any other sort of namespacing for its resource
> names.  It uses qualified resource names (fully-qualified even?).  In
> some cases this results in something that looks a lot like namespacing,
> but it isn't. The Volume API commands are one example of this, nearly
> every resource there includes the word 'volume' but not because that is
> the API name, it is because that is the correct name for those
> resources ('volume backup', etc).

[Hongbin Lu] I might provide a minority point of view here. What confused me is 
inconsistent style of the resource name. For example, there is a "container" 
resource for a swift container, and there is "secret container" resource a 
barbican container. I just found it odd to have both un-qualified resource 
(i.e. container) and qualified resource name (i.e. secret container) in the 
same CLI. It appears to me that some resources are namespaced and others are 
not, and this kind of style provides a suboptimal user experiences from my 
point of view.

I think the style would be more consistent if all the resources are qualified 
or un-qualified, not the mix of both.

> 
> > 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.
> 
> Naming resources is hard to get right.  Here's my throught process:
> 
> For OSC, start with how to describe the specific 'thing' being
> manipulated.  In this case, it is some kind of cluster.  In the list
> you posted in the first email, 'coe cluster' seems to be the best
> option.  I think 'coe' is acceptable as an abbreviation (we usually do
> not use them) because that is a specific term used in the field and
> satisfies the 'what kind of cluster?' question.  No underscores please,
> and in fact no dash here, resource names have spaces in them.
> 
> dt
> 
> --
> 
> Dean Troyer
> dtro...@gmail.com
> 
> ___
> ___
> 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

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Clint Byrum]

Excerpts from Adrian Otto's message of 2017-03-20 22:19:14 +:
> I was unsure, so I found him on IRC to clarify, and he pointed me to the 
> openstack/service-types-authority repository, where I submitted patch 445694 
> for review. We have three distinct identifiers in play:
> 
> 1) Our existing service catalog entry name: container-infra
> 2) Our openstack client noun: TBD, decision expected from our team tomorrow. 
> My suggestion: "coe cluster”.
> 3) Our (proposed) service type: coe-cluster
> 
> Each identifier has respective guidelines and limits, so they differ.
> 
> Adrian

Oh neat, I didn't even know that repository existed. TIL.

__
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

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Adrian Otto]

Clint,

On Mar 20, 2017, at 3:02 PM, Clint Byrum 
> wrote:

Excerpts from Adrian Otto's message of 2017-03-20 21:16:09 +:
Jay,

On Mar 20, 2017, at 12:35 PM, 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.

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?

I propose "coe-cluster” for that, but that should be discussed further, as it’s 
impossible for magnum to conform with all the requirements for service types 
because they fundamentally conflict with each other:

https://review.openstack.org/447694

In the past we referred to this type as a “bay” but found it burdensome for 
users and operators to use that term when literally bay == cluster. We just 
needed to call it what it is because there’s a prevailing name for that 
concept, and everyone expects that’s what it’s called.

I Think Jay was asking for Magnum's name in the catalog:

Which is 'container-infra' according to this:

https://github.com/openstack/python-magnumclient/blob/master/magnumclient/v1/client.py#L34

I was unsure, so I found him on IRC to clarify, and he pointed me to the 
openstack/service-types-authority repository, where I submitted patch 445694 
for review. We have three distinct identifiers in play:

1) Our existing service catalog entry name: container-infra
2) Our openstack client noun: TBD, decision expected from our team tomorrow. My 
suggestion: "coe cluster”.
3) Our (proposed) service type: coe-cluster

Each identifier has respective guidelines and limits, so they differ.

Adrian
__
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

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Clint Byrum]

Excerpts from Adrian Otto's message of 2017-03-20 21:16:09 +:
> Jay,
> 
> On Mar 20, 2017, at 12:35 PM, 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.
> 
> >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?
> 
> I propose "coe-cluster” for that, but that should be discussed further, as 
> it’s impossible for magnum to conform with all the requirements for service 
> types because they fundamentally conflict with each other:
> 
> https://review.openstack.org/447694
> 
> In the past we referred to this type as a “bay” but found it burdensome for 
> users and operators to use that term when literally bay == cluster. We just 
> needed to call it what it is because there’s a prevailing name for that 
> concept, and everyone expects that’s what it’s called.

I Think Jay was asking for Magnum's name in the catalog:

Which is 'container-infra' according to this:

https://github.com/openstack/python-magnumclient/blob/master/magnumclient/v1/client.py#L34

__
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

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Dean Troyer]

On Mon, Mar 20, 2017 at 4:36 PM, Adrian Otto  wrote:
> So, to be clear, this would result in the following command for what we 
> currently use “magnum cluster create” for:
>
> openstack coe cluster create …
>
> Is this right?

Yes.

dt

-- 

Dean Troyer
dtro...@gmail.com

__
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

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Adrian Otto]

Dean,

Thanks for your reply.

> On Mar 20, 2017, at 2:18 PM, Dean Troyer  wrote:
> 
> On Mon, Mar 20, 2017 at 3:37 PM, Adrian Otto  
> wrote:
>> the  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?
> 
> I am going to jump in here and clarify one thing.  OSC does not do
> project namespacing, or any other sort of namespacing for its resource
> names.  It uses qualified resource names (fully-qualified even?).  In
> some cases this results in something that looks a lot like
> namespacing, but it isn't. The Volume API commands are one example of
> this, nearly every resource there includes the word 'volume' but not
> because that is the API name, it is because that is the correct name
> for those resources ('volume backup', etc).

Okay, that makes sense, thanks.

>> 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.
> 
> Naming resources is hard to get right.  Here's my throught process:
> 
> For OSC, start with how to describe the specific 'thing' being
> manipulated.  In this case, it is some kind of cluster.  In the list
> you posted in the first email, 'coe cluster' seems to be the best
> option.  I think 'coe' is acceptable as an abbreviation (we usually do
> not use them) because that is a specific term used in the field and
> satisfies the 'what kind of cluster?' question.  No underscores
> please, and in fact no dash here, resource names have spaces in them.

So, to be clear, this would result in the following command for what we 
currently use “magnum cluster create” for:

openstack coe cluster create …

Is this right?

Adrian

> 
> dt
> 
> -- 
> 
> Dean Troyer
> dtro...@gmail.com
> 
> __
> 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

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Dean Troyer]

On Mon, Mar 20, 2017 at 3:37 PM, Adrian Otto  wrote:
> the  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?

I am going to jump in here and clarify one thing.  OSC does not do
project namespacing, or any other sort of namespacing for its resource
names.  It uses qualified resource names (fully-qualified even?).  In
some cases this results in something that looks a lot like
namespacing, but it isn't. The Volume API commands are one example of
this, nearly every resource there includes the word 'volume' but not
because that is the API name, it is because that is the correct name
for those resources ('volume backup', etc).

> 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.

Naming resources is hard to get right.  Here's my throught process:

For OSC, start with how to describe the specific 'thing' being
manipulated.  In this case, it is some kind of cluster.  In the list
you posted in the first email, 'coe cluster' seems to be the best
option.  I think 'coe' is acceptable as an abbreviation (we usually do
not use them) because that is a specific term used in the field and
satisfies the 'what kind of cluster?' question.  No underscores
please, and in fact no dash here, resource names have spaces in them.

dt

-- 

Dean Troyer
dtro...@gmail.com

__
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

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Adrian Otto]

Jay,

On Mar 20, 2017, at 12:35 PM, 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.

>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?

I propose "coe-cluster” for that, but that should be discussed further, as it’s 
impossible for magnum to conform with all the requirements for service types 
because they fundamentally conflict with each other:

https://review.openstack.org/447694

In the past we referred to this type as a “bay” but found it burdensome for 
users and operators to use that term when literally bay == cluster. We just 
needed to call it what it is because there’s a prevailing name for that 
concept, and everyone expects that’s what it’s called.

Adrian


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

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Adrian Otto]

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]   [parameters]

the  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

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Hongbin Lu]

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.

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

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Jay Pipes]

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

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Adrian Otto]

Kevin,

I added that to the list for consideration.Feel free to add others to the list 
on the team agenda using our Wiki page.

Adrian

> On Mar 20, 2017, at 12:27 PM, Fox, Kevin M <kevin@pnnl.gov> wrote:
> 
> What about coe?
> 
> Thanks,
> Kevin
> 
> From: Adrian Otto [adrian.o...@rackspace.com]
> Sent: Monday, March 20, 2017 12:08 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [magnum][osc] What name to use for magnum commands   
>   in osc?
> 
> 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. 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. 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.
> 
> Thanks,
> 
> Adrian
> 
> __
> 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

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

[Fox, Kevin M]

What about coe?

Thanks,
Kevin

From: Adrian Otto [adrian.o...@rackspace.com]
Sent: Monday, March 20, 2017 12:08 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [magnum][osc] What name to use for magnum commands 
in osc?

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. 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. 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.

Thanks,

Adrian

__
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-dev] [magnum][osc] What name to use for magnum commands in osc?

[Adrian Otto]

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. 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. 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.

Thanks,

Adrian

__
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