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