Derived Manifests

Problem Statement

 AI must offer an easy to use and observable mechanism for administrators to be able to create and manage custom client configurations, which could scale from a small number of configurations to a very large number.

• Custom configurations can be based on attributes specific to the client, such as hardware or the location of the client.
• The number of unique configurations may actually scale 1 to 1 with the number of clients to install.

Criteria for the Mechanism

• Support deriving which disk to install OS onto.
• Support deriving the disk partition layout
  • fdisk partitioning
  • slice partitioning
• Support deriving disk setup
  • number of zpools
  • size of zpools
  • swap and dump devices
  • zpool mirroring
  • zpool compression
• Support deriving the software payload. i.e. the packages to install
• Support deriving which IPS repo to install from based on location of client.
• Support derivation based on hardware attributes of the client. For example:
  • HBA type
  • disk vendor type
  • disk protocol (SCSI, SAS, FC, iSCSI, etc)
  • disk transport (DAS, FC SAN, iSCSI, FCoE, etc)
  • disk physical path
  • internal disk vs. external disk
  • disk type
  • disk size
  • number of disks
  • Memory size
  • video card type
  • NIC card type
  • client platform
  • firmware revision
  • aliases set in OBP
  • system manufacturer
  • system model - smbios
• The list of hardware attributes of the client to base derivation from needs to be extensible.
• Support derivation based on location of the client. Location inferred from:
  • IP address
  • hostname
  • domainname
  • netmask file
  • DHCP provided information
  • other networking information
  • arbitrary site information?
• Provide an interface for the derivation process to access a set of known client attribute values. The set of client attribute values to provide is not yet known, but examples are listed above.

Documentation

Documentation.

Notes

1. Derivation logic

Should the derivation logic execute on the server or client?

• Execution on the AI client:
  • - Advantages:
    • - modular client; derived manifest feature not dependent on existence of an AI server.
    • - execution not run on server; this would be safer for server
    • - no heavy processing load on server
    • - client attribute probes fully extensible
  • - Disadvantages:
    • - potentially unpredictable runtime environments for the derivation logic.
• Execution on the AI server:
  • - Advantages:
    • - If derivation logic is implemented as scripting, then there's no arbitrary scripting on the client.
  • - Disadvantages:
    • - client attribute probes not extensible unless there is some arbitrary scripting run on the client to collect whatever client attribute is wanted.

* Based on the advantages, we've decided execution to be run on the client.

What implements the derivation logic?

2. Scope of derivation

 Should we define that the derivation process a) create a full manifest from scratch, or b) just be filling in missing parameters in a "base" manifest provided by the user?

• The advantage of (a) is that there is less to develop into AI. There wouldn't be a need for AI to own a list of client attribute probes, and would be extremely flexible for the user.
• The big advantage of (b) is that as the manifest xml format changes, the user's derivation setup doesn't neccessarily need to know this.

* We have decided that the scope of the derivation will be (b)

3. Observability Tools

 Observability tools that interface with derived manifests should provide the following information:

1. Observe the processes and behavior of client and server.
   1* What the server is serving,
   1* What the client is requesting.
   1* Success and failure of the delivery.
2. Report, diagnose and assist in repairing faults.
3. Report successes and failures
4. Provide the manifest derived for a specific client.
5. Provide the derived manifest script that is run on a specific client