|
On 9/07/2013 8:03 PM, Brian Gupta
wrote:
On Fri, Jul 5, 2013 at 12:43 AM, James Bromberger <james@rcpt.to> 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 |