Hi John,
thank you for fixing fallback mechanism.
I reviewed manifest-locator script and I have just a nit:
161 print "Service $AI_SERVICE_NAME located at $AI_SERVICE_ADDRESS
will" \
162 "be used" | \
163 $TEE_LOGTOCONSOLE
->
161 print "Service $AI_SERVICE_NAME located at $AI_SERVICE_ADDRESS
will" \
162 "be used" | $TEE_LOGTOCONSOLE
Other than that it looks good to me.
Thank you,
Jan
On 02/18/11 07:28 PM, John Fischer wrote:
All,
A new webrev has been posted for this issue. It is located at:
http://cr.opensolaris.org/~johnfisc/7019724-aimdns-2/
http://cr.opensolaris.org/~johnfisc/7019724-aimdns-diff-2/
Again, the CR is 7019724:
http://monaco.sfbay.sun.com/detail.jsf?cr=7019724
I have modified how I am doing the code by establishing
default values for exclude_networks and networks
(false, 0.0.0.0/0 -- respectively). I have also added another
flag to handle the register case to truly initialize these
to what is in the SMF service. If the key/value properties
are not within the SMF service then we should exit abnormally
in the register case as the code will do. Using the default
values is reasonable for the browse and find case as we
want to find as many services as possible and does not
effect multihomed.
I have also added the necessary changes to the manifest-locator
code that was missing from the original AI webserver project.
I have tested this by creating a new AI install image that does
not contain the installadm package but has the /var/run work
around for a different AI install image issue. The client is able
to obtain the correct manifest.
Finally, as Keith pointed out the AImDNS class should be broken
into 2 distinct classes with one being used for the client and
the other for the server. This is not being done at this point
in time.
Thanks,
John
On 02/15/11 03:02 PM, John Fischer wrote:
All,
Here is a webrev for CR 7019724:
http://monaco.sfbay.sun.com/detail.jsf?cr=7019724
The webrev is located at:
http://monaco.sfbay.sun.com/detail.jsf?cr=7019724
During tests of the webserver project the clients contained the
installadm package and thus had access to the install/server SMF
service information. So what happened is when the webserver package
bug (CR 7018370) removed a dependency on installadm the
client no longer had access to the install/server SMF service
information.
This meant that the client would try to get the all_services properties
and fail. Thus the install would stop. However, the client does not
need to have those properties. So the solution is to move the
initialization
of the properties into the register portion of the code which is done on
the server side of the house that has access to the appropriate
install/server SMF service information.
Thanks,
John
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
