On 07/23/10 07:37 PM, Alok Aggarwal wrote:
Some more updates have been made to the design
document:
. Separate transfer-ips into transfer-ips-install
and transfer-ips-uninstall
. Added TI API calls to ba-arch
. Replace 'exec_method name' with 'checkpoint_class'
to better align with the current schema spec
. Add details about referencing DOC elements in user
checkpoints
. Added warning to console/logs for version incompatibilities
The document can be found here -
http://src.opensolaris.org/source/xref/caiman/caiman-docs/distro_constructor/dc_cud_design.pdf
Please review and provide feedback by July 27.
Apologies for being tardy on this, but you requested my feedback on the
RBAC portion, and there are a few other nits I noticed along the way:
2.2: create_usb would work fine on SPARC if usbgen did, perhaps rephrase
so that it's clear that usbgen is the piece that doesn't support SPARC.
2.2 s/local zone/non-global zone/
3.1, page 9: The paragraph beginning with "The engine executes the
checkpoints in order. First, the IPS..." Perhaps preface the IPS
reference with "In the typical usage" or something like this, as the
current phrasing implies that it's always this way, when in reality DC
could build something completely different that didn't involve any of
the listed steps that comprise the rest of this paragraph. As an
example, building the repo ISO's could be a DC process that would
involve a very different set of steps.
page 14, final paragraph: s/two/three/
3.6: checkpointing allows stop and restart at defined points of the
construction process, not "any", which could be taken to imply finer
granularity than is possible
3.9: would be good to note the reason for the gnome exception since this
has been unclear to some readers
3.12: you should specify a name for the new profile ("Distribution
Construction"?). ZFS FS management and Device Security are profiles,
not privileges. The references to requirements for executing lofiadm
and chroot could be more specific. Anyone can run lofiadm, though
usually the device permissions allow only query, not modification, of
the mappings by ordinary users, so I'm not sure exactly what to say
here. chroot does appear to require a specific privilege, proc_chroot.
3.13.3: If we have a CR number for the SMF work, would be good to
reference it here.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
