http://defect.opensolaris.org/bz/show_bug.cgi?id=14263
--- Comment #6 from Anurag S. Maskey <Anurag.Maskey at Sun.COM> 2010-02-03 15:39:03 UTC --- (In reply to comment #5) > So if I understand the problem - we want to trigger conditon checking when ENM > and location states change, but in order to do effective condition checking we > need to ensure that the location has been applied. Because we can get flurries > of refreshes, we can't easily place an upper bound on the time this will all > take. The key conditions we need to worry about here are advertised-domain and > system-domain since these are actually determined on the basis of location > application (at least sort of in the former case). So I might apply location X > with system domain a, then location Y with system-domain b, and the test might > pick up a when it expected b. Is that right? You have it about right. The case I was looking at was applying location Y several times because network/location is refreshed several times. [ ...] > One thing I can't remember though is if there's a good reason to have location > activation conditions support system-domain at all - if not, allowing > system-domain as a condition seems circular to me since the location is the > entity that applies the system domain in the first place (at least when it's > manually specified). We already forbid locations and enm's having > self-referential activation conditions where these pertain to that > location/enm's state, this seems a similar case to me. An ENM has a condition based on the system-domain (in the test case that I am looking at). The problem is that before different nameservices for a location are applied, the domainname(1M) is cleared out. If the ENM happens to check the conditions at this time, its condition will fail (because so domainname is set). The triggered condition check goes to waste and the ENM has to wait until the next timed condition check to see that its condition has been satisfied. -- Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
