Open Stack

On Tue, Jan 29, 2013 at 11:58:39AM -0800, Vishvananda Ishaya wrote:
> On Jan 29, 2013, at 6:18 AM, Daniel P. Berrange <berrange at redhat.com> wrote:
> 
> > On Wed, Jan 23, 2013 at 07:41:19PM +0000, Daniel P. Berrange wrote:
> >> I think one of the things I'd like to see before looking at any further
> >> patches is a clear illustration of the various different config scenarios
> >> we're aiming at supporting.
> >> 
> >> eg a set of  nova boot command line examples, showing how to express
> >> all the different possible configurations we need.
> >> 
> >> It is hard to infer what is possible in this respect from just looking
> >> at patch reviews.
> > 
> > I created a wiki page describing what I think we need to be able to
> > handle in terms of block device mapping for Nova in general. This is
> > basically the set of parameters described in the test Vish quoted
> > earlier in this thread. In addition though, I have had a go at
> > specifying a suitable syntax for 'nova boot' (and friends) to use
> > for specifying the block device mapping
> > 
> >  http://wiki.openstack.org/BlockDeviceConfig
> > 
> > my intent is that this obsoletes the '--image' and '--block-deice-mapping'
> > parameters, though they obviously need to remain for back compatibility
> > so can't just be removed. The new syntax is intended to be more expressive
> > to facilitate readability and future expansion should we need it.
> > 
> > The missing piece is describing what data format we should use at the
> > API level, and then possibly what we need todo about data stored in
> > the DB for this - how to migrate existing data to any new schema used.
> > 
> 
> Thanks for doing this! I was planning on putting together something similar.
> 
> A few concerns/suggestions:
> 
> a) There doesn't seem to be any way to specify a snapshot which is something
> we currently support. This may be due to the lack of b) below, but we definitely
> need some way to support that existing functionality unless we are going to
> handle the creation of the volume from the snapshot client side.

Doh, my bad, I completely forgot about snapshots. I'll look at extending it
to cover that.

> b) There is no concept of dest-type so I assume we would be going with
> auto-generating dest-type from source? Glance -> local, Ephemeral -> local,
> Cinder -> remote.

I'm not entirely sure what you mean by 'dest-type' - can you point to
where this 'dest-type' value is currently specified and/or used ?

> c) I really like the semantics of --image and I wonder if it would be beneficial
> to have a simplified one for as well:
> 
> nova boot --image XXX # required, same as --block type=glance,id=XXX
> nova boot --volume XXX # this would be new, same as --block type=cinder,id=XXX

Sure, we can have convenience args for some more common usages

> d) if someone specifies an invalid or unsupported value for bus, should we fail
> or select a valid one?

My preference is always to report errors to the client, rather than
try to second-guess what they might have wanted & get it wrong.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|