Hi folks, before you say «romcheg, go away and never come back again!», please read the story that caused me to propose this and the proposed solution. Perhaps it makes you reconsider :)
As you know for different reasons, among which are being able to set up
everything online and bringing up-to-date packages, we maintain an OSCI
repository which is used for building ISOs and deploying OpenStack services.
Managing that repo is a pretty hard job. Thus a dedicated group of people is
devoted to perform that duty, they are always busy because of a lot of
responsibilities they have.
At the same time Fuel’s developers are pretty energetic and always want to add
new features to Fuel. For that they love to use different libraries, many of
which aren’t in the OSCI mirror yet. So they ask OSCI guys to add more and more
of those and I guess that’s pretty fine except one little thing — sometimes
those libraries conflict with ones, required by OpenStack services.
To prevent that from happening someone has to check every patch against the
OSCI repo and OpenStack’s global requirements, to detect whether a version bump
or adding a new library is required an whether it can be performed. As you can
guess, there’s too much of a human factor so statistically no one does that
until problems appear. Moreover, theres’ nothing but a «it’s not compatible
with OpenStack» yelling from OSCI team that stops developers to change
dependencies in Fuel.
All the stuff described above causes sometimes tremendous time losses and is
very problem-prone.
I’d like to propose to make everyone’s life easier by following these steps:
- Create a new project called Fuel Requirements, all changes to it should go
through a standard review procedure
- We strict ourselves to use only packages from both Fuel Requirements and
Global Requirements for the version of OpenStack, Fuel is installing in the
following manner:
- If a requirement is in Global Requirements, the version spec in all
Fuel’s components should be exactly like that.
- OSCI mirror should contain the maximum version of a requirement that
matches its version specification.
- If a requirement is not in the global requirements list, then Fuel
Requirements list should be used to check whether all Fuel’s components require
the same version of a library/package.
- OSCI mirror should contain the maximum version of a requirement that
matches its version specification.
- If a requirement that previously was only in Fuel Requirements is merged
to Global Requirements, it should be removed from Global Requirements
- Set up CI jobs in both OpenStack CI and FuelCI to check all patches against
both Global Requirements and Fuel Requirements and block, if either of checks
doesn’t pass
- Set up CI jobs to notify OSCI team if either Global Requirements or Fuel
Requirements are changed.
- Set up requirements proposal jobs that will automatically propose changes
to all fuel projects once either of requirements lists was changed, just like
it’s done for OpenStack projects.
These steps may look terribly hard, but most of the job is already done in
OpenStack projects and therefore it can be reused for Fuel.
Looking forward for your feedback folks!
- romcheg
signature.asc
Description: Message signed with OpenPGP using GPGMail
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
