juju not using image-metadata-url for container images

[John A Meinel]

It is possible to configure image-metadata-url for a model, it is respected for LXD provider, but not for LXD containers deployed in other providers.

The line in question is:
 https://github.com/juju/juju/blob/9646929ab399350b6e676c1d5c088160e8ed7c6d/container/lxd/lxd.go#L130

Where the DefaultImageSources is going to be just cloud-images.ubuntu.com.

Allowing this to be pulled from the Model config would let us use either daily images, or use images from a mirror.

[Anastasia (anastasia-macmood)]

Removing 2.1 milestone as we will not be addressing this issue in 2.1.

[Ante Karamatić (ivoks)]

I suspect this is called image-metadata-url these days?

[John A Meinel (jameinel)]

Since we have ContainerManager which can take a ManagerConfig, we could start to pass through image-metadata-url.

The content in apiserver/agent/provisioner/provisioner.go ContainerManagerConfig knows that we're asking for the LXD configuration.
It has access to p.m.Config() which should be the 'model-config' for the model we're running in, so should be able to lookup p.m.Config().
That would let us check:
  config.ImageMetadataURL()
and
  config.ImageStream()

and pass them into the cfg which is a map[string]string

and then we should already be passing that into container/lxd/lxd.go NewContainerManager
where we can pop out those attributes if they are set, which would let us set them on containerManager.

And then in containerManager.CreateContainer() we should be able to include them in the list of of 'EnsureImageExists'.

We probably need to turn them from a URL into a Remote object. We'd probably just assume they are a Simplestreams remote.

We might also need to promote "http://" sources to "https://" since it is required by LXD.

It is also arguable that we very much shouldn't be punning the image-metadata-url for the cloud with the values for the containers.
Given something like Openstack, do we actually think the metadata for Cloud images would be in the same place as LXD images?

It feels like what we really want would be something like "lxd-image-metadata-url" which users can set to the same value as image-metadata-url if it is actually the same. But the question of "where is the metadata about images for VMs for my cloud" feels very much like it could be a different question than "where is the metadata for images for LXD containers for my cloud".

I also wonder what we should be doing for KVM images, as those seem to also hard-code cloud-images.ubuntu.com: (kvm.go):
 if instanceConfig.ImageStream != imagemetadata.ReleasedStream {
  startParams.ImageDownloadURL = imagemetadata.UbuntuCloudImagesURL + "/" + instanceConfig.ImageStream
 }

(if no URL is supplied it falls back to "DefaultSource")

[John George (jog)]

This bug was subscribed to Canonical Field High and is now being tracked per the Field SLA process.

[Tim Penhey (thumper)]

Hey Nicholas, I was thinking that we get this to Joe and Heather along with the other LXD bits.

[Tim Penhey (thumper)]

In 1.25.13 we had this (in config) which worked:

 // CloudImageBaseURL allows a user to override the default url that the
 // 'ubuntu-cloudimg-query' executable uses to find container images. This
 // is primarily for enabling Juju to work cleanly in a closed network.
 CloudImageBaseURL = "cloudimg-base-url"

[John A Meinel (jameinel)]

I think we sorted out that what we want is

container-image-metadata-url

and then we can tie that into both LXD and KVM sources.

As mentioned earlier, it should be reasonable to chain through the
information given our current codebase.

On Thu, Apr 5, 2018 at 12:56 AM, Tim Penhey <email address hidden>
wrote:

> In 1.25.13 we had this (in config) which worked:
>
> // CloudImageBaseURL allows a user to override the default url
> that the
> // 'ubuntu-cloudimg-query' executable uses to find container
> images. This
> // is primarily for enabling Juju to work cleanly in a closed
> network.
> CloudImageBaseURL = "cloudimg-base-url"
>
> --
> You received this bug notification because you are a member of Canonical
> Field High, which is subscribed to the bug report.
> https://bugs.launchpad.net/bugs/1606617
>
> Title:
> juju not using image-metadata-url for container images
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1606617/+subscriptions
>

[Joseph Phillips (manadart)]

Pull request athttps://github.com/juju/juju/pull/8578 accommodates the desired changes.

New configuration values:
- container-image-metadata-url
- container-image-stream

Works for KVM and LXD containers deployed on other providers.

[Joseph Phillips (manadart)]

These new config values mirror the existing config values for "image-metadata-url" and "image-stream" that are used by providers.

In the same way, leaving them as defaults results in images sourced from the released stream at cloud-images.ubuntu.com.

If the provider-level values are configured for a custom source/stream, and the operator desires that containers use the same images, then container-level config needs to be explicitly set to the same values.

In the course of this work, an existing issue was fixed whereby KVM containers did not find images in metadata from cloud-images.ubuntu.com when the stream was set to "daily".

[John A Meinel (jameinel)]

https://github.com/juju/juju/pull/8606 into 2.4

[John A Meinel (jameinel)]

the rest of 2.4 changes: https://github.com/juju/juju/pull/8610

[Anastasia (anastasia-macmood)]

Marking as Fix Released as 2.4.0 is out.