Support custom templates

[thund-x]

It will be nice to let the community come up with their own templates for all sorts of use cases. This partially shifts the burden to provide a template for each distro from us to the users. Shared base images could be used, but then you trust a 3rd party to not install malware in the image. This issue complements #66

[Gerharddc]

I don't quite follow the request here. Is the idea just to make it possible for the "template menu" in litterbox define to pull custom templates from some local folder or is it to have an online repository of sorts where anyone can submit templates? To some extent, one can already just use Docker hub (or GitHub registry etc.) to submit template "base images" that can be easily used to make litterboxes.

[thund-x]

The former; to use a Dockerfile/Containerfile from the local file system. For the latter, if there is popular community demand we can do something like that.

I don't really like the workaround because one will be trusting a single 3rd party to not include any malicious software in the final image. At least with shareable Containerfiles the base images which are usually official are (hopefully) better audited.

[Gerharddc]

Indeed, it is not ideal to have to trust images from strangers. Another reasonably simple workaround is to just build and tag an image locally then any litterbox Dockerfile can simply inherit from that image. This eliminates the need to rebuild the same thing over and over.

A possible "nicer" solution could be to make Dockerfiles completely optional and make it possible to just provide an image name as a setting for a Litterbox instead. We could add a feature for building images using Litterbox in which case they also get the litterbox labels. Then when you want to create a new litterbox, we can present you with a list of images we found with the label.

[thund-x]

I prefer the nicer solution.

[Gerharddc]

Perhaps the simplest way to support this in the short term is to just split the build command in two so we now have build and create. The idea would be for build to build images and then create to create a container. Running create will then prompt you for which image to use in addition to the other settings.

[thund-x]

While we are at it, something should be done about the container and image names as well. Using the label is nice and all, but auto generating them IMO worsens UX. Functionally, they are the same as an image or container ID. At least for fish, autocompletion does not list labels, just the container names and the IDs.

[Gerharddc]

The motivation for auto-generating the container and image names is so they look weird when you list things directly in Podman. I.e. the goal was to make them stand out from things created directly through Podman since the idea is for Litterbox resources to always be managed by Litterbox rather than directly through Podman. I also wanted to try avoiding name clashes between things created directly via Podman and things created via Litterbox.

[thund-x]

the goal was to make them stand out from things created directly through Podman since the idea is for Litterbox resources to always be managed by Litterbox rather than directly through Podman.

We can't really prevent that though, so we might as well help the user discover the "odd" images and containers.

I also wanted to try avoiding name clashes between things created directly via Podman and things created via Litterbox.

There shouldn't be any issues if images and containers are prefixed with lbx-. I doubt many people will have images and containers named like that. As of name clashes caused by Litterbox, I don't think it will be an issue if images are named as lbx-NAME. As of containers, perhaps they could be named as lbx-NAME.COUNTER, where COUNTER is the amount of lbx-name containers, starting from 1? They are more user-friendly and they avoid name clashes. In case two or more invocations run at the same time and they end up colliding against each other (very rare), the relevant code could run in a loop {}. In most cases it will iterate only once. I suggest using counters here because podman will kill any running containers if the user attempts to recreate a container while one is running.

[Gerharddc]

There shouldn't be any issues if images and containers are prefixed with lbx-. I doubt many people will have images and containers named like that.

Fair enough, I guess it would indeed be very strange for someone to name things like that. So yeah, then it seems reasonable enough to get rid of the fully random names.

As of containers, perhaps they could be named as lbx-NAME.COUNTER, where COUNTER is the amount of lbx-name containers, starting from 1? They are more user-friendly and they avoid name clashes. In case two or more invocations run at the same time and they end up colliding against each other (very rare), the relevant code could run in a loop {}. In most cases it will iterate only once. I suggest using counters here because podman will kill any running containers if the user attempts to recreate a container while one is running.

To keep things simple, I would rather just decouple names for images and containers completely (as is already the case in "raw" podman). It will then be up to the user to pick a distinct name for each litterbox (which would map to a container instead of an image in this case). This also means that users will need to specify and image name (or pick one from a list) when they want to create a litterbox.

[thund-x]

I would rather just decouple names for images and containers completely (as is already the case in "raw" podman)

Sure. That is essentially #66. It could be added as a sub-issue to this one if you want.

It will then be up to the user to pick a distinct name for each litterbox (which would map to a container instead of an image in this case). This also means that users will need to specify and image name (or pick one from a list) when they want to create a litterbox.

I'm not sure how that is relevant to the quoted part of my reply, but we are on the same page here. About the image name, should the lbx- prefix be added then or do we let users really name it as they please?

[Gerharddc]

About the image name, should the lbx- prefix be added then or do we let users really name it as they please?

I would prepend lbx- to both image and container names before sending them to Podman. Of course, that would not be part of the name inside Litterbox, only the "official" name as used by Podman. I think it is important to do this for both images and containers so they still stand out from their "unamaged" siblings.

[Gerharddc]

The issue with the funky names has now been fixed in bab91da. Decoupling containers from images still needs to be done though.