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