jiebi/CodeConvo huggingface dataset:
Change:
ServiceTopology:                                {Default: false, PreRelease: featuregate.Alpha}, ServiceAppProtocol:                             {Default: true, PreRelease: featuregate.Beta}, ImmutableEphemeralVolumes:                      {Default: true, PreRelease: featuregate.Beta}, <del> DefaultIngressClass:                            {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.20 </del> HugePageStorageMediumSize:                      {Default: true, PreRelease: featuregate.Beta}, ExternalPolicyForExternalIP:                    {Default: true, PreRelease: featuregate.GA}, // remove in 1.20 AnyVolumeDataSource:                            {Default: false, PreRelease: featuregate.Alpha},

Discussion:
When should it be removed? /sig network /kind cleanup
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
According to , it need to remove in 1.20. /assign
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
/remove-triage unresolved
Change:
"strings" "sync" "sync/atomic" <ins> "syscall" </ins> "time" "github.com/golang/glog"

Discussion:
There's some practical limit on the number of concurrent access tokens that can be used in a Kubernetes cluster before it begins to spend all of its time in the authn stack verifying them. Absent fixes to it was < 500; with the fixes linked there it's still not infinitely scalable-- I still hit (what I believe to be) with ~ 5k unique tokens @ ~700QPS. This request is to this dimension an official name & definition, and list it with others, e.g. here: it it have a useful value (I think it should be 10k) /kind bug /sig scalability
/cc
oh and 4. add tests which verify it is as high as believed.
cc since projected tokens will increase the number of unique tokens
/sig auth
LRUs are not good at scaling and sharding has some major pitfalls as pointed out. I would suggest that we try to drop the LRU cache for successful authentication results in the token cache. The main benefit of using an LRU here is bound cache size. Entries in the token cache have a fast expiration independent of the LRU policy. The records probably take up O(2kb) (guesstimate) of memory. Given that these are successful attempts with presumably valid tokens, I don't think we are getting any benefit from the LRU. If we don't have a constraint on fixed cache size, we can back the token cache with a sync.Map and run a single background goroutine to periodically walk the map and remove expired entries. This would fix the problematic locking and eviction due to nonuniform distribution of tokens over shards. The failure cache is less important and we don't cache failures by default. If we consider this the "slowpath", we can probably leave it as. If that's not good enough, we have a couple options (with various tradeoffs) to improve it.
If off by default is not enough, more reasoning why the failed cache is not super useful: it might help with an accidental DoS but it doesn't prevent anything actively malicious DoS. I think we can focus our improvements on the success cache.
/assign He is already working on adding an explicit test for it.
has taken it over and is actively working on this. Unfortunately, I cannot assign this issue to him as he's not a k8s member yet
It's not closed - all testes must be submitted and appropriate documentation must be
Thanks everyone!!
Change:
can then aim traffic at the `Service` port on that `Node` and it will be proxied to the backends. <ins> ## Choosing your own PortalIP address A user can specify their own ```PortalIP``` address as part of a service creation request.  For example, if they already have an existing DNS entry that they wish to replace, or legacy systems that are configured for a specific IP address and difficult to re-configure.  The ```PortalIP``` address that a user chooses must be a valid IP address and within the portal net CIDR range that is specified by flag to the API server.  If the PortalIP value is invalid, the apiserver returns a ```422``` HTTP status code to indicate that the value is invalid. </ins> ## Shortcomings We expect that using iptables and userspace proxies for portals will work at

Discussion:
According to this page: "PortalIP is usually assigned by the master. If specified by the user // we will try to respect it or else fail the request. This field can // not be changed by updates." PortalIP string to clarify the above - it means that user is allowed to assign it during creation of service, but not during update service - correct? why update is not supported as well? are the considerations for "we will try to respect it" - what validations are made (Except for addr already in use) ? exact error is returned when it can't be assigned?
1) We did not support update because it is a bit more complicated, but mostly because the semantic we want around services is that the IP never changes. 2) We ensure that the IP is within the "portal net" CIDR and not used already. 3) I am 99% sure it returns an HTTP 422 error , abonas wrote:
is there anywhere (or at least planned) the documentation of various errors returned from REST api? I mean beyond the standard 404, 500, etc. For instance - for duplicate entities, validation errors on entity content, things like the above. Is there a distinction between wrong json (which should always fail) and the above which is more of a runtime error? I know some apis (not kubernetes) will actually return 400 in this case and not 422, so declaration of errors will be a great help for consumers of REST api. (one can always experiment, test and register all those errors, but consider how time consuming that can be)
We do plan to document and test (and, in some cases, fix) status code behavior: .
Brian - you 1.0 milestone to this issue, but I'm not sure what is the action item here. Can you please explain what should be done?
The action here is/was to verify the behavior and ensure it is documented correctly. Thanks to we now have general status code behavior documented: It doesn't say what happens in this specific case, though I don't know that it's possible to document every specific case, at least not in a way that's kept up to date. I can confirm that 422 is returned in this case: It would be useful to document that users/clients can specify PortalIP in the services doc:
I'll take the update to and then close this.
Change:
terminationGracePeriodSeconds: 600 hostNetwork: true containers: <del> - image: gcr.io/k8s-ingress-image-push/ingress-gce-glbc-amd64:v1.11.0 </del> <ins> - image: gcr.io/k8s-ingress-image-push/ingress-gce-glbc-amd64:v1.12.0 </ins> livenessProbe: httpGet: path: /healthz

Discussion:
found this in while finding beta API dependencies for 1.22. This will block from running at all in 1.22 I think this is for this deployment: , and in ingress-gce I found
/sig network /triage accepted I pinged some GCE sig-network folks in the PR
given that uses extensions/v1beta1 Deployments, that particular manifest seems unused
once we land the fix in , anyone know how to update the image we use in e2e tests?
/assign The update to use v1 APIs is merged to in What version should be tagged we can pick up in Does need to be picked back to one or more release branches?
It would be helpful to get a version containing the fix tagged, so the manifest can be updated in to get e2e signal even before opens for 1.22.
Ack. We are planning to cut a release soon. Once the release is cut, I will update the k/k to use that
what's the ETA for cutting ingress-gce release? I think it might be related to failing pull-kubernetes-e2e-gce-100-performance run in
Change:
testSlowMultiplier = 10 // How long to wait until CSINode gets attach limit from installed CSI driver. <del> csiNodeInfoTimeout = 1 * time.Minute </del> <ins> csiNodeInfoTimeout = 2 * time.Minute </ins> ) var _ storageframework.TestSuite = &volumeLimitsTestSuite{}

Discussion:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig storage /kind flake
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
Change:
Currently, local-up scripts, GCE scripts and kubeadm support switching IPVS proxy mode via exporting environment variables or specifying flags. ### Prerequisite <del> Ensure IPVS required kernel modules </del> <ins> Ensure IPVS required kernel modules (**Notes**: use `nf_conntrack` instead of `nf_conntrack_ipv4` for Linux kernel 4.19 and later) </ins> ```shell ip_vs ip_vs_rr

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!--kube-proxy cannot use ipvs mode on Linux 4.19 due to a check for the module, which was changed to (). uses to check for : It should instead accept on Linux 4.19 or above. What happened: kube-proxy fell back from ipvs mode to iptables mode. What you expected to happen: kube-proxy using ipvs. How to reproduce it (as minimally and precisely as possible): Launch a cluster on an image using Linux 4.19 or above with kube-proxy using ipvs mode (see ). Environment: Kubernetes version (use ): All Kernel (e.g. ): 4.19 <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig network
/area ipvs /assign /cc
Okay, so should check {nfconntrackipv4 | nf_conntrack} and expect load at least one module?
I think so
Please just go ahead :)
Change:
// the list automatically by PodDisruptionBudget controller after some time. // If everything goes smooth this map should be empty for the most of the time. // Large number of entries in the map may indicate problems with pod deletions. <del> DisruptedPods map[string]metav1.Time `json:"disruptedPods" protobuf:"bytes,2,rep,name=disruptedPods"` </del> <ins> // +optional DisruptedPods map[string]metav1.Time `json:"disruptedPods,omitempty" protobuf:"bytes,2,rep,name=disruptedPods"` </ins> // Number of pod disruptions that are currently allowed. PodDisruptionsAllowed int32 `json:"disruptionsAllowed" protobuf:"varint,3,opt,name=disruptionsAllowed"`

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: PodDisruptionBudget provides inappropriate message and cannot be updated as is required filed. What you expected to happen: works fine for editing labels under . Also, produce correct error message when edit field. How to reproduce it (as minimally and precisely as possible): Then, we will get following error after step-2. When edit , it should provide correct message as .When edit especially labels under metadata, they should be updated without error. Anything else we need to know?: According to the code comment, is valid. Environment: Kubernetes version (use ): build on
/sig cli
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 there is a PR open
Change:
} } } <ins> func TestValidatePodDisruptionBudgetUpdate(t *testing.T) { c1 := intstr.FromString("10%") c2 := intstr.FromInt(1) c3 := intstr.FromInt(2) oldPdb := &policy.PodDisruptionBudget{} pdb := &policy.PodDisruptionBudget{} testCases := []struct { generations []int64 name        string specs       []policy.PodDisruptionBudgetSpec status      []policy.PodDisruptionBudgetStatus ok          bool }{ { name:        "only update status", generations: []int64{int64(2), int64(3)}, specs: []policy.PodDisruptionBudgetSpec{ { MinAvailable:   &c1, MaxUnavailable: &c2, }, { MinAvailable:   &c1, MaxUnavailable: &c2, }, }, status: []policy.PodDisruptionBudgetStatus{ { PodDisruptionsAllowed: 10, CurrentHealthy:        5, ExpectedPods:          2, }, { PodDisruptionsAllowed: 8, CurrentHealthy:        5, DesiredHealthy:        3, }, }, ok: true, }, { name:        "only update pdb spec", generations: []int64{int64(2), int64(3)}, specs: []policy.PodDisruptionBudgetSpec{ { MaxUnavailable: &c2, }, { MinAvailable:   &c1, MaxUnavailable: &c3, }, }, status: []policy.PodDisruptionBudgetStatus{ { PodDisruptionsAllowed: 10, }, { PodDisruptionsAllowed: 10, }, }, ok: false, }, { name:        "update spec and status", generations: []int64{int64(2), int64(3)}, specs: []policy.PodDisruptionBudgetSpec{ { MaxUnavailable: &c2, }, { MinAvailable:   &c1, MaxUnavailable: &c3, }, }, status: []policy.PodDisruptionBudgetStatus{ { PodDisruptionsAllowed: 10, CurrentHealthy:        5, ExpectedPods:          2, }, { PodDisruptionsAllowed: 8, CurrentHealthy:        5, DesiredHealthy:        3, }, }, ok: false, }, } for i, tc := range testCases { oldPdb.Spec = tc.specs[0] oldPdb.Generation = tc.generations[0] oldPdb.Status = tc.status[0] pdb.Spec = tc.specs[1] pdb.Generation = tc.generations[1] oldPdb.Status = tc.status[1] errs := ValidatePodDisruptionBudgetUpdate(oldPdb, pdb) if tc.ok && len(errs) > 0 { t.Errorf("[%d:%s] unexpected errors: %v", i, tc.name, errs) } else if !tc.ok && len(errs) == 0 { t.Errorf("[%d:%s] expected errors: %v", i, tc.name, errs) } } } </ins>

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?: /kind bug What happened: When trying to forcefully update using command segmentatio voliation happens. What you expected to happen: podDistributionBudget to be replaced How to reproduce it (as minimally and precisely as possible): create : Create : Forcefull update (replace) : Anything else we need to know?: The same error happens on kubectl version 1.6 or 1.7. Manually deleting and recreating works. Environment: Kubernetes version (use ): 1.7 Cloud provider or hardware configuration**: gke OS (e.g. from /etc/os-release): Debian GNU/Linux 7 (wheezy) Kernel (e.g. ): 3.16.0-4-amd64
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., for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig cli
This issue not only applies to PBP's but NetworkPolicy (and perhaps others).
Change:
e2essh "k8s.io/kubernetes/test/e2e/framework/ssh" ) <del> const etcdImage = "3.5.3-0" </del> <ins> const etcdImage = "3.5.4-0" </ins> // EtcdUpgrade upgrades etcd on GCE. func EtcdUpgrade(targetStorage, targetVersion string) error {

Discussion:
Please publish 3.5.4-0 image and update to to benefit from fix for , while still keeping v3.5.3 critical correctness fixes (, ). For recent PRs for update to etcd v3.5.3 see and
/sig release /sig api-machinery /kind bug
/cc /triage accepted
Hey, Can I work on this ? I'm a beginner, but all the good first issues are mostly assigned. Can you guide me on doing this ?
I am working on this. /assign
Hi I would like to work on Make sense to backport in v1.22, v1.23 & v1.24? Thanks!!
hi, it makes sense to me, but requires approval from dependency maintainers. i can only approve the kubeadm changes.
was this backported ?
Change:
Param("fieldValidation", "Strict"). Body(yamlBody). DoRaw(ctx) <del> if !(strings.Contains(string(result), `line 11: key "foo" already set in map`)) { </del> <ins> if !(strings.Contains(string(result), `line 9: key "foo" already set in map`)) { </ins> framework.Failf("error missing duplicate field: %v:n%v", err, string(result)) } })

Discussion:
After running k8s conformance testing on kubernetes v1.27, we have leftover custom resources of the format that should not exist. For example) Basic test instructions: We use the latest official kubernetes kubekins image: We extract kubetest binary from kubekins latest-master docker image. We run serial conformance tests as follows. We also run parallel conformance tests as follows.
/sig api-machinery
The following script is used to cleanup the leftover CRDs:
/triage accepted /assign /cc
/area conformance
/sig architecture
Change:
type readWriteOncePodTest struct { config *storageframework.PerTestConfig <del> cs     clientset.Interface volume *storageframework.VolumeResource pods   []*v1.Pod </del> <ins> cs            clientset.Interface volume        *storageframework.VolumeResource pods          []*v1.Pod priorityClass *schedulingv1.PriorityClass </ins> migrationCheck *migrationOpCheck }

Discussion:
For 1.27 we should graduate the ReadWriteOncePod feature to beta. This is needed to rollout the feature to GA. In beta this feature will support preemption of pods using PVCs. See:
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 storage /sig scheduling
Change:
var prober volume.DynamicPluginProber = nil // TODO (#51147) inject mock kubelet.volumePluginMgr, err = <del> NewInitializedVolumePluginMgr(kubelet, kubelet.secretManager, kubelet.configMapManager, token.NewManager(kubelet.kubeClient.CoreV1()), allPlugins, prober) </del> <ins> NewInitializedVolumePluginMgr(kubelet, kubelet.secretManager, kubelet.configMapManager, token.NewManager(kubelet.kubeClient), allPlugins, prober) </ins> require.NoError(t, err, "Failed to initialize VolumePluginMgr") kubelet.mounter = &mount.FakeMounter{}

Discussion:
/kind bug /priority failing-test /priority important-critical /milestone v1.11 /assign cc All GKE jobs are failing in various release dashboards. Code freeze for 1.11 is a couple of hours away.
Common error appears to be:
Failures seem to align with when was merged. But nothing in that PR seems suspicious. Having verify. Bringing up my own cluster on head to try and get a live cluster.
I have a quick try to reproduce one of the failure test cases by gcloud container clusters create --addons=HttpLoadBalancing,HorizontalPodAutoscaling,KubernetesDashboard --machine-type=n1-standard-2 --image-type=gci --num-nodes=3 --cluster-version=1.11.0-beta.1.222+ test- The cluster isn't up. What I observed is the following: 1) kubelet on master is in crash-loop due to a panic No other master components could be up. 2) kubelet is in crashloop in node as well.
/sig node Looks like has a patch up at
/priority critical-urgent
/status approved-for-milestone
Waiting for new runs to verify the fix. Will reopen this issue if needed
/reopen Reopening this one until its actually verified to ensure it shows up in our tracking queries.
I see the GKE tests cleaning up in the . still doesn't seem to have the change (will have to wait for cutover?). The fix looks promising. Will wait for a couple more runs before I close
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code freeze, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues. Action Required: This issue has not been updated since Jun 6. Please provide an update. Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release.

</details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
all the GKE ones still look good /close
Change:
genericfeatures "k8s.io/apiserver/pkg/features" "k8s.io/apiserver/pkg/server/egressselector" utilfeature "k8s.io/apiserver/pkg/util/feature" <ins> utilflowcontrol "k8s.io/apiserver/pkg/util/flowcontrol" </ins> "k8s.io/apiserver/pkg/util/x509metrics" restclient "k8s.io/client-go/rest" "k8s.io/client-go/transport"

Discussion:
On a cluster with many APIs provided by aggregated apiservers, with controllers managing those APIs, the number of occupied seats effectively has a floor of 1 per watch. If the combined max-inflight limit is reduced low enough, priority levels tend to become saturated by these long-running watch requests and other requests are starved. Watch requests consume a seat only during initialization. a PriorityLevelConfiguration and a corresponding FlowSchema to match watches against a resource served by an aggregated apiserver. some watch requests. the metric climb on the priority level per watch until all seats are exhausted. Kubernetes version (use ): (OpenShift 4.9) /sig api-machinery
cc
D'oh! I can see two obvious possible ways to cope: one apiserver not manage watch requests the are delegated to another apiserver; or a marker into the notification stream so that the non-origin apiservers can detect when initialization is done.
I would even say that for regular (non-long-running) requests, it's not obvious that they should be managed by P&F even. [I agree that for watch initialization it's particularly bad though.] - do we have a simple way to detect if the request will be served from our kube-apiserver or from some other aggregated apiserver?
There is not currently a way to know that ahead of time in the filters today. It require a list/watch, but it ought not be excessively expensive to make a 99% correct prediction, but the actual decision is made by the aggregated apiserver later in the request.
/triage accepted
: is there a way that we can plumb that knowledge forward to the filters?
Change:
client := fake.NewSimpleClientset( &v1.Service{Spec: v1.ServiceSpec{Selector: map[string]string{"foo": ""}}}, ) <del> ctx := context.Background() </del> <ins> ctx, cancel := context.WithCancel(context.Background()) defer cancel() </ins> informerFactory := informers.NewSharedInformerFactory(client, 0) _ = informerFactory.Core().V1().Services().Lister() informerFactory.Start(ctx.Done())

Discussion:
The ctx object () is context.Background(). Thus, its Done() method returns a nil channel. Later, the nil channel is used to call and as their argument. The goroutines created in the two functions are leaked. No goroutine leaks in TestSelectorSpreadScore(). Run TestSelectorSpreadScore() No response all versions after <details</details<details</details<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
/sig scheduling (It sounds like leas in unit tests, which may be negligible. Does it cause some test failures?)
the test can pass.
/assign
/unassign /assign