>
> Sundar Yamunachari wrote:
>>>
>>> 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?
>
> Since we're storing the manifest configurations internally, I think
> that could make a lot of sense. The association of a manifest to
> criteria seems a bit rigid in that once a manifest is published with
> whatever criteria it was published with, that can't ever change.
> If I wanted to use some already published manifest for another
> client, I can't do that right now.
Right now, I think of manifests as a free standing entity with criteria
sets attached to it. If one uses 'installadm list -n svc -c' they see this
bourne out more (or go to http:/ai-server:4650[123...] and look at the
output there, ensure you have a manifest which has multiple criteria
sets added to it)[1]. Perhaps this is not the right method of vision,
however.
[1]: Example of one manifest with two criteria sets:
root at opensolaris:/# installadm list -n service -c
Manifest Instance arch mem
------------------------------
Bob1.xml:
0 sun4u -
-
1 sun4v 1024
-
Here Bob1.xml is served for a machine with a sun4u processor or sun4v and
at least 1024MB of RAM.
>>> - 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
>
> To me, that's functionally the same thing. I think the question
> here is whether or not we think the "default" setting should be
> part of the criteria or its own special element. I'm okay with
> keeping it separate from the criterion, but it definitely shouldn't
> be based on the name.
I'd prefer to have an XML default tag and not have a manifest name for
default manifests (this affects publish-manifest and the AI schema but
shouldn't be hard to achieve).
>>> - 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.
>>>
Returning the manifest (without criteria) should be very easy, or
returning the manifest with a specific criteria set (i.e. set 0, 1, 2...)
but we would have to think up an XML schema to have multiple criteria sets
in one manifest to return a manifest with all of its criteria sets
(perhaps we should!).
>>> - 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.
>
> I'm a bit leery about 4322. It seems more like the submittor's
> attachment to how the old Jumpstart used to work rather than
> something useful. Jumpstart configuration is just a bunch of
> pointers, so keeping track of and neatly organizing the profile
> files was a necessity. However, with AI, the configuration is
> stored internally, so there's no required correlation between
> the configuration and the file once its publish as a manifest,
> other than the user's own knowledge of that.
>
> I think the real "want" here is the ease of correlation between
> a published manifest and its contents, but that's what exporting
> a manifest to file is for.
I like this as a better answer to an awkward shim between an arbitrary
file name and what the "manifest name" is in the XML.
>>> - 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.
>>>
The current way of storing an SC manifest in the composite manifest is a
hokey shim (a comment containing a different type of XML is wrong! But
how to combine a DTD defined XML and schema defined XML?).
I would like to see criteria define which manifest and SC manifest to use
independently. Then, one can perhaps install the same subset of software
on a machine (defined in the manifest) but with a different login/password
(an item in the SC manifest and thinking of single purpose user desktops
or something odd).
Thank you,
Clay
>>>
>>> 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.
>
> It seems to me there already is a 1-1 relationship between a service
> and the default image it serves up. But currently, a client can be told
> to install from some different image during a client-specific setup
> (the "create-client") and then use the same service to get its manifest,
> but that's not the same as saying the "service" serving up multiple
> images.
>
> In addition, I think we're relying on the implementation of grub
> to allow our client-specific setups to specify random other images.
> I guess that could be fine but something to be really aware of.
> If we do want our usage model to allow client-specific setups to
> use any random image, we need to build some additional
> subcommands to administer the images.
>
>
> thanks,
> -ethan
>
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>
