Open Stack

On Wed, 7 Oct 2020, 21:18 Julia Kreger, <juliaashleykreger at gmail.com> wrote:

> On Wed, Oct 7, 2020 at 11:16 AM Mark Goddard <mark at stackhpc.com> wrote:
> >
> > On Wed, 7 Oct 2020 at 16:11, Riccardo Pittau <elfosardo at gmail.com>
> wrote:
> > >
> > > Hello fellow openstackers!
> > >
> > > At the moment it's not possible to migrate the
> ironic-python-agent-builder src jobs from bionic to focal nodeset because
> of diskimage-builder limitations.
> > > We're stuck with ubuntu bionic and we're pinning those jobs to the
> bionic nodeset for the time being:
> > > https://review.opendev.org/756291
> > >
> > > One of the community goals for victoria is to move the base nodeset of
> the CI jobs from ubuntu bionic to focal.
> > > In general, doing this for most of the ironic projects has not been
> trivial, but still doable, and it has been accomplished almost entirely.
> > > The biggest challenge comes from the src jobs in
> ironic-python-agent-builder where, for some of them, we build
> ironic-python-agent ramdisks using rpm-based distributions (mainly centos)
> with diskimage-builder on ubuntu bionic.
> > > This is possible using utilities (e.g. yumdownloader) included in
> packages still present in the ubuntu repositories, such as yum-utils and
> rpm.
> > > Starting from Ubuntu focal, the yum-utils package has been removed
> from the repositories because of lack of support of Python 2.x and there's
> no plan to provide such support, at least to my knowledge.
> > > The alternative provided by dnf is not usable as there's also no plan
> to compile and provide a package of dnf for deb-based distributions.
> > > For the reasons mentioned above, currently the ironic project team
> can't complete the migration of the CI jobs from bionic to focal and
> there's no ETA on when this can be accomplished.
> > >
> > > Considering all the things in the preamble, two possibilities are
> available:
> > > - change the mechanics in diskimage-builder; this process would
> completely change the way DIB builds rpm-based distros; this approach
> delegates the work almost entirely to the DIB team.
> > > - instead of migrating to focal, migrate to centos-8 nodeset; that
> would mean having devstack+ironic working on centos-8, which poses an
> interesting challenge and would consume no little resources from the ironic
> team.
> > >
> > > Opinions and advice are very welcome!
> >
> > My first reaction would be to consider the user impact beyond the box
> > checking of fulfilling a goal. Does this imply Ubuntu users can no
> > longer build IPA images from Focal? That would be a shame.
>
> The goals are really meant to drive the community together as a group.
> And if box checking is not appropriate, then it is not appropriate. I
> think the key is in the meaning of the goal which is to drive everyone
> forward together. I do concur end user impact is the key item to focus
> on. I don't think this is helped due to pre-existing constraints. I
> seem to remember that you couldn't build ubuntu on centos previously,
> so this sort of issue does not surprise me. At least, not without
> having some extra packages present that one could install and it might
> work with some hope.
>
I didn't mean to imply that the goal is not a worthwhile endeavour, only
that user impact should come first.

>
> My guess is that we're effectively entering a situation where if I
> want to build a centos/rhel/fedora IPA image, I need to run the ipa
> builder command on one of those machine types, and if I want the same
> for debian/ubuntu, I need to run the build on one of those operating
> systems. Is that situation horrible for users, not really because they
> are and likely should keep the distribution the same for familiarity
> and compatibility. The thing we likely need to do is do an ubuntu IPA
> image test in CI but not save the artifact. Or debian!
>
This does raise the question of how to test a centos based IPA image before
it is published though.

>
> >
> > In terms of fulfilling the goal, perhaps running DIB in a CentOS
> > container would help? This of course adds complexity, potential
> > problems, and doesn't really test what users would do.
> >
> > >
> > > Thanks,
> > >
> > > Riccardo
> > >
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201007/729b90e2/attachment.html>