Dear all, Thanks all for the reply, I have read the etherpad note and there seems no working BP/SPEC now. So I have updated one BP/SPEC from my colleague put up for Mitaka with microversion implementation for Ocata release: BP: https://blueprints.launchpad.net/nova/+spec/add-volume-type-when-boot-instances SPEC: https://review.openstack.org/#/c/362698/
I'm aiming to implement this useful feature for O release :-) Thanks, Kevin Zheng On Tue, Aug 30, 2016 at 3:35 AM, Sean McGinnis <sean.mcgin...@gmx.com> wrote: > 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 >
__________________________________________________________________________ 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