Open Stack

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.

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.

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

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

Vish