<div dir="ltr">Dear all,<div><br></div><div>Thanks all for the reply, I have read the etherpad note and there seems no working BP/SPEC now.</div><div>So I have updated one BP/SPEC from my colleague put up for Mitaka with microversion implementation for Ocata release:</div><div>BP: <a href="https://blueprints.launchpad.net/nova/+spec/add-volume-type-when-boot-instances">https://blueprints.launchpad.net/nova/+spec/add-volume-type-when-boot-instances</a></div><div>SPEC: <a href="https://review.openstack.org/#/c/362698/">https://review.openstack.org/#/c/362698/</a></div><div><br></div><div>I'm aiming to implement this useful feature for O release :-)</div><div><br></div><div>Thanks,</div><div><br></div><div>Kevin Zheng</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 30, 2016 at 3:35 AM, Sean McGinnis <span dir="ltr"><<a href="mailto:sean.mcginnis@gmx.com" target="_blank">sean.mcginnis@gmx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Aug 29, 2016 at 09:29:57AM -0400, Andrew Laski wrote:<br>
><br>
><br>
><br>
> On Mon, Aug 29, 2016, at 09:06 AM, Jordan Pittier wrote:<br>
> ><br>
> ><br>
> > On Mon, Aug 29, 2016 at 8:50 AM, Zhenyu Zheng<br>
> > <<a href="mailto:zhengzhenyulixi@gmail.com">zhengzhenyulixi@gmail.com</a>> wrote:<br>
> >> Hi, all<br>
> >><br>
> >> Currently we have customer demands about adding parameter<br>
> >> "volume_type" to --block-device to provide the support of specified<br>
> >> storage backend to boot instance. And I find one newly drafted<br>
> >> Blueprint that aiming to address the same feature:<br>
> >> <a href="https://blueprints.launchpad.net/nova/+spec/support-boot-instance-set-store-type" rel="noreferrer" target="_blank">https://blueprints.launchpad.<wbr>net/nova/+spec/support-boot-<wbr>instance-set-store-type</a><br>
> >> ;<br>
> >><br>
> >> As I know this is kind of "proxy" feature for cinder and we don't<br>
> >> like it in general, but as the boot from volume functional was<br>
> >> already there, so maybe it is OK to support another parameter?<br>
> >><br>
> >> So, my question is that what are your opinions about this in general?<br>
> >> Do you like it or it will not be able to got approved at all?<br>
> >><br>
> >> Thanks,<br>
> >><br>
> >> Kevin Zheng<br>
> ><br>
> > Hi,<br>
> > I think it's not a great idea. Not only for the reason you mention,<br>
> > but also because the "nova boot" command is already way to complicated<br>
> > with way to many options. IMO we should only add support for new<br>
> > features, not "features" we can have by other means, just for<br>
> > convenience.<br>
><br>
> I completely agree with this. However I have some memory of us<br>
> saying(in Austin?) that adding volume_type would be acceptable since<br>
> it's a clear oversight in the list of parameters for specifying a block<br>
> device. So while I greatly dislike Nova creating volumes and would<br>
> rather users pass in pre-created volume ids I would support adding this<br>
> parameter. I do not support continuing to add parameters if Cinder adds<br>
> parameters though.<br>
><br>
<br>
</div></div>FWIW, I get asked the question on the Cinder side of how to specify<br>
which volume type to use when booting from a Cinder volume on a fairly<br>
regular basis.<br>
<br>
I agree with the approach of not adding more proxy functionality in<br>
Nova, but since this is an existing feature that is missing expected<br>
functionality, I would like to see this get in.<br>
<br>
Just my $0.02.<br>
<br>
Sean<br>
<br>
><br>
> ><br>
> ><br>
> > ______________________________<wbr>______________________________<wbr>________-<br>
<div class="HOEnZb"><div class="h5">> > ________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: OpenStack-dev-<br>
> > <a href="http://request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">request@lists.openstack.org?<wbr>subject:unsubscribe</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>