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... Thanks, Darren. _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
