Open Stack

On Jan 30, 2013, at 2:05 AM, Daniel P. Berrange <berrange at redhat.com> wrote:

> 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.

Nice, thanks.

> 
>> 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 ?

Sorry i confused things by changing what i was calling it. My previous email called
it target-type. Basically it refers to where the bits will live while the guest
is active. From my previous email:

---
5. allow users to specify target_type (optional)
(not mentioned)
src_type tells us where the disk bits come from. Currently we do some magic to
determine where the  bits will live while the guest is active.
volume -> self
snapshot -> new volume
image -> local
blank -> local
We could continue to have a magic mapping like this or we could expose to the user
the ability to specify where the bits should be. This involves nova having more
conversion options, but it could be valuable to specify if it isn't too complex.
---

I think it is fine having this automatically calculated initially, which is what
we do already, but we should keep in mind that we may want to add an extra
parameter for this in the future.

> 
>> 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.

That works for me.

Vish