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 <nzwul...@gmail.com> 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 <han...@ucsc.edu> 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 <nzwul...@gmail.com> 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 <han...@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 <j...@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 >>>>> j...@redhat.com | http://community.redhat.com/ >>>>> Twitter: @jzb | http://dissociatedpress.net/ >>>>> >>>>> >>>>> _______________________________________________ >>>>> cloud mailing list >>>>> cloud@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) >>>> han...@ucsc.edu >>>> >>>> _______________________________________________ >>>> cloud mailing list >>>> cloud@lists.fedoraproject.org >>>> http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org >>>> >>>> >>> >>> _______________________________________________ >>> cloud mailing list >>> cloud@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) >> han...@ucsc.edu >> >> _______________________________________________ >> cloud mailing list >> cloud@lists.fedoraproject.org >> http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org >> >> > > _______________________________________________ > cloud mailing list > cloud@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) han...@ucsc.edu
_______________________________________________ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
