[Event] 2015 oVirt Asia Workshop
by Brian Proffitt
As oVirt strives to become the best open source and comprehensive data center virtualization management suite, and its community rapidly evolves and grows, one of the ways its vibrant community connects is through our Global Workshops. The events are conducted solely to introduce new users and veteran oVirt admins to new features and new techniques found in oVirt, as well as provide a forum for our users to connect directly with the development team behind oVirt.
With that in mind, we are pleased to announce that registration is now open for the 2014 oVirt Workshop!
The next 2015 oVirt workshop will be co-located with the FOSSAsia in Singapore on March 14, 2015. This workshop is designed to encourage collaboration in our community, lay the foundation for best practices in oVirt use, convey end-user stories, and help answer questions about the project from both a developer and user's perspective.
For more information, and to register for the event, visit the Workshop page[1] today!
[1] http://www.ovirt.org/Asia_Workshop_Mar_2015
--
Brian Proffitt
Community Liaison
oVirt
Open Source and Standards, Red Hat - http://community.redhat.com
Phone: +1 574 383 9BKP
IRC: bkp @ OFTC
9 years, 9 months
[QE] oVirt 3.6.0 nightly build testing
by Sandro Bonazzola
Hi,
I've been asked to start the discussion about testing 3.6.0 nightly builds.
Once http://gerrit.ovirt.org/37384 will be merged or manually applied on the testing host, 3.6 cluster compatibility will be enabled on the following
distributions:
Fedora 21: no special instructions for this distribution, should work out of the box.
Fedora 20: requires virt-preview repository. you can find the .repo file[1] in the virt-preview home[2]. AN update to ovirt-release-master rpm will
enable the repository by default, it will be available probably tomorrow.
RHEL / CentOS 7.1: not yet released, but once they'll be out they'll support 3.6 cluster compatibility
RHEL / CentOS <= 7.0 won't have 3.6 cluster compatibility.
[1] https://fedorapeople.org/groups/virt/virt-preview/fedora-virt-preview.repo
[2] https://fedorapeople.org/groups/virt/virt-preview/
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
9 years, 9 months
[QE][ACTION REQUIRED] oVirt 3.6.0 status
by Sandro Bonazzola
Hi, here's an update on 3.6 status on integration / rel-eng side
ACTION: Feature proposed for 3.6.0 must now be collected in the 3.6 Google doc [1] and reviewed by maintainers.
Finished the review process, the remaining key milestones for this release will be scheduled.
For reference, external project schedules we're tracking are:
Fedora 22: 2015-05-19
Fedora 20 End Of Life: 2015-06-19 (1 month after Fedora 22 release)
Foreman 1.8.0: 2015-03-01
GlusterFS 3.7: 2015-04-29
OpenStack Kilo: 2015-04-30
QEMU 2.3.0: 2015-03-27
The tracker bug for 3.6.0 [2] currently shows no blockers.
There are 548 bugs [3] targeted to 3.6.0.
Excluding node and documentation bugs we have 506 bugs [4] targeted to 3.6.0.
oVirt 3.6 cluster compatibility status in nightly builds:
VDSM patch introducing 3.6 compatibility[5] has not been merged yet, waiting for CentOS and RHEL 7.1 to be released for getting libvirt support.
CentOS and RHEL 6.z won't have 3.6 compatibility by design [6].
Fedora 20 won't have 3.6 compatibility level since virt maintainers are going to maintain latest libvirt rpms only in latest stable Fedora release
(currently Fedora 21). There's no point in providing Fedora 20 packages on oVirt side since Fedora 20 will go EOL before oVirt 3.6.0 GA.
Fedora 21 will be able to support 3.6 compatibility once VDSM patch[5] will be merged.
Fedora 22 may not be able to support VDSM at all since it will run Python 3 instead of Python 2 as default python interpreter[7], so more work will be
needed there.
[1] http://goo.gl/9X3G49
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1155425
[3] https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_release%3A3.6....
[4] http://goo.gl/ZbUiMc
[5] http://gerrit.ovirt.org/37384
[6] http://lists.ovirt.org/pipermail/users/2014-September/027421.html
[7] https://fedoraproject.org/wiki/Releases/22/ChangeSet
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
9 years, 9 months
[QE][ACTION REQUIRED] oVirt 3.5.2 RC status
by Sandro Bonazzola
Hi,
We're going to start composing oVirt 3.5.2 RC on *2015-02-25 08:00 UTC* from 3.5 branch.
Maintainers:
- Please be sure that 3.5 snapshot allow to create VMs before *2015-02-24 15:00 UTC*
- Please be sure that no pending patches are going to block the release before *2015-02-24 15:00 UTC*
- If any patch must block the RC release please raise the issue as soon as possible.
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.
There are still 43 bugs [2] targeted to 3.5.2.
Excluding node and documentation bugs we still have 35 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, 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
Get involved in oVirt project! February edition
by Sandro Bonazzola
Hi,
do you want to get involved in oVirt project?
Here are some bugs you can hopefully fix in less that one day or you can just try to reproduce providing info:
Bug ID Whiteboard Status Summary
1059952 integration NEW hosted-engine --deploy (additional host) will fail if the engine is not using the default self-signed CA
1065350 integration NEW hosted-engine should prompt a question at the user when the host was already a host in the engine
1073421 integration NEW [RFE] allow additional parameter for engine-backup to omit audit_log data
1080823 integration NEW [RFE] make override of iptables configurable when using hosted-engine
1083104 integration NEW engine-setup --offline does not update versionlock
Do you want something easier?
Bug ID Whiteboard Status Summary
1174285 i18n NEW [de-DE] "Live Snapshot Support" reads "Live Snapsnot Support"
772931 infra NEW [RFE] Reports should include the name of the oVirt engine
1143817 integration NEW [TEXT ONLY] - Hosted Engine - Instructions for FQDN are not clear enough
1156060 integration NEW [text] engine admin password prompt consistency
1115059 network NEW Incomplete error message when adding VNIC profile to running VM
734120 storage NEW [RFE] VDSM: use virt-sparsify/zerofree to reduce image size
Do you love "DevOps?", you count stable builds in jenkins ci while trying to fall a sleep?
Then oVirt infra team is looking for you!, join the infra team and dive in to do the newest and coolest devops tools today!
Here are some of our open tasks you can help with: https://fedorahosted.org/ovirt/report/1
You don't have programming skills, not enough time for DevOps but you want still to contribute?
Here are some bugs you can take care of, also without writing a line of code:
Bug ID Whiteboard Status Summary
1074545 docs NEW Error in API documentation: Create API object in python sdk
1099995 docs NEW Migrate to Hosted Engine How-To does not state all pre-reqs
1099998 docs NEW Hosted Engine documentation has several errors
1159784 docs NEW [RFE] Document when and where new features are available when upgrading cluster / datacenters
1074301 infra NEW [RFE] ovirt-shell has no man page
1120585 integration NEW update image uploader documentation
1120586 integration NEW update iso uploader documentation
1120588 integration NEW update log collector documentation
Do you prefer to test things? We have some test cases[5] you can try using nightly snapshots[6]
Do you want to contribute test cases? Most of the features[7] included in oVirt are missing a test case, you're welcome to contribute one!
Is this the first time you try to contribute to oVirt project?
You can start from here [1][2]!
Don't know gerrit very well? You can find some more docs here [3].
Any other question about development? Feel free to ask on devel(a)ovirt.org or on irc channel[4].
[1] http://www.ovirt.org/Develop
[2] http://www.ovirt.org/Working_with_oVirt_Gerrit
[3] https://gerrit-review.googlesource.com/Documentation
[4] http://www.ovirt.org/Community
[5] http://www.ovirt.org/Category:TestCase
[6] http://www.ovirt.org/Install_nightly_snapshot
[7] http://www.ovirt.org/Category:Feature
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
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
