jiebi/CodeConvo huggingface dataset:
Change:
# For each release create a tmp dir 'etcd_release_tmp_dir' and unpack the release tar there. for version in $(BUNDLED_ETCD_VERSIONS); do  etcd_release_tmp_dir=$(shell mktemp -d);  <del> docker run --interactive -v $${etcd_release_tmp_dir}:/etcdbin golang:$(GOLANG_VERSION) /bin/bash -c  </del> <ins> docker run --interactive -v $${etcd_release_tmp_dir}:/etcdbin golang:$(GOLANG_VERSION)$(DOCKER_VOL_OPTS) /bin/bash -c  </ins> "git clone https://github.com/coreos/etcd /go/src/github.com/coreos/etcd  && cd /go/src/github.com/coreos/etcd  && git checkout v$${version}  && GOARM=$(GOARM) GOARCH=$(ARCH) ./build  && cp -f bin/$(ARCH)/etcd* bin/etcd* /etcdbin; echo 'done'";  <del> cp $$etcd_release_tmp_dir/etcd $$etcd_release_tmp_dir/etcdctl $(TEMP_DIR)/;  cp $(TEMP_DIR)/etcd $(TEMP_DIR)/etcd-$$version;  cp $(TEMP_DIR)/etcdctl $(TEMP_DIR)/etcdctl-$$version;  </del> <ins> $(BIN_INSTALL) $$etcd_release_tmp_dir/etcd $$etcd_release_tmp_dir/etcdctl $(TEMP_DIR)/;  $(BIN_INSTALL) $(TEMP_DIR)/etcd $(TEMP_DIR)/etcd-$$version;  $(BIN_INSTALL) $(TEMP_DIR)/etcdctl $(TEMP_DIR)/etcdctl-$$version;  </ins> done # Add this ENV variable in order to workaround an unsupported arch blocker

Discussion:
Part of What happened: Attempt to run as a non-root user Get What you expected to happen: It runs How to reproduce it (as minimally and precisely as possible): /sig release /sig cluster-lifecycle /area security And as part of kubeadm v1.16 milestone: /milestone v1.16 /priority critical-urgent
/assign randomvariable /lifecycle active
/priority important-soon
Change:
return pod, err } pod.CurrentState.Info = info <ins> pod.CurrentState.Status = makePodStatus(info) </ins> pod.Kind = "cluster#pod" return pod, err }

Discussion:
ci-cgroupv1-containerd-node-arm64-al2023-e2e-ec2-eks E2eNode Suite: [It] [sig-node] Summary API [NodeConformance] when querying /stats/summary should report resource usage through the stats api { failed [FAILED] Timed out after 180.001s. Expected <string: Summary to match fields: { .Node.SystemContainers: missing expected element runtime } In [It] at: @ 07/26/23 05:48:05.248 } arm test since begining cadvisor on arm? /sig node
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
/cc
/assign it may be ec2 related, not arm related. We need to fix arm tests on gce to validate (failing currently).
Should be fixed, but I'm watching and will re-open if not.
Test is passing now, good to leave closed.
Change:
} func TestKubeletDefault(t *testing.T) { <ins> var resolverConfig string if isSystemdResolvedActive, _ := isServiceActive("systemd-resolved"); isSystemdResolvedActive { // If systemd-resolved is active, we need to set the default resolver config resolverConfig = kubeletSystemdResolverConfig } </ins> tests := []struct { name       string clusterCfg kubeadmapi.ClusterConfiguration

Discussion:
What happened: TestKubeletDefault unit test fails when run locally on system that has systemd-resolved active What you expected to happen: Unit test succeeds How to reproduce it (as minimally and precisely as possible): Use ubuntu with systemd-resolved active. Run Output: Anything else we need to know?: Environment: Kubernetes version (use ): Master branch (v1.19.0-alpha) Cloud provider or hardware configuration: n/a OS (e.g: ):Kernel (e.g. ):Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig node /priority important-soon I created this issue to track what happened. I'll have a PR to fix soon. /assign
/area kubeadm /sig cluster-lifecycle
/remove-sig node
thanks for reporting. /remove-kind bug /kind failing-test /assign
Change:
expectErr:      true, expectedErrMsg: "unable to provision SubPath `no/backsteps/../allowed`: must not contain '..'", }, <ins> "volume doesn't exist": { podVolumes: kubecontainer.VolumeMap{}, container: v1.Container{ VolumeMounts: []v1.VolumeMount{ { MountPath: "/mnt/path3", Name:      "disk", ReadOnly:  true, }, }, }, expectErr:      true, expectedErrMsg: "cannot find volume "disk" to mount into container """, }, "volume mounter is nil": { podVolumes: kubecontainer.VolumeMap{ "disk": kubecontainer.VolumeInfo{}, }, container: v1.Container{ VolumeMounts: []v1.VolumeMount{ { MountPath: "/mnt/path3", Name:      "disk", ReadOnly:  true, }, }, }, expectErr:      true, expectedErrMsg: "cannot find volume "disk" to mount into container """, }, </ins> } for name, tc := range testCases {

Discussion:
<!-- 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: The makeMounts function adding volumes to the volumes list if the volume doesn't exist or mounter doesn't exist. This is potentially dangerous behavior because an application can write to the mount path (if it already exists in the container image) expecting it to be backed by a persistent volume, but in fact, is only backed by the container rootfs, which is ephemeral. We probably have not seen this issue manifest in the wild because the volume not existing or mounter being nil should never happen, and also the application would probably see a path/file does not exist error first. What you expected to happen: If we can't mount all of the user's requested volumes into the container, we should fail to start the container. /assign /sig storage node /cc
Change:
func IsCriticalPodBasedOnPriority(priority int32) bool { return priority >= scheduling.SystemCriticalPriority } <ins> // IsNodeCriticalPod checks if the given pod is a system-node-critical func IsNodeCriticalPod(pod *v1.Pod) bool { return IsCriticalPod(pod) && (pod.Spec.PriorityClassName == scheduling.SystemNodeCritical) } </ins>

Discussion:
<!-- Feature requests are unlikely to make progress as an issue. Instead, please suggest enhancements by engaging with SIGs on slack and mailing lists. A proposal that works through the design along with the implications of the change can be opened as a KEP: --I'd like only pods to have low OOM score -997. introduced a change which ensured all the critical priority classes will have a low OOM score -997. While this helped in relating OOM score to priority of pod, it also allows containers in pods to have -997 OOM score, making them one of the last processes to be OOMKilled. By definition pods can be scheduled elsewhere if there is crunch on the node where as pods cannot be rescheduled. This was the reason for to have higher priority value than . So, I think it makes sense for only pods to have low OOM score of -997. /sig node cc
/triage accepted
i think this is reasonable since is higher priority than and this would make a distinction between the two making killable but assured to be rescheduled
Note that oomscore has nothing to do with rescheduling. Eviction looks at priority, oomscore simply controls the killer. I think that strengthens the argument - the point of node-critical is makinng sure it's killed last, but even then that should be a rare, rare case (a memory leak in kube-proxy will blow out the workload, but if we just killed kube-proxy everything would heal). We may want to go back to the original justifications for -99x oomscore in system-node-critical and make sure we're still aligning correctly.
Change:
expected["bert"] = sets.NewString("one", "two") expected["elmo"] = sets.NewString("tre") expected["oscar"] = sets.NewString("two") <del> expected["elmo"] = sets.NewString() // let's just make sure we don't get anything back in this case </del> <ins> expected["elmo1"] = sets.NewString() </ins> { for k, v := range expected { found := sets.String{}

Discussion:
second will cancel the first set, as a result, the is checking empty list which will always be true. this test should fail.
/sig testing
A set is immutable, and by definition cannot support two of the same key name. We should have to change the data structure for this to pass, no?
/assign After read , size check would be a way to solve this problem. I try to fix this in
/sig apimachinery /remove-sig testing sig testing owns the frameworks, infrastructure, etc. SIG api-machinery owns their unit tests / client-go
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig apimachinery /remove-sig testing 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
/sig api-machinery
/triage accepted
Change:
t.Fatal(err) } <ins> var extenders []framework.Extender for ii := range test.extenders { extenders = append(extenders, &test.extenders[ii]) } </ins> sched := &Scheduler{ Cache:                    cache, nodeInfoSnapshot:         snapshot, percentageOfNodesToScore: schedulerapi.DefaultPercentageOfNodesToScore, <ins> Extenders:                extenders, </ins> } sched.applyDefaultHandlers()

Discussion:
When Extender filters out some Nodes, we don't set any unschedulable plugins at all. It means Extender is completely ignored during the requeueing process. So, what's happening is: If Extender filters out all Nodes during scheduling, this Pod is soon retried because this Pod doesn't have any plugin name in unschedulable plugins. If Extender filters out some Nodes during scheduling and plugins filter out all other Nodes, this Pod is retried based on plugins' QueueingHint. Even if any cluster events happen and it could change Extender's decision (but not any plugins' decision), this Pod won't be requeued to activeQ/backoffQ. The latter case is serious because it could make Pods being stuck in unschedulable pod pool in 5min. We should have a short-term solution for the latter case. We can requeue Pods, which were rejected by Extender, by any kind of cluster events because we cannot know which events make Pods schedulable. Eventually, this issue makes us wonder how Pods rejected by Extender should be requeued. We cannot implement QHint equivalent in Extenders because it'd be too slow to call Extender every time any cluster events happen. Probably, somehow implementing EventsToRegister equivalent in Extender? Use Extender which does something in Filter. No response master <detailsn/a </details<details</details<details</details<details</details<details</details
/assign
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 scheduling
/reopen We'll close it when all cherry-picks are done.
Reopened this issue. <detailsIn response to : /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
/close Cherry-picks are done.
Change:
// if the number of consecutive read failure equals or exceeds the failureThreshold , the // configuration is regarded as not ready. failureThreshold int <ins> // number of consecutive failures so far. failures int </ins> // if the configuration is regarded as ready. ready               bool mergedConfiguration runtime.Object

Discussion:
Found in I can reproduce locally using
/assign (via git blame)
cc
Thanks. I will take a look.
Got a fix locally. Testing it.
Change:
return nil } <del> // addLivezChecks allows you to add a HealthCheck to livez. It will also automatically add a check to readyz, // since we want to avoid being ready when we are not live. func (s *GenericAPIServer) addLivezChecks(delay time.Duration, checks ...healthz.HealthChecker) error { </del> <ins> // AddLivezChecks allows you to add a HealthCheck to livez. func (s *GenericAPIServer) AddLivezChecks(delay time.Duration, checks ...healthz.HealthChecker) error { </ins> s.livezLock.Lock() defer s.livezLock.Unlock() if s.livezChecksInstalled {

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : When using GenericAPIServer you can only add new checks via function which adds them to all , , and endpoints. All other methods like are private. I would like to request those methods to be made public: Why is this needed: Developers of apiservers should be able to define their readiness probes add them to specific endpoint of their choosing. For example in case of Metrics Server we defined probes: Readiness - Metrics cache is full. As MS serves data only from cache, traffic will be only sent after cache is full. Liveness - Metric scraping loop is not deadlocked. It doesn't make sense to have those probes to both endpoints. Not ready metric cache should not cause MS being killed via liveness probe. Delayed scrape should not cause traffic not being served from cache due failing readiness probe. /assign
/sig apimachinery
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig apimachinery 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
/sig api-machinery
/cc /triage accepted
I can see this. PR welcome.
Change:
"time" v1 "k8s.io/api/core/v1" <ins> apierrors "k8s.io/apimachinery/pkg/api/errors" </ins> "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/fields"

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 --integration test jobs TestQuotaLimitService which was recently in One example run: I suspect this is because TestQuotaLimitService runs through multiple test cases where each test case relies on state created from the previous case. However, resource quota changes take some time to get propagated on the system and the test is trying to validate acceptance of new Services before the resource quota controller applies the necessary changes. links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --
cc
/sig network /sig apimachinery
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig network /sig apimachinery 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
/sig api-machinery
Opened a fix here
/triage accepted
Change:
concurrencyLimit:       6, evalDuration:           time.Second * 20, expectedFair:           []bool{true}, <del> expectedFairnessMargin: []float64{0.1}, </del> <ins> expectedFairnessMargin: []float64{0.16}, </ins> expectAllRequests:      true, evalInqueueMetrics:     true, evalExecutingMetrics:   true,

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 --pull-kubernetes-unit TestDifferentWidths links to appreciated links to specific failures in spyglass appreciated
/sig api-machinery
/assign /cc /triage accepted
Yes, a couple of the unit tests have too stringent evaluations. See
Change:
// // If the webhook is running within the cluster, then you should use `service`. // <del> // If there is only one port open for the service, that port will be // used. If there are multiple ports open, port 443 will be used if it // is open, otherwise it is an error. </del> <ins> // Port 443 will be used if it is open, otherwise it is an error. </ins> // // +optional Service *ServiceReference `json:"service" protobuf:"bytes,1,opt,name=service"`

Discussion:
What happened: Deployed a webhook backend and service as follows: Please note that there is only 8443 port on the service. Register the webhook as follows: Got the following error when creating pods: What you expected to happen: Based on , should be called. Not the 443 port shown in the error message. How to reproduce it (as minimally and precisely as possible): Just deploy the same setup and register webhook. Anything else we need to know?: Environment: Kubernetes version (use ): HEAD Client Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.0-alpha.1.97+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2018-01-22T20:00:24Z", GoVersion:"go1.9.1", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.0-alpha.0.470+", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-03-12T19:36:42Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): COS Kernel (e.g. ): COS
thanks for the detailed bug report!
I actually think that the API specification (or documentation) must change. Not all API servers will have access to look up the Service object and see what ports it defines. If we want to support ports other than 443, the port information must be specified in the webhook object, not discovered by direct Service object lookup
/assign
Looks like it will always use 443 no matter what ports are available, right? Should our documentation reflect this or should it behave differently? (also just sets 443 in the custom dial wrapper thing )
As a first step, I would adjust the documentation. As noted in , if we want to support ports other than 443, that information needs to be to the webhook config object
Change:
return err } <del> dataDir := filepath.Dir(deviceMountPath) if err := os.MkdirAll(dataDir, 0750); err != nil { glog.Error(log("attacher.MountDevice failed to create dir %#v:  %v", dataDir, err)) </del> <ins> // Store volume metadata for UnmountDevice. Keep it around even if the // driver does not support NodeStage, UnmountDevice still needs it. if err = os.MkdirAll(deviceMountPath, 0750); err != nil { glog.Error(log("attacher.MountDevice failed to create dir %#v:  %v", deviceMountPath, err)) </ins> return err } <ins> glog.V(4).Info(log("created target path successfully [%s]", deviceMountPath)) dataDir := filepath.Dir(deviceMountPath) </ins> data := map[string]string{ volDataKey.volHandle:  csiSource.VolumeHandle, volDataKey.driverName: csiSource.Driver, } <del> if err := saveVolumeData(dataDir, volDataFileName, data); err != nil { </del> <ins> if err = saveVolumeData(dataDir, volDataFileName, data); err != nil { </ins> glog.Error(log("failed to save volume info data: %v", err)) <del> if err := os.RemoveAll(dataDir); err != nil { glog.Error(log("failed to remove dir after error [%s]: %v", dataDir, err)) return err </del> <ins> if cleanerr := os.RemoveAll(dataDir); err != nil { glog.Error(log("failed to remove dir after error [%s]: %v", dataDir, cleanerr)) </ins> } return err } <ins> defer func() { if err != nil { // clean up metadata glog.Errorf(log("attacher.MountDevice failed: %v", err)) if err := removeMountDir(c.plugin, deviceMountPath); err != nil { glog.Error(log("attacher.MountDevice failed to remove mount dir after errir [%s]: %v", deviceMountPath, err)) } } }() </ins> if c.csiClient == nil { c.csiClient = newCsiDriverClient(csiSource.Driver)

Discussion:
/kind bug /sig storage What happened: When using a CSI driver that does not support NODESTAGE, I can see orphan json files in that are never cleaned up. What you expected to happen: No orphan file /assign
Change:
# If you want to build AND push all containers, see the 'all-push' rule. all: all-container <ins> all-push: all-push-images push-manifest push-manifest: manifest-tool manifest-tool push from-args --platforms $(call join_platforms,$(ALL_ARCH)) --template $(IMAGE)-ARCH:$(TAG) --target $(IMAGE):$(TAG) </ins> sub-container-%: $(MAKE) ARCH=$* container

Discussion:
<!-- 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 feature This issue if for tracking the work related to pushing manifest list for kubernetes images(infra and test) List of images for which manifest need to be created: - [x] kubernetes to use manifest pause image - [x] dns - - - - - [ ] dashboard [x] Manifest images for k8s release images -
/assign
/cc
/sig cluster-lifecycle
/sig testing
/area test-infra /sig release
/reopen
I'd add dashboard to this as well, based off the issue at
can you provide a status update on this issue? I'd really want this fully working in v1.10... :)
I've created one more PR for pushing manifest for few more images, reference - I'll try my best to push into v1.10 release
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
/remove-lifecycle stale
/remove-lifecycle rotten
A problem related to manifests and was addressed here:
An update of this issue would be welcomed to track the status of all affected images, since I think at least some of the linked issues have progressed.
/sig testing
all the k8s core images are now fat manifest, hence closing this task. Will create a separate task for creating manifest for ecosystem images(e.g dashboard, metric-server etc...)
did you have a issue open tracking other images? I noticed today that kube-addon-manager (cluster/addons/addon-manager) is multi-arch but not using a manifest list yet.
Change:
streams, _, buf, _ := genericclioptions.NewTestIOStreams() cmd := NewCmdConfig(cmdutil.NewFactory(genericclioptions.NewTestConfigFlags()), clientcmd.NewDefaultPathOptions(), streams) <ins> // "context" is a global flag, inherited from base kubectl command in the real world cmd.PersistentFlags().String("context", "", "The name of the kubeconfig context to use") </ins> cmd.SetArgs(argsToUse) cmd.Execute() <del> // outBytes, _ := ioutil.ReadFile(fakeKubeFile.Name()) </del> config := clientcmd.GetConfigFromFileOrDie(fakeKubeFile.Name()) return buf.String(), *config }

Discussion:
/kind bug What happened: Current context was set to cluster1. Ran and got back information about cluster1 instead. What you expected to happen: I expected the output to be the cluster2 information How to reproduce it (as minimally and precisely as possible): Have two contexts in your kube config, A and B Run to set A as current context Run Anything else we need to know?: I'd like to help contribute, so if this is an easy fix, someone point me in the right direction and I'll try to get it done. Environment: Kubernetes version (use ): 1.10.2 OS (e.g. from /etc/os-release): MacOS 10.11.6 Install tools: kubectl was installed via brew
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
/assign Filed
Change:
import ( "fmt" "io" <ins> "sort" </ins> "k8s.io/apimachinery/pkg/api/resource" "k8s.io/kubernetes/pkg/api"

Discussion:
and node should sort by namespace / name so that results don't jump around. We should consider adding sort, but only after we make a stable sort the default.
next Also, why does it sometimes lose nodes? Annoying
I did not reproduce this. I think this may be caused by the monitoring timeout of heapster. So that the data got missing.