OVIRT-3.5-TEST-DAY-3: CPU SLA for capping
by Juan Hernandez
Hello,
I tested the support for limiting the use of CPU of VMs. Setting it up
in the GUI worked correctly, but when starting the VM the settings are
ignored. Apparently the reason is a mismatch between the parameters that
the engine sends and what VDSM expects:
https://bugzilla.redhat.com/1142851
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.
9 years, 7 months
Package vdsm-4.13.4-0.el6.x86_64.rpm is not signed again in 3.3.5. repo
by Sven Kieske
Hi,
well the message in the topic already explains what is wrong.
This happend already once some days ago and dcaro fixed it, but somehow
this occurs again.
It would be kind of someone could fix it.
Thanks
--
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
9 years, 7 months
[QE][ACTION NEEDED] oVirt 3.4.4 status
by Sandro Bonazzola
Hi,
We're going to start composing oVirt 3.4.4 GA on *2014-09-23 08:00 UTC* from 3.4 branch.
Maintainers:
- Please be sure that 3.4 snapshot allow to create VMs before *2014-09-22 15:00 UTC*
- Please be sure that no pending patches are going to block the release before *2014-09-22 15:00 UTC*
- If any patch must block the GA release please raise the issue as soon as possible.
A bug tracker [1] has been opened and shows no open blockers.
There are still 6 bugs [2] targeted to 3.4.4.
Excluding node and documentation bugs we still have 3 bugs [3] targeted to 3.4.4.
Bug ID Whiteboard Status Summary
988341 node NEW Should not create bond when report an error in configuration process
1097735 node NEW "Reboot" button failed to work in progress_page with serial console to install ovirt-node iso.
1023481 node ASSIGNED Sane and working default libvirt config
1059309 sla NEW [events] 'Available memory of host $host (...) under defined threshold...' is logged only once
1127460 storage NEW VM abnormal stop after LV refreshing when using thin provisioning on block storage
1135061 storage POST Require qemu-kvm-rhev on EL to support live snapshots
Maintainers / Assignee:
- Please add the bugs to the tracker if you think that 3.4.4 should not be released without them fixed.
- Please update the target to 3.5.1 or later for bugs that won't be in 3.4.4:
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.4 nightly snapshot, please add yourself to the test page [5]
[1] http://bugzilla.redhat.com/1118689
[2] http://red.ht/1qwhPXB
[3] http://red.ht/1r8jnap
[4] http://www.ovirt.org/OVirt_3.4.4_Release_Notes
[5] http://www.ovirt.org/Testing/oVirt_3.4.4_Testing
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
9 years, 7 months
oVirt Engine Virtual Appliance for 3.5 is ready for testing
by Fabian Deutsch
Hello!
The ready-to-use Engine appliance is now building again and should contain the the latest and greatest 3.5rc2 packages.
That appliance can be used for testing hosted engine, as well as testing oVirt Engine 3.5 in general.
The ova (intended to be used with hosted engine setup) and the qcow2 (intended to be used for testing) images can be found here:
http://jenkins.ovirt.org/view/All/job/ovirt-appliance_master_merged/
All relevant packages are pre-installed, but the appliance still needs to be configured.
To configure the appliance you need to run:
$ engine-setup --offline --config-append=ovirt-engine-answers
inside the appliance after downloading it.
Please let us know if you have any issues.
Greetings
fabian
9 years, 7 months
GWT :: pretty CSS option now part of draft mode
by Vojtech Szocs
Hi,
with patch [1] merged to master, enabling "pretty" (non-obfuscated)
CSS for GWT applications can now be done simply by activating draft
mode:
$ make clean install-dev [usual makefile options] DEV_BUILD_GWT_DRAFT="1"
Previously, developers had to mess with DEV_EXTRA_BUILD_FLAGS [2]
but this is no longer necessary -- just use draft mode and you're
all set.
Frontend debug wiki http://www.ovirt.org/DebugFrontend was updated
to reflect this change.
Regards,
Vojtech
[1] http://gerrit.ovirt.org/#/c/31342/
[2] DEV_EXTRA_BUILD_FLAGS="-Dgwt.cssResourceStyle=pretty"
9 years, 7 months
oVirt Node Weekly Meeting Minutes - September 16th 2014
by Fabian Deutsch
Minutes: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-09-16-13.00.html
Minutes (text): http://ovirt.org/meetings/ovirt/2014/ovirt.2014-09-16-13.00.txt
Log: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-09-16-13.00.log.html
=================================
#ovirt: oVirt Node Weekly Meeting
=================================
Meeting started by fabiand at 13:00:25 UTC. The full logs are available
at http://ovirt.org/meetings/ovirt/2014/ovirt.2014-09-16-13.00.log.html
.
Meeting summary
---------------
* Agenda (fabiand, 13:00:45)
* Action Item Review (fabiand, 13:00:50)
* oVirt 3.5 (fabiand, 13:00:54)
* Jenkins (fabiand, 13:00:58)
* Next-Gen Node (fabiand, 13:01:16)
* Other Items (fabiand, 13:01:23)
* oVirt 3.5 (fabiand, 13:04:11)
* Testing and some smaller bug ficxing happend last Friday (fabiand,
13:04:24)
* rbarry created a new iso (fabiand, 13:04:41)
* ovirt-node-iso-3.5.0.ovirt35.20140912.el6.iso contains 3.5rc2
packages (fabiand, 13:06:44)
* ovirt-node rpms need to be published (fabiand, 13:06:51)
* ACTION: fabiand to generate rpms for 3.5rc2 iso (fabiand, 13:10:54)
* ACTION: fabiand to ask dcaro to publish iso (fabiand, 13:11:05)
* Action Item Review (fabiand, 13:13:05)
* LINK:
http://lists.ovirt.org/pipermail/devel/2014-September/008713.html
(fabiand, 13:13:16)
* fabiand to fix appliance job during the next week (fabiand,
13:13:33)
* LINK:
http://jenkins.ovirt.org/view/All/job/ovirt-appliance_master_merged/
(fabiand, 13:13:42)
* appliance rootfs is built, ova is currentl not created, but WIP
(fabiand, 13:14:36)
* Jenkins (fabiand, 13:15:00)
* Next-Gen Node (fabiand, 13:19:53)
* Stable job which builds the runtime layout (fabiand, 13:20:21)
* LINK: http://www.ovirt.org/OVirt_3.5_release-management (fabiand,
13:20:41)
* Stable job to run functional tests on runtime layout image
(fabiand, 13:20:53)
* LINK: http://www.ovirt.org/OVirt_3.5_release-management (fabiand,
13:21:53)
* Idea to do configuration using puppet - early investigationsdone by
rbarry (fabiand, 13:32:14)
* ripping the guts out of ovirt.node.config.defaults and shipping
small puppet manifests which match each bit (kdump, ntp, rsyslog,
etc al), assigning variables with hiera and pushing from there
(fabiand, 13:32:28)
* etcd hiera provider is also interesting to configure many nodes at
once (fabiand, 13:32:48)
* ACTION: rbarry to create a wiki page summarizing all the compoents
which need a module, also specifying if it can be done with puppet
or needs something else (fabiand, 13:33:30)
* Other Items (fabiand, 13:37:50)
Meeting ended at 13:43:19 UTC.
Action Items
------------
* fabiand to generate rpms for 3.5rc2 iso
* fabiand to ask dcaro to publish iso
* rbarry to create a wiki page summarizing all the compoents which need
a module, also specifying if it can be done with puppet or needs
something else
Action Items, by person
-----------------------
* fabiand
* fabiand to generate rpms for 3.5rc2 iso
* fabiand to ask dcaro to publish iso
* rbarry
* rbarry to create a wiki page summarizing all the compoents which
need a module, also specifying if it can be done with puppet or
needs something else
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* fabiand (113)
* rbarry (14)
* dougsland (6)
* vidalinux (5)
* Netbulae (4)
* ovirtbot (4)
* [trip] (1)
* winfr34k (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
9 years, 7 months
[ANN] oVirt 3.5 Third Test Day - Wed Sep 17th
by Sandro Bonazzola
Hi all,
On Wed Sep 17th (instead of Sep 16th) we'll have oVirt 3.5.0 third test day.
On this day all relevant engineers will be online ready to support
any issues you find during install / operating this new release.
Just make sure you have 1 host or more to test drive the new release.
If you're curious to see how it works, this is your chance.
Thanks again for everyone who will join us tomorrow!
Location
#ovirt irc channel
Please communicate here to allow others to see any issues
What
In this test day you have a license to kill ;)
Follow the documentation to setup your environment, and test drive the new features.
Please remember we expect to see some issues, and anything you come up with will save you when you'll install final release
Remember to try daily tasks you'd usually do in the engine, to see there are no regressions.
Write down the configuration you used (HW, console, etc) in the report etherpad[1].
Documentation
Release notes: http://www.ovirt.org/OVirt_3.5_Release_Notes
Features pages links: http://bit.ly/17qBn6F
If you find errors in the wiki please annotate it as well in report etherpad [1]
Prerequisites / recommendations
Use CentOS or RHEL 6.5 only. 6.4 is unsupported due to various issues (sanlock, libvirt, etc).
Use Fedora 19 or 20.
Latest RPMs
repository to be enabled for testing the release are listed in the release notes page [2].
NEW issues / reports
For any new issue, please update the reports etherpad [1]
Feature owners, please make sure:
your feature is updated and referenced on release page [2].
you have testing instruction for your feature either on test day page [3] or in your feature page.
your team regression testing section is organized and up to date on test day page [3].
[1] http://etherpad.ovirt.org/p/3.5-testday-3
[2] http://www.ovirt.org/OVirt_3.5_Release_Notes
[3] http://www.ovirt.org/OVirt_3.5_TestDay
Thanks.
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
9 years, 7 months
[RFC] Release process
by Sandro Bonazzola
Hi,
while we're near to release 3.5.0 I would like to start the discussion on the release process for 3.5.z and 3.6.0.
The reference page for the release process has been last updated 2 years ago and is not reflecting the way we're managing the releases anymore.
In order to start the discussion here's what we are currently doing:
= oVirt maintenance releases =
* After a new 3.y.0 release, maintenance releases are scheduled every month until a new 3.y+1.0 release is published.
* After first 3.y.0 release candidate is published a new release management wiki page is created (see http://www.ovirt.org/OVirt_3.4.z_release-management)
* For each 3.y.z release, the release management page is updated
** Defining the schedule for RC and GA date
** Pointing to the new release note page to be created (see http://www.ovirt.org/OVirt_3.4.4_Release_Notes)
** Pointing to a testing page to be created (see http://www.ovirt.org/Testing/oVirt_3.4.4_Testing)
** Pointing to a blocker bug to be created (see http://bugzilla.redhat.com/1118689)
* Weekly status email are sent to users and devel lists
* QA page is updated with pointers to the new release (see http://www.ovirt.org/OVirt_Quality_Assurance)
* Release manager update the release notes pages starting from RC
Usually RC date is scheduled one week before GA.
RC releases are created by taking the latest nightly snapshot available after verifying that the build passes basic sanity test and repository closure.
A new stabilization branch is created with the same git hash used for building the snapshot.
Between RC and GA release criteria are tested on the RC and if the release met the criteria a GA release will be built just updating the versioning
code to drop master, git hash and timestamp suffix from tarballs and rpms.
A new RC will be created and GA postponed by one week if release criteria are not met.
= oVirt Release Process =
* After a new 3.y.0 release, a new 3.y+1.0 release is tentatively scheduled after 6 months.
* A new release management page is created (see http://www.ovirt.org/OVirt_3.5_release-management)
* A new tracker bug is created (see http://bugzilla.redhat.com/1073943)
* A discussion is started on devel and users mailing list gathering idea for next release features
* Teams prepare a list of accepted features collecting / creating bug tracker, devel owner, qa owner, feature page for each of them
* Several presentations are scheduled by the teams presenting the accepted features
* An alpha release is scheduled 4 months before GA
* Feature freeze is scheduled 3 months before GA
* A beta release is scheduled 2 months before GA, git tree is branched for stabilization
* A release candidate is scheduled 1 month before GA
* Weekly status email are sent starting 3 weeks before alpha release.
* Test days are scheduled after every milestone release
* Release manager update the release notes pages starting from Alpha
All milestones releases are created by taking the latest nightly snapshot available after verifying that the build passes basic sanity test and
repository closure.
RC will be postponed until all known blockers are fixed
Between RC and GA release criteria are tested on the RC and if the release met the criteria a GA release will be built just updating the versioning
code to drop master, git hash and timestamp suffix from tarballs and rpms.
A new RC will be created and GA postponed by one week if release criteria are not met.
[[Category:Release management]]
What I think we're missing / doing wrong:
* A discussion about release criteria *after* accepted features list is ready
* A clear schedule like http://fedoraproject.org/wiki/Releases/21/Schedule
* A clear feature freeze policy like https://fedoraproject.org/wiki/Changes_Freeze_Policy
* A clear policy about changes we must allow and not allow between RC and GA
* Alpha release should come after feature freeze
* A string freeze schedule, allowing translators to have enough time to translate new strings
* Maintainers should pay more attention to release notes and test day pages
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
9 years, 7 months
