-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
README: De-emphasize specifying user configuration #135
Conversation
Per the changes here, it is very much expected that users create their own derived containers as the starting point to the system, *not* just running the base image. And once one does that, per the docs there are multiple solutions for injecting and managing authentication credentials, lifecycled with the *container* image as is often desired. There's obviously use cases for injecting user configuration, this change just de-emphasizes it and links to the existing centos-bootc docs.
@@ -43,7 +51,7 @@ sudo podman run \ | |||
quay.io/centos-bootc/bootc-image-builder:latest \ | |||
--type qcow2 \ | |||
--config /config.json \ | |||
quay.io/centos-bootc/fedora-bootc:eln | |||
<your custom image> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would really like to keep a ready made copy/paste example. I think we will lose a lot of our audience if there is not a 1-5 lines copy/paste recipe for people to just try it out. Note that this might be fine depending on the audience we are targeting. But my preference would be to have some
$ cat >Containerfile <<EOF
FROM quay.io/centos-bootc/fedora-bootc:eln
<do-something-like-create-a-user-here>
EOF
$ podman build -f Containerfile -t hello-bootc
$ sudo podman run ... quay.io/centos-bootc/bootc-image-builder:latest ...
With that the user will have an image, can login, look around etc.
Happy to discuss this of course!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I understand your point. However let me back up and say that I think the entrypoint to the documentation should be shared - and currently that lives in more in https://github.com/CentOS/centos-bootc
(At some point hopefully soon we'll create a dedicated docs repo, but that's a distinct thread)
Now, we keep getting hung up on the user bits. It's a super hard problem. I just did CentOS/centos-bootc#205 which also documents using systemd credentials, IMO is often better than baking ssh keys into an image for "one off testing". This is just a super complex topic because again one might have a setup where the production image uses FreeIPA, but when you're just iterating locally you don't want that.
I understand from the perspective of bib it'd be good to have a one-liner to copy-paste to be able to execute it.
But I think bib is unlikely to be the primary "system entrypoint" in reality. There are multiple, basically in some order:
cloud
Try out https://github.com/CentOS/centos-bootc-layered/tree/main/cloud (which note also has pre-generated disk images that are made using bib right now). This will be straightforward and understandable to many experienced Linux sysadmins, immediately getting them a shell in their preferred virt framework, without building any containers or disk images.
podman CLI verb
Given we want podman (and podman desktop) to be a key entrypoint I think containers/podman#21243 will make the most sense, because we have the opportunity to streamline that all down to a basic:
podman machine bootc run quay.io/centos-bootc/centos-bootc:stream9
or whatever (that would also work with custom images); my WIP code today uses bootc install to-disk
behind the scenes to materialize a disk image and systemd credentials to inject a root SSH key.
And notably doing it in podman gets us cross-architecture virt, which is an important thing (this repo does a decent job at documenting it, but we just need to streamline it to that I think).
This PR is stale because it has been open 30 days with no activity. Remove "Stale" label or comment or this will be closed in 7 days. |
This PR was closed because it has been stalled for 30+7 days with no activity. |
Per the changes here, it is very much expected that users create their own derived containers as the starting point to the system, not just running the base image.
And once one does that, per the docs there are multiple solutions for injecting and managing authentication credentials, lifecycled with the container image as is often desired.
There's obviously use cases for injecting user configuration, this change just de-emphasizes it and links to the existing centos-bootc docs.