Skip to content
This repository has been archived by the owner on Oct 15, 2019. It is now read-only.

WIP add images from registry #200

Closed
wants to merge 2 commits into from

Conversation

jordimassaguerpla
Copy link
Member

We are not using rpms anymore to deploy containers for caasp4(SLE15).
However, we would like to choose which images we use, so we will use a
patch instead of a sed command.

Signed-off-by: Jordi Massaguer Pla [email protected]

We are not using rpms anymore to deploy containers for caasp4(SLE15).
However, we would like to choose which images we use, so we will use a
patch instead of a sed command.

Signed-off-by: Jordi Massaguer Pla <[email protected]>
@jordimassaguerpla
Copy link
Member Author

I don't like very much this thing but I don't know how to make it work with kubic and caasp. I wanted to keep compatibility with sle12 since we don't yet have the sle15 image, but this is a "nice to have" thing.

@davidcassany @bergmannf : any ideas on how to do this differently?

@jordimassaguerpla
Copy link
Member Author

what if we had yaml files for each version? like public.yaml.caasp4, private.yaml.caasp4, public.yaml.caasp3, private.yaml.caasp3, public.yaml.kubic, etc...

And then in the package we install one or the other depending on the build architecture. How does it sound?

@bergmannf
Copy link
Contributor

I think using the concrete versions might be a problem - I don't know how often those change, but whenever they do we have to change the patch.

Maybe there is a way to use one of those source-services to generate the patched-in images to use the latest tag available under a certain image-name from registry.suse.de?

Also - if we do it like this, I think using the same approach in kubernetes-salt makes sense, to use a placeholder in case of using registry.suse.de and patching the concrete images in during build time.

@jordimassaguerpla
Copy link
Member Author

Having some automation in place would be great. Actually, once we were discussing with @davidcassany about getting the information from the build service by generating some metadata packages with each image build, and requiring this metadata when building c-c-m package (and k8s-salt).

The key point is to know if the tags will change that much.

Thus, will velum image be tagged on velum version, which changes on each commit, or will the velum image be tagged with a more stable number, as 0.0?

@jordimassaguerpla
Copy link
Member Author

SUSE/caaspv3-rfc#7

@jordimassaguerpla
Copy link
Member Author

I agree using the patch is not a good approach.

If we were using some kind of obs trick to get the tag, should we leave some defaults in case we don't use the RPM?

@ereslibre @MaximilianMeister : Are the development environments using the manifests files without the RPM?

@jordimassaguerpla
Copy link
Member Author

@bergmannf : Right now we are using the images based on sle12, like registry.suse.de/devel/casp/head/controllernode/images_container_base/sles12/velum:0.0, which have a tag that does not change.

What if we used this as a default until we have the automation in place?

@jordimassaguerpla
Copy link
Member Author

If we were using, as a first step, the ones based in sle12: registry.suse.de/devel/casp/head/controllernode/images_container_base/sles12/velum:0.0 we could easily do that by setting the _base_image variable to registry.suse.de/devel/casp/head/controllernode/images_container_base/sles12 in the spec file.

Then on a second step, we could use the obs mechanism.

How does it sound?

@bergmannf
Copy link
Contributor

@jordimassaguerpla I think setting the _base_image would be cleaner than the patch - I didn't know that we were already using sed in the spec-file. To get something working I would be fine with that.

AFAIK the dev environment is using the packaged rpm files right now (except for velum which is modified on the fly - but I think that is also adjusted on the fly, so we might have to change the automation around that to correspond to the new image names): but let's wait for @MaximilianMeister or @ereslibre to chime in on that part.

@jordimassaguerpla
Copy link
Member Author

I just created a new PR that uses the sles12 images from the registry as a starting point, until we have more info on the dev env and the tagging strategy.
#201

jgleissner pushed a commit to jgleissner/caasp-container-manifests that referenced this pull request Jan 15, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants