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.
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). > 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? cheers, tony
