Automatic merge from submit-queue
goflags must be after subcommand
**What this PR does / why we need it**:
if GOFLAGS is set when calling make, kubernetes will fail to build
as an example, I often have `GOFLAGS=-v` so I can have some idea of progress during compilation
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*:
no known issue
**Special notes for your reviewer**:
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 38419, 38457, 38607)
Node E2E: Update CVM version to e2e-node-containervm-v20161208-image.
I built the new node e2e image from e2e-node-containervm-v20161208-image.
@timstclair
/cc @kubernetes/sig-node
Automatic merge from submit-queue (batch tested with PRs 38419, 38457, 38607)
Fix pod level QoS does not works on CRI dockershim
Fixes: https://github.com/kubernetes/kubernetes/issues/38458
We did set `CgroupParent ` in `CreateContainer`, but the `HostConfig.Resources` which `CgroupParent` belongs to is override by the following code:
```
hc.CgroupParent = lc.GetCgroupParent()
...
hc.Resources = dockercontainer.Resources{
Memory: rOpts.GetMemoryLimitInBytes(),
...
}
```
That's why `HostConfig.CgroupParent` is always empty and pod level QoS does not work.
Automatic merge from submit-queue
bump log level on service status update
ref: https://github.com/kubernetes/kubernetes/issues/38349
I tried to reproduce the problem in #38349 and failed. Not sure why service status update failed and service controller skip status update in the next round. What I have observed is that if service status update failed due to conflict, the next round of processServiceUpdate will correct it.
Bumping log level to get a better signal when it occurs.
Automatic merge from submit-queue (batch tested with PRs 38453, 36672, 38629, 34966, 38630)
Fix threshold notifier build tags
Fix threshold notifier build tags so the linux version is only built if cgo is
enabled, and the unsupported version is built if it's either not linux or not
cgo.
Automatic merge from submit-queue (batch tested with PRs 38453, 36672, 38629, 34966, 38630)
Fix staging/copy.sh to work on mac and linux
@smarterclayton ptal
Automatic merge from submit-queue (batch tested with PRs 38453, 36672, 38629, 34966, 38630)
Warn user if they try to apply on an object without the annotation
Give user a warning when using `kubectl apply` on a resource lacking the `LastAppliedConfig` annotation
fixes#36620
Ref: #35134 and #36509.
**Release note**:
```release-note
Issue a warning when using `kubectl apply` on a resource lacking the `LastAppliedConfig` annotation
```
Automatic merge from submit-queue
remove incorrect groupName comment for apps.k8s.io
The group name is "apps", not "apps.k8s.io"
The comment didn't actually affect client generation because there was an extra space between it and the package declaration, but removing it to avoid confusion
This is to facilitate GCI tip vs. K8s tip testing; we need to
dynamically set the version of GCI to stay current with their
latest canary (latest of the "gci-base" prefixed images).
Automatic merge from submit-queue
Increase GCE operation timeout
It seems 30 minutes is too small for creating some routes in large clusters.
@thockin - FYI
Automatic merge from submit-queue
error in setNodeStatus func should not abort node status update
`setNodeStatus()` currently errors out if any of the functions in the `kl.setNodeStatusFuncs` returns an error, resulting in the node not reporting status and eventually being marked as `NotReady`.
`setNodeAddress()` is currently the only function in `defaultNodeStatusFuncs()` that can return an error and it does if the cloud provider can't be contacted for any number of reasons like token expiration, API outage, ratelimit block, etc.
This PR changes `setNodeStatus()` to log, rather than return, when an error is returned by one of the `setNodeStatusFuncs` so that the node status update can proceed.
Fixes#34455
xref https://bugzilla.redhat.com/show_bug.cgi?id=1400574
@eparis @derekwaynecarr @mikedanese @anguslees
Fix threshold notifier build tags so the linux version is only built if cgo is
enabled, and the unsupported version is built if it's either not linux or not
cgo.
Automatic merge from submit-queue
fix client cert handling for delegate authn
Builds on https://github.com/kubernetes/kubernetes/pull/38409.
The client cert wasn't presented by the API server, so tools didn't send it. These will start getting caught as we add usage into e2e. Once we split genericapiserver out, we can have a different style integration test that hits these too.
RESTMapping takes a desired GroupKind, and a set of versions, and
returns a rest mapper for the first matching version. It also has a
list of built-in discovered prioritized versions, to which it appends
the user versions.
However, when it goes to parse the versions, it parses them as
GroupVersions. Since only a version was passed, the group will be the
empty group (""), which will only match rest mappings for the empty
group, ergo, none of the user's versions will match if they are
attempting a match for a non-emtpy-group GroupKind.
This fixes that by taking the parsed GroupVersion, and overriding the
Group with the Group from the passed-in GroupKind.
Automatic merge from submit-queue
test: cleanup test logs for deployments
@mfojtik @janetkuo this will help with the deployment logs (should make them a bit cleaner) ptal
Automatic merge from submit-queue (batch tested with PRs 38608, 38299)
controller: set unavailableReplicas correctly when scaling down
```
deployment_controller.go:299] Error syncing deployment
e2e-tests-kubectl-2l7xx/e2e-test-nginx-deployment:
Deployment.extensions "e2e-test-nginx-deployment" is invalid:
status.unavailableReplicas: Invalid value: -1:
must be greater than or equal to 0
```
The validation error above occurs usually when a Deployment is
scaled down. In such a case we should default unavailableReplicas
to 0 instead of making an invalid api call.
@kubernetes/deployment
Automatic merge from submit-queue (batch tested with PRs 38597, 38570)
Logging request / response body should not allocate
Putting string(data) in the critical path causes an allocation which can
be very large, and happens regardless of whether logging is enabled.
Also, use the more sophisticated logging of body output that avoids
causing quoting of JSON output (current behavior is "{\"key\":...}" and
should be {"key":...} for readability).
@wojtek-t reduces large heap allocations on updates
Mike Danese