On 22 September 2017 at 17:21, Paul Belanger <[email protected]> wrote: > On Fri, Sep 22, 2017 at 02:31:20PM +0000, Jeremy Stanley wrote: >> On 2017-09-22 15:04:43 +0200 (+0200), Attila Fazekas wrote: >> > "if DevStack gets custom images prepped to make its jobs >> > run faster, won't Triple-O, Kolla, et cetera want the same and where >> > do we draw that line?). " >> > >> > IMHO we can try to have only one big image per distribution, >> > where the packages are the union of the packages requested by all team, >> > minus the packages blacklisted by any team. >> [...] >> >> Until you realize that some projects want packages from UCA, from >> RDO, from EPEL, from third-party package repositories. Version >> conflicts mean they'll still spend time uninstalling the versions >> they don't want and downloading/installing the ones they do so we >> have to optimize for one particular set and make the rest >> second-class citizens in that scenario. >> >> Also, preinstalling packages means we _don't_ test that projects >> actually properly declare their system-level dependencies any >> longer. I don't know if anyone's concerned about that currently, but >> it used to be the case that we'd regularly add/break the package >> dependency declarations in DevStack because of running on images >> where the things it expected were preinstalled. >> -- >> Jeremy Stanley > > +1 > > We spend a lot of effort trying to keep the 6 images we have in nodepool > working > today, I can't imagine how much work it would be to start adding more images > per > project. > > Personally, I'd like to audit things again once we roll out zuulv3, I am sure > there are some tweaks we could make to help speed up things.
I don't understand, why would you add images per project? We have all the images there.. What I'm talking about is to leverage what we'll have soon (registry) to lower time of gates/DIB infra requirements (DIB would hardly need to refresh images...) > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
