[ANNOUNCE] Third milestone release of RHEV-M REST API
by Eoghan Glynn
Hi All,
We're happy to announce the third milestone release of the REST API
for Red Hat Enterprise Virtualization Manager.
Linux and Windows distributions of 0.9-milestone3 may be downloaded
from [1].
Signed individual artifacts are also deployed to maven and synch'd up
to the Central repository [2].
Highlights of this milestone release are summarized below, with the
corresponding trac[3] ticket ID specified where appropriate.
Main API additions:
- Users and roles resources
- Support for snapshots (#23)
- Support for iSCSI and FCP storage domains (#59)
- A storage collection under host resources (#59)
- Support for adding/removing a network to/from a cluster (#57)
- A NICs collection under host resources (#57)
- Support for managing bonded NICs (#57)
- Cluster compatibility levels (#25)
- A versioned capabilities resource (#19)
- Support for managing the users attached to a VM (#36)
- VM display details and "ticket" action (#24)
- Boot options in VM and template resources (#39)
- Data center status (#45)
Improvements to the API implementation:
- Re-use powershell instances to greatly speed up API accesses
- Improved error reporting for missing required parameters (#40)
- Improved error reporting of authentication failures (#68, #69)
Watch out for these incompatibilities with milestone2:
- the 'cpus' collection has been moved under 'capabilities' (#25)
- the 'user\domain' convention for specifying the username in the
Authorization header is deprecated; use 'user@domain' instead (#70)
RESTEasy:
- Fix for https://jira.jboss.org/browse/RESTEASY-426 which
allows for POSTing to sub-collections (#47).
And, finally, miscellaneous bug fixes:
- Work around xerces XML parser not being thread-safe (#49)
- Fix several issues specific to running on RHEV-M 2.2 (#48)
- Fix issue with powershell instances being reaped (#58)
- Fix issue with adding VM devices (#47)
- Fix broken data center update (#51)
- Make VM type immutable post-creation (#46)
- Fix issue with CLI and env variables (#50)
- Resolve several issues when running under tomcat
As always, feedback is most welcome!
[1] https://fedorahosted.org/releases/r/h/rhevm-api
[2] http://repo2.maven.org/maven2/com/redhat/rhevm/api
[3] https://fedorahosted.org/rhevm-api/report/6
13 years, 8 months
Issues running rhevm-api
by Geert Jansen
Hi,
i'm getting some JBoss errors when running rhevm-api. It complains that
port 8009 is in use. According to netstat, this port is being listened
on by RhevManager.exe.
Any idea on how to resolve the conflict?
Attached is a traceback (zipped to stay below size limitations of email
list).
Regards,
--
Geert Jansen, Product Marketing Manager EMEA
Red Hat S.r.L. T: +39 348 1980079
Via Antonio da Recanate 1 E: gjansen(a)redhat.com
Milan 20124, Italy
13 years, 8 months
git links
by Geert Jansen
Hi,
i was going through some of the tickets. I noticed that there are a lot
of git.fedoraproject.org links embedded in them, however the repo seems
to be at git.fedorahosted.org.
Regards,
--
Geert Jansen, Product Marketing Manager EMEA
Red Hat S.r.L. T: +39 348 1980079
Via Antonio da Recanate 1 E: gjansen(a)redhat.com
Milan 20124, Italy
13 years, 8 months
Cluster version levels and capabilities
by Mark McLoughlin
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.
13 years, 8 months
REST mapping of some storage commands
by Mark McLoughlin
Hi,
I'm going through each of the storage related powershell commands which
we don't have an equivalent for in the REST API and trying to figure out
how each should be modelled in a RESTful manner
See below for the list of powershell commands and some notes on each.
Basically, my conclusion so far is:
1) Storage server connections don't need to be modelled in the REST
API
2) We need host actions for discovering pre-configured storage
domains, iSCSI targets, LUNs and VGs
Any and all feedback very welcome.
Thanks,
Mark.
=== Storage Server Connections ===
>From a user's point of view, what is the use case for these commands?
Get-StorageServerConnections
- Lists all connections in the DB
New-StorageServerConnection
- Just creates a CLIStorageServerConnection, no interaction with the
backend
Add-StorageServerConnection
- Runs ConnectStorageToVds backend action which doesn't add the
connection to the DB
Connect-StorageToHost
- Also runs ConnectStorageToVds backend action
Detach-StorageServerConnection
- Calls RemoveStorageConnection backend action, which doesn't remove
the connection from the DB
=== Pre-Configured Storage Domains ===
What is the use case of these? e.g. is it to allow an export domain to
be imported into another instance of RHEV-M?
We could support this using a "discoverdomains" host action (similar to
target/device/VG listing below) which would return a <storage_domain/>
representation which could then be POSTed to /storagedomains/ in order
to import it
Get-PreConfiguredStorageDomains
- Lists existing storage domains at a given NFS mount point
Import-PreConfiguredStorageDomain
- Adds a storage domain which has already been initialized
=== Listing Targets/Devices/VGs ==
All of these would probably make sense to support as host action (rather
than including the results in the host representation) since each needs
an expensive query to be run on the host
Get-StorageDevices
- Runs GetDeviceList query
Get-StorageVolumeGroups
- Runs GetVgList query
Get-StorageServerSendTargets
- Runs DiscoverSendTargets backend query, which runs iSCSI SendTarget
on a portal listing the available targets
- This is the most RPC-like, since it requires a portal parameter.
13 years, 8 months