Jan Damborsky wrote: > Hi Sundar, > > Sundar Yamunachari wrote: >> jan damborsky wrote: >>> Hi Dave, >>> >>> >>> On 02/19/09 22:48, Dave Miner wrote: >>>> A couple of comments in-line: >>>> >>>> jan damborsky wrote: >>>>> Hi Sundar, >>>>> >>>>> I have been thinking about support for unicast DNS part (section 1.2) >>>>> and it seems we would need to provide option for specifying DNS >>>>> domain for unicast DNS, since DNS server might reside in different >>>>> domain than AI server, for instance >>>>> >>>>> # installadm create-service [-u domain] ... >>>>> >>>>> '-u' would be optional and its presence would determine if unicast >>>>> DNS is to be used. If not provided, unicast DNS wouldn't be taken >>>>> into account. >> Currently we find unused port numbers and start AI web server. When >> it comes to unicast, we should allow user to use the same well known >> port for the service. Otherwise preconfiguring or replicating same >> DNS entries difficult. I would like us to take port numbers to start >> web servers in the case of unicast setup. > > If you agree, then we might use optional '-p port' command line option > in order to provide user with a way to explicitly specify which port > should be picked up by the service. > > If not specified, port number for unicast DNS would be determined by > utilizing > the same algorithm which is used for for multicast DNS. > > In order to provide consistent user experience, we might allow this > to be used for both multicast as well as unicast DNS. I understand the desire to have consistency for unicast and multicast. What I am saying is that the default behavior is multicast if the user doesn't specify the option to setup multicast. The port number makes more sense for the user if the unicast is setup since the DNS records needs to be updated. In the case of multicast, the user doesn't care about the port since the user doesn't need to update anything. > >>>>> >>>>> I am then thinking if this API enhancement might be sufficient >>>>> for incoming release - additional options might not be needed >>>>> for now with respect to support for unicast DNS and introducing >>>>> fallback mechanism (when neither unicast nor multicast DNS is >>>>> available). >>>>> >>>>> Behavior of AI server and AI client might be following: >>>>> >>>>> AI server - installadm create-service >>>>> ------------------------------------- >>>>> >>>>> * if '-u domain' provided, create service with support for unicast >>>>> DNS, >>>>> display appropriate PTR & SRV records which need to be added to DNS >>>>> database >>>>> >>>>> * if multicast DNS available, register the service using multicast >>>>> DNS. >>>>> Otherwise inform user that multicast DNS feature is not avialable. >> I am assuming unicast and multicast setup is mutually exclusive. If >> the unicast option is given in 'create-service', then it will setup >> only unicast. > > Will we need to allow user to use both in some cases, > or will it be always mutually exclusive ? I don't know whether there is a use case for the user wanting to use unicast and multicast. > >>>>> >>>>> * add appropriate options specifying service location to >>>>> configuration >>>>> files (menu.lst, install.conf) for fallback mechanism >> This may be setup in both unicast and multicast options. > > Agreed. > >>>>> >>>>> AI client behavior during service discovery phase >>>>> ------------------------------------------------- >>>>> >>>>> * if service unicast DNS domain provided, look up service using >>>>> unicast DNS. DNS domain would be specified as another option in >>>>> configuration file (menu.lst or install.conf), not determined >>>>> from DHCP DNSdmain option, since this might be different, >>>>> something like >>>>> >>>>> install_service=_install_service_64501,install_service_domain=ai_caiman.org >>>>> >>>>> >>>>> >>>> >>>> It appears that you'd be forcing a domain to be specified and >>>> stored in the configuration file in all cases, which seems >>>> unnecessary; if the site wants to place the records in the standard >>>> domain, why shouldn't we use DNSdmain when an override is not >>>> supplied? >>> >>> That is a good point. If user doesn't specify domain (or specify >>> default), then >>> DNSdmain would be picked up: >>> >>> * default (pick up the one from DNSdmain): >>> install_service_domain=default >>> >>> * user specified >>> install_service_domain=ai-caiman.org. >>> >>> Presence of 'install_service_domain' option would let AI client >>> know that unicast DNS should be used. >>> In order to avoid potential confusion, trailing '.' would indicate >>> that install_service_domain contains DNS domain name. >>> >>>> >>>>> >>>>> * if searching using unicast DNS fails or DNS domain not provided, >>>>> try to look >>>>> up service using multicast DNS >>>>> >>>>> * if it fails, contact AI webserver directly using service location >>>>> provided, the option might be >>>>> >>>>> install_service_location=machine:port >>>>> >>>>> Since 'machine:port' is now generated by AI server when service is to >>>>> be created, I think it wouldn't be necessary to specify it on >>>>> command line. >> See the comments above. For muticast, we can generate a port number. >> For unicast, provide an option for the user to provide a port number. > > I think that we should provide user with consistent experienc. If we > allow > to explicitly specify port number for unicast DNS, I think it might be > expected > that the same is possible for multicast as well. > > And if it is supported to let AI decide automatically about port number > for multicast DNS, it might be desirable to support the same for unicast. I am okay with installadm tools generating port number for unicast. I don't know about asking port number for multicast since it is not used by the user. It is needed for internal use. > >>>>> >>>>> >>>>> Limitations: >>>>> ------------ >>>>> >>>>> * If unicast DNS is required, domain always has to be specified. If >>>>> it turns out to be inconvenience for this release, we might add >>>>> support for 'default' or 'current', like '-u default' >>>>> >>>> >>>> Why not "-u" without an argument? >>> >>> I would prefer this, but I saw message from Frank that >>> "option arguments should not be optional". >>> >>> Frank, could we declare <domain> in '-u <domain>' optional ? >>> Or would you recommend to work out some keyword for the case >>> when default should be picked up ? >>> >>>> >>>>> * AI server always tries to register service using multicast DNS. >>>>> I think this is a good default behavior, since it would be one >>>>> of fallback mechanisms, when unicast DNS is unavailable. I am >>>>> not sure, if there might be cases when this is not desired >>>>> >>>> >>>> I think a flag to disable multicast registration would be desirable >>>> for some administrators. It would also be useful in some test >>>> scenarios where you're trying not to interfere with an >>>> already-running infrastructure. >>> >>> You are right - then that sounds like a good >>> things to have. I am thinking about following >>> possibilities: >>> >>> >>> '-u <domain>' - unicast & multicast >>> '-U <domain>' - unicast only >>> >>> or >>> >>> '-u <domain> -m' - unicast & multicast >>> '-u <domain>' - unicast only >>> >>> or >>> >>> '-u <domain>' - unicast & multicast >>> '-u <domain> -M' - unicast only, multicast disabled >>> >>> or >> Can we treat unicast and muticast as mutually exclusive options? The >> fall back is to use files. Why setup both? > > I was thinking that multicast DNS might provide one more > level of fallback mechanism for unicast DNS. I am not sure > if this is something user would like to take advantage of > or expect to work. If this might be source of confusion then > I agree we should treat unicast and multicast as mutually > exclusive - at least for default behavior. > > We could initially implement this as mutually exclusive > which is more deterministic and if we see that people will > ask for modification, we could enhance it. That seems to be a right approach.
Thanks, Sundar > > Thank you, > Jan >
