Karen Tung wrote: > 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?
Correct. >> >>> 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? manifest-import script is responsible for many tasks but only carry out necessary operations. The operations that consume time are those making changes to repository and in your case is minimal as there's no import or cleanup. That said, instead of dummy out the start method, we can put the profile application section into a function and add an option to manifest-import script to run only that function. During the liveCD construction process would modify the start method to invoke manifest-import with the new option. Others may have additional ideas. -tony
