Thanks, Mark, for this very clear explanation. Some initial thoughts ...
By requiring that a data centre is specified upfront on storage domain
creation, we'd be effectively conflating creation and attachment.
Not necessarily a problem, but it occurred to me that it an initially
unattached state, would a host actually be required for the storage
domain at all? What I mean to say is, if the storage domain is
unattached, does it actually need an NFS mount point? It's not going to
be used in anger when unattached, so surely it doesn't need to be
mounted anywhere. Or have I missed the point?
To continue along that line of reasoning, maybe we should be looking at
the attachment operation as the point at which the host providing the
mount point is specified by the client (or selected automatically, as
the case may be). That way we'd skate around the need to (sometimes)
encapsulate the host in the storage domain representation.
Cheers,
Eoghan
On Wed, 2010-04-21 at 18:10 +0100, Mark McLoughlin wrote:
Hey,
I started taking a look at how we should model storage domains
First off some definitions:
- Data center - toplevel container of host clusters, storage domains
and logical networks; a data center can only use one
type of storage (e.g. NFS or iSCSI, not both)
- Host cluster - a collection of hosts forming a migration domain
(i.e. RHEV-M should be able to migrate a VM to any
host within a given cluster). That implies that all
hosts within a cluster have the same type of CPU and
access to the same storage
- Storage Domain - a pool from which disk images can be allocated for
VMs and templates; e.g. an NFS storage domain is
an NFS mounted directory where RHEV-M can create
disk image as files.
Storage domains can be 'data', 'iso' or
'export'
domains depending on whether they contain disk
images, isos or exported VM images
Storage domains can be attached to and detached
from a data center - i.e. there exists an
"unattached" state where it is not associated with
a data center
Here's what the XML for a storage domain might look like:
<storage_domain>
<id>76d8a12c-8b15-45f9-afc7-510f2377da74</id>
<name>images_0</name>
<link rel="self"
href="/storage_domains/76d8a12c-8b15-45f9-afc7-510f2377da74"/>
<type>data</type>
<link rel="datacenter"
href="/datacenters/24aa455a-4cde-4201-a36b-cd9c4358e902"/>
<storage type="nfs">
<host name="172.31.0.6"/>
<directory path="/exports/RHEV/images/0"/>
</storage>
<available>128849018880</available>
...
</storage_domain>
Pretty straightforward, but there are details worth thinking about:
- I'm using <link/> here, but I think the <object
href="..."/>
equal merit - we've got to decide on this soon :-)
<storage_domain href="...">
...
<datacenter href="..."/>
...
</storage_domain>
- Should 'type' be an attribute?
<storage_domain type='data'>
...
</storage_domain>
- The <host> and <directory> elements I copied from libvirt because I
didn't see any reason not to:
http://libvirt.org/formatstorage.html
Okay, that's all fairly boring so far, but let's look at what parameters
are required to create a storage domain in powershell:
Add-StorageDomain -Storage <String> -HostId <Int32>
-DomainType <StorageDomainType>
-StorageType <StorageType> -Name <String>
That's all fine, except HostId. Notice there is no reference to a host
in the XML modelling above!
That's because a storage domain isn't directly associated with a host,
but you do need a host in order to create it (e.g. some host on which
we'll mount the NFS directory and create the metadata for the domain).
Options I see:
1) Require a 'host' reference in the document POSTed to the
storage_domains collection, but never include a 'host' reference
in a storage domain document returned by the server
POST /storage_domains HTTP/1.1
Content-Type: application/xml
Content-Length: {length}
<storage_domain type='data'>
<name>images_0</name>
<host href='/hosts/288478f3-f4c9-4589-b4f5-d6522501762e'/>
<storage type='nfs'>
<host name='172.31.0.6'/>
<directory path='/exports/RHEVX/images/0'/>
</storage>
</storage_domain>
HTTP/1.1 201 Created
Location: http://{host}/storage_domains/76d8a12c-8b15-45f9-afc7-510f2377da74
Content-Type: application/xml
Content-Length: <length>
<storage_domain type='data'
href='/storage_domains/76d8a12c-8b15-45f9-afc7-510f2377da74'>
<id>76d8a12c-8b15-45f9-afc7-510f2377da74</id>
<name>images_0</name>
<storage type='nfs'>
<host name='172.31.0.6'/>
<directory path='/exports/RHEVX/images/0'/>
</storage>
<available>128849018880</available>
</storage_domain>
Seems pretty strange to me
2) Use a different document format at creation time. Same as above,
except the root element would be e.g. <storage_domain_add_request/>
Eoghan touches on that option here:
https://www.redhat.com/archives/rest-practices/2010-April/msg00041.html
I'm not loving that either, we'll end up with 2 or 3 times the
number of document formats
3) Don't require a host to be specified and randomly choose a host to
use when creating a storage domain
4) Require a data center to be specified at creation time and
use that to choose a host from one of the clusters in the data
center. We could remember that data center and allow no data
center to be specified when invoking 'attach' later.
5) Same as (4), except we automatically attach the storage domain to
the cluster as part of the creation. We would still have 'detach'
and 'attach' actions, though.
I'm liking the latter option. Anyone else have thoughts? Anyone else
read this far? :-)
Cheers,
Mark.
_______________________________________________
rhevm-api mailing list
rhevm-api(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhevm-api