{image,tools}-metadata-url not usable w/ ec2 provider

[dann frazier]

I'm trying to override the simple stream used for ec2 images in juju-core 1.17.4. Basically I have an AMI that includes a network-transparent arm64 simulator, and I need to teach juju to use that AMI when I specify an arch=arm64 constraint.

Initially I tried doing this with via environments.yaml by specifying a image-metadata-url parameter to my simple stream. I see juju pull my metadata from the server, but it isn't able to use the AMI I added:

$ juju bootstrap --constraints arch=arm64
Launching instance
WARNING no matching image meta data for constraints: {region: us-east-1, series: trusty, arches: [arm64], constraints: arch=arm64 cpu-power=100, storage: ebs}
ERROR bootstrap failed: cannot start bootstrap instance: no "trusty" images in us-east-1 with arches [arm64]
ERROR cannot start bootstrap instance: no "trusty" images in us-east-1 with arches [arm64]

But, if I instead hack the juju code and change the default value for UbuntuCloudImagesURL to the same URL in ./src/launchpad.net/juju-core/environs/imagemetadata/simplestreams.go to point to the same URL, it launches ok:

$ juju bootstrap --constraints arch=arm64
Launching instance
 - i-63bd8142
Waiting for address
Attempting to connect to ec2-50-17-155-57.compute-1.amazonaws.com:22
Attempting to connect to ip-10-10-53-152.ec2.internal:22
Attempting to connect to 50.17.155.57:22
Attempting to connect to 10.10.53.152:22
[...]

[John A Meinel (jameinel)]

So looking at the code, if we are getting the URL from UbuntuCloudImagesURL then we do:
  source = fmt.Sprintf("%s/%s", source, cloudImagesPath)
which is, essentially, URL = URL + "/releases"

So it sounds like if you set:
 image-metadata-url = $WHATEVER_YOU_HAD/releases

Then it should work.

[dann frazier (dannf)]

I tried this again with 1.19.2, and confirmed I'm using the recommended string (URL = URL + "/releases"). I'm still seeing the same issue, but I have more information to add. The problem does not appear to be with URL parsing, rather that only "signed" metadata is allowed. If I patch the source to permit unsigned metadata, things work as expected.

On the plus side, this might mean that LP: #1320312 isn't an issue for the ec2 provider - but on the negative side, it does seem like the stream override feature isn't a usable feature, in practice, for the ec2 provider, because you can neither provide unsigned repos nor specify a key to use to verify a 3rd party repo.

One suggestion is to add image-metadata-key/tools-metadata-key options for environments.yaml.

[Bogdan Teleaga (bteleaga)]

This still doesn't work in the latest juju. After trying to deploy a windows AMI with a custom image-metadata-url even with the latest patch https://bugs.launchpad.net/juju-core/+bug/1452422, that fixes generation and maybe other issues I get:

agent-state-info: no "win2012hvr2" images in us-east-1 with arches [amd64]

However doing juju metadata validate-images yields

ImageIds:
- ami-850adbee
Region: us-east-1

Applying the patch specified by dann frazier above does fix the issue.

[Curtis Hovey (sinzui)]

I am escalating this issue. The patch demonstrate that we can easilly enable any juju cloud developer or tester to develop for arm64, windows, and centos.

[Bogdan Teleaga (bteleaga)]

I've got a patch for enabling unsigned metadata for ec2 only(as opposed to everything that's simplestreamed) that I'll propose soon. It'll probably bring about another bug report on enabling user-signed metadata after that.

[Eric Snow (ericsnowcurrently)]

See http://reviews.vapour.ws/r/2252/.

[Eric Snow (ericsnowcurrently)]

However, I see that only as a temporary hack. I would expect the proper fix to be 2-fold:

* determine signedImageDataOnly based on config criteria (default to true unless custom image-metadata-url is provided
* add a config option to explicitly override the calculated signedImageDataOnly value

[Eric Snow (ericsnowcurrently)]

...or add a config option for the key to use for custom-signed metadata (see lp:1477464).

[William Reade (fwereade)]

Yeah, +100 to ericsnow's comments. It's good to allow unsigned metadata; but we need to be sure that we don't open a path by which we can ignore the signature on the official metadata.

[Anastasia (anastasia-macmood)]

Curtis - I believe that this is fixed as part of another bug. This restriction is no longer in code for images supplied though image-metadata-url. Feel free to confirm and close \o/