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 MOn 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 SchmidtSoftware Engineer
Center for Biomolecular Science and Engineering
_______________________________________________
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 SchmidtSoftware Engineer
Center for Biomolecular Science and Engineering
_______________________________________________
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
Center for Biomolecular Science and Engineering
_______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/cloud@xxxxxxxxxxxxxxxxxxxxxxx
