Rethinking the <info> tag

[Radek Pazdera]

Hello!

It occured to me, while I was writing the XML Reference, that we have
forgotten to consider expansion of information using which we would
like to match machines.

At the moment, LNST can match interfaces (that is pretty good) and apart
from that it can match hostnames and libvirt_domain from the info tag.

<info hostname="karel.org"/>

We agreed in the past, that we'd like to add more options to match to
that list. At first, we could just add more attributes to the <info> tag,
but after while it could get pretty messy (if we combine OS options,
hardware requirements, package requirements and all other sorts of
things into a single info tag). One tag in my opinion does not scale
very well.

I think we could (with a little effort) improve the scalability of
the solution for the future by making the info tag just a parent to
many more information tags. For instance:

<info>
        <connection hostname="karel.org"/>
        <libvirt domain="virtual_karel"/>
        <os name="RHEL" version="4.9.z"/>
        <pool name="Boston"/> <!-- use only a specific pool -->
    </info>

A fairly short and general piece of code could be written to accept all
different subtags and parse it into:

recipe["machines"]["karel"]["info]["connection"]["hostname"]
    recipe["machines"]["karel"]["info]["libvirt"]["domain"]
    recipe["machines"]["karel"]["info]["os"]["name"]
    recipe["machines"]["karel"]["info]["os"]["version"]

And we wouldn't have to worry about it at all (even if we would like to
add a new matching feature support). The users would add these tags into
their pool and into their recipes. The same parser would be used for both
and then we'd just compare strings in arrays.

What do you think?

Merry Christmas!

Radek