Hi Jon,
That's a very good question! I'm not sure that the binding
precedence has been documented before.
The ordering comes from the underlying database[1]. The manifest
selection happens from first to last (left to right) of the various
criteria as provided by the database table creation.
During manifest selection the code traverses down a path of
criteria as passed in by the client and determined by which criteria are
actually in use. The code does not traverse back up a path in case of a
hole[2]. It was intended publish-manifest should prevent holes from
being added[3], however, as bug 9106 shows it doesn't in all cases (one
can always use delete-manifest to contrive holes too right now).
This part of the AI webserver should be looked over to move it out
of its relatively prototype state. Does this help your understand for the
time being at least?
Thank you,
Clay
[1]: Here's what the database criteria look like (note the ordering):
root at jumprope: 530 # sqlite3 /var/ai/46501/AI.db
SQLite version 3.6.7
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .schema manifests
CREATE TABLE manifests (name TEXT, instance INTEGER, arch TEXT, MINmac
INTEGER, MAXmac INTEGER, MINipv4 INTEGER, MAXipv4 INTEGER, cpu TEXT,
platform TEXT, MINnetwork INTEGER, MAXnetwork INTEGER, MINmem INTEGER,
MAXmem INTEGER);
[2]: A hole looks like:
Say the database has two criteria sets who's criteria span:
architecture, MAC address, memory size and IP address.
Assume one criteria specifies only, arch, MAC address and IP address and
the other manifest only specifies arch, memory size and IP address. Then,
the server asks all clients requesting a manifest to at least return the
span of criteria:
architecture, MAC address, memory size and IP address.
Say a client requests a manifest and provides criteria which match both
criteria sets' architecture, MAC address, memory size but but only one
criteria set's IP address. The server will then look for manifests which
are specified by exactly that architecture, or failing will go with an
architecture agnostic manifest. Next, the server will move on to see which
manifests having the chosen architecture (since we matched an
architecture) have a matching MAC address or are MAC address agnostic. As
we match on MAC address, the server will then look for manifests matching
architecture and MAC address -- we have thrown out the manifest which did
not specify MAC address since we got a more exact match so far -- this is
the hole. Next we look for a memory size match, finding none, we keep our
current manifest selection. Then we compare on IP address and see that
there is not a match, throw out our one selection and go with a default
manifest. This despite a manifest which matched exactly on its three
criteria (arch, MEM, IP). Thus we had a hole in the manifests.
[3]: If one tries to publish a hole, they may see an error like:
Error: Manifest has a range collision with manifest:test.xml/1
in criteria:mac!
One can see what's being talked about by running:
root at jumprope: 560 # installadm list -n clay_ai_sparc -c
Manifest Instance mac ipv4 mem
--------------------------------------------------------
test.xml:
0 00:14:4F:C3:41:FA - -
00:14:4F:C3:41:FA - -
1 - 010.010.000.001 -
- 010.010.000.001 -
Here we see that the MAC address specified in my new manifest must have
had 00:14:4F:C3:41:FA in the range. Note that publish-manifest(1) is off
by one in its range errors (see bug 9105).
On Wed, 20 May 2009, Jon K Aimone wrote:
> Hi,
>
> I've probably just missed this subject in all the design discussion and notes
> flying around this alias lately, but I don't recall seeing any discussion
> about binding precedence for the various attributes in the criteria manifest.
> Which binds tighter, IPv4 or MAC.
>
> And do manifests blend? If I have an ARCH criteria /and/ one for MAC do both
> apply, and how would they blend? And example...
>
> ARCH criteria would select some set of systems (e.g. sun4v) and specify a set
> of packages to install.
>
> MAC criteria would select one sun4v system and specify the target disk for
> installation. None of the criteria nor configuration information collides, so
> this could actually describe a valid installation.
>
>
> ...jm2?...
>
> --
> ~~~~\0/~~~~
> Cheers,
> Jon.
> {-%]
> ========
> If you always do what you've always done, you'll always get what you've
> always gotten.
> - Anon.
> --------
> When someone asks you, "Penny for your thoughts," and you put your two cents
> in, what happens to the other penny?
> - G. Carlin (May 12, 1937 - June 22, 2008)
> ========
>
>
