Open Stack

Roman,

I like this proposal very much, thanks for the idea and for putting
together a straightforward process.

I assume you meant: "If a requirement that previously was only in Fuel
Requirements is merged to Global Requirements, it should be removed
from *Fuel* Requirements".

Sebastian,

We have found ways to resolve the conflicts between clvm and docker,
and between ruby versions 1.8 and 2.1, without introducing a separate
package repo for Fuel master. I've updated the blueprint to make note
of that:
https://blueprints.launchpad.net/fuel/+spec/separate-repo-for-master-node




On Wed, Mar 18, 2015 at 9:25 AM, Sebastian Kalinowski
<skalinowski at mirantis.com> wrote:
> 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?
>
> Thanks!
> Sebastian
>
> 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
>>
>
>
> __________________________________________________________________________
> 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
>



-- 
Dmitry Borodaenko