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(a)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 <hannes(a)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 <nzwulfin(a)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 <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
>>>
>>>
>>
>> _______________________________________________
>> 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
>
>
_______________________________________________
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