jiebi/CodeConvo huggingface dataset:
Change:
return err } <del> // This means that if a Service transitions away from a nil selector, any // mirrored EndpointSlices will not be cleaned up. #91072 tracks this issue // for this controller along with the Endpoints and EndpointSlice // controllers. </del> <ins> // If a selector is specified, clean up any mirrored slices. </ins> if svc.Spec.Selector != nil { <del> return nil </del> <ins> klog.V(4).Infof("%s/%s Service now has selector, cleaning up any mirrored EndpointSlices", namespace, name) c.endpointSliceTracker.DeleteService(namespace, name) return c.deleteMirroredSlices(namespace, name) </ins> } endpointSlices, err := endpointSlicesMirroredForService(c.endpointSliceLister, namespace, name)

Discussion:
with Selector is created is removed Endpoints and EndpointSlice controllers do not clean up Endpoint(Slice)s mirroring controller starts mirroring the Endpoints resource originally created by the Endpoints controller is back to the Service backing Service change created by mirroring controller still references original IP from step 4 At least one of the following: Endpoints and EndpointSlices to be cleaned up when the Service has the selector removed () mirrored EndpointSlice to be removed when the Service has a selector back See "What Happened" No response Most noticeable in Kubernetes 1.19+ since that's when kube-proxy starts reading from EndpointSlices by default. Any No response No response No response No response
/sig network /triage accepted /priority important-soon /cc
/assign
Change:
CSIMigrationOpenStack:          {Default: false, PreRelease: featuregate.Beta}, // Off by default (requires OpenStack Cinder CSI driver) CSIMigrationOpenStackComplete:  {Default: false, PreRelease: featuregate.Alpha}, VolumeSubpath:                  {Default: true, PreRelease: featuregate.GA}, <del> ConfigurableFSGroupPolicy:      {Default: false, PreRelease: featuregate.Alpha}, </del> <ins> ConfigurableFSGroupPolicy:      {Default: true, PreRelease: featuregate.Beta}, </ins> BalanceAttachedNodeVolumes:     {Default: false, PreRelease: featuregate.Alpha}, CSIBlockVolume:                 {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.20 CSIInlineVolume:                {Default: true, PreRelease: featuregate.Beta},

Discussion:
We need to add e2e that verifies volume permissions in pod with different values of fsGroupChangePolicy. /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
/assign
Change:
CSIMigrationOpenStack:          {Default: false, PreRelease: featuregate.Beta}, // Off by default (requires OpenStack Cinder CSI driver) CSIMigrationOpenStackComplete:  {Default: false, PreRelease: featuregate.Alpha}, VolumeSubpath:                  {Default: true, PreRelease: featuregate.GA}, <del> ConfigurableFSGroupPolicy:      {Default: false, PreRelease: featuregate.Alpha}, </del> <ins> ConfigurableFSGroupPolicy:      {Default: true, PreRelease: featuregate.Beta}, </ins> BalanceAttachedNodeVolumes:     {Default: false, PreRelease: featuregate.Alpha}, CSIBlockVolume:                 {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.20 CSIInlineVolume:                {Default: true, PreRelease: featuregate.Beta},

Discussion:
We need to move this field to beta in 1.20. /sig storage
/triage accepted
According to , is working on a better design on this.
Nope. The current design is the design we are going to use to handle fsgroup. we discussed this at length in sig-storage call.
Is it okay if I make this change?
Change:
return nil, nil } isInternal := requiresInternalLoadBalancer(service) <del> lbFrontendIPConfigName := az.getFrontendIPConfigName(service, subnet(service)) </del> <ins> lbFrontendIPConfigName := az.getFrontendIPConfigName(service) </ins> serviceName := getServiceName(service) for _, ipConfiguration := range *lb.FrontendIPConfigurations { if lbFrontendIPConfigName == *ipConfiguration.Name {

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 the specified internal LB uses a subnet with longer name, the LB configuration will fail with following error: What you expected to happen: When constructing the frontend IP configuration name and the load balancing rules name, the subnet name should be truncated if too long. How to reproduce it (as minimally and precisely as possible): Use a subnet that has long name (70 charactors) and create ILB service. Anything else we need to know?: Environment: Kubernetes version (use ): 1.15 Cloud provider or hardware configuration: azure OS (e.g: ): Ubuntu 16.04 Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider /area provider/azure /assign
Change:
func TestRunApplyPrintsValidObjectList(t *testing.T) { cmdtesting.InitTestErrorHandler(t) <del> cmBytes := readConfigMapList(t, filenameCM) </del> <ins> configMapList := readConfigMapList(t, filenameCM) </ins> pathCM := "/namespaces/test/configmaps" tf := cmdtesting.NewTestFactory().WithNamespace("test")

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 dry run output listed all the resources that would be configured: deployments, HPAs, services, and an ingress: This was expected. However, it then listed all resources again (except for the HPAs) as being pruned: The config was then applied with: As expected, no resources were actually pruned. What you expected to happen: should actually display which resources are going to be pruned. How to reproduce it (as minimally and precisely as possible): a YAML file to with it: run + prune: should be listed as both configured and pruned it again with pruning: that the deployment is configured but not pruned, even though the dry run said it would be. Anything else we need to know?: Was trying to write a devops script that gave a warning before any resources would be pruned. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: GKE OS (e.g. from /etc/os-release): (Lubuntu 18.04) Kernel (e.g. ):Install tools: Others:
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
I can reproduce it, and i will try to fix it.
Change:
} // Marshal to disk <del> if err := clientcmd.WriteToFile(kubeconfigData, kubeconfigPath); err != nil { return err } return nil </del> <ins> return clientcmd.WriteToFile(kubeconfigData, kubeconfigPath) </ins> } func loadRESTClientConfig(kubeconfig string) (*restclient.Config, error) {

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: reports following errors- What you expected to happen: This is the required fix reported by PR processing. How to reproduce it (as minimally and precisely as possible): run from k8s source. Anything else we need to know?: Detailed list of ERRORS reported by Environment: Kubernetes version (use ):Cloud provider or hardware configuration:OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: Others:
There are no sig labels on this issue. Please add a sig label. <detailsA sig label can be by either: 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. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals 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-testing-bugs
It looks like you're building with go1.9.x… master is building with go1.10 now, so gofmt expects to run with that version
/close +1 to what said
Change:
import ( "fmt" <ins> "strings" </ins> "sync" "time"

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Pods are synchronized by kubelet before network is ready. Synchronization in such case fails and pod is synchronized after 10 seconds. What you expected to happen: Kubelet should wait until network is ready before starting synchronizing pods. How to reproduce it (as minimally and precisely as possible): Configure cluster with Cluster Autoscaler enabled. Start pod so cluster is scaled up. In logs you might find following error: E0907 13:18:49. 972 ] Error syncing pod xxxxxx ("xxxxxxxxx(xxxxxxxxxxx)"), skipping: network is not ready: [runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: Kubenet does not have netConfig. This is most likely due to lack of PodCIDR] Environment: Build from HEAD Cloud provider or hardware configuration: GKE
/kind bug /sig node
Change:
"strings" "github.com/GoogleCloudPlatform/kubernetes/pkg/api" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/api/errors" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/api/meta" "github.com/GoogleCloudPlatform/kubernetes/pkg/runtime"

Discussion:
e.g. REST.Update should never return an arbitrary error value. Maybe we should change the return code to something stricter than generic error.
/cc
FYI: is for remaining cases where the API doesn't return JSON/Status errors.
Re-opening this until we
I think etcd errors require more abstraction, also:
There are some admission control plugins that did not always follow that practice which I will resolve as part of
Are there any known instances of this remaining?
None that I know of.
Change:
expectError:    false, }, { <ins> // case insentive check diskURL:        "/subscriptions/4be8920b-2978-43d7-axyz-04d8549c1d05/resourcegroups/azure-k8s1102/providers/Microsoft.Compute/disks/andy-mghyb1102-dynamic-pvc-f7f014c9-49f4-11e8-ab5c-000d3af7b38e", expectedResult: "azure-k8s1102", expectError:    false, }, { </ins> diskURL:        "/4be8920b-2978-43d7-axyz-04d8549c1d05/resourceGroups/azure-k8s1102/providers/Microsoft.Compute/disks/andy-mghyb1102-dynamic-pvc-f7f014c9-49f4-11e8-ab5c-000d3af7b38e", expectedResult: "", expectError:    true,

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 resource id should be case insensitve, while some places are case sensitve: What you expected to happen: 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: /sig azure /assign
Change:
return nil, fmt.Errorf("Error getting loadbalancer %s: %v", name, err) } glog.V(2).Infof("Creating loadbalancer %s", name) <del> loadbalancer, err = lbaas.createLoadBalancer(apiService, name) </del> <ins> loadbalancer, err = lbaas.createLoadBalancer(apiService, name, internalAnnotation) </ins> if err != nil { // Unknown error, retry later return nil, fmt.Errorf("Error creating loadbalancer %s: %v", name, 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.
Change:
podInformer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{ AddFunc: func(obj interface{}) { <del> nc.maybeDeleteTerminatingPod(obj) </del> pod := obj.(*v1.Pod) if nc.taintManager != nil { nc.taintManager.PodUpdated(nil, pod) } }, UpdateFunc: func(prev, obj interface{}) { <del> nc.maybeDeleteTerminatingPod(obj) </del> prevPod := prev.(*v1.Pod) newPod := obj.(*v1.Pod) if nc.taintManager != nil {

Discussion:
As discussed on slack with we might want to clean the node controller from code that ensures backward compatibility for version 1.4 and earlier ones. /sig node
/assign
- how do we plan to devide this one ? The following order for merge should be fine I think: the tests (we can split also test case deletion if it's too long to review): logic itself + kubeletVersion on the according tests: change how we create nodecontroller: clean consts and BUILD:
Yeah, sounds good.
I'll create the PRs accordingly and assign them to you
Change:
# Print the supported API Resources with more information kubectl api-resources -o wide <ins> # Print the supported API Resources sorted by a column kubectl api-resources --sort-by=name </ins> # Print the supported namespaced resources kubectl api-resources --namespaced=true

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add a sort parameter (or similar concept) to the command. Why is this needed: With the numerous amount of API resources (not counting custom ones), it is sometimes difficult locating them in the output. By default, API resources are not sorted by the name column (the first on the left) and often this is the column holding the information one wishes to query. A sort parameter would help more easily identify the object to be understood.
/sig usability
Change:
docker run --rm -i -v "${TARGET}:${TARGET}:Z" registry.k8s.io/build-image/kube-cross:${KUBE_CROSS_VERSION}  /bin/bash -c " mkdir -p /go/src /go/bin &&  <del> GO111MODULE=on go get -d k8s.io/sample-apiserver@v0.17.0 &&  GO111MODULE=on CGO_ENABLED=0 GOARM=${GOARM} GOOS=${OS} GOARCH=${ARCH} go get k8s.io/sample-apiserver@v0.17.0 &&  </del> <ins> git clone https://github.com/kubernetes/sample-apiserver /go/src/k8s.io/sample-apiserver &&  cd /go/src/k8s.io/sample-apiserver &&  git checkout tags/v0.17.0 &&  go mod tidy &&  GO111MODULE=on CGO_ENABLED=0 GOARM=${GOARM} GOOS=${OS} GOARCH=${ARCH} go install . &&  </ins> find /go/bin -name sample-apiserver* -exec cp {} ${TARGET}/sample-apiserver ;" # for arm, go install uses /go/bin/linux_arm, so just find the file and copy it to the # root so we can copy it out from this throw away container image from a standard location.

Discussion:
. [1] We've recently switched to Go 1.19, and because of this, the E2E image has started failing to build recently [2] with the error: Using ` directly doesn't work either: [1] [2] The image should be buildable. /sig testing /priority important-soon N/A N/A N/A <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
please see the PR and lgtm if it works right for you!
Change:
"fmt" "testing" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "github.com/stretchr/testify/assert"

Discussion:
What happened: Pods with invalid container-level seccomp profiles allow its init containers to be executed. Pods with unloaded apparmor profiles blocks the entire pod. What you expected to happen: Consistency between both. In one hand AppArmor blocks all pod execution regardless of the containers having or not a profile attached to it. On the other, Seccomp allows for an init container to deploy its own profile - as currently done on . How to reproduce it (as minimally and precisely as possible): Apply the yaml below: Resulting in only the init container from the being executed: ! Anything else we need to know?: AppArmor is currently being target to GA on 1.21 (). Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-12-08T17:59:43Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"21+", GitVersion:"v1.21.0-alpha.0.292+", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-12-12T23:13:21Z", GoVersion:"go1.15.6", Compiler:"gc", Platform:"linux/amd64"} 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: /sig node /area security
/cc
/sig security /triage accepted
I think we can consider this as a bug, right? Then we could work on a fix for v1.21 interdependently of the AppArmor GA graduation.
Sounds like a good plan :+1:
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
/assign
Change:
// Reset sends a reset frame, putting the stream into the fully closed state. func (s *Stream) Reset() error { s.conn.removeStream(s) <ins> return s.resetStream() } func (s *Stream) resetStream() error { </ins> s.finishLock.Lock() if s.finished { s.finishLock.Unlock()

Discussion:
Hit this while :
cc/ Andy can you take a look at this failure?
looking now
Working with on a fix
Proposed fix:
Change:
readonly master_ssh_supported_providers="gce aws kubemark" readonly node_ssh_supported_providers="gce gke aws" <del> readonly master_logfiles="kube-apiserver kube-scheduler rescheduler kube-controller-manager etcd glbc cluster-autoscaler" </del> <ins> readonly master_logfiles="kube-apiserver kube-scheduler rescheduler kube-controller-manager etcd glbc cluster-autoscaler kube-addon-manager" </ins> readonly node_logfiles="kube-proxy" readonly aws_logfiles="cloud-init-output" readonly gce_logfiles="startupscript"

Discussion:
Addon Manager was broken a few times recently by some indirect-related changes(like ) made in the code base. Addon Manager's logs would be very helpful for narrowing down the problem. And I don't think there is an obvious way to retrieve Addon Manager's logs for Jenkins tests currently. This can be achieved in the same way as what we did for the components like and (mounting /var/log). I will try it through this way for addon manager. cc
Change:
{% if pillar.get('network_provider', '').lower() == 'opencontrail' %} {% set network_plugin = "--network-plugin=opencontrail" %} {% elif pillar.get('network_provider', '').lower() == 'cni' %} <del> {% set network_plugin = "--network-plugin=cni --cni-bin-dir=/etc/cni/net.d/" %} {%elif pillar.get('network_policy_provider', '').lower() == 'calico' and grains['roles'][0] != 'kubernetes-master' -%} </del> <ins> {% set network_plugin = "--network-plugin=cni --cni-conf-dir=/etc/cni/net.d/ --cni-bin-dir=/home/kubernetes/bin/" %} {% elif pillar.get('network_policy_provider', '').lower() == 'calico' and grains['roles'][0] != 'kubernetes-master' %} </ins> {% set network_plugin = "--network-plugin=cni --cni-conf-dir=/etc/cni/net.d/ --cni-bin-dir=/home/kubernetes/bin/" %} {% elif pillar.get('network_provider', '').lower() == 'kubenet' %} <del> {% set network_plugin = "--network-plugin=kubenet" -%} </del> <ins> {% set network_plugin = "--network-plugin=kubenet --network-plugin-dir=/home/kubernetes/bin/" -%} </ins> {% endif -%} # Don't pipe the --hairpin-mode flag by default. This allows the kubelet to pick

Discussion:
Kubernetes version (use ): master Environment: Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): debian, gci Install tools: cluster/kube- What happened: Creating a cluster with GCI uses the directory for CNI plugins. Creating a cluster with debian uses the directory for CNI plugins, which is read-only on GCI. This makes it impossible to create a DaemonSet which works for both image types. What you expected to happen: The CNI installation directory should be the same across all image types. In this case, it should be . CC
/sig network
Some related work here:
Ok, I approved this one for 1.7 since It helps clean up our CVM based tests. The cleanup code is also self-contained, shouldn't cause any issues on other cloud providers. But will double check through the pr.
Change:
if err != nil { t.Fatalf("Failed to create replication controller: %v", err) } <del> pod := newMatchingPod("pod1", ns.Name) </del> <ins> podName := fmt.Sprintf("pod%d", i) pod := newMatchingPod(podName, ns.Name) </ins> pod.OwnerReferences = tc.existingOwnerReferences(rc) _, err = podClient.Create(pod) if err != nil {

Discussion:
https://k8s- Failed: TestAdoption {integration}
https://k8s- Failed: TestAdoption {integration}
https://k8s- Failed: TestAdoption {integration}
https://k8s- Failed: TestAdoption {integration}
The problem is that the rc manager hasn't observed pod1, so it creates another pod and scales down, pod1 might get deleted. I'm working on the fix.
Change:
- endpoint: replaceAutoscalingV2NamespacedHorizontalPodAutoscalerStatus reason: optional feature link: https://github.com/kubernetes/kubernetes/pull/106595#issuecomment-1006015756 <ins> - endpoint: logFileHandler reason: optional feature link: https://github.com/kubernetes/kubernetes/issues/108675 - endpoint: logFileListHandler reason: optional feature link: https://github.com/kubernetes/kubernetes/issues/108675 </ins>

Discussion:
We have a question regarding the eligibility of the following 2 endpoints for conformance; logFileListHandler logFileHandler We found this PR Don’t test the debug /logs endpoint on GKE. that disables testing of /log endpoint for GKE. Is this still valid or should the exclusion of GKE be reconsidered? Does this provider requirement make these 2 log endpoints ineligible for conformance?
/triage accepted /sig architecture /area conformance
confirmed that these endpoints should no be eligible for conformance. They should be considered an operational tool, not related to application consistency across distros.