Dale,
Thanks for the comments.
Dale Ghent wrote:
> On Aug 17, 2009, at 3:14 PM, Sundar Yamunachari wrote:
>
>> Hi,
>>
>> I have updated the proposal to simplify AI manifests with the
>> following changes:
>>
>> - The installadm interfaces for new subcommands and changes to the
>> existing subcommands are finalized (Thanks to Frank and Ethan)
>> - Changes based on the feedback to the previous proposal
>> The document is at
>> http://www.opensolaris.org/os/project/caiman/auto_install/manifest_simplification_proposal_v3.
>>
>> Your feedback is requested.
>
> Hello Sundar
>
> I'm taking interest in "Derived Manifests" (Section 5.0) specifically.
>
> The quoted URL for the Derived Manifests functional spec gives me a
> 404, so please post it up if you can or correct the quoted URL if it
> lives elsewhere.
There correct link is
http://www.opensolaris.org/os/project/caiman/auto_install/DerivedManifests/AI_derived_manifests_func_spec.v2.0.txt.
>
> Quoting the second paragraph:
>
>> The user can create all the required manifests and setup the
>> configuration to associate manifests to clients using installadm
>> commands. This is a better option if the user configuration is based
>> on commonly used client characteristics like MAC address, memory,
>> architecture and IP address.
>
> Assuming the listed items is an exhaustive list of characteristics
> from which one may generate a manifest on the fly, I would like to
> advocate some additions:
This is not the exhaustive list. These are only some examples.
>
> 1) By client hostname, as assigned by DHCP, with optional regex
>
> Reasoning: It is common in large and/or dispersed environments to find
> a client's function, location, disposition and other arbitrary
> information encoded in the client's hostname, eg:
>
> ## Web servers
> web1-sjl2.prod.company.com
> web4-nrt1.prod.company.com
>
> ## Oracle DB server clusters
> rac1-db1.nyc.noprofit.org
> rac3-db2.wdc.noprofit.org
>
> And so on.
>
> Using the above Web servers example, those servers would want to be
> installed with the same manifest, but the list of characteristics
> would mean a laborious enumeration of IP addresses in large-scale
> enterprise. Therefore it would be highly desired to dynamically
> generate a manifest base on hostname in this instance, with a regex
> applied which would say, for example, "this is a production web
> server" and the appropriate manifest generated from that and any
> additional variables. A "web production web server in Tokyo" however
> might require a slightly different manifest. If all one had at their
> disposal were the listed characteristics in this spec, one would
> certainly not have this flexibility, increasing administrative work.
The host name can be easily added. I will add hostname to the list.
>
>
> 2) IP address ranges should accept CIDR notation
>
> Reasoning: CIDR notation is the industry standard method of defining a
> range of IPv[46] addresses. CIDR is well understood and easily parsed.
> Notation in the form of following examples should be accepted:
>
> 10.0.11.40/29
> 10.0.10.0/255.255.255.0
The syntax and examples are only samples. The CIDR notation can be
easily accepted.
>
>
> 3) Platform should be added to the list of available characteristics,
> with optional regex.
>
> Reasoning: Architecture ("i386" vs "sparc") is often not fine-grained
> enough to go on when it comes to specific kinds of servers and
> generating manifests tailored to them. What I am referring to as
> "Platform" would be what you get in the output of 'uname -i' on SPARC
> and the Product string from 'smbios -t SMB_TYPE_SYSTEM' on x86.
>
> Often, one has to install supplemental packages or patches or define
> additional parameters (boot disk choice, etc) which are specific to a
> certain model of hardware. Many parameters cannot be derived (or
> rather, guessed) safely without knowing this information before
> generating the manifest. X4500/X4540 servers with their particular
> disk assignment needs immediately come to mind, and I assure you
> additional situational examples could be given.
The platform is currently supported and will continue to be supported.
Thanks,
Sundar
>
> /dale
