Hi Dave,
Thanks for the review.
On Fri, 9 Jul 2010, Dave Miner wrote:
Alok, good start at this. Some comments below that I don't think duplicate
issues already raised by others:
On 07/ 7/10 06:52 PM, Alok Aggarwal wrote:
I have posted the first version of the DC re-design
spec. The section on VMC is still TBD pending implementation details
that are being worked out.
The document can be found here (Thanks, Dave) -
http://src.opensolaris.org/source/xref/caiman/caiman-docs/distro_constructor/dc_cud_design.pdf
1.1 You might note that the CUD is derived to a great extent from the
existing DC design and lessons learned from its usage.
I'll add it.
3.5.3: I found the choice of a separate set_ips_attributes checkpoint
surprising; why this rather than the application doing this directly? Also,
should we retain this, a nit: it's "two checkpoints" not "two sets of
checkpoints".
The reasons for this are two fold -
a) Recently a user reported, as part of his development and testing,
that he'd like to quickly add his "test" packages to the package image
area without having to re-run the "im-pop" step or write a finalizer
script to do the same.
He couldn't easily do that with our current DC because as part of
"im-pop" not only do we pull the packages listed in the manifest but
we also set ips attributes such as post_install_publishers, etc. So,
if you rollback to "im-pop" and want to add your test packages, you
can't do so easily unless you reset the publishers, etc by hand.
If we break im-pop into two checkpoints, a transfer and a
set_ips_attributes, we can enable this fairly easily.
b) The Transfer module allows for setting IPS attributes and it
does it correctly by using the pkg(1) APIs. It seems redundant
for the application (DC in this case) to have to learn those
APIs unless it needs to.
3.5.4: The consolidation here seems sensible, but an (primarily
implementation) issue to consider is how to make the checkpoints robust.
Right now the live CD-specific checkpoint has an implicit dependency on
GNOME, and further dependencies on a lot of implementation details of the
particular GNOME version. At a high level I'd like to see it made more
robust, through interfaces from GNOME and probably some simple validation by
the checkpoint itself, so that these become less problematic going forward.
We're going to do two things wrt isolating the dependency on
gnome.
a) Per the offline discussions we've been having with the desktop
folks, we're going to remove the hardcoded list of gnome caches
to generate. This will be replaced by a search for all such
services that match application/desktop-cache and invoking their
respective service methods.
So, as the list of caches change, we should be able to pick up
the changes automatically.
b) The LiveCD specific checkpoint is going to be structured such
that the gnome customizations are isolated in a separate method.
This will allow for better maintainability going forward.
Do you think this would be adequate?
I'll add the above to the document.
3.5.8: Here you seem to have made the opposite choice from 3.5.3 that I
mentioned above. Could use some explanation why they're different.
Currently, boot_archive_archive does both the sizing
computations as well as instantiating the ramdisk target.
Since, the new TI module is going to pick up the burden
of doing boot_archive sizing computations, it made sense
to see if boot_archive_archive could be refactored.
To that end, it made sense to abstract out the ramdisk
instantiation and the rest of the archiving process into
two checkpoints - boot_archive_instantiate and boot_archive_archive.
3.5.11: In some cases you have subclasses executing parent class's execute()
first (e.g. 3.5.6), in other cases (here) it's second. I think this has
potential for confusion for both users and developers, so I'd suggest
establishing a convention to make this consistent.
I'll look into making this consistent.
3.5.14: Any change to usbgen?
No changes to usbgen or usbcopy. I'll make a mention
of that in 2.2
3.7: Overall, I support the approach taken but I do have a nagging concern
about raising the requirements for plugging into DC. I think it would be
nice for users to be able to drop in custom scripts without having to write
Python or get heavily educated in how the engine & DOC work. I'm wondering
if we could provide a fairly simple "CustomScript" generic checkpoint that
could be easily added to a manifest and that would provide simple bridge
logic to retrieve items from the DOC into environment variables, execute a
named script, and report results back. Any thoughts?
I've been thinking about it some more since Darren also
pointed this out.
I think it would be easy to provide a generic checkpoint
that implements the checkpoint interfaces. The execute
method for that checkpoint would -
a) Pull out the values that have a high probability of being
used out of the DOC and stick it in a self.* variables.
For example: pkg image area path, ba_build path, tmp_dir
path, etc.
b) Have the following dummy code -
cmd = ["/usr/bin/myscript" + " " + self.pkg_img + " " + self.ba_build .. ]
subprocess.check_call(cmd)
A 3rd party would then just need to replace '/usr/bin/myscript'
with their script and provide the necessary arguments.
How does that sound?
3.12: I'd expect next version of the spec to be specific about the RBAC
configuration that will be supplied.
Sure.
Thanks,
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
