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. > I agree that we need to make all install services along with web servers as SMF services. Instead of thinking of starting or stopping web servers, we need to think about starting and stopping install services, which includes DNS services and web servers. > > > 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. > Right now the only manifest allowed with out criteria is the default manifest. If we allow manifests written with out criteria, then we need an external mechanism to tie manifests with criteria. Do you envision whether a manifest with out criteria served to client? Do you want to use the service as a manifest store to keep manifests with out criteria for future use? > - 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. > I see your point but I am not sure that having a special criteria that says some thing is default is the right thing to do. We could have a command-line option to make a manifest as default > - 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> > This problem is due to the way we implemented this feature in November. The file names used for manifests are saved any where and the manifests are saved with the name specified inside the manifest. Unless the file name and the field name are same, this is a problem. Bug 4322 is created to track this issue. > > And while we're on nits, "add" and "remove" seem like they could > be more specifically named to be "add-manifest" and > "remove-manifest" > okay.
> - 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> ... > The design allows sharing install services between images. Unless we make a strict 1-1 relationship between an image and a service, cloning a service is that useful. > > 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. > This is a good enhancement and is part of the roadmap for AI. > > > 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 > These are good enhancements. We already do some of them. I will add them to the list of tasks. Thanks, Sundar > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >
