Automatic merge from submit-queue
Detect flakes in PR builder e2e runs
Won't be mergable until https://github.com/onsi/ginkgo/pull/261 is agreed upon and merged.
Tossing a PR here to get the e2e test to run on it.
we need to add the dateformat option so that the logrotate
can create unique logfiles for each rotation. Without this,
we logrotation is skipped with message like (generated in
verbose mode of logrotate):
rotating log /var/log/rotate-test.log, log->rotateCount is 5
dateext suffix '-20160718'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
destination /var/log/rotate-test2.log-20160718.gz already exists, skipping rotation
Tested as follows:
# config in '/etc/logrotate.d/rotate-test':
/var/log/rotate-test.log {
rotate 5
copytruncate
missingok
notifempty
compress
maxsize 100M
daily
dateext
dateformat -%Y%m%d-%s
create 0644 root root
}
# create 150Mb of /var/log/rotate-test.log
$ dd if=/dev/zero of=/var/log/rotate-test.log bs=1048576 count=150 conv=notrunc oflag=append
# run logrotate
$ /usr/sbin/logrotate -v /etc/logrotate.conf
...
rotating pattern: /var/log/rotate-test.log after 1 days (5 rotations)
empty log files are not rotated, log files >= 104857600 are rotated earlier, old logs are removed
considering log /var/log/rotate-test.log
log needs rotating
rotating log /var/log/rotate-test.log, log->rotateCount is 5
Converted ' -%Y%m%d-%s' -> '-%Y%m%d-%s'
dateext suffix '-20160718-1468875268'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
copying /var/log/rotate-test.log to /var/log/rotate-test.log-20160718-1468875268
truncating /var/log/rotate-test.log
compressing log with: /bin/gzip
Repeating 'dd' and 'logrotate' commands now generate logfiles correctly.
This was removed by mistake in 9eb42f (PR #25978). Reverting some
of those changes and adding the new mechanism to autogenerate
conversions for the new types that we might define in this API
group in the future.
Automatic merge from submit-queue
Do not skip check for cgroup creation in the systemd mount
As soon as libcontainer dependency is update in #28410, we can skip check for cgroup creation in the systemd mount. As the latest version of libcontainer should create cgroups in the sytemd mount aswell.
This is tied to the upstream issue: #27204
@vishh PTAL
Remove an unused logic. Also this prevents the KillPod() from failing
when the service file doesn't exist. E.g., it can be removed by garbage
collection in a rare case:
1, There are already more than `gcPolicy.MaxContainers` containers running
on the host.
2, The new pod(A) starts to run but doesn't enter 'RUNNING' state yet.
3, GC is triggered, and it sees the pod(A) is in an inactive state (not running),
and the it needs to remove the pod to force the `gcPolicy.MaxContainers`.
4, GC fails to remove the pod because `rkt rm` fails when the pod is running,
but it removes the service file anyway.
5, Follow up KillPod() call will fail because it cannot find the service file
on disk.
Also this is possible only when the pod has been in prepared state for longer
than 1 min, which sounds like another issue.
Automatic merge from submit-queue
Do not query the metadata server to find out if running on GCE. Retry metadata server query for gcr if running on gce.
Retry the logic for determining is gcr is enabled to workaround metadata unavailability.
Note: This patch does not retry fetching registry credentials.
Automatic merge from submit-queue
[flake fix] Wait for the podInformer to observe the pod
Fix#29065
The problem is that the rc manager hasn't observed pod1, so it creates another pod and scales down, pod1 might get deleted. To fix it, wait for the podInformer to observe the pod before running the rc manager.
Marked as P0 as it's fixing a P0 flake.
Automatic merge from submit-queue
Change maxsize to size in logrotate.
How do I trigger a test? I usually test logrotate with `logrotate -s` and that works as expected.
Automatic merge from submit-queue
Apiserver ServeHTTP() modify
In File "pkg\apiserver\watch.go", line 123:
"// Serve serves a series of encoded events via HTTP with Transfer-Encoding: chunked"
Here "Serve" should be "ServeHTTP" because the func name is ServeHTTP:
"func (s *WatchServer) ServeHTTP(w http.ResponseWriter, req *http.Request)"
Automatic merge from submit-queue
Drop support for --gce-service-account, require activated creds
Now that `gcloud auth activate-service-account` is in remove support in the test framework for default service accounts -- testing GCE/GKE now requires prior gcloud activation.
Automatic merge from submit-queue
Make sure --record=false is acknowledged when passed to commands
```release-note
Change setting "kubectl --record=false" to stop updating the change-cause when a previous change-cause is found.
```
Ensures that when `--record=false` is explicity set that no `ChangeCauseAnnotation`s are set on the object. Previously, if `--record=true` was used then all following actions triggered a `ChangeCauseAnnotation` even if `--record=false` was set, due to the prior `ChangeCauseAnnotation` existing.
Reference to bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1351127
[]()
Automatic merge from submit-queue
kubectl apply add --overwrite flag
```release-note
Add "kubectl --overwrite" flag to automatically resolve conflicts between the modified and live configuration using values from the modified configuration.
```
fixes#17238
This PR just add the `--overwrite` flag, pkg/strategicpatch has already support overwrite. @bgrant0607 @jackgr ptal.
Automatic merge from submit-queue
Func note not consistent with real fun name
File "plugin\pkg\webhook.go", line #41 :
"// New creates a new GenericWebhook from the provided kubeconfig file."
Here "New" not consistant with real fun name "NewGenericWebhook" in line #42 :
"func NewGenericWebhook(kubeConfigFile string, groupVersions []unversioned.GroupVersion, initialBackoff time.Duration) (*GenericWebhook, error) {"
Automatic merge from submit-queue
Add proposal for secret and configmap files mode bits
This is a proposal to address https://github.com/kubernetes/kubernetes/issues/28317.
cc @pmorie (owner) @thockin
@thockin: Sorry if you preferred not to be CCed, I thougth you'd be interested :-)
I think this is always the case, but let me say it one more time just in case: as this is a PR, ALL the feedback is more than welcome!
It's my first time in kubernetes, so sorry in advance if this is obviously wrong. What I realize now is that I forgot to add the headers to the proposal. Is there some script to add them? Or should I just c&p from some other proposal?
Thanks a lot,
Rodrigo
Before this change, Authorize() method was just returning an error,
regardless of whether the user is unauthorized or whether there
is some other unrelated error. Returning boolean with information
about user authorization and error (which should be unrelated to
the authorization) separately will make it easier to debug.
Fixes#27974
Automatic merge from submit-queue
Fix verify results in MaxPods
As we already have "unschedulable" PodCondition we can stop relying on Events, which should make the tests more reliable.
cc @davidopp
Automatic merge from submit-queue
Fix port range checking, port should not be greater than 65535.
When passing flag `--proxy-port-range` to kube-proxy with an invalid range which is greater than 65535, the proxy doesn't exit. That's not what we want.
Should we fix this in v1.3?
/cc @thockin @mikedanese @resouer
Before fixing:
```
root@vm:/home/paas/zxp# kube-proxy --master=172.16.1.11:8080 --logtostderr=false --log-dir=/home/user/log/kube --proxy-port-range=65536-65599 &
[6] 6671
root@vm:/home/paas/zxp# ps -ef | grep kube-proxy
root 6671 13507 0 03:48 pts/1 00:00:00 kube-proxy --master=172.16.1.11:8080 --logtostderr=false --log-dir=/home/user/log/kube --proxy-port-range=65536-65599
```
After:
```
root@vm:/home/paas/zxp# kube-proxy --master=172.16.1.11:8080 --logtostderr=false --log-dir=/home/user/log/kube --proxy-port-range=65536-65599 &
[6] 6725
root@vm:/home/paas/zxp# invalid argument "65536-65599" for --proxy-port-range=65536-65599: "65536-65599" is not a valid port range: the port range cannot be greater than 65535: 65536-65599
..............
[6]+ Exit 2 kube-proxy --master=172.16.1.11:8080 --logtostderr=false --log-dir=/home/user/log/kube --proxy-port-range=65536-65599
```
```
root@vm:/home/paas/zxp# kube-proxy --master=172.16.1.11:8080 --logtostderr=false --log-dir=/home/user/log/kube --proxy-port-range=6000-65599 &
[6] 6732
root@vm:/home/paas/zxp# invalid argument "6000-65599" for --proxy-port-range=6000-65599: "6000-65599" is not a valid port range: the port range cannot be greater than 65535: 6000-65599
..............
[6]+ Exit 2 kube-proxy --master=172.16.1.11:8080 --logtostderr=false --log-dir=/home/user/log/kube --proxy-port-range=6000-65599
```
