On 03/05/12 04:44, Darren Kenny wrote:
On 03/03/2012 01:47, Ethan Quach wrote:
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.
Unfortunately the size of a domain is very much something that could vary
by customer, even by department or floor within the same company, possibly
even in the same building.
I would agree that supporting a domainname criteria would be an alternative
solution, but until that exists, maybe we shouldn't cripple what we do have
right now?
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?
If the name we got from the client was the FQHN, then I think that m3 would
be the only match here - but that will depend on how we implement it.
If we do support weighting, then we could weight the hostname match
depending on the level of match - i.e. FQHN best match, x.us, next best,
and x the weakest...
I'm definitely not in favor of the fix sent for review, stripping names
is not a good idea as it can lead to incorrect results in
highly-centralized infrastructures that happen to have duplicate
hostnames across different domains. As a result, using fully-qualified
names really should be preferred.
I'm somewhat unconvinced we should do anything at all here. The user
should know what hostname is being supplied to clients, whether it's the
fully-qualified or not, and configure appropriately. What is wrong with
that?
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
