Reword modifications for clarity

This commit is contained in:
matte21 2019-12-31 09:48:28 +01:00
parent 3ae8c864de
commit 21f59c9923

View File

@ -107,17 +107,15 @@ import (
// For a given SharedInformer and client, the notifications are
// delivered sequentially. For a given SharedInformer, client, and
// object ID, the notifications are delivered in order. Because
// `ObjectMeta.UID` has no role in identifying objects, if an object
// O1 with ID (e.g. namespace and name) X and `ObjectMeta.UID` U1 in
// the SharedInformer's local cache is deleted and shortly after
// another relevant object O2 with ID X and `ObjectMeta.UID` U2 is
// created a client has no guarantee of seeing O1's deletion and
// O2's creation as two separate notifications, it might as well
// receive a single update notification where the old object is O1
// and the new object is O2. Clients that need to detect such cases
// might do so by comparing the `ObjectMeta.UID` field of the old
// and the new object in the code that handles update notifications
// (i.e. `OnUpdate` method of ResourceEventHandler).
// `ObjectMeta.UID` has no role in identifying objects, it is possible
// that when (1) object O1 with ID (e.g. namespace and name) X and
// `ObjectMeta.UID` U1 in the SharedInformer's local cache is deleted
// and later (2) another object O2 with ID X and ObjectMeta.UID U2 is
// created the informer's clients are not notified of (1) and (2) but
// rather are notified only of an update from O1 to O2. Clients that
// need to detect such cases might do so by comparing the `ObjectMeta.UID`
// field of the old and the new object in the code that handles update
// notifications (i.e. `OnUpdate` method of ResourceEventHandler).
//
// A client must process each notification promptly; a SharedInformer
// is not engineered to deal well with a large backlog of