In the previous post, I discussed what is fedimg and how it works currently. In this post, I plan to explain the issue in the current uploading process of the AMIs and how we plan to fix it.
What’s the problem?
fedimg boots an utility instance using the RHEL AMI configured for that region.
The problem with this design is that while adding a new region we need to look for the appropriate RHEL AMI in the newer region first. Afterward, we need to test if fedimg works with the newer regions RHEL AMIs. Finally, if everything turns out to be okay we can go ahead with adding the AMI to the fedimg configuration.
This becomes a tedious task over time and delays adding a new region.
How does redesign fixes this?
The new design completely removes the dependency of the utility instances.
fedimg would then utilize
euca-import-volume to upload the raw cloud image to
create a volume via S3.
fedimg will keep retrying to check if the volume is read using
euca-describe-conversion-tasks. Once the volume is created, fedimg goes ahead
with creating the snapshot of the volume and then finally the AMI.
Adding a new region now becomes effortless as we just need to append the region to the configuration file.
Fedimg also right now boots up test instances to test the AMIs and does a basic
/bin/true test. This test just ensures that the machine boots and nothing
more than that.