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)
>
>
