jiebi/CodeConvo huggingface dataset:
Code change:
}, expectedError: false, }, <ins> { name: "super-admin.conf: admin.conf cannot create CRB, try to create CRB with super-admin.conf, encounter 'already exists' error", setupAdminClient: func(client *clientsetfake.Clientset) { client.PrependReactor("create", "clusterrolebindings", func(action clientgotesting.Action) (bool, runtime.Object, error) { return true, nil, apierrors.NewForbidden( schema.GroupResource{}, "name", errors.New("")) }) }, setupSuperAdminClient: func(client *clientsetfake.Clientset) { client.PrependReactor("create", "clusterrolebindings", func(action clientgotesting.Action) (bool, runtime.Object, error) { return true, nil, apierrors.NewAlreadyExists( schema.GroupResource{}, "name") }) }, expectedError: true, }, </ins> } for _, tc := range tests {

Related discussion:
text: master-informing: periodic-kubernetes-e2e-kind-kms ! No response /sig cluster-lifecycle
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
/milestone v1.29
/assign but this test job is maintained by sig auth: /sig auth looks like the API server has decided to consistently fail on an unpolled CRB create API call from the kubeadm client. this did not happen on the kind presubmit jobs here: or kubeadm periodic jobs using the kinder tool: or my local tests. so what is different here and why are we getting informer errors? is this highlighting a bug in core k8s? cc best we can do in kubeadm is make that API call polled. FTR, the API call exactly prior to this failing API call is already polled.
Hello. I want to echo that the code freeze is starting (next week), and we want to ensure that each PR has a chance to be merged and issues can be addressed. Is this PR still targeting the 1.29 release?
FTR, the API call exactly prior to this failing API call is already polled. +1 to have the API call polled just as the API call with .
here is the kubeadm PR.
we are tracking a failing test in this ticket and we can proceed with fixing this after code freeze is in effect. i just submitted an associated fix PR here:
As the Alpha 3 release cut is approaching (2nd Nov) /priority critical-urgent
/assign
we have a couple of kubeadm passes here: of the presubmit variant of this job: pull-kubernetes-e2e-kind-kms this seems like a flake and not a failure, given the offending PR merged on the 27th and looking at the history of the periodic:
we are having the similar issue with i saw in the logs I am not sure what I should do, could you help me?
Code change:
}, expectedError: false, }, <ins> { name: "super-admin.conf: admin.conf cannot create CRB, try to create CRB with super-admin.conf, encounter 'already exists' error", setupAdminClient: func(client *clientsetfake.Clientset) { client.PrependReactor("create", "clusterrolebindings", func(action clientgotesting.Action) (bool, runtime.Object, error) { return true, nil, apierrors.NewForbidden( schema.GroupResource{}, "name", errors.New("")) }) }, setupSuperAdminClient: func(client *clientsetfake.Clientset) { client.PrependReactor("create", "clusterrolebindings", func(action clientgotesting.Action) (bool, runtime.Object, error) { return true, nil, apierrors.NewAlreadyExists( schema.GroupResource{}, "name") }) }, expectedError: true, }, </ins> } for _, tc := range tests {

Related discussion:
text: thanks
Can you pls tell where is the the log you pasted above? I searched in this file: , and some other logs related with kubeadm but cannot find it. The original issue is expected to be fixed by: It's now continuous green now: But the log you pasted do point to the change we landed last week:
kubeadm introduced a new step in the "init" process. it creates an file but it needs RBAC for it. this RBAC is created in a rather complicated manner (with a fallback), but in your case it's failing at the first step where the API server is not reachable in 40 seconds. do you expect the API server to no be ready in 40 seconds? are you sure there are no other problems with the setup and it just ends up failing at this first API server step where RBAC is created? other jobs like CAPI (non-upgrade), kinder, kind are green with respect to this. i wonder if we can just stop returning this error and fallback to the super- "create" attempt later: this will allow for more time for certain setups to start - 40 + 40 seconds. ... it exactly to catch problems like the one is reporting - no early connectivity to the API server. but if this is now the "first thing" in kubeadm, it might have introduced a bit of a timeout regression for slower setups.
also note that the kubeadm CP provider in CAPI does not yet support this feature and the upgrade CAPI jobs are also failing:
actually, the feature seems change the order of "init": it waits for the apiserver + kubelet (, 40seconds for kubelet) and the RBAC create ( when the first client() creation happens) at the same time. i think what has to be changed here is: the parallel aspect of the apiserver + kubelet wait. it has been difficult to manage and confusing. delay the RBAC create to be after the apiserver + kubelet waiting is done. maybe something we can do for .29 is 2. but 1 is a bigger refactor.
PR with an attempt to improve the kubeadm wait logic: i do think CAPG has unrelated problems. the kubelet might be failing to start or starting but not creating the static pod for kube-apiserver.
Code change:
}, expectedError: false, }, <ins> { name: "super-admin.conf: admin.conf cannot create CRB, try to create CRB with super-admin.conf, encounter 'already exists' error", setupAdminClient: func(client *clientsetfake.Clientset) { client.PrependReactor("create", "clusterrolebindings", func(action clientgotesting.Action) (bool, runtime.Object, error) { return true, nil, apierrors.NewForbidden( schema.GroupResource{}, "name", errors.New("")) }) }, setupSuperAdminClient: func(client *clientsetfake.Clientset) { client.PrependReactor("create", "clusterrolebindings", func(action clientgotesting.Action) (bool, runtime.Object, error) { return true, nil, apierrors.NewAlreadyExists( schema.GroupResource{}, "name") }) }, expectedError: true, }, </ins> } for _, tc := range tests {

Related discussion:
text: Had some discussion with Carlos. I didn't follow this issue here in full detail, but probably the CAPG issue is resolved by the PR that we merged in core CAPI and will be part of the CAPI rc next week
yes, seems to work now :) thank you all!!!
Code change:
return nil, err } c.defaultConfig = config if c.matchVersion { if err := client.MatchesServerVersion(config); err != nil { return nil, err } } } // TODO: have a better config copy method config := *c.defaultConfig <ins> if len(version) != 0 { config.Version = version } </ins> client.SetKubernetesDefaults(&config) return &config, nil }

Related discussion:
text: I stumbled across this while experimenting with kubeconfig load order/merging. There are various helpers constructed from a Factory that use , however this always uses the same default ClientConfig because doesn't use the passed in version param: Am I missing something or is this a bug? /cc
Looks like a bug, clientforversion should accept "" (which can provide a default) and SetKubernetesDefaults has the final fallback protection (by using latest.Version). If version != defaultConfig.Version, we should copy defaultConfig, set version, then apply kubedefaults. The reason we take version here is if a resource is specified via file which only exists in a newer version, ie user says: --api-version=v1beta1 -f RESTMapper can handle that newresource is only valid for v1beta3 and apply the right override, then ask for client. --api-version is expected to bubble up via default config.
Code change:
var map_ServicePort = map[string]string{ "":           "ServicePort contains information on service's port.", <del> "name":       "The name of this port within the service. This must be a DNS_LABEL. All ports within a ServiceSpec must have unique names. This maps to the 'Name' field in EndpointPort objects. Optional if only one ServicePort is defined on this service.", </del> <ins> "name":       "The name of this port within the service. This must be a DNS_LABEL. All ports within a ServiceSpec must have unique names. When considering the endpoints for a Service, this must match the 'name' field in the EndpointPort. Optional if only one ServicePort is defined on this service.", </ins> "protocol":   "The IP protocol for this port. Supports "TCP", "UDP", and "SCTP". Default is TCP.", "port":       "The port that will be exposed by this service.", "targetPort": "Number or name of the port to access on the pods targeted by the service. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. If this is a string, it will be looked up as a named port in the target Pod's container ports. If this is not specified, the value of the 'port' field is used (an identity map). This field is ignored for services with clusterIP=None, and should be omitted or set equal to the 'port' field. More info: https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service",

Related discussion:
text: ): uname -a Linux 4.15.0-51-generic -Ubuntu SMP Wed May 15 14:27:21 UTC 2019 x8664 x8664 x86_64 GNU/Linux Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig api-machinery
/remove-sig api-machinery /sig network The name mapping to the endpoints is intentional, but needs documentation
/triage unresolved
/assign
It may be under-documented, but it is not UNdocmented.
Also
working on a PR to fix doc
Code change:
httpCacheDir := filepath.Join(cacheDir, "http") discoveryCacheDir := computeDiscoverCacheDir(filepath.Join(cacheDir, "discovery"), config.Host) <del> return diskcached.NewCachedDiscoveryClientForConfig(config, discoveryCacheDir, httpCacheDir, time.Duration(10*time.Minute)) </del> <ins> return diskcached.NewCachedDiscoveryClientForConfig(config, discoveryCacheDir, httpCacheDir, time.Duration(6*time.Hour)) </ins> } // ToRESTMapper returns a mapper.

Related discussion:
text: The discovery cache for kubectl is defaulted to 10 minutes: That means that every 10 minutes of using against a cluster, it runs API requests against all group versions, which can take quite some time on clusters with many operators installed (like , , , etc.). I previously wrote that shows that every 10 minutes a simple makes 170 API requests against a test cluster, vs 4 API requests when the cache exists. That results in significant productivity implications against such clusters. Here is a time comparison between a request that runs the discovery cache vs one that doesn't: The discovery cache doesn't really have to run every 10 minutes, as CRDs don't change that often. A lot of unnecessary load is created on clients and servers. This issue is raised to change the discovery cache default to 24 hours and also to make the discovery cache ttl configurable. Running the discovery cache every 10 minutes has a significant productivity impact on using on clusters with many CRDs as it is taking time to run these unnecessary requests. The discovery cache doesn't really have to run every 10 minutes, as CRDs don't change that often. A lot of unnecessary load is created on clients and servers.
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 cli
I would like to work on this issue.
/assign
Code change:
allErrs := validation.ValidateDaemonSet(obj.(*extensions.DaemonSet)) allErrs = append(allErrs, validation.ValidateDaemonSetUpdate(newDaemonSet, oldDaemonSet)...) <del> // Update is not allowed to set Spec.Selector for all groups/versions except extensions/v1beta1. </del> <ins> // Update is not allowed to set Spec.Selector for apps/v1 and apps/v1beta2 (allowed for extensions/v1beta1). </ins> // If RequestInfo is nil, it is better to revert to old behavior (i.e. allow update to set Spec.Selector) // to prevent unintentionally breaking users who may rely on the old behavior. // TODO(#50791): after extensions/v1beta1 is removed, move selector immutability check inside ValidateDaemonSetUpdate().

Related discussion:
text: /priority failing-test /priority critical-urgent /sig apps This test case has been failing for a while and affects a number of jobs: This is affecting multiple jobs on the testgrid dashboard, and prevents us from cutting 1.9.0-alpha.2 (kubernetes/sig-release). Is there work ongoing to bring this job back to green?
All test failures look similar: . ~Is it due to network issue instead of DaemonSet?~
This seems related to the new DaemonSet. The connection refused error is happening because kube-apiserver is crashing:
needs an update
Ah, well... I guess it's halfway working as intended. We put that there to make the tests fail if we forgot to update it when adding a new version. We had hoped it would fail during presubmit tests though. :(
Sending a fix now
I wonder why the test is not failing on submit queue tests. Do i need to fix deployment and replicaset?
The rest of the group is not merged, and the v1 PR takes the selector mutability into account.
Since this bug crashes apiserver I'd expect it to affect many other e2e tests.
Noted, we need to fix deployment and replicaset when the v1 PR is merged.
Not quite sure how this test isn't failing before but is now consistently failing. I'd expect the commit that triggers this to block the submit queue. The e2e test is still accessing DaemonSet through extensions/v1beta1 endpoints. From the above apiserver log it's hard to tell what updates DaemonSet via apps/v1 before the code panics. I tried to reproduce it locally, and found that garbage collector PUT apps/v1 DaemonSet:
When apps/v1 gets introduced, it may be ordered before apps/beta1 alphabetically. IIRC, there is a code change on the apps/v1 PR that changes the order of API versions such that apps/v1 is ranked before apps/v1beta2 and apps/v1beta2 before apps/v1beta1. Perhaps this problem can be fixed when the PR merges.
Since crashes apiserver and makes debugging harder, which defeats the purpose of using it, we should return error on unsupported versions instead.
The first run with this change is still in progress, but this test already passed: https://k8s- Thanks for the quick fix
Code change:
} }) }) <ins> // fullIPv6 returns a string with the IP representation // if IPv6 it returns the expanded address format // credit https://stackoverflow.com/a/52003106/4532704 func fullIPv6(ip net.IP) string { if ip.To4() == nil { dst := make([]byte, hex.EncodedLen(len(ip))) _ = hex.Encode(dst, ip) return string(dst[0:4]) + ":" + string(dst[4:8]) + ":" + string(dst[8:12]) + ":" + string(dst[12:16]) + ":" + string(dst[16:20]) + ":" + string(dst[20:24]) + ":" + string(dst[24:28]) + ":" + string(dst[28:]) } return ip.String() } </ins>

Related discussion:
text: Which jobs are failing: kops-aws and many other jobs Which test(s) are failing: This isn't the actual test, but the text we're consistently seeing is Since when has it been failing: Testgrid links: (ref: ) Reason for failure: TBD Anything else we need to know: Very rarely tests pass when one of the tests passes: Seems related to , that was merged about the same time:
/sig cluster-lifecycle /sig aws
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig cluster-lifecycle /sig aws 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
/priority critical-urgent this is merge blocking
/assign /cc /cc /cc
The PR we think we want to revert
is also failing, I don't think this is aws-specific
/cc
/assign
it failed with kind too :/ with the same message
Opened to revert
/unassign /sig network /sig testing /remove-sig cluster-lifecycle
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
This may be the actual cause PR to address But we're going with revert first to be sure we've identified the offending PR
I think I've identified the root cause
Revert brought us back to green: Awaiting root cause fix
/remove-triage unresolved
/reopen merged but we're now seeing multiple tests fail since it merged Looking at it went red between these commits:
Reopened this issue. <detailsIn response to : /reopen merged but we're now seeing multiple tests fail since it merged 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
is an attempt to fix
reverting in
is the failure cluster I suspect will go down once the revert goes in
/close Failure cluster has gone down, calling this done <img width="998" alt="Screen Shot 2020-01-10 at 9 56 17 AM" src="https://user-"
Closing this issue.
Code change:
} }) }) <ins> // fullIPv6 returns a string with the IP representation // if IPv6 it returns the expanded address format // credit https://stackoverflow.com/a/52003106/4532704 func fullIPv6(ip net.IP) string { if ip.To4() == nil { dst := make([]byte, hex.EncodedLen(len(ip))) _ = hex.Encode(dst, ip) return string(dst[0:4]) + ":" + string(dst[4:8]) + ":" + string(dst[8:12]) + ":" + string(dst[12:16]) + ":" + string(dst[16:20]) + ":" + string(dst[20:24]) + ":" + string(dst[24:28]) + ":" + string(dst[28:]) } return ip.String() } </ins>

Related discussion:
text: <detailsIn response to : /close Failure cluster has gone down, calling this done <img width="998" alt="Screen Shot 2020-01-10 at 9 56 17 AM" src="https://user-"</details
Code change:
func AddApiWebService(s runtime.NegotiatedSerializer, container *restful.Container, apiPrefix string, getAPIVersionsFunc func(req *restful.Request) *unversioned.APIVersions) { // TODO: InstallREST should register each version automatically <del> versionHandler := APIVersionHandler(s, getAPIVersionsFunc) </del> <ins> // Because in release 1.1, /api returns response with empty APIVersion, we // use StripVersionNegotiatedSerializer to keep the response backwards // compatible. ss := StripVersionNegotiatedSerializer{s} versionHandler := APIVersionHandler(ss, getAPIVersionsFunc) </ins> ws := new(restful.WebService) ws.Path(apiPrefix) ws.Doc("get available API versions")

Related discussion:
text: Kubectl client Kubectl api-versions should check if v1 is in available api versions [Conformance] Expected error: <_errors.errorString | 0xc208641770: { s: "Error running &{/jenkins-master-data/jobs/kubernetes-upgrade-gke-1.1-master-step1-deploy/workspace/kubernetes/platforms/linux/amd64/kubectl [kubectl --server=https://130.211.136.232 --kubeconfig=/var/lib/jenkins/jobs/kubernetes-upgrade-gke-1.1-master-step1- api-versions] [] error: Couldn't get available api versions from server: no kind "APIVersions" is registered for version "v1"n [] 0xc208382fa0 exit status 1 true [0xc208627148 0xc208627168 0xc208627188] [0xc208627148 0xc208627168 0xc208627188] [0xc208627160 0xc208627180] [0x6d81a0 0x6d81a0] 0xc2082fb2c0}:nCommand stdout:nnstderr:nerror: Couldn't get available api versions from server: no kind "APIVersions" is registered for version "v1"nn", } Error running &{/jenkins-master-data/jobs/kubernetes-upgrade-gke-1.1-master-step1-deploy/workspace/kubernetes/platforms/linux/amd64/kubectl [kubectl --server=https://130.211.136.232 --kubeconfig=/var/lib/jenkins/jobs/kubernetes-upgrade-gke-1.
Code change:
func AddApiWebService(s runtime.NegotiatedSerializer, container *restful.Container, apiPrefix string, getAPIVersionsFunc func(req *restful.Request) *unversioned.APIVersions) { // TODO: InstallREST should register each version automatically <del> versionHandler := APIVersionHandler(s, getAPIVersionsFunc) </del> <ins> // Because in release 1.1, /api returns response with empty APIVersion, we // use StripVersionNegotiatedSerializer to keep the response backwards // compatible. ss := StripVersionNegotiatedSerializer{s} versionHandler := APIVersionHandler(ss, getAPIVersionsFunc) </ins> ws := new(restful.WebService) ws.Path(apiPrefix) ws.Doc("get available API versions")

Related discussion:
text: 1-master-step1- api-versions] [] error: Couldn't get available api versions from server: no kind "APIVersions" is registered for version "v1" [] 0xc208382fa0 exit status 1 true [0xc208627148 0xc208627168 0xc208627188] [0xc208627148 0xc208627168 0xc208627188] [0xc208627160 0xc208627180] [0x6d81a0 0x6d81a0] 0xc2082fb2c0}: Command stdout: stderr: error: Couldn't get available api versions from server: no kind "APIVersions" is registered for version "v1" not to have occurred* See and Investigating. cc
Okiedokie. Looks like the v1.1 client is getting a response from the v1.2 master, but the v1.1 client doesn't know how to handle the v1 APIVersions object, because in v1.1, that object was never expected to have an . From a 1.1 server, we get which doesn't include a . We should expect to have plenty of pre-v1.1.7 clients floating around, and releasing a fixed v1.1.8 probably isn't going to solve this; if we want to be backward compatible, we need to not return an string with unversioned kinds like . Looking into more details about how we got here... cc cc
I have a maybe feeling that this is caused by ? In particular, we went from: to
Probably it's caused by this:
Let me double check the code. cc
What about that line? I've never dealt with the version negotiation; should the server and client be negotiating in a way that the server can return an object without ?
More precisely it's this line: This line sets the version to "v1". In , during encoding, we set unversioned object's APIVersion field to "v1".
I think in the long run, because we expect to move many unversioned types to group "common", so they should be versioned, so making APIVersion=v1 is the right move. Back to the backwards compatibility issue, how's the situation at other url, like http://127.0.0.1:8080/apis/extensions?