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(a)ucsc.edu> 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(a)redhat.com> 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(a)redhat.com |
http://community.redhat.com/
> Twitter: @jzb |
http://dissociatedpress.net/
>
>
> _______________________________________________
> cloud mailing list
> cloud(a)lists.fedoraproject.org
>
http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
>
>
--
Hannes Schmidt
Software Engineer
Center for Biomolecular Science and Engineering
University of California, Santa Cruz
(206) 696-2316 (cell)
hannes(a)ucsc.edu
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org