jiebi/CodeConvo huggingface dataset:
Change:
HardPodAffinitySymmetricWeight: 1, HealthzBindAddress:             "", // defaults empty when not running from config file MetricsBindAddress:             "", // defaults empty when not running from config file <ins> DebuggingConfiguration: componentbaseconfig.DebuggingConfiguration{ EnableProfiling:           true, EnableContentionProfiling: true, }, </ins> LeaderElection: kubeschedulerconfig.KubeSchedulerLeaderElectionConfiguration{ LeaderElectionConfiguration: componentbaseconfig.LeaderElectionConfiguration{ LeaderElect:       true,

Discussion:
What would you like to be : Enable profiling by default in the scheduler. We can do this by defaulting the CC flags to true. Why is this needed: It is useful when debugging the performance of a running cluster. API server already enables profiling by default. /sig scheduling /help /milestone v1.17
/assign /remove-help
Change:
This rule maintains the invariant that all JSON/YAML keys are fields in API objects. The only exceptions are pure maps in the API (currently, labels, selectors, and annotations), as opposed to sets of subobjects. <ins> #### Constants Some fields will have a list of allowed values (enumerations). These values will be strings, and they will be in CamelCase, with an initial uppercase letter. Examples: "ClusterFirst", "Pending", "ClientIP". </ins> ### Lists and Simple kinds

Discussion:
The api conventions document should provide guidance on values for constants and naming of -like fields like .
Yes, apparently we didn't document the CamelCase rule.
Change:
<ins> apiVersion: storage.k8s.io/v1beta1 kind: StorageClass metadata: name: default annotations: storageclass.beta.kubernetes.io/is-default-class: "true" labels: kubernetes.io/cluster-service: "true" provisioner: kubernetes.io/azure-disk </ins>

Discussion:
We'd like to deprecate alpha provisioning in 1.6. In order to make current deployments working after upgrade to 1.6 we need to deploy a default StorageClass as part of installation/upgrade on Azure so it will automatically provision volumes for PVCs marked with annotation - the annotation will be ignored and default storage class must provision the volume instead. On GCE and AWS, we use addon manager to install the default storage class, see Note that some extra code is probably needed to actually put the storage class into addons directory during installation, e.g. for manual script-based installation on GCE or for salt-based installation. Please make sure that: A default StorageClass is deployed during "default" installation. It would be nice if admin could turn this off during installation (e.g. as on GCE) If any additional manual steps are needed to deploy the default storage class make sure they're documented in appropriate installation guide.
Assigning to random Microsoft personnel for faster routing to proper person.
I believe this is fixed, correct? If so, I will close it...
Yes, it's fixed.
Change:
# do_start() { <ins> # Avoid a potential race at boot time when both monit and init.d start # the same service PIDS=$(pidof $DAEMON) for PID in ${PIDS}; do kill -9 $PID done </ins> # Raise the file descriptor limit - we expect to open a lot of sockets! ulimit -n 65536

Discussion:
During an e2e test run, on GCE, I ssh-ed into the box. After the reboot test runs, it appears that something is trying to start kubelet every 2 minutes after the reboot: It does appear that it is monit restarting the process: I do only have one copy of kubelet running, because the second kubelet fails to start:
The direct cause of monit thinking the kubelet is down is that does not match. Also, keeps changing (every two minutes?) My hypothesis is that the second kubelet writes the pid, because it gets pretty far in its boot-up. And thereafter, monit sees it as down so keeps trying to start more. And so the root cause is that first second kubelet start, which I think is down to this: My kubelet is currently listening to that url though: My guess is that kubelet is too slow to start listening to /healthz
Oh! ... or it's a simple race with init.d starting the services; monit vs kube-proxy. If monit starts kube-proxy before init.d starts kube-proxy =double start.
/cc
Ok, there is a race when monit is used to monitor services that are also started at boot time via init.d, in our ecosystem, such as kubelet, kube-proxy, and docker. Especially when a service is slow to start, monit can assume that the service is not running and possibly try to start it and raise an issue while the service is already about to start or already in its startup sequence. In this case, there is a stale pidfile which is used by monit during the service validation periodically (currently configured every 2 mins), thus run into the issue reported by here. A clean way to fix this is starting those kubernetes related services requiring monitoring by monit directly by monit. The issue is that monit is not installed by default in our gce images for now. My proposed solution is that for each dostart call in /etc/init.d/${servicedaemon}, checking if there is existing process running. If it does, kill it before calling start-stop-daemon --start Will send pr shortly.
Change:
t.Errorf("unexpected error: %v", err) } if len(times) != 2 { <del> t.Errorf("expected 2 start times, got: , got: %v", times) </del> <ins> t.Errorf("expected 2 start times, got: %v", times) </ins> } else { if !times[0].Equal(T1) { t.Errorf("expected: %v, got: %v", T1, times[0])

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Unit test error message match the conventional Go style: For example: if got, want := set.Status.Replicas, 3; got != want { t.Errorf("set.Status.Replicas = %v; want %v", got, want) }
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig testing
/assign
/reopen
Change:
} } } <ins> func TestExtractDeviceAndPrefix(t *testing.T) { devicePath := "127.0.0.1:3260-iqn.2014-12.com.example:test.tgt00" lun := "-lun-0" device, prefix, err := extractDeviceAndPrefix("/var/lib/kubelet/plugins/kubernetes.io/iscsi/" + devicePath + lun) if err != nil || device != (devicePath+lun) || prefix != devicePath { t.Errorf("extractDeviceAndPrefix: expected %s and %s, got %v %s and %s", devicePath+lun, devicePath, err, device, prefix) } } func TestExtractPortalAndIqn(t *testing.T) { devicePath := "127.0.0.1:3260-iqn.2014-12.com.example:test.tgt00-lun-0" portal, iqn, err := extractPortalAndIqn(devicePath) if err != nil || portal != "127.0.0.1:3260" || iqn != "iqn.2014-12.com.example:test.tgt00" { t.Errorf("extractPortalAndIqn: got %v %s %s", err, portal, iqn) } } </ins>

Discussion:
During iscsi volume cleanup, kubelet reads from and retrieves a list of device paths where iscsi volume mounts on. The device path was expected to be in the form of . But currently the device path in is in the form of , thus iscsi panicked . I suspect this panic started to happen after switched to use from . seems to always resolve device path (see output below), and thus the expected iscsi configuration in the device path no longer exists.
Change:
"github.com/GoogleCloudPlatform/kubernetes/pkg/api" "github.com/GoogleCloudPlatform/kubernetes/pkg/client" "github.com/GoogleCloudPlatform/kubernetes/pkg/runtime" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/util" </ins> ) func TestRunExposeService(t *testing.T) {

Discussion:
This was broken by , and therefore broken in as well. Any fix should be offered as a cherry pick so "make release" is clean there.
I went ahead and worked something up for this this morning, to get Shippable builds back on the rails.
Change:
- linters: - ginkgolinter text: use a function call in (Eventually|Consistently) <ins> # SSA Extract calls are allowed in tests. - linters: - forbidigo text: should not be used because managedFields was removed path: _test.go$ </ins> linters: disable-all: true # not disabled in golangci-strict.yaml enable: # please keep this alphabetized and in sync with golangci-strict.yaml <ins> - forbidigo </ins> - ginkgolinter - gocritic - govet

Discussion:
Add a code static check for to report using server-side-apply extract With optimization of and , the will be removed in and , and maybe more of other components in the future, using Extract is problematic. It's safer to add this lint check.
/cc
/sig api-machinery
/sig scheduling /sig apps
/assign /triage accepted
Change:
//   user: //     token: red-token } <ins> func TestDeduplicate(t *testing.T) { testCases := []struct { src    []string expect []string }{ { src:    []string{"a", "b", "c", "d", "e", "f"}, expect: []string{"a", "b", "c", "d", "e", "f"}, }, { src:    []string{"a", "b", "c", "b", "e", "f"}, expect: []string{"a", "b", "c", "e", "f"}, }, { src:    []string{"a", "a", "b", "b", "c", "b"}, expect: []string{"a", "b", "c"}, }, } for _, testCase := range testCases { get := deduplicate(testCase.src) if !reflect.DeepEqual(get, testCase.expect) { t.Errorf("expect: %v, get: %v", testCase.expect, get) } } } </ins>

Discussion:
/kind bug /sig cli What happened: The same path was multiple times to KUBECONFIG env variable. 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 ): Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-10-05T00:40:04Z", GoVersion:"go1.9.1", Compiler:"gc", Platform:"darwin/amd64"} Cloud provider or hardware configuration**: Irrelevant OS (e.g. from /etc/os-release): MacOS Sierra 10.12.6 Kernel (e.g. ): Darwin Kernel Version 16.7.0 Install tools: brew install kubernetes-cli Others:
I would help fix it.
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
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
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Change:
return ps } <del> func (p *petSetTester) execInPets(ps *apps.PetSet, cmd string) { </del> <ins> func (p *petSetTester) checkMount(ps *apps.PetSet, mountPath string) error { for _, cmd := range []string{ // Print inode, size etc fmt.Sprintf("ls -idlh %v", mountPath), // Print subdirs fmt.Sprintf("find %v", mountPath), // Try writing fmt.Sprintf("touch %v", filepath.Join(mountPath, fmt.Sprintf("%v", time.Now().UnixNano()))), } { if err := p.execInPets(ps, cmd); err != nil { return fmt.Errorf("failed to execute %v, error: %v", cmd, err) } } return nil } func (p *petSetTester) execInPets(ps *apps.PetSet, cmd string) error { </ins> podList := p.getPodList(ps) for _, pet := range podList.Items { stdout, err := framework.RunHostCmd(pet.Namespace, pet.Name, cmd) <del> ExpectNoError(err) </del> framework.Logf("stdout of %v on %v: %v", cmd, pet.Name, stdout) <ins> if err != nil { return err } </ins> } <ins> return nil </ins> } func (p *petSetTester) saturate(ps *apps.PetSet) {

Discussion:
Eg: Suspect it's because of:
If this hasn't been seen in 3 months, okay to close?
Yes we fixed it with
Change:
"github.com/GoogleCloudPlatform/kubernetes/pkg/client" "github.com/GoogleCloudPlatform/kubernetes/pkg/labels" "github.com/GoogleCloudPlatform/kubernetes/pkg/util" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/watch" </ins> . "github.com/onsi/ginkgo" . "github.com/onsi/gomega"

Discussion:
PodInterface should have Watch method behaving in the same way as ServiceInterface.Watch does. Use case: a monitoring system (namely Prometheus) expects to get the list of monitored servers performing a DNS-SD query. Special service (similar to kube2sky shipped with Kubernetes) mirrors status of running Pods into etcd, which is in turn monitored by SkyDNS server and exported as DNS-SD. Schematically the data flow looks like this: Kubernetes -kube2sky -etcd -SkyDNS -Prometheus. The biggest challenge is to deliver list of all running pods from Kubernetes to kube2sky. Currently kube2sky can only poll Kubernetes with PodInterface.List() each N seconds, which is not efficient. Having a Watch method would be much better.
cc Do you know why we do not support watch?
Every object should support Watch.
Watching status doesn't currently work -- that's .
I agree with OP. This is just an accident of history; some boilerplate in the client isn't completely filled out. As Brian mentions, not every field is currently watchable but that's being addressed elsewhere.
This is relevant to your interests potentially w/ your work on
This is a pretty simple change if someone wants to get their feet wet. :)
I'll work on it.
Change:
"containers": [{ "name": "slave", "image": "brendanburns/redis-slave", <ins> "cpu": 200, </ins> "ports": [{"containerPort": 6379, "hostPort": 6380}] }] }

Discussion:
HPA tests are currently failing in gke-large cluster suite: I did some debugging and the problem seems to be related to pod-nanny. Looking into logs from the last run: was first scheduled on the large node dedicated to it pod-nany updated heapster deployment then heapster was scheduled on the normal node (when it actually shouldn't fit) that point it was never updated by the pod nanny. that point, heapster started crashlooping (OOMing) [which in fact was expected in too small machine] So it's pretty clear that that pod-nanny changed the amount of resources to something smaller, which in fact it shouldn't.
Change:
- name: SchedulingPreferredAntiAffinityWithNSSelector defaultPodTemplatePath: config/pod-preferred-anti-affinity-ns-selector.yaml <del> featureGates: PodAffinityNamespaceSelector: true </del> workloadTemplate: - opcode: createNodes countParam: $initNodes

Discussion:
/sig scheduling in the job is failing. success run Due to this failure, we cannot see any scheduler metrics results from the perf-dash. master
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
/remove-kind bug /kind flake /kind failing-test
/assign /remove-kind flake
will fixed by
Change:
"//staging/src/k8s.io/component-base/metrics/...", "//test/e2e_node", "//test/integration/apiserver/flowcontrol", <ins> "//test/integration/metrics", </ins> "//vendor/...", ], )

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: While I was watching grafana for a single run, I noticed that GET requests are reported as LIST requests, e.g. grafana shows ~1K QPS for LIST of pods ! while kube-apiserver's logs show: (there are no pod lists that time). I'm not sure if this is intended change to metrics reporting (kind of unexpected to be honest), but this definitely affects way our scalability tests validate latency metrics: We do not validate GET API call latency at all Validation for LIST requests is also affected, as usually GET API calls are way cheaper than LIST requests, so grouping GET-LISTs and LIST-LISTs together lowers p99 for LISTs. Also perf-dash shows that GET requests simply disappeared at some point: http://perf- ! What you expected to happen: GET requests should be reported with verb=GET in apiserverrequest_total metric. 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:

FYI
I managed to narrow the issue by bisecting the runs of which runs load tests using master k/k every 1 hour. This is the last test run that had GETs reported correctly: This is the first test run that has no GETs reported: Looking at the k/k repo commits' hashes inside artifacts in both runs and at what happened between each of them it looks as if might be the culprit.
From the former run's artifacts: This is (among others) what we miss in the latter run - this is understandable from the point of view of this if condition: Why did the reported GETs have as the scope instead of in the first place, however??
It seems that our handing is incorrect: vs Or my understanding of it was incorrect.

It seems that the semantic is: cluster - for cluster-scope requests namespace - for namespace-scoped requests request - for subresources I think the assumption in the monitoring path was: cluster - for cluster-scope requests namespace - for namespace-scope requests requests - for requests touching a single resource (not necessary subresource) I'm not 100% sure which semantic we should use - based on the finding we should fix one or the other place...
cc There should probably be a unit test mapping URL paths to the expected label values.
is opened to fix that.
/triage accepted
Change:
"UserDefinedMetrics": gomega.BeEmpty(), }) } <ins> expectedPageFaultsUpperBound := 1000000 </ins> expectedMajorPageFaultsUpperBound := 10 if IsCgroup2UnifiedMode() { <del> expectedMajorPageFaultsUpperBound = 1000 </del> <ins> // On cgroupv2 these stats are recursive, so make sure they are at least like the value set // above for the container. expectedPageFaultsUpperBound = 1e9 expectedMajorPageFaultsUpperBound = 100000 </ins> } podsContExpectations := sysContExpectations().(*gstruct.FieldsMatcher)

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --ci-cos-cgroupv2-containerd-node-e2e <!-- You can identify the SIG from the "prowjobconfigurl" on the testgrid dashboard for a test --<!-- Please see the deflaking doc () for more guidance! --/sig node
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : #### Which jobs are flaking: links to appreciated links to specific failures in spyglass appreciated </details
On cgroupv2, it looks like like the number of for cgroup is sometimes higher than is currently expected in the test. We currently expect this however, in a few runs of the test we've seen We may need to adjust this value similar as was done in for
/cc
yes, good idea. I think we need to adjust the PageFaults test as well. I've opened a PR:
/assign /triage accepted /area test /priority important-soon
Change:
core.NewCreateAction(schema.GroupVersionResource{Version: "v1", Resource: "secrets"}, metav1.NamespaceDefault, createdTokenSecret()), // Retry 1 core.NewGetAction(schema.GroupVersionResource{Version: "v1", Resource: "serviceaccounts"}, metav1.NamespaceDefault, "default"), <del> core.NewCreateAction(schema.GroupVersionResource{Version: "v1", Resource: "secrets"}, metav1.NamespaceDefault, namedCreatedTokenSecret("default-token-x50vb")), </del> <ins> core.NewCreateAction(schema.GroupVersionResource{Version: "v1", Resource: "secrets"}, metav1.NamespaceDefault, namedCreatedTokenSecret("default-token-jk9rt")), </ins> // Retry 2 core.NewGetAction(schema.GroupVersionResource{Version: "v1", Resource: "serviceaccounts"}, metav1.NamespaceDefault, "default"), <del> core.NewCreateAction(schema.GroupVersionResource{Version: "v1", Resource: "secrets"}, metav1.NamespaceDefault, namedCreatedTokenSecret("default-token-scq98")), </del> <ins> core.NewCreateAction(schema.GroupVersionResource{Version: "v1", Resource: "secrets"}, metav1.NamespaceDefault, namedCreatedTokenSecret("default-token-684pg")), </ins> }, }, "new serviceaccount with missing secrets": {

Discussion:
/kind feature What happened: In playing with the nginx ingress controller deployment, I noticed the following pod name: nginx-ingress-controller--c0ck5 I figure we should possibly put something in place to prevent accidental l33t profanity ;-). What you expected to happen: The following pod name: nginx-ingress-controller--r0ck5
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
My first github (k8s) issue. I've no idea which SIG would cover this topic. /sig product-management
/sig api-machinery
Previously we removed vowels in . We can 3xt3nd the idea with 0, 1 (can stand for ) and 3. would you like to send a PR? If not, I can work on this.
/assign jamesawebb1
Reassign to me if you do not want to contribute a PR.
Change:
"sync" "time" <ins> "github.com/golang/glog" </ins> "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/util/diff" )

Discussion:
/kind bug What happened: Start a cluster using ./hack/local- Now just monitor the memory on kube-apiserver and kube-controller-manager. Without doing anything else note the memory on each process has grown by 500 MB each day. Tried this for 5 days and saw this steady growth. What you expected to happen: Memory to remain relatively flat after some initial growth. How to reproduce it (as minimally and precisely as possible): Run ./hack/local- and wait. Anything else we need to know?: Environment: Kubernetes version (use ): 1.10 Cloud provider or hardware configuration: local OS (e.g. from /etc/os-release): Debian GNU/Linux Kernel (e.g. ): Debian 4.9.65-3+deb9u2 Install tools: Others:
/sig api-machinery
/milestone v1.10
/priority important-soon
!
Copying some of what was discussed in Slack - we need to redo a test with set when running . This disables the cache mutation detector, which holds on to "all the things" .
What does the chart mean? yeah determined that most of it is from the mutation detector (it really makes me nervous to have test code linked in to the production binaries).
It was a differential pprof memory chart of hack/local-cluster- But as noted, we have to run it without mutation detection. I did that for an hour yesterday and did not notice much memory leaking.
After the suggested fix (turn of mutation detection), there was no noticeable increase on controller manager memory and the api-server memory increase was down to 8 MB per day. (on my setup)
[MILESTONENOTIFIER] Milestone Issue Needs Approval Action required: This issue must have the label applied by a SIG maintainer. If the label is not applied within 2 days, the issue will be moved out of the v1.10 milestone. <details<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
closing this to remove it from the release radar. Feel free to reopen if you think we still have an issue.