jiebi/CodeConvo huggingface dataset:
Change:
func alwaysAlice(req *http.Request) (*authenticator.Response, bool, error) { return &authenticator.Response{ User: &user.DefaultInfo{ <del> Name: "alice", </del> <ins> Name:   "alice", UID:    "alice", Groups: []string{user.AllAuthenticated}, </ins> }, }, true, nil }

Discussion:
While moving APF to beta (see comments on ), we discovered that the integration tests commonly present users which are not members of any groups. We had thought that the system enforced membership in either the authenticated or unauthenticated group. If this is supposed to be a system invariant (as we thought), we'd like to ask SIG Auth: Please fix the integration tests Please add e.g. logging so that if real, operational clusters hit this there's at least a log message and people will file bugs. /sig auth
Can I suggest also, if this is a real invariant, that it be documented in some place(s) likely to be read?
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 /priority important-longterm /triage accepted
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]:
/lifecycle frozen
fixes the authenticator configured in one of the integration test API server startup helpers which resolved this issue for . Remaining tests that still need fixing that are encountering unexpected users look to be ones set up to specifically test auth paths:
open to fix remaining integration test users
Change:
} func (s *Plugin) mountServiceAccountToken(serviceAccount *corev1.ServiceAccount, pod *api.Pod) error { <del> // Find the name of a referenced ServiceAccountToken secret we can mount serviceAccountToken, err := s.getReferencedServiceAccountToken(serviceAccount) if err != nil { return fmt.Errorf("Error looking up service account token for %s/%s: %v", serviceAccount.Namespace, serviceAccount.Name, err) </del> <ins> var ( // serviceAccountToken holds the name of a secret containing a legacy service account token serviceAccountToken string err                 error ) if !s.boundServiceAccountTokenVolume { // Find the name of a referenced ServiceAccountToken secret we can mount serviceAccountToken, err = s.getReferencedServiceAccountToken(serviceAccount) if err != nil { return fmt.Errorf("Error looking up service account token for %s/%s: %v", serviceAccount.Namespace, serviceAccount.Name, err) } </ins> } <del> if len(serviceAccountToken) == 0 { </del> <ins> if len(serviceAccountToken) == 0 && !s.boundServiceAccountTokenVolume { </ins> // We don't have an API token to mount, so return if s.RequireAPIToken { // If a token is required, this is considered an error

Discussion:
What happened: We enabled the feature gate on to start switching from non-expiring to expiring ServiceAccount tokens as . It works well. We then wanted to completely get rid of the "legacy" non-expiring ServiceAccount token Secrets. To do that we configured with (so it wouldn't auto-create the Secrets), removed the existing Secrets and removed the reference from the respective ServiceAccount to the Secret. This works as expected: No non-expiring token Secrets are generated. However, when creating a Pod we now see: This happens because the rejects the Pod because it cannot find a ServiceAccount token Secret (because it doesn't exist anymore as intended). What you expected to happen: When using the feature the legacy ServiceAccount token Secrets aren't used anymore, so a Pod should not be rejected if the Secret doesn't exist. The Pod doesn't even use the Secret at all. How to reproduce it (as minimally and precisely as possible): Enable feature gate Start with Create a new ServiceAccount Deploy a dummy app using that ServiceAccount Observe no Pod being created with Describe the corresponding ReplicaSet to see the above Error event. Anything else we need to know?: Looking at the it seems that at least one legacy Secret must exist in order for the Pod to get admitted. This is enforced even when and we're relying on projected token volumes. Following the code path when is enabled reveals that the token is never going to be used later on as there's no SecretVolume to be mounted in . In other words:  is just fine when . During the transition period it's fine to have the legacy Secrets lying around but ultimately it's desirable to get rid of them because as far as I can tell they are still happily accepted by the API server. Environment: Kubernetes version: tested on but code seems the same in and Cloud provider or hardware configuration: OS (e.g: ): Ubuntu 18.04.3 LTS Kernel (e.g. ): 4.15.0-1054-aws Install tools: /kind bug /sig auth
Fixed in
Thank you!
Change:
// ServiceAnnotationLoadBalancerResourceGroup is the annotation used on the service // to specify the resource group of load balancer objects that are not in the same resource group as the cluster. ServiceAnnotationLoadBalancerResourceGroup = "service.beta.kubernetes.io/azure-load-balancer-resource-group" <ins> // ServiceAnnotationAllowedServiceTag is the annotation used on the service // to specify a list of allowed service tags separated by comma ServiceAnnotationAllowedServiceTag = "service.beta.kubernetes.io/azure-allowed-service-tags" ) var ( // supportedServiceTags holds a list of supported service tags on Azure. // Refer https://docs.microsoft.com/en-us/azure/virtual-network/security-overview#service-tags for more information. supportedServiceTags = sets.NewString("VirtualNetwork", "VIRTUAL_NETWORK", "AzureLoadBalancer", "AZURE_LOADBALANCER", "Internet", "INTERNET", "AzureTrafficManager", "Storage", "Sql") </ins> ) // GetLoadBalancer returns whether the specified load balancer exists, and

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: When using the loadBalancerSourceRanges property of a service in a manifest, we are force to use a CIDR block. This was discovered while debugging the following issue. What you expected to happen: Azure allows us to use Service Tags (e.g. VirtualNetwork, Internet, etc) WE should be able to specify them form a k8s service manifest. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.7.11 Cloud provider or hardware configuration: Azure OS (e.g. from /etc/os-release): centOS 7.3 Kernel (e.g. ): 3.10 Install tools: Others:
/sig azure
Here's the requested Feature.
SourceRanges is part of service spec, while serviceTag is azure specific. I think we don't expect to add cloud-specific features into Kubernetes API. What about adding a new annotation for this? e.g.
I believe that at this stage, (no out of tree cloud provider logic), using an annotation would be the only way to go unfortunately.
/priority important-soon
/status approved-for-milestone
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : New functionality. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Change:
} func (rc *resourceMetricsCollector) collectNodeMemoryMetrics(ch chan<- metrics.Metric, s summary.NodeStats) { <del> if s.Memory == nil { </del> <ins> if s.Memory == nil || s.Memory.WorkingSetBytes == nil { </ins> return }

Discussion:
kubelet panic when accessing metrics/resource endpoint kubelet log kubelet works fine access metrics/resource endpoint of kubelet No response <details</details<details</details<details</details<details</details<detailsINFO[2022-07-14 05:36:21.474173892Z] Starting CRI-O, version: 1.23.0, git: (dirty) Version: 1.23.0 GitCommit: GitTreeState: dirty BuildDate: 1980-01-01T00:00:00Z GoVersion: go1.17.4 Compiler: gc Platform: linux/amd64 Linkmode: static BuildTags: apparmor, excludegraphdriverdevicemapper, seccomp, selinux SeccompEnabled: true AppArmorEnabled: true </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
/assign
/sig node
Change:
return &ValidationError{ValidationErrorTypeNotFound, field, value, ""} } <del> func NewFieldTooLong(field string, value interface{}) *ValidationError { return &ValidationError{ValidationErrorTypeTooLong, field, value, ""} </del> <ins> func NewFieldTooLong(field string, value interface{}, maxLength int) *ValidationError { return &ValidationError{ValidationErrorTypeTooLong, field, value, fmt.Sprintf("must have at most %d characters", maxLength)} </ins> } type ValidationErrorList []error

Discussion:
For example, creating a service with id 'redis-master10012345678999' fails and the returned message contains the following: "message": "service "redis-master10012345678999" is invalid: name: invalid value 'redis-master10012345678999' 'invalid value' is too general, users should understand exactly what is wrong with the input. for example - is it too long? does it contain characters that are not allowed?
Agree - there is now a place to stick the explanations in the ValidationError - we need to link together validation logic and that string. , abonas wrote:
I checked and it seems there are only two errors that do not have detailed explanation. I'll send a PR to fix this.
This is one:
Thanks for the pointer Brian! I'll send second PR to fix this one.
Still second PR to be sent.
Change:
importpath = "k8s.io/kube-aggregator/pkg/controllers/autoregister", deps = [ "//staging/src/k8s.io/apimachinery/pkg/api/errors:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/labels:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/runtime:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/wait:go_default_library",

Discussion:
k8s version: v1.9.3 When I create customresourcedefinition, There is error like Operation cannot be fulfilled on "": the object has been modified; please apply your changes to the latest version and try again . apiVersion: kind: CustomResourceDefinition metadata: name: annotations: "": crd-install labels: app: istio-pilot spec: group: names: kind: VirtualService listKind: VirtualServiceList plural: virtualservices singular: virtualservice categories: istio-io networking-istio-io scope: Namespaced version: v1alpha3 So what is the reason of it?
a few questions: where are you seeing the error, in the apiserver log or in the output of the kubectl command? what kubectl command are you using to create the object? are you running HA apiservers?
The log is shown by apiserver. I run k8s in HA apiservers. The command I used is "kubectl apply -f "+file.
API servers attempt to update CRD status to indicate whether the names were available. In an HA apiserver setup, the API servers race to do so, and all but the first lose the race with a resource conflict error. That is not unexpected. Opened to avoid logging normal API responses in that scenario.
Thanks ! But I want to know whether the CRD has been set successfully in HA apiservers ? I use the command " kubectl get crd -o yaml" and get the following results. ! I see its status is true. But when i create a virtualservices, it returns error. Error from server (Timeout): error when creating "cms-api-": Timeout: request did not complete within allowed duration ! So i want to know how to solve this error.
/assign
Excuse me. Do you have some greate ideas to solve this issue??
There is a PR for this sent by
I see your request is timed-out not failed. In HA, I expect the request to fail in the first seconds of the CRD creation, but after that it should go through. I need more logs during this timeout or a consistent way to reproduce it.
Change:
importpath = "k8s.io/kubernetes/test/e2e/framework/events", visibility = ["//visibility:public"], deps = [ <del> "//staging/src/k8s.io/api/core/v1:go_default_library", </del> "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", <del> "//staging/src/k8s.io/apimachinery/pkg/types:go_default_library", </del> "//staging/src/k8s.io/apimachinery/pkg/util/wait:go_default_library", "//staging/src/k8s.io/client-go/kubernetes:go_default_library", <del> "//test/e2e/framework:go_default_library", "//vendor/github.com/onsi/ginkgo:go_default_library", </del> ], )

Discussion:
[x] Original approval issue: [x] Two weeks soak end date: 6 July 2020 This issue is created to allow edit by /wip /hold According to this APIsnoop query, there are still an endpoint which is untested. a set of 3 Events with a static label within a Namespace. that all 3 Events with the label in the Namespaces are created. the set of Namespaced Events with a label via DeleteCollection. that all Events with the label have been deleted. Discover useragents: List endpoints hit by the test: Display endpoint coverage change: Two other endpoints tested here have tests in progress to conformance already. If a test with these calls gets merged, test coverage will go up by 1 points This test is also created with the goal of conformance promotion.
/sig testing /sig architecture /area conformance
During Conformance Meeting: Is there a way to write this test so it is resource agnostic? If we are just changing the resource... can be parameterize the resource-type
/assign
GitHub didn't allow me to assign the following users: heyste. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign 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
/reopen PR Merge and soaking
Reopened this issue. <detailsIn response to : /reopen PR Merge and soaking 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
Change:
f.lbScheme == other.lbScheme && equalStringSets(f.ports, other.ports) && f.backendService == other.backendService && <del> f.allowGlobalAccess == other.allowGlobalAccess </del> <ins> f.allowGlobalAccess == other.allowGlobalAccess && f.subnetwork == other.subnetwork </ins> } // toForwardingRuleComposite converts a compute beta or GA ForwardingRule into the composite type

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: ILB ip addresses come from the subnet that the K8s cluster uses. There is no ability to specify a different subnet. What you expected to happen: ILB ip addresses should be allocated from a different subnet if specified. 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: GCE OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/area platform/gce /assign
/sig network
Change:
- monit - nginx - kube-client-tools <ins> {% if grains['cloud'] is defined and grains['cloud'] != 'vagrant' %} </ins> - logrotate <ins> {% endif %} </ins> - kube-addons {% if grains['cloud'] is defined and grains['cloud'] == 'azure' %} - openvpn

Discussion:
It appears that the provision-network script that is run on the kubernetes-master can cause salt provisioning on the minions to fail or block in a forever retry timeout error loop. I think it's because of the service network.restart that happens after openvswitch is installed in provision-network. I only say this because when I disable installing docker on kubernetes-master in vagrant, I do not have an issue. - is there a different way we can structure this on the kubernetes-master? For example, could we run the script in or something?
Change:
"k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/types" <ins> utilfeature "k8s.io/apiserver/pkg/util/feature" "k8s.io/kubernetes/pkg/features" </ins> "k8s.io/kubernetes/pkg/util/mount" utilstrings "k8s.io/kubernetes/pkg/util/strings" "k8s.io/kubernetes/pkg/volume"

Discussion:
FEATURE REQUEST: vSphere volume plugin does not support volume device yet. Need to add volumeMode in PV spec as other plugin did. release 1.12
/sig storage
Change:
"io/ioutil" "log" "math/rand" <ins> "net" </ins> "net/http" <del> "net/url" </del> "os" "sync" "time" <del> "github.com/GoogleCloudPlatform/kubernetes/pkg/api/latest" </del> "github.com/GoogleCloudPlatform/kubernetes/pkg/client" "github.com/GoogleCloudPlatform/kubernetes/pkg/util" )

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:
return err } <ins> if o.ServerSideApply && o.DeleteOptions.ForceDeletion { return fmt.Errorf("--force cannot be used with --server-side") } </ins> if o.DryRunStrategy == cmdutil.DryRunServer && o.DeleteOptions.ForceDeletion { return fmt.Errorf("--dry-run=server cannot be used with --force") }

Discussion:
What happened: A resource is not replaced (deleted and recreated) when passing the flag to and the change cannot be applied. What you expected to happen: I expected the service to be replaced. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ):
/sig api-machinery /wg api-expression
/sig cli
/cc
Good to know, that's certainly worthy of a fix.
/cc
This is slightly related: If we want to support we could try and make the behavior clearer.
Can you weigh in on how important this is? We feel that is super, super dangerous in general. It's also very easy to confuse it with for server side apply, so it's extra dangerous. Do we need to implement this field for this command? Can we give an error, like "use one of: --force-conflicts or --delete-then-create"? Can SIG CLI do something about this flag in general?
/cc
Noted, I'll make sure this is in the agenda for the next sig-cli meeting.
I don't think the two are related. is now error-ing when used with , but it'll still fail with server-side apply.
You're right... my recall was bad. I deleted my comment where I thought was this, but it is not. Sorry about that
Looks like in the SIG-CLI meeting it was decided to not enable the user to use the and flag together. kubectl should fail immediately with a warning that should not be used with server side apply. Do you mind if I start working on this issue? I will reach out to you and other members of the SIG to get more details needed. I am a new contributor to k8s and would like to work on this issue.
Thanks for summarizing the discussion! I'd love to see you submit a PR for that, that's awesome!
/assign /lifecycle-active
Change:
if requestInfo.IsResourceRequest && longRunningSubresources.Has(requestInfo.Subresource) { return true } <ins> if !requestInfo.IsResourceRequest && strings.HasPrefix(requestInfo.Path, "/debug/pprof/") { return true } </ins> return false } }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: What happened: In the log: What you expected to happen: The timeout should be more relaxed on /debug/pprof endpoints. How to reproduce it (as minimally and precisely as possible):
/assign
Change:
outBuiltIn := e2ekubectl.RunKubectlOrDie("", "get", "nodes", node.Name) ginkgo.By(fmt.Sprintf("calling kubectl get nodes %s --subresource=status", node.Name)) outStatusSubresource := e2ekubectl.RunKubectlOrDie("", "get", "nodes", node.Name, "--subresource=status") <del> gomega.Expect(outBuiltIn).To(gomega.Equal(outStatusSubresource)) </del> <ins> // Avoid comparing values of fields that might end up // changing between the two invocations of kubectl. requiredOutput := [][]string{ {"NAME"}, {"STATUS"}, {"ROLES"}, {"AGE"}, {"VERSION"}, {node.Name},                           // check for NAME {""},                                  // avoid comparing STATUS {""},                                  // avoid comparing ROLES {""},                                  // avoid comparing AGE {node.Status.NodeInfo.KubeletVersion}, // check for VERSION } checkOutput(outBuiltIn, requiredOutput) checkOutput(outStatusSubresource, requiredOutput) </ins> }) }) })

Discussion:
Example: this PR seems to be flaking: comparing age of a node from the output of two commands: Kubernetes e2e suite: [It] [sig-cli] Kubectl client kubectl subresource flag GET on status subresource of built-in type (node) returns identical info as GET on the built-in type expandless 5 hours back No response No response No response_ /sig cli
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
/priority important-soon
it seems that is comparing subresources and there is something there that changes over time As Sergey correctly points out is the Age The test can not assume the executions will be done in the same second
/assign
Change:
_, err := runCommand("sh", "-c", cmd) return err } <ins> func systemctlDaemonReload() error { cmd := "systemctl daemon-reload" _, err := runCommand("sh", "-c", cmd) return err } var ( dbusConfPath = "/etc/systemd/system/dbus.service.d/k8s-graceful-node-shutdown-e2e.conf" dbusConf     = ` [Unit] RefuseManualStart=no RefuseManualStop=no [Service] KillMode=control-group ExecStop= ` ) func overlayDbusConfig() error { err := os.MkdirAll(filepath.Dir(dbusConf), 0755) if err != nil { return err } err = os.WriteFile(dbusConfPath, []byte(dbusConf), 0644) if err != nil { return err } return systemctlDaemonReload() } func restoreDbusConfig() error { err := os.Remove(dbusConf) if err != nil { return err } return systemctlDaemonReload() } </ins>

Discussion:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node /cc
The failure should be caused by
/assign
/triage accepted /assign