jiebi/CodeConvo huggingface dataset:
Change:
export CONTEXT="ubuntu" export KUBE_SERVER="http://${KUBE_MASTER_IP}:8080" <del> source "${KUBE_ROOT}/cluster/common.sh" </del> # set kubernetes user and password load-or-gen-kube-basicauth

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: I was following to install a cluster but failed due to the following. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else do we need to know:
The current workaround solution is remove in ./kube-
please have a look
thanks for the quick response
Just FYI, I think that you should fix both kube-up and kube-down
i have already move: source "${KUBE_ROOT}" to the head of ,is there something can't work?
Thanks, I did not have a try but just a reminder, just check code, yes, I think it works. Thanks
Seems the kube-up still does not work, filed another issue here
can you help take a look? Thanks!
/sig cluster-lifecycle
hi, I still see the issue but wondering since you have closed considering planned deprecation of the script. Does this issue still requires a fix or any decision was made not to work on it? Thanks!
Thanks , I think that we can close this now as it is not supported any more.
sure and thank you for the quick response and closing it !!
Change:
func Register(registry k8smetrics.KubeRegistry) { registry.Register(healthcheck) registry.Register(healthchecksTotal) <ins> _ = k8smetrics.RegisterProcessStartTime(registry.Register) </ins> } func ResetHealthMetrics() {

Discussion:
/metrics/slis was for several components (apiserver, kube-controller-manager, kube-scheduler, kubelet, cloud-controller-manager) in This is to propose adding metric to these components for /metrics/slis to support cumulative metric Missing start time metric in metrics/slis will result in inaccurate cumulative metrics. Even though the start time metric is available in /metrics, it requires the metrics collector to scrape two endpoints at once and sync them to prepare the cumulative metric data.
/sig instrumentation
/assign cc /triage accepted
I just ran into an issue related to this change while adding scrapers to /metrics/slis in kube-prometheus The components /metrics and /metrics/slis endpoints are supposed to be scraped together, but at different intervals and this is really possible anymore since we the metric to the /metric/slis endpoint since now both endpoints are exposing the same metric which causes a conflict when scraped by Prometheus. Instead of exposing the metric inside of the endpoint, I think we should rather expect users to correlate the metric with the process start time metric from the endpoint. Because otherwise, we have to explicitly drop the metric at scrape time from the SLI endpoint in order to avoid conflicts.
We can't not include it, what if people opt only to scrape ?
That's a fair point, but do we really need to make use of the cumulative metric? Computing an error rate from it shouldn't require a start time, and even in the event of a restart, it should be transparent to the computation of the rate.
Yes, you need process-start-time in order to know when a process has restarted otherwise a cumulative metric could be (1) not cumulative going from 2 -1, (2) be cumulative but not measured as such if you measure 1 at process-start-time A, and then you measure 1 again at process-start-time B, but you ignore process-start-times.
Change:
utilerrors "k8s.io/apimachinery/pkg/util/errors" runtimeapi "k8s.io/kubernetes/pkg/kubelet/apis/cri/runtime/v1alpha2" "k8s.io/kubernetes/pkg/kubelet/checkpointmanager" <ins> "k8s.io/kubernetes/pkg/kubelet/checkpointmanager/errors" </ins> kubecontainer "k8s.io/kubernetes/pkg/kubelet/container" "k8s.io/kubernetes/pkg/kubelet/dockershim/libdocker" "k8s.io/kubernetes/pkg/kubelet/qos"

Discussion:
/kind bug are failing. seems like the likely cause. cc /assign
ping
seems one test still failing.
Change:
podName  = "pod-" + string(uuid.NewUUID()) pod      = testPodWithROVolume(podName, source, volumePath) ) <ins> pod.Spec.NodeSelector = map[string]string{ "kubernetes.io/os": "windows", } pod = f.PodClient().CreateSync(pod) ginkgo.By("verifying that pod has the correct nodeSelector") framework.ExpectEqual(pod.Spec.NodeSelector["kubernetes.io/os"], "windows") </ins> <del> f.PodClient().CreateSync(pod) </del> cmd := []string{"cmd", "/c", "echo windows-volume-test", ">", filePath} _, stderr, _ := f.ExecCommandInContainerWithFullOutput(podName, containerName, cmd...) framework.ExpectEqual(stderr, "Access is denied.") } func doReadWriteReadOnlyTest(f *framework.Framework, source v1.VolumeSource, volumePath string) {

Discussion:
similar to PR en route
/sig windows
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
Change:
} } <ins> for _, turnOff := range []bool{true, false} { // Turn off for checking if exist return true if turnOff { _, _ = vm.PowerOff(ctx) } exist, err := vm.Exists(ctx) if err != nil { t.Error(err) } if !exist { t.Errorf("exist=%t, expected=%t", exist, true) } // Turn back on if turnOff { _, _ = vm.PowerOn(ctx) } } </ins> for _, expect := range []bool{true, false} { active, err := vm.IsActive(ctx) if err != nil {

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: We have k8s cluster with version . And I noticed that if I deleted worker node VM from IAAS, then node stuck in state, I created statefulset before and the pod scheduled on that node was stuck in state, and no new pod was created to replace that. Node should be deleted if no instance is found Related log When I check the log of I could see following log keeps popping up. Looks like node_controller noticed that the VM is gone but it doesn't delete the node. Related code here will return if no instance is found. But it should check if it's VM is deleted not shutdown, then return And it should cherry pick this fix avoiding deleting shutdown node What you expected to happen: After VM is deleted, the node should be deleted, pods assigned to the node should be rescheduled to other available nodes How to reproduce it (as minimally and precisely as possible): k8s cluster. In our case we use PKS. workloads on node worker node VM from IAAS Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: vSphere Cloud Provider
/sig cloud-provider /sig vmware
Same issue as this one The issue and is cluster API repo. We should fix it inside node_controller in k/k
Hi this issue was found when testing windows cluster deployed using PKS. We do have a workaround by manually deleting node using kubectl. Still we wish the fix could go in ASAP. Could you ask someone from upstream to to review the PR that fix this issue? Thank you
, we will try to push this through for v1.20. 1.19 is approaching code thaw, so we can't push this through
Thanks Michael. I'll let my team know.
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
/remove-lifecycle stale
Change:
} // Return the plugin's client pod spec. Use an InitContainer to setup the file i/o test env. <del> func makePodSpec(config framework.VolumeTestConfig, dir, initCmd string, volsrc v1.VolumeSource, podSecContext *v1.PodSecurityContext) *v1.Pod { volName := fmt.Sprintf("%s-%s", config.Prefix, "io-volume") </del> <ins> func makePodSpec(config framework.VolumeTestConfig, initCmd string, volsrc v1.VolumeSource, podSecContext *v1.PodSecurityContext) *v1.Pod { </ins> var gracePeriod int64 = 1 <ins> volName := fmt.Sprintf("io-volume-%s", config.Namespace) </ins> return &v1.Pod{ TypeMeta: metav1.TypeMeta{ Kind:       "Pod",

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: [sig-storage] In-tree Volumes [Driver: hostPath] [Testpattern: Inline-volume (default fs)] volumeIO should write files of various sizes, verify size, validate content [Slow] Since when has it been failing: 11/13 Testgrid link: https://k8s- Reason for failure: Anything else we need to know: This is consistently failing in 1.13 branch and is release blocking. <!-- DO NOT EDIT BELOW THIS LINE --/kind failing-test /sig storage /priority critical-urgent /milestone v1.13 /assign /cc
The test case is failing because it wrote 2MB instead of the expected 1MB. It's also very odd that the test is failing in soak, but passing in regular CI suites.
There's a few problems: .GetVolumeSource returns "/tmp" for everything. This means all tests will share the same directory. This should be probably use some unique directory instead volume IO test generates a unique mountPath directory, however that doesn't mean a unique directory is actually created on the host. Ie, a mountPath of "/a/b/c" on a hostpath volume at "/tmp" doesn't mean directory "/tmp/a/b/c" is created. io test file name is not unique seems like the IO test is not cleaning up the files it creates, so the files are getting reused on subsequent tests due to the non-unique naming issues.
The other thing I can't explain is why it's failing only now
Fix is here:
As per discussion in 1.13 burndown this morning, this is a test job issue and its not release blocking at this point. So we can take this fix in 1.14 as opposed now during code freeze let us know if you feel otherwise
/milestone v1.14 /priority important-soon
/remove-priority critical-urgent
Change:
"k8s.io/api/admissionregistration/v1beta1" "k8s.io/apimachinery/pkg/api/meta" "k8s.io/apimachinery/pkg/runtime/schema" <ins> utilruntime "k8s.io/apimachinery/pkg/util/runtime" </ins> "k8s.io/apimachinery/pkg/util/sets" "k8s.io/apimachinery/pkg/util/validation/field" "k8s.io/apimachinery/pkg/util/version"

Discussion:
When I load a policy definition like this The object is updated with the following status While this error is reported, the policy does seem to be fully functioning This is similar to the documented examples No error reported on a valid spec Create a a policy that uses variables Observe the status of the newly created policy No response <details</details<detailsn/a </details<details</details<detailskind </details<details</details<details</details
/sig api-machinery
/assign Oops. Good find. Thank you. /triage accepted
Change:
// that we should check is if the "pod" is failing to schedule due to pod affinity // failure. // TODO(bsalamat): Consider checking affinity to lower priority pods if feasible with reasonable performance. <del> if fits, _, err := podFitsOnNode(pod, meta, nodeInfoCopy, fitPredicates, nil, queue, false); !fits { </del> <ins> if fits, _, err := podFitsOnNode(pod, meta, nodeInfoCopy, fitPredicates, nil, queue, false, nil); !fits { </ins> if err != nil { glog.Warningf("Encountered error while selecting victims on node %v: %v", nodeInfo.Node().Name, err) }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Today, . This seems unnecessary and should be done once for all the nodes. Is this a BUG REPORT or FEATURE REQUEST?: /kind enhancement /sig scheduling cc:
/assign Thanks, will send fix per slack discussion.
/cc
Change:
// update the status condition to false. The function returns a bool to let the // caller know if the list was changed (either appended or updated). func ensureJobConditionStatus(list []batch.JobCondition, cType batch.JobConditionType, status v1.ConditionStatus, reason, message string) ([]batch.JobCondition, bool) { <del> for i := range list { if list[i].Type == cType { if list[i].Status != status || list[i].Reason != reason || list[i].Message != message { list[i].Status = status list[i].LastTransitionTime = metav1.Now() list[i].Reason = reason list[i].Message = message return list, true } return list, false </del> <ins> if condition := findConditionByType(list, cType); condition != nil { if condition.Status != status || condition.Reason != reason || condition.Message != message { *condition = *newCondition(cType, status, reason, message) return list, true </ins> } <ins> return list, false </ins> } // A condition with that type doesn't exist in the list. if status != v1.ConditionFalse {

Discussion:
If the user update , duplicate condition: ! Only one Failed condition Create Job and wait it marked as Failed Update the Failed condition to False No response <details</details<details</details<details</details<details</details<details</details<details</details
It's not a bug. The is a list, so it can contain many conditions with different probe timestamps. Also, we should not update the fields.
But should we avoid the duplicate Type's conditionIn my opinionthis will confuse the user. According to kubelet, it will rewrite the 'Ready' condition in pod, and take is as managed only by kubelet. Should we did this for job Failed condition? Refer:
/sig apps
It is a bug. We should only have one condition for each type. /triage accepted
/assign
/assign
/assign
I have reproduced the issue locally and intend work on the fix
/priority backlog Since the user is manually modifying the status, this is not an inherent bug in the controller. Still worth avoiding duplicates.
Change:
echo '    make test-integration' echo echo "The following invocation will run a specific test with the verbose flag set: " <del> echo '    make test-integration WHAT=./test/integration/pods KUBE_GOFLAGS="-v" KUBE_TEST_ARGS="-run ^TestPodUpdateActiveDeadlineSeconds$"' </del> <ins> echo '    make test-integration WHAT=./test/integration/pods GOFLAGS="-v" KUBE_TEST_ARGS="-run ^TestPodUpdateActiveDeadlineSeconds$"' </ins> echo exit 1

Discussion:
We should just use GOFLAGS
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 contributor-experience
/assign
Change:
framework.ExpectEqual(namespace.ObjectMeta.Labels["testLabel"], "testValue", "namespace not patched") }) <del> ginkgo.It("should apply changes to a namespace status", func() { </del> <ins> /* Release: v1.25 Testname: Namespace, apply changes to a namespace status Description: Getting the current namespace status MUST succeed. The reported status phase MUST be active. Given the patching of the namespace status, the fields MUST equal the new values. Given the updating of the namespace status, the fields MUST equal the new values. */ framework.ConformanceIt("should apply changes to a namespace status", func() { </ins> ns := f.Namespace.Name dc := f.DynamicClient nsResource := v1.SchemeGroupVersion.WithResource("namespaces")

Discussion:
[x] test approval issue : [x] test pr : [x] two weeks soak end date : 1 Aug 2022 [x] test promotion pr : According to this APIsnoop query, there is still some remaining NamespaceStatus endpoints which are untested. readCoreV1NamespaceStatuspatchCoreV1NamespaceStatus Using a number of existing e2e test practices a new has been created for 2 namespace status endpoints. The e2e logs for this test are listed below. This query shows the endpoints hit within a short period of running the e2e test If a test with these calls gets merged, test coverage will go up by 3 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
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
Change:
return err } mapper, typer := f.Object() <del> r := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand(cmd)). </del> <ins> r := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand()). </ins> ContinueOnError(). NamespaceParam(cmdNamespace).DefaultNamespace(). FilenameParam(filenames...).

Discussion:
I think the need for this argument to the factory methods has passed - it means that callers who want to provide configurable behavior have to do it through the factory itself, which is acceptable. We can remove it whenever.
I removed most of the unused arguments. But, There are a few methods still using the argument. Namely, , , and . Before proceeding any further I wanted to ask what should be done about these methods? Deprecated/Refactored/Removed ?
The factory methods were the most important. The pattern before was people using the flags by name (cmd.Flags().Get("foo")), but now factory methods must use pointer flag vars, so there's nothing that should need the command there. The printer methods are optional units that can be used when you add the flags for them to your command. Unless we refactor the definition of those flags to use pointers and return a printer struct (something I had started a while back and never finished), it's not worth changing them right now. The other consumer of factory is OpenShift - we wrap the factory to add our additional types (implementations of things like describers, action verbs, etc): - but we will pick up and remove use of cmd when we rebase.
Thanks for the explanation. I've cleaned the as well. Print method APIs are untouched as you suggested.
cc
Looks like this was done by PR
Change:
creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults <ins> name: system:aws-cloud-provider roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:aws-cloud-provider subjects: - kind: ServiceAccount name: aws-cloud-provider namespace: kube-system - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults </ins> name: system:basic-user roleRef: apiGroup: rbac.authorization.k8s.io

Discussion:
Recently introduced fix of tainting the node if EBS volume on a node is stuck for too long in "attaching" state does not work on RBAC enabled clusters because of missing service account permissions. /sig storage /sig aws
Change:
needToSetNewMapValue := currMapValue.Kind() == reflect.Invalid if needToSetNewMapValue { <ins> if unset { return fmt.Errorf("current map key `%v` is invalid", mapKey.Interface()) } </ins> currMapValue = reflect.New(mapValueType.Elem()).Elem().Addr() actualCurrValue.SetMapIndex(mapKey, currMapValue) }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): 1.5.3 Environment: Cloud provider or hardware configuration: minikube 0.17.1 How to reproduce it (as minimally and precisely as possible): config Note that there's only one context. the property of a non-existent context config Note that a context named foo was created just because I tried to unset a property. What you expected to happen: should give an informative message saying that context doesn't exist. Anything else we need to know: This is probably low-hanging fruit.
/sig cli
/assign i will take a look for this
GitHub didn't allow me to assign the following users: a, look, for, this, i, will, take. Note that only can be assigned. <detailsIn response to : /assign i will take a look for this 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
i can reproduce this, this is a bug, have open PR fix this. thanks
/kind bug
Change:
} loadBalancerIP := service.Spec.LoadBalancerIP <del> if loadBalancerIP != "" { </del> <ins> if loadBalancerIP != "" && internalAnnotation { </ins> createOpts.VipAddress = loadBalancerIP }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Currently openstack cloud provider just support for specifying internal LoadBalancerIP. I think that is unreasonable, actually user just use a floating ip to access a LoadBalancer service. So it is necessary to spport for specifying external LoadBalancerIP. What you expected to happen: Support for specifying external LoadBalancerIP on openstack Anything else we need to know?: Currently LoadBalancerIP can be specified in service.Spec.LoadBalancerIP, we can add annotation to distinguish between internal and external.
/sig openstack /assign I'd like to work for it.
Change:
// (+optional) Annotations defines the PVC's annotations type PersistentVolumeClaimConfig struct { <del> AccessModes []v1.PersistentVolumeAccessMode Annotations map[string]string Selector    *metav1.LabelSelector </del> <ins> AccessModes      []v1.PersistentVolumeAccessMode Annotations      map[string]string Selector         *metav1.LabelSelector StorageClassName *string </ins> } // Clean up a pv and pvc in a single pv/pvc test case.

Discussion:
For statically created PVs, the persistent volume label admission controller adds the zone label to the PV object. If the admission controller is not enabled or has some bugs, then an e2e test would be helpful for catching these errors. /assign
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
Change:
var iscsiTransport string var lastErr error <del> out, err := b.exec.Run("iscsiadm", "-m", "iface", "-I", b.Iface, "-o", "show") </del> <ins> out, err := b.exec.Run("iscsiadm", "-m", "iface", "-I", b.InitIface, "-o", "show") </ins> if err != nil { <del> klog.Errorf("iscsi: could not read iface %s error: %s", b.Iface, string(out)) </del> <ins> klog.Errorf("iscsi: could not read iface %s error: %s", b.InitIface, string(out)) </ins> return "", err }

Discussion:
What happened: When creating a block volume, the iSCSI storage plugin stores volume-related data in different directories: As a result, some data is not cleaned up once the volume is detached: How to reproduce it (as minimally and precisely as possible): These are the objects I used to reproduce this issue: pod- /sig storage CC
/assign