Sundar et al,
I started looking at the user experience pieces from your original
list and have some thoughts below. So far, I've only looked at the
server-side tasks, mainly in the installadm command. Lets discuss
these...
Thanks,
-ethan
1. SMF Install Server Service
- Create an SMF service, svc://system/install/server, as the overall
install server service.
- Can be used as the controlling mechanism to stat/stop the
webserver(s) needed for the install services served.
- Illiminates the need for explicit service dependency checks
in the installadm tool.
2. Manifests
- Move the criteria manifest down one level in the composite
manifest, and make it optional, thus allowing a NULL criteria
to be specified. This enables one to write and publish manifests
without having to think about the client usage ahead of time.
- The default manifest for a service should be specifiable via a
specific tag in the criteria manifest, not the absence of a non-default
name.
- The above two imply that criteria could be administered
subsequent to a manifest being published. Given that criteria are
an external entity from the actual install manifest (the ai_manifest),
I think this makes sense. Perhaps we add a couple new
subcommands to enable this? (This assumes that the list of 'criteria'
is an interface we export, and is not customizable. I didn't see
anything in the design doc to say otherwise.)
installadm set-criteria -n <svcname> -m <manifest_name> name=value
installadm get-criteria -n <svcname> -m <manifest_name> [name]
- Be able to view the contents of a published manifest. Perhaps:
installadm export-manifest -n <svcname> -m <manifest_name> [-o file]
- Being able to edit the attributes of a published manifest would
seem like a natural follow-on to the above, but I don't have any
evidence yet that this is required. Given the ability to export the
contents of a manifest, it should suffice for now to just export a
manifest to file, make edits, and re-publish.
- A small nit I ran into is that the specification of the manifest in
the "add" and "remove" subcommands are inconsistent. The
former takes a file, the latter takes the actual name of the
manifest, yet the both are specified with -m. This could be a little
less confusing if the usage for "add" was instead:
installadm add -n <svcname> <file>
And while we're on nits, "add" and "remove" seem like they could
be more specifically named to be "add-manifest" and
"remove-manifest"
- I need to do further evaluation on the SC portion of the manifest.
Even with enhanced profiles, the install server tools will still have to
deal with an SC manifest specification, so its current existence in
the composite manifest will likely change, though I'm not sure how
yet.
3. Services and service configurations
- Since manifests are tied to services rather than individual clients,
we need a way to replicate a service's configuration, including all of
its published manifest, to serve a new/different image. One possibility
here is to provide a way to clone an existing service's configuration
to create a new service. Maybe something like:
installadm clone-service -e <existing_svcname> -n <svcname> ...
There's potentially hidden cost here in that replicating service's
configuration might mean physically replicating the actual data.
We need to figure out how to share the elements of the configuration.
(This might just be implementation detail however.)
- Bypass the download of the AI iso image by providing an option
to point to an IPS repo and branch name, and building the AI image
on the fly. Maybe something like:
installadm create-service ... [-s <srcimage> | -r <repo> -b <branch>] ...
This obviously depends on DC and would only work when creating
a service of like architecture as the install server.
4. Visibility into the install server's configuration.
- Enhance to the "list" subcommand with options to get more
details. Here are some things that would seem useful:
- status of each service
- the image associated with each service.
- the manifests associated with each service, and which is
the default
