Open Stack

On Mon, 11 Oct 2021 at 05:39, Sam Morrison <sorrison at gmail.com> wrote:
>
> Thank Jason and Mark,
>
> I think just adding another tag at the end of the build process is what we are going to do.
>
> On a related note doe anyone have any tips on how to version a horizon container because it has multiple repos inside.
>
> Eg. We have the source for horizon and then source for each plugin which have different versions.
> With Debian they are all separate debs and installed differently with separate version and makes tracking things really easy.
>
> In the container world it makes it a bit harder.
> I’m thinking we need to have our kolla-build.conf specify specific git refs and then when we update this file incorporate that somehow into the versioning.

This is probably one reason why kolla doesn't do it this way - there
isn't always a single versioned thing that's being deployed. Every
service has dependencies. In this case I'd suggest going with the
version of horizon.

>
> Sam
>
>
>
>
> On 8 Oct 2021, at 2:47 am, Jason Anderson <jasonanderson at uchicago.edu> wrote:
>
> Sam, I think Mark’s idea is in general stronger than what I will describe, if all you’re after is different aliases. It sounds like you are trying to iterate on two images (Barbican and Nova), presumably changing the source of the former frequently, and don’t want to build the entire ancestor chain each time.
>
> I had to do something similar because we have a fork of Horizon we work on a lot. Here is my hacky solution: https://github.com/ChameleonCloud/kolla/commit/79611111c03cc86be91a86a9ccd296abc7aa3a3e
>
> We are on Train w/ some other Kolla forks so I can’t guarantee that will apply cleanly, but it’s a small change. It involves adding build-args to some Dockerfiles, in your case I suppose barbican-base, but also nova-base. It’s a bit clunky but gets the job done for us.
>
> /Jason
>
> On Oct 7, 2021, at 3:41 AM, Mark Goddard <mark at stackhpc.com> wrote:
>
> Hi Sam,
>
> I don't generally do that, and Kolla isn't really set up to make it
> easy. You could tag the base containers with the new tag:
>
> docker pull <prefix>-base:wallaby
> docker tag <prefix>-base:wallaby <prefix>-base:<git describe output>
>
> Mark
>
> On Thu, 7 Oct 2021 at 03:34, Sam Morrison <sorrison at gmail.com> wrote:
>
>
> I’m trying to be able to build a projects container without having to rebuild the parents which have different tags.
>
> The workflow I’m trying to achieve is:
>
> Build base and openstack-base with a tag of wallaby
>
> Build a container image for barbican with a tag of the version of barbican that is returned when doing `git describe`
> Build a container image for nova with a tag of the version of barbican that is returned when doing `git describe`
> etc.etc.
>
> I don’t seem to be able to do this without having to also build a new base and openstack-base with the same tag which is slow and also means a lot of disk space.
>
> Just wondering how other people do this sort of stuff?
> Any ideas?
>
> Thanks,
> Sam
>
>
>
>
>
>