On 9/07/2013 8:03 PM, Brian Gupta wrote: > On Fri, Jul 5, 2013 at 12:43 AM, James Bromberger <[email protected]> wrote: >> This leaves me with a question over the 7.0 release (which will have the >> same ECC vulnerability). Should we deprecate (and remove) this? Feedback >> required! ;) > As much as I would greatly prefer that we don't deprecate AMIs this > quickly, I suspect that this vulnerability is reason to make an > exception.
Indeed that's what I was thinking. I am a fan of keeping recent AMIs around for a reasonable period after they are replaced, but I think this calls for a shorter cycle for the original 7.1 release. > If it's not to much work to publish new 7.0 images that largely > contain the same package versions, I think we should consider it. That > said, I don't feel that strongly about it, as things are gonna break > no matter what for those who have automation build around the old > AMIs. This just leaves folks who have qualified on the 7.0 images and > package versions, and I am not sure how many people have done so. (I > am guessing this is a very small contingent, if any.) I didn't pull 7.0 into this because I am not immediately sure how to pull in older ppint releases for the build scripts, and I think there is diminishing value in doing so. I think the "first" release of a major release (7.0) is potentially interesting in a historical perspective, and the "last" release (ie, 6.0.7) is even more interesting from the perspective of someone who suddenly realises they need to run something on an old version of Debian... (!) > If we wanted to just deprecate them without a replacement, I think > that wouldn't be the end of the world either. (Unfortunately there > isn't a way to keep the old AMI IDs and replace them with updated 7.0 > images. If there was, that would be what I would suggest.) Indeed, not currently. You'll see I am constantly keeping the CloudFormation template example on the wiki as up-to-date as possible to ease the mappings of AMIs. James -- /Mobile:/ +61 422 166 708, /Email:/ james_AT_rcpt.to
