DRBD Integration with oVirt
by Hayley Swimelar
Hello all,
A DRBD integration into oVirt is currently being planned.
DRBD provides replicated, highly available block storage. For those
unfamiliar with DRBD more information can be found here:
https://www.drbd.org/en/comp/drbd-linux-driver
DRBD 9 is the latest version of DRBD and interacts with DRBD Manage
which is a daemon exposed via a D-Bus api. More information can be found
here: https://www.drbd.org/en/comp/drbdmanage
DRBD Manage handles the creation, assignment, etc. of DRBD volumes and
is the interface through which Cinder manages DRBD.
We are looking for advice on how best to have oVirt communicate with
DRBD Manage and we have come to two options:
1) Use Cinder. Although we are integrated into Cinder, there are
concerns about the need to set up a complete Cinder instance to provide
access to DRBD.
2) The alternative to Cinder would be to have the oVirt Engine
communicate directly to DRBD Manage via D-Bus.
Any advice on the best way to achieve this would be much appreciated.
--
Hayley Swimelar
LINBIT | Keeping the Digital World Running
DRBD — Corosync — Pacemaker
+1-503-573-1262 x212
8 years
How to build and install oVirt on Product Environment
by Dewey Du
To build and install ovirt-engine execute the folllowing command:
$ make clean install-dev PREFIX="${PREFIX}"
What about installing it on Product Environment. Is the folllowing command
right?
$ make clean install PREFIX="${PREFIX}"
8 years
Integration tests future (and very nice alternative for the DAO fixture file)
by Roman Mohr
Hi all,
In [1] you can find some patches which are meant to improve the test
writing experience in ovirt-engine.
They provide the following things:
A) Domain Object builders which can be used for creating and/or
persisting domain objects [2]
B) DAO testing without writing fixtures because of the builders
C) Integration testing for commands in conjunction with a real database
Arquillian, injectable commands and the builders [3]
# How to run what?
A) In normal unit tests just create a new instance of a builder and use it.
This should help us to get rid of all the small createDefaultVm(),
createHostWithX() helper methods in our tests.
B) In dao tests just inject them and go ahead. The advantage of not using
the fixture file is that we can now set up clean scenarios for every test
in a setup method. See example 2 below on how easy it is to set up a new
cluster.
C) Arquillian integration tests need to be marked with
"@Category(IntegrationTest.class)" and can inherit from
TransactionalTestBase. The @Category annotation makes sure that the
integration tests are only run when
mvn clean verify -DskipITs=false
is invoked. Note that these tests are then executed in the integration test
phase of maven. For them we use the maven-failsafe-plugin[5] which will
also make sure that the testing database is up to date. See [4] for more
details.
# Examples
1) Add a running VM to a host, persist everything to the database and load
all VMs which are running on the host:
VDS host = vdsBuilder.cluster(persistedCluster).persist();
vmBuilder.host(host).up().persist();
List<VM> vms = vmDao.getAllRunningForVds(host.getId());
2) Add 10 hosts with 1 GB of RAM to a cluster, persist the hosts to the
database in a DAO test:
public class MyHostDaoTest extends BaseDaoTestCase {
@Inject
private VdsBuilder vdsBuilder;
@Test
public void createHosts() {
VdsBuilder builder =
vdsBuilder.cluster(persistedCluster).physicalMemory(1000);
for (int x =0; x < 10; x++){
builder.id(Guid.newGuid()).persist();
}
}
}
3) Full integration test with arquillian and the database
@Category(IntegrationTest.class)
public class VmDaoIntegrationTest extends TransactionalTestBase {
@Inject
VmDao vmDao;
private final Guid VM1_GUID =
Guid.createGuidFromString("0fe4bc81-5999-4ab6-80f8-7a4a2d4bfacd");
@Deployment
public static JavaArchive deploy(){
return createDeployment();
}
@Test
public void shouldFailOnExistingEntity() {
vmBuilder.id(VM1_GUID).cluster(clusterBuilder.reset().persist()).persist();
// This uses assertThat from assertj:
assertThat(vmDao.get(VM1_GUID)).isNotNull();
}
}
4) Using the builders in a normal unit test without a database:
VM vm = new VmBuilder().id(Guid.newGuid()).up().build();
# How to add your own Domain objects?
There are just a few simple rules:
1) Your builder should extend org.ovirt.engine.core.builder.AbstractBuilder
2) Make sure that you only access DAOs injected into the builder during
#prePersist() and #persist(). This allows to use the #build() method also
without injections
3) #prePersist() should set all fields which are necessary to suffice
database constraints. The fields should only be set if they are not already
set before by the builder. When following this rule we can always persist
new objects to the database by simply calling myBuilder.reset().persist().
4) Mark your builder with @Repository to make them useable for our Spring
DAO tests and our Arquillian integration tests.
So have a look at the patches at [1] and let me know what you think about
them.
Best Regards and happy testing,
Roman
[1] https://gerrit.ovirt.org/#/q/topic:integration
[2] https://gerrit.ovirt.org/#/c/47008/17
[3] https://gerrit.ovirt.org/#/c/47007/10
[4] https://gerrit.ovirt.org/#/c/47008/17
[5] https://maven.apache.org/surefire/maven-failsafe-plugin/
8 years
ovirt tests failing on missing libxml2-python
by Eyal Edri
2016-06-24 17:28:17,843 DEBUG [org.ovirt.otopi.dialog.MachineDialogParser]
(VdsDeploy) [796140d9] Got: ***L:ERROR Failed to execute stage 'Package
installation': [u'libxml2-python-2.9.1-6.el7_2.3.x86_64 requires libxml2 =
2.9.1-6.el7_2.3']
2016-06-24 17:28:17,844 DEBUG [org.ovirt.otopi.dialog.MachineDialogParser]
(VdsDeploy) [796140d9] nextEvent: Log ERROR Failed to execute stage
'Package installation': [u'libxml2-python-2.9.1-6.el7_2.3.x86_64 requires
libxml2 = 2.9.1-6.el7_2.3']
2016-06-24 17:28:17,860 ERROR
This is failing 3.6,4.0 and master tests, anyone knows on a recent
dependency change in vdsm or other host level pkg?
--
Eyal Edri
Associate Manager
RHEV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
8 years
master won't compile
by Alexander Wels
Hi,
I just rebased master and now it won't compile user
portal with the following exception, looks like the for
ACTION_TYPE_FAILED_SETUP_NETWORKS_OR_REFRESH
_IN_PROGESS is missing in user portal:
[INFO] Generating method body for
coloredText()
8 years
[ACTION REQUIRED] oVirt Engine 4.0.1 branched
by Rafael Martins
Hi,
ovirt-engine-4.0.1 has been created and is currently an exact copy of ovirt-engine-4.0.
>From now on, all patches targeted to 4.0.1 will need to be cherry-picked to that branch too.
A patch for bumping the ovirt-engine-4.0 branch to 4.0.2 will follow.
Thanks,
Rafael
8 years
oVirt 4.0.1 RC1 build starting
by Lev Veyde
Fyi oVirt products maintainers,
An oVirt build for an official release is going to start right now.
If you're a maintainer for any of the projects included in oVirt distribution and you have changes in your package ready to be released please:
- bump version and release to be GA ready
- tag your release within git (implies a GitHub Release to be automatically created)
- build your packages within jenkins / koji / copr / whatever
- verify all bugs on MODIFIED have target release and target milestone set.
Thanks in advance,
Lev Veyde.
8 years
Logs showing in the oVirt Engine localization/translation
by Juliette Tux
Hello, gentlemen,
Is there a way to translate the logs which appear in the Engine interface
at the bottom part of the window, see the secreenshot here:
http://rgho.st/75Y5P2jXM.view ?
Were the logs meant to be translated at all, i.e. are they i18'd in the
source code? Kindly direct me towards the relevant files in the v 3.6.x.
Sorry for another small stupid question, and lots of thanks in advance!
--
Best regards,
Julia Dronova
С уважением, Дронова Юлия
8 years
oVirt 4.0.1 RC1 merge / tag / bugzilla reminder
by Lev Veyde
All stable branch maintainers, please make sure to:
* merge all relevant open bugs until Thursday morning 11:00 AM TLV time.
* https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4....
Every package build (i.e oVirt product) - please make sure every bug in MODIFIED has the right Target Release and Target Milestone.
A Target release should state the version of the package you're building and should include the same version you used for the tag you just used for this build. (e.g. for ovirt-engine, tag: ovirt-engine-3.6.3.2, tr: 3.6.3.2)
Thanks in advance,
Lev Veyde.
8 years
