jiebi/CodeConvo huggingface dataset:
Change:
listers "k8s.io/apiextensions-apiserver/pkg/client/listers/apiextensions/internalversion" ) <ins> // OverlappingBuiltInResources returns the set of built-in group/resources that are persisted // in storage paths that overlap with CRD storage paths, and should not be deleted // by this controller if an associated CRD is deleted. func OverlappingBuiltInResources() map[schema.GroupResource]bool { return map[schema.GroupResource]bool{ {Group: "apiregistration.k8s.io", Resource: "apiservices"}:             true, {Group: "apiextensions.k8s.io", Resource: "customresourcedefinitions"}: true, } } </ins> // CRDFinalizer is a controller that finalizes the CRD by deleting all the CRs associated with it. type CRDFinalizer struct { crdClient      client.CustomResourceDefinitionsGetter

Discussion:
What happened: Created a CRD: Created another CRD defining an overlapping type with CustomResourceDefinition: Verify both exist: Deleted the one overlapping with the in-tree CRD type: Verify only the overlapping CRD remains: and is stuck deleting: What you expected to happen: Creation and deletion of the overlapping type CRD would have no effect on the in-tree data. Anything else we need to know?: The only types in the kube-apiserver (currently) that store data under a group prefix are: APIService () CustomResourceDefinition () Custom resources () When a CRD is deleted, all instances of the type it defines are first removed. That means that defining and deleting a CustomResourceDefinition that defines an overlapping APIService or CustomResourceDefinition type will remove existing APIService or CustomResourceDefinition data. We can special-case these two resources in the CRD deletion code, but we need a more robust solution before CRD v1. /cc /sig api-machinery /priority important-soon /area custom-resources
/sub
Is anyone working on this? I'll like to take a stab at this.
Not currently, no. Great. I'd suggest discussion a potential solution here before diving into code. The two main aspects are: -time - Should we forbid creating CRDs that overlap with built-in types? -time - How do we detect a CRD overlapping with a built-in type and skip the etcd cleanup for it
I think we should forbid creating CRDs that overlap (option 1).
That can help, but is not sufficient. Imagine: n forbids creating overlapping CRDs on version n creates MyType, which is allowed because that is not a built-in type upgrades to version n+1 which adds MyType as a built-in type deletes CRD What should happen?
For that, we may need delete-time detection of overlapping types as well (option 2), which may make option 1 redundant. Do you have any advice for detecting overlapping CRDs?
for now, just delete-time detection in
Change:
import ( "fmt" "net" <ins> "strings" </ins> "time" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime/serializer" <ins> "k8s.io/apimachinery/pkg/util/errors" </ins> "k8s.io/apiserver/pkg/server" utilfeature "k8s.io/apiserver/pkg/util/feature"

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add the "Strict-Transport-Security" header to the API server responses. Why is this needed: Nessus scanner treats this as a Medium Risk in kubernetes 1.18.10.
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 api-machinery
/remove-sig api-machinery /sig auth
Change:
// IMPORTANT NOTE : the returned pods should NOT be modified. func (dc *DisruptionController) getPodsForPdb(pdb *policy.PodDisruptionBudget) ([]*v1.Pod, error) { sel, err := metav1.LabelSelectorAsSelector(pdb.Spec.Selector) <del> if sel.Empty() { return []*v1.Pod{}, nil } </del> if err != nil { return []*v1.Pod{}, err } <ins> if sel.Empty() { return []*v1.Pod{}, nil } </ins> pods, err := dc.podLister.Pods(pdb.Namespace).List(sel) if err != nil { return []*v1.Pod{}, 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: panicked with "invalid memory address or nil pointer dereference", resulting in crash-looping. What you expected to happen: to gracefully handle nil-valued variables. How to reproduce it (as minimally and precisely as possible): Create a object with a field that, when passed to , returns . Anything else we need to know?: This is the offending code: The nil pointer dereference occurred on line 473. Environment: Kubernetes version (use ): 1.17.14 Cloud provider or hardware configuration: GKE OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig apps
/cc /triage accepted
/assign
Change:
} } Expect(string(body)).To(Equal("pass")) <del> }, 120) </del> <ins> }) </ins> })

Discussion:
test panicked: (root)/Kubernetes%%20suite/Monitoringverifymonitoringpodsandallclusternodesareavailableoninfluxdbusingheapster/ cc
Vish please take a look if you have cycles or reassign if there's someone with better context.
I looked at the panic and it was due to the last test (networking) timing out but still running. I think the fix is more in better cleanup between tests.
I just saw this... it's totally due to ginkgo's cleanup when a test times out. I can fix.
I will get this one.
Ugh, the thing ginkgo does when a test times out is totally lame...
Instead of working around this, I've filed I'm going to go back to a manual timeout on this test.
Change:
// ResourcePolicyRule matches a resource request if and only if: (a) // at least one member of verbs matches the request, (b) at least one // member of apiGroups matches the request, (c) at least one member of <del> // resources matches the request, and (d) least one member of // namespaces matches the request. </del> <ins> // resources matches the request, and (d) either (d1) the request does // not specify a namespace (i.e., `Namespace==""`) and clusterScope is // true or (d2) the request specifies a namespace and least one member // of namespaces matches the request's namespace. </ins> type ResourcePolicyRule struct { // `verbs` is a list of matching verbs and may not be empty. // "*" matches all verbs and, if present, must be the only entry.

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 --I looked at the comment on ResourcePolicyRule to understand exactly what its ClusterScope field means, and was dismayed to find an outdated precise description that does not mention that field. I expected that comment to be up to date. Kubernetes version (use ): current 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:
/cc /cc /cc /cc
/triage accepted
Change:
endpoint:             "/var/log/kubelet/plugins/myplugin/csi.sock", versions:             []string{"v1.2.3", "4.9.12", "v0.3.0", "2.0.1"}, foundInDeprecatedDir: true, <del> shouldFail:           true, </del> <ins> shouldFail:           false, </ins> }, { pluginName:           "test.plugin",

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!--What happened: CSI allows 0.x drivers only in the deprecated kubelet plugin dir. CSI allows 1.x drivers only in the new kubelet plugin dir. If a driver implements both 0.x and 1.x (which is unlikely since the side car containers do not support this), kubelet requires the driver live in new kubelet plugin dir. So CSI drivers that implement both 0.x and 1.x if they want a seamless transition between k8s 1.12 to 1.13 would need to deploy in both old and new dir. What you expected to happen: argues that this is adding churn for CSI authors. He recommends allowing any driver that implements 0.x (even if it implements 1.x) to use either new or old (not just new). /milestone v1.13 If release team approves, PR is small and I can get prepare it pretty quickly. 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
discussed in the burndown meeting, please go ahead and prepare the PR
/sig storage /priority critical-urgent /milestone v1.13
we need to wait for a fix for this before lifting code freeze
Change:
// TODO: SkipUnlessDefaultScheduler() // Non-default schedulers might not spread }) ginkgo.It("should spread the pods of a service across zones", func() { <del> SpreadServiceOrFail(f, (2*zoneCount)+1, image) </del> <ins> SpreadServiceOrFail(f, (2*zoneCount)+1, imageutils.GetPauseImageName()) </ins> }) ginkgo.It("should spread the pods of a replication controller across zones", func() { <del> SpreadRCOrFail(f, int32((2*zoneCount)+1), image, []string{"serve-hostname"}) </del> <ins> SpreadRCOrFail(f, int32((2*zoneCount)+1), framework.ServeHostnameImage, []string{"serve-hostname"}) </ins> }) })

Discussion:
It's not being used. Alternatively, pass the right image name to start with. /assign /sig scheduling /sig testing
/kind cleanup
Change:
Use the [standalone.yaml](cloud-configs/standalone.yaml) cloud-config to provision a single node Kubernetes cluster. <ins> *Attention:* This requires at least CoreOS version 593.0.0/598.0.0. </ins> ### CoreOS image versions ### AWS

Discussion:
Hello, I have installed the latest kubernetes binaries on CoreOS running on GCE. The cloud-config is as per instructions on "getting started guides". After I installed 3 Pods, the state on all were constantly "pending". I looked around but none of the previous solutions worked. After messing around a lot for 3 days it turned out to be the following line. I had 3 in pending status now one Pod is "successful" the others are "running". Change the config for docker daemon from ExecStart=/usr/bin/docker -d -s=overlay -H fd:// --bip={FLANNELMTU} To ExecStart=/usr/bin/docker -d -s=btrfs -H fd:// --bip={FLANNELMTU}
Usually this means that you have a scheduling conflict. What does print? My guess is that you have set on your pods, and you have more replicas than you have machines, and so some pods can not schedule due to hostPort conflicts.
The event dump as follows. I have the entire cluster in a stand alone machine. The cloud-config is this one
So it looks like you are trying to get node level logging up using Flunetd -Elasticsearch? Let me know if there is something I can do to help.
satnam, I will contact you if I have any questions with Flunetd -Elasticsearch. Much appreciated.
Not sure if related but CoreOS instructions are borked for 0.10.x or 0.11.x. Will PR changes today. See .
Actually, changed the layer driver from to which means he's using an older version of CoreOS. I can't reproduce this behavior with CoreOS 593.0.0/598.0.0 and Kubernetes 0.9.3, 0.10.1 or 0.11.0.
I am using coreos-beta-584-0-0-v20150218 . Perhaps a warning should go on getting-started-guides to say it only applies to CoreOS after 593.0.0/598.0.0.
Change:
return } ref := &v1.ObjectReference{ <del> Kind:      "Pod", Name:      nsName.Name, Namespace: nsName.Namespace, </del> <ins> APIVersion: "v1", Kind:       "Pod", Name:       nsName.Name, Namespace:  nsName.Namespace, </ins> } tc.recorder.Eventf(ref, v1.EventTypeNormal, "TaintManagerEviction", "Marking for deletion Pod %s", nsName.String()) }

Discussion:
Events from node taint manager doesn't report involved object apiVersion: ! apiVersion is reported as other events. For example: ! a pod on node A (not master) off node A is reported, but without apiVersion in involvedObject. The apiVersion is not reported in The issue is still not fixed in master: ! <details</details<detailsIrrelevant </details<details</details<details</details<details</details<details</details
/sig node /sig apps
/assign In the latest version, the issue is confirmed
one suggestion you should wait for the corresponding SIG to triage the issue and accept it before sending PRs, the chances of your PR getting reviewed and approver are much higher
You are right sorry about that. It won’t happen again.
no no worries, it was a suggestion, is not that you did something wrong, but it is possible that your PR doesn't get reviews and you get frustrated
/remove-sig node please re-add if this is node-related issue
I think it is a node related issue. The root cause in taint manager.
/sig node
/assign /triage accepted
Change:
s.elb = &MockedFakeELB{FakeELB: s.elb.(*FakeELB)} return s } <ins> func TestAzToRegion(t *testing.T) { testCases := []struct { az     string region string }{ {"us-west-2a", "us-west-2"}, {"us-west-2-lax-1a", "us-west-2"}, {"ap-northeast-2a", "ap-northeast-2"}, {"us-gov-east-1a", "us-gov-east-1"}, {"us-iso-east-1a", "us-iso-east-1"}, {"us-isob-east-1a", "us-isob-east-1"}, } for _, testCase := range testCases { result, err := azToRegion(testCase.az) assert.NoError(t, err) assert.Equal(t, testCase.region, result) } } </ins>

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : AWS release [Local Zones] (). One user enable local zones, using us-west-2 as an example, there's AZ and AWS right now uses method here to infer to region. This won't work for local zone region. Why is this needed: Update to cover this case
/sig cloud-provider These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
/area provider/aws
Change:
# set values in ETCD_OPTS function configEtcd(){ <del> echo ETCD_OPTS="-name $1 -initial-advertise-peer-urls http://$2:2380 -listen-peer-urls http://$2:2380 -initial-cluster-token etcd-cluster-1 -initial-cluster $3 -initial-cluster-state new" > default_scripts/etcd </del> <ins> echo ETCD_OPTS="-name $1 -initial-advertise-peer-urls http://$2:2380 -listen-peer-urls http://$2:2380 -initial-cluster-token etcd-cluster-1 -initial-cluster $3 -initial-cluster-state new" > work/default_scripts/etcd </ins> } # check root

Discussion:
I used the ubuntu-cluster setup scripts to build a mini testing environment. The first time I inputted a wrong config and when I reconfigured the environment by running the scripts again an error occured. I looked into the code and found the scripts hadn't deal with old configs. And of kube-proxy configs are not replaced.
Looks like this was fixed by .
Change:
test/e2e/scheduling/predicates.go: "validates resource limits of pods that are allowed to run" test/e2e/scheduling/predicates.go: "validates that NodeSelector is respected if not matching" test/e2e/scheduling/predicates.go: "validates that NodeSelector is respected if matching" <del> test/e2e/scheduling/predicates.go: "validates that taints-tolerations is respected if matching" </del> test/e2e/scheduling/predicates.go: "validates that there is no conflict between pods with same hostPort but different hostIP and protocol" test/e2e/scheduling/predicates.go: "validates that there exists conflict between pods with same hostPort and protocol but one using 0.0.0.0 hostIP" test/e2e/scheduling/taints.go: "removing taint cancels eviction"

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:
KUBECFG_CERT_BASE64=$(cat "${CERT_DIR}/pki/issued/kubecfg.crt" | base64 | tr -d 'rn') KUBECFG_KEY_BASE64=$(cat "${CERT_DIR}/pki/private/kubecfg.key" | base64 | tr -d 'rn') } <ins> # # Using provided master env, extracts value from provided key. # # Args: # $1 master env (kube-env of master; result of calling get-master-env) # $2 env key to use function get-env-val() { local match=`(echo "${1}" | grep ${2}) || echo ""` if [[ -z ${match} ]]; then echo "" fi echo ${match} | cut -d : -f 2 | cut -d ' -f 2 } # Load the master env by calling get-master-env, and extract important values function parse-master-env() { # Get required master env vars local master_env=$(get-master-env) KUBELET_TOKEN=$(get-env-val "${master_env}" "KUBELET_TOKEN") KUBE_PROXY_TOKEN=$(get-env-val "${master_env}" "KUBE_PROXY_TOKEN") CA_CERT_BASE64=$(get-env-val "${master_env}" "CA_CERT") EXTRA_DOCKER_OPTS=$(get-env-val "${master_env}" "EXTRA_DOCKER_OPTS") KUBELET_CERT_BASE64=$(get-env-val "${master_env}" "KUBELET_CERT") KUBELET_KEY_BASE64=$(get-env-val "${master_env}" "KUBELET_KEY") } </ins>

Discussion:
When we add nodes to an existing cluster, we need to reuse the existing configuration. In particular, we need to extract the kubelet cert & key, otherwise we get a cert error connecting to the master.
WIP fix in
Change:
import ( "context" <ins> "fmt" "io/ioutil" "net/http" "strings" </ins> <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> policy "k8s.io/api/policy/v1beta1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/client-go/kubernetes/scheme" </ins> restclient "k8s.io/client-go/rest" <ins> fakerest "k8s.io/client-go/rest/fake" </ins> core "k8s.io/client-go/testing" )

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 tried to use  in a unit test, however I get a nil pointer panic when is invoked. What you expected to happen: would return a that doesn't panic on any method call. Ideally, it would allow me to interact with the client in someway for testing. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: client-go version: 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 testing
I believe this also impacts returning logs via a reactor as does not implement
Seems to be a problem with . Since we're creating the request with all empty fields. Not sure what the best way it to resolve this. The best thing I came up with is to use to return a request with everything set up. But I'm a noob here so that's just a shot in the dark :man_shrugging:
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
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
The request returned has a nil which is used in the
I have filed a PR trying to fix this issue.
Change:
select { case <-stopCh: return nil <del> case <-r.initConnBackoffManager.Backoff().C(): </del> <ins> case <-r.backoffManager.Backoff().C(): </ins> continue } }

Discussion:
Currently, reflector uses two backoff managers: One is used for initial list call and other for watch call. Imagine following scenaraion when k8s apiserver is under very heavy load: the beginning, reflector spams k8s apiserver (with exponential backoff) with calls until one of them succeeds (due to APF throtling and receiving ) tries to run request and uses separate backoffManager - so again spams k8s apiserver with requests Watch does not succeed during Etcd compaction window (2.5 - 5 minutes usually) at some point it will receive and go back to point 1, spamming k8s apiserver again with List calls (because first backoffManager for List got reseted after 2 minutes of retries for Watch requests) I propose we combine these two backoff managers into one. If we combine these two backoffManagers into one, it will work like this: At the beginning, reflector spams k8s apiserver (still with exponential backoff) with calls until one of them succeeds Tries to make first watch call instantly (as there is no backoff on this path) If it fails, it will makre retries every (30, 60)s If watch request fails all the times during Etcd compaction window it will go back to List call, but already being throttled with (30, 60)s window. /sig scalability
/cc
/assign
I think the proposed solution makes sense to me. Probably before we start, we should to understand why we ended up with two back off managers by looking into PRs touching them. Maybe the code authors had some specific case in mind.
for thoughts too I agree it makes sense, but I don't know the historical context here.
/sig api-machinery
/triage accepted
Change:
assert.Equal(t, svc.Name, slices[0].Labels[discovery.LabelServiceName]) assert.EqualValues(t, []discovery.EndpointPort{}, slices[0].Ports) assert.EqualValues(t, []discovery.Endpoint{}, slices[0].Endpoints) <ins> expectTrackedResourceVersion(t, r.endpointSliceTracker, &slices[0], "200") </ins> expectMetrics(t, expectedMetrics{desiredSlices: 1, actualSlices: 1, desiredEndpoints: 0, addedPerSync: 0, removedPerSync: 0, numCreated: 0, numUpdated: 1, numDeleted: 0}) }

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: With EndpointSlice feature enabled, after EndpointSliceController creates or updates an EndpointSlice when reconciling a Service, the Service would always be processed one extra time, which is triggered by the EndpointSlice /updated event made by itself during the first processing. What you expected to happen: EndpointSliceController shouldn't reprocess a Service due to the EndpointSlice update made by itself. How to reproduce it (as minimally and precisely as possible): EndpointSlice feature, improve kube-controller-manager log to 5. a nginx deployment a Service backed by the above deployment. kube-controller-manager log: the service will be processed twice in succession. Anything else we need to know?: It's because EndpointSliceController tracks stale resource version after creating/updating an EndpointSlice. Environment: Kubernetes version (use ): v1.18.0-alpha.3 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:
/assign
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved