On 03/02/12 00:16, Darren Kenny wrote:
On 02/03/2012 06:58, Nirmal Agarwal wrote:
Hi Jesse, Darren
Thanks for the comments.
On 3/2/2012 1:06 AM, Jesse Butler wrote:
On Mar 1, 2012, at 12:47 PM, Darren Kenny wrote:
Hi Nirmal,
Some quick comments:
- The bug synopsis - could it be changed to be what the bug really is, as
it reads now it suggests it *should* be FQDN, but the fix is stripping
the domainname.
I agree. It took me a bit to sort out exactly what the bug was here.
I will fix the bug synopsis.
Thanks.
- I'm not totally sure that we should be stripping the domainname all the
time. Maybe if the hostname is not qualified in the criteria, then we
should be stripping the value from the client. But I feel that if the
criteria was set with a FQDN then it really should be used I think.
e.g.
Criteria: hostname = mymachine
Should match: mymachine
mymachine.us
mymachine.us.oracle.com
While
Criteria: hostname = mymachine.us
Should match: mymachine.us
mymachine.us.oracle.com
and finally
Criteria: hostname = mymachine.us.oracle.com
Should match: mymachine.us.oracle.com
i.e. if the user specifies a specific value, we should try to match
it as much as is feasible - more like what the 'host' or 'nslookup'
commands would do here.
What do other people think?
Initially, this was how we thought the bug could be fixed as well, and I
don't recall the exact reasons why we decided not to do it this way but
I think it was pretty much for simplicity, and knowing that if we really
did needed to support domainname, that should just be its own separate
criteria so that things are more predictable (as far as what gets
returned as the HOSTNAME for a booting install client) and easier for
the user to understand.
We control the client side so it really seemed like a pretty simple
solution for us to just dictate what gets returned. Why deal with the
variability?
In addition, if/when we ever did support a domainname criteria, that
could actually be useful on its own to map a class of clients in the
same domain to a manifest.
In the above scenario if I have criteria's for 3 manifest as below :
Criteria for manifest 'm1' : hostname = mymachine
Criteria for manifest 'm2' : hostname = mymachine.us
Criteria for manifest 'm3' : hostname = mymachine.us.oracle.com
client hostname is "mymachine.us.oracle" , we should try and match the
longest string match. So applying the same in the example client will
get manifest "m3" ?
Is my understanding correct ?
Yes, that would be my expectation.
What happens when there are multiple criteria associated with m1, m2, or
m3? e.g.
Criteria for manifest 'm1' : hostname = mymachine
mem = 1024 - 8196
Criteria for manifest 'm2' : hostname = mymachine.us
Criteria for manifest 'm3' : hostname = mymachine.us.oracle.com
platform = i386
When more than one manifest matches, we currently go through a process
of weighting the manifests that match based on which criteria matched
(and I *think* how many criteria matched.) For this case, would 'm1'
and 'm2' be completely ruled out in the first place because of the
longer FQHN match from 'm3' exists, or should 'm1' and 'm2' still in
contention? What if 'm3's other criteria didn't match?
-ethan
Thanks,
Darren.
Regards
Nirmal
I agree that we should match the level of qualification set in the criteria,
not just strip it to none every time. Unless there is something I'm missing,
I'd suggest moving toward this solution.
/jb
Thanks,
Darren.
On 01/03/2012 15:02, Nirmal Agarwal wrote:
Hi all
Could I please get a code review for the following CR:
7098861 hostname criteria must be fully qualified when adding a profile
via installadm
Webrev :
https://cr.opensolaris.org/action/browse/caiman/nirmal27/7098861
-- Source is pep8 clean.
slim_test result
/net/indiana-build.us.oracle.com//export/home/na210770/ai/7098861
/slim-test
Manual Tests Result :
/net/indiana-build.us.oracle.com//export/home/na210770/ai/7098861
/Manual-Test
Thanks
Nirmal
_______________________________________________
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
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
