John,
Looks good to me now.
thanks,
-ethan
On 03/24/11 15:03, John Fischer wrote:
Ethan,
Thanks. I have updated the webrev at:
http://cr.opensolaris.org/~johnfisc/7025817-ai_sd.1/
http://cr.opensolaris.org/~johnfisc/7025817-ai_sd.diff-1/
Let me know if this looks good.
Thanks,
John
On 03/24/11 02:30 PM, Ethan Quach wrote:
On 03/23/11 16:43, John Fischer wrote:
Ethan,
Thanks for taking the time to review this change.
See below. Let me know if this addresses your
questions or if you want me to make an additional
change.
Thanks,
John
On 03/22/11 06:15 PM, Ethan Quach wrote:
102 - I know you didn't change this line of code per this bugfix,
but would it be possible that the one interface that the client
brought up isn't the first one in the list?
As you know the client will only have a single interface so the
original code simply
assumed the first interface. The interface dictionary is loaded by
the getifaddrs
function within libaimdns. For example,
>>> import osol_install.libaimdns as lib
>>> lib.getifaddrs()
{'e1000g0': '10.132.149.118/23'}
>>>
getifaddrs only returns active interfaces. Thus using the
first_interface from
getifaddrs() will always yield the configured interface for the client.
105 - Since this is never a browse anymore, would we ever be
getting more than one service returned from the find ?
It should always return the found service. Thus the comment:
103 # Use the first service within the interface's service list.
104 # Find will have exactly 1 service.
I suppose that I could remove the comment on line 103 if that would
make things more
clear.
That would help. And what do you think about changing the variable
name to just 'service' ?
thanks,
-ethan
On 03/22/11 08:48, John Fischer wrote:
All,
Please review the following webrev:
http://cr.opensolaris.org/~johnfisc/7025817-ai_sd/index.html
It resolves:
http://monaco.us.oracle.com/detail.jsf?cr=7025817
OR
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=7025817
The failure occurs because the lookup method in the AIservice class
within ai_sd.py special cases the _default service name. The
special case
was added during the webserver design project and a misunderstanding
on how the find_manifest mechanism works on the client side. The
special
case did a simple browse and assumed that the first service
returned was
fine. The only problem is that the first service could be x86 or
SPARC and
thus potentially have the wrong architecture as well as it would
not match
the service which is already providing information.
The solution is to not special case the _default service and allow
the fall back
mechanism within the find_manifest client side script to use the
grub menu
values for host, service name and port values.
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
