Project

General

Profile

Bug #2084

Frontend classad invalidation is not correct

Added by Krista Larson almost 9 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
10/31/2011
Due date:
% Done:

0%

Estimated time:
First Occurred:
Occurs In:
Stakeholders:
Duration:

Description

The Frontend code is written to invalidate the glideclient classads but it is also invalidating the glideclientglobals, even though it explicitly includes the TargetType of 'glideclient'. TargetType is ignored so if other classads match the Requirements, they will be removed from the collector. In both the factory and frontend we use Master classads and use INVALIDATE_MASTER_ADS as the command. We need to verify what classad types we should use and then adjust the advertise/deadvertise code accordingly.

Here is Dan Bradley's explanation of the Condor behavior:
Unfortunately, this appears to be slightly messy.

When you submit this invalidation request to the collector, what command
do you use? INVALIDATE_ADS_GENERIC? INVALIDATE_GRID_ADS?

In the collector code, I see that TargetType is, in many cases,
ignored. Whether it is nor not depends on which command was used. The
command that is used determines which hash table the ads are deleted
from. There is a hash table for startd ads, schedd ads, "generic" ads,
and so on.

If the invalidation request contains all required attributes to lookup
an ad by its hash key, then the requirements expression is ignored. An
efficient hash table lookup is used, and the ad is deleted. If the ad
does not contain the attributes necessary to produce a hash key, then
the requirements expression is used. The attributes that are used to
make a hash key depend on the type of ad. Many types of ads use Name
and MyAddress.

If the command that was used was INVALIDATE_ADS_GENERIC, then the
requirements expression is always used, and the specified TargetType
should be honored. Otherwise, TargetType is ignored.

History

#1 Updated by Krista Larson almost 9 years ago

  • Status changed from New to Resolved
  • Target version set to v3_0

Fixed in master. Added GlideinMyType to the Requirements and a new method to deadvertize the frontend globals. Commit 12e2aea3.

Also verified that monitoring were of type "LICENSE", resource were of type "GENERIC" and everything else was of type "MASTER". Also verified that the correct invalidate commands were used for each.

#2 Updated by Parag Mhashilkar over 8 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF