Folks, >>> Correct me if I am wrong, but isn't it what we have containers on master >>> node for? >>> On the master node itself conflicts won’t happen because the components are >>> run in their containers.
Do you propose to use _separate_ package repository for each docker container? (It means separate gerrit project for each package of each container, including openstack projects) On Thu, Mar 19, 2015 at 1:16 PM, Roman Prykhodchenko <m...@romcheg.me> wrote: > Folks, > >> 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». > > Exactly. > >> I'm not sure it's good idea. >> We should stay so close to upstream distro as we can. It should be >> very important reason to update package against it's upstream distro > > > The issue is the following: OpenStack’s components are tested against those > versions of dependencies, that are specified in their requirements. IIRC > those requirements are set up by pip so CI nodes contain latest versions of > python packages that match their specs. > > The question is whether it’s required to ship OpenStack services with > packages from a distro or with packages, that are used for testing. > >> Splitting of repositories doesn't help to solve python packages >> conflicts because master node uses a number of openstack components. > > On the master node itself conflicts won’t happen because the components are > run in their containers. > > > - romcheg > > >> 19 бер. 2015 о 10:47 Dmitry Burmistrov <dburmist...@mirantis.com> >> написав(ла): >> >> Roman, all >> >>>>> - OSCI mirror should contain the maximum version of a requirement >>>>> that matches its version specification. >> I'm not sure it's good idea. >> We should stay so close to upstream distro as we can. It should be >> very important reason to update package against it's upstream distro >> version. >> If we update some package, we should maintain it too. Tracking bugs, >> CVEs and so on. The more packages, the more efforts to support it. >> >>>>> - 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 >> Need to be discussed and investigated. >> >> Sebastian, Dmitry, >> >> >>>>> There are some plans (unfortunately I do not know details, so maybe >>>>> someone from OSCI could tell more) to split those repositories >> Splitting of repositories doesn't help to solve python packages >> conflicts because master node uses a number of openstack components. >> Anyway it should be done for 7.0 milestone in order to separatre >> master-node distro from environment one. (e.g. if we going to move >> master-node to debian) >> >> >> >> On Thu, Mar 19, 2015 at 12:01 AM, Dmitry Borodaenko >> <dborodae...@mirantis.com> wrote: >>> 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 >> >> __________________________________________________________________________ >> 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 > __________________________________________________________________________ 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
