- Devel - oVirt List Archives

[ANN] oVirt 3.5 Third Test Day - Wed Sep 17th
by Sandro Bonazzola 15 Sep '14

15 Sep '14

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

1 0

[URGENT][ACTION REQUIRED] oVirt engine on branch 3.5 doesn't build anymore
by Sandro Bonazzola 15 Sep '14

15 Sep '14

Hi, we should release oVirt 3.5.0 RC2 today but looks like it doesn't build anymore. Can you please fix it as soon as possible? See: http://jenkins.ovirt.org/job/ovirt-engine_3.5_create-rpms_merged/221/ Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

6 11

[RFC] Release process
by Sandro Bonazzola 15 Sep '14

15 Sep '14

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

1 2

[ACTION NEEDED] Please fix vdsm build dependencies on master
by Sandro Bonazzola 15 Sep '14

15 Sep '14

Hi, looks like VDSM is missing python-ethtool as BuildRequire on EL6 and FC20: http://jenkins.ovirt.org/job/vdsm_master_install-rpm-sanity-fc20_created/35… http://jenkins.ovirt.org/job/vdsm_master_install-rpm-sanity-el6_created/368… Please fix. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 3

feature review - ReportGuestDisksLogicalDeviceName
by Liron Aravot 13 Sep '14

13 Sep '14

Feel free to review the the following feature. http://www.ovirt.org/Features/ReportGuestDisksLogicalDeviceName

5 7

mom-0.4.2 released (Karma requested)
by Adam Litke 12 Sep '14

12 Sep '14

Hi all, I have released mom-0.4.2 and submitted updates for f20[1], el6[2], and epel7[3]. If you have a spare cycle, please install this new version from the updates-testing repository and add a comment in the fedora updates system. This will help expedite the rollout of this update. Thanks! [1] https://admin.fedoraproject.org/updates/FEDORA-2014-10757/mom-0.4.2-1.fc20 [2] https://admin.fedoraproject.org/updates/mom-0.4.2-1.el6 [3] https://admin.fedoraproject.org/updates/mom-0.4.2-1.el7 -- Adam Litke

2 2

[ANN] oVirt 3.5.0 Second Release Candidate is now available for testing
by Sandro Bonazzola 12 Sep '14

12 Sep '14

The oVirt team is pleased to announce that the 3.5.0 Second Release Candidate is now available for testing as of Sep 11th 2014. The release candidate is available now for Fedora 19, Fedora 20 and Red Hat Enterprise Linux 6.5 (or similar) and allow you to use Red Hat Enterprise Linux 7 as node and run Hosted Engine. Feel free to join us testing it on Tue 2014-09-16 third test day! This release of oVirt includes numerous bug fixes. See the release notes [1] for a list of the new features and bugs fixed. The existing repository ovirt-3.5-pre has been updated for delivering this release without the need of enabling any other repository. If you're already using oVirt 3.5 repository, please update ovirt-release35 rpm. Please refer to release notes [1] for Installation / Upgrade instructions. New oVirt Live, oVirt Guest Tools and oVirt Node ISO will be available soon as well[2]. Please note that mirrors may need usually one day before being synchronized. If you want to be sure to use latest rpms and don't want to wait for the mirrors, you can edit /etc/yum.repos.d/ovirt-3.5.repo commenting the mirror line and removing the comment on baseurl line. Please refer to the release notes for known issues in this release. [1] http://www.ovirt.org/OVirt_3.5_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.5-pre/iso/ -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

3 2

[ATTN] Changing messages with variable placeholders
by Einav Cohen 11 Sep '14

11 Sep '14

all, in general, changing non-English messages in the code is forbidden, as these are pulled automatically from the translation management system (Zanata). HOWEVER: changing non-English messages in the code is *a must* in case not doing so will result in maven build failure. this can happen when changing the quantity of variable placeholders in localized messages. example: let's say that I have an English message: "xxx {0} yyy {1}" and the parallel non-English messages are: "aaa {0} bbb {1}", "ccc ddd {0} {1}", "{1} eee fff {0}", etc. If I am changing the English message to be: "xxx {0}" but leaving the parallel non-English messages as is: "aaa {0} bbb {1}", "ccc ddd {0} {1}", "eee {1} fff {0}", etc. now the messages for the same key in different locales have different amounts of variable placeholders in them. this would result in a mvn build error. ** so whenever changing the quantity of variable placeholders in an English message, you must change the parallel non-English messages to match the new variable placeholders quantity. ** in the example above: the "{1}" placeholder (that was removed from the English message) should be removed from the non-English messages, so that the updated non-English messages would be: "aaa {0} bbb", "ccc ddd {0}", "eee fff {0}", etc. you don't need to worry about the correctness of the non-English messages that you are changing; this will be taken care of in the translation cycle that will follow your patch. you just need to do the minimal changes necessary (remove placeholders / append placeholders) so that build errors will not occur. NOTE: this can be very easily missed, as this type of build error will occur only when building the project with non-English locales (e.g. with the "BUILD_LOCALES=1" parameter within the "make" command in a devel env). So please - pay extra attention when making this kind of messages changes; if in doubt - build with "BUILD_LOCALES=1" and/or ask. Let me know if you have any questions. Many thanks in advance. ---- Regards, Einav

3 4

Packages for oVirt 3.5.0 RC2
by Sandro Bonazzola 11 Sep '14

11 Sep '14

1 0

[ACTION NEEDED] vdsm master jobs failing on mock building due to missing build dependencies
by Sandro Bonazzola 11 Sep '14

11 Sep '14

Hi, can you please take a look at the following jobs? http://jenkins.ovirt.org/job/vdsm_master_install-rpm-sanity-el6_created/352/ http://jenkins.ovirt.org/job/vdsm_master_install-rpm-sanity-fc20_created/33… Looks like build dependencies are missing. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 2