"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. You need to provide a bug link(s) (distribution/upstream bug) for blacklisting a package. Very unlikely we will run out from the disk space juts because of the too many packages, usually if a package causes harm to anything it is a distro/upstream bug which expected to be solved within 1..2 cycle in the worst case scenario. If the above thing proven to be not working, we need to draw the line based on the expected usage frequency. On Wed, Sep 20, 2017 at 3:46 PM, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2017-09-20 15:17:28 +0200 (+0200), Attila Fazekas wrote: > [...] > > The image building was the good old working solution and unless > > the image build become a super expensive thing, this is still the > > best option. > [...] > > It became a super expensive thing, and that's the main reason we > stopped doing it. Now that Nodepool has grown support for > distributed/parallel image building and uploading, the cost model > may have changed a bit in that regard so I agree it doesn't hurt to > revisit that decision. Nevertheless it will take a fair amount of > convincing that the savings balances out the costs (not just in > resource consumption but also administrative overhead and community > impact... 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?). > -- > Jeremy Stanley > > __________________________________________________________________________ > 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
