Engine on Fedora 21
by Adam Litke
Hi all,
Today I tried running engine on my Fedora 21 laptop. I tried two
approaches for deploying jboss: using the ovirt-jboss-as package, and
by downloading and unpacking jboss-7.1.1 into /usr/share as I have
done in the past. engine-setup runs without errors but when I try to
start engine the application does not seem to deploy in jboss and
there are no errors reported (engine.log is empty).
Is there a reasonable expectation that I should be able to get this
working on F21 or am I wasting my time? Does anyone have any ideas
on how I can resolve the startup issues?
See logs attached...
--
Adam Litke
9 years, 9 months
Using travis yaml files to specify dependencies and tests
by David Caro
--oLBj+sq0vYjzfsbl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi everyone!
After talking a bit with some of you, I think that we can start
planning a common build and dependency declaration for tests for the
ovirt products, to improve and automate most of the ci process and
maintenance.
Current status:
=3D=3D Dependencies
Right now we have 4 types of dependencies:
* test dependencies
* tarball/srcrpm build dependencies
* rpm build dependencies
* installation dependencies
The last two are managed from the spec files through rpm/yum
dependency systems. But the first ones are managed manually on the
jobs on jenkins or puppet manifests. What separates it from the code
that actually requires them and adds an extra layer of maintenance and
synchronization between the code, the jenkins jobs and the puppet
repository.
=3D=3D Builds
We started using autotools to build most of the projects, but it's
not a global methodology and even being used on some projects, you
need to tune the run for each of them, specifying different variables
and running some side scripts.
=3D=3D Tests
Some projects use make check to run some of the tests, some tests are
totally outside the code and run only in jenkins jobs.
Some possible improvements:
=3D=3D Tests/builds
Using shell scripts:
We talked before in another thread to create some generic script to
build the artifacts for the product and to run the tests, namely we
talked about having 3 executables (bash scripts probably) at the root
of each project, that should not require any parameters:
./build-artifacts
This should generate any artifacts to be archives (isos, rpms,
debs, tarballs, ...) and leave them at ./exported-artifacts/
directory, for the build system to collect, removing any
previous artifacts if needed.
./check_patch
Runs all the tests required for any new patchset in gerrit, for
non-merged changes, should be fast to run to get feedback easily
./check_merge
Runs all the tests for any change that is going to be merged
(right now we are not using gates, so it actually after merge,
but the idea is to use this as gate for any merge to the
repo). This can be more resource hungry than check_path.
That way it will let you use easily any framework that you want to use
for your project, but still let it be easy to maintain in the global
ci/build system (you can use pip, tox, maven, gradle, autotools, make,
rake, ...). This will not allow at first running tests in parallel in
jenkins, but we can in the future add that possibility (for example,
allowing the user to define more than one check script, like
check_patch.mytest1 and check_patch.mytest2 and make jenkins run them
in parallel).
I started a POC of this process here [1]
Using travis yaml files:
Using a travis compliant yaml file [2]. That will be less flexible
than the above solution and will not allow you to run tests in
parallel, though it will let you use travis at any point to offload
our ci if needed.
=3D=3D Dependencies
Using plain text files:
Similar to the above scripts solution, I though of adding an extra
file, with the same name, to declare the dependencies to run that
script. Adding a suffix in case of different requirements for
different distros (matching facter fact strings), for example:
./build-artifacts.req
Main requirements file, used if no more specific one
found. With a newline separated list of packages to install on
the environment (jenkins will take care of which package
manager to use).
./build-artifacts.req.fc20
Specific requirements for fc20 environment, replaces the
general one if present.
And the same for the other scripts (check_patch and check_merge).
Using travis yaml file:
Using a travis compliant yaml file with some extensions to declare
the different dependencies for each type and os/distro. That will
allow you to have only one extra file in your repo, though you'd have
to duplicate some of the requirements as travis only has ubuntu and
forces you to run scripts to install dependencies.
What do you think? Do you have any better idea?
ps. About using an external repository to store the
scripts/requirements for the code. The issue with this is that it
forces you to bind a code change in the code repo, to a
script/dependency change in the scripts repo, and that adds a lot of
extra maintenance and source of issues and failures. If you know a way
of doing it like that without all the fuss, I'd love to hear it.
For example, imagine that you have vdsm and the dependencies are in
another repo, now you send a patch to vdsm that requires you to run a
specific pep8 version to pass the patch tests, so you have to change
the script repo to add that dependency, but doing that you will brake
all the other patches tests because they require the older pep8
version, so you have to somehow specify in the vdsm patch that you
require a specific commit from the scripts repo to be tested with...
Having both in the same repo, allows you to do the code change and the
dependency/script change in the same patchset, and test it right away
with the correct scripts/deps.
It also binds together code and tests to some point, what is nice to
have in a product view, because you know for each version which tests
it passed and have a better idea of the possible failures for that
version.
[1] http://gerrit.ovirt.org/#/admin/projects/repoman
[2] http://docs.travis-ci.com/
--=20
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605
Email: dcaro(a)redhat.com
Web: www.redhat.com
RHT Global #: 82-62605
--oLBj+sq0vYjzfsbl
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJUvnkrAAoJEEBxx+HSYmnD2f0H/1t40fR3h4Tlae891vmiPyYv
zxfTY6SlW0CJkSEis2ED2KZTkQZwQ6clfK+aRdGzSXL0mtUL9wr3Kk1/+i4tMQD/
5gqjP9Hc7HoMzDDvIRIvBdBm3fDgnvChkqr8xbRG1l4LIDGgDH2AE9uhkEClHpqV
CdhwrYGAU9DCBcB1kINZqKPn7q42nR1fkvl2ItIlJ6eRpY51bf6PNIW2INNvVB7V
3LMkO9E2Y1uen61HZ5A7MvQ58vaJJjxM4seCrcdkbAEtHxbtPxVAEG7mXlpZBcH6
EbT1KfLAyghRcpdGxa5PsAQRHcrTre+sKhsi17fI8JZBhJVmAfdbHd2iEhMlqZ8=
=LXWV
-----END PGP SIGNATURE-----
--oLBj+sq0vYjzfsbl--
9 years, 9 months
CORS enabled for oVirt REST API
by Jenny Kang
Hello,
As part of my OPW project, I'm trying to build a mobile web UI for oVirt
but I'm having some troubles.
I cannot access the oVirt REST API because it doesn't allow cross origin
resource sharing (CORS). The only way to access the API is to host the UI
on the same IP as the engine. If it is enabled then people would be able to
run the mobile UI directly from the desktop without hosting it anywhere.
Do you have any suggestions on how to access oVirt REST API from another
host inside the browser? Any plans on enabling CORS on the REST API?
Thank you!
Cheers
Jenny
9 years, 9 months
oVirt 3.6 Feature: Cumulative Network Usage Statistics
by Lior Vernia
Hello users and developers,
Just put up a feature page for the aforementioned feature; in summary,
to report total RX/TX statistics for hosts and VMs in oVirt. This has
been requested several times on the users mailing list, and is
especially useful for accounting in VDI deployments.
You're more than welcome to review the feature page:
http://www.ovirt.org/Features/Cumulative_RX_TX_Statistics
Note that this only deals with network usage - it'll be great if we have
similar features for CPU and disk usage!
Yours, Lior.
9 years, 9 months
[DB] Diffrent UUIDs for inserted data per installation
by Eli Mesika
Hi
I am trying to cleanup all the data insertion to the engine DB and make it more general
The main drive to that is DB version squashing that was done manually and therefor was error prone ...
I know that both storage_pool_id (a.k.a DC) and vds_group_id (a.k.a Cluster) needs to get a different UUID per installation.
But I had found that UUIDs are generated per installation for also :
table | column/s
------------------------------------
[cpu_profiles] : id
[gluster_services] : id
[mac_pools] : id
[permissions] : id, object_id
[vm_device]: device_id, vm_id
[vm_static] : vm_guid
[vnic_profiles] : id
Please let me know if any of the above should be generated using the uuid_generate_v1() function on each installation or we can have static IDs for those.
Thanks
Eli Mesika
9 years, 10 months
Upgrade job is failing while upgrading from 3.4.4 to 3.5.2-snapshot:
by Sandro Bonazzola
Upgrade job is failing while upgrading from 3.4.4 to 3.5.2-snapshot:
2015-01-27 15:02:46 DEBUG otopi.plugins.ovirt_engine_setup.ovirt_engine.upgrade.asynctasks plugin.execute:866 execute-output:
('/usr/share/ovirt-engine/setup/dbutils/taskcleaner.sh', '-l', '/var/log/ovirt-engine/setup/ovirt-engine-setup-20150127150216-p4ixpj.log', '-u',
'engine', '-s', 'localhost', '-p', '5432', '-d', 'engine', '-R', '-A', '-J', '-q') stderr:
psql:/usr/share/ovirt-engine/setup/dbutils/taskcleaner_sp.sql:145: ERROR: type "command_entities" does not exist
FATAL: Cannot execute sql command: --file=/usr/share/ovirt-engine/setup/dbutils/taskcleaner_sp.sql
2015-01-27 15:02:46 DEBUG otopi.context context._executeMethod:152 method exception
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/otopi/context.py", line 142, in _executeMethod
method['method']()
File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/upgrade/asynctasks.py", line 422, in _validateZombies
self._clearZombieTasks()
File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/upgrade/asynctasks.py", line 156, in _clearZombieTasks
'Failed to clear zombie tasks. Please access support '
RuntimeError: Failed to clear zombie tasks. Please access support in attempt to resolve the problem
2015-01-27 15:02:46 ERROR otopi.context context._executeMethod:161 Failed to execute stage 'Setup validation': Failed to clear zombie tasks. Please
access support in attempt to resolve the problem
Please fix ASAP.
Reference: http://jenkins.ovirt.org/job/ovirt-engine_3.5_upgrade-from-3.4_merged/lab...
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
9 years, 10 months
DAO test is failing on master
by Sandro Bonazzola
http://jenkins.ovirt.org/job/ovirt-engine_master_dao-unit-tests_merged/10...
15:50:12 Failed tests:
15:50:12 scheduleARecurringJob(org.ovirt.engine.core.utils.timer.DBSchedulerUtilQuartzImplTest): Unexpected exception occured -Failed to obtain DB
connection from data source 'EngineDS': java.sql.SQLException: Connections could not be acquired from the underlying database!
15:50:12 scheduleAJob(org.ovirt.engine.core.utils.timer.DBSchedulerUtilQuartzImplTest): Unexpected exception occured -Failed to obtain DB connection
from data source 'EngineDS': java.sql.SQLException: Connections could not be acquired from the underlying database!
Not sure if it's infra or devel issue.
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
9 years, 10 months
Move bugs to ON_QA based on snapshot builds?
by Lior Vernia
Hello everyone,
I wanted to suggest that we automate the change of oVirt 3.6 bug status
from MODIFIED to ON_QA based on nightly snapshot builds.
The motivation should be clear: when bugs are fixed on the master
branch, the fix becomes readily available for verification as soon as
the next snapshot is built (and there's indeed someone to verify on the
master branch - the same person who was working on the master branch and
opened the bug!).
We currently only move them to ON_QA on milestone builds (e.g. alpha,
beta), but I don't think that's right for an open source project - the
status of bugs (targeted to the nearest release) should be up-to-date
with the actual state of the master branch.
We've encountered the problem testing features for 3.6 the last couple
of weeks, and since it's gonna be a long version this situation will
likely occur often. So far I've been moving bugs to ON_QA myself, but I
don't really want to follow the snapshot builds manually (nor move the
bugs to ON_QA as soon as they're merged, in case the snapshot build
doesn't happen).
The downside would be that bugs could be VERIFIED at an early point in
the development, and later regressions could occur that would render the
verification obsolete. But this could happen just the same between
release milestones...
Thoughts?
Yours, Lior.
9 years, 10 months
[QE] oVirt 3.5.2 status
by Sandro Bonazzola
Hi,
Development cycle for oVirt 3.5.2 release started and we're now going to schedule this release.
A release management entry has been added for tracking the schedule of 3.5.2 [0]
A bug tracker [1] has been created and currently has no open blockers.
Maintainers:
- Please be sure that 3.5 snapshot allow to create VMs
- Please be sure that no pending patches are going to block the release
- If any patch must block the RC release please raise the issue as soon as possible.
There are still 44 bugs [2] targeted to 3.5.2.
Excluding node and documentation bugs we still have 36 bugs [3] targeted to 3.5.2.
Maintainers / Assignee:
- Please add the bugs to the tracker if you think that 3.5.2 should not be released without them fixed.
- Please update the target to 3.5.3 or later for bugs that won't be in 3.5.2:
it will ease gathering the blocking bugs for next releases.
- Please fill release notes, the page has been created here [4]
Community:
- If you're testing oVirt 3.5 nightly snapshot, please add yourself to the test page [5]
[0] http://www.ovirt.org/OVirt_3.5.z_Release_Management#oVirt_3.5.2
[1] http://bugzilla.redhat.com/1186161
[2] http://goo.gl/crVJPH
[3]http://goo.gl/2qTZZU
[4] http://www.ovirt.org/OVirt_3.5.2_Release_Notes
[5] http://www.ovirt.org/Testing/oVirt_3.5.2_Testing
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
9 years, 10 months
