Storage domains
by Mark McLoughlin
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.
14 years
Modelling Data Centre storage-specific info
by Eoghan Glynn
Hi Mark,
I was too busy yesterday afternoon butchering the git master (sorry!) to
get back to your question on IRC about modelling storage-type specific
details of NFS versus iSCSI in the data centre representation.
How about using the <xs:choice> mechanism to represent the mutually
exclusivity of NFS-specific info versus iSCSI-specific details, and have
the storage type intended be implicit from this selection?
So say we were to start generating the JAXB model from XML schema (which
is what I thought you meant yesterday, though obviously I got that
backwards).
Starting with schema types something like the following (just making up
the storage-specific primitives, as I can't remember exactly what was in
that C-like union type you quoted on IRC) ...
<xs:complexType name="NfsInfo">
<xs:sequence>
<xs:element name="host" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="IscsiInfo">
<xs:sequence>
<xs:element name="LUN" type="xs:int"/>
<xs:element name="IP" type="xs:string"/>
<xs:element name="port" type="xs:short"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="StorageTypeSpecific">
<xs:choice maxOccurs="1">
<xs:element name="NfsSpecific" type="NfsInfo"/>
<xs:element name="IscsiSpecific" type="IscsiInfo"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="dataCenter">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="storageDetails" type="StorageTypeSpecific"/>
<!-- ... etc. -->
</xs:sequence>
</xs:complexType>
AFAIK the JAXB compiler is then supposed to generate code of form
ThisOrThat, e.g. getNfsSpecificOrIsciSpecific(), to represent the
one-or-t'other-ness.
Not sure what the equivalent Java-first annotations would be, but I
guess we could codegen and reverse engineer these.
Cheers,
Eoghan
14 years
Suggestion on schema binding customization
by Eoghan Glynn
Hey Mark,
Just scanned thru' at the codegen from schema branch, looking good.
One issue with JAXB is that the default generated code can be a little
unnatural. For example the accessor on the collections types are in the
singular rather than the plural, e.g. VMs.getVm() instead of
VMs.getVMs().
You can work around this with binding customization, e.g. in the above
example controlling the method naming using some inline annotations:
<xs:complexType name="VMs">
<xs:sequence>
+ <xs:annotation>
+ <xs:appinfo>
+ <jaxb:property name="VMs"/>
+ </xs:appinfo>
+ </xs:annotation>
<xs:element ref="vm" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
or alternatively if you don't want to pollute the schema with JAXB-isms,
these can be pushed out to a separate file.
Unfortunately there doesn't seem to be a customization to decorate the
generated code with an extra annotation (to add in the missing
@BadgerFish)
Patch attached with the inline changes for the schema and pom, but
obviously the code using these types would have to be updated also (not
again, says you!)
Cheers,
Eoghan
14 years
First cut of CLI client
by Eoghan Glynn
Folks,
I've pushed the first cut of a CLI client using the command completion
infrastructure from the Apache Felix Karaf shell. Its on a remote branch
called "cli", only VM-related commands for now.
Mark - can you cast your eye over this before I push it up to master?
Cheers,
Eoghan
14 years
concatenating Link headers in response to entry-point HEAD method
by Eoghan Glynn
Folks,
We've noticed some funnies with the handling of multiple headers of the
same name by various REST providers, with RESTeasy concatenating the
header values into a comma separated list, and CXF JAX-RS seemingly
dropping all but the last header instance.
In the light of the following chapter & verse from the spec:
"Multiple message-header fields with the same field-name MAY be present
in a message if and only if the entire field-value for that header field
is defined as a comma-separated list [i.e., #(values)]. It MUST be
possible to combine the multiple header fields into one "field-name:
field-value" pair, without changing the semantics of the message, by
appending each subsequent field-value to the first, each separated by a
comma. The order in which header fields with the same field-name are
received is therefore significant to the interpretation of the combined
field value, and thus a proxy MUST NOT change the order of these field
values when a message is forwarded."[1]
It seems like a concatenation is the canonical form and least likely
cause trouble along the way. So how about we simply squash together the
Links set in the implementations of ApiResource.head()?
Cheers,
Eoghan
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2
14 years
Pure webapp deployment
by Eoghan Glynn
Hi Mark,
I just pushed a branch with support for pure webapp deployment of the
dummy application and also some lightweight testing options.
Can you do cast your eye over the changes on origin/pure-webapp before I
do the same for the powershell app?
Cheers,
Eoghan
14 years
Sprint!
by Mark McLoughlin
Hey,
Eoghan and I are going to give a shot at this agile sprint malarky
Here's our focus for the next two weeks:
https://fedorahosted.org/rhevm-api/wiki/Sprint1
Cheers,
Mark.
= Sprint 1 =
Starting Friday April 23rd, finishing Thursday May 7th.
The basic theme is to finalize some of the gnarly [wiki:Design_Questions
API design issues] while also making a big improvement in the functional
coverage of the API.
== Mark's Tasks ==
1. Expand the API coverage so that, given a fresh RHEV-M install, the
following is possible:
* Add a host
* Create a storage domain
* Install a VM
* Create a template from that VM
2. Resolve the question of how we want to pass parameters to actions
3. Re-jigger our RHEV-M install so that Eoghan can use it remotely
== Eoghan's Tasks ==
1. Figure out what we're going to do about async operations:
* Should actions have an async parameter?
* If so, when POSTing to a collection, how to make the creation
async?
* An async operation will return a URI to poll; what will a GET
on that return?
* Once an async operation is completed, do we need to worry about
purging the record of that completion at some point?
* Should we integrate operation completions with the audit/event
log?
2. Decide on {{{<vm href="..."/>}}} versus {{{<link rel="host"
href="..."/>}}}
3. Make the dummy and powershell implementations simple servlets
rather than EJBs
4. Return an error if the client tries to change an object UUID.
Requires thinking about how we should handle errors.
5. Decide what our media types should be and add support for them.
14 years