1. current design is not restfull
2. is not consistent with the rest of api impl.
as this resource not used programmatically, we do not expect any
backward compatibility issues
planned change is:
<version major="3" minor="1">
<version major="3" minor="0">
(where xxx is a version number)
RedHat, ENG-Virtualization R&D
Garry is sick and can not make it for today's meeting.
Since he wrote the wiki proposal we'll reschedule this meeting to later
this week or early next week.
I'll send update soon.
I have a newbie question regarding host/cluster compatibility versions. I hope someone could clarify this for me.
We have an old lab setup in which we were managing KVM hostnodes using RHEV Manager (version 18.104.22.168796) . We are now trying to upgrade to the latest version of oVirt Engine (version 3.1.0_0001-1.8.el6).
Now, when I add the old KVM node to oVirt Engine, I am getting following error message:
Host's Compatibility Version doesn't match the Cluster's Compatibility Version
Can someone tell me if oVirt Engine is backward-compatible with older hostnodes? Or do I need to upgrade one or more components (such as VDSM) on the hostnode to be compatible with new engine?
Here is the version information from the hostnode I'm trying to add:
OS : RHEV Hypervisor - 5.6 - 9.3.el5_6
Kernel : 2.6.18 - 238.5.1.el5
KVM : 83 - 224.el5
VDSM : 22.214.171.124
SPICE : 0.3.0 - 54.el5_5.2
After seeing an email regarding api/capabilities and looking at the
code, and dealing regardless of that with VDSM versions -
I have a question - is it interesting for us to display the list of
supported VDSM versions under api/capabilities?
Correlation-ID feature allows 'tagging' a call to a Backend command
with a String ID, and this ID will be appended to all log messages
that result from this command.
In REST-API, we would like to enable the user to pass a correlation-ID
when he activates actions.
I have two questions:
1) what's the name you'd give this parameter? job-id? batch-id?
flow-id? command-id? correlation-id???
2) I've already implemented this as a url parameter. Are there objections?
The only viable alternative I see is as an http header, which doesn't feel
right. It's not an option to pass it in the XML body, because sometimes
there is no body, for example, in DELETE commands.
BZ#822158 (https://bugzilla.redhat.com/show_bug.cgi?id=822158) is currently marked as oVirt 3.1 release blocker.
I'd like to get some updates from you, As the assignee for this bug:
1. What is the current status of this bug?
2. Any time estimation for a complete fix?
oVirt Release Manager
This is a message in Mime Format. If you see this, your mail reader does not support this format.
Content-Type: text/plain; charset=utf-8
# ./upgrade.sh -u postgres=0ARunning upgrade script upgrade/03_01_1120_v=
ias_column.sql:1: invalid command \'');=0A=0A--
Content-Type: text/html; charset=utf-8
<br># ./upgrade.sh -u postgres<br>Running upgrade script upgrade/03_01_1=
add_alias_column.sql:1: invalid command \'');<br><br><br><br><br>--<br><=
I need a reasonable test suites to test VDSM APIs. I know most of tests
are done from the engine side manually. But I think we need a
reasonable test suites to define the typical workflows of engine usage
calling into VDSM APIs and make sure all the functions are doing well.
As engine publics REST-APIs, an automated test suites can be created on
top of the REST-APs without much difficult. Any other comments about
IBM China Systems and Technology Laboratory