[jira] [Commented] (WHIRR-341) Hard code the images used for integration testing

["Adrian Cole (JIRA)" <ji...@apache.org>]

    [ 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 complicated. 
> 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