Comment 1 for bug 1635345

Ok.. updates to the virtualization script. I've changed how URLs are constructed quite a bit and also added a bit more debugging code. I've also added a method for validating URLs before testing. If the URL is invalid, we retry with a slight alteration to the cloud image filename and if it fails a second time, we exit with an error message.

This is necessary because the Xenial and earlier filenames look like this:

$RELEASE-server-cloudimg-$ARCH-disk1.img

while Yakkety and later look like this:

$RELEASE-server-cloudimg-$ARCH.img

So the way the script works now, it checks the xenial format first, then changes to the yakkety format and re-validates the URL.

There are basically three different ways to specify a remote URL (I haven't changed how local files are handled, whether they are just a file name and path, or file:// URI formatted):

Default - user doesn't specify a url and we assume to pull from cloud-images.ubuntu.com

Relative - user specifies a url to a director (or with no directory), as in http://192.168.0.20/images. We assume that /images is a dir with copies of the official images from cloud-images, and thus follow the same naming conventions. (this assumes that the end of the URL does not end in .img)

Absolute - user specifies a url to an actual file such as http://192.168.0.20/images/yakkety-image.img, in which case we validate the absolute URL and go on about our day, or exit if it's invalid.

This will require images to end in .img, but we can just enforce that with policy and the error messages, as there's really no way to query a URL and determine if it's a File or a Directory.

Sample output will follow.