jiebi/CodeConvo huggingface dataset:
Change:
clientConfig = DefaultClientConfig(flags) } <del> clients := &clientCache{ clients: make(map[string]*client.Client), loader:  clientConfig, } </del> <ins> clients := NewClientCache(clientConfig) </ins> return &Factory{ clients:    clients,

Discussion:
This seems like a bug to me No output, and command exits success... wat. Have to explicitly pass to see expected output. If the client version is greater the server version, it should be making requests based on the server's newest accepted apiversion.
cc
Change:
}, []string{"requestKind"}, ) <ins> requestTerminationsTotal = compbasemetrics.NewCounterVec( &compbasemetrics.CounterOpts{ Name:           "apiserver_request_terminations_total", Help:           "Number of requests which apiserver terminated in self-defense.", StabilityLevel: compbasemetrics.ALPHA, }, []string{"verb", "group", "version", "resource", "subresource", "scope", "component", "code"}, ) </ins> kubectlExeRegexp = regexp.MustCompile(`^.*((?i:kubectl.exe))`) metrics = []resettableCollector{

Discussion:
What happened: When the kube-apiserver timeouts on a request, we end up doubling the counts measured in : apiserverrequestcounts apiserverrequesttotal apiserverrequestlatencies apiserverrequestlatenciessummary apiserverrequestdurationseconds apiserverresponsesizes What you expected to happen: We only count our requests a single time in our metrics. How to reproduce it (as minimally and precisely as possible): Add a 60 second sleep in the func . You may want to filter by resource (like pods or something) and verb for testing (otherwise this will be quite annoying). Manually hit that endpoint and look at the metric output. /assign
/sig api-machinery instrumentation /cc
Thanks for filing. Can we, while fixing this, add a metric counting timed-out requests? You can't tell from the latency distribution, even if we made the buckets more useful.
Yeah, that's the current plan. I've relayed the idea to offline and he has concurred.
Change:
kubeDNSProbeSRV = "SRV" kubeDNSProbeA   = "A" <del> coreDNSVersion  = "1.0.0" </del> <ins> coreDNSVersion  = "1.0.1" </ins> ) // GetDNSVersion returns the right kube-dns version for a specific k8s version func GetDNSVersion(kubeVersion *version.Version, dns string) string { // v1.8.0+ uses kube-dns 1.14.5 // v1.9.0+ uses kube-dns 1.14.7 <del> // v1.9.0+ uses CoreDNS  1.0.0 </del> <ins> // v1.9.0+ uses CoreDNS  1.0.1 </ins> // In the future when the version is bumped at HEAD; add conditional logic to return the right versions // Also, the version might be bumped for different k8s releases on the same branch

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: BUG What happened: When CoreDNS is deployed by default using feature-gates of kubeadm, it does not log anything when processing a DNS query. That is due to change of log option of CoreDNS in latest version. that version was bumped up in kubeadm, but the manifest was not adapted to the new log option. initial change of 'log stdout' in CoreDNS : version of CoreDNS 1.0.0 bumped into Kubeadm : NOTE: I guess we should also changed manifests for kube-up : see The change in manifest expected is to remove the option "stdout" in the line "log ...". As it is now interpreted as a scope of domain to log. Invalid manifest: Environment: Kubernetes version (use ): 1.9 and MAIN Cloud provider or hardware configuration: any Install tools: kubeadm, kube-up the configmap for coredns kubectl get configmaps -n kube-system coredns -o yaml kubectl replace -f - the coredns deployment kubectl scale deployment --replicas=0 -n kube-system coredns kubectl scale deployment --replicas=1 -n kube-system coredns
/cc /sig network
NOTE: only log is impacted. CoreDNS working as expected.
/cc
I have a question : the initial manifest is done for the image 0.9.10 of CoreDNS. Bumping the version of CoreDNS was done by changing the version in file (see ) which means that the image's version is STILL 0.9.10 in the manifests ... and the corefile config is correct against the version of the manifest. QUESTION: when modifying the , is there a way to upgrade the manifest by program ? I guess at the time the new version number is applied on the manifest ...
thanks for reporting this! I send PR to update the Corefile. I don't think of a way so far. I guess we can't unless there is a way to get the Corefile from some place of upstream (CoreDNS).
Change:
numNodes, err := e2enode.TotalRegistered(c) framework.ExpectNoError(err) originalNodeCount = int32(numNodes) <del> common.NewRCByName(c, ns, name, originalNodeCount, nil) </del> <ins> common.NewRCByName(c, ns, name, originalNodeCount, nil, nil) </ins> err = e2epod.VerifyPods(c, ns, name, true, originalNodeCount) framework.ExpectNoError(err)

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gci-gce-serial Which test(s) are failing: [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to add nodes [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to delete nodes Since when has it been failing: These tests have been failing since 6/28 Failures coincide with the following changes: Testgrid link: Reason for failure: The failure messages look as follows: [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to add nodes [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to delete nodes /cc /milestone v1.16 /priority critical-urgent /kind failing-test /cc
/sig cluster-lifecycle
For more context, the code for the failing tests is here The error for both comes through  - some Pod is not responding. It is failing to find pods prefixed with "my-hostname-add-node". Within the logs we can see this: So the Pods are stuck in a Pending state. The Pods are supposed to be created by a ReplicationController in , which itself uses this method from the e2e framework . However, after being in a Pending state (after the "failed to wait for pods responding: timed out waiting for the condition" error is registered), they do seem to reach a Ready state
/assign for triage.
I think agnhost needs to be passed , but did not do so in /assign sig-testing
GitHub didn't allow me to assign the following users: sig-testing. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : I think agnhost needs to be passed , but did not do so in 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
Reopen to monitor job /reopen
Reopened this issue.

<detailsIn response to : Reopen to monitor job /reopen 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
Thank you for working on the PR to solve this. indeed solved the issue reported here. /close
Closing this issue. <detailsIn response to : Thank you for working on the PR to solve this. /close 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
Change:
# Compile migrate migrate_tmp_dir=$(shell mktemp -d);  docker run --rm --interactive -v $(shell pwd)/../../../:/go/src/k8s.io/kubernetes$(DOCKER_VOL_OPTS) -v $${migrate_tmp_dir}:/build$(DOCKER_VOL_OPTS) -e GOARCH=$(ARCH) golang:$(GOLANG_VERSION)  <del> /bin/bash -c "CGO_ENABLED=0 go build -o /build/migrate k8s.io/kubernetes/cluster/images/etcd/migrate";  </del> <ins> /bin/bash -c "CGO_ENABLED=0 GO111MODULE=off go build -o /build/migrate k8s.io/kubernetes/cluster/images/etcd/migrate";  </ins> $(BIN_INSTALL) $${migrate_tmp_dir}/migrate $(TEMP_DIR);  docker run --rm --interactive -v $(shell pwd)/../../../:/go/src/k8s.io/kubernetes$(DOCKER_VOL_OPTS) -v $${migrate_tmp_dir}:/build$(DOCKER_VOL_OPTS) -e GOARCH=$(ARCH) golang:$(GOLANG_VERSION)  <del> /bin/bash -c "CGO_ENABLED=0 go build -o /build/cp k8s.io/kubernetes/cluster/images/etcd/cp";  </del> <ins> /bin/bash -c "CGO_ENABLED=0 GO111MODULE=off go build -o /build/cp k8s.io/kubernetes/cluster/images/etcd/cp";  </ins> $(BIN_INSTALL) $${migrate_tmp_dir}/cp $(TEMP_DIR); ifeq ($(ARCH),amd64)

Discussion:
Right now the golang version in the Makefile is set to GOLANGVERSION?=1.12.17. Build fails with " undefined: errors.Is", presumably because errors.Is didn't exist in golang 1.12.
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <detailsInstructions 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
I can take a look.
/triage accepted
According to , we should use 1.16. /kind bug /area release-eng
I send a fix. It would be good to make sure this doesn't break in the future. Question to How we can include building cloud/image as part of presubmits?
Somehow I thought maybe we'd switched to an ectd image built from the etcd project and needed to eventually drop this one? If not this is rather concerning. We don't have a great presubmit to shove this in, I would suggest a runifchanged presubmit to let reviewers of this image know if it builds w/o making it a required job on all PRs (since also changes should be scoped to a directory and infrequent).
For example the conformance image works this way
Change:
"sync" "time" <ins> libcontainercgroups "github.com/opencontainers/runc/libcontainer/cgroups" </ins> "golang.org/x/sys/unix" "k8s.io/klog/v2" )

Discussion:
Start kubelet on a cgroupv2 image with kubelet config option or the flag enabled. Kubelet will periodically log something like: This is because the kernel memcg notifications relies on kubelet's which uses evenfd on file which is cgroupv1 specific and not supported on cgroupv2. Kubelet will disable kernel memcg notifications on cgroupv2 if they are unsupported and consider long term support for more cgroupv2 "compatible" ways to monitor for memory pressure. The closest analogous cgroupv2 concept is using inotify notifications on file and or combination with PSI pressure. This requires to be set on pod cgroup which requires the MemoryQOS feature to be enabled Start kubelet on a cgroupv2 image with enabled.
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions 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
/sig node /cc
Change:
glog.Errorf("No ip address for node %v", node.Name) } else { address := api.NodeAddress{Type: api.NodeLegacyHostIP, Address: addrs[0].String()} <del> node.Status.Addresses = append(node.Status.Addresses, address) </del> <ins> api.AddToNodeAddresses(&node.Status.Addresses, address) </ins> } } }

Discussion:
Since we append hostips to the list on every node controller run invocation which happens at 10s intervals, this list grows pretty large pretty soon: Maybe: would still satisfy the requirements?
Fix is here I think we generally use list instead of map
This could have been P1, but I just merged a fix so I'll leave at P2. Remaining work to do: Add to validation something that limits the number of IP addresses. (and maybe checks dups?)
Yeah, I'll add validation later.
Change:
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels" clientset "k8s.io/client-go/kubernetes" <del> apiv1pod "k8s.io/kubernetes/pkg/api/v1/pod" </del> <ins> "k8s.io/kubectl/pkg/util/podutils" </ins> "k8s.io/kubernetes/test/e2e/framework" e2ekubectl "k8s.io/kubernetes/test/e2e/framework/kubectl" e2epod "k8s.io/kubernetes/test/e2e/framework/pod"

Discussion:
Several test/e2e/framework/* packages have as their only dependency on k/k. The following functions are shared that way: IsPodAvailable returns true if a pod is available; false otherwise. IsPodReady returns true if a pod is ready; false otherwise. VisitContainers invokes the visitor function with a pointer to every container spec in the given pod spec with type set in mask. If visitor returns false, visiting is short-circuited. VisitContainers returns true if visiting completes, false if visiting was short-circuited. AllFeatureEnabledContainers returns a ContainerType mask which includes all container types except for the ones guarded by feature gate. The feature gate check in AllFeatureEnabledContainers is problematic. E2E tests don't know what the feature gates in the cluster are. The rest of the functions look like something that could be moved into == Having the functions in makes it clearer that the checks only depend on aspects of the public API. Reduces dependencies of e2e/framework on k/k, in case that we want to move it into staging. Prevents accidentally using checks that only work in-tree (like feature gates).
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions 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
/sig testing
/assign
Change:
hc.NetworkMode = dockercontainer.NetworkMode(sandboxNSMode) hc.IpcMode = dockercontainer.IpcMode(sandboxNSMode) hc.UTSMode = "" <del> hc.PidMode = "" </del> if hostNetwork { hc.UTSMode = namespaceModeHost

Discussion:
Kubernetes version (use ): 1, 1.6.0 (both run into this issue) Environment: Cloud provider or hardware configuration: VirtualBox 5.1.18 VM OS: 16.04.2 LTS (Xenial Xerus) Kernel: Install tools: kubeadm What happened: A pod scheduled using hostPID wasn't using the host's PID namespace. I've investigated this issue together with What you expected to happen: I expected in the Docker container's config. Instead, the scheduled pod's container had How to reproduce it: Use this config to get a pod running a Docker container: Use on the running container and check whether PidMode is set to host or not. Anything else we need to know*: This was working properly on Kubernetes 1.5.3.
doesn't look like you've specified Docker version, it may be crucial here.
I've tested this with Docker 17.03.1-ce and can confirm that it's the case for pods.
It was Docker 1.12.6 from what I know. I'll check again to be sure it was 1.12.6 and update the post.
Is this with the CRI? If you disable the CRI do you get the desired outcome?
I don't know if that's enabled by default. I've noticed that hostPID doesn't work as it should with Docker. I'm not familiar with CRI.
I'll test with .
With CRI disabled it doesn't work on Docker 17.03, simply because it doesn't like the new versioning scheme. it'd be really great if you can try setting in your , e.g. by modifying (will need to do , and after that you either reinitialise the cluster or kill all the pods).
Seems a bug of kuberuntime, will file a PR to fix this.
Filed for this.
Reoppened this issue to ensure we cherrypick the fix to the 1.6 branch
has been merged to the release-1.6 branch. From what has been discussed so far, this will make it to Kubernetes 1.6.2. I'll close this issue now.
Can anyone help how this issue is fixed? I tried with pidMode: host but it is failing. I am using i.11 version.
I found it --hostPID: true
Change:
readonly master_ssh_supported_providers="gce aws kubemark" readonly node_ssh_supported_providers="gce gke aws" <del> readonly master_logfiles="kube-apiserver kube-scheduler kube-controller-manager etcd glbc cluster-autoscaler" </del> <ins> readonly master_logfiles="kube-apiserver kube-scheduler rescheduler kube-controller-manager etcd glbc cluster-autoscaler" </ins> readonly node_logfiles="kube-proxy" readonly aws_logfiles="cloud-init-output" readonly gce_logfiles="startupscript"

Discussion:
We need to have collected by: fluentd jenkins
could you please take a look?
I this is actually two separate problems. Exporting as artifact from master is easy. Exporting logs to the logging backend will require fluentd configuration changes =images version changes, which are blocked by and
Change:
} // set namespace options and supplemental groups. <del> podSc := pod.Spec.SecurityContext if podSc == nil { return synthesized } </del> synthesized.NamespaceOptions = &runtimeapi.NamespaceOption{ HostNetwork: pod.Spec.HostNetwork, HostIpc:     pod.Spec.HostIPC, HostPid:     pod.Spec.HostPID, } <del> if podSc.FSGroup != nil { synthesized.SupplementalGroups = append(synthesized.SupplementalGroups, *podSc.FSGroup) </del> <ins> podSc := pod.Spec.SecurityContext if podSc != nil { if podSc.FSGroup != nil { synthesized.SupplementalGroups = append(synthesized.SupplementalGroups, *podSc.FSGroup) } if podSc.SupplementalGroups != nil { synthesized.SupplementalGroups = append(synthesized.SupplementalGroups, podSc.SupplementalGroups...) } </ins> } if groups := m.runtimeHelper.GetExtraSupplementalGroupsForPod(pod); len(groups) > 0 { synthesized.SupplementalGroups = append(synthesized.SupplementalGroups, groups...) } <del> if podSc.SupplementalGroups != nil { synthesized.SupplementalGroups = append(synthesized.SupplementalGroups, podSc.SupplementalGroups...) } </del> return synthesized }

Discussion:
Kubernetes version (use ): 1, 1.6.0 (both run into this issue) Environment: Cloud provider or hardware configuration: VirtualBox 5.1.18 VM OS: 16.04.2 LTS (Xenial Xerus) Kernel: Install tools: kubeadm What happened: A pod scheduled using hostPID wasn't using the host's PID namespace. I've investigated this issue together with What you expected to happen: I expected in the Docker container's config. Instead, the scheduled pod's container had How to reproduce it: Use this config to get a pod running a Docker container: Use on the running container and check whether PidMode is set to host or not. Anything else we need to know*: This was working properly on Kubernetes 1.5.3.
doesn't look like you've specified Docker version, it may be crucial here.
I've tested this with Docker 17.03.1-ce and can confirm that it's the case for pods.
It was Docker 1.12.6 from what I know. I'll check again to be sure it was 1.12.6 and update the post.
Is this with the CRI? If you disable the CRI do you get the desired outcome?
I don't know if that's enabled by default. I've noticed that hostPID doesn't work as it should with Docker. I'm not familiar with CRI.
I'll test with .
With CRI disabled it doesn't work on Docker 17.03, simply because it doesn't like the new versioning scheme. it'd be really great if you can try setting in your , e.g. by modifying (will need to do , and after that you either reinitialise the cluster or kill all the pods).
Seems a bug of kuberuntime, will file a PR to fix this.
Filed for this.
Reoppened this issue to ensure we cherrypick the fix to the 1.6 branch
has been merged to the release-1.6 branch. From what has been discussed so far, this will make it to Kubernetes 1.6.2. I'll close this issue now.
Can anyone help how this issue is fixed? I tried with pidMode: host but it is failing. I am using i.11 version.
I found it --hostPID: true
Change:
) // NewProxyServer returns a new ProxyServer. <del> func NewProxyServer(config *proxyconfigapi.KubeProxyConfiguration, cleanupAndExit bool, scheme *runtime.Scheme, master string) (*ProxyServer, error) { </del> <ins> func NewProxyServer(o *Options) (*ProxyServer, error) { return newProxyServer(o.config, o.CleanupAndExit, o.scheme, o.master) } func newProxyServer(config *proxyconfigapi.KubeProxyConfiguration, cleanupAndExit bool, scheme *runtime.Scheme, master string) (*ProxyServer, error) { </ins> if config == nil { return nil, errors.New("config is required") }

Discussion:
https://k8s- https://k8s- cc: /kind bug /priority failing-test
This is at least twice in a week we've had cross break due to a public method signature change not being brought to all platforms () We should do:
I'm lost - the PR in question adds an argument and fixes the call-site - what is broken?
Ahh, I see.
How did that PR get through, if it is so obviously broken on Cross?
Cross build doesn't run 100% of the time as a pre-submit (because it takes so long), and it can't block. It's something sig-testing is tracking, but there isn't a quick fix yet.
Looks like was skipped for that PR: "pull-kubernetes-cross Skipped" not sure why yet.
Cross runs when a file matching: changes, (which needs to be fixed, opening a test-infra issue to expand the regex), but also some files could have build tags without the file name matching () Additionally cross is not blocking (), the underlying bug should be fixed now though so once we get the fix in to k/k we can make it blocking when it does run.
I find has already sent a PR. Thanks!
Change:
deps = [ "//pkg/api:go_default_library", "//pkg/apis/componentconfig:go_default_library", <ins> "//pkg/apis/componentconfig/v1alpha1:go_default_library", </ins> "//pkg/util:go_default_library", <ins> "//pkg/util/configz:go_default_library", </ins> "//pkg/util/iptables:go_default_library", "//vendor/github.com/stretchr/testify/assert:go_default_library", "//vendor/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", <ins> "//vendor/k8s.io/apimachinery/pkg/runtime:go_default_library", </ins> "//vendor/k8s.io/apimachinery/pkg/util/diff:go_default_library", ], )

Discussion:
Is this a request for help? No. What keywords did you search in Kubernetes issues before filing this one? is:issue is:open ipv6 Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST Kubernetes version (use ): N/A, these are unit test changes in latest master Environment: Cloud provider or hardware configuration: Kubernetes container dev env on Ubuntu 16.04.1 OS (e.g. from /etc/os-release): Ubuntu 16.04.1 Kernel (e.g. ): 4.4.0-78-generic -Ubuntu x8664 GNU/Linux Install tools: Others: What happened: Upon inspection, no IPv6 test cases found in kubernetes/cmd/kube- What you expected to happen: Expect to see some IPv6 test cases exercised for kube-proxy server code (kubernetes/cmd/kube-). Also need some code coverage for negative conditions in How to reproduce it (as minimally and precisely as possible): Run unit tests in kubernetes/cmd/kube- Anything else we need to know:
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig networking
/area ipv6
/sig network