Re: Deprecating AMIs for: 6.0.6, 7.1 (pre-ECC hostkey fix)
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.