Debian OpenStack packaging BoF ============================== [wendar] For a several years, the OpenStack packaging work has relied on the heroic work of one person (thanks zigo!). In the past few months, we’ve been expanding the effort out to a broader team, leading to a DebCamp sprint last week where we made good progress on some key goals like: - moving general Python dependencies for OpenStack into the Debian Python Modules Team, - moving OpenStack packaging work back to Alioth git repositories, to be more welcoming to broader Debian contributions, - laying the groundwork for packaging the Pike release of OpenStack (currently in RC, heading for release at the end of the month) This BoF is a chance to chat a bit about our thoughts on what lies ahead, welcome feedback, and welcome anyone who might be interested in joining our growing band of DebStackers. Notes from the OpenStack BoF ============================ (quick notes; need to be expanded a bit afterwards) Opening Question: * Who as used OpenStack (even as a User)? ca. 8/16 People rise Hands. CI: * [zigo] spoke with Holger, using jenkins.d.n with tempest etc. should be no problem Upgrade Path: * upstream supports +1 upgrades only, okata never got packaged. upgrade path for stretch->buster needs okata (or some other way, some distros do support +2 upgrades) * we'll use stable-backports, and move them one OS release after another to an "offsite" archive so users can catch-up if they missed one (when using stable-backports), or, use it to do incremential updates stable->stable+1 Python 3: * swift is the only hold up for pike Anyone interesting to help with packaging OpenStack? * two people volunteered, people should sign up to the mailinglist on alioth and join the irc channel. OpenStack supported in LTS? * no, hardly usefull; majority of serious users do: - people either upgrade in place every 6 months - or replace after 5 year to new hardware Synergies with Ubuntu? * for dependencies, yes * not for openstack services/core packages (missing default configurations) * after pike, we'll try to make use of as much synergies as possible * suggestion: move the preseed to own packages?