Hi,
This explains much! Thank you.
My server has this following.
> installadm list -n mpkpen-ai-1-osol-111b-sparc -c
Manifest Instance arch mac ipv4
--------------------------------------------------------------------------
ssqa-2009-06.111b.ai-d33a.xml:
0 sun4v 00:14:4F:46:DB:F6 -
00:14:4F:46:DB:F6 -
ssqa-2009-06.111b.ai.xml:
0 sun4v ::::: 172.021.000.000
::::: 172.021.255.255
1 sun4u ::::: 172.021.000.000
::::: 172.021.255.255
I had originally created the d33a manifest thus:
> installadm list -n mpkpen-ai-1-osol-111b-sparc -c
Manifest Instance arch mac ipv4
--------------------------------------------------------------------------
ssqa-2009-06.111b.ai-d33a.xml:
0 - 00:14:4F:46:DB:F6 -
00:14:4F:46:DB:F6 -
ssqa-2009-06.111b.ai.xml:
0 sun4v ::::: 172.021.000.000
::::: 172.021.255.255
1 sun4u ::::: 172.021.000.000
::::: 172.021.255.255
...and the target machine never used the d33a manifest. You explanation
sheds light on this behavior. By adding the "sun4v" I got lucky in the
evaluation order.
I was trying to create a "default" manifest that applied only to my
group's systems in the lab while allowing override with machine specific
manifests. I basically stumbled upon the evaluation order.
Should this be documented somewhere for others who are going to try what
I did? Especially to make it well known that the current behavior is an
artifact of the implementation and will likely change in the future (YMMV!).
Clay Baenziger said the following on 05/21/09 07:37 PM:
> 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)
>> ========
>>
>>
--
~~~~\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)
========
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jon_aimone.vcf
Type: text/x-vcard
Size: 274 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20090521/a99e8e8c/attachment.vcf>
