Hi Jason,
On 03/16/09 14:49, Jason Zhao wrote: > jan damborsky ??: > >> Hi Jason, >> >> >> On 03/16/09 04:06, Jason Zhao wrote: >> >> >>> Hi, Sundar and Jan, >>> >>> I am preparing the the test of AI DNS discovery >>> solutions. From the AI design documents and >>> discussion of caiman-disuss mail list, I know for >>> 2009.06 release, multicast and config file solution >>> will work together for DNS discovery. >>> >>> Here are some possible cases in order to test >>> DNS solutions, please tell me your idea. Thanks! >>> >>> On AI server side: >>> ---------------------------------------------- >>> 1. After "create-service", the DNS message will be >>> registered on AI server, which enable AI client >>> make DNS multicast query on the same subnet. So >>> that, it requires to check if dns-sd register >>> value right or not. >>> E.G., >>> After >>> # installadm create-server -s <iso> </image/path> >>> >>> >>> >> just a nit: >> >> installadm create-server >> -> >> installadm create-service >> >> > Oops... That is a typo. > > > Thank you for point it out! :) > >> >> >>> it register the following process: >>> "dns-sd -R <service> <type> <domain> <port> <key=val>" >>> >>> To test, on server side, run >>> "dns-sd -L <service> <type> <domain>" >>> command to get AI server and socket information, >>> then verify its correctness. >>> >>> >>> >> That sounds good - you also need to verify that TXT record reported >> by 'dns-sd -L' points to the right location (your AI server under test), >> since 'dns-sd -L' looks up given service on whole local subnet. >> >> Also, the same check you describe below (setting install_svc_address) >> should be done here, since when install service is created, menu.lst >> (for x86) and install.conf (for Sparc) are populated with >> install_svc_address option as well. In this case, you need to take >> a look at following files >> >> x86: >> /tftpboot/menu.lst.<install_service> >> >> Sparc: >> </image/path>/install.conf >> >> > Right, on server side, it requires to check both files! > >> >> >>> 2. For individual AI client, when it is not in >>> the same subnet with AI server. >>> >>> >> Let me clarify a bit - install_svc_address option is set in all cases, >> as there is no check if AI client is on the same subnet as AI server. >> >> > OK. > > Is it possible that "install_svc_address" contains wrong AI information > while dns-sd could find correct one, or vice versa? > It is not impossible, but unlikely at this moment. When install service is created, dns-sd as well as install_svc_address always point to the same location, since they use the same approach to determine the service location (host address and port). We might encounter this problem in future, e.g. If/when the possibility to relocate service to other machine is introduced. > could get correct AI information > >> >> >>> It requires to >>> check "menu.lst(X86)" and "install.conf(SPARC)" >>> after "installadm create-client" for individual >>> AI client. >>> E.G., >>> >>> # installadm create-client -e <mac> -n <service> >>> >>> >>> >> As far as I am aware of, <image_path> is also mandatory, so >> you will need to invoke installadm command in following way: >> >> # installadm create-client -e <mac> -n <service> -t <image_path> >> >> >> > Thanks! > >> >> >>> check if menu.lst(X86) or install.conf(SPARC) >>> contains "install_svc_address" item with correct >>> AI Server IP address and socket information. >>> >>> >>> >> Yes, those files can be found at following locations: >> >> x86: >> /tftpboot/menu.lst.01<mac> >> >> sparc: >> <image_path>/install.conf >> >> > Thank you. > >> >> >>> For above 2 cases, To verify correct AI server >>> and socket, it requires to access http://AI_Server:Socket >>> to make sure its correctness. >>> >>> >>> >> Correct. >> >> >> >>> On AI client side: >>> ---------------------------------------------- >>> On AI client side, to make sure AI clients are >>> able to find correct AI server and its socket, >>> the following verifications will do on AI client >>> after it boots up from AI image. >>> >>> 1. Run DNS multicast to find: >>> "dns-sd -L <service> <type> <domain>" >>> >>> 2. In case that DNS multicast fails, download >>> menu.lst.<mac> file or install.conf from AI server >>> to verify if AI client receive correct value. >>> >>> Frankly, at first, I thought it was necessary to do >>> above 2 verifications on AI client side, but now, I >>> find it may not be required, because item 1# has >>> already been verified during AI installation. As for >>> item 2#, if client receives wrong menu.lst or install.conf, >>> it is always network issue or configuration error on server >>> side and could be covered by AI server test cases. The >>> situation that AI client receives correct menu.lst >>> but intepretes it into wrong value is impossible, because >>> it means the devfs on kernel space is ruined. >>> >>> >>> >> Thinking about this, as far as this part of service discovery is concerned, >> what you might need to take a look at is if correct service name and >> correct service location was provided to AI client. >> >> For this check, it could be sufficient to take a look at install_service >> and install_svc_address options applying the same mechanism AI client >> uses: >> >> x86: >> # /usr/sbin/prtconf -v /devices | /usr/bin/sed -n >> '/install_service/{;n;p;}' | /usr/bin/cut -f 2 -d \' >> # /usr/sbin/prtconf -v /devices | /usr/bin/sed -n >> '/install_svc_address/{;n;p;}' | /usr/bin/cut -f 2 -d \' >> >> Sparc: >> # /usr/bin/grep "^install_service" /tmp/install.conf | /usr/bin/cut >> -d'=' -f2 >> # /usr/bin/grep "^install_svc_address" /tmp/install.conf | /usr/bin/cut >> -d'=' -f2` >> >> If you would like to verify if service discovery itself works, you could >> use either >> 'dns-sd -L' command you mention above or /usr/bin/ai_sd Python script >> available in AI image (please see usr/src/cmd/auto-install/README.test file >> for details). >> >> > Thank you for your detailed instructions, Jan. > > I am thinking about if it is required to do verification on AI client side. > Because once client did wrong behavior (i.e., try to visit wrong > http://AI_server:socket), > in most cases it is because on AI server, it generates wrong menu.lst or > install.conf > and the error could be checked on AI server side. In this way, tests or > AI client > side may not be required from testing DNS discovery points of view. > > Could you tell me your opinion about it? > It depends on what you would like to test. If the intent here is to make sure that whole chain works correctly, you might need to involve AI client as well, e.g. in order to make sure that correct menu.lst (or install.conf) is obtained. As client side of service discovery is straightforward for now, I agree with you that most of the time the problem would be located on server side, but I think that some kind of misconfiguration wouldn't be found without involving AI client in whole process. Thank you, Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20090317/67598fd4/attachment.html>
