Scott Stark wrote:
I had created and uploaded a fedora 13 based ec2 image in the past, and today created a new image and tried to upload it. First I saw that the uploaded ami had the same id as a previous one. I deleted the ami and ran boxgrinder-build again. This time a new ami was crteated, but after looking at the instance contents it was the same as the previous uploaded version. I then went into S3 and deleted the associated /boxgrinder-images/images/hostmanager/fedora/13/1.0/i386/ contents, and uploaded the image again. This time it was as expected.
If you rebuild the AMI, you create a new version, therefore you need to bump the version of the AMI in .appl file using version and release tags. It'll use then a different path and register as a fresh AMI and the old one will remain.
If you still needs to have 1.0 version and replace old one – you need to:
- Unregister the AMI in AWS
- Remove all the files from bucket
- Re-upload AMI
Is this just a current tooling limitation or a limitation at amazon that one cannot have multiple AMIs for a given platform?
It's because of using the same path on S3 which is obviously not allowed for different AMI's.
I ended up stopping and then restarting the upload of the 45 parts of the AMI. The uploaded started over from the beginning. It is taking a good 15 mins to upload over a fast connection. I would like to add a resume upload feature of the s3 plugin.
There is no way to add a resume feature because an external command is used to upload the image (ec2-bundle-upload). IIRC correctly if something fails with this command – all data uploaded data is removed from S3. It's all or nothing command type.
If you want greatly speed up the building process I suggest meta-appliance and building the AMI directly on EC2. Uploading to S3 from EC2 instance for ~45 pieces should take a minute or so.