When an apiservice is deleted, its relative
aggregator_unavailable_apiservice metric remains with the value of the
last availability observed. Hence, if an apiservice is deleted while
being unavailable, the metric remains marked as unavailable.
This presents some problems when alerting on unavailable apiservices
as deleted apiservices might trigger the alert indefinitely.
To solve this issue, the aggregator_unavailable_apiservice metric should
only reflect the availability of existing apiservices.
This is achievable by using a custom Collector instead of a GaugeVec and
create throw-away metrics based on an apiservice lister output. With
this approach, on deletion, the apiservice will not be listed anymore,
resulting in its availability metric not being exposed.
Signed-off-by: Damien Grisonnet <dgrisonn@redhat.com>
for CREATE and UPDATE requests, we check duplication before managedFields
update, and after mutating admission; for PATCH requests, we check
duplication after mutating admission
Adds unit tests covering the problematic scenarios identified
around conflicting data in child owner references
Before After
package level 51% 68%
garbagecollector.go 60% 75%
graph_builder.go 50% 81%
graph.go 50% 68%
Added/improved coverage of key functions that had lacking unit test coverage:
* attemptToDeleteWorker
* attemptToDeleteItem
* processGraphChanges (added coverage of all added code)
- as soon as a request is received by the apiserver, determine the
timeout of the request and set a new request context with the deadline.
- the timeout filter that times out non-long-running requests should
use the request context as opposed to a fixed 60s wait today.
- admission and storage layer uses the same request context with the
deadline specified.
The test code generation for create subresource was missing the resource
name parameter in the template which caused a compile error for the
sample projects using the scale subresource. That only occurs with
non-namespaced resource kind.
Also re-ran the code generation after applying the fix.
* Mixed protocol support for Services with type=LoadBalancer
KEP: https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20200103-mixed-protocol-lb.md
Add new feature gate to control the support of mixed protocols in Services with type=LoadBalancer
Add new fields to the ServiceStatus
Add Ports to the LoadBalancerIngress, so cloud provider implementations can report the status of the requested load balanc
er ports
Add ServiceCondition to the ServiceStatus so Service controllers can indicate the conditions of the Service
* regenerate conflicting stuff
