jiebi/CodeConvo huggingface dataset:
Change:
// In IPVS proxy mode, the following flags need to be set const ( <del> sysctlBridgeCallIPTables      = "net/bridge/bridge-nf-call-iptables" </del> sysctlVSConnTrack             = "net/ipv4/vs/conntrack" sysctlConnReuse               = "net/ipv4/vs/conn_reuse_mode" sysctlExpireNoDestConn        = "net/ipv4/vs/expire_nodest_conn"

Discussion:
The check in: is incorrect. It misses the case when the sysctl doesn't exist (err != nil). /sig network /area ipvs /area kube-proxy The check sould be: To reproduce you must use a kernel without the function, or the module unloaded. This is likely not easy if a regular Linux distro is used. But IMO no e2e testing should be needed (none exist now). It's just a warning that may be missed, so nothing urgent. master (all) N/A N/A N/A N/A N/A
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
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue </details
removed one of those , it looks that we should remove this to be consistent
I can work on removing the code to maintain consistency. Can you please assign this issue to me
/assign You can also use to assign the issue to yourself.
oops, I should have thought to check ipvs backend too
Change:
const ( aggregatorServicePort = 7443 <ins> apiServiceRetryPeriod  = 1 * time.Second apiServiceRetryTimeout = 2 * time.Minute </ins> ) var _ = SIGDescribe("Aggregator", func() {

Discussion:
[X] Test approval issue: [X] Test PR: [x] Two weeks soak end date: [X] Test promotion PR: According to this APIsnoop query, there are still some remaining APIService endpoints which are untested. Using a number of existing e2e test practices the has to cover the outstanding APIService endpoints. There has been some around how the current Conformance test is using RBAC, which is optional and not part of Conformance. Those calls will now only happen if is true. The e2e logs for this test are listed below.

This query shows the following APIService endpoints are hit within a short period of running this e2e test example endpoint | useragent ---------------------------------------------+
createApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] deleteApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] deleteApiregistrationV1CollectionAPIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] listApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] patchApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] patchApiregistrationV1APIServiceStatus | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] readApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] readApiregistrationV1APIServiceStatus | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] replaceApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] replaceApiregistrationV1APIServiceStatus | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] (10 rows) If a test with these calls gets merged, test coverage will go up by 4 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
Change:
<del> 0.2.3 </del> <ins> 0.2.4 </ins>

Discussion:
One of the dependencies of k8s, filepath-securejoin, has a following vulnerability discovered: It has been patched in version 0.2.4, however k8s is still using version 0.2.3. Potential fix: updating the dependency. A small PR will follow. /sig security
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 security
/kind bug /sig security
Change:
return boundClaims, unboundClaimsDelayBinding, unboundClaimsImmediate, nil } <del> func (b *volumeBinder) checkBoundClaims(claims []*v1.PersistentVolumeClaim, node *v1.Node, podName string) (bool, error) { </del> <ins> func (b *volumeBinder) checkBoundClaims(claims []*v1.PersistentVolumeClaim, node *v1.Node, podName string) (bool, bool, error) { </ins> csiNode, err := b.csiNodeLister.Get(node.Name) if err != nil { // TODO: return the error once CSINode is created by default

Discussion:
What would you like to be : Scheduler VolumeBinding plugin reports error when a PVC doesn't exist for example: We need to take a second look at the VolumeBinding plugin and make sure that errors are returned only when there is a system error, not a user error. Why is this needed: To fix the scheduler's error reporting metrics. /sig scheduling /sig storage /cc
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
/assign I'll take a look.
If the PVC object does not exist, the plugin will return status. I guess you mean the plugin will return an error when a referenced PV does not exist? I've created a PR for this:
Thanks! The errors I am seeing are on 1.18 clusters, can we look at 1.18 and try to patch? This is still throwing the scheduler's error metrics off.
sure
I've submitted a patch for the 1.18 release branch:
I guess on the master branch should be reviewed and merged too? cc
hello! the fix you made only apply for 1.18? how about 1.19 and 1.17? thanks!
after the fix on the master branch () is merged, I'll cherry-pick it into the 1.19 branch (the code are almost the same). I'm not sure if it's necessary to fix the 1.17 branch. It's 3 versions behind 1.20.
hi, This is because of this patch: Do you think this fix needs to be cherry-picked into 1.19 and 1.18 branch too?
can you send a patch for 1.19?
ah, here it is
to sum up: master: 1.19: 1.18: and I think this change should be backported to 1.19/1.18 too: I'll send PRs soon.

summary of the issue that an error will be reported instead of UnschedulableAndUnresolvable when PVC not found: master: already implemented, see 1.19: 1.18: can't backport as it does not implement the PreFilter extension point
Change:
return len(s1) == len(s2) && s1.IsSuperset(s2) } <del> type sortableSliceOfGeneric[T ordered] []T </del> <ins> type sortableSliceOfGeneric[T cmp.Ordered] []T </ins> func (g sortableSliceOfGeneric[T]) Len() int           { return len(g) } func (g sortableSliceOfGeneric[T]) Less(i, j int) bool { return less[T](g[i], g[j]) }

Discussion:
Package use a custom-defined type . Go 1.21 support an official package cmp which has .
/sig api-machinery
cc
/assign xgp01
/triage accepted
/kind cleanup
Change:
f.NamespacePodSecurityLevel = admissionapi.LevelBaseline ginkgo.It("will mask proc mounts by default", func(ctx context.Context) { <del> testProcMount(ctx, f, v1.DefaultProcMount, gomega.BeNumerically(">=", 10), gomega.BeNumerically(">=", 7)) </del> <ins> testProcMount(ctx, f, v1.DefaultProcMount, gomega.BeNumerically(">", 1), gomega.BeNumerically(">", 0)) </ins> }) })

Discussion:
https://prow.ppc64le- E2eNode Suite: [It] [sig-node] DefaultProcMount [LinuxOnly] [NodeConformance] will mask proc mounts by default in 2024-07-17 06:00:19 +0000 UTC No response Debugged to identify that on a ppc64le machine, the available files are as follows: while on an amd64 machine, is an additional entry, with the following output: As ppc64le does not implement ACPI, the test case may need a minor change to accommodate the architecture by changing the number of lines to exist to be =6. No response /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 Thanks!
Testgrid Link:
Change:
} } <ins> func TestRequestVersionedParamsWithInvalidScheme(t *testing.T) { parameterCodec := runtime.NewParameterCodec(runtime.NewScheme()) r := (&Request{c: &RESTClient{content: ClientContentConfig{GroupVersion: v1.SchemeGroupVersion}}}) r.VersionedParams(&v1.PodExecOptions{Stdin: false, Stdout: true}, parameterCodec) if r.Error() == nil { t.Errorf("should have recorded an error: %#v", r.params) } } func TestRequestError(t *testing.T) { // Invalid body, see TestRequestBody() r := (&Request{}).Body([]string{"test"}) if r.Error() != r.err { t.Errorf("getter should be identical to reference: %#v %#v", r.Error(), r.err) } } </ins> func TestRequestURI(t *testing.T) { r := (&Request{}).Param("foo", "a") r.Prefix("other")

Discussion:
When constructing a , e.g. to stream I/O from a pod: if ends up set, will still return a result without indicating that something went wrong, resulting in a misleading error further down the line. (In my case, I wasn’t providing the correct scheme; the parameters therefore couldn’t be encoded, and the SPDY upgrade failed with an error saying that at least one of stdin, stdout or stderr had to be provided.) Other operations on fails as appropriate if is not ; I would expect to do so too. I realise that means a backwards-incompatible change. Another solution could be to provide a (same as on the response). See above, with any scheme other than client-go’s. No response <details</detailsN/A N/A N/A N/A N/A
this is the same as standard library, the url is not validated when creating the request
is it really the same though? In the case which led to my filing this issue, the call to results in an error, which is recorded in , but the caller has no way to know that. The main issue I have with this is that in most code paths, does end up being returned, e.g. calls to etc. But callers using only have no way of knowing that the URL they get is unusable.
I didn't understand that from the description sorry I see what you mean now, the methods that execute the request return the error, but if you want to reuse the request instead of executing it, you can't know that value until it is executed IMHO is a legit demand to use a getter for Error(), the field is there but not accessible , WDYT?
/sig api-machinery
a Request#Error() getter seems reasonable
/triage accepted
Change:
// being updated from a config source. func (kl *Kubelet) HandlePodUpdates(pods []*v1.Pod) { start := kl.clock.Now() <del> // Responsible for checking limits in resolv.conf if kl.dnsConfigurer != nil && kl.dnsConfigurer.ResolverConfig != "" { kl.dnsConfigurer.CheckLimitsForResolvConf() } </del> for _, pod := range pods { kl.podManager.UpdatePod(pod) if kubetypes.IsMirrorPod(pod) {

Discussion:
What happened: Ref , we noticed that there are some unnecessary check around limit in kubelet, specifically at: and is moving this check to outside of the pods loop make it better, but we should be looking at whether this check can exist in an even higher layer, as it doesn't make much sense in either or . cc
/sig network
/assign Pending outcome of the discussion here, I would be happy to present a PR
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
poke :-)
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
How about lifting the check to the beginning of Kubelet#syncLoop (outside the for loop) ? All the events emitted by CheckLimitsForResolvConf are at EventTypeWarning level (not error). The CheckLimitsForResolvConf call in HandlePodUpdates would be removed as well.
Change:
NS="${9:-$NS}"          # namespace echo "Running w/ args: kubectl $kubectl version $VERSION ip $PUBLIC_IP sec $_SECONDS fe $FE lg $LG slave $SLAVE test $TEST NAMESPACE $NS" <ins> function create_ns { case "$NS" in "default" ) ;; "kube-system" ) ;; * ) cat << EOF > ns.json { "apiVersion": "v1", "kind": "Namespace", "metadata": { "name": "$NS" } } EOF $kubectl create -f ns.json esac } </ins> function create { cat << EOF > fe-rc.json

Discussion:
During the review of , it's better to also update and to use non-default namespace. cc .
cc
/ , I can continue to work on this one :).
/ , can you help to assign this issue to me? So I can trace the tasks in my hand :).
I'd be happy to assign you once you accept the invitation to the org. Do you plan to work on this now? If you're not actively working on it, I'd prefer to leave it unassigned.
, would you help to send the invitation ? Yes, I'd like to work on this now, that's a good start for me to learn example & e2e test suite :).
Already sent. Visit to accept. See
, I'm kuber now , thanks. I'm working on this now :). Checked and , openshift-origin is not using default namespace now; and we can update 's script to update namespace. But it seems and other example are still using default namespace, should we go through all example and update them accordingly?
, should I update all ns in one commit or one commit per example?
In which examples do you plan to make this change? cc
Making this change in some examples would be useful, but only if we explain why we're doing it. Additionally, linking to existing docs and blogs about namespaces would be helpful: I don't want to do this in all of the examples, because it does add an extra step, and labels also provide a means of managing a group of related resources within a namespace. Perhaps could recommend examples where this would make sense.
Change:
return p } <ins> // CreateEventually retries pod creation for a while before failing // the test with the most recent error. This mimicks the behavior // of a controller (like the one for DaemonSet) and is necessary // because pod creation can fail while its service account is still // getting provisioned // (https://github.com/kubernetes/kubernetes/issues/68776). // // Both the timeout and polling interval are configurable as optional // arguments: // - The first optional argument is the timeout. // - The second optional argument is the polling interval. // // Both intervals can either be specified as time.Duration, parsable // duration strings or as floats/integers. In the last case they are // interpreted as seconds. func (c *PodClient) CreateEventually(pod *v1.Pod, opts ...interface{}) *v1.Pod { c.mungeSpec(pod) var ret *v1.Pod Eventually(func() error { p, err := c.PodInterface.Create(pod) ret = p return err }, opts...).ShouldNot(HaveOccurred(), "Failed to create %q pod", pod.GetName()) return ret } </ins> // CreateSync creates a new pod according to the framework specifications in the given namespace, and waits for it to start. func (c *PodClient) CreateSyncInNamespace(pod *v1.Pod, namespace string) *v1.Pod { p := c.Create(pod)

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The code creates a pod directly, without waiting for the service account secret to be available. Depending on timing, this can fail with a error. What you expected to happen: It should use a DaemonSet instead, then the daemon set controller will ensure that the pod gets created eventually. [Edit: when implementing the fix, I found it easier and less intrusive to just retry pod creation.] How to reproduce it (as minimally and precisely as possible): It's not possible to trigger the failing race condition reliably. I've seen it a few times on my own cluster. Anything else we need to know?: Originally discussed in and in the CSI working group meeting on Monday, September 17th ().
/sig storage
Change:
import ( "strconv" <ins> "strings" </ins> "github.com/golang/glog" "k8s.io/kubernetes/pkg/api"

Discussion:
Documentation says that port number for is optional, but I've found that not to be true. It's due to the way it detects whether the disk is attached or not. also must be an IP. Refer to:
/cc
I see what you meant. Good catch. According to , the disk path contains both ip and port. So port is indeed required even for default port 3260. If you don't have a pr yet, I'll provide a fix to the doc.
I don't have a CLA in file yet, so I'll leave it up to you. Thanks.
check this out
Change:
Conditions: []api.ComponentCondition{ {Type: api.ComponentHealthy, Status: api.ConditionTrue, Message: "ok", Error: "nil"}, }, <del> ObjectMeta: api.ObjectMeta{Name: "servergood", Namespace: "test"}, </del> <ins> ObjectMeta: api.ObjectMeta{Name: "servergood"}, </ins> } bad := api.ComponentStatus{ Conditions: []api.ComponentCondition{ {Type: api.ComponentHealthy, Status: api.ConditionFalse, Message: "", Error: "bad status: 500"}, }, <del> ObjectMeta: api.ObjectMeta{Name: "serverbad", Namespace: "test"}, </del> <ins> ObjectMeta: api.ObjectMeta{Name: "serverbad"}, </ins> } unknown := api.ComponentStatus{ Conditions: []api.ComponentCondition{ {Type: api.ComponentHealthy, Status: api.ConditionUnknown, Message: "", Error: "fizzbuzz error"}, }, <del> ObjectMeta: api.ObjectMeta{Name: "serverunknown", Namespace: "test"}, </del> <ins> ObjectMeta: api.ObjectMeta{Name: "serverunknown"}, </ins> } return &api.ComponentStatusList{

Discussion:
The selflink provided in the api response for component statuses (/api/v1/componentstatuses) is broken. For example: /api/v1/namespaces/componentstatuses/controller-manager (as specified in the response of /api/v1/componentstatuses), will return: { "kind": "Status", "apiVersion": "v1", "metadata": {}, "status": "Failure", "message": "the server could not find the requested resource", "reason": "NotFound", "details": {}, "code": 404 } while: /api/v1/namespaces/default/componentstatuses/controller-manager, will return the data. In addition, and this is asked for better understanding, are the component statuses namespace scoped? as far as I understood etcd, the scheduler and the controller manager were shared across the kubernetes cluster. If they aren't namespace scoped, what is the logic behind specifing a namespace in these api requests (as shown in ): /api/v1/namespaces/{namespace}/componentstatuses /api/v1/namespaces/{namespace}/componentstatuses/{name} If they are in fact namespace scoped, would you be kind and share an explanation/link to a documentation page?
I agree that it doesn't make a lot of sense for this to be namespaced given what's in it at the moment. Given what I'd like it to contain, the namespace might make more sense in the future. The self link is super broken right now, though, probably due to lack of actual namespace. there's probably a bug in the go-restful setup code for this. Can you take a look at some point? Also it might be worth mentioning that this will probably change in the near future, is working on a replacement.
The whole /componentstatus API is just broken. It needs rewriting.
Change:
registry := RegistryList{ DockerLibraryRegistry: "docker.io/library", E2eRegistry:           "gcr.io/kubernetes-e2e-test-images", <del> EtcdRegistry:          "quay.io/coreos", </del> GcRegistry:            "k8s.gcr.io", PrivateRegistry:       "gcr.io/k8s-authenticated-test", SampleRegistry:        "gcr.io/google-samples",

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: I see only amd64 architecture etcd is used for the which will create issues for the other architectures like ppc64le, arm etc. We need to replace this etcd image with the k8s maintained fat manifest image present in
/sig testing