jiebi/CodeConvo huggingface dataset:
Change:
"k8s.io/apimachinery/pkg/runtime/schema" "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/intstr" <ins> utilrand "k8s.io/apimachinery/pkg/util/rand" </ins> "k8s.io/apimachinery/pkg/util/wait" "k8s.io/apimachinery/pkg/watch" "k8s.io/client-go/dynamic" clientset "k8s.io/client-go/kubernetes" appsclient "k8s.io/client-go/kubernetes/typed/apps/v1" watchtools "k8s.io/client-go/tools/watch" <ins> "k8s.io/client-go/util/retry" </ins> appsinternal "k8s.io/kubernetes/pkg/apis/apps" deploymentutil "k8s.io/kubernetes/pkg/controller/deployment/util" "k8s.io/kubernetes/test/e2e/framework"

Discussion:
[X] Test PR: kuberenetes/kubernetes [x] Two weeks soak end date: 1 July 2021 [x] Test promotion PR: kubernetes/kubernetes According to this APIsnoop query, there are still some remaining StatefulSet endpoints which are untested. Create a watch to track deployment events. Create a deployment with a static label. Confirm that the pods are running. Get the deployment status. Parse the response and confirm that the deployment status conditions can be listed. Update the deployment status. Confirm via the watch that the status has been updated. Patch the deployment status. Confirm via the watch that the status has been patched. Using an existing as a template for a new for deployment lifecycle test. 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 1 point This test is also created with the goal of conformance promotion. /sig apps /sig testing /sig architecture /area conformance
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
/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 job, nil } <del> // Return Unix Epoch Time </del> <ins> // getTimeHash returns Unix Epoch Time </ins> func getTimeHash(scheduledTime time.Time) int64 { return scheduledTime.Unix() }

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 What happened: There are some unused commet, these are meaningless. And some function‘s comment does not follow go style. What you expected to happen: We should delete them all. and fix comment following golang style How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/assign
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
can you edit the PR description in to say instead of ? That would automatically close this issue once the PR is merged. :)
OK, no problem~:)
Change:
}, }, }, false}, <ins> {api.Node{ ObjectMeta: metav1.ObjectMeta{ Name: "update-provider-id-when-not-set", }, }, api.Node{ ObjectMeta: metav1.ObjectMeta{ Name: "update-provider-id-when-not-set", }, Spec: api.NodeSpec{ ProviderID: "provider:///new", }, }, true}, {api.Node{ ObjectMeta: metav1.ObjectMeta{ Name: "update-provider-id-when-set", }, Spec: api.NodeSpec{ ProviderID: "provider:///old", }, }, api.Node{ ObjectMeta: metav1.ObjectMeta{ Name: "update-provider-id-when-set", }, Spec: api.NodeSpec{ ProviderID: "provider:///new", }, }, false}, </ins> } for i, test := range tests { test.oldNode.ObjectMeta.ResourceVersion = "1"

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Follow up for , With the change for cloud-controller-manager updating providerID, the is to be updated. But it will fail later in node update call: Should also check validation rule: By adding following line will do the trick. But this will also allow users to manually edit node's providerID Shall we enforce that only cloud-controller-manager can update the providerID? What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?:
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 cluster-lifecycle
cc
/area cloudprovider
being able to update seems pretty reasonable to me. Can you get a PR in for that since we're close to code freeze?
cc
I found this issue when validating against a cluster running azure cloud provider, could you please also check whether it is the same case from you side? serves somewhat like an identity for nodes, thus it wouldn't expect arbitrarily updating. A compromise proposal is to allow updates when the value is not set. This gives controller manager a chance to set it during node register. Created as a fix proposal.
thanks for the patch, I think I'll have some time this weekend to verify this fix!
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/cluster-lifecycle: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</a</details
Change:
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips tallclair </del> <ins> andrewsykim danwinship dcbw lachie83 thockin </ins>

Discussion:
The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the kube-proxy repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon
/sig network These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign
Can I list you folks? Anyone else who wants to be in?
count on me if you need more people
Change:
apps/v1/Deployment apps/v1/ReplicaSet apps/v1/StatefulSet <del> extensions/v1beta1/Ingress </del> <ins> networking.k8s.io/v1/Ingress </ins> ) else read -ra KUBECTL_PRUNE_WHITELIST <<< "${KUBECTL_PRUNE_WHITELIST_OVERRIDE}"

Discussion:
What happened: Sweeping uses of extensions/v1beta1 in preparation for , the addon manager stood out as using extensions/v1beta1 Ingress by default: What you expected to happen: All components shipped in 1.21 must use Ingress in order to work properly against a 1.22 API server. /sig networking cc per cluster/addons/addon-manager/OWNERS cc I'm not sure what the addon manager does if given a prune list of Ingress objects while still using a manifest containing extensions/v1 Ingress objects... this needs to be tested. /milestone v1.21 /priority important-soon /lifecycle frozen
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : What happened: cc /priority important-soon /lifecycle frozen 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 network
/triage accepted
how "urgent" is this? Can wait until next tuesday? Otherwise I can work on the tests this weekend :)
important, not urgent. it should happen early in the 1.21 cycle, but does not require work out of business hours
Hello! I am from the Bug Triage team! This issue has not been updated for a few weeks, so I'd like to check on the status. Code freeze is starting March 9th, 2021 (about 1 week from now). We want to ensure that each PR has a chance to be merged before code freeze. As the Issue is tagged for 1.21, is it still planned for this release?
we're waiting to the PR to get merged :) I guess it's important for the v1.21 release, for the sake of extensions apiGroup deprecation :) Will ping reviewers on the PR
Change:
domain:           domain, cache:            NewTreeCache(), cacheLock:        sync.RWMutex{}, <ins> nodesStore:       kcache.NewStore(kcache.MetaNamespaceKeyFunc), </ins> reverseRecordMap: make(map[string]*skymsg.Service), domainPath:       reverseArray(strings.Split(strings.TrimRight(domain, "."), ".")), federations:      federations,

Discussion:
Run like so:
nodeStore doesnt seem to be set anywhere (except in tests). Thats why code panics when we access it:
cc
Sent to fix this
thx
Change:
"//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime/schema:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/util/diff:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/util/intstr:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/wait:go_default_library", "//staging/src/k8s.io/apiserver/pkg/util/feature:go_default_library",

Discussion:
bug (): Originally posted by in cc /sig network /priority critical-urgent
fix in
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Change:
// FindContainersByPod returns the containers that belong to the pod. func (c DockerContainers) FindContainersByPod(podUID types.UID, podFullName string) DockerContainers { containers := make(DockerContainers) for _, dockerContainer := range c { if len(dockerContainer.Names) == 0 { continue

Discussion:
Observed in testing somehting unrelated - prio We need a test that captures this - we can't let this slip through, Maybe same as ?
I just reproduced this with newly built cluster from HEAD. This is definitely a regression introduced lately. Will look into it in detail.
Change:
job.Status.CompletedIndexes = succeededIndexes.String() } job.Status.UncountedTerminatedPods = nil <del> jm.enactJobFinished(&job, finishedCondition) </del> <ins> jobFinished := jm.enactJobFinished(&job, finishedCondition) </ins> if _, err := jm.updateStatusHandler(ctx, &job); err != nil { return forget, err } <ins> if jobFinished { jm.recordJobFinished(&job, finishedCondition) } </ins> if jobHasNewFailure && !IsJobFinished(&job) { // returning an error will re-enqueue Job after the backoff period

Discussion:
Occasionally job completions are counted twice (or potentially multiple times?) in the metric. This happens for about 20% of jobs, but may depend on the Job specificity, which results in an overestimation of the number of finished jobs. The metric reflects the actual number of completed jobs. a kind cluster with prometheus monitoring stack (for example follow this: ). the number of completed jobs by inspecting the metric and delete a job multiple times in a loop Example job: Example repro script: . Check the number of completed jobs by inspecting the metric and the job Yes, in the kube-controller-logs we find the following log lines which are related and probably indicate repeated updated which results in double counting. <details</details<detailsReproducible with kind </details<details</details<details</details<details</details<details</details
/assign
FYI
/sig apps
/triage accepted
Change:
"syscall" "time" <del> "k8s.io/apimachinery/pkg/apis/meta/v1" </del> <ins> v1 "k8s.io/apimachinery/pkg/apis/meta/v1" </ins> statsapi "k8s.io/kubelet/pkg/apis/stats/v1alpha1" )

Discussion:
PIDPressure is not set to true when the system has insufficient pid resource. PIDPressure is set to true correctly when the system is insufficient in pid resource. See cause below The max pid is not solely controlled by which is referred by . But it is also controlled by (whichever is smaller). However, they have different semantics resulting in the same constraint to how many processes/threads can be running on the system. <details</details<details</details<details</details<details</details<details</details<details</details
/sig node
I asked the same issue before,
My opinion: the minimum of and is the right number to count, for Linux. That will provide better instrumentation. If you're reserving a number of task IDs (PIDs) for system use, that minimum is the number that you're reserving from.
/triage accepted /priority important-longterm
/retitle System maximum PID inconsiderate of sysctl 'threads-max'
BTW I made a thing that might help folks test a fix: Originally I used it to create PIDs, to test whether apps cope with long PIDs. This version keeps the threads around so that you see them in .
Change:
// Total number of available pods (ready for at least minReadySeconds) targeted by this statefulset. // This is a beta field and requires enabling StatefulSetMinReadySeconds feature gate. <ins> // +optional </ins> AvailableReplicas int32 }

Discussion:
Looking at the for , it defines as a required attribute. But looking at the of , it states . Should this in fact be a required attribute? I come about this from using , a python package that generates models from the swagger definitions and thus builds a that requires an attribute that is not enabled. That only truly required attributes be required in the swagger definition Reproduction is not applicable as this is an issue with a spec No response Appeared in 1.22 (I believe) and affects current versions. Does not affect 1.21 n/a No response No response No response No response
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
alpha: has that is planned for removal in beta. ( results in fields as non-required in the OpenAPI) beta: removes the this might be a question whether feature gate controlled fields must remain until the feature gate is removed (and how would validation work in that case). ~old feature gates graduations to beta enabled a feature by default.~ a topic related to ? but it does not apply to feature gates. /kind documentation /sig apps
cc (since you are the author)
new fields to existing types must always be marked as +optional, since clients are not required to specify them
please open a PR adding back the +optional tag, regenerate openapi, and open picks back to 1.23 and 1.22
Change:
envArray: []string{ "WITH_OUT_VALUES=", }, <del> expected:  []api.EnvVar{}, expectErr: true, </del> <ins> expected: []api.EnvVar{ { Name:  "WITH_OUT_VALUES", Value: "", }, }, expectErr: false, </ins> test:      "test case 3", }, {

Discussion:
It should be possible to pass empty environment variables to pods run by env (to clear an env var set inside the image, for example). is valid syntax for "set env var FOO to empty string".
Change:
} errs = append(errs, err) } <del> if len(infos) == 0 { </del> <ins> if len(infos) == 0 && len(errs) == 0 { </ins> outputEmptyListWarning(errOut) }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): bug Kubernetes version (use ): master What happened: is printed when error. What you expected to happen: Only error message was printed.
I believed this has been fixed
, it seems not; in , it's not necessary to print if errs is not empty. Refer to the PR on the proposal :).
ok, seems other issue.
Change:
}) ginkgo.By("Giving the Kubelet time to start up and produce metrics") <del> gomega.Eventually(ctx, getKubeletMetrics, 1*time.Minute, 15*time.Second).Should(matchResourceMetrics) </del> <ins> gomega.Eventually(ctx, getKubeletMetrics, 2*time.Minute, 10*time.Second).Should(matchResourceMetrics) </ins> ginkgo.By("Ensuring the metrics match the expectations a few more times") <del> gomega.Consistently(ctx, getKubeletMetrics, 1*time.Minute, 15*time.Second).Should(matchResourceMetrics) </del> <ins> gomega.Consistently(ctx, getKubeletMetrics, 2*time.Minute, 10*time.Second).Should(matchResourceMetrics) </ins> }) ginkgo.It("should not report any admission failures when the topology manager alignment is expected to succeed", func(ctx context.Context) {

Discussion:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node started to fail since 09-13.
/cc
/assign
/cc
/triage accepted /priority important-soon it's indeed failing too often
/reopen The test is still failing: Now timing out at 120s i.e. 2 minutes as we increased the default timeout . We need to understand the root cause and get to the bottom of this.
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
Snippet from the build log () corresponding from this failure We see from the above logs that: node has two numa nodes, 8 cpus per NUMA so the root cause of the failure is not because the tests are running on a node that doesn't have multi-numa support. is started and the health check fails a couple of times but eventually succeeds. pod is created with 9 cpus (cpusperNUMA +1 i.e. 8+1) which is expected to fail with Topology Affinity Error as we cannot allocate resources for such a pod from a single NUMAnode. We fail to get matching metrics. It is not clear if the check fails because we don't get kubelet metrics at all or the expected metrics but based on point 6 below it seems like it is because of latter. We can add additional logs for more clarity here. each is executed and Kubelet is restarted and health check is done. are collected from the namespace corresponding to the test pod which shows that the pod started even though it was expected to fail with Topology Affinity Error. We need to understand why the pod got successfully created even though it requested CPUs that couldn't be allocated from a single NUMAnode.
Change:
package validation import ( <ins> "fmt" </ins> "k8s.io/kubernetes/pkg/api" <ins> "k8s.io/kubernetes/pkg/api/meta" "k8s.io/kubernetes/pkg/api/unversioned" apiutil "k8s.io/kubernetes/pkg/api/util" "k8s.io/kubernetes/pkg/apimachinery/registered" </ins> "k8s.io/kubernetes/pkg/util/validation" "k8s.io/kubernetes/pkg/util/validation/field" )

Discussion:
ValidateEvent() in checks for "Node" specifically, but should really check for "any non-namespaced object.
I'd like to fix this.
Harder than it sounds, because events may reference 3rd party objects for which we don't know this piece of information...
Change:
if err != nil && err != ErrNotFound { return nil, fmt.Errorf("Error getting floating ip for port %s: %v", portID, err) } <del> if floatIP == nil && floatingPool != "" { </del> <ins> if floatIP == nil && floatingPool != "" && !internalAnnotation { </ins> glog.V(4).Infof("Creating floating ip for loadbalancer %s port %s", loadbalancer.ID, portID) floatIPOpts := floatingips.CreateOpts{ FloatingNetworkID: floatingPool, PortID:            portID, } <ins> loadBalancerIP := apiService.Spec.LoadBalancerIP if loadBalancerIP != "" { floatIPOpts.FloatingIP = loadBalancerIP } </ins> floatIP, err = floatingips.Create(lbaas.network, floatIPOpts).Extract() if err != nil { return nil, fmt.Errorf("Error creating LB floatingip %+v: %v", floatIPOpts, err)

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.