Hi Itamar,
On Tue, 2010-04-27 at 08:06 -0400, Itamar Heim wrote:
> 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)
[IH] this may change (more than one type of storage)
More than one type or no type restriction at all? i.e. we have:
<datacenter type="nfs">
...
Do you suggest we move to:
<datacenter>
<storage_type>nfs</storage_type>
<storage_type>iscsi</storage_type>
or are you saying that in future the storage type attribute will go
away?
...
> 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
[IH] this is not an option. You need to select a host that can actually
access said storage.
Right.
> 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.
[IH] this requires that setting the storage domain all hosts will already
have access to it in the cluster. Sounds a bit limiting.
Okay, where am I going wrong with this logic:
- At creation time, all we need is any host with access to the storage
- I can't see an obvious use case where one would create a storage
domain and not immediately attach it to a datacenter
- Before attaching a storage domain to a datacenter, all hosts in the
datacenter should have access to the storage
- Therefore it makes sense to specify a datacenter (rather than a
host) when creating a storage domain
One could also later attach it to another storage domain.
Btw - a storage domain can be attached to multiple data centers,
And all hosts within the multiple datacenters should have access to the
storage, right?
and may have a different status in each of them.
Huh? That would suggest a storage domain's status needs to be modelled
like:
<datacenter>
....
<storage_domain_statuses>
<storage_domain_status>
<storage_domain href="..."/>
<status>....</status>
</storage_domain_status>
</storage_domain_statuses>
How is this expressed with the powershell API - do you get a different
storage domain object from get-storagedomain depending on which
datacenter ID you supply?
Also, which of the two statuses do you mean:
StorageDomainStatus { Unknown, Uninitialized, Unattached, Active, InActive, Locked }
StorageDomainSharedStatus { Unattached, Active, InActive, Mixed, Locked }
What is the difference between the two?
> 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.
[IH] this makes creation of a storage domain an action that has to be
synchronized on all hosts in a data center.
Could you explain that a bit further?
> I'm liking the latter option. Anyone else have thoughts?
Anyone else
> read this far? :-)
[IH] I'm not sure I see the issue with passing a parameter of the host you
want to use to the storage domain creation request, even if it is not part
of the response?
With REST it's not so much about the requests or responses, it's about
the representation of the storage domain resource
I don't think "the host which was used to create the storage domain"
makes sense to have in our representation of the resource, so it doesn't
belong in the POSTing of the resources representation either
If we end up not being able to infer the creation host from the
datacenter, then we'll need to split out the actual creation to a
separate action i.e.
POST /vms HTTP/1.1
Host: {host}
Content-Type: application/xml
Content-Length: {length}
<storage_domain>
<name>image_0</name>
<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>
<status>unattached</status>
<actions>
<link rel='init'
href='/storage_domains/76d8a12c-8b15-45f9-afc7-510f2377da74/init'/>
<link rel='attach'
href='/storage_domains/76d8a12c-8b15-45f9-afc7-510f2377da74/attach'/>
</action>
</storage_domain>
POST /storage_domains/76d8a12c-8b15-45f9-afc7-510f2377da74/init HTTP/1.1
Host: {host}
Content-Type: application/xml
Content-Length: {length}
<action>
<host href='/hosts/288478f3-f4c9-4589-b4f5-d6522501762e'/>
</action>
HTTP/1.1 201 Created
Location: http://{host}/storage_domains/76d8a12c-8b15-45f9-afc7-510f2377da74
Content-Type: application/xml
Content-Length: {length}
<action resource="storage_domain" type="init"
href="/storage_domains/288478f3-f4c9-4589-b4f5-d6522501762e/init/707c9a0f-c53c-4015-a149-1dc8d85d5353">
<id>707c9a0f-c53c-4015-a149-1dc8d85d5353</id>
<host href='/hosts/288478f3-f4c9-4589-b4f5-d6522501762e'/>
<status>IN_PROGRESS</status>
</action>
(Don't pay too much attention to how we're modelling actions here -
we're still thinking that over)
Cheers,
Mark.