Open Stack

On Mon, Aug 29, 2016, at 09:06 AM, Jordan Pittier wrote:
>
>
> On Mon, Aug 29, 2016 at 8:50 AM, Zhenyu Zheng
> <zhengzhenyulixi at gmail.com> wrote:
>> Hi, all
>>
>> Currently we have customer demands about adding parameter
>> "volume_type" to --block-device to provide the support of specified
>> storage backend to boot instance. And I find one newly drafted
>> Blueprint that aiming to address the same feature:
>> https://blueprints.launchpad.net/nova/+spec/support-boot-instance-set-store-type
>> ;
>>
>> As I know this is kind of "proxy" feature for cinder and we don't
>> like it in general, but as the boot from volume functional was
>> already there, so maybe it is OK to support another parameter?
>>
>> So, my question is that what are your opinions about this in general?
>> Do you like it or it will not be able to got approved at all?
>>
>> Thanks,
>>
>> Kevin Zheng
>
> Hi,
> I think it's not a great idea. Not only for the reason you mention,
> but also because the "nova boot" command is already way to complicated
> with way to many options. IMO we should only add support for new
> features, not "features" we can have by other means, just for
> convenience.

I completely agree with this. However I have some memory of us
saying(in Austin?) that adding volume_type would be acceptable since
it's a clear oversight in the list of parameters for specifying a block
device. So while I greatly dislike Nova creating volumes and would
rather users pass in pre-created volume ids I would support adding this
parameter. I do not support continuing to add parameters if Cinder adds
parameters though.


>
>
> ____________________________________________________________________-
> ________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160829/84c8cc70/attachment.html>