-
Notifications
You must be signed in to change notification settings - Fork 526
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
docs: Add quickstart guide for local QEMU/KVM VMs #2280
docs: Add quickstart guide for local QEMU/KVM VMs #2280
Conversation
Commit e2b58d6 ("tools: Add start-local-vm script") added a wrapper script to simplify running a locally built Bottlerocket image in a local VM using QEMU and KVM. Provide a quickstart guide analogous to the existing ones for EKS, ECS, and VMware to help make use of it. The guide currently assumes anyone following along to be running Fedora. Changes to the guide for other distros will be minimal, if they are needed at all. However, changes in start-local-vm are likely to be required. Leave this to a dedicated later change. Signed-off-by: Markus Boehme <[email protected]>
[settings.host-containers.admin] | ||
enabled = true | ||
user-data = "${ADMIN_USER_DATA}" | ||
source = "public.ecr.aws/bottlerocket/bottlerocket-admin:v0.9.0" |
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.
This is a bit awkward because it needs to be kept up to date. However, it seems the defaults defined in sources/models/shared-defaults/public-host-containers.toml
are replaced entirely with the user-data.toml
placed directly on the file system, i.e. if the source
is left off here, thar-be-settings will notice and error out on boot.
- Any ideas for forcing a merge?
- The public admin and control containers don't have a
latest
tag which would be helpful here. Are there downsides to introducing one and referring to it instead?
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.
Of course we would like to keep this reasonably up to date, but for the purposes of this guide using that container version is not going to break at any point in the future.
The wider ramifications of creating a latest
tag are probably not worth it for the purpose of setting up the host containers in a quickstart.
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.
The wider ramifications of creating a
latest
tag are probably not worth it for the purpose of setting up the host containers in a quickstart.
Fully agree with that on effort alone, and I couldn't think of any other use: It makes sense for a Bottlerocket release to define those explicitly to avoid surprise updates and have everything be tested in combination. As a container newbie I couldn't help but wondering out loud whether there are any downsides, though. :-)
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.
For what it's worth, this should probably be merged into the documentation/website repo (once that is available). There we can interpolate the latest version, so if we update the repo, it updates the docs.
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.
Nice work!
[settings.host-containers.admin] | ||
enabled = true | ||
user-data = "${ADMIN_USER_DATA}" | ||
source = "public.ecr.aws/bottlerocket/bottlerocket-admin:v0.9.0" |
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.
Of course we would like to keep this reasonably up to date, but for the purposes of this guide using that container version is not going to break at any point in the future.
The wider ramifications of creating a latest
tag are probably not worth it for the purpose of setting up the host containers in a quickstart.
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.
🍸
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.
LGTM
Issue number: #834
Description of changes: Commit e2b58d6 ("tools: Add start-local-vm script") added a wrapper script to simplify running a locally built Bottlerocket image in a local VM using QEMU and KVM. Provide a quickstart guide analogous to the existing ones for EKS, ECS, and VMware to help make use of it.
The guide currently assumes anyone following along to be running Fedora. Changes to the guide for other distros will be minimal, if they are needed at all. However, changes in start-local-vm are likely to be required. Leave this to a dedicated later change.
Testing done: Put steps together while building a Bottlerocket image on a new c6g.metal instance and launching a local VM with it afterwards.
Terms of contribution:
By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.