[
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
