<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 8, 2020 at 10:19 AM Luigi Toscano <<a href="mailto:ltoscano@redhat.com">ltoscano@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thursday, 8 October 2020 06:18:35 CEST Ian Wienand wrote:<br>
> On Wed, Oct 07, 2020 at 05:09:56PM +0200, Riccardo Pittau wrote:<br>
> > This is possible using utilities (e.g. yumdownloader) included in packages<br>
> > still present in the ubuntu repositories, such as yum-utils and rpm.<br>
> > Starting from Ubuntu focal, the yum-utils package has been removed from<br>
> > the<br>
> > repositories because of lack of support of Python 2.x and there's no plan<br>
> > to provide such support, at least to my knowledge.<br>
> <br>
> Yes, this is a problem for the "-minimal" elements that build an<br>
> non-native chroot environment.  Similar issues have occured with Suse<br>
> and the zypper package manager not being available on the build host.<br>
> <br>
> The options I can see:<br>
> <br>
> - use the native build-host; i.e. build on centos as you described<br>
> <br>
> - the non-minimal, i.e. "centos" and "suse", for example, images might<br>
>   work under the current circumstances.  They use the upsream ISO to<br>
>   create the initial chroot.  These are generally bigger, and we've<br>
>   had stability issues in the past with the upstream images changing<br>
>   suddenly in various ways that were a maintenance headache.<br>
> <br>
> - use a container for dib.  DIB doesn't have a specific container, but<br>
>   is part of the nodepool-builder container [1].  This is ultimately<br>
>   based on Debian buster [2] which has enough support to build<br>
>   everything ... for now.  As noted this doesn't really solve the<br>
>   problem indefinitely, but certainly buys some time if you run dib<br>
>   out of that container (we could, of course, make a separate dib<br>
>   container; but it would be basically the same just without nodepool<br>
>   in it).  This is what OpenDev production is using now, and all the<br>
>   CI is ultimately based on this container environment.<br>
> <br>
> - As clarkb has mentioned, probably the most promising alternative is<br>
>   to use the upstream container images as the basis for the initial<br>
>   chroot environments.  jeblair has done most of this work with [3].<br>
>   I'm fiddling with it to merge to master and see what's up ... I feel<br>
>   like maybe there were bootloader issues, although the basic<br>
>   extraction was working.  This will allow the effort put into<br>
>   existing elements to not be lost.<br>
> <br>
> If I had to pick; I'd probably say that using the nodepool-builder<br>
> container is the best path.  That has the most momentum behind it<br>
> because it's used for the OpenDev image builds.  As we work on the<br>
> container-image base elements, this work will be deployed into the<br>
> container (meaning the container is less reliant on the underlying<br>
> version of Debian) and you can switch to them as appropriate.<br>
<br>
I have to mention at this point, at risk of reharshing old debates, that an <br>
alternative in various scenarios (maybe not all) is the usage of libguestfs <br>
and its tools which modifies an existing base image.<br>
<br>
<a href="https://libguestfs.org/" rel="noreferrer" target="_blank">https://libguestfs.org/</a><br>
<br>
We switched to it in Sahara for most of the guest images and that saved some <br>
headaches when building from a different host.<br>
<a href="https://docs.openstack.org/sahara/latest/user/building-guest-images.html" rel="noreferrer" target="_blank">https://docs.openstack.org/sahara/latest/user/building-guest-images.html</a></blockquote><div><br></div><div>I like guestfish (a lot), but our IPA images are a bit awkward: we take a qcow2 image and convert it to a kernel/ramdisk pair. I guess we can use guestfish to get the former, but not the latter.</div><div><br></div><div>It also means changing the approach that has been used and documented for years. Not impossible, but should not be done lightly.</div><div><br></div><div>Dmitry<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
<br>
I'd like to mention that libguestfs has been carrying a virt-dib tool for a <br>
while, but it has been tested only back to a certain version of dib:<br>
<a href="https://libguestfs.org/virt-dib.1.html" rel="noreferrer" target="_blank">https://libguestfs.org/virt-dib.1.html</a><br>
<br>
-- <br>
Luigi<br>
<br>
<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Red Hat GmbH, <a href="https://de.redhat.com/" target="_blank">https://de.redhat.com/</a> , Registered seat: Grasbrunn, <br>Commercial register: Amtsgericht Muenchen, HRB 153243,<br>Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill <br></div></div></div>