jiebi/CodeConvo huggingface dataset:
Change:
require ( github.com/coreos/etcd v3.3.15+incompatible github.com/emicklei/go-restful v2.9.5+incompatible <ins> github.com/ghodss/yaml v0.0.0-20180820084758-c7ce16629ff4 // indirect </ins> github.com/go-openapi/errors v0.19.2 github.com/go-openapi/spec v0.19.2 github.com/go-openapi/strfmt v0.19.0

Discussion:
What happened: Created a CRD with a group/version/kind that defines a CustomResourceDefinition type overlapping with the in-tree kubernetes type (WARNING: do not create this CRD on a cluster you care about, see ) Note that two definitions for the group/version/kind appear in openapi: What you expected to happen: published openapi only includes the in-tree type, which has precedence /cc /area custom-resources /priority important-soon /sig api-machinery
/cc
haven't looked into the code yet. I'd expect the naming controller / apiextensions server to prevent conflicting CR GVK, but they are unaware of builtin API groups
CRD handling is isolated to the apiextensions server... it does not have information about all other built-in and aggregated APIs
mentioned something he was working on to make the aggregation layer honor APIService priorities (so that later definitions would not be included if something had already defined a GVK) edit: possibly
a naive idea is to reserve k8s groups in a hard code way that sounds good the CRD in defines a but the kubectl results are about . Did I miss something?
oops... fixed. I started with an API type under but the issue only surfaces for specific APIs (due to the generated definition name colliding for some types)
that wouldn't address duplicate GVKs from aggregated APIs
Three kinds of openapi paths/definitions that we want to prevent CRDs from overwriting: CRD API the spec aggregation in apiextensions-apiserver allows overwriting. I will send a fix native APIs well protected. The spec aggregation in kube-aggregator: 1) ignores duplicated paths and renames duplicated definitions; 2) treats kube-apiserver with than apiextensions-apiserver APIs the spec aggregation in kube-aggregator allows overwriting. The spec aggregation in kube-aggregator treats aggregated APIs with than apiextensions-apiserver. I'm thinking about giving apiextensions-apiserver the lowest priority, but then the problem is aggregated APIs can potentially overwrite the CRD API Note that none of the above prevents CRDs from adding new subpaths to existing APIs. E.g. a CRD can add a path to the CRD API, or to a aggregated API if it didn't have one
Change:
e2eskipper.Skipf("Could not get controller-manager metrics - skipping") } <del> // Forced detach metric should be present forceDetachKey := "attachdetach_controller_forced_detaches" _, ok := updatedControllerMetrics[forceDetachKey] if !ok { framework.Failf("Key %q not found in A/D Controller metrics", forceDetachKey) } </del> // Wait and validate totalVolumesKey := "attachdetach_controller_total_volumes" states := []string{"actual_state_of_world", "desired_state_of_world"}

Discussion:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig storage
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
3 tests seem to be failing related to sig-storage: <img width="1229" alt="image" src=""
Also see there are a few there as well
/assign
x-ref Looks like the only jobs running volume metrics tests are e2e-ci-kubernetes-e2e-cos-gce-serial-canary &e2e-ci-kubernetes-e2e-al2023-aws-serial-canary... In that PR we are trying to make those tests run in for kind clusters and gce-serial. Therefore [sig-storage] [Serial] Volume metrics PVC should create metrics for total number of volumes in A/D Controller has likely been broken for a while. Is the metric for being emitted in that test at all? I printed the metricsGrabber results while running test on a kOps cluster and only saw . Could have printed wrong though*
Thanks for dumping the metrics, good call. Could we be dealing with a logical error in the test? I would expect that the only requirement for passing a test to be that the metric is emitted (which it is, as per the dump) It's odd to also expect in . Ideally, this validation: should be part of a separate test.
cc
Perhaps later an extra serial test where force detach is actually excercised should be . But I think the short-term question we should be trying to solve next is why the forced detach metric is not present in this test, and if that is a regression vs this test not functioning correctly for last few years since line was . ~If I were consuming these metrics, I would expect that there is an metric emitted, even if the value is 0, if any volumes were attached/detached for a particular driver. Right? (But Perhaps metric only emitted lazily on first detach?

Will investigate deeper)~ Never mind, it makes sense for this metric to be missing if force detach never happened, and perhaps this test has just been broken for 6 years since this line was . I'll go put up a PR.
Change:
"github.com/aws/aws-sdk-go/service/kms" "github.com/golang/glog" "github.com/prometheus/client_golang/prometheus" <ins> clientset "k8s.io/client-go/kubernetes" "k8s.io/client-go/tools/record" </ins> "path" "k8s.io/api/core/v1" <ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" </ins> "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/sets" "k8s.io/apimachinery/pkg/util/wait" <ins> "k8s.io/client-go/kubernetes/scheme" v1core "k8s.io/client-go/kubernetes/typed/core/v1" </ins> "k8s.io/kubernetes/pkg/api/v1/service" "k8s.io/kubernetes/pkg/cloudprovider" "k8s.io/kubernetes/pkg/controller"

Discussion:
On AWS when we call "attach" of a volume then we periodically we check (via API call) if volume has indeed been attached. We run the check in a loop with timeout of 21 minutes. AWS documents that - if a volume is stuck in "attaching" state for too long, the node where volume is being attached is in "dirty" state and must be rebooted to fix the problem. Until node is rebooted, more pods with volumes to same node is only going be stuck in same state (i.e "attaching"). We propose that - if attach operation times out waiting for volume in "attaching" state, we should simply taint the node so as it can not affect other pods and a admin can manually fix the node. /sig aws /sig storage cc
Change:
Via a _label selector_, the client/user can identify a set of objects. The label selector is the core grouping primitive in Kubernetes. The API currently supports two types of selectors: _equality-based_ and _set-based_. <del> A label selector can be made of multiple _requirements_ which are comma-separated. In the case of multiple requirements, all must be satisfied so comma separator acts as an AND logical operator. </del> <ins> A label selector can be made of multiple _requirements_ which are comma-separated. In the case of multiple requirements, all must be satisfied so the comma separator acts as an _AND_ logical operator. </ins> An empty label selector (that is, one with zero requirements) selects every object in the collection.

Discussion:
The suggests we support both "equality-based" and "set-based" label selectors, but actually we only support "==" selector right now. This is confusing. People are asking questions on IRC. We should update the doc in both github and
cc
We support the set-based selectors for filtering GET/watch requests. We support equality-based selectors, represented as maps, for API resources, such as ReplicationController, Service, and Pod nodeSelector.
Even if it's technically correct people are getting confused, so we need to fix the documentation.
Ref
sorry I see this only now. I'm ok to better explain the difference between set-based and equality based but I would need of some example of questions on IRC. May you have some of them? Otherwise we may clearly write that kubectl <command-l <selectorsupports set-based and equality based selector while API resources supports only equality-based.
I was thinking of making the difference between selectors in kubectl and in API clear.
cool, I can work on this if you've not already started.
By all means - please do:)
:)
Change:
- name: kube-dns-config mountPath: /kube-dns-config - name: dnsmasq <del> image: gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64:1.14.2 </del> <ins> image: gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64:1.14.3 </ins> livenessProbe: httpGet: path: /healthcheck/dnsmasq

Discussion:
A number of addon images have CVEs that have been fixed in the upstream base images. We should update these images before the final 1.7 release. cc
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
/cc
cc
The new image appears to have removed . I'm not sure if this was expected, but it caused at least fluentd to stop working on COS (). This might also affect kubeproxy, which uses (a derivative of ).
also the metadata-proxy, prometheus-to-sd, the fluentd-event-exporter, and ip-masq-agent.
anything more to do for this issue?
yes, I need to get merged and update those images again. I also need to bump a few other images (dns and ip-masq-agent).
should be the last update needed.
Change:
cmdutil.CheckErr(fmt.Errorf("output must be one of '' or 'name': %v", outputFormat)) } if !supportedOutputTypes.Has(outputFormat) { <del> fmt.Fprintf(out, "--output %v is not available in kubectl config get-contexts; reseting to default output format", outputFormat) </del> <ins> fmt.Fprintf(out, "--output %v is not available in kubectl config get-contexts; resetting to default output formatn", outputFormat) </ins> cmd.Flags().Set("output", "") } cmdutil.CheckErr(options.Complete(cmd, args, out))

Discussion:
When specifying an invalid output format, the error message and the table headers are printed on the same line, producing hard-to-read output:
Change:
print('File %s is missing the year' % filename, file=verbose_out) return False <del> # Replace all occurrences of the regex "2017|2016|2015|2014" with "YEAR" </del> <ins> # Replace all occurrences of the regex "2014|2015|2016|2017|2018" with "YEAR" </ins> p = regexs["date"] for i, d in enumerate(data): (data[i], found) = p.subn('YEAR', d)

Discussion:
Happy New Year! Now when I run make I get a diff like this in every zz_generated file: Not sure what a smart solution is, but we could merge something like in the meantime.
Change:
// If a non-success status is returned, then the scheduling cycle is aborted. func (f *frameworkImpl) RunPreFilterPlugins(ctx context.Context, state *framework.CycleState, pod *v1.Pod) (_ *framework.PreFilterResult, status *framework.Status) { startTime := time.Now() <ins> skipPlugins := sets.New[string]() </ins> defer func() { <ins> state.SkipFilterPlugins = skipPlugins </ins> metrics.FrameworkExtensionPointDuration.WithLabelValues(metrics.PreFilter, status.Code().String(), f.profileName).Observe(metrics.SinceInSeconds(startTime)) }() var result *framework.PreFilterResult var pluginsWithNodes []string <del> skipPlugins := sets.New[string]() </del> logger := klog.FromContext(ctx) logger = klog.LoggerWithName(logger, "PreFilter") // TODO(knelasevero): Remove duplicated keys from log entry calls

Discussion:
In k8s 1.27, scheduler introduced a new "short circuit" semantics in PreFilter to bypass a Pod quickly. A change introduced here is it relies on that plugin to be stored in , which makes sense as what it was explained . However, the info, although is populated upon each plugin's PreFilter invocation, is not injected into when some PreFilter returns unschedulable: So think about this workflow: pluginA returns Skip in its PreFilter pluginB return Unschedulable in its PreFilter note: pluginA is not included in due to aforementioned bug a Pod is claimed as unschedulable (failed by pluginB) during PostFilter, it's supposed to bypass pluginA's PreEnqueueExtension's AddPod/RemovePod, but it doesn't calling a "skipped" Plugin's AddPod/RemovePod during preemption, sometimes will abort the whole preemption as the logic tries to read info from cycleState, and some plugin's "skip" version doesn't fill cycleState properly, e.g., InterPodAffinity (skip immediately w/o write preFilterStateKey). Short circuiting using Skip is fine, but should injected properly at all cases. Described in the workflow above. It's firstly captured in an out-of-tree PostFilter plugin: , but can also happen in in-tree plugins. No response v1.27 <details</details<details</details<details</details<details</details<details</details
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
/kind regression /sig scheduling
cc
Among in-tree plugins, 3 plugins employ non-nil and may return Skip in their PreFilter() implementation w/o writing to cycleState, while return error immediately if is missing in their Add/RemovePod() functions.

So technically, as long as a scheduling flow hit the following criteria, it would hit the bug (preemption doesn't function): plugin 1/2/3 return Skip in PreFilter arbitrary PreFilter plugin after the "skipped" plugin returns Unschedulable in its PreFilter
/cc
/cc
Cherry-pick PRs: 1.28: 1.27:
Change:
Name:            name, Description:     fmt.Sprintf(`{"kubernetes.io/service-name":"%s"}`, serviceName), Instances:       instances, <del> SessionAffinity: translateAffinityType(affinityType), </del> <ins> SessionAffinity: translateAffinityType(svc.Spec.SessionAffinity), </ins> HealthChecks:    hcLinks, }

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 /sig network /area cloudprovider What happened: The cloud provider interface that should . The GCE provider does this for but not for . Every other in-tree provider implements by fully updating the load balancer including updated backend nodes: , , , And the following out-of-tree providers do as well and Oracle (not oss yet). What you expected to happen: I expect that all cloud providers implement by creating or fully updating the load balancer if it already exists. Related discussion: /cc
/assign Make sense to make implementation in GCE consistent with others for the ease of up-coming service controller enhancement. This sounds like a 1.10 task.
is this task blocking you on another attempt at refactoring the service controller sync logic?
yup
Change:
} // We have unmamanged pods, instead of erroring and hotlooping in disruption controller, log and continue. if len(unmanagedPods) > 0 { <del> klog.V(4).Infof("found unmanaged pods associated with this PDB: %v", unmanagedPods) </del> <ins> klog.Warningf("found unmanaged pods associated with this PDB: %v", unmanagedPods) </ins> dc.recorder.Eventf(pdb, v1.EventTypeWarning, "UnmanagedPods", "Pods selected by this PodDisruptionBudget (selector: %v) were found "+ <del> "to be unmanaged or managed by an unsupported controller (missing a /scale subresource). As a result, the status of the PDB "+ "cannot be calculated correctly, which may result in undefined behavior. To account for these pods please set ".spec.minAvailable" "+ </del> <ins> "to be unmanaged. As a result, the status of the PDB cannot be calculated correctly, which may result in undefined behavior. "+ "To account for these pods please set ".spec.minAvailable" "+ </ins> "field of the PDB to an integer value.", pdb.Spec.Selector) }

Discussion:
When using PDBs with or (percentage), it is not supported to reference pods via a PDB selector, that do not have a supported controller owner reference: Deployment, ReplicationController, ReplicaSet, and StatefulSet controllers or a resource implementing subresource This is also documented Nevertheless, there are still people who create PDBs a pods without controllers that ignore this. For example PDBs that set , want to block eviction, and node drain (it works for them but the PDB status is invalid). Unfortunately there is no feedback for the user to receive when this happens. The KCM logs is the only place that informs the user when unmanaged pods are found. Which I think is insufficient. There should be some way to inform users about this. Since it cannot be know on admission we probably have to do it when reconciling the PDB and unmanaged pods are found. Options: an event when this is detected - probably needs to be throttled in some way a condition in a PDB status that would be set and admins could monitor these to detect misbehaving PDBs create a PDB create unmanaged pod observe incorrect status because this configuration is unsupported No response <detailsNA </details<detailsNA </details<detailsNA </details<details</details<details</details<details</details
/sig apps
/triage accepted This was discussed during today's sig-apps, we've agreed to add a warning event right next to the log statement from the original description
I'll take this on.
/assign
/reopen I did some more testing for the unsupported controllers and found out that these are covered by the event, so I posted a followup to reflect that The new event should cover only the naked pods
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:
apiVersion: v1 kind: ReplicationController metadata: <del> name: kube-dns-v18 </del> <ins> name: kube-dns-v19 </ins> namespace: kube-system labels: k8s-app: kube-dns <del> version: v18 </del> <ins> version: v19 </ins> kubernetes.io/cluster-service: "true" spec: replicas: {{ pillar['dns_replicas'] }} selector: k8s-app: kube-dns <del> version: v18 </del> <ins> version: v19 </ins> template: metadata: labels: k8s-app: kube-dns <del> version: v18 </del> <ins> version: v19 </ins> kubernetes.io/cluster-service: "true" spec: containers:

Discussion:
Observed weird memory spikes for both the dns healthz and kube-dns pods in production. Kube-dns didn't oom because there's enough headroom, but healthz did. I can't explain the spikes yet. I tried a bunch of different repros: no , bad nslookup command, sharing the node with cpu hogs etc, but was unable to trigger it. The memory grows, but stays under 10Mi. As a short term mitigation, we stole some ram from kube-dns, because it was always comfortably within limits. Related b/
can be closed -- healthz has been removed
-- close issue?
Change:
ctx, name, rest.DefaultUpdatedObjectInfo(obj, transformers...), <del> withAuthorization(rest.AdmissionToValidateObjectFunc(admit, staticAdmissionAttributes), scope.Authorizer, createAuthorizerAttributes), rest.AdmissionToValidateObjectUpdateFunc(admit, staticAdmissionAttributes), </del> <ins> withAuthorization(rest.AdmissionToValidateObjectFunc( admit, admission.NewAttributesRecord(nil, nil, scope.Kind, namespace, name, scope.Resource, scope.Subresource, admission.Create, userInfo)), scope.Authorizer, createAuthorizerAttributes), rest.AdmissionToValidateObjectUpdateFunc( admit, admission.NewAttributesRecord(nil, nil, scope.Kind, namespace, name, scope.Resource, scope.Subresource, admission.Update, userInfo)), </ins> false, ) wasCreated = created

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig api-machinery What happened: The that we use to make a create validation function is given admission.Update as its operation field. In the create validation we then use the provided operation (admission.Update) , when we call the admission controllers, even though a new object is being created. A similar thing is happening with the mutating admission. This means that when an objects is created on update, the admission controllers will see this as an update request. Meaning there could be an objects in storage which never passed create admission validation and were never modified by create admission mutation. I think this is a bug. What you expected to happen: Admission controllers would handle a create-on-update exactly the same as a normal create
I think the solution to this would be to separate the static admission attributes into one for the create validation and one for the update validation. Also, the function which performs the mutating admission needs to determine whether or not it is an actual update or if the old object doesn't exist (probably by checking uid) and then call the mutating admission correctly based on which operation is being performed.
/assign I might be interested to give it a try.
How to reproduce this bug?
Instead of a reproduceable BUG, I think it's like a mismatch of conceptual design and actual implementation. If a resource allows create-on-update in its strategy e.g.: Then admission plugins would receive operations (CREATE/UPDATE) on UPDATE requests. Some problems might happen the admission plugin is written without considering the circumstances that admitting a UPDATE operation might result a object creation into the storage. Risky and confusing, WDYT?
With the current build in admission controllers, I'm not sure if there are any bugs. Maybe something with resource quota? The real problem is that there is no way to know which webhook authors will have a dependency on seeing a "create" operation for every object put into storage. If a webhook relies on creates to implement its custom logic (which should be allowed), then objects created with an update would currently be missed by the webhook.
Change:
testcases := []struct { name        string zone        string <ins> location    string </ins> faultDomain string expected    string }{ { name:     "GetZone should get real zone if only node's zone is set", zone:     "1", <ins> location: "eastus", </ins> expected: "eastus-1", }, { name:        "GetZone should get real zone if both node's zone and FD are set", zone:        "1", <ins> location:    "eastus", </ins> faultDomain: "99", expected:    "eastus-1", }, { name:        "GetZone should get faultDomain if node's zone isn't set", <ins> location:    "eastus", </ins> faultDomain: "99", expected:    "99", }, <ins> { name:     "GetZone should get availability zone in lower cases", location: "EastUS", zone:     "1", expected: "eastus-1", }, </ins> } for _, test := range testcases {

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: Azure cloud provider gets the availability zone from IMDS directly and the zone is usually in lower cases in most regions. But there're chances this is not true in some regions, hence customer's workloads depend on availability zone may not work. What you expected to happen: The availability zone is always in lower cases. 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: /kind bug /sig cloud-provider /area provider/azure
/assign
Fixed by .