[Engine-devel] Maven 3 here we come!
by Doron Fediuck
Hi guys,
We're trying to be as updated as possible in oVirt development.
In order to catch up with recent changes in major distro's,
we'd like to move to Maven 3.
Current oVirt engine code actually can be built with Maven 3 now,
but we still need to handle some minor issues. Also we need
to update our wiki's accordingly.
To make this move coordinated, and give everyone some time
to play with Maven 3, I suggest we do it in 2 weeks from now,
and move on April 29. Basically the code should remain the same,
other than minor changes we may need to do.
If you have substantials considerations against maven3,
please share.
--
/d
"Who's General Failure and why's he reading my disk?"
12 years
[Engine-devel] ovirt-engine deployment method
by Ofer Schreiber
As decided earlier, oVirt next release (3.1) is targeted for Fedora 17.
Since the engine uses JBoss, we have two deployment options:
1. Continue working with ovirt-engine-jbossas package
PROS: Single rpm. known upgrade method.
CONS: Maintaining un-natural zip based rpm. No official support. Can't be pushed into Fedora.
2. Move to JBoss F17 official packages:
PROS: Fully supported F17 rpms (including bug fixes, security fixes, etc). "The right thing to do".
CONS: Upgrade from first release (relaying on old jboss) will be almost impossible, Some open issues (will it work just as as normal service? or will we need to code a new one?), Might cause a delay to Feature Freeze.
Thought? Comments?
Share them with us!
---
Ofer Schreiber
oVirt Release Manager
12 years
[Engine-devel] java enum syntax trick
by Laszlo Hornyak
Hi,
In java enums, you can leave a coma before the semicolon closing the names in the enum. e.g.
enum Foo {
bar,
baz, // <!-- last, still with a coma
; //and there is no more
}
I don't know if this fits in the code formating requirements, but maybe it could help us to waste less time on merging because you did not have to change the last line to add some more.
Laszlo
12 years
[Engine-devel] Query regarding ValidationUtils#validateInputs
by Shireesh Anjal
This is a multi-part message in MIME format.
--------------060906010904020105000601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
This is regarding the following validation method we have in
ValidationUtils:
/public static <T extends VdcActionParametersBase> ArrayList<String>
validateInputs(List<Class<?>> validationGroupList, T parameters);/
I there any particular reason for supporting the validations only on
objects of classes derived from VdcActionParametersBase? I guess this
was done because this method is primarily intended to validate the
action parameters passed to a BLL action, using the validation
annotations on the parameter class. However I think this method can be
useful for general use as well. e.g. I cannot add a "@Valid" annotation
on a "list" or a "map" in a parameter class. So I need to iterate over
the list/map, and validate each element inside the loop. The validation
inside the loop can also utilize the above method if the restriction
"extends VdcActionParametersBase" is removed. This will allow me to do
the following in the canDoAction method:
protected boolean canDoAction() {
...
for(GlusterBrickEntity brick :
getParameters().getGlusterVolume().getBricks()) {
List<String> errors =
ValidationUtils.validateInputs(getValidationGroups(), brick);
if(errors != null) {
for(String error : errors) {
addCanDoActionMessage(error);
}
}
}
...
}
Regards,
Shireesh
--------------060906010904020105000601
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
This is regarding the following validation method we have in
ValidationUtils:<br>
<br>
<i>public static <T extends VdcActionParametersBase>
ArrayList<String> validateInputs(List<Class<?>>
validationGroupList, T parameters);</i><br>
<br>
I there any particular reason for supporting the validations only on
objects of classes derived from VdcActionParametersBase? I guess
this was done because this method is primarily intended to validate
the action parameters passed to a BLL action, using the validation
annotations on the parameter class. However I think this method can
be useful for general use as well. e.g. I cannot add a "@Valid"
annotation on a "list" or a "map" in a parameter class. So I need to
iterate over the list/map, and validate each element inside the
loop. The validation inside the loop can also utilize the above
method if the restriction "extends VdcActionParametersBase" is
removed. This will allow me to do the following in the canDoAction
method:<br>
<br>
protected boolean canDoAction() {<br>
...<br>
for(GlusterBrickEntity brick :
getParameters().getGlusterVolume().getBricks()) {<br>
List<String> errors =
ValidationUtils.validateInputs(getValidationGroups(), brick);<br>
if(errors != null) {<br>
for(String error : errors) {<br>
addCanDoActionMessage(error);<br>
}<br>
}<br>
}<br>
...<br>
}<br>
<br>
Regards,<br>
Shireesh<br>
</body>
</html>
--------------060906010904020105000601--
12 years
Re: [Engine-devel] [Users] Hey everyone how do we upgrade engine?
by Livnat Peer
On 13/04/12 19:59, Itamar Heim wrote:
> On 04/13/2012 06:42 PM, Dominic Kaiser wrote:
>> I am running 3.0.0_0001-1.6.fc16 ovirt engine and has been great! I
>> appreciate Red Hat and all the support from the community on this
>> project you all are awesome!
>>
>> I have not thought about it yet but was looking on the wiki and did not
>> see how to upgrade and reninstallengine. What have been your
>> experiences doing this and is it worth it? And how to do it? Sorry if
>> it was posted somewhere else just let me know if there is info on this
>> already.
>
> by running the engine-upgrade utility, though i suspect it will have to
> pass some testing/bug fixes for the second release before can be used
> (doing a test upgrade at that phase on your environment would help
> finding issues)
>
We have one issue that we know of and we'll fix soon -
https://bugzilla.redhat.com/show_bug.cgi?id=790303
If you are interested you can track engine-devel(a)ovirt.org list for
updates on this in the upcoming week (or keep track of the bug status).
Livnat
>>
>> I have had the greatest experience moving from 2 esxiservers to ovirt.
>> You guys and gals rock!
> thanks - nice to hear.
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
12 years
[Engine-devel] Issue with XML namespaces in engine-setup
by Juan Hernandez
Hello,
The code that we use in engine-setup to modify JBoss AS XML
configuration files uses the following pattern:
datasourceStr = '''
<datasource ...>
...
</datasource>
'''
xmlObj.addNodes("//datasource:subsystem/datasource:datasources",
datasourceStr)
This looks correct but is in fact generating a incorrect XML document,
as the tags being added are not associated to a namespace. The resulting
XML file will be correct, but the temporary representation in memory is
not. This causes problems if you later, before writing out the modified
file, try to use xpath expressions matching the added nodes: there will
be no match.
I would suggest that we change the pattern to something like this:
datasourceStr = '''
<any_dummy_tag xmlns="urn:jboss:domain:datasources:1.0">
<datasource ...>
...
</datasource>
</any_dummy_tag>
'''
datasourceNodes = libxml2.parseDoc(datasourceStr).getRootElement().children
xmlObje.addNodes("//datasource:subsystem/datasource:datasources",
datasourceNodes)
This way both the representation in memory and the resulting file are
correct.
Le me know what you think.
Regards,
Juan Hernandez
--
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
12 years
[Engine-devel] Hot-plug of disks and nics
by Ori Liel
On the subject of activate/deactivate disks and nics ("hot-plug"), I'd like to hear opinions about the correct modelling. I see two possible options (I will use disks as an example, but the chosen modelling should be the same for nics and disks).
Option 1 - update:
=================
PUT
.../api/vms/{vm:id}/disks/{disk:id}
<disk>
<activated>true</activated>
</disk>
Pros:
-----
* RESTful, no need for new action
Cons:
-----
* Inconsistent with other flows. We do not normally update status fields to perform actions. For example to run a VM, we do not update it's status to 'activated', we run an action (start).
* Enables user to update disk properties AND activate/deactivate in the same operation. Updating certain disk properties is forbidden while the VM is up, but activating/deactivating the disk is allowed always. This requires business-logic in REST-API: if the user activates the disk and changes properties on it - REST-API must first change the properties and then activate the disk (if disk is activated first, update properties will fail). If, on the other hand, the user *deactivates* the disk and changes properties on it - REST-API must first deactivate the disk and then change the properties (changing properties while disk is still active will fail). This bug-prone logic is only necessary because when activate/deactivate is merged with update.
Option 2 - action
=================
.../api/vms/{vm:id}/disks/{disk:id}/attach
Pros:
----
* Less RESTful
Cons:
-----
* Consistent with other flows
* Does not have the drawback of the additional business-logic described above
Opinions?
Thanks,
Ori.
12 years
