Correct Image properties lookup for paths

The image lookup process, when handed a path attempts
to issue a HEAD request against the path and gets a
response which is devoid of details like a content length
or any properties. This is expected behavior, however if
we have a path, we also know we don't need to explicitly
attempt to make an HTTP HEAD request in an attempt to
match the glance ``kernel_id`` -> ``kernel`` and similar
value population behavior.

Also removes an invalid test which was written before the
overall method was fully understood.

And fixes the default fallback for kickstart template
configuration, so that it uses a URL instead of a
direct file path.

And fix logic in the handling of image property result
set, where the code previously assumed a ``stage2``
ramdisk was always required, and based other cleanup
upon that.

Change-Id: I589e9586d1279604a743746952aeabbc483825df

1 files changed, 16 insertions, 0 deletions

diff --git a/releasenotes/notes/correct-source-path-handling-lookups-4ce2023a56372f10.yaml b/releasenotes/notes/correct-source-path-handling-lookups-4ce2023a56372f10.yaml
new file mode 100644
index 000000000..10d270a45
--- /dev/null
+++ b/releasenotes/notes/correct-source-path-handling-lookups-4ce2023a56372f10.yaml
@@ -0,0 +1,16 @@
+---
+fixes:
+  - |
+    Fixes an issue where image information retrieval would fail when a
+    path was supplied when using the ``anaconda`` deploy interface,
+    as `HTTP` ``HEAD`` requests on a URL path have no ``Content-Length``.
+    We now consider if a path is used prior to attempting to collect
+    additional configuration data from what is normally expected to
+    be Glance.
+  - |
+    Fixes an issue where the fallback to a default kickstart template
+    value would result in error indicating
+    "Scheme-less image href is not a UUID".
+    This was becaues the handling code falling back to the default
+    did not explicitly indicate it was a file URL before saving the
+    value.