Hey,
I've added some changes to resolve the following issues:
https://fedorahosted.org/rhevm-api/ticket/25
Model cluster compatibility version
https://fedorahosted.org/rhevm-api/ticket/19
Add a capabilities resource
I thought I'd highlight the changes here, since most people would miss
the details from trac and git.
Okay, first some background on the concept of cluster levels - if you
update from RHEV-M 2.1 to 2.2, you can continue to use 2.2 to manage
hosts with the 2.1 version of vdsm installed.
The idea is that a cluster and data center have a "cluster level" which
reflects the oldest host versions supported by the cluster or data
center. When you upgrade, your existing clusters will have the 2.1
level. When you've upgraded all hosts in a cluster, you can update the
cluster to the 2.2 level and use 2.2 features in that cluster. Once all
clusters have been upgraded in a data center, you can update the data
center level.
First thing we've done is add a <version major="x"
minor="y"/> tag to
data centers and clusters. This shows the level and can be specified
when adding or updating a resource.
Next thing we've done is to also add a <supported_versions/> tag which
lists the versions that you can upgrade the data center or cluster to -
i.e. if the cluster level is 2.1 and all the hosts are at level 2.2, it
will show level 2.2 as supported in the cluster.
Now to the concept of capabilities - basically, each instance of RHEV-M
will have different capabilities or constraints, based on the version of
RHEV-M, its configuration, what OS it's deployed on, or whatever.
Over time we'll be adding things like the maximum number of CPUs and the
list of supported NIC models, but the example we started with is the
list of CPUs types that are valid in cluster configurations - i.e. the
contents of "CPU Name" list in the "New Cluster" dialog.
The interesting thing about this is that the list is dependent on the
cluster level - i.e. "Intel Xeon" is the highest CPU you can specify for
2.1 clusters, but you can specify "Intel Xeon Core i7" for 2.2 clusters.
The way we've modelled all this is by adding a capabilities resource:
---
GET /capabilities HTTP/1.1
Accept: application/xml
HTTP/1.1 200 OK
Content-Type: application/xml
<capabilities>
<version major="2" minor="2">
<current>true</current>
<cpus>
<cpu id="Intel Xeon w/o XD/NX">
<level>2</level>
<flags>
<flag>vmx</flag>
<flag>sse2</flag>
</flags>
</cpu>
<cpu id="Intel Xeon">
<level>3</level>
<flags>
<flag>vmx</flag>
<flag>sse2</flag>
<flag>nx</flag>
</flags>
</cpu>
</cpus>
</version>
<version major="2" minor="1">
<cpus>
<cpu id="Intel Xeon w/o XD/NX">
..
</cpu>
<cpu id="Intel Xeon">
..
</cpu>
...
<cpu id="Intel Xeon Core i7">
<level>6</level>
<flags>
<flag>vmx</flag>
<flag>sse2</flag>
<flag>nx</flag>
<flag>cx16</flag>
<flag>ssse3</flag>
<flag>ssse4_1</flag>
<flag>ssse4_2</flag>
</flags>
</cpu>
</cpus>
</version>
</capabilities>
---
Clear as mud?
Thanks,
Mark.