Hi, In-line...
Ethan Quach said the following on 06/24/10 05:47 PM:
I have not been able to find that order documented anywhere, and I did not want to assume a dictated binding precedence that turned out to simply be serendipitous.On 04/30/10 02:28, Jon Aimone wrote:Hi, I greatly appreciate this design effort. Reading section 5.3.3 raises a few questions about criteria...First... How will the administrator specify the binding precedence for the criteria?Consider a scenario that exists in our data center today.Most of the machines in IP range x.x.x.65-x.x.x.128 need to use manifest A.Machines outside this range may use the default manifest. Specific machines in that range need to use manifest B. These are all SPARC systems.How does this get configured without explicitly setting a criteria for each and every machine in the IP range?My impulse would be to create a criteria that selects manifest A for the IP range, then set specific criteria using MAC address for the few select machines requiring manifest B. However, for this to function I need to be able to specify the binding precedence.Hi Jon, For this particular example, why would you need to specially dictate the order of precedence? The inherent order AI uses today should work, no?
Second... How can I create multiple criteria sets for the same manifest.For example, I'd like to specify IP range x.x.x.10-x.x.x.31 and range x.x.x.200-x.x.x.254 all get manifest A while everything else gets the default. The syntax described in 5.3.3 doesn't make it clear that this would be possible.Would making a copy of said manifest and adding it again with the second criteria set be acceptable?
"Acceptable" is such a subjective term...Doing thus increases the number of manifests requiring maintenance. I'm already facing the probability of hundreds of manifests per AI service, because we have rather eclectic lab resources.. So I'm looking for anything that allows me to group clients into a smaller set of manifests.
This is also the reason I had originally asked last year about breaking manifests into even smaller segments: client configuration, installation payload, sw configuration, etc., each with their own selection criteria. A facility for arbitrary manifest segmentation and client-side derivation and assembly would be ideal.
My favored view of manifests would be data filtered through a sieve of attributes from the client and AI server.
thanks, -ethanjm2ยข Ethan Quach wrote:I have posted a revision to the derived manifest design. (I've removed the pieces about an interactive manifest CLI on the server side, as that needs to be a separate design.)http://hub.opensolaris.org/bin/download/Project+caiman/DerivedManifests/DerivedManifestsDesignSpec.pdfPlease review. Comments appreciated. thanks, -ethan _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss_______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
--
~~~~~~~\o/~~~~~~~
Cheers,
Jon.
{-%]
========
If you always do what you've always done, you'll always get what you've always
gotten.
- Anon.
--------
The difference between genius and stupidity is that genius has its limits.
- Albert Einstein
--------
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) ========
<<attachment: jon_aimone.vcf>>
_______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
