Open Stack

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.montgomery at 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.mahimane at RACKSPACE.COM> wrote:
> 
>> 
>> 
>> On 12/3/13 7:51 AM, "Roshan Agrawal" <roshan.agrawal at RACKSPACE.COM> wrote:
>> 
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Russell Bryant [mailto:rbryant at redhat.com]
>>>> Sent: Monday, December 02, 2013 8:17 PM
>>>> To: openstack-dev at 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 at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev