Hi,
In my musing over this I've a suggestion from way out in left field. Why
not let the administrator who creates the service set the binding
precedence using something akin to a regex or even a SQL select
statement? This would alleviate the burden of having to define a binding
precedence that someone will always disagree with or want "enhanced."
Certainly we must provide some default and establish some suggested best
practices to begin with, but why try to come up with sophisticated
algorithm attempting to satisfy most of the cases only to have someone
want to revisit it later (near future) to fix some corner case.
I can envision this being an ordered list of statements provided by the
administrator when creating the service. A simple case would be
something like this:
client.MAC == criteria.MAC && usethis
client.ARCH == criteria.ARCH && client.IPV4.value in
criteria.IPV4.range && usefirst
client.ARCH == criteria.ARCH && usefirst
usedefault
Being an ordered list, process the first line. If statement does not
select a manifest, proceed to the next statement. If the statements are
exhausted with no match error.
"usethis" implies this should select exactly one or none, otherwise error.
"usefirst" implies possible multiple selection, use the first manifest.
"usedefault" uses the default manifest that comes with the service.
And if manifests can be blended:
(client.ARCH == criteria.ARCH || client.IPV4 in criteria.IPV4.range)
&& useblended
In this last case the ARCH selects a manifest that defines which
packages to install, and the IPV4 selects a manifest that defines which
repo to use. Together this defines a complete dataset for a working
manifest.
Anyway, just some of my thotz...
Jon K Aimone wrote:
> 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)
>>> ========
>>>
>>>
>
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>
--
~~~\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: 305 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20090522/57ba42ea/attachment.vcf>
