Open Stack

On 4/9/19 12:13 PM, Chris Dent wrote:
> 
>  From etherpad [1]:
> 
> * Some talk in the past of moving https://github.com/cdent/placedock
>    into placement but not sure
> * Another option is [to] trigger container build with each merge
> 
> I wrote this one, so I guess I should expand on it a bit. Basically,
> placedock is a Dockerfile for placement that strives to be small but
> configurable. The same repo also contains instructions (and YAML)
> for using the container in kubernetes, and provides a helm chart
> that uses the generated image.
> 
> Each of those three things is done in a way where many of the
> choices are made for you in favor of being light and simple. In
> things like Kolla, openstack-helm, and other containerizing setups
> some of those choices are left as options, making the build and run
> infrastructure more complex. The result with placedock is a tiny
> service that scales horizontally really well.
> 
> In the past there's been talk of including some of that stuff in the
> placement repo itself as a sort of "hey look, here's one way to do
> it". If we did that, which stuff?
> 
> Another suggestion has been to use a web-hook or similar from zuul
> to trigger an image build (either at docker hub or some other
> registry) post-merge.

We actually have some pretty awesome new container building jobs in Zuul 
now - I'd recommend using them. One of the things they can do is build 
your container image to be used in a gate job, and then when the patch 
for the gate job merges, publish and tag the actual container image used 
in the gate.

This also works with depends-on, so if you have container images that 
consume layers from other container images or are built on top of them, 
all the right things happen.

I'd be happy to help you get that set up in placement.

> Or we can let things go as they are (I manually build new images
> every now and again, which triggers automatic placecat [2] testing).

One of the neat things with depends-on and containers is that it's done 
via registry config, so jobs _consuming_ images don't have to know that 
they're consuming speculative future images. This means you could have 
your placecat job run in the placement container build gate job against 
the speculative container state and things shoud Just Work.

> The reason this comes back up is because I'm somewhat concerned that
> the "seriously, this is really simple" aspect of Placement gets lost
> and there's probably plenty of useful info in this kind of stuff. If
> we make it owned by more than just me, that might help spread the
> learning.
> 
> Thoughts?k
> 
> [1] https://etherpad.openstack.org/p/placement-ptg-train
> 
> [2] https://github.com/cdent/placecat
> 
>