jiebi/CodeConvo huggingface dataset:
Change:
/kind bug is not working on Kubernetes 1.8. It gets stuck and only returns when the container exits. I tested it in GKE 1.6.11 and 1.7.8 and it works there. But doesn't work on GKE 1.8.0. Here's a simple reproduction: a 1.8.0 or 1.8.1 cluster. a simple busybox container and . another terminal, try without . It works. now. It gets stuck. more commands in the busybox terminal but there are still no logs in the terminal. another terminal try without again. That still works. Exit the busybox container: would show up on the terminal now. /sig cli cc -
/cc
Please file under kubernetes/kubectl
It seems this is not a kubectl bug, see echo the comment here: /reopen
/unassign /sig node api-machinery
Also note , this only happens in () that turn on all alpha features.
to make sure this isn't something funky with CRI log streaming on the node side do either of you guys know who's responsible for log streaming through API server?
AFAIK, we did not change CRI log streaming in 1.8. Given that this only fails in Alpha clusters, it'd be easier to vet the Alpha features instead.
Adding sig-gcp since only this has been observed only in GKE alpha clusters so far. If anyone from is willing to help out by narrowing down what Alpha features are related, that'd be great.
I turned off in the apiserver in a GKE cluster and the log function is working again. /cc
Ubuntu 16.0.4.5 Kubernetes v1.11.3 Agree with ! If ---"kubectl -f" dose not work
Would you mind sharing how you did this? This now seems to be happening on non-alpha clusters there. The feature gate's alpha status in the Kubernetes docs hasn't changed though.
Reiterating the mentions to trigger a notification: <detailsIn response to : I turned off in the apiserver in a GKE cluster and the log function is working again. /cc Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This is still an issue in Alpha Clusters. I encountered this while deploying a GKE 1.13.5-gke.10 alpha cluster. Shouldn't this issue be re-opened? /cc

Discussion:
return -1, errors.New("compressing error: tried to write data using closed compressor") } c.Header().Set(headerContentEncoding, c.encoding) <ins> defer c.compressor.Flush() </ins> return c.compressor.Write(p) }
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: in func OnError() of ErrorHandlers in apimachinery it is expected to go on sleep for some time if not meet the minPeriod. However, if time happens hops to the past in the process. would be a negative number, thus, it may sleep a lot longer than we expected. What you expected to happen: The period for sleep should be reseted if time hops
/sig api-machinery
adding a check on whether d is < 0 should fix it, no? if d < 0, simply don't sleep.
ooh, we have time travelling kubes now :)
so if d < 0, it's better to sleep r.minPeriod.
i think Go 1.9 should fix it, as reported and verified in the other issue

Discussion:
r.lastErrorTimeLock.Lock() defer r.lastErrorTimeLock.Unlock() d := time.Since(r.lastErrorTime) <del> if d < r.minPeriod { </del> <ins> if d < r.minPeriod && d >= 0 { // If the time moves backwards for any reason, do nothing // TODO: remove check "d >= 0" after go 1.8 is no longer supported </ins> time.Sleep(r.minPeriod - d) } r.lastErrorTime = time.Now()
Change:
/kind bug What happened: Warning printed by : What you expected to happen: No warning. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: This is my first e2e cluster. Logs with more context below. Environment: Kubernetes version (use ): master Cloud provider or hardware configuration**: GCE OS (e.g. from /etc/os-release): Description: Ubuntu 14.04 LTS
This is probably an issue in the scripts.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
This has started failing in tests: https://k8s-
/shrug /milestone v1.10 /assign /assign /priority failing-test /priority critical-urgent /sig network /sig testing
I think this might be only in the staging gcloud release; at least doesn't mention this being removed.
and yeah, gce-canary is also using staging gcloud /shrug
/assign I'll fix kubetest, is patching k8s
/approved-for-milestone
/status approved-for-milestone
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code freeze, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues. Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
/status in-review
should we close this issue since the PR merged?
waiting for , and that need to be cherrypicked into older releases
still need to cherrypick into previous releases
agreed, but isn't blocking 1.10 any more /milestone clear
cherrypick is done, closing /close

Discussion:
network_mode="custom" fi echo "Creating new ${network_mode} network: ${NETWORK}" <del> gcloud compute networks create --project "${NETWORK_PROJECT}" "${NETWORK}" --mode="${network_mode}" </del> <ins> gcloud compute networks create --project "${NETWORK_PROJECT}" "${NETWORK}" --subnet-mode="${network_mode}" </ins> else PREEXISTING_NETWORK=true PREEXISTING_NETWORK_MODE="$(check-network-mode)"

} function expand-default-subnetwork() { <del> gcloud compute networks switch-mode "${NETWORK}"  --mode custom  </del> <ins> gcloud compute networks update "${NETWORK}"  --switch-to-custom-subnet-mode  </ins> --project "${NETWORK_PROJECT}"  --quiet || true gcloud compute networks subnets expand-ip-range "${NETWORK}"
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig cluster-lifecycle What happened: introduced a redundant call on StartLogging in the service controller. It's called on line What you expected to happen: Should only be called once Anything else we need to know?: cc

Discussion:
broadcaster.StartLogging(glog.Infof) broadcaster.StartRecordingToSink(&v1core.EventSinkImpl{Interface: v1core.New(kubeClient.Core().RESTClient()).Events("")}) recorder := broadcaster.NewRecorder(scheme.Scheme, v1.EventSource{Component: "service-controller"}) <del> broadcaster.StartLogging(glog.Infof) </del> if kubeClient != nil && kubeClient.Core().RESTClient().GetRateLimiter() != nil { metrics.RegisterMetricAndTrackRateLimiterUsage("service_controller", kubeClient.Core().RESTClient().GetRateLimiter())
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: reports that the cluster is running and returns exit code 0. correctly identifies that the cluster is not running and exists with exit code 1. What you expected to happen: should fail when the cluster is not running. How to reproduce it (as minimally and precisely as possible): Start and stop a kubernetes cluster using minikube and then type kubectl cluster-info. Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-09-28T22:57:57Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.5", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-10-06T20:53:14Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration**: Local OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): Linux Ubuntu16-HP-800 4.10.0-35-generic ~16.04.1-Ubuntu SMP Wed Sep 13 09:02:42 UTC 2017 x8664 x8664 x86_64 GNU/Linux Install tools: snap for kubectl. minikube local for k8s. Others:
/assign /sig cli

Discussion:
SelectorParam("kubernetes.io/cluster-service=true"). ResourceTypeOrNameArgs(false, []string{"services"}...). Latest() <del> b.Do().Visit(func(r *resource.Info, err error) error { </del> <ins> err = b.Do().Visit(func(r *resource.Info, err error) error { </ins> if err != nil { return err }

return nil }) out.Write([]byte("nTo further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.n")) <del> return nil </del> <ins> return err </ins> // TODO consider printing more information about cluster }
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: kubelet has support for running in dockershim-only mode via a hidden flag named , but this flag is ignored when kubelet is run using hyperkube binary, e.g. . What you expected to happen: I expected to have the same effect with hyperkube as it has with 'plain' kubelet binary. How to reproduce it (as minimally and precisely as possible): Try to run kubelet in dockershim mode using hyperkube binary: It'll start in normal mode instead. Anything else we need to know?: We use dockershim server for CRI Proxy part of project. Virtlet is a CRI implementation for running VMs as pods, and thanks to that CRI proxy mechanism it's deployed as a DaemonSet itself. Unfortunately lack of flag in hyperkube causes some deployment difficulties and as of now we have to import code from kubelet to run our own dockershim server. Environment: Kubernetes version (use ): v1.8.1 I can fix this one myself if it's agreed that the change is useful.
go for it. the debate can be on the PR :)
/assign
[MILESTONENOTIFIER] Milestone Issue Current <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details

Discussion:
configuration data, with the running set of containers by starting or stopping Docker containers.`, Run: func(_ *Server, _ []string, stopCh <-chan struct{}) error { <ins> if s.ExperimentalDockershim { return app.RunDockershim(&s.KubeletFlags, &s.KubeletConfiguration) } </ins> return app.Run(s, nil) }, }
Change:
Currently there are several, and some of them have problems with excessive logging could you please do this?
Any estimate on this fix? Asking because I'm seeing the issue referenced in
It was already fixed in head and in 1.8 long time ago. Fix was merged to 1.7 recently, so we are just waiting for new patch release.

Discussion:
readOnly: true # BEGIN_PROMETHEUS_TO_SD - name: prom-to-sd <del> image: gcr.io/google-containers/prometheus-to-sd:v0.2.1 </del> <ins> image: gcr.io/google-containers/prometheus-to-sd:v0.2.2 </ins> command: - /monitor - --source=heapster:http://localhost:8082?whitelisted=stackdriver_requests_count,stackdriver_timeseries_count

- --api-override={{ prometheus_to_sd_endpoint }} - --pod-id=$(POD_NAME) - --namespace-id=$(POD_NAMESPACE) <del> volumeMounts: - name: ssl-certs mountPath: /etc/ssl/certs </del> env: - name: POD_NAME valueFrom:

- '/event-exporter' # BEGIN_PROMETHEUS_TO_SD - name: prometheus-to-sd-exporter <del> image: gcr.io/google-containers/prometheus-to-sd:v0.2.1 </del> <ins> image: gcr.io/google-containers/prometheus-to-sd:v0.2.2 </ins> command: - /monitor <del> - --component=event_exporter </del> - --stackdriver-prefix={{ prometheus_to_sd_prefix }}/addons - --api-override={{ prometheus_to_sd_endpoint }} <del> - --whitelisted-metrics=stackdriver_sink_received_entry_count,stackdriver_sink_request_count,stackdriver_sink_successfully_sent_entry_count volumeMounts: - name: ssl-certs mountPath: /etc/ssl/certs </del> <ins> - --source=event_exported:http://localhost:80?whitelisted=stackdriver_sink_received_entry_count,stackdriver_sink_request_count,stackdriver_sink_successfully_sent_entry_count - --pod-id=$(POD_NAME) - --namespace-id=$(POD_NAMESPACE) env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace </ins> # END_PROMETHEUS_TO_SD terminationGracePeriodSeconds: 30 volumes:

fi; # BEGIN_PROMETHEUS_TO_SD - name: prometheus-to-sd-exporter <del> image: gcr.io/google-containers/prometheus-to-sd:v0.1.3 </del> <ins> image: gcr.io/google-containers/prometheus-to-sd:v0.2.2 </ins> command: - /monitor <del> - --component=fluentd - --target-port=31337 </del> - --stackdriver-prefix={{ prometheus_to_sd_prefix }}/addons - --api-override={{ prometheus_to_sd_endpoint }} <del> - --whitelisted-metrics=stackdriver_successful_requests_count,stackdriver_failed_requests_count,stackdriver_ingested_entries_count,stackdriver_dropped_entries_count </del> <ins> - --source=fluentd:http://localhost:31337?whitelisted=stackdriver_successful_requests_count,stackdriver_failed_requests_count,stackdriver_ingested_entries_count,stackdriver_dropped_entries_count - --pod-id=$(POD_NAME) - --namespace-id=$(POD_NAMESPACE) env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace </ins> # END_PROMETHEUS_TO_SD nodeSelector: beta.kubernetes.io/fluentd-ds-ready: "true"
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: unit test fail randomly. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
I am working on it.
/sig cli
/kind bug
Thanks for opening the issue. I'm experiencing this too.

Discussion:
mountHeader: mountSecretNames, tokenHeader: tokenSecretNames, } <del> for header, names := range types { </del> <ins> for _, header := range sets.StringKeySet(types).List() { names := types[header] </ins> if len(names) == 0 { w.Write(LEVEL_0, "%st<none>n", header) } else {
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: I want to run test on (ubuntu) with this cmd: What you expected to happen: e2enode test pass How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: After go into details I got this info: I think e2enode start kubelet by this cmd as is not set by default in : After fix it temporarily I got one more error about this issue: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: Others: I will send a PR to fix this if it is confirmed.
/sig testing
/sig node
If your environment doesn't support swap, you could override kubelet flag with:
Thanks! Could you take a look at this : append if needed.

Discussion:
// - test/e2e_node/conformance/run_test.sh. "--pod-cidr", "10.100.0.0/24", "--eviction-pressure-transition-period", "30s", <del> // Apply test framework feature gates by default. This could also be overridden // by kubelet-flags. "--feature-gates", framework.TestContext.FeatureGates, </del> "--eviction-hard", "memory.available<250Mi,nodefs.available<10%,nodefs.inodesFree<5%", // The hard eviction thresholds. "--eviction-minimum-reclaim", "nodefs.available=5%,nodefs.inodesFree=5%", // The minimum reclaimed resources after eviction. "--v", LOG_VERBOSITY_LEVEL, "--logtostderr", ) <ins> // Apply test framework feature gates by default. This could also be overridden // by kubelet-flags. if framework.TestContext.FeatureGates != "" { cmdArgs = append(cmdArgs, "--feature-gates", framework.TestContext.FeatureGates) } </ins> if utilfeature.DefaultFeatureGate.Enabled(features.DynamicKubeletConfig) { // Enable dynamic config if the feature gate is enabled dynamicConfigDir, err := getDynamicConfigDir()
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: IPVS proxy UT breaks in macOS platform. What you expected to happen: Should run IPVS proxy UTs everywhere. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: That's because there is a flag in , see Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig network
/assign cc

Discussion:
go_library( name = "go_default_library", <del> srcs = select({ "@io_bazel_rules_go//go/platform:linux_amd64": [ "fake.go", ], "//conditions:default": [], }), </del> <ins> srcs = ["fake.go"], </ins> importpath = "k8s.io/kubernetes/pkg/proxy/ipvs/testing", tags = ["automanaged"], )

<del> // +build linux </del> /* Copyright 2017 The Kubernetes Authors.
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: NO FailedPostStartHook Error Message After Upgrade to 1.7.8 When we use 1.6.3 , We can get message like Error syncing pod, skipping: failed to "StartContainer" for "xxxx" with PostStart handler: command '/xxxxxx' exited with 1: Hook do errexit, this is stderr : "PostStart Hook Failed" From Event, But After Upgrade to 1.7.8 ,the FailedPostStartHook Event always have no message What you expected to happen: we need the message to find out the poststarthook failed reason How to reproduce it (as minimally and precisely as possible): Use PostStartHook And Fail It Anything else we need to know?: line 123 ,dont delete it Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.8", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-10-05T06:54:19Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.8", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-10-05T06:35:40Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: OS (e.g. from /etc/os-release):CentOS Linux 7 (Core) Kernel (e.g. ):4.13.7- Install tools: Others:
/area kubelet /sig node
I think this was fixed from 1.8. see:
the error message is in handlerErr ,so didnot fix this
I've just updated to kubernetes 1.8 and still no error message in However, I've never seen it there, as I've been using k8s for a few days, some of which were spent on searching how to debug hooks... Anyway client and server version: Server is running as a part of minikube
thanks for pointing it out! I send PR . PTAL.
We also require the error message included in the Event Would you please add it?
Seems like the is already included in the according to implementation.
the m.runner.Run in master seems same as release-1.7 ,And I found the msg is empty in release-1.7so the handlerErr may not included in msg.
ping and for confirmation. thanks!
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
JUST FOR SOMEBODY WHO CARE ABOUT THE PostStartHook Event Message "the msg is empty " have really already been fixed in It's in release 1.7.12 but it seems the release note didn't mention this

Discussion:
glog.Errorf("Failed to kill container %q(id=%q) in pod %q: %v, %v", container.Name, kubeContainerID.String(), format.Pod(pod), ErrPostStartHook, err) } <del> return msg, ErrPostStartHook </del> <ins> return msg, fmt.Errorf("%s: %v", ErrPostStartHook, handlerErr) </ins> } }
Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Fluentd pod failed to become ready on master after upgrade from 1.8-HEAD. Logs from https://k8s- Multiple CIs are hitting this: https://k8s- https://k8s- https://k8s- Anything else we need to know?: From the timeline, possibly caused by the fluentd hostnetwork change:
https://k8s- has the same symptom as well. /sig instrumentation
Could you please take a look?
/unassign /assign
It doesn't seem like an upgrade issue actually. It happens exclusively on master and I see it happening just after regular cluster startup. In the prom-to-sd logs: Why is metadata server unaccessible from the master? Can it be related to the metadata-proxy?
Yeah I agree, edited the title. Sorry for the confusion.
This is definitely metadata proxy related. Are you still seeing this? I introduced a bug in that I fixed in
https://k8s- Same issue today. Again on master
Okay. My guess is that the metadata proxy isn't getting scheduled on the master for some reason. Looking ...
Hm. The master's shows that it's got the right node label and that a proxy is being scheduled:
Okay, I'm seeing the same thing on a newly-created HEAD cluster. Metadata-proxy is running and serving requests ... my next guess is that the iptables rules are messed up.
The iptables rules are fine:
cc
Note that we moved fluentd out of host network recently. Why do we want to do that?
Thanks, yup. We're trying to root cause; unclear if that's what caused it, or a change in the metadata proxy.
Thanks for debugging this! found that on master node is 0, which should be 1. I set it to 1, and it does fix the issue.
I've included the fix in
Thanks a lot for debugging! Could you please add to the PR description? Also, what about previous branches? Is it going to work on 1.7 and 1.8 branches, or we need to propagate your fix there?

Discussion:
function config-ip-firewall { echo "Configuring IP firewall rules" <ins> # Do not consider loopback addresses as martian source or destination while # routing. This enables the use of 127/8 for local routing purposes. sysctl -w net.ipv4.conf.all.route_localnet=1 </ins> # The GCI image has host firewall which drop most inbound/forwarded packets. # We need to add rules to accept all TCP/UDP/ICMP packets. if iptables -L INPUT | grep "Chain INPUT (policy DROP)" > /dev/null; then