Re: Deletion of AMIs in the EC2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'm not asking for the images to be continually supported. Just not deleted. Maybe they can be placed into a separate "archive" AWS account?

On Wed, Feb 3, 2016 at 12:29 PM, Matt Micene <nzwulfin@xxxxxxxxx> wrote:
The transparency argument does make sense, but yes then the "stock Fedora AMI" is dependent on the projects update and lifecycle policy.

On Wed, Feb 3, 2016 at 2:52 PM, Hannes Schmidt <hannes@xxxxxxxx> wrote:
We do take images of fully set-up VMs that are used in experiments. But there is also the use case of being able to start from a well-known, published AMI and running through the scripted setup again, maybe with small tweaks. This increases the transparency of an experiment. Saying to a fellow researcher "take my custom AMI and run the experiment" is less convincing than saying "start with the stock Fedora AMI, run this script to deploy this software on it, then run the experiment". 


On Wed, Feb 3, 2016 at 11:34 AM, Matt Micene <nzwulfin@xxxxxxxxx> wrote:
 big data genomics community where an experiment that can't be verified by a 2nd party is a bad experiment. Like everywhere in science. VMs are a great way to provide that reproducibility.

Have you looked at AMI snapshots for reproducing experiment environments?  

Once the baseline environment (OS, additional packages, etc) is built, you could create a snapshot of that instance to use both as additional scaling components as well as an archive of the experiment.  You could relaunch the exact environment without the need to build from scratch.

It also breaks the dependency on any particular version of OS, package, or configuration from going EOL or missing.  It may help with 2nd party configuration errors against the original environment.

 - Matt M


On Wed, Feb 3, 2016 at 2:00 PM, Hannes Schmidt <hannes@xxxxxxxx> wrote:
Whether something makes sense is subjective. 

But as to your 2nd point. One word: Reproducibility. I am in the big data genomics community where an experiment that can't be verified by a 2nd party is a bad experiment. Like everywhere in science. VMs are a great way to provide that reproducibility. I understand the security argument to some degree but we're not all noobs. We can make our own conscious choice as to under what conditions it is safe to run an EOLed VM without security updates. For example, within a VPC or a under tightly controlled security group (firewall policy).

On Wed, Feb 3, 2016 at 1:37 AM, Joe Brockmeier <jzb@xxxxxxxxxx> wrote:
On 02/03/2016 09:24 AM, Hannes Schmidt wrote:
>
> So EOL implies that no one should ever be able to launch a VM for it?
> Makes no sense to me.

It's no longer receiving updates, so that does actually make sense.

Can you describe the use case for an EOL release that might persuade us
that we should continue paying for the storage required to host EOL AMIs
and risking that users might deploy them without realizing they are no
longer receiving security updates?

Best,

jzb
--
Joe Brockmeier | Community Team, OSAS
jzb@xxxxxxxxxx | http://community.redhat.com/
Twitter: @jzb  | http://dissociatedpress.net/


_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/cloud@xxxxxxxxxxxxxxxxxxxxxxx




--
Hannes Schmidt
Software Engineer
Center for Biomolecular Science and Engineering
University of California, Santa Cruz

(206) 696-2316 (cell)
hannes@xxxxxxxx

_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/cloud@xxxxxxxxxxxxxxxxxxxxxxx



_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/cloud@xxxxxxxxxxxxxxxxxxxxxxx




--
Hannes Schmidt
Software Engineer
Center for Biomolecular Science and Engineering
University of California, Santa Cruz

(206) 696-2316 (cell)
hannes@xxxxxxxx

_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/cloud@xxxxxxxxxxxxxxxxxxxxxxx



_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/cloud@xxxxxxxxxxxxxxxxxxxxxxx




--
Hannes Schmidt
Software Engineer
Center for Biomolecular Science and Engineering
University of California, Santa Cruz

(206) 696-2316 (cell)
hannes@xxxxxxxx
_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/cloud@xxxxxxxxxxxxxxxxxxxxxxx

[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Big List of Linux Books]     [Yosemite News]     [Linux Apps]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

  Powered by Linux