FWIW, Google deprecates images and kernels in its cloud in a way that's visible to both users and APIs for a while before removing them, even when security vulnerabilities exist (of course we fix those in newer builds and provide release notes). We also have a way for gcutil users to request the newest squeeze or wheezy image, hide older images for each version by default, include the image date in the image name, and sometimes release more than one image revision per Debian release (e.g. to tune performance or integrate newer Google tools).
Mentioning this not to be competitive but to give a data point for folks' consideration in how to handle AMIs.
On 07/09/2013 06:45 PM, James Bromberger wrote:
On 10/07/2013 6:25 AM, Charles Plessy wrote:
this opens the question of our naming scheme: 7.1 is the version of a Debian
release, whereas 7.1a is not. Do you think that it is enough to assume that
Debian will never use such version numbers, or shall we use a version scheme
that makes it more explicit that it is the combination of a release number and
a build number ?
Great question. In the heat of issuing 7.1a, I needed something that was
distinctly different. Squeeze went with three digits, Wheezy seems to be
going with two. I think an Alphabetic character is significantly
different and possibly unlikely to be used... but perhaps we want to
separate in future with a period/dot between major debian release, and
AMI/cloud re-releases? However for an initial release, I think it it
really like the Cloud image version numbers being identical to the
Debian release number - so we only introduce an additional letter/number
when we have to do a re-release.
Jumping in the middle of a thread without context, but if you're talking about naming AMIs on EC2, there is a strong standard to include the YYYYMMDD build date somewhere in the AMI name.
This is important because EC2 does not provide any metadata about when an AMI was created. Without this date in the name, there is no easy way to know which AMI is the latest for a specific series and how current the software is on the snapshot.
On another topic, I understand the desire to remove AMIs for versions of an OS that are old, but I'd encourage you to think about the effects this might have in an EC2 environment.
In a standard hardware environment, a user might download a release and run it on their servers for years, even past when they should. You would encourage people to upgrade, but you would not put a switch into the distro that causes the machine to not boot once it has reached a specific point in time.
On EC2, there are many reasons people take a running instance and replace it with a new one. Other folks might have set up Auto Scaling so that new instances are started automatically as their traffic grows and terminated as their traffic dips.
If you delete an AMI that they are using, suddenly their entire site could stop working because Auto Scaling can no longer start new instances of that AMI, and folks are unable to replace instances that fail.
By deleting a public AMI, you are explicitly breaking any company that has not upgraded their EC2 infrastructure to use your newer AMIs.
This is a pretty strong statement. In the non-EC2 world, it is like reaching into every company's physical data center and changing their existing hardware server installations so that the servers will no longer reboot if they are running an old version of the operating system.
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com
Archive: 51DCC3DC.firstname.lastname@example.org" target="_blank">http://lists.debian.org/51DCC3DC.email@example.com