Comment 15 for bug 1872941

On Fri, 17 Apr 2020, 08:30 bugproxy, <email address hidden> wrote:

> ------- Comment From <email address hidden> 2020-04-17 03:12 EDT-------
> (In reply to comment #21)
> > Unfortunately installer-arch/ is hardcoded portion of the prefix in the
> > internal archive publishing, internal mirroring, and external mirroring,
> > thus I cannot change it to legacy-installer-arch.
> >
> > Also these will only exist for a short period of time until June, so I
> don't
> > see the point of investing into redoing all of our archive publishing to
> > support this.
> >
> > If you use an internal mirror, you can modify it with extra symlinks to
> > symlink legacy-images to images to fix your internal deployment.
> However, we
> > should work together on moving away your virt-install deployments away
> from
> > d-i.
>
> You can install suse,redhat,fedora,debian and old ubuntu guests with
> virt-install. cockpit uses virt-install under the covers. virt-manager
> uses virt-install under the covers. For any system that has non-Ubuntu
> guests as well saying "hey we have something better" is just not
> helpful.
>
> I think the proper fix is to teach virt-install the new installer. We
> already have lots of special handling code in virt-install for different
> versions of different distros.

Sure, however virt-install currently is not the best way to experience any
release of Ubuntu. That's why MAAS, Canonical Distribution of Openstack,
LXD, Multipass and all public & private clouds that provide Ubuntu consume
and use cloud images, providing a superior experience & configurability
than all other distributions mentioned. The above products cater from
Multipass "give me a quick VM", to manage a "small cloud" / "very bit
cloud".

And virt-install using d-i or iso, instead of qcow2 images (with or without
unpacked kernel) as inputs for any release of Ubuntu, on any architecture
is suboptimal. virt-install should be using cloud images for Ubuntu 12.04
LTS (precise and up). Just like Multipass, lxd-kvm, maas KVM pods,
OpenStack. Many other distributions also provide cloud-init enabled images.
There was GSOC project to get "cloud-init" support but that only landed on
a branch, and hasn't made it into release.

It seems to me that virt-install pre-dates the times of distributions
providing preinstalled cloud-init enabled qcow2 images. Hence so much
automation grew around the suboptimal inputs. Cloud-images is not an
ubuntu-only feature.

Given that the d-i paths changed, and I can't make them compatible enough,
I will reopen the virt-install task to fix path detection in virt-install,
at a wishlist priority. I'll open a separate feature request to support
cloud-images in virt-install & forward it upstream, also at wishlist
priority.