Some additional notes on these items interspersed below, gathered
from various folks ... and more comments below.
thanks,
-ethan
Ethan Quach wrote:
> 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.
The use of an instance of a webserver for *each* install service
needs to be reevaluated. It seems as though this can be implemented
by just using one instance of a webserver, owned by the install server
service, serving up all of the install images.
We should look for other functional pieces of the install server
to see if it makes sense to separate them out as their own SMF
services.
>
>
>
> 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 default manifest shouldn't be specified in the manifest content
at all. Its a property of the service, so should be specified
independently from the manifest content. Two ways we'll do this:
a) Use a command line option to note it while the manifest is
being added to the service.
installadm add-manifest [-d] -m <manifest_file> <svcname>
b) Set the property on the service, subsequent to the manifest
being added.
installadm set -p default-manifest=<name> <svcname>
>
> - 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.
If a manifest gets republished (i.e. we readd a manifest to a service
that already has that manifest name), we'll check if the criterion
for the already published manifest matches that of the one being
added. If they differ, ask user which one they want.
>
> - 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>
This will instead be:
installadm add-manifest -m <manifest_file> <svcnname>
>
>
> 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.
>
>
All of (3) is a lower priority than (1), (2), and (4).
The create-client command should take the imagepath as an optional
parameter, and use the imagepath associated with the install service
specified if its not given.
>
> 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
List all clients that have been specifically setup, and the
name of the install service and imagepath associated with it.
Don't list remote services unless specifically asked to. e.g.
installadm list -r
Other general comments:
----------------------
The create-service command could take a pointer to an AI image
over the internet and download it itself, instead of having a
step for the user to download it.
installadm create-service -s http://URL ...
The create-service command could automatically store the expanded
install image in a standard place like /export/ai/images, rather
than requiring an argument to specify where.
An AI install server could track the stats on the number of
installs its served.
For all of the installadm subcommands, the main operand shouldn't
need an option identifier. For example,
installadm list -n <svcname>
should be
installadm list <svcname>
