Open Stack

Thomas Goirand wrote:
> Hi,
> 
> For updating keystone from 2014.1.1 to 2014.1.2, I had to:
> 
> - Upgrade oslo-config from 1.2.1 to 1.4.0.0~a3
> - Upgrade oslo.messaging from 1.3.0~a9 to 1.4.0.0~a3
> - Upgrade python-six from 1.6 to 1.7
> - Upgrade python-pycadf from 0.4 to 0.5.1
> - Add python-ldappool
> - Add python-oslo.db
> - Add python-oslo.i18n
> - Add python-keystonemiddleware, which needs python-crypto >= 2.6
> (previously, 2.5 was enough)
> 
> So, we have 5 major Python module upgrades, and 4 completely new
> libraries which were not there in 2014.1.1. Some of the changes aren't
> small at all.
> 
> I'm sure that there's very valid reasons for each of the upgrades or
> library addition, but I don't think that it is overall reasonable. If
> this was to happen during the freeze of Debian, or worse, after a
> release, upgrading all of this would be a nightmare, and I'm sure that
> the Debian release team would simply refuse.
> 
> Should I assign myself to program a robot which will vote -1 on all
> change on the stable/Icehouse global-requirements.txt file? Or is sanity
> still possible in OpenStack? :)
> 
> It is my opinion that we need to review our release process for the
> stable releases, policy for requirement changes, and need to adopt a way
> more conservative attitude.

No, actually this is because the 2014.1.2 tarball is still completely
wrong. The tag is now OK, but due to some stale workspaces in our CI the
tarball was still generated from the wrong (Juno) tag.

I'll upload a new tarball ASAP. I took down the wrong one. Sorry for the
inconvenience... the issues here are not a policy problem, they are just
human error in the original tag, complicated by CI staleness that made
us think we fixed it while we didn't.

-- 
Thierry Carrez (ttx)