Hi Dave,
On 04/16/09 17:15, Dave Miner wrote: > jan damborsky wrote: >> On 04/15/09 21:10, Dave Miner wrote: >>> jan damborsky wrote: >>>> On 04/15/09 18:21, Ethan Quach wrote: >>>>> Putting aside our opinion of its usefulness for a bit, I think a part >>>>> why we're here now is because this scenario is least worked properly >>>>> for x86. When sparc came along, we didn't reevaluate whether it >>>>> actually worked for sparc. >>>> I agree - in current implementation (based on how wanboot works and >>>> what >>>> it allows), that scenario can't be accomplished for Sparc. >>>> >>> It's not really a useful scenario, as seldom is a user in a >>> situation where they'll say "Hey, I don't care which of two >>> different possible installations gets applied to a particular >>> system". The useful scenario is one in which there is a default >>> installation that's used for standard systems, and then there are >>> other installation services which are used for specific exception >>> systems. The latter are what you'd use create-client for; the >>> former should just use the default service. >> >> Agreed. This is the scenario which I think we implicitly assumed to >> work before >> 8130 was reported. As you pointed out it defines two install service >> scopes >> or bindings: >> >> [1] per-client binding - explicitly established by 'create-client' >> - max one per client, total number not limited >> >> [2] 'default' - serving clients without per-client binding >> - only one is active at a time >> >> Right now, [1] works correctly for both x86 & Sparc. >> >> When investigating 8130, I have realized that [2] doesn't seem to work >> correctly neither for x86 nor for Sparc. >> >> Sparc is more problematic, since if more than one install service is >> created, >> mismatch between boot archive and compressed archives appears. This >> is what >> was initially assumed (when this discussion started) to be addressed >> by fix >> for 8130. >> >> When discussion was evolving, it seemed to appear that fixing 8130 in >> such >> a way that [1]+[2] continues to work is problematic and risky at this >> point. >> >> Then two approaches were suggested: >> >> * support only [1] for Sparc >> >> - it solves problem with mismatch, since mismatch only occurs for [2] >> - it is not acceptable >> >> * allow only one install service to be available at a time and >> use it as default - which is [2] >> >> - it seems to be too restrictive - only one install service for >> all Sparc clients >> - it doesn't solve mismatch problem >> >> If my understanding is correct, now we are back in situation when >> [1]+[2] is required to work ? >> >> Let me try to verify if I understand what problems we are trying to >> solve >> (and how) before I get completely lost :-) >> > > Thank you for ensuring we get the problem defined clearly. You are welcome. > >> [A] mismatch problem - tracked by bug 8130 >> ------------------------------------------ >> affects only Sparc AI client when it uses [2] >> >> Since it is caused by the fact that Sparc client obtains location >> of AI image pieces from two places, I think the solution (at least >> for now) would be to query one common source for obtaining >> location for both boot archive as well as solaris*.zlib archives. >> >> We can't do too much about boot archive stage at this point, >> so let's take a look at the stage when solaris*.zlib archives >> are obtained. >> >> Since full path to boot archive is defined by 'root_file' option >> in wanboot.conf file, if we have this info available in AI client, >> I think it would help to solve the problem. >> >> I was investigating what wanboot offers in this point and it seems >> we can easily obtain particular wanboot.conf. During wanboot process, >> wanboot.conf along with other files is bundled as HSFS filesystem >> and provided by kernel as /devices/ramdisk-bootfs:a block device >> (I finally realized what the wanbootfs file downloaded by client >> can be used for :-). >> >> Looking at how legacy installer makes it available, it is >> straightforward: >> ... >> BOOTFS_DISK="/devices/ramdisk-bootfs:a" >> >> if [ -b "$BOOTFS_DISK" ] ; then >> mount -r -F hsfs "$BOOTFS_DISK" /etc/netboot > /dev/null 2>&1 >> ... >> >> Then we have wanboot.conf available in /etc/netboot/ directory in >> microroot and we could determine location of solaris*.zlib archives >> by inspecting 'root_file' option - it is created by installadm(1M) >> in following format: >> >> root_file=<ai_image>/boot/boot_archive >> >> and solaris*.zlib archives are in >> >> <ai_image>/solaris*.zlib >> >> I haven't tried this yet, but it seems promising. >> > > Agreed, and it removes one item that's being configured in DHCP. Also, this will simplify things for Sparc, since RootPath is the only one which is service specific. Once removed, we don't need to create (take care of updating) service-specific macro for Sparc. Thinking about this, it would mean that Sparc AI images relying on this DHCP option would no longer work with new installadm(1M) tools. > >> >> [B] correctly working [2] scope >> ------------------------------- >> Assuming [A] is addressed, then [2] would work in following way: >> >> x86 - first created service has 'default' scope >> ----------------------------------------------- >> When local DHCP server is to be used, the first install service is >> created along with -i -c options and IP pool is associated with >> service-specific DHCP macro. Thus it is used as default, since >> client loads menu.lst file defined in service-specific macro. >> >> Any subsequent service (if created without -i -c) doesn't update IP pool >> by calling pntadm(1M) leaving the first service used as 'default'. >> >> Issues: >> - It is a little bit problematic to change the default service >> (e.g. delete old/create new), since appropriate IP pool has to be >> updated with new dhcp service-specific macro. This is now only done >> if '-i -c' options are provided and user has to know which IP pool >> is to be updated. >> >> - If default service is deleted, client is still served with menu.lst >> file referring to it, as IP pool is still associated with service >> specific DHCP macro. >> >> - First one is always set as a default - this could be addressed by >> explicitly specifying which one should be set by default (e.g. >> by providing '-d' option as suggested). >> > > One way to simplify this problem is to use the classic approach of > adding a level of indirection. In this case, we would not set each > client entry created by create-service in the per-network tables to > point to the service-specific macro, but instead point to a default > macro (for example "AI_default_service"); that macro would merely use > the Include pseudo-option to reference the correct default service > macro. This is how we've run the Jumpstart services in the Burlington > lab for many years, and it works well. Applies just as well here. This is a good point ! It should make updating macros for default service much more easier - thanks ! > >> >> Sparc - last created service has 'default' scope >> ------------------------------------------------ >> The reason is that each time new service is created, >> /etc/netboot/wanboot.conf is updated. Specifying -i -c doesn't >> affect this behavior, since DHCP server would be queried only for >> network info (client IP, server IP, ...) and boot file (which is >> wanboot-cgi common for all clients). Once [A] is fixed, 'RootPath' >> option would be no longer utilized. >> >> Issues: >> - Last one is always set as default - this could be addressed by >> explicitly specifying which one should be set by default (e.g. >> by providing '-d' option as suggested). >> >> I think we would need to clarify >> * desired behavior for [2] along with corner cases and possible states >> * what is appropriate/desirable to address for the current release >> > > This scenario is *very* common and is one I believe needs to be > working properly for AI to be useful in most environments. I have no objections in general, I am a little bit concerned with respect to possible amount of work involved and given time constraints. Thanks a lot for your comments ! Jan
