Hi Tony, Thanks for your suggestions. Please see some follow up questions I have inline.
Tony Nguyen wrote: > Hi Karen, > > Karen Tung wrote: >> We are working on improving a script that's currently used >> by the Distribution Constructor to pre-import SMF services >> and applying SMF profiles in the root archive >> during the process of constructing the LiveCD. This is done >> to optimize the boot performance. >> >> The script we are using now, mkrepo, is actually a hacked together >> script based on the manifest-import S >> MF service start method. >> We removed most of the functionality except searching for all manifests, >> loading of the manifests and applying the profiles. >> For reference, here's the script we use right now: >> http://src.opensolaris.org/source/xref/caiman/slim_source/usr/src/cmd/distro_const/utils/mkrepo >> >> >> >> The ultimate goal is to get rid of our own script, >> because we don't want to maintain our version of something that already >> exists else where. >> The following thread is the latest discussion. I have some suggestions >> on what need to be done in there. >> http://www.opensolaris.org/jive/thread.jspa?threadID=107033&tstart=0 >> >> The following is the bug we filed to track this work. It has all the >> discussion >> we had on this. >> http://defect.opensolaris.org/bz/show_bug.cgi?id=5209 >> >> From the Distribution Constructor(DC) point of view, the following >> features are needed: >> >> 1) Find all the manifests in the alternate root, and pre-import all >> the manifest we found. >> 2) Apply profiles to the alternate root's SMF repository. In >> addition to the various >> profiles the manifest-import script normally applies in first boot, >> DC also needs to >> be able to apply 1 or more user provided SMF profiles. These will be >> applied after all >> the "standard" ones are applied. >> 3) Manifest-import script determines at boot time which platform the >> machine is >> running on, and creates the appropriate link for the platform.xml >> profile, before >> applying it. Since the machine on which DC runs is not the one that >> will be used for >> running image produced, creating the link during image construction >> time is wrong. >> This needs to be done during first boot of the LiveCD/AI image. >> >> If the current manifest-import script is updated such that all the code >> for doing manifest search/import and applying profile are put into >> functions in some sort of library delivered by the SMF group, items >> 1+2 should be >> easily done. Is this possible? >> > While I agree manifest-import script can be better factored, I'm not > convinced coding reuse in this case is the right choice. With the > exception of setting the alternate repository, the tasks of > importing/applying are quite common that I don't see much benefit in > sharing code with manifest-import. The current manifest-import > performs many non-generic tasks and may get more complex in the > future. Code sharing in this case may make it hard for both Install > and SMF to make changes. Understood. > > That said, as part of Early Manifest Import project, we plan to > integrate support for svccfg to import all manifests in a given > directory. This would potentially make import operation your script a > two line code (setting SVCCFG_REPOSITORY and run svccfg import -d). This will certainly make things simple, and it achieves our goal of not sharing code. Just want to make sure I understand correctly. When I run "svccfg import -d", only the manifests will get imported. For the profiles that need to be applied, our code will have to do that, right? > >> We are not sure what to do with item 3. In the discussion thread >> above, I mentioned we >> can do this as a special case in one of the LiveCD/AI boot up SMF >> script. >> Is there a better way to do it? > Is it possible to leave the symlink creation to manifest-import? I > can't imagine a significant performance issue with generating a single > symlink? > The Live CD does not run manifest-import at all at boot time. At the time when the Live CD is constructed, we dummy out the start method for the manifest-import script so it won't run when the Live CD boots up. If we were to enable running this script at boot up, I assume it will not just create that one single symlink and apply the platform.xml profile. It will probably do many things too. Is that a correct assumption? If so, we really can't run manifest-import at LiveCD start up. Any other suggestions? Thanks, --Karen > cheers, > tony
