Container image repositories and utilities

11 views
Skip to first unread message

Lennart Jern

unread,
Oct 5, 2023, 6:35:35 AM10/5/23
to Metal3 Dev
Hi!

In last week's community meeting, there was brief discussion about the ironic-image repository and the utility images that we build around Ironic. Adam suggested to add an iPXE builder image to avoid creating more repositories, but there were some objections around wanting one image per project to avoid issues with image building tooling.

I wanted to expand a bit on this discussion and maybe find a better way forward than just creating more repositories. There was already some sort of consensus in a PR discussion around this, that we cannot really have a separate repository for every utility image we want.

First of all, let me clarify that I agree that a project should not have a lot of random "extra" Containerfiles and scripts included in the main repository. However, we seem to have a need for many images for external tools or custom utilities. I think the tooling for these should ideally be consolidated into one repository since they are not really projects of their own.

To be specific, I'm talking about MariaDB, Dnsmasq, keepalived, etc. My understanding is that we build these custom images mainly to integrate better with Ironic, i.e. we include custom scripts and configuration to make it easier to run them in Metal3 context.  We don't really touch the code of these upstream projects, they are just utilities for us. This is why I think we can keep them all in one repository. I'm not saying we need to move the existing code from ironic-image though, just that I think we can have a repository for these things. That is where we can now put the iPXE builder container.
Does this make sense?


Now I am perhaps going a bit off topic. This is more about the long-term road map and spawning ideas, so take it with a grain of salt.

Ideally (in my opinion), we should try to keep the configuration and custom scripts outside of the container images and use upstream/official images as far as possible. This means we do not need to build and publish images. We will still need to configure the containers of course, but that can be done through environment variables and mounted scripts instead of baking them into the image. 

Another benefit is that it becomes much easier for an external expert to understand the setup. Currently you basically have to be an expert on ironic-image to understand our dnsmasq or keepalived container. It is not at all obvious how it works for someone that knows dnsmasq but not ironic-image.

To recap, I'm mainly interested in if it sounds alright to you all if we work on a new repo utility-images that would be for these kind of things. Do you think it is OK to have a repository like this, or do we need to have e.g. a separate ipxq-builder repo?

Best ragards,
Lennart Jern

Riccardo Pittau

unread,
Oct 5, 2023, 9:01:18 AM10/5/23
to Lennart Jern, Metal3 Dev
Hi Lennart,

Thanks for this.
Let's separate the topics.

For the short term I think it does make sense to have a "tools" repository as long as we establish some basic ground rules.
We need to evaluate carefully what to keep in it, first of all to avoid just dumping any script/tool there, but also in case an image is more than a simple tool and it actually deserves its own repository.
For example, in the case of the iPXE builder container I think we're at the limit, but we can live with that.
Also, it sounds silly but we should have a very well documented list of the tools contained in the repository, meaning that every time we add something, we need to update the documentation as a mandatory step.
Finally, we also at some point need to re-evaluate the containers inside the repository in case their usage and footprint become more important, and be able to move them to its own repository when needed.

For the long term topic, this is a huge subject and we should probably dedicate time during our weekly meeting, or meetings even, not just a thread in the mailing list.
I just want to say that I agree with what you wrote and ideally it would be great to have something like that, we just need to plan it well and give it its own time to get to it.

Thanks
Riccardo


--
You received this message because you are subscribed to the Google Groups "Metal3 Development List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to metal3-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/metal3-dev/HE1P189MB04754EC8B73D53A588EDECC7FFCAA%40HE1P189MB0475.EURP189.PROD.OUTLOOK.COM.

Lennart Jern

unread,
Oct 10, 2023, 8:22:50 AM10/10/23
to Riccardo Pittau, Metal3 Dev
Thanks for the input!

I think we are pretty much on the same page. Let's forget about the long term topic for now. We can discuss that separately.

For the repo that Adam already started on (utility-images), I think the readme is already giving quite a good example for how to document the content. We can add to the PR template a checkbox for "updated docs" also to remind everyone of the need to keep it updated.

Do we need something more? Perhaps some kind of "policy" for what to keep in this repository, or rather, what *not* to put in it?

Best,
Lennart



From: Riccardo Pittau <elfo...@gmail.com>
Sent: Thursday, October 5, 2023 16:01
To: Lennart Jern <lennar...@est.tech>
Cc: Metal3 Dev <metal...@googlegroups.com>
Subject: Re: [metal3-dev] Container image repositories and utilities
 
Reply all
Reply to author
Forward
0 new messages