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 <skalinow...@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 <m...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Dmitry Borodaenko __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev