Re: [openstack-dev] [Fuel] Nominating Sergey Kulanov to core reviewers of fuel-main
Agree +1 On Fri, Nov 27, 2015 at 3:12 PM, Roman Vyalov wrote: > Hi all, > Sergey is doing great work and I hope our Fuel make system will become > even better. > Fuelers, please vote for Sergey > > __ > 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
Re: [openstack-dev] [Fuel] Let's stick to OpenStack global requirements
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 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 >> написав(ла): >> >> 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 >> 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 >>> 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 : >>>>> >>>>> Hi folks, >>>>> >>>
Re: [openstack-dev] [Fuel] Let's stick to OpenStack global requirements
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 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 > 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 : >>> >>> 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 spec
Re: [openstack-dev] [Fuel] Problem with kombu version.
Mattew, main reason is global-requirements.txt It defines that your app should work with kombu v2.4.8 and upper On Wed, Apr 9, 2014 at 3:38 PM, Matthew Mosesohn wrote: > Dmitry, I don't think you should drop kombu.five so soon. > We haven't heard directly from Fuel python team, such as Dmitry > Pyzhov, what reason we have to lock kombu at version 2.5.14. > I wrote to him earlier today out of band, so hopefully he will get > back to this message soon. > > On Wed, Apr 9, 2014 at 3:27 PM, Dmitry Teselkin > wrote: >> Hi again, >> >> So there is a reply from the Dmitry Burmistrov which for some reason was >> missed in this thread: >>> Nailgun requires exact version of kombu ( == 2.5.14 ). >>> This is the only reason why we can't update it. >>> I think you should talk to Dmitry P. about this version conflict. >>> I want to take this opportunity to remind everyone that we should >>> adhere to the global-requirements.txt in order to avoid such >>> conflicts. >> >> Hopefully our developers decided to get rid of kombu.five usage what looks >> an easy task. >> >> Thanks, everyone. >> >> >> >> On Mon, Apr 7, 2014 at 8:33 PM, Dmitry Teselkin >> wrote: >>> >>> Hello, >>> >>> I'm working on Murano integration into FUEL-5.0, and have faced the >>> following problem: our current implementation depends on 'kombu.five' >>> module, but this module (actually a single file) is available only starting >>> at kombu 3.0. So this means that murano-api component depends on kombu >>> >=3.0. This meets the OpenStack global requirements list, where kombu >>> >=2.4.8 is declared. Unfortunately, this also means that "system-wide" >>> version upgrade is required. >>> >>> So the question is - what is the right way to solve the promblem? I see >>> the following options: >>> 1. change kombu version requirement to >=3.0 for entire FUEL installation >>> - it doesn't break global requirements constraint but some other FUEL >>> components could be affected. >>> 2. replace calls to functions from 'python.kombu' and use existing version >>> - I'm not sure if it's possible, I'm awaiting answer from our developers. >>> >>> Which is the most suitable variant, or are there any other solutions for >>> the problem? >>> >>> >>> -- >>> Thanks, >>> Dmitry Teselkin >>> Deployment Engineer >>> Mirantis >>> http://www.mirantis.com >> >> >> >> >> -- >> Thanks, >> Dmitry Teselkin >> Deployment Engineer >> Mirantis >> http://www.mirantis.com >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
