whirr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrian Cole (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (WHIRR-341) Hard code the images used for integration testing
Date Mon, 18 Jul 2011 13:05:58 GMT

    [ https://issues.apache.org/jira/browse/WHIRR-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13067008#comment-13067008

Adrian Cole commented on WHIRR-341:

I don't agree with this change, but I do think we should document the template parameters
that passed tests (and led to a release of whirr).

We should be optimizing for predictability across images, not honing for only a single version
with a set of patches frozen in time.  Users will certainly want to use whirr on more platforms
as time progresses.  I agree that locking in image ids will make things easy for us in the
short term, but not the long term as users will encounter problems we didn't catch.  Besides,
devs can already set whirr test properties, so if one of us wants to only use a favorite image,
we can already do that.

Whirr needs to work as new images release.  Amazon, canonical etc. regularly release new versions
of AMIs for a specific os/version id.  There are good reasons for them to update these, for
example security patches.  That said, sometimes image producers change an image without an
id update (bad practice imho), so imageId isn't always going to get the stability you desire.
 Finally, the maintenance of image id per provider/region/os mix is a pretty big job and requires
constant attention.  This isn't a legacy I'd recommend us entering.

If image updates become troublesome, I'd instead recommend fortification.  For example, automated
forensics gathering, or hardening configuration scripts to reveal dependencies needed or incompatible
with a specific service role.  

Regardless of what we do to be more bullet-proof wrt image updates, I do believe we should
document the configuration tested during a release.  This should include all facets of the
configuration including the hardware and location id; basically the ids in the template, not
just image ids.

> Hard code the images used for integration testing
> -------------------------------------------------
>                 Key: WHIRR-341
>                 URL: https://issues.apache.org/jira/browse/WHIRR-341
>             Project: Whirr
>          Issue Type: Sub-task
>          Components: core
>            Reporter: Andrei Savu
>            Assignee: Andrei Savu
>             Fix For: 0.6.0
>         Attachments: WHIRR-341.patch
> I suggest we should hard code the images that we are using for integration testing (the
default images selected by Whirr) so that we can make the process more predictable. Right
now you don't really know what image jclouds is going to select for you and that makes things
> By doing this we should also be able to publish a list of officially supported images
for Apache Whirr, a list of images that we should be testing against before making a new release.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message