[openstack-dev] [Fuel] Let's stick to OpenStack global requirements

Sebastian Kalinowski skalinowski at mirantis.com
Wed Mar 18 16:25:28 UTC 2015

I assume that you considered a situation when we have a common repository
with RPMs for Fuel master and for nodes.
There are some plans (unfortunately I do not know details, so maybe someone
from OSCI could tell more) to split those repositories. How this workflow
will work with those separated repos? Will we still need it?


2015-03-18 11:04 GMT+01:00 Roman Prykhodchenko <me at romcheg.me>:

> 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
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150318/d788b340/attachment.html>

More information about the OpenStack-dev mailing list