Thank you, John.
I _think_ that following change in manifest-locator could
take care of it:
print "$AI_SERVICE_ADDRESS" > $AI_SERVICE_LIST
->
print "${AI_SERVICE_ADDRESS}:${AI_SERVICE_NAME}" > $AI_SERVICE_LIST
I haven't tested that, though.
Jan
On 02/16/11 07:53 PM, John Fischer wrote:
Jan,
Thank you for this additional information. I will rework the fix
based upon this information
and the fact that we have some additional time as there is a work
around for the issue.
Thanks,
John
On 02/16/11 02:28 AM, Jan Damborsky wrote:
Hi John,
I have a questions not related to proposed fix itself, but related
to that CR, I believe.
There are two service discovery mechanisms currently used on AI client:
* mDNS
* fallback mechanism
Fallback mechanism is used if mDNS one fails. It obtains service
provider
from install_svc_address property.
Looking at bug report, it seems like AI didn't succeed to obtain
manifest at all,
so I assume that both mechanisms failed. Proposed fix seems to address
mDNS part of the problem.
I have taken a quick look at what might went wrong with fallback
mechanism
and it seems there is a discrepancy between what manifest-locator puts
into /tmp/service_list.$$ and what ai_get_manifest expects.
manifest-locator populates /tmp/service_list.$$ with 'IP:port'
(provided via install_svc_address) while ai_get_manifest now seems to
expect
'IP:port:service':
# echo "192.168.100.10:5555" > /tmp/svc
# ai_get_manifest -s /tmp/svc -o /tmp/m.xml
Traceback (most recent call last):
File "/usr/bin/ai_get_manifest", line 939, in <module>
RET_CODE = main()
File "/usr/bin/ai_get_manifest", line 932, in main
return(parse_cli(sys.argv))
File "/usr/bin/ai_get_manifest", line 858, in parse_cli
(ai_service, ai_port, ai_name) = service.split(':')
ValueError: need more than 2 values to unpack
# echo "192.168.100.10:5555:x-7012389-158" > /tmp/svc
# ai_get_manifest -s /tmp/svc -o /tmp/m.xml ; echo $?
0
#
I believe that should be fixed as well (assuming fallback mechanism
still matters).
Thank you,
Jan
On 02/16/11 12:02 AM, 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
