Open Stack

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.mcginnis at 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
> > > <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.
> >
>
> 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-
> > > request at 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-request at 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-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/20160830/65d71f97/attachment.html>