Extends the certificate attribute deprecation RoundTrippers wrapper with
a checker that counts certificates with sha-1 signatures in server responses.
Non-root non-self-signed SHA-1 certificate signatures were deprecated in
Golang 1.18.
Kubernetes-commit: 499ee65a9b0cd45d41716b513fae0d537f7f9c88
Previously, this test assumed that:
- a global watch would return only an event for the key in question
- only the delete event in question would be returned
Neither of these assumptions are correct for an etcd backend as long
as any other clients are interacting with the system. This commit
makes the watch more specific and extracts the correct event.
Signed-off-by: Steve Kuznetsov <skuznets@redhat.com>
Kubernetes-commit: 2631c0a0f959bd67aa455045dce33e77150ab5f8
In a number of tests, the underlying storage backend interaction will
return the revision (logical clock underpinning the MVCC implementation)
at the call-time of the RPC. Previously, the tests validated that this
returned revision was exactly equal to some previously seen revision.
This assertion is only true in systems where no other events are
advancing the logical clock. For instance, when using a single etcd
cluster as a shared fixture for these tests, the assertion is not valid
any longer. By checking that the returned revision is no older than the
previously seen revision, the validation logic is correct in all cases.
Signed-off-by: Steve Kuznetsov <skuznets@redhat.com>
Kubernetes-commit: eba25cdbbcc5d35e707516194f64d8ed363c2773
When tests attempt to validate behavior in the case that a client asks
for a resource version that is "too large" for the underlying storage,
the previous implementation would simply add 1 to the latest revision
seen. This is only appropriate for storage backends that
a) provide a continuous monotonic logical clock
b) have no other events occurring while the test runs
For instance, when using a singe etcd backend as a shared fixture for
these tests, adding 1 to a previously-seen revision is not suffcient to
ensure that the resulting revision is "too large". By instead using the
largest possible integer value, we can be certain of this.
Signed-off-by: Steve Kuznetsov <skuznets@redhat.com>
Kubernetes-commit: b973cdc57cc6ee57684455cdb76db13a8c82cefa
Without these select statements, this test runs until the package-global
timeout and causes a panic. This change makes the test fail faster and
more legibly.
Signed-off-by: Steve Kuznetsov <skuznets@redhat.com>
Kubernetes-commit: fc33d0176a5afb81927430d075165152f953c54e
This is the first version to be fully go-mod-compatible.
Signed-off-by: Stephen Kitt <skitt@redhat.com>
Kubernetes-commit: 080c6c711ebf527d5494732b4b41d074ab02733f
Validating admission webhook evaluation can fail, if uncaught this
crashes a kube-apiserver. Add handling to catch panic while preserving
the behavior of "must not fail".
Kubernetes-commit: d412bf92b3b02bda93707c6aaba945f28bf60c72
This commit includes all the changes needed for APIServer. Instead of modifying the existing signatures for the methods which either generate or return stopChannel, we generate a context from the channel and use the generated context to be passed to the controllers which are started in APIServer. This ensures we don't have to touch APIServer dependencies.
Kubernetes-commit: 8b84a793b39fed2a62af0876b2eda461a68008c9
The cacher blocks requests until it is ready, however, the
ready variable doesn't differentiate if the cacher was stopped.
The cacher is using a condition variable based on sync.Cond to
handle the readiness, however, this was not taking into account
if it was not ready because it was waiting to be ready or it was
stopped.
Add a new condition to the condition variable to handle the
stop condition, and returning an error to signal the goroutines
that they should stop waiting and bail out.
Kubernetes-commit: 2cb3a56e83ae33464edb174b1b6373ba50600759
This reverts commit 83ca74541216405323ddfb67f5f80ad5717da826, reversing
changes made to 1c216c6ec86e700170620fe4c75fa3a2a2817530.
Kubernetes-commit: b0b460921b81b260473d5c393d85beeb5a03e834
Some of these changes are cosmetic (repeatedly calling klog.V instead of
reusing the result), others address real issues:
- Logging a message only above a certain verbosity threshold without
recording that verbosity level (if klog.V().Enabled() { klog.Info... }):
this matters when using a logging backend which records the verbosity
level.
- Passing a format string with parameters to a logging function that
doesn't do string formatting.
All of these locations where found by the enhanced logcheck tool from
https://github.com/kubernetes/klog/pull/297.
In some cases it reports false positives, but those can be suppressed with
source code comments.
Kubernetes-commit: edffc700a43e610f641907290a5152ca593bad79
Kubernetes Publisher
Stanislav Laznicka
Steve Kuznetsov
kerthcet
Wojciech Tyczyński
kartik494
Kensei Nakada
Jiahui Feng
Ross Peoples
Ikko Ashimine
astraw99
Daniel Smith
Stephen Kitt
Anish Ramasekar
David Eads
Patrick Ohly
Maciej Borsz
Ravi Gudimetla
Antonio Ojea
Tim Bannister
Abu Kashem
Maciej Wyrzuc
zk
Sally O'Malley