Skip to content
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

Universal (qemu) provider for building images on all clouds at once #45

Draft
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

thecubed
Copy link
Member

@thecubed thecubed commented Mar 25, 2022

This PR adds the ability to create images locally using QEMU, which will be imported by various cloud providers at the completion of the build.

It maintains the ability for the same base -> specialization image hierarchy that ami-bakery currently has.

Building images with QEMU requires a cloud-init preseed ISO image to be created before provisioning, and that is taken care of by the default packer env script logic and packer itself.

There are some changes introduced:

  • Packer uses the new HCL2 configuration format; and
  • Variables are now passed into packer by the PKR_VAR_ env var prefix, which eliminates most of the cruft of build.sh
  • Since this now boots a machine, it needs to be 'generalized' after the build finishes. cloud-init clean handles this mostly, but we'll probably find more places that need to be cleaned of logs to ensure the machine presents as completely clean.

Thoughts:

  • This builder sits between the docker provider and the AWS provider such that rapid iteration can be achieved with Docker, but not if you need to test kernel-level or systemd changes.
  • The only reason to actually boot the target is because we can't always guarantee that the target's OS family is similar to the host (i.e. OSX building RHEL). We may want to consider using something chroot-based for faster and cleaner builds, and using this provider for builds that aren't as time critical.
  • Uploading images to AWS/Azure is pretty slow. AWS doesn't let you name your AMIs via ImportVM either, instead they get autonamed ami-import-<id>, which is frustrating.

TODO before merging:

  • rebase off fedora changes from @missingcharacter (you're awesome!!)
  • build.sh refactor to use PKR_VAR_ for all builders
  • figure out how to dynamically enable/disable different post-provisioners (i.e. disable upload to AWS/Azure if just testing locally)
  • investigate how to use the ec2 import to copy the ami to other regions/accounts to preserve existing functionality

@missingcharacter
Copy link
Member

This looks great thus far, do you want me to change anything on #44 before I merge it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants