jiebi/CodeConvo huggingface dataset:
Change:
func SetFeatureGateDuringTest(tb testing.TB, gate featuregate.FeatureGate, f featuregate.Feature, value bool) func() { originalValue := gate.Enabled(f) <ins> // Specially handle AllAlpha and AllBeta var cleanups []func() if f == "AllAlpha" || f == "AllBeta" { // Iterate over individual gates so their individual values get restored for k, v := range gate.(featuregate.MutableFeatureGate).GetAll() { if k == "AllAlpha" || k == "AllBeta" { continue } if (f == "AllAlpha" && v.PreRelease == featuregate.Alpha) || (f == "AllBeta" && v.PreRelease == featuregate.Beta) { cleanups = append(cleanups, SetFeatureGateDuringTest(tb, gate, k, value)) } } } </ins> if err := gate.(featuregate.MutableFeatureGate).Set(fmt.Sprintf("%s=%v", f, value)); err != nil { tb.Errorf("error setting %s=%v: %v", f, value, err) }

Discussion:
PR was reverted by because it (erroneously) relied on OpenAPIV3 feature to be enabled, but would non-deterministically leave the feature disabled after running. I tracked it down to the fact that this test disables all or features in a loop which iterates over a , which are known to have unstable iteration order: When key is processed before key , then would disable before s default value is to be saved. Normally, ignores features that have been explicitly set, so it only affects those which fall back on the value. But this issue does not just affect but any non-GA feature. I suggest the loop in be made to skip the special feature keys such as . /cc /cc The value before every feature gate should be restored after running . This test always fails on my machine (just pasted it into ): No response <details</details<details</details<details</details<details</details<details</details<details</details
/assign
Wow, good catch, sorry to make you track down what turned out to be a bug in our test
/sig auth
/area test
/triage accepted
Change:
return watcher.Stop } <del> // StartRecordingToSink starts sending events received from the specified eventBroadcaster to the given sink. func (e *eventBroadcasterImpl) StartRecordingToSink(stopCh <-chan struct{}) { go wait.Until(func() { e.refreshExistingEventSeries() }, refreshTime, stopCh) go wait.Until(func() { e.finishSeries() }, finishTime, stopCh) </del> <ins> func (e *eventBroadcasterImpl) startRecordingEvents(stopCh <-chan struct{}) { </ins> eventHandler := func(obj runtime.Object) { event, ok := obj.(*eventsv1.Event) if !ok {

Discussion:
Which jobs are flaking: periodic-kubernetes-bazel-test-master (xref ) Which test(s) are flaking: TestEventSeriesf Testgrid link: Reason for failure: Timeout: Anything else we need to know: To reproduce with stress: /cc
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
/assign
filed to address this issue.
contains the correct analysis of flakes (thanks a lot!), I commented on way of fixing it (which I'm not convinced about).
Change:
// see an update podUpdate := CreatePodUpdate(kubetypes.ADD, TestSource, CreateValidPod("foo", "")) channel <- podUpdate <ins> expectPodUpdate(t, ch, CreatePodUpdate(kubetypes.ADD, TestSource, CreateValidPod("foo", ""))) </ins> config.Sync() <del> expectPodUpdate(t, ch, CreatePodUpdate(kubetypes.SET, kubetypes.AllSource)) </del> <ins> expectPodUpdate(t, ch, CreatePodUpdate(kubetypes.SET, kubetypes.AllSource, CreateValidPod("foo", ""))) </ins> } func TestNewPodAddedDefaultNamespace(t *testing.T) {

Discussion:
To read a pod manifest file from disk (or from the http source), kubelet execute the following code to Decode a on-disk v1 pod manifest to an internal pod object (the defaults are applied in this process). Validate the internal pod. Convert the internal pod back to a v1 pod. The downstream pod cache (which gets v1 pods from different sources) performs similar operations: Convert the v1 pod to an internal pod. Validate the internal pod. One of two conversion/validation should be removed, and some of them should be simplified.
/cc for suggestions on defaulting and conversion.
If no one is working on this, I will take it.
Change:
func (s *APIServer) AddFlags(fs *pflag.FlagSet) { // Note: the weird ""+ in below lines seems to be the only way to get gofmt to // arrange these text blocks sensibly. Grrr. <del> fs.IntVar(&s.Port, "port", s.Port, ""+ </del> <ins> fs.IntVar(&s.WideOpenPort, "port", s.WideOpenPort, ""+ </ins> "The port to listen on. Default 8080. It is assumed that firewall rules are "+ "set up such that this port is not reachable from outside of the cluster. It is "+ "further assumed that port 443 on the cluster's public address is proxied to this "+

Discussion:
Trying to hit the read-write kubernetes service from inside a cluster does not work. tailing the kube-proxy logs shows: And sure enough, kube-apiserver is not listening on the NIC on that port. 8080 is only for the localhost HTTP communications between master components (and nginx redirect after HTTPS termination). The "kubernetes" master service needs to get created with Port set to 443.
+1
This needs to be port 6443 the auth_port On Feb 6, 2015 10:14 AM, "Paulo Pires" wrote:
The code says 8443, but then a flag changes to 6443. Will fix. , Eric Tune wrote:
Holy macaroni this is a mess. , Tim Hockin wrote:
Change:
kube::util::wait_for_url "http://${API_HOST}:${API_PORT}/api/v1beta1/pods" "apiserver: " CTLRMGR_LOG=/tmp/kube-controller-manager.log <del> "${GO_OUT}/kube-controller-manager"  </del> <ins> sudo "${GO_OUT}/kube-controller-manager"  </ins> -v=${LOG_LEVEL}  --machines="127.0.0.1"  --master="${API_HOST}:${API_PORT}" >"${CTLRMGR_LOG}" 2>&1 & CTLRMGR_PID=$! KUBELET_LOG=/tmp/kubelet.log <del> "${GO_OUT}/kubelet"  </del> <ins> sudo "${GO_OUT}/kubelet"  </ins> -v=${LOG_LEVEL}  --etcd_servers="http://127.0.0.1:4001"  --hostname_override="127.0.0.1" 

Discussion:
/kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --
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
looks like started a few days ago ! /sig cluster-lifecycle
cc
fix was sent earlier
/sig cluster-lifecycle
thanks :) i saw it yesterday and forgot to raise the issue. i should have checked the PR queue :)
Change:
csitranslationplugins.AzureFileInTreePluginName: func() bool { return utilfeature.DefaultFeatureGate.Enabled(features.CSIMigrationAzureFile) }, <ins> csitranslationplugins.VSphereInTreePluginName: func() bool { return true }, </ins> csitranslationplugins.PortworxVolumePluginName: func() bool { return utilfeature.DefaultFeatureGate.Enabled(features.CSIMigrationPortworx) },

Discussion:
A pod that uses in-tree vSphere volume never starts in Kubernetes 1.29.0. Such pod should start as usual. See above Feature gate removal deleted that vSphere volumes are migrated to CSI. So the CSI volume plugin ignores in-tree vSphere volumes and does not translate them to CSI. <details</details<details</details<details</details<details</details<details</details<details</details
/sig storage /priority important-soon /triage accepted /assign
cc have you ever tested with CSI migration?
/assign
I already have a PR:
Change:
return CompilationResult{ Program:            prog, ExpressionAccessor: expressionAccessor, <ins> OutputType:         ast.OutputType(), </ins> } }

Discussion:
Variables field is to ValidatingAdmissionPolicy in 1.28. Currently the usage of variables would expect a operator associated. e.g. (thanks to Mariam Fahmy for raising the issue) Above will fail with error: Meanwhile the will pass. The reason is when variables be evaluated to non dyn type(like bool or string), it will require special handling(like casting) since we use dyn type everywhere. It might confuse user.
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
/triage accepted /sig api-machinery /cc
Tests I'd expect to see verify this behavior: PASS: A variable is of type bool, an expression returns the variable PASS: A variable is of type string, a messageExpression returns the variable PASS: A variable is of type dyn, at runtime the dyn is a bool, an expression returns the variable PASS: A variable is of typedyn, at runtime the dyn is a string, an messageExpression returns the variable PASS: A expression is of type dyn, at runtime the dyn is of type bool PASS: A messageExpression is of type dyn, at runtime the dyn is of type string COMPILE ERROR: A variable is of type bool, an expression tries to perform a non-bool (e.g. string replace) operation on the variable, this should resultsin a compile error COMPILE ERROR: A variable is of type string, an expression tries to perform a non-string (e.g. less than) operation on the variable, this should result in a compile error RUNTIME ERROR: A variable is of type dyn, at runtime the dyn is a bool, an expression tries to perform a non-bool (e.g. string replace) operation on the variable, this should result in a runtime error I'd also expect to see some cases covering variables of other types (maps, lists, duration, quantity, ...) to make sure we're over-fitting for bool and string.
/retitle ValidatingAdmissionPolicy: variable expression type not recognized as return type in expression that evaluates the variable
/assign
Change:
if apiResourceConfig.VersionEnabled(v1beta1.SchemeGroupVersion) { storage := map[string]rest.Storage{} // customresourcedefinitions <del> customResourceDefintionStorage := customresourcedefinition.NewREST(Scheme, c.GenericConfig.RESTOptionsGetter) storage["customresourcedefinitions"] = customResourceDefintionStorage storage["customresourcedefinitions/status"] = customresourcedefinition.NewStatusREST(Scheme, customResourceDefintionStorage) </del> <ins> customResourceDefinitionStorage, err := customresourcedefinition.NewREST(Scheme, c.GenericConfig.RESTOptionsGetter) if err != nil { return nil, err } storage["customresourcedefinitions"] = customResourceDefinitionStorage storage["customresourcedefinitions/status"] = customresourcedefinition.NewStatusREST(Scheme, customResourceDefinitionStorage) </ins> apiGroupInfo.VersionedResourcesStorageMap[v1beta1.SchemeGroupVersion.Version] = storage } if apiResourceConfig.VersionEnabled(v1.SchemeGroupVersion) { storage := map[string]rest.Storage{} // customresourcedefinitions <del> customResourceDefintionStorage := customresourcedefinition.NewREST(Scheme, c.GenericConfig.RESTOptionsGetter) </del> <ins> customResourceDefintionStorage, err := customresourcedefinition.NewREST(Scheme, c.GenericConfig.RESTOptionsGetter) if err != nil { return nil, err } </ins> storage["customresourcedefinitions"] = customResourceDefintionStorage storage["customresourcedefinitions/status"] = customresourcedefinition.NewStatusREST(Scheme, customResourceDefintionStorage)

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: When joining a new control plane node with stacked , while the local server starts and joins the cluster, can't connect to it and panics: What you expected to happen: Not sure if this is a bug per se, because in the end the static pod restarts and starts successfully after the server joins the cluster, but that panic should probably be gracefully handled. How to reproduce it (as minimally and precisely as possible): Join a new control plane node. Anything else we need to know?: Environment: Kubernetes version (use ): 1.18.0 Cloud provider or hardware configuration: Hetzner VPS OS (e.g: ): Ubuntu 18.04.4 LTS Kernel (e.g. ): 5.3.0-45-generic (Ubuntu's default HWE kernel) Install tools: kubeadm Network plugin and version (if this is a network-related bug): Others:
/sig api-machinery
Yeah, the storage signature needs adjusting to propagate the error: /remove-kind bug /kind cleanup /priority backlog
/assign
Change:
// Check iptables chain and rules epIpt := netlinktest.ExpectedIptablesChain{ string(kubeServicesChain): {{ <ins> JumpChain: "RETURN", SourceAddress: "127.0.0.0/8", }, { </ins> JumpChain: string(kubeLoadBalancerChain), MatchSet: kubeLoadBalancerSet, }, { JumpChain: string(kubeMarkMasqChain), MatchSet: kubeClusterIPSet,

Discussion:
Loopback addresses (127.0.0.0/8, ::1/128) can't be used by services in proxy-mode=ipvs it makes sense to dismiss those early, add RETURN rule to KUBE-NODE-PORT,KUBE-SERVICES No response <details</details25 <details</detailsnone <details</details<details</details<details</details<details</details
/sig network
As mentioned in , this is not a bug since the nodeport and ephemeral ranges overlap.
/kind cleanup /kind remove-bug
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /kind cleanup /kind remove-bug </details
/remove-kind bug
The title of this issue should be changed to something like; Which would indicate that this is not a bug fix but an improvement. Also remove the invalid use-case in the description and add references to comments in like I think to dismiss nodePort connects to localhost early for proxy-mode=ipvs is an improvement, and in the majority of systems traffic to localhost is more common than traffic to nodePorts so this change will also improve overall performance. This is not a fix for overlapping ephemeral and nodePort ranges! So if the title and description is not updated the correct triage is to close this issue as it violates the non overlapping rule for ephemeral/nodeport ranges, please see
/area ipvs
Ok, i will change issue title and descripiton
/triage accepted
Change:
// Package-wide variables from generator "generated". option go_package = "v1"; <del> // IPBlock describes a particular CIDR (Ex. "192.168.1.1/24") that is allowed to the pods // matched by a NetworkPolicySpec's podSelector. The except entry describes CIDRs that should // not be included within this rule. </del> <ins> // IPBlock describes a particular CIDR (Ex. "192.168.1.1/24","2001:db9::/64") that is allowed // to the pods matched by a NetworkPolicySpec's podSelector. The except entry describes CIDRs // that should not be included within this rule. </ins> message IPBlock { // CIDR is a string representing the IP Block <del> // Valid examples are "192.168.1.1/24" </del> <ins> // Valid examples are "192.168.1.1/24" or "2001:db9::/64" </ins> optional string cidr = 1; // Except is a slice of CIDRs that should not be included within an IP Block <del> // Valid examples are "192.168.1.1/24" </del> <ins> // Valid examples are "192.168.1.1/24" or "2001:db9::/64" </ins> // Except values will be rejected if they are outside the CIDR range // +optional repeated string except = 2;

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : mentions an IPBlock with only IPv4 examples. Add a comment or example to clarify that IPv6 network blocks are (or possibly aren't) valid here. Why is this needed: Cluster operators who use IPv6 networking want to understand how to isolate different workloads inside their cluster network (and without reading source code). Logged against kubernetes/kubernetes rather than the website repo because this is generated documentation. Kubernetes already has single-stack support for IPv6 clusters KEP for dual-stack support is /sig docs /sig network /priority backlog
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign /remove-triage unresolved can you guide me on what steps are needed to publish the examples?
I via the pull request. (Although I want these examples , it's not a task I'm familiar with).
Change:
cadvisorapi "github.com/google/cadvisor/info/v1" "github.com/google/go-cmp/cmp" <del> libcontaineruserns "github.com/opencontainers/runc/libcontainer/userns" </del> "github.com/opencontainers/selinux/go-selinux" "go.opentelemetry.io/otel/attribute" semconv "go.opentelemetry.io/otel/semconv/v1.12.0"

Discussion:
is no longer compilable on macOS in the master branch. It was compilable with Kubernetes v1.29.0 and v1.30.0-alpha.0. It should be compilable. No response <detailsmaster () (This is just the latest commit, not the commit that introduced the regression) </details<detailsN/A </details<detailsmacOS 14.2.1 (Intel) </details<detailsN/A </details<detailsN/A </details<detailsN/A </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
/sig testing
Regression in:
Change:
// IsLikelyNotMountPoint determines if a directory is not a mountpoint. // It is fast but not necessarily ALWAYS correct. If the path is in fact // a bind mount from one part of a mount to another it will not be detected. <ins> // It also can not distinguish between mountpoints and symbolic links. </ins> // mkdir /tmp/a /tmp/b; mount --bind /tmp/a /tmp/b; IsLikelyNotMountPoint("/tmp/b") // will return true. When in fact /tmp/b is a mount point. If this situation // if of interest to you, don't use this function...

Discussion:
What happened: I realized csi local driver with the function of IsLikelyNotMountPoint in kubernetes pkg/util/mount library. The function as follows: We notice that If i use the symbolic link filepath, it will return false which cause the error to umount after this function. What you expected to happen: return true How to reproduce it (as minimally and precisely as possible): A directory link A to someone device the function with symbolic link Anything else we need to know?: Environment: Kubernetes version (use ): 1.15 OS (e.g: ): centos Kernel (e.g. ): Linux 3.10.0-862.3.2.el7.x8664 SMP Mon May 21 23:36:36 UTC 2018 x8664 x8664 x8664 GNU/Linux Install tools: yum
/sig storage
Change:
</tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">topologyKey</p></td> <del> <td class="tableblock halign-left valign-top"><p class="tableblock">This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. For PreferredDuringScheduling pod anti-affinity, empty topologyKey is interpreted as "all topologies" ("all topologies" here means all the topologyKeys indicated by scheduler command-line argument --failure-domains); for affinity and for RequiredDuringScheduling pod anti-affinity, empty topologyKey is not allowed.</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td> </del> <ins> <td class="tableblock halign-left valign-top"><p class="tableblock">This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed.</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">true</p></td> </ins> <td class="tableblock halign-left valign-top"><p class="tableblock">string</p></td> <td class="tableblock halign-left valign-top"></td> </tr>

Discussion:
The field is marked as optional: The comment also describes a use case for empty topologykey: But the validation rule says it's required:
cc
cc could you take a look? Thank you. The validation rule is by
the release note of should go into the "action-required" section of the , but it's currently in "Other notable changes".
/assign
It seems that we should also update the external api type comments. Right?
I will look into it today.
If you didn't work on this, I am pleasure to send PR to fix this. :)
yeah sure. thanks.
Change:
return r } <del> func makeValidPromethusMetricName(in string) string { </del> <ins> func makeValidPromethusMetricLabel(in string) string { </ins> // this isn't perfect, but it removes our common characters <del> return strings.NewReplacer("/", "_", ".", "_", "-", "_").Replace(in) </del> <ins> return strings.NewReplacer("/", "_", ".", "_", "-", "_", ":", "_").Replace(in) </ins> } // internalPackages are packages that ignored when creating a default reflector name. These packages are in the common

Discussion:
I'm seeing a large number of unique prometheus series showing up (due to the logging we for anonymous reflectors). This is a small cluster but I believe this may have unbounded cardinality.
we storing the resource version in the metric name?
cc
Came into the same problem, checked the code, seems we use + + as metric names, for most reflector, they use a default name provided by which is go filename. I think the proper way is use as the metric name, and add a label, like
opened a pr to fix this, ptal thanks :)