Hi Sarah,
On Mon, 14 Jun 2010, Sarah Jelinek wrote:
- Is there a substitute for the (current) resume_from attribute
under the checkpoint_enable tag?
No, there isn't. Since we enable checkpoints by default now the resume from
seems unnecessary. The user can specify it on the command line. Can you think
of a use case where this might still be desirable?
Actually I can't think of a reason that it might
still be desirable. A user can just as easily do
the equivalent thing from the command line.
I asked just to be sure that it wasn't overlooked
in the design.
- Where is the smf_service_profile information for the boot_archive
captured?
Good question :-). I do have an smf profile allowed for in the DC dtd, but
not specifically attached to the boot archive. Let me look at this and see
what needs to be done here. I missed this.
he
post_install_repo, in which section of the instance document
would that be done?
dc_spec section. It is an attribute on dc_spec element. They are not
required, but the dc.xml document I set this attribute. Am I missing
something with regard to how this needs to be specified?
Ah, I see it in the schema. It was missing from the instance
document example and that threw me off.
- For Section 7.4, which of these two approaches are you leaning
towards?
I think a combination of both. In some cases the validation is the same
between consumers, such as validating something is an int(non-negative) or
that the install repo is available. In some cases the validation might be
different where I think applying the consumer specific hooks. What are your
thoughts on this?
I would actually prefer the latter approach where
the hooks are provided in the manifest itself. Just
seems like a more extensible way of doing things.
If you've got a change to the how a specific field is
validated, simply update the manifest to reflect that
and the validation will work -- no need to change the
client app itself.
Thanks,
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
