jiebi/CodeConvo huggingface dataset:
Change:
t.Run("PatchCRDSchemaless", func(t *testing.T) { testFieldValidationPatchCRDSchemaless(t, rest, schemalessGVK, schemalessGVR) }) t.Run("ApplyCreateCRDSchemaless", func(t *testing.T) { testFieldValidationApplyCreateCRDSchemaless(t, rest, schemalessGVK, schemalessGVR) }) t.Run("ApplyUpdateCRDSchemaless", func(t *testing.T) { testFieldValidationApplyUpdateCRDSchemaless(t, rest, schemalessGVK, schemalessGVR) }) <ins> t.Run("testFinalizerValidationApplyCreateCRD", func(t *testing.T) { testFinalizerValidationApplyCreateAndUpdateCRD(t, rest, schemalessGVK, schemalessGVR) }) </ins> } // testFieldValidationPost tests POST requests containing unknown fields with

Discussion:
A client is allowed to add custom finalizers to Custom Resources with a finalizer name that's not fully qualified (e.g. or ). However they're prevented from doing the same on builtin resource types, returning the following error: Invalid value: "": name is neither a standard finalizer name nor is it fully qualified Per , custom finalizer names are expected to be in format "consist of a domain name, a forward slash and the name of the finalizer" (e.g. ). Therefore, I expected the enforcement to be the same for CRs and builtin types. a custom resource on the cluster it to add the edit does not fail the same on a builtin resource (e.g. Namespace or Pod), observe it fails No response Reproducible at least starting from 1.21 and still on latest versions. <details</details<detailsN/A kind cluster </details<detailsN/A - kind cluster accessed via macOS </details<details</details<details</details<details</details
/area api /cc /sig api-machinery
/assign /triage accepted
There is no validation of finalizer in and . Please unassign me if you guys have started to work on it. /assign
it is called from here on custom resources:
lacks validation for finalizer name. I have raised a pr for this. PTAL.
Change:
done`, testCmd) } <ins> loaderAffinity := &api.Affinity{ PodAffinity: &api.PodAffinity{ RequiredDuringSchedulingIgnoredDuringExecution: []api.PodAffinityTerm{{ Namespaces: []string{f.Namespace.Name}, LabelSelector: &metav1.LabelSelector{ MatchLabels: map[string]string{loaderLabelKey: loaderLabelValue}, }, TopologyKey: "kubernetes.io/hostname", }}, }, } </ins> pod := &api.Pod{ ObjectMeta: metav1.ObjectMeta{ GenerateName: "test-apparmor-",

Discussion:
The "AppArmor load AppArmor profiles should enforce an AppArmor profile" e2e test in failing on our 5k-node gce clusters - https://k8s- (run no. 8) due to timeout: Seems like the test is trying to load the profiles across all the nodes using a daemonset and then running a test pod to check that. It's passing on our 2k-node clusters (https://k8s-) but failing for 5k - suggesting that it's likely due to size of the cluster. I think it's the ds creation taking longer on large cluster. cc
Seems like you're the most relevant here. Could one of you take a look into it? And does increasing the timeout for the test-pod based on no. of nodes sound reasonable?
Assigning it you since is OOO. Feel free to reassign as apt.
This is part of the correctness suite and large cluster tests are release-blocking.
FYI
Reassigning to who is back on Tuesday. He wrote the AppArmor stuff and should be able to debug this quickly. /assign
Ref
Could you manage to take a look into this?
Sorry, I meant to reply to this! I have a fix, just need to confirm it works. I think you're right about the DaemonSet timing out. There's no reason this needs to load the profiles on every node, so the fix just runs a single loader, and uses pod affinity to co-schedule the test pod.
Smooth!
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/node sig/scalability: 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</aThe commands available for adding these labels are documented <a href=""here</a</details
Change:
no trailing newline. The first `tr` command will remove the newline if your editor added one. <ins> **Note:** if your cluster enforces **_selinux_** and you will be using [Host Path](#host-path) for storage, then please follow this [extra step](#selinux). </ins> ```shell tr --delete 'n' <password.txt >.strippedpassword.txt && mv .strippedpassword.txt password.txt kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/master/examples/mysql-wordpress-pd/local-volumes.yaml

Discussion:
Version: Running this example on RHEL 7.2 (assume same for centos), and using hostPath, I get a permissions error when the mysql container does a . If I set selinux to permissive on the host it works. If I manually run the container with it works. I was not able to get it to work when adding to the deployment. My fix was to locate the PVs in by changing the local- file, and doing . I this comment to local- If this issue is valid I will create a quick PR to doc this selinux solution.
See pr
Change:
framework.ExpectEqual(labelPod.Spec.NodeName, nodeName) }) <del> /* Release : v1.18 Testname: Scheduler, taints-tolerations matching Description: Find an available node and taint it with a key with effect NoSchedule. Schedule a pod with a corresponding nodeLabel and toleration spec such that it should only be able to run on the selected node. Ensure that the pod is scheduled and running on the node. */ framework.ConformanceIt("validates that taints-tolerations is respected if matching [Disruptive]", func() { </del> <ins> // 1. Run a pod to get an available node, then delete the pod // 2. Taint the node with a random taint // 3. Try to relaunch the pod with tolerations tolerate the taints on node, // and the pod's nodeName specified to the name of node found in step 1 ginkgo.It("validates that taints-tolerations is respected if matching", func() { </ins> nodeName := getNodeThatCanRunPodWithoutToleration(f) ginkgo.By("Trying to apply a random taint on the found node.")

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: kind serial conformance jobs Which test(s) are failing: The conformance test SchedulerPredicates [Serial] validates that taints-tolerations is respected if matching [Disruptive] [Conformance] Since when has it been failing: The test was promoted in kubernetes/kubernetes passing the kind-ipv6 job but it keeps failing after that in both ipv4 and ipv6 conformance jobs Testgrid link: https://k8s-(IPv6),%20master%20(dev) Reason for failure: Investigating Anything else we need to know: Seems the job in presubmit is not testing Serial conformance :/
/cc
/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. ‍
EDIT: posting GCE results because it is failing there too
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/retitle Failing Test: SchedulerPredicates [Serial] validates that taints-tolerations is respected if matching [Disruptive] [Conformance]
/remove-sig network /sig scheduling /area conformance
I've opened to revert
Change:
"k8s.io/utils/ptr" ) <ins> // generateRandomIP is copied from pkg/apis/networking/fuzzer/fuzzer.go func generateRandomIP(is6 bool, c fuzz.Continue) string { n := 4 if is6 { n = 16 } bytes := make([]byte, n) for i := 0; i < n; i++ { bytes[i] = uint8(c.Rand.Intn(255)) } ip, ok := netip.AddrFromSlice(bytes) if ok { return ip.String() } // this should not happen panic(fmt.Sprintf("invalid IP %v", bytes)) } // generateRandomCIDR is copied from pkg/apis/networking/fuzzer/fuzzer.go func generateRandomCIDR(is6 bool, c fuzz.Continue) string { ip, err := netip.ParseAddr(generateRandomIP(is6, c)) if err != nil { // generateRandomIP already panics if returns a not valid ip panic(err) } n := 32 if is6 { n = 128 } bits := c.Rand.Intn(n) prefix := netip.PrefixFrom(ip, bits) return prefix.Masked().String() } // getRandomDualStackCIDR returns a random dual-stack CIDR. func getRandomDualStackCIDR(c fuzz.Continue) []string { cidrIPv4 := generateRandomCIDR(false, c) cidrIPv6 := generateRandomCIDR(true, c) cidrs := []string{cidrIPv4, cidrIPv6} if c.RandBool() { cidrs = []string{cidrIPv6, cidrIPv4} } return cidrs[:1+c.Intn(2)] } </ins> // Funcs returns the fuzzer functions for the kube-proxy apis. func Funcs(codecs runtimeserializer.CodecFactory) []interface{} { return []interface{}{

Discussion:
pull-kubernetes-unit TestRoundTripFuzzing Only noticed the failure once in No response No response No response
/sig network may be caused by
This flakes in /cc
/assign so the problem is that sometimes the fuzzer generates a random string value that contains a comma, and when that gets converted back from v1alpha1, the comma is treated as punctuation rather than as part of the value. we should probably manually fuzz ClusterCIDRs to contain 0-2 actual CIDR values
/triage accepted
Saw here:
Change:
case m.isFor("GET", "/namespaces/default/pods/bar"): return &http.Response{StatusCode: 404, Header: cmdtesting.DefaultHeader(), Body: cmdtesting.ObjBody(codec, &corev1.Pod{})}, nil case m.isFor("GET", "/pods"): <ins> if test.failUponEvictionOrDeletion && atomic.LoadInt32(&evictions) > 0 || atomic.LoadInt32(&deletions) > 0 { return nil, errors.New("request failed") } </ins> values, err := url.ParseQuery(req.URL.RawQuery) if err != nil { t.Fatalf("%s: unexpected error: %v", test.description, err)

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: kubectl drain crashed with panic when apiserver connection disappeared while there were pods that couldn't be evicted/deleted (sorry, the problem is a bit hard to reproduce and the log was lost) What you expected to happen: kubectl drain should exit with a proper error message How to reproduce it (as minimally and precisely as possible): Try kubectl drain multiple times, interrupting the connection during eviction/deletion Anything else we need to know?: The here can be in case if returns an error, and will panic upon accessing : This causes the c Environment: Kubernetes version (use ): The problem is present as of but is also present in earlier versions (I have a fix for this bug)
/priority important-longterm /sig cli
Change:
return "", imagePullResult.err.Error(), ErrImagePull } <del> m.logIt(ref, v1.EventTypeNormal, events.PulledImage, logPrefix, fmt.Sprintf("Successfully pulled image %q", container.Image), klog.Info) </del> <ins> m.logIt(ref, v1.EventTypeNormal, events.PulledImage, logPrefix, fmt.Sprintf("Successfully pulled image %q in %v", container.Image, time.Since(startTime)), klog.Info) </ins> m.backOff.GC() return imagePullResult.imageRef, "", nil }

Discussion:
What would you like to be : The 'Successfully pulled image' event should contain the duration for image pulling. Why is this needed: Currently the success event is in this form: User has to trace back to the corresponding event for the beginning of image pulling and calculate the duration him/herself:
/sig node /assign
Change:
var matched string scanner := bufio.NewScanner(strings.NewReader(s)) for scanner.Scan() { <ins> // losetup output has symlinks expanded if strings.HasSuffix(scanner.Text(), "("+realPath+")") { matched = scanner.Text() break } // Just in case losetup changes, check for the original path too </ins> if strings.HasSuffix(scanner.Text(), "("+path+")") { matched = scanner.Text() break

Discussion:
How to reproduce it (as minimally and precisely as possible): /var/lib/kubelet a symlink kubelet a block PVC + a pod that uses it. the pod. -The pod is forever. In kubelet logs: The reason is that shows: kubelet can't find there, because losetup shows real path . Environment: Kubernetes version (use ): 1.18 /sig storage /priority important-soon
/triage accepted
Change:
AWS            | Saltstack    | Ubuntu | OVS         | [docs](../../docs/getting-started-guides/aws.md)       | Community (@justinsb)        | Uses K8s version 0.5.0 Vmware         | CoreOS       | CoreOS | flannel     | [docs](../../docs/getting-started-guides/coreos.md)    | Community (@kelseyhightower) | Uses K8s version 0.15.0 Azure          | Saltstack    | Ubuntu | OpenVPN     | [docs](../../docs/getting-started-guides/azure.md)     | Community                    | <del> Bare-metal     | custom       | Ubuntu | flannel     | [docs](../../docs/getting-started-guides/ubuntu.md)    | Community (@resouer @WIZARD-CXY)       | use k8s version 0.15.0 </del> <ins> Bare-metal     | custom       | Ubuntu | flannel     | [docs](../../docs/getting-started-guides/ubuntu.md)    | Community (@resouer @WIZARD-CXY)       | use k8s version 0.18.0 </ins> Docker Single Node        | custom       | N/A    | local       | [docs](docker.md) | Project (@brendandburns) | Tested @ 0.14.1 | Docker Multi Node        | Flannel| N/A    | local       | [docs](docker-multinode.md) | Project (@brendandburns) | Tested @ 0.14.1 | Local          |              |        | _none_      | [docs](../../docs/getting-started-guides/locally.md)   | Community (@preillyme)                     |

Discussion:
This flag is deprecated and no longer has any effect.
I wonder which version does this include.Now ubuntu approach is using ubuntu 0.15.0.
This change was checked in this week, so it will be true for clusters at 0.18.0+ (once the next release is cut next week). So the next time the ubuntu documentation is updated, this change should be reflected.
Ohit means that minion node can be automatically discovered by the master node when then kubelet set ? No other configuration is needed?
Yes, the kubelet, when passed the location of the apiserver, will register itself and then post node update messages. The only part that may depend on your deployment environment is the set of addresses that the kubelet passes to the apiserver. They will be based on the name of the node, reverse resolving the name of the node, or checking for addresses from the cloud provider.
Got it.I will include this when I updates the doc and scripts. Besides, I have a little questions here. Eric told me the addon services do not have service-account now.Will 0.18.0+ have it?
Service accounts will be included as part of 0.18.0 as well.
got it
- makes sense
Change:
"k8s.io/kubernetes/pkg/kubelet/dockershim/network/kubenet" "k8s.io/kubernetes/pkg/kubelet/server/streaming" "k8s.io/kubernetes/pkg/kubelet/util/cache" <del> utilstore "k8s.io/kubernetes/pkg/kubelet/util/store" </del> "k8s.io/kubernetes/pkg/kubelet/dockershim/libdocker" "k8s.io/kubernetes/pkg/kubelet/dockershim/metrics"

Discussion:
/kind bug are failing. seems like the likely cause. cc /assign
ping
seems one test still failing.
Change:
plugin := plugins[0] fakeMounter := iscsiDiskMounter{ iscsiDisk: &iscsiDisk{ <ins> Iface:  "192.168.1.10:pv0001", </ins> plugin: plugin.(*iscsiPlugin)}, exec: fakeExec, } <del> newIface := "192.168.1.10:pv0001" cloneIface(fakeMounter, newIface) </del> <ins> cloneIface(fakeMounter) </ins> if cmdCount != 1 { t.Errorf("expected 1 CombinedOutput() calls, got %d", cmdCount) }

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
Change:
request: &http.Request{ Method: "PATCH", URL: &url.URL{ <del> RawPath:  "/apis/batch/v1/namespaces/foo/pods/status", </del> <ins> RawPath:  "/apis/batch/v1/namespaces/foo/jobs/bar/status", </ins> RawQuery: "dryRun=All", }, }, requestInfo: &request.RequestInfo{ <ins> Verb:              "patch", </ins> APIGroup:          "batch", APIVersion:        "v1", Resource:          "jobs", <ins> Name:              "bar", </ins> Subresource:       "status", IsResourceRequest: true, },

Discussion:
I've observed, that some metrics has and labels. (create) requests are "single resource", therefor they should be classified as . Def: customresourcehandler uses , which is based on the RequstInfo only: the RequestInfo is based only on the requests: method and url example: e.g: Since this RequestInfo has Name and Namespace empty, it is classified as . In a similar way it could be explained why: There's a mismatch in scope classification between built-in and custom resources: The key difference - the check if either "name" was provided OR it is a : Where the metrics.CleanScope ONLY checks, if name is not-empty. Tested: = v1.20 There were other scope related issues <1.20 and the distinction is not obvious. <details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/triage accepted
Change:
RELEASE_TAR_PATH=$(dirname ${RELEASE_TAR_LOCATION}) echo "[INFO] Uploading ${KUBERNETES_RELEASE_TAR}" <del> swift upload kubernetes ${RELEASE_TAR_PATH}/${KUBERNETES_RELEASE_TAR}  </del> <ins> swift upload ${SWIFT_OBJECT_STORE} ${RELEASE_TAR_PATH}/${KUBERNETES_RELEASE_TAR}  </ins> --object-name kubernetes-server.tar.gz echo "[INFO] Uploading kubernetes-salt.tar.gz" <del> swift upload kubernetes ${RELEASE_TAR_PATH}/kubernetes-salt.tar.gz  </del> <ins> swift upload ${SWIFT_OBJECT_STORE} ${RELEASE_TAR_PATH}/kubernetes-salt.tar.gz  </ins> --object-name kubernetes-salt.tar.gz }

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?: What happened: Currently swift object store has a hard-coded name: . E.g., What you expected to happen: Make swift object store parameterizable. E.g., How to reproduce it (as minimally and precisely as possible): This defaults to the hard-coded swift object store. Anything else we need to know?: Here is the patch file to address this issue: Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OpenStack OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., /sig scalability for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig openstack /sig storage /remove-sig api-machinery
cc
Quick question, if you have the diff already, why not send a PR?
I noticed the contributor documentation is extensive (b/c k8s is such a big project, this is understandable) and I wasn't sure how if I was following the rules. I can send the PR, if you would like. This is no problem. Let me know :-)
I created a PR based on the diff in your issue. Please let me know if you'd like me to abandon it so that you can have credit for the work.
Here you go:
hey can you please reopen this?
I don't think I have enough privileges to reopen. It's probably best to create a new issue and reference this one.
Ah. thanks
/assign
/reopen
Looks like the bot commands worked! ()
/close
Change:
func (lb *LoadBalancerRR) resetService(svcPort proxy.ServicePortName) { // If the service is still around, reset but don't delete. <del> if state, ok := lb.services[svcPort]; ok { </del> <ins> if state, ok := lb.services[svcPort]; ok && state != nil { </ins> if len(state.endpoints) > 0 { klog.V(2).InfoS("LoadBalancerRR: Removing endpoints service", "servicePortName", svcPort) state.endpoints = []string{}

Discussion:
As suggested in , some portions of the code contains the map checking for nil values in map, and others don't have. Even though we're never assigning nil values to this map, we should standardize the portions that does not have this check in module. Example: Should be like this: I can take care of this issue.
/sig network
There have been discussions of deprecating the user-space proxier. Maybe transfer it to . A question is if anybody still uses it. Seems like you do, so if possible please explain if you have a use-case where the user-space proxier is wanted/needed.
Hey Actually, I was casually reading the source code and I saw a over there regarding the nil checks. Regarding your question, we should check if anyone actually uses it though, or maybe discuss its usage or deprecation a little further.
Quick question though: I saw in the news that the user-space proxy porting was near completion, maybe it's worth talking to them in order to check upon the status.
I don't object to making it clearer or more consistent, if you want to spend time on it, but it's not a high priority. That said, I think a nil value in that map would be really bad (and should be impossible) and I don't know how we would raise a signal about it.
let us know if you want to try to fix it, otherwise we can just close this.
I already opened a PR with the clearer nil checks for this specific module in , so you can review it. I think whether this would have nil values into the service map we should discuss this apart and try to reproduce this case (if any would happen).
PR submitted, so let's review and discuss further there. /assign dcbw /triage accepted
Change:
// of having to do conversions with IP addresses. // Don't allocate the network's ".0" address. ipFirst := prefix.Masked().Addr().Next() <del> if err != nil { return nil, err } </del> // Use the broadcast address as last address for IPv6 ipLast, err := broadcastAddress(prefix) if err != nil {

Discussion:
The err is already checked on line 84, so it will always be nil On line 107, the check is redundant
That is indeed redundant. It seems like someone forgot to remove after a refactor but It was this way in
Feel free to send a pull request by following Thanks.
Thanks! I am wondering whether it is necessary to check ip address returned by calling or is As in But I don't find the overflowed cases yet.
/sig network
/assign DrAuYueng
Hmmm, in theory yes, since .Next() and .Prev() can return an empty netip.Addr. In practice, they probably never overflow in this particular case. Adding a check for .IsValid() for both Prev and Next would not hurt. I don't expect the path of !ip.IsValid() to be ever taken in these cases, but if they do then that is a bug and it should propagate an error.
/triage accepted