Re: [openstack-dev] [cinder] Bug#1231298 - size parameter for volume creation

2014-08-12 Thread Duncan Thomas
On 11 August 2014 21:03, Dean Troyer  wrote:
> On Mon, Aug 11, 2014 at 5:34 PM, Duncan Thomas 
> wrote:
>>
>> Making an previously mandatory parameter optional, at least on the
>> command line, does break backward compatibility though, does it?
>> Everything that worked before will still work.
>
>
> By itself, maybe that is ok.  You're right, nothing _should_ break.  But
> then the following is legal:
>
> cinder create
>
> What does that do?

It returns an error. The following becomes legal though:

cinder create --src-volume aaa-bbb-ccc-ddd

cinder create --snapshot aaa-bbb-ccc-ddd

cinder create --image aaa-bbb-ccc-ddd


-- 
Duncan Thomas

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [cinder] Bug#1231298 - size parameter for volume creation

2014-08-11 Thread Dean Troyer
On Mon, Aug 11, 2014 at 5:34 PM, Duncan Thomas 
wrote:
>
> Making an previously mandatory parameter optional, at least on the
> command line, does break backward compatibility though, does it?
> Everything that worked before will still work.
>

By itself, maybe that is ok.  You're right, nothing _should_ break.  But
then the following is legal:

cinder create

What does that do?

dt

-- 

Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [cinder] Bug#1231298 - size parameter for volume creation

2014-08-11 Thread Duncan Thomas
On 8 August 2014 07:55, Dean Troyer  wrote:
> In cinderclient I think you're stuck with size as a mandatory argument to
> the 'cinder create' command, as you must be backward-compatible for at least
> a deprecation period.[0]

Making an previously mandatory parameter optional, at least on the
command line, does break backward compatibility though, does it?
Everything that worked before will still work.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [cinder] Bug#1231298 - size parameter for volume creation

2014-08-08 Thread Vishvananda Ishaya

On Aug 8, 2014, at 6:55 AM, Dean Troyer  wrote:

> On Fri, Aug 8, 2014 at 12:36 AM, Ganapathy, Sandhya 
>  wrote:
> This is to discuss Bug #1231298 – 
> https://bugs.launchpad.net/cinder/+bug/1231298
> 
> ... 
> Conclusion reached with this bug is that, we need to modify cinder client in 
> order to accept optional size parameter (as the cinder’s API allows)  and 
> calculate the size automatically during volume creation from image.
> 
> There is also an opinion that size should not be an optional parameter during 
> volume creation – does this mean, Cinder’s API should be changed in order to 
> make size a mandatory parameter.
> 
> 
> In cinderclient I think you're stuck with size as a mandatory argument to the 
> 'cinder create' command, as you must be backward-compatible for at least a 
> deprecation period.[0]
> 
> Your option here[1] is to use a sentinel value for size that indicates the 
> actual volume size should be calculated and let the client do the right thing 
> under the hood to feed the server API.  Other project CLIs have used both 
> 'auto' and '0' in situations like this.  I'd suggest '0' as it is still an 
> integer and doesn't require potentially user-error-prone string matching to 
> work.

We did this for novaclient volume attach and allowed device to be ‘auto' or the 
argument to be omitted. I don’t see a huge problem turning size into an 
optional parameter as long as it doesn’t break older scripts. Turning it from 
an arg into a kwarg would definitely require deprecation.

Vish

> 
> FWIW, this is why OSC changed 'volume create' to make --size an option and 
> make the volume name be the positional argument.
> 
> [0] The deprecation period for clients is ambiguous as the release cycle 
> isn't timed but we think of deprecations that way.  Using integrated release 
> cycles is handy but less than perfect to correlate to the client's semver 
> releases.
> [1] Bad pun alert...or is there such a thing as a bad pun???
> 
> dt
> 
> -- 
> 
> Dean Troyer
> dtro...@gmail.com
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [cinder] Bug#1231298 - size parameter for volume creation

2014-08-08 Thread Dean Troyer
On Fri, Aug 8, 2014 at 12:36 AM, Ganapathy, Sandhya <
sandhya.ganapa...@hp.com> wrote:

>  This is to discuss Bug #1231298 –
> https://bugs.launchpad.net/cinder/+bug/1231298
>
...

> Conclusion reached with this bug is that, we need to modify cinder client
> in order to accept optional size parameter (as the cinder’s API allows)
>  and calculate the size automatically during volume creation from image.
>
> There is also an opinion that size should not be an optional parameter
> during volume creation – does this mean, Cinder’s API should be changed in
> order to make size a mandatory parameter.
>

In cinderclient I think you're stuck with size as a mandatory argument to
the 'cinder create' command, as you must be backward-compatible for at
least a deprecation period.[0]

Your option here[1] is to use a sentinel value for size that indicates the
actual volume size should be calculated and let the client do the right
thing under the hood to feed the server API.  Other project CLIs have used
both 'auto' and '0' in situations like this.  I'd suggest '0' as it is
still an integer and doesn't require potentially user-error-prone string
matching to work.

FWIW, this is why OSC changed 'volume create' to make --size an option and
make the volume name be the positional argument.

[0] The deprecation period for clients is ambiguous as the release cycle
isn't timed but we think of deprecations that way.  Using integrated
release cycles is handy but less than perfect to correlate to the client's
semver releases.
[1] Bad pun alert...or is there such a thing as a bad pun???

dt

-- 

Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev