jiebi/CodeConvo huggingface dataset:
Change:
get-kubeconfig-basicauth if [[ ${GCE_UPLOAD_KUBCONFIG_TO_MASTER_METADATA:-} == "true" ]]; then <del> gcloud compute instances add-metadata "${MASTER_NAME}" --zone="${ZONE}"  --metadata-from-file="kubeconfig=${KUBECONFIG}" || true </del> <ins> gcloud compute instances add-metadata "${MASTER_NAME}" --project="${PROJECT}" --zone="${ZONE}"  --metadata-from-file="kubeconfig=${KUBECONFIG}" || true </ins> fi echo

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 --kube-up tries to add metadata to the wrong project. It is trying to add metadata to the prow project running the tests instead of the target project. This is because is missing a kube-up uses the target project to add metadata Don't set/set a different default project and run cluster/kube-up. originally in kubetest hides the project acquired from boskos under the covers by setting it as the default project uncovered as part of migration to kubetest2 xref: /cc
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
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:
service := &remoteImageService{timeout: connectionTimeout} <del> if err := service.determineAPIVersion(conn); err != nil { </del> <ins> if err := service.determineAPIVersion(conn, endpoint); err != nil { </ins> return nil, err }

Discussion:
When installing the latest component, got the error: Then the flag , got error: It is confusing to see these error msgs at the first glance, need to make it more clearly. Add the required field validation, and add more supportive error message. Download the latest v1.25.0 binary, and install it with systemd service or just manually start the binary, will reproduce these errors. <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 node
kubelet 1.24+ is not working with the docker, unless using Are you using it? If not, try switching to other available container runtimes. Please re-open if you have further questions /close
Closing this issue. <detailsIn response to : kubelet 1.24+ is not working with the docker, unless using Are you using it? If not, try switching to other available container runtimes. Please re-open if you have further questions 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
Yes, I got to know the , so need to add runtime validation by the fix PR: PTAL thanks.
Change:
assert.Equal(t, secret1.Name, createdSecret.Name) assert.True(t, secretsEqual(secret1, *createdSecret)) <ins> // Wait for the secret to appear in the informer store err := WaitForStoreUpdate( secretController.secretFederatedInformer.GetTargetStore(), cluster1.Name, getSecretKey(secret1.Namespace, secret1.Name), wait.ForeverTestTimeout) assert.Nil(t, err, "secret should have appeared in the informer store") </ins> // Test update federated secret. secret1.Annotations = map[string]string{ "A": "B",

Discussion:
https://k8s- Failed: TestNamespaceController {namespace} Previous issues for this test:
GetObjectFromChan() is timing out (20s) and returning nil causing the panic. Happens in TestSecretController (and probably TestIngressController) controller as well. https://k8s-
https://k8s- Failed: TestNamespaceController {namespace}
https://k8s- Failed: TestNamespaceController {namespace}
https://k8s- Failed: TestNamespaceController {namespace}
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: TestNamespaceController {namespace}
https://k8s- Failed: TestNamespaceController {namespace}
I have a fix for this in
https://k8s- Failed: TestNamespaceController {namespace}
https://k8s- Failed: TestNamespaceController {namespace}
https://k8s- Failed: TestNamespaceController {namespace}
/cc OWNERS of :
I think this is also related to Issue .
fix is pending
Change:
package job import ( <del> "reflect" </del> "testing" "github.com/google/go-cmp/cmp" "github.com/google/go-cmp/cmp/cmpopts" batchv1 "k8s.io/api/batch/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/apimachinery/pkg/labels" </ins> "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/validation/field" genericapirequest "k8s.io/apiserver/pkg/endpoints/request"

Discussion:
The gets very long testing mulitple functions in such as , and . These checks should be performed in dedicated Test functions using table for different scenarios. Target functions and are being as part of The remaining checks should be migrated to these functions. Also, a test function should be to migrate the remaining tests.
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 apps
/assign
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]:
/remove-lifecycle stale
Any progress on this? I'm working on and I noticed that has relatively low coverage so I was going to work on getting the coverage up.
I created that is somewhat related to this.
no progess. go ahead please
/assign
Change:
} if le.observedTime.Add(le.config.LeaseDuration).After(now.Time) && oldLeaderElectionRecord.HolderIdentity != le.config.Lock.Identity() { <del> glog.Infof("lock is held by %v and has not yet expired", oldLeaderElectionRecord.HolderIdentity) </del> <ins> glog.V(4).Infof("lock is held by %v and has not yet expired", oldLeaderElectionRecord.HolderIdentity) </ins> return false }

Discussion:
What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): "lock is held by" "has not yet expired" Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): tested on 1.3.5 and 1.3.8 (upgraded today) Environment: Hardware: vmware guest OS: CoreOs 1122.2.0 kernel: 4.7.0-coreos masters: 3 /etc/kubernetes/manifests/kube- looks like this: /etc/kubernetes/manifests/kube-controller- looks like this: What happened: The logs from kube-scheduler and kube-controller-manager are spamming with: The node holding the lock only logs this: What you expected to happen: If this is expected behaviour i would like to be able to supress those messages with --v=2 How to reproduce it (as minimally and precisely as possible): I think it would be sufficient to run scheduler or controller-manager with . etcdctl get registry/services/endpoints/kube-system/kube-controller-manager looks like this: The cluster seems healthy and are scheduling pods correctly.
Same issue with 1.4.4
Just hit this with 1.4.6 as well.
To state that the spam is overwhelming would be a vast understatement. It dominates all log entries by a factor of 7. Please do something about this sooner rather than latter.
This is expected behavior, this appears from standby controllers and schedulers. You can tune these parameter on the binaries.. see leader-election params under --help. closing, not an bug
i cannot find any way to supress this exept turning upp the duration and thats not what we want.

I only dont want to fill elasticerarch with those messages. Why dont they have a proper loglevel there? When this which seems like an error has a higher log level?
K, I'll adjust the log levels.
Does the controller-manager start with by default? Did I understand this correctly that you moved it to ? Does this by chance have anything to do with the log for Ingress controllers as well and will be fixed in 1.6 ?
default depends on provider, some folks default to 3. Needless to say -v 4 "should be" outside the normal range to prevent spamming. verbosity on ingress controller is controlled by how that component is started, but I applied it to the base so it should hit *.
Change:
set = obj.(*apps.StatefulSet) } if set.Status.Replicas != 3 { <del> t.Error("Falied to scale statefulset to 3 replicas") </del> <ins> t.Errorf("set.Status.Replicas = %v; want 3", set.Status.Replicas) </ins> } *set.Spec.Replicas = 5 fakeResourceVersion(set)

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Unit test error message match the conventional Go style: For example: if got, want := set.Status.Replicas, 3; got != want { t.Errorf("set.Status.Replicas = %v; want %v", got, want) }
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 testing
/assign
/reopen
Change:
// only return the user provided mode if at least one was valid if len(mode) > 0 { <del> klog.Warningf("the default kube-apiserver authorization-mode is %q; using %q", strings.Join(defaultMode, ","), strings.Join(mode, ","), ) </del> <ins> if !compareAuthzModes(defaultMode, mode) { klog.Warningf("the default kube-apiserver authorization-mode is %q; using %q", strings.Join(defaultMode, ","), strings.Join(mode, ","), ) } </ins> return strings.Join(mode, ",") } } return strings.Join(defaultMode, ",") } <ins> // compareAuthzModes compares two given authz modes and returns false if they do not match func compareAuthzModes(a, b []string) bool { if len(a) != len(b) { return false } for i, m := range a { if m != b[i] { return false } } return true } </ins> func isValidAuthzMode(authzMode string) bool { allModes := []string{ kubeadmconstants.ModeNode,

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: when i installed k8s using kubeadm and my custom config like then output is It is a bug that the default value(Node,RBAC) is entered but a warning message is displayed. A function must be to compare two string slices. What you expected to happen: If the default value and custom value are the same, no warning message should be displayed. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 17.3 Install tools: kubeadm /area kubeadm /feature bug /sig cluster-lifecycle
/lifecycle active
Change:
<ins> # Security Policy ## Supported Versions Information about supported Kubernetes versions can be found on the [Kubernetes version and version skew support policy] page on the Kubernetes website. ## Reporting a Vulnerability Instructions for reporting a vulnerability can be found on the [Kubernetes Security and Disclosure Information] page. [Kubernetes version and version skew support policy]: https://kubernetes.io/docs/setup/release/version-skew-policy/#supported-versions [Kubernetes Security and Disclosure Information]: https://kubernetes.io/docs/reference/issues-security/security/#report-a-vulnerability </ins>

Discussion:
What would you like to be : GitHub has a that uses a file from the repository to show the project's security policy. Why is this needed: Adding this file makes it easier for security researchers to learn about the correct place to report a vulnerability in the Kubernetes project.
/sig docs
/remove-sig docs /sig contributor-experience
Change:
// the labelSelector in the specified namespaces, where co-located is defined as running on a node // whose value of the label with key topologyKey matches that of any node on which any of the // selected pods is running. <del> // For PreferredDuringScheduling pod anti-affinity, empty topologyKey is interpreted as "all topologies" // ("all topologies" here means all the topologyKeys indicated by scheduler command-line argument --failure-domains); // for affinity and for RequiredDuringScheduling pod anti-affinity, empty topologyKey is not allowed. // +optional TopologyKey string `json:"topologyKey,omitempty" protobuf:"bytes,3,opt,name=topologyKey"` </del> <ins> // Empty topologyKey is not allowed. TopologyKey string `json:"topologyKey" protobuf:"bytes,3,opt,name=topologyKey"` </ins> } // Node affinity is a group of node affinity scheduling rules.

Discussion:
The field is marked as optional: The comment also describes a use case for empty topologykey: But the validation rule says it's required:
cc
cc could you take a look? Thank you. The validation rule is by
the release note of should go into the "action-required" section of the , but it's currently in "Other notable changes".
/assign
It seems that we should also update the external api type comments. Right?
I will look into it today.
If you didn't work on this, I am pleasure to send PR to fix this. :)
yeah sure. thanks.
Change:
return "", fmt.Errorf("Failed to create the virtual disk having name: %+q with err: %+v", destVolPath, err) } } <ins> if filepath.Base(datastore) != datastore { // If Datastore is within cluster, add cluster path to the destVolPath destVolPath = strings.Replace(destVolPath, filepath.Base(datastore), datastore, 1) } </ins> glog.V(1).Infof("VM Disk path is %+q", destVolPath) return destVolPath, nil }

Discussion:
With version 1.4.7 I could use a datastore that is in a cluster as a vsphere volume as . When I upgraded to 1.6.0, this same exact path does not work and throws a error. I'm struggling to find what changed, but am guessing it's difference in how the datastore is being looked up in vcenter. Has anyone had luck with this?
We have verified creating pod using static PV and dynamic provisioning, both works fine with Can you post here? cc:
Did that include using a datastore that was in a datastore cluster? That seemed to be working before because the datastore previously (before 1.5) was read out of the global config, which supported datastore path with cluster name. But post 1.5 datastore is parsed from the entry, which if you include the path to the cluster it gets you past the datastore lookup, but then when you go to add the disk it fails because that is not valid to vCenter. It's kind of this weird mixed mode, because to look up the datastore you need the path including the cluster, but to create the file you need the path without the cluster. I presume the PV is working because they use the cloud config values? I was not using a PV but putting a volumePath directly in my deployment yaml. Should I be using a PV to do this? If the deployment is deleted and re-created how do I guarantee that my pod would get the same PV claim? That was why I did not go down that path originally. I'm pretty sure I have narrowed down where in the provider this is happening, but didn't see a good path to get it to work. I have, admittantly, not tried PV/PVCs yet, due to the concern raised above, but could try those to see. The pertinent part of the deployment yaml: The cloud config:
Just confirmed I have the same issue using a PV and PVC....
Here it needs it in format: (which it gets on line 791 by parsing . But here it needs it in true format, without the datastorecluster: Therefore if you do it gets you past line 796 but fails on 802. But if you do then you don't get past line 796.
Thanks for detailed look up. This is the commit which caused this regression. We will work on the fix.

cc:
Ah yes, I see that now. What is the lifecycle of a dynamic disk? Does that disk live on after the PVC is released? After the PV is deleted? It seems like I may just not fully be exercising the power of the volume plugins as well. I would still have the issue with existing volumes as they have data that I need to maintain, but would be interesting for new volumes to look into these more.
RECLAIMPOLICY for PV created using Dynamic Provisioning is Delete PV will get deleted if you delete PVC. Disk also gets deleted from datastore.
Change:
return nil, err } <ins> ss.vmssCache, err = ss.newVMSSCache() if err != nil { return nil, err } </ins> ss.vmssVMCache, err = ss.newVMSSVirtualMachinesCache() if err != nil { return nil, err

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: Recently we upgraded our cluster from 1.14.4 to 1.14.7. Then we started to observe tons of following errors: I guess the cause may be related to this line which was introduced recently: As we have hundreds of services with LoadBalancer type, and we also enable cluster-autoscaler, the nodes list change very often. For each service, there will be one call to GetScaleSet. The quota will be exhausted quickly. When fails, new nodes created by cluster-autoscaler will lose connectivity to load balancer. What you expected to happen: Kubernetes should not hit VMSS throttling threshold. How to reproduce it (as minimally and precisely as possible): a cluster with aks-engine. Use VMSS. 200 services with LoadBalancer type. up VMSS to 50 nodes down VMSS to 60 nodes scaling up and down VMSS Anything else we need to know?: Environment: Kubernetes version (use ): 1.14.7 Cloud provider or hardware configuration: Azure, VMSS OS (e.g: ): Ubuntu Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider /area provider/azure
I create a PR to mitigate the issue.
do we have a rough num about how this PR would mitigate this issue? looks like we need to cherry-pick this PR to old releases. it's better if we have a rough estimation.
The revised version of code calls instead of azure API. The cache refreshes itself every 10 min. I believe this will solve the throttling issue.
I believe we're being affected by this. Apart from getting the - when creating our to use a pre-configured Azure Public IP, the ingress appears to be getting a different IP each time
Thank you all!
The PR is merged. Does your issue remain?

pls cherry-pick that fix to old release, thanks
Cherry picked to release 1.14-1.16
I’ll retry today and let you know Wysłane z iPhone'a
Issue returned in K8S 1.15.4 Warning UpdateLoadBalancerFailed service/nginx-ingress-controller Error updating load balancer with new hosts map[<nodes names]: [EnsureHostInPool(ingress/nginx-ingress-controller): backendPoolID(/subscriptions/<subscription/resourceGroups/<rg/providers/Microsoft.Network/loadBalancers/<rg/backendAddressPools/<rg) - failed to ensure host in pool: "azure - cloud provider rate limited(read) for operation:VMSSGet", EnsureHostInPool(ingress/nginx-ingress-controller):
Change:
VolumeStatsAggPeriod:         unversioned.Duration{Duration: time.Minute}, CertDirectory:                "/var/run/kubernetes", CgroupRoot:                   "", <ins> CloudProvider:                AutoDetectCloudProvider, </ins> ConfigureCBR0:                false, ContainerRuntime:             "docker", RuntimeRequestTimeout:        unversioned.Duration{Duration: 2 * time.Minute},

Discussion:
It appears that the kubelet will detect and use the cloud provider as detected by cadvisor thus overriding the cloud provider passed in at runtime: This will break our private cloud configuration where we do not use our cloud provider's load balancing and instead use our own load balancing tier. In my opinion, the cloud provider specified at kubelet runtime should be respected for the node. Am I reading this correctly? Any thoughts on how to handle this properly? Thank you!
If you specify any cloud provider through flags, it will be used by kubelet (see ). It's only when you don't specify any cloud provider that kubelet will detect the cloud provider from the machine info, as described by the comment.
that's exactly my situation, I want to run in our private cloud environment without any of the cloud integration. If I specify cloud-provider="" at runtime it will get overridden.
Ah I see. I guess specifying an empty string is the same as not specifying any cloud provider. This auto-detection feature was introduced by /cc the author and reviewer to see if this is an intended behavior:
Legitimate concern. I'm posting a fix. Do you consider this to be a regression or are you just getting started with k8s.
I am sorry, This was not the original intention. We can keep the auto detection with a flag, or make a flag to ask kubelet not to do it. Unless there is a way to see if the variable was assigned to that I missed. I can post a fix tomorrow if it won't exit by then.
Thank you. We're running on 1.2.4 and won't be running on 1.3 for a few months yet anyways and was just testing to look for future issues when I found this.
I assigned this issue to you since , and I can't assign this to anyway :-)
Thanks for testing our 1.3 release candidate, and reporting this regression to us. We are including the fix to 1.3.