When I describe network policies, it often tells me that pods are
isolated for egress connectivity because the policy that applies to them
has no egress rules. However, this would only lead to isolation if there
is an explicitly set egress policy type. Otherwise, the policy allows
egress traffic. The same applies if you have explicitly set an egress
type only, describe will incorrectly report isolated ingress traffic.
This PR fixes this by inferring the applicable direction for the policy
based on the PolicyTypes, and then if a policy doesn't apply eg to
egress, we print 'Not affecting egress traffic'
- Added thread_safe_store_test exercising new index backing string set delete at 0 functionality.
- TestThreadSafeStoreDeleteRemovesEmptySetsFromIndex logic nesting inverted.
- Added test case for usage of an index where post element delete there is non-zero count of elements and expect the set to still exist.
- Fixed date.
- Fixed awprice nits.
- Fix bazel.
After the detach calls are made, any further updates with the disks in
the process of getting detached will complain with errors such as:
"
Cannot attach data disk '<disk name>' to VM '<vm name>' because the
disk's ToBeDetached flag is set to true. Please either remove the
disk from APIModel or set the ToBeDetached flag to false and then
try again
"
This PR will ensure that the disks with the ToBeDetached flag set are
filtered out before the update to the cloud is made.
b.N is adjusted by pkg/testing using an internal heuristic:
> The benchmark function must run the target code b.N times. During
> benchmark execution, b.N is adjusted until the benchmark function
> lasts long enough to be timed reliably.
Using b.N to seed other parameters makes the benchmark behavior
difficult to reason about. Before this change, thread count in the
CachedTokenAuthenticator benchmark is always 5000, and batch size is
almost always 1 when I run this locally. SimpleCache and StripedCache
benchmarks had similarly strange scaling.
After modifying CachedTokenAuthenticator to only adjust iterations based
on b.N, the batch chan was an point of contention and I wasn't able to
see any significant CPU consumption. This was fixed by using
ParallelBench to do the batching, rather than using a chan.
This commit performs two refactors and fixes a bug.
Refactor 1 changes the signature of Request to take a RESTClient, which
removes the extra copy of everything on RESTClient from Request. A pair
of optional constructors are added for testing. The major functional
change is that Request no longer has the shim HTTPClient interface and
so some test cases change slightly because we are now going through
http.Client code paths instead of direct to our test stubs.
Refactor 2 changes the signature of RESTClient to take a
ClientContentConfig instead of ContentConfig - the primary difference
being that ClientContentConfig uses ClientNegotiator instead of
NegotiatedSerializer and the old Serializers type. We also collapse
some redundancies (like the rate limiter can be created outside the
constructor).
The bug fix is to negotiate the streaming content type on a Watch()
like we do for requests. We stop caching the decoder and simply
resolve it on the request. We also clean up the dynamic client
and remove the extra WatchSpecificVersions() method by providing
a properly wrapped dynamic client.
Instead of returning an error on the watch stream, if we can't properly
negotiate a watch serialization format we should error and return that
error to the client.
Clients have to renegotiate frequently, and the shape of the interface
that a client wants is slightly different than the interface on the
server. Create a new ClientNegotiator interface that represents what
the client->server code would want to use (mostly, still evolving
Encoder) and move versioning details out of RESTClient.
In the long run, we want to remove internal clients and conversions
from clients. This takes a step in that direction and also makes sure
watch negotiation is consistent with the server.
