Launching xenial LXD VM images should not default to the images: remote

[OddBloke]

The expectation of the cloud-init integration tests is that pycloudlib will operate on official Ubuntu cloud images by default. This is also the documented expectation in the design doc:

Instances are expected to use the latest daily image, unless another image is specifically requested.

For LXD, that means fetching images from the ubuntu-daily: remote (and not from images:).

(As UA client has specific requirements that diverge from this sensible default behaviour, I believe its testing code should be specifically requesting an image that meets those requirements, rather than modifying the default behaviour for all consumers.)

[OddBloke]

(@TheRealFalcon FYI, this is a blocker for moving the integration tests to be voting for cloud-init, IMO: they aren't testing what they should be testing (and what the existing tests are testing).)

[TheRealFalcon]

The 'images:' remote is only being used for xenial VMs running on LXD, correct? IIRC there's an issue that prevents xenial from running on an LXD VM at all, so unless there's a reasonable workaround, it's this or no Xenial at all.

[OddBloke]

The 'images:' remote is only being used for xenial VMs running on LXD, correct? IIRC there's an issue that prevents xenial from running on an LXD VM at all, so unless there's a reasonable workaround, it's this or no Xenial at all.

Not as of e9791a9, no.

[OddBloke]

For reference:

$ CLOUD_INIT_OS_IMAGE=xenial tox -r -e integration-tests -- tests/integration_tests/bugs/test_lp1886531.py
...
INFO     integration_testing:conftest.py:76 Setting up environment for lxd_container
INFO     integration_testing:conftest.py:102 Done with environment setup
INFO     integration_testing:clouds.py:64 Launching instance with launch_kwargs:
image_id=images:ubuntu/16.04/cloud
user_data=#cloud-config
bootcmd:
- rm -f /etc/fstab

wait=False

[OddBloke]

This is now causing cloud-init integration test failures: our apt tests pass configuration which will render apt unable to update or install (specifically because we configure squid.internal as a proxy to test that configuration is written correctly). This means that when we attempt to install openssh-server, it fails (and we never gain SSH access to the system).

[blackboxsw]

The related UA-client PR is an attempt to double-down on pycloudlib custom vm setup. We'll hold on this in ua-client as it can carry the burden of LXD VM Xenial support for our use-case. We should probably discuss implications of documenting this gap in functionality in pycloudlib.

[TheRealFalcon]

This was fixed in #122