Open Stack

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