Roshan, I have added some comments to the Etherpad - https://etherpad.openstack.org/p/MinimalCLI
-Arati On 12/3/13 10:27 AM, "Randall Burt" <randall.b...@rackspace.com> wrote: >I disagree. If a param is required and has no meaningful default, it >should be positional IMO. I think this actually reduces confusion as you >can tell from the signature alone that this is a value the user must >supply to have any meaningful thing happen. > >On Dec 3, 2013, at 10:13 AM, Paul Montgomery ><paul.montgom...@rackspace.com> > wrote: > >> I agree. With many optional parameters possible, positional parameters >> would seem to complicate things a bit (even for end users). >> >> >> On 12/3/13 8:14 AM, "Arati Mahimane" <arati.mahim...@rackspace.com> >>wrote: >> >>> >>> >>> On 12/3/13 7:51 AM, "Roshan Agrawal" <roshan.agra...@rackspace.com> >>>wrote: >>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Russell Bryant [mailto:rbry...@redhat.com] >>>>> Sent: Monday, December 02, 2013 8:17 PM >>>>> To: openstack-dev@lists.openstack.org >>>>> Subject: Re: [openstack-dev] [Solum] CLI minimal implementation >>>>> >>>>> On 12/02/2013 07:03 PM, Roshan Agrawal wrote: >>>>>> I have created a child blueprint to define scope for the minimal >>>>> implementation of the CLI to consider for milestone 1. >>>>>> >>>>> >>>>>https://blueprints.launchpad.net/solum/+spec/cli-minimal-implementatio >>>>>> n >>>>>> >>>>>> Spec for the minimal CLI @ >>>>>> >>>>> >>>>>https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/CLI-minimal-im >>>>>> plementation Etherpad for discussion notes: >>>>>> https://etherpad.openstack.org/p/MinimalCLI >>>>>> >>>>>> Would look for feedback on the ML, etherpad and discuss more in the >>>>> weekly IRC meeting tomorrow. >>>>> >>>>> What is this R1.N syntax? How does it relate to development >>>>> milestones? >>>>> Does R1 mean a requirement for milestone-1? >>>> >>>> These do not relate to development milestones. R1 is a unique >>>>identified >>>> for the given requirement. R1.x is a unique requirement Id for >>>>something >>>> that is a sub item of the top level requirement R1. >>>> Is there a more "openstack standard way" for generating requirements >>>>Id? >>>> >>>>> For consistency, I would use commands like: >>>>> >>>>> solum app-create >>>>> solum app-delete >>>>> solum assembly-create >>>>> solum assembly-delete >>>>> >>>>> instead of adding a space in between: >>>>> >>>>> solum app create >>>>> >>>>> to be more consistent with other clients, like: >>>>> >>>>> nova flavor-create >>>>> nova flavor-delete >>>>> glance image-create >>>>> glance image-delete >>>> >>>> The current proposal is an attempt to be consistent with the direction >>>> for the "openstack one CLI". Adrian's addressed it in his other reply. >>>> >>>> >>>>> I would make required arguments positional arguments. So, instead >>>>>of: >>>>> >>>>> solum app-create --plan=planname >>>>> >>>>> do: >>>>> >>>>> solum app-create <planname> >>>> >>>> I will make this change unless hear objections >>> >>> In my opinion, since most of the parameters (listed here >>> >>>https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/ApplicationDeplo >>>ym >>> e >>> ntAndManagement#Solum-R1.12_app_create:_CLI) are optional, >>> it would be easier to specify the parameters as <param_name>=<value> >>> instead of having positional parameters. >>> >>> >>>> >>>> >>>>> Lastly, everywhere you have a name, I would use a UUID. Names >>>>> shouldn't >>>>> have to be globally unique (because of multi-tenancy). UUIDs should >>>>> always >>>>> work, but you can support a name in the client code as a friendly >>>>> shortcut, >>>>> but it should fail if a unique result can not be resolved from the >>>>> name. >>>> >>>> >>>> Names do not have to be globally unique; just unique within the tenant >>>> namespace. The Name+tenant combination should map to a unique uuid. >>>> The CLI is a client tool, where as a user working with names is >>>>easier. >>>> We will support both, but start with Names (the friendly shortcut), >>>>and >>>> map it to uuid behind the scenes. >>>> >>>> >>>>> -- >>>>> Russell Bryant >>>>> >>>>> _______________________________________________ >>>>> OpenStack-dev mailing list >>>>> OpenStack-dev@lists.openstack.org >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> OpenStack-dev@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >_______________________________________________ >OpenStack-dev mailing list >OpenStack-dev@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev