On Mon, Aug 29, 2016 at 09:29:57AM -0400, Andrew Laski wrote: > > > > On Mon, Aug 29, 2016, at 09:06 AM, Jordan Pittier wrote: > > > > > > On Mon, Aug 29, 2016 at 8:50 AM, Zhenyu Zheng > > <zhengzhenyul...@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. >
FWIW, I get asked the question on the Cinder side of how to specify which volume type to use when booting from a Cinder volume on a fairly regular basis. I agree with the approach of not adding more proxy functionality in Nova, but since this is an existing feature that is missing expected functionality, I would like to see this get in. Just my $0.02. Sean > > > > > > > ____________________________________________________________________- > > ________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: OpenStack-dev- > > requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev