Explicit image selection

William Reade william.reade at canonical.com
Mon Apr 22 10:41:36 UTC 2013


On Mon, 2013-04-22 at 13:51 +0400, John Arbash Meinel wrote:
> It is meant to be a way for users to "know better" than the defaults.
> Is there a reason that today Juju only deploy's stock Ubuntu images? I
> realize deploying your Ubuntu + customizations image could break
> charms, but it could also fix things for users that want the ability.
> (The alternative is those users just cannot use Juju for what they
> want to do.)

Yes: the most fundamental reason is that charms target individual
series, and we don't want to deploy charms to the wrong one.

> So the Openstack clouddata lookup looks in your object storage for the
> file. It certainly would be possible to add that to EC2. (So you
> upload a file describing the instance you want, matching the series, etc.)

We need to be careful to differentiate between instance types and
images. The instance-type data varies across ec2 regions, but not across
different ec2s (because there is only one ec2 ;p). So I don't think it's
reasonable to specify *instances*: but it is (I think) reasonable to
allow people to use their own custom images.

> The main problem is that those files are pretty esoteric. It isn't a
> trivial "series: image-id" that you would like to have (it has stuff
> about whether it is compiled for Cluster and paravirtual, and ebs, etc.)

All these things are *important*. If you're building your own images you
kinda need to know about all these things, otherwise you end up with a
whole bunch of cases in which juju just fails, because you asked
(directly or indirectly) for an instance-type that doesn't fit the
image.

> It is reasonable to say "Juju will not support this use case", making
> it really hard to support it is roughly the same. I can also agree
> with "don't make it too easy because the shotgun is loaded". But
> finding a nice balance between "the defaults are sane, but you can
> override them when you know what you are doing" seems useful.

My perception is that it's not *that* difficult to describe your images
in enough detail to satisfy juju's requirements; and moreover that once
we switch over to oxygen/simplestreams across the board it'll be even
simpler to do so. Is it really any harder than creating those images in
the first place? Because *that* seemed like a hassle whenever I did it
(distant past, can't really remember anything except the tedium).

> Is your concern that if you just set "image-id" then deploy a charm
> from a different series? I think there is a small hole in Juju that
> the constraints for the bootstrap node end up as the default
> constraints for the whole environment. With no good way of splitting
> them apart.

It's a bit dirty, I agree, but we have env-set now, and so the cases in
which default-series and constraints need to differ between the
bootstrap node and future instances can be, I think, trivially
addressed. Because we've always known that env-set was coming, it never
seemed important enough to add complexity to bootstrap configuration to
address those cases. Am I missing something?

Cheers
William




More information about the Juju-dev mailing list