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/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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
