Automatic merge from submit-queue
Reset core_patern on GCI
The default core_pattern pipes the core dumps to /sbin/crash_reporter
which is more restrictive in saving crash dumps. So for
now, set a generic core_pattern that users can work with.
@dchen1107 @aulanov can you please review?
cc/ @kubernetes/goog-image
Automatic merge from submit-queue
Remove duplicated ECDHE key handling
This PR removes the duplicated ECDHE private key handling. `x509.CreateCertificateRequest` picks the signature type for ECDHE keys already (see https://golang.org/src/crypto/x509/x509.go `signingParamsForPublicKey`). Only the RSA key signature needed customization.
It also defers to `CreateCertificateRequest` to return errors on unknown private key types.
Automatic merge from submit-queue
Add positive logging for GC events
We have no positive logging for GC events. This PR:
1. Adds positive logging at V(4) for success cases
2. Adds positive logging at V(1) for the first successful GC after a failure
Automatic merge from submit-queue
Mount kubelet root directory as executable in GCI
Fixes#33315 and #33318
This PR is isolated to GCI distro. Without this rather simple patch,
PetSets won't work with GCI. Hence requesting a cherry-pick.
Automatic merge from submit-queue
Dereference the UID pointer for a readable error message.
cc @nikhiljindal @quinton-hoole @kubernetes/sig-cluster-federation
Automatic merge from submit-queue
Don't try to write the wrong UID, version on Federated Ingress updates.
Fixes#33135.
This looks more complicated than it really is.
Essentially, use the cluster object's metadata, rather than the federated objects's metadata when updating cluster Ingress objects. The deepcopy stuff is mainly to get around shortcomings in the Kubernetes fake test infrastructure, which ends up with crossed pointers if we don't deep copy.
Automatic merge from submit-queue
Staging 1.5 client
Created the 1.5 folder and remove the 1.4 folder in the staging area in the master branch.
Content of kubernetes/client-go/1.4 will be pulled from the kubernetes/kubernetes 1.4 branch (https://github.com/kubernetes/contrib/pull/1719)
Automatic merge from submit-queue
Fake container exec/logs support for in-process docker CRI integration
This is necessary to unblock other work on docker integration, while we are addressing
`logs` and `exec` in the meantime.
This is part of #31459 and #33189
/cc @kubernetes/sig-node
Automatic merge from submit-queue
remove storage related fields from genericapiserver
Removes `StorageFactory` and `StorageDecorator` from from `genericapiserver` since both constructs are related to building a `RESTStorage`, which should be provided fully formed (or via factory func) to a truly generic API server.
I found this while trying to move the creation API routes earlier.
This is a temporary hack to bypass CRI when getting container logs or
running exec in a container. This is necessary to unblock testing and adding
other features in the integration.
Automatic merge from submit-queue
Add description for behavior changes of the DELETE REST operation caused by garabge collection
@janetkuo @lavalamp @pwittrock
Automatic merge from submit-queue
Minor refactor of Ceph RBD provisioning docs.
Improves clarity of Ceph RBD provisioner documentation, expanded on how to translate Ceph settings into secrets.
Allow the group claim to be a single string instead of an array of
strings. This means the following claim
{
"role": "admin"
}
Will be mapped to the groups
["admin"]
This PR fixes the race condition in setting node statusUpdateNeeded flag
in master's attachdetach controller. This flag is used to indicate
whether a node status has been updated by the node_status_updater or
not. When updater finishes update a node status, it is set to false.
When the node status is changed such as volume is detached or new volume
is attached to the node, the flag is set to true so that updater can
update the status again. The previous workflow has a race condition as
follows
1. updater gets the currently attached volume list from the node which needs to be
updated.
2. A new volume A is attached to the same node right after 1 and set the
flag to TRUE
3. updater updates the node attached volume list (which does not include volume A) and then set the flag to FALSE.
The result is that volume A will be never added to the attached volume
list so at node side, this volume is never attached.
So in this PR, the flag is set to FALSE when updater tries to get the
attached volume list (as in an atomic operation). So in the above
example, after step 2, the flag will be TRUE again, in step 3, updater
does not set the flag if updates is sucessful. So after that, flag is
still TRUE and in next round of update, the node status will be updated.
This PR also changes a unit test due to the workflow changes
Automatic merge from submit-queue
Refactor Builder.visitorResult by extra methonds.
**What this PR does / why we need it**:
Code polish; it'll make code readable.
