[libvirt] [jenkins-ci PATCH v5 4/5] mappings: extend mapping to allow per-arch entries

[Daniel P. Berrangé]

On Tue, Feb 26, 2019 at 03:00:58PM +0100, Andrea Bolognani wrote:
> On Tue, 2019-02-26 at 11:00 +0000, Daniel P. Berrangé wrote:
> > For example to prevent Xen being installed on any s390x
> > 
> >   xen:
> >     default-s390x:
> >     deb: libxen-dev
> >     Fedora: xen-devel
> > 
> > Or the inverse to only install Xen on x86_64 on Debian, but allow
> > it on all archs on Fedora
> > 
> >   xen:
> >     deb-x86_64: libxen-dev
> >     Fedora: xen-devel
> > 
> > Note that the architecture specific matches are considered after
> > all the non-architcture matches.
> 
> I feel like the order entries are processed with this implementation
> can be quite counter-intuitive. The root problem of course is that up
> until this point we have had a single axis to work on, and we're now
> introducing a second one which is independent of the existing one but
> which we still have to fit along with it into the same flat hierarchy
> somehow...
> 
> Consider an example such as
> 
>   foo:
>     Fedora: oldfoo
>     Fedora-s390x:
>     FedoraRawhide: foo
> 
> The general intuition up until now has been that appending something
> to a label would make it more specific, and only one item on each
> level would possibly match, but now both Fedora-s390x and
> FedoraRawhide appear to be on the same level and *both* could apply
> to an s390x Fedora Rawhide machine, making it less clear which one
> would take precedence.

Yes, I wasn't entirely happy with that.

> I suggest that the example above would be rewritten as
> 
>   foo:
>     Fedora: oldfoo
>     FedoraRawhide: foo
>     s390x-Fedora:
> 
> where two changes happened: first of all, the lines have been
> shuffled around to match the order they would actually be processed,
> which is something that we could have done with the above as well,
> but more importantly the architecture name is now *prepended* to the
> existing labels to clearly signal that it's part of a completely
> separate hierarchy. The ambiguity is now gone entirely, and which
> entry has precedence is easier to see at a glance.

I wouldn't say its unambigous, but it is less bad than before which
is nice :-)


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|