Explicit image selection

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2013-04-22 12:08, William Reade wrote:
> On Mon, 2013-04-22 at 16:55 +1000, Ian Booth wrote:
>> Allowing the users to explicitly select the image id they want
>> to run can of course lead to problems. But some users require
>> that functionality.
>> 
>> Proposal:
>> 
>> Introduce a new config attribute called "user-image-id". If set, 
>> this short circuits the image id lookup from metadata.

I'd rather see this show up as a constraint, than a config. So:

 juju deploy --constraints "image-id: XXYY"


>> 
>> The existing default-image-id attribute as implemented for 
>> Openstack only would remain unchanged, and is still used as a 
>> fallback when all else fails (if specified). The difference is 
>> that this new attribute overrides the image id lookup and would 
>> be documented with suitable warnings etc.
>> 
>> Sound reasonable?
> 
> "default-image-id" enables a real use case, but it enables it in a
>  profoundly broken way. I'm implacably -1 on the idea that it is 
> sensible to allow an explicit end-run around our series/arch 
> selection: it will break instance type selection on ec2, it will 
> break arbitrary charms in arbitrary ways, and it will probably
> have further consequences that I'm not farsighted enough to see.

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.)

> 
> Counter-proposal: allow users to specify the clouddata URL for ec2 
> as well as (as is planned) in openstack. There's still the 
> possibility of poisoned data, but we can't defend against that; we 
> can however avoid threading brokenness right through our model.
> 
> Cheers William

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.)

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.)

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.

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.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlF1CAgACgkQJdeBCYSNAANfUwCfSvlxMQJqggWR7iXaeMf5nCXM
UwIAoKB61eypWMhe+frwfQZUBQfsZj2C
=c/31
-----END PGP SIGNATURE-----