John Stanford's Blog Random Sample

I have been working on a particularly fun section of code in N1SPS. I am trying to create a parallel Solaris Container deployment strategy that requires minimal operational interaction. Basically, a configuration manifest like:

ZONE_NAME=test-zone11
ZONE_PARENT=t2000-11-1
ZONE_MGMT_IP_ADDR=10.15.200.111
local_zone_base_path=/zones
ZONE_INTERFACES=ipge0:10.15.200.111/24
ZONE_FULL_ROOT=false
ZONE_INHERIT_LOFS_DIR=rw:/logs/foo:/logs rw:/xyz/foo:/xyz
ZONE_CREATE_LOFS_DIRS=true
ZONE_INHERIT_PKGS_DIR=
ZONE_PASSWORD=1d2jxiU7dXp7k
ZONE_TZ=US/Arizona
ZONE_TIMEHOST=localhost
ZONE_TERM=xterm
ZONE_AUTOBOOT=true
ZONE_DESTROY_EXISTING=true
ZONE_DOMAIN=xyz.com
ZONE_NAMESERVER=ns.xyz.com
ZONE_DEFAULTROUTER=10.15.200.1
CSZ_GO_BOOT_NOW=true

ZONE_NAME=test-zone12
ZONE_PARENT=t2000-11-1
ZONE_MGMT_IP_ADDR=10.15.200.112
local_zone_base_path=/zones
ZONE_INTERFACES=ipge0:10.15.200.112/24
ZONE_FULL_ROOT=false
ZONE_INHERIT_LOFS_DIR=rw:/logs/foo:/logs rw:/xyz/foo:/xyz
ZONE_CREATE_LOFS_DIRS=true
ZONE_INHERIT_PKGS_DIR=
ZONE_PASSWORD=1d2jxiU7dXp7k
ZONE_TZ=US/Pacific
ZONE_TIMEHOST=localhost
ZONE_TERM=xterm
ZONE_AUTOBOOT=true
ZONE_DESTROY_EXISTING=true
ZONE_DOMAIN=xyz.com
ZONE_NAMESERVER=ns.xyz.com
ZONE_DEFAULTROUTER=10.15.200.1
CSZ_GO_BOOT_NOW=false

#ZONE_NAME=test-zone13
#ZONE_PARENT=t2000-mgmt-2
#ZONE_MGMT_IP_ADDR=10.15.200.113
#local_zone_base_path=/zones
#ZONE_INTERFACES=ipge0:10.15.200.113/24
#ZONE_FULL_ROOT=false
#ZONE_INHERIT_LOFS_DIR=rw:/logs/foo:/logs rw:/xyz/foo:/xyz
#ZONE_CREATE_LOFS_DIRS=true
#ZONE_INHERIT_PKGS_DIR=
#ZONE_PASSWORD=1d2jxiU7dXp7k
#ZONE_TZ=US/Central
#ZONE_TIMEHOST=localhost
#ZONE_TERM=xterm
#ZONE_AUTOBOOT=true
#ZONE_DESTROY_EXISTING=true
#ZONE_DOMAIN=xyz.com
#ZONE_NAMESERVER=ns.xyz.com
#ZONE_DEFAULTROUTER=10.15.200.1
#CSZ_GO_BOOT_NOW=false

The format of the manifest is not important, in fact, it could easily be a graphical front end, a spreadsheet, LDAP entries, etc. The important thing is that the data can be predefined by people or systems. At this point, the role of the operator is limited to entering:

The location of the manifest file The root password for the new zone The n1sps user password for the new zone

Anyway, I ran into a fairly serious challenge. Since we are deploying an OS instance that will have it's own N1SPS remote agent, the appropriate mechanism in the plan/component language is to use a targetable component. This is a component that creates an N1SPS host upon successful completion of the install block. In this case, we want to make the new host a physical host so we can later put an agent on it. The code to make a component targetable looks something like:

Unfortunately, I found that it was not currently possible to install a targetable component that creates a physical host on a virtual host target. I spoke with engineering and N1 marketing, and we all decided that there was no real reason this shouldn't be possible, and due to the time sensitive nature of this initiative, they would expedite a fix. The fix was available the next day in an internal only, unqualified form, and the patch will be pushed through QA, and be available to the general N1SPS community in approximately 1 month. Much thanks for keeping me moving forward goes to Anshul, Doan, Ilango, and others who helped out!