Hi,
I'll take a stab at it...
I was thinking of a simple ordered list of rules to evaluate. Each rule
would include an explicit order number and an expression. (I hate "line
numbers", but can't think of a better method at the moment.)
Rule order Expression
"mynode" 10 "client.MAC == criteria.MAC && blend"
"bysubnet" 20 "client.ARCH == criteria.ARCH && client.IPV4.value in
criteria.IPV4.range && blend"
"byram" 30 "client.RAM in criteria.RAM.range && blend"
"bydisk" 40 "client.DISKS in criteria.DISKS.range" && blend"
"default" 99999 "default"
How these are entered remains open. I can see a web interface or XML
files. XML files would probably be required for reproducibility,
recovery and replication.
Each manifest already specifies the criteria and values. So... if a
manifest specifies criteria which coincides with all the fields used in
a rule, then the manifest binds to the rule, and the rule should be
evaluated... or perhaps it might be simpler if the manifest names the
rule explicitly.
This would allow an administrator to create a layered selection for
matching manifests to clients. I would expect the following for the
rules above:
"default" binds to exactly one manifest that should be "good enough"
to install any system. It could specify a common configuration and
payload expected on every client installed.
"bysubnet" binds to a small number of manifests each of which would be
proper for a given subnet. It might specify certain payload additions
and/or other configuration specific to the subnet (e.g. name servers,
NFS servers, "local" application servers, repo server, etc.)
"mynode" binds to manifests written with specific machines in mind.
Since most of the clients should be covered by the more general
manifests selected through the higher numbered rules, there should be
very few machine specific manifests to which this rule would bind.
Such a layered scheme would allow me to install a wide variety of
systems with a minimum number of manifests blended together. Each layer
adds to the total configuration of each client, and the few clients
which really need special treatment could get it.
Now the ramification of being able to blend manifests will take a bit
more thought... can a manifest chosen by tighter binding (lower number)
rule "undo" something from looser binding (higher number) rule? ...need
more thought here.
Combine this with derived profiles... I could probably cover all the
configurations necessary in our lab with a handful of rules and manifests!
Clay Baenziger said the following on 06/ 2/09 01:59 PM:
> Hi Jon,
> Very cool way to come up with a manifest binding preference system
> and manifest blending system in one. I'm not quite sure I follow what
> the rules are ordered by, however. Would each manifest get a rule
> statement or something else?
> I had thought about when writing the little browser interface
> which runs on the web server that a way to allow the admin to reorder
> the fields would be a nice thing to provide. However, I hadn't given
> much thought to a more comprehensive system. Could you share a vision
> on how more power than just changing the binding globally would
> benefit a situation, as I think I'm having a lack of creativity for
> such as case?
>
> Thank you,
> Clay
>
> On Fri, 22 May 2009, Jon Aimone wrote:
>
>> 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)
>>
>>
--
~~~~\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/20090602/f80a0d31/attachment.vcf>
