> On Mar 22, 2017, at 5:48 AM, Ricardo Rocha <rocha.po...@gmail.com> 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 <strig...@gmail.com> 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 <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 <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. >>>> >>> >>> >>> __________________________________________________________________________ >>> 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 __________________________________________________________________________ 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
