Hi,
It's been about 2 weeks since the last status update, so here's the latest:
https://fedoraproject.org/wiki/OpenStack_status_report_2012-05-24
Historical archives are here:
http://fedoraproject.org/wiki/OpenStack_status_reports
Cheers, Pádraig.
(appended below for convenience)
= Package updates =
== openstack-nova ==
nova was synced with the stable branch incorporating [http://pkgs.fedoraproject.org/gitweb/?p=openstack-nova.git;a=commit;h=07d81d... 15 new fixes].
Alan Pevec also cleaned up the nova package dependencies removing many packages no longer needed by Essex.
== openstack-glance ==
glance was synced with the stable branch incorporating [http://pkgs.fedoraproject.org/gitweb/?p=openstack-glance.git;a=commit;h=bee8... 5 new fixes] including a change to stop auto creating the database on service start, allowing for more robust control over the database.
== openstack-keystone ==
keystone was synced with the stable branch incorporating [http://pkgs.fedoraproject.org/gitweb/?p=openstack-keystone.git;a=commit;h=ed... 1 new fix]. Also included there was a package dependency cleanup.
Also related to dependency removal is the creation of a new [https://bugzilla.redhat.com/show_bug.cgi?id=824034 python-keystone-auth-token subpackage] for keystone to minimize dependencies in certain multi host setups.
== oz ==
The OZ VM guest builder was updated to 0.8.0 in Fedora 16,17 and EPEL 6 which addressed many issues when using on current platforms.
= new packages =
== python-jsonschema ==
A [http://pbrady.fedorapeople.org/python-jsonschema/ python JSON schema validator was packaged] for Fedora to support the upcoming OpenStack Folsom milestone 1 (glance uses this). This is the first python JSON schema validator packaged for Fedora, so should be generally useful outside of OpenStack.
== python-websockify and novnc ==
Adam Young prepared [https://bugzilla.redhat.com/show_bug.cgi?id=822182 python-websockify] and [https://bugzilla.redhat.com/show_bug.cgi?id=822187 noVNC] packages for review, to support vnc access to openstack guests through the web dashboard.
== cloud-init for RHEL ==
An initial version of [http://pbrady.fedorapeople.org/cloud-init-el6/ cloud-init for RHEL] was prepared. There was immediate [https://lists.launchpad.net/openstack/msg12106.html interest expressed] in adding the changes upstream.
= Misc =
== Fedora/RHEL OpenStack manuals ==
Anne Gentle prepared excellent [https://review.openstack.org/#/c/7431/ Fedora/RHEL documentation for the OpenStack manuals], which is currently under review upstream.
== Diablo on EPEL ==
There was a request from Brookhaven National Lab as to how to continue using Diablo on RHEL (derivatives) given that EPEL has now updated to the Essex release. Older builds can be downloaded from koji, and these in conjunction with the yum-priorities plugin can be used to create a diablo repo on top of EPEL. A [http://pbrady.fedorapeople.org/openstack-diablo-el6/ convenience repository for Diablo on EPEL] was made available, containing instructions on how it was created and how to use it.
On Thu, May 24, 2012 at 11:27:55AM -0500, Pádraig Brady wrote:
== Diablo on EPEL ==
There was a request from Brookhaven National Lab as to how to continue using Diablo on RHEL (derivatives) given that EPEL has now updated to the Essex release. Older builds can be downloaded from koji, and these in conjunction with the yum-priorities plugin can be used to create a diablo repo on top of EPEL. A [http://pbrady.fedorapeople.org/openstack-diablo-el6/ convenience repository for Diablo on EPEL] was made available, containing instructions on how it was created and how to use it.
i'd like for us to consider making a permanent repo, and policy, for maintaining older openstack releases going forward. the request to maintain diablo, in addition to essex, necessitates the conversation.
epel isn't designed to hold multiple supported versions of a whole suite of packages, such as openstack. they have different lifecycle requirements, as the above proves.
as such, can we: 1) set a policy for how long the sig wants to maintain a given openstack release? 2) define a permanent repository location for each openstack release? 3) consider likewise for other cloud sig frameworks (openshift, eucalyptus, cloudstack, opennebula) should the need arise (which i would anticipate).
it may necessitate creating new top-level projects such as epel was, for each, with rel-eng and infrastructure resources. scratch-builds and manual copying only get us so far.
thoughts?