jiebi/CodeConvo huggingface dataset:
Code change:
return az.ExcludeMasterFromStandardLB != nil && *az.ExcludeMasterFromStandardLB } <ins> func (az *Cloud) disableLoadBalancerOutboundSNAT() bool { if !az.useStandardLoadBalancer() || az.DisableOutboundSNAT == nil { return false } return *az.DisableOutboundSNAT } </ins> // IsNodeUnmanaged returns true if the node is not managed by Azure cloud provider. // Those nodes includes on-prem or VMs from other clouds. They will not be added to load balancer // backends. Azure routes and managed disks are also not supported for them.

Related discussion:
text: <!-- 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: is the recommended way to configure the outbound networks together with Azure standard loadbalancer (SLB). However, for load balancer rules are disabled by default. That means all frontend IPs would be used as the SNAT IPs for virtual machines, according to . This would introduce troubles for various security scenarios, as there's no way to get a stable list of egress IPs. Azure cloud provider should support this scenario, and disable the outbound SNAT when outbound rules are configured by provisioning tools. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others: /kind bug /sig azure /priority critical-urgent
Code change:
}) <ins> ginkgo.It("should perform canary updates and phased rolling updates of template modifications for partiton1 and delete pod-0 without failing container", func(ctx context.Context) { ginkgo.By("Creating a new StatefulSet without failing container") ss := e2estatefulset.NewStatefulSet("ss2", ns, headlessSvcName, 3, nil, nil, labels) deletingPodForRollingUpdatePartitionTest(ctx, f, c, ns, ss) }) ginkgo.It("should perform canary updates and phased rolling updates of template modifications for partiton1 and delete pod-0 with failing container", func(ctx context.Context) { ginkgo.By("Creating a new StatefulSet with failing container") ss := e2estatefulset.NewStatefulSet("ss3", ns, headlessSvcName, 3, nil, nil, labels) ss.Spec.Template.Spec.Containers = append(ss.Spec.Template.Spec.Containers, v1.Container{ Name:    "sleep-exit-with-1", Image:   imageutils.GetE2EImage(imageutils.BusyBox), Command: []string{"sh", "-c"}, Args: []string{` echo "Running in pod $POD_NAME" _term(){ echo "Received SIGTERM signal" if [ "${POD_NAME}" = "ss3-0" ]; then exit 1 else exit 0 fi } trap _term SIGTERM while true; do echo "Running in infinite loop in $POD_NAME" sleep 1 done `, }, Env: []v1.EnvVar{ { Name: "POD_NAME", ValueFrom: &v1.EnvVarSource{ FieldRef: &v1.ObjectFieldSelector{ APIVersion: "v1", FieldPath:  "metadata.name", }, }, }, }, }) deletingPodForRollingUpdatePartitionTest(ctx, f, c, ns, ss) }) </ins> // Do not mark this as Conformance. // The legacy OnDelete strategy only exists for backward compatibility with pre-v1 APIs. ginkgo.It("should implement legacy replacement when the update strategy is OnDelete", func(ctx context.Context) {

Related discussion:
text: Pla suggest : apiVersion: v1 kind: Service metadata: name: nginx labels: app: nginx spec: ports: port: 80 name: web clusterIP: None selector: app: nginx apiVersion: apps/v1 kind: StatefulSet metadata: name: web-am spec: updateStrategy: type: RollingUpdate rollingUpdate: partition: 1 serviceName: "nginx" replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: name: nginx args: /bin/sh -c sleep 30;touch /tmp/healthy; sleep 3600 image: nginx:1.14.2 ports: containerPort: 80 name: web
Code change:
if ss.excludeMasterNodesFromStandardLB() && isMasterNode(node) { continue } <ins> if ss.ShouldNodeExcludedFromLoadBalancer(node) { klog.V(4).Infof("Excluding unmanaged/external-resource-group node %q", node.Name) continue } </ins> // in this scenario the vmSetName is an empty string and the name of vmss should be obtained from the provider IDs of nodes resourceGroupName, vmssName, err := getVmssAndResourceGroupNameByVMProviderID(node.Spec.ProviderID) if err != nil {

Related discussion:
text: What happened: After creating Kubernetes service on a Kubernetes cluster built on Azure IaaS (not AKS), nodes which are not master nodes but are also not worker nodes and which are labeled with are included in the backend pool for the load balancer. What you expected to happen: All nodes labeled with should be excluded from the load balancer's backend pool. How to reproduce it (as minimally and precisely as possible): Create a node with a type other than and label it with Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.10", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-05-20T14:00:52Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.10", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-05-20T13:51:56Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: Azure OS (e.g: ): CentOS Linux release 7.8.2003 (Core) Kernel (e.g. ): Linux master- 3.10.0-1127.8.2.el7.x8664 SMP Tue May 12 16:57:42 UTC 2020 x8664 x8664 x8664 GNU/Linux Install tools: Custom terraform stack Network plugin and version (if this is a network-related bug): Others:
/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. ‍
/priority important-soon /sig cloud-provider /area provider/azure
/priority critical-urgent
Code change:
openapinamer "k8s.io/apiserver/pkg/endpoints/openapi" "k8s.io/apiserver/pkg/registry/rest" genericfilters "k8s.io/apiserver/pkg/server/filters" <ins> "k8s.io/apiserver/pkg/warning" </ins> "k8s.io/client-go/informers" "k8s.io/client-go/kubernetes/fake" restclient "k8s.io/client-go/rest"

Related discussion:
text: I am doing v1.28.3 kube-apiserver testing in the test environment, and I often encounter kube-apiserver panic, especially when kube-apiserver call webhook fails. The following are the captured panic logs: and: kube-apiserver does not panic even if calling webhook times out or fails Deploy a webhook, remove the service corresponding to the webhook, and then create pods in batches to trigger webhook calls No response <details</details<detailsprivate cloud </details<details</details<details</details<details</details<details</details
/sig api-machinery
somewhat related to
The scenarios that trigger panic are similar(the apiserver fails to call webhook), but the log shows that the location of panic is different.
/assign For context of  Thank you. /triage accepted
again, full stack logs:
I'll try to test the mr:
Let me try to explain the panic - both goroutines are trying to write to the of the first goroutine: This request has timed out, and consequently the filter is trying to send a response to the caller. This is the client facing goroutine from the timeout filter. Note that the call to is protected by a mutex, that means that if the other goroutine is using the delegated object via the adapter, then this panic should not happen. second goroutine: let's check the other goroutine, it is also trying to write to the of the object: Now uses an unprotected version of the ResponseWriter object: The filter precedes the filter in the execution order, so the in is not using the thread safe implementation. This is the order today: one quick resolution is to move the after the timeout filter: , but there could be code that precedes that needs to write warning? Also note that the panic mentioned in is not as severe, it does not cause the apiserver to crash. For a more proper solution, i think we would want any thoughts?
Code change:
openapinamer "k8s.io/apiserver/pkg/endpoints/openapi" "k8s.io/apiserver/pkg/registry/rest" genericfilters "k8s.io/apiserver/pkg/server/filters" <ins> "k8s.io/apiserver/pkg/warning" </ins> "k8s.io/client-go/informers" "k8s.io/client-go/kubernetes/fake" restclient "k8s.io/client-go/rest"

Related discussion:
text: /cc
I tend to remove the timeout filter, the sooner the better, and I think the Apiserver panic is the P0-level bug, directly affecting the availability of the cluster I have cherry-picked and tested it in my cluster, and I still need to continue to observe for 1-2 days
I opened a minimal WIP fix for the warning writer in since the timeout filter removal is a much bigger change to reason through
thanks a lot, I will try to test and cherry-pick the above minimal WIP fix in
sorry, I completely overlooked , I only saw and that looked too big to take safely right now I prefer to
Can we backport the fix to 1.28?
Why 1.28 specifically? I'm not aware of anything that changed in 1.28 that made this more or less prevalent. If this meets backport criteria, going to all active branches could make sense (1.27+)
Code change:
} kind = fqParentKind.Kind } <ins> verbOverrider, needOverride := storage.(StorageMetricsOverride) </ins> switch action.Verb { case "GET": // Get a resource. var handler restful.RouteFunction

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: What happened: use kubectl search log with follow option get api latency (apiserverrequestlatenciessummary{quantile="0.99",resource="pods",verb="GET"} )high to give a alert in my cluster. the apiserver log is below and we can see it costs 1m25s. What you expected to happen: do not make this api latency account in getting pod request api latency How to reproduce it (as minimally and precisely as possible): use kubectl to search a pod log with follow option long enough and you will get this metric apiserverrequestlatenciessummary{quantile="0.99",resource="pods",verb="GET"} higher than the ordinary case. Anything else we need to know?: I am happy to fix it. Environment: Kubernetes version (use ): 1.6 Cloud provider or hardware configuration**: bare-metal OS (e.g. from /etc/os-release): ubuntu 16.04 Kernel (e.g. ): 4.4 Install tools: kubeadm Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig API Machinery
/area apiserver
/sig api-machinery
/assign Thanks... looking forward to your PR!
fixed with PTAL
Code change:
want:      []string{ss1Rev1.Name, ss1Rev2.Name, ss1Rev3.Name}, }, { <ins> name:      "with ties", revisions: []*apps.ControllerRevision{ss1Rev3, ss1Rev3Time2, ss1Rev2, ss1Rev1}, want:      []string{ss1Rev1.Name, ss1Rev2.Name, ss1Rev3.Name, ss1Rev3Time2.Name, ss1Rev3Time2Name2.Name}, }, { </ins> name:      "empty", revisions: nil, want:      nil,

Related discussion:
text: <!-- 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: Statefulsets are sometimes continually rolling pods and I don't know why statefulset created: storageclass referenced: kubectl describe statefulset statefulset-test: As you can see from the above describe, the pod in the statefulset has been restarted a lot of times. Observing the created pod, 1) The pod comes up ready 2) immediately transitions to terminating 3) Is terminated 4) A new pod is created 5) Go back to (1) (repeats forever) Despite no updates to the statefulset spec ocurring. Making a change to the statefulset template (for example a trivial change adding a nonsense annotation) stops the rolling and fixes the issue When this statefulset was created, there was a mutating webhook enabled. After the observed pod rolling. I disabled this by making its configuration invalid and making it non required, and the rolling persisted. The status of the statefulset: : You can see that there is a discrepency between currentRevision and updateRevision. currentRevision: statefulset-test- updateRevision: statefulset-test- A short while later the status is changed to contain currentRevision: statefulset-test- updateRevision: statefulset-test- This change happened at Sun Apr 1 19:48:48 2018 Presumably after the rollout of statefulset-test- is complete.
Code change:
want:      []string{ss1Rev1.Name, ss1Rev2.Name, ss1Rev3.Name}, }, { <ins> name:      "with ties", revisions: []*apps.ControllerRevision{ss1Rev3, ss1Rev3Time2, ss1Rev2, ss1Rev1}, want:      []string{ss1Rev1.Name, ss1Rev2.Name, ss1Rev3.Name, ss1Rev3Time2.Name, ss1Rev3Time2Name2.Name}, }, { </ins> name:      "empty", revisions: nil, want:      nil,

Related discussion:
text: Here are all the controllerrevisions from above: kubectl get controllerrevision statefulset-test- -o yaml kubectl get controllerrevision statefulset-test- -o yaml: kubectl get controllerrevision statefulset-test- -o yaml: The differences between the above controllerrevisions are insignificant (the hash, the creation timestamp, the name, the resource version, the uid, the self link) Interestingly all these controllerrevisions were created very close together in time shortly after I created the statefulset The current controllerrevisions are After watching the state change for a while, it actually seems like the statefulset is just cycling through the updateRevision being one of the above 10 controllerrevisions Leaders during this time From kube-controller-manager logs during this time, here is one excerpt: The error sync in there is suspicous, and as you can see the controllerrevisions are changing in the logs I have the full logs from a 5 minute window on either side of the above if necessary. The reason I'm inclined to think this is a kubernetes bug is that any update to the statefulset template fixes the problem. How to reproduce it (as minimally and precisely as possible): Not really sure. Worth just trying to create the above statefulset (requires creating the I tried deleting and recreating the above statefulset and it didn't happen, so something flaky is going on Anything else we need to know?: kubernetes 1.9.3 (client and server) cloud provider: aws
/sig apps
I realize this will probably need some further debugging, happy to get some direction
Consistent repro: Create a statefulset that creates a controllerrevision whose hash is between max int32 and max uint32 (this shouldn't be that hard to do, possibly a 50/50 chance of this). Manually create a controllerrevision identical to the first (same revision), incrementing both the name and hash by one. See that the statefulset controller will continually switch which controller revision should be the target of the statefulset.
Due to the issue fixed here: , under some circumstances controllerrevisions whose revision is the same were being considered equal.
Code change:
want:      []string{ss1Rev1.Name, ss1Rev2.Name, ss1Rev3.Name}, }, { <ins> name:      "with ties", revisions: []*apps.ControllerRevision{ss1Rev3, ss1Rev3Time2, ss1Rev2, ss1Rev1}, want:      []string{ss1Rev1.Name, ss1Rev2.Name, ss1Rev3.Name, ss1Rev3Time2.Name, ss1Rev3Time2Name2.Name}, }, { </ins> name:      "empty", revisions: nil, want:      nil,

Related discussion:
text: This ends up causing this bug to manifest as follows: ListRevisions finds many controllerrevisions with the same revision (unclear how this state happens, but it can happen) The sort here randomly sorts them Due to the linked bug , FindEqualRevisions incorrectly finds that all these controller revisions are equal to the proposed udpate. The updateRevision selects the last revision found here Therefore, updateRevision, is randomly selected and causes the bug. This fixes the immediate issue, but the sort should probably be made stable (i.e not just look at the revision number, perhaps just consider the hash for tie breakers)
As an update, fixing the equality check will not be sufficient because it is possible for multiple controller revisions to be created that are actually equal, including the same hash, that have the same revision number. I believe the fix will need to be equal controllerrevisions with the same revision number from being created sort the controllerrevisions so that the controllerrevision that is the target of the statefulset is stable
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
ping I use the K8S which version is 1.11.4 and encounter the same problem. I want to reproduce the problem and find your way: Manually create a controllerrevision identical to the first (same revision), incrementing both the name and hash by one. Could you tell me how to mannually create a same controllerrevision identical to the first? Thanks in anvance.
Code change:
// Create a deployment to delete nginx pods and instead bring up redis pods. deploymentName := "redis-deployment-2" Logf("Creating deployment %s", deploymentName) <del> _, err = c.Deployments(ns).Create(newDeployment(deploymentName, replicas, deploymentPodLabels, "redis", "redis")) </del> <ins> _, err = c.Deployments(ns).Create(newDeployment(deploymentName, replicas, deploymentPodLabels, "redis", "redis", extensions.RollingUpdateDeploymentStrategyType)) </ins> Expect(err).NotTo(HaveOccurred()) defer func() { deployment, err := c.Deployments(ns).Get(deploymentName)

Related discussion:
text: 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!!
Code change:
if (-not (Test-Path $user_dir)) { # If for some reason Create-NewProfile failed to create the user profile # directory just continue on to the next user. <del> continue </del> <ins> return </ins> } # NOTE: there is a race condition here where someone could try to ssh to

Related discussion:
text: I followed the document to create an e2e cluster However, doesn't work after the cluster is up. I got the following error: /cc
/cc
where are you trying to ssh from? Can you ssh to a Linux instance in GCE? If you run do you see ssh keys there? Do any of them match a public key that you have under ? There could be a delay the very first time you try to ssh; we noted this in , but we could add it to the README too. If you try a second time after a couple minutes does it still fail?
Yeah I can ssh to a linux instance in the same cluster. It still fails after a long. I've removed all my ssh keys from cloud metadata, and recreating a cluster. Let me see how it goes this time.
I still got the same error after recreating the cluster. I can ssh into linux nodes in the same cluster just fine.
Code change:
logger.V(5).Info("Starting attacherDetacher.AttachVolume", "volume", volumeToAttach) err := rc.attacherDetacher.AttachVolume(logger, volumeToAttach.VolumeToAttach, rc.actualStateOfWorld) if err == nil { <del> logger.Info("attacherDetacher.AttachVolume started", "volume", volumeToAttach) </del> <ins> logger.Info("attacherDetacher.AttachVolume started", "volumeName", volumeToAttach.VolumeName, "nodeName", volumeToAttach.NodeName, "scheduledPods", klog.KObjSlice(volumeToAttach.ScheduledPods)) </ins> } if err != nil && !exponentialbackoff.IsExponentialBackoff(err) { // Ignore exponentialbackoff.IsExponentialBackoff errors, they are expected. // Log all other errors. <del> logger.Error(err, "attacherDetacher.AttachVolume failed to start", "volume", volumeToAttach) </del> <ins> logger.Error(err, "attacherDetacher.AttachVolume failed to start", "volumeName", volumeToAttach.VolumeName, "nodeName", volumeToAttach.NodeName, "scheduledPods", klog.KObjSlice(volumeToAttach.ScheduledPods)) </ins> } } }

Related discussion:
text: Keep running but not crashing Have a long volume attach path This corresponds to these lines We are using k0s <details</detailsbare metal <details</details<details</details<details</details<details</details
I turned to use the JSON logger, it is gorgeous no wonder it failed
related
/sig node storage
/cc
VolumeToAttach contains Pod pointers, so yes, I think we should not log the entire struct, and only log important parts to it. /triage accepted /help-wanted
/priority important-longterm /assign
Code change:
true, }, { <del> "mounting-unix-socket", </del> <ins> "mount-unix-socket", </ins> func(base string) error { <del> testSocketFile := filepath.Join(base, "mount_test.sock") _, err := net.Listen("unix", testSocketFile) if err != nil { return fmt.Errorf("Error preparing socket file %s with %v", testSocketFile, err) </del> <ins> socketFile, socketError := createSocketFile(base) if socketError != nil { return fmt.Errorf("Error preparing socket file %s with %v", socketFile, socketError) </ins> } return nil }, <del> "mount_test.sock", </del> <ins> "mt.sock", </ins> false, }, { "mounting-unix-socket-in-middle", func(base string) error { <del> testSocketFile := filepath.Join(base, "mount_test.sock") _, err := net.Listen("unix", testSocketFile) if err != nil { return fmt.Errorf("Error preparing socket file %s with %v", testSocketFile, err) </del> <ins> testSocketFile, socketError := createSocketFile(base) if socketError != nil { return fmt.Errorf("Error preparing socket file %s with %v", testSocketFile, socketError) </ins> } return nil }, <del> "mount_test.sock/bar", </del> <ins> "mt.sock/bar", </ins> true, }, }

Related discussion:
text: Subpath unix socket tests can flake because of long socket path. On Linux the path limit should be 108 chars or less. /sig storage