[tripleo] Container image tooling roadmap

Sean Mooney smooney at redhat.com
Sun May 3 01:31:41 UTC 2020


On Sat, 2020-05-02 at 13:37 +0000, Jeremy Stanley wrote:
> On 2020-05-01 15:18:13 -0500 (-0500), Kevin Carter wrote:
> > As you may have seen, the TripleO project has been testing the
> > idea of building container images using a simplified toolchain
> 
> [...]
> 
> Is there an opportunity to collaborate around the proposed plan for
> publishing basic docker-image-based packages for OpenStack services?

> 
>     https://review.opendev.org/720107
assumign that goes ageand then i guess that would be one path forward to avoid
yet another set of openstack images as i share your concern although i dont think
the technical case has been made that ooo should replace the kolla images with a new set
or that the proposed cross project goal should be accpeted.
> 
> Obviously you're aiming at solving this for a comprehensive
> deployment rather than at a packaging level, just wondering if
> there's a way to avoid having an explosion of different images for
> the same services if they could ultimately use the same building
> blocks. (A cynical part of me worries that distro "party lines" will
> divide folks on what the source of underlying files going into
> container images should be, but I'm sure our community is better
> than that, after all we're all in this together.)
> 
> Either way, if they can both make use of the same speculative
by the way waht do you define as speculative image building?
if its just building contier image for git repos prepared by zuul then
kolla source image could trivialy support that.

kolla supports building images for git repos so you can just override the
source location for each image to point to the zull cloned git repos.

i have not really followed why https://review.opendev.org/720107 is somehow
unique in being able to support that? obviously without a way to rebuild distroy packages we 
build kolla binary images speculativly. but kolla source images which just pip install the
different service into a virtual env could totally support depens-on and other featuer we get
for free in the devstack jobs by virtue of using the soruce repos prepared by zuul.

> container building workflow pioneered in Zuul/OpenDev, that seems
> like a huge win (and I gather the Kolla "krew" are considering
> redoing their CI jobs along those same lines as well).




More information about the openstack-discuss mailing list