andrew. Thanks very much for the comments. inline below:
Well, one desire of mine is to be able to know if we are testing
something different than before. For example, when the cloud provider
or image provider updates a template, it would be nice to be able to
log a warning or something saying this is fresh. I'm keen on other
places to retrieve this from, just seemed nice to be able to run
without a dependency. Where do you think we could store test
results?.. hehe maybe a CloudBees app? :)
> I don't feel it should be part of the *source* because, as you point out,
> "templateBuilder expressions shouldn't return a different id on
> every run, and if they do, this is likely a problem that can be
> revised with a more specific expression"
> Basically, if your requirements for tests are such that you need an image
> that is more specific than those matched by your template expression, then
> there's a bug in the code.
> If the requirements can't (yet) be expressed by a template, we'd have a
> feature request.
I think this will unveil new features for templateBuilder, or perhaps
give us enough momentum to get beyond past stalemates on the topic ;)
 I'm particularly interested in capturing the intent of the image,
which is generally a combination of it being free, small, owned by a
stable entity (generally the provider), and baseOs. When we get more
specific queries, I think the fear of image thrashing will be quelled.
Before we start, we should really be able to measure this, hence the
thought about storing the test results.
> But if the template really does capture all the requirements you have for
> your image...why shouldn't it work even if a different (matching) image were
> returned every time.
This is a concern I agree with, but I don't think our query is strong
enough yet (to your point above). Especially when the image cannot be
guaranteed to be the base os, or even from a specific publisher, I can
imagine trouble can arise, and it does. So in a way, I think our
template expression isn't quite specific enough to give downstream
tools a high enough level chance.
That said, I rarely have to muddle with the default image for our
tests to pass, and I can't remember the last time I needed to do so on
aws-ec2. Maybe this success should be a warning sign. Perhaps we
need something more quirky than installing openjdk, an os user, sudo,
setting up ip tables, modifying ssh, and running jboss.
Maybe more important is that we only test one version of one operating
system. Just because our template that matches amazon linux works per
above, it means nothing if you choose ubuntu or centos. I think we
will end up needing relevant expressions for each OS. For example, I
want CentOs published by Rightscale, but if I choose Ubuntu, I want
Canonical's, but not their daily build. Again.. this is more to your
point above. When we do have more precise expressions, I think tools
will have a good chance on working.
> That said, I'm all for predictable behaviour, so if there *are* some
> sensible rules we can apply to deterministically pick one of the matching
> images that would certainly be worth looking at.
+1 I've labored this point above :D
> However, that would probably imply testing *all* available images (rather
> than picking the first that matches), which could be quite a performance
Well, I think what we can do is basically query users for the images
they trust, and get better at capturing those requirements. For
example instead of ami-2131234, which is only relevant to a zone and a
pretty opaque ask, query the user about what essentially are they
looking for? In this case, perhaps it is a Debian from a specific
owner. When we have better queries, we can match on any region.
Picking favorites has been recent past for us, but I think it is
worthwhile testing on at least 2 operating systems per cloud, since
not everyone use ubuntu. Perhaps starting with CentOs (or RHEL'ish) +
Ubuntu, refining templates for these, and testing the entire compute
suite based on a profile (-Dtest.compute.osfamily=CENTOS) It does
double the test execution time, but I think it may be worth it.
> Perhaps this could be an additional arg to templateBuilder?
> .pickFirstMatching() or .lexicallySortAndPickFirst() etc....?
+1 I like the idea of exposing these things.
> You received this message because you are subscribed to the Google Groups
> "jclouds-dev" group.
> To post to this group, send email to email@example.com.
> To unsubscribe from this group, send email to
> For more options, visit this group at