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.
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:
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.
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
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.
/dale
