jiebi/CodeConvo huggingface dataset:
Code change:
tc.runTest(t) } <ins> func TestReplicaCalcScaleUpCMExternalIgnoresUnreadyPods(t *testing.T) { tc := replicaCalcTestCase{ currentReplicas:  3, expectedReplicas: 2, // Would expect 6 if we didn't ignore unready pods podReadiness:     []v1.ConditionStatus{v1.ConditionFalse, v1.ConditionTrue, v1.ConditionFalse}, metric: &metricInfo{ name:                "qps", levels:              []int64{8600}, targetUtilization:   4400, expectedUtilization: 8600, selector:            &metav1.LabelSelector{MatchLabels: map[string]string{"label": "value"}}, }, } tc.runTest(t) } </ins> func TestReplicaCalcScaleUpCMExternalNoLabels(t *testing.T) { tc := replicaCalcTestCase{ currentReplicas:  1,

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: We are starting to use the HPA (horizontal pod autoscaling) for one of our components. What is special about this particular component is that the warm up period is very long (sometimes even more than 30 minutes). During that time, the pod is in Running state but its containers are in Not Ready state. This pod is of course not able to receive any traffic so the metric we use in the HPA is ignoring those pods that are not Ready. The equation used by HPA to calculate the new number of replicas is as follows Our problem is that the equation used by HPA to calculate the new number of replicas is including in the "current replica count" the pods that are "Not Ready" so the value for "new replica count" is not correct. Since this warm up is so long we end up by having a lot of more instances of our services of what it should be necessary. They eventually get deleted once gradually the metrics start going down but that will take a lot of time and a big waste of resources without mentioning that with a changing traffic this HPA will never stabilize What you expected to happen: I would like to have a flag somewhere where I tell HPA to don't include in the "current replica count" the pods that are in "Not Ready" state How to reproduce it (as minimally and precisely as possible): Have a component that takes a lot of time to start and being able to receive traffic. Then define a metric that will ignore the pods that are Not Ready. Finally create a metric that will scale that component based on the mentioned metric Anything else we need to know?: Environment: Kubernetes version 1.7 Cloud provider or hardware configuration: Azure
/sig autoscaling
Hi - thanks for reaching out about this! It looks like this section of the , handles when pods aren't ready. I think you this behavior in , so I'm interested in your thoughts on whats best here. If we do end up adding a flag for this, I'd be happy to write the code :) Also, purely for my own curiosity, I'm curious what type of pod is taking 30 minutes to become ready. If your traffic pattern varies at a rate faster than 30 minutes, it may be difficult for auto-scaling to be helpful.
can you also share a bit more about your HPA?
Code change:
tc.runTest(t) } <ins> func TestReplicaCalcScaleUpCMExternalIgnoresUnreadyPods(t *testing.T) { tc := replicaCalcTestCase{ currentReplicas:  3, expectedReplicas: 2, // Would expect 6 if we didn't ignore unready pods podReadiness:     []v1.ConditionStatus{v1.ConditionFalse, v1.ConditionTrue, v1.ConditionFalse}, metric: &metricInfo{ name:                "qps", levels:              []int64{8600}, targetUtilization:   4400, expectedUtilization: 8600, selector:            &metav1.LabelSelector{MatchLabels: map[string]string{"label": "value"}}, }, } tc.runTest(t) } </ins> func TestReplicaCalcScaleUpCMExternalNoLabels(t *testing.T) { tc := replicaCalcTestCase{ currentReplicas:  1,

Related discussion:
text: What kind of metric type is it? Based on the description I'm suspecting that it is an Object metric, am I right?
So answer about why our process takes that much time to start. Basically this is a server that in order to do what he needs to do, he needs to load a lot of data in memory (several GBs) and then perform some warm up that are pretty intensive. The idea is that he doesn't need to grab (almost) anything from outside to attend a request so it's latency is extremely low (in the order of millisecond) By the way. Because of this we have another problem which is that there is not an specific flag per HPA object that we could tell k8s to don't try to scale up again passed some time so the new pods have enough time to get ready before the next scale happens. I know that there is a cluster wide flag but we will need to have a different one by resource that we scale. Now to answer You pointed another interesting topic. The metric we use is % Utilization. We are able to calculate the level of utilization of our pods and we want to keep this metric in an specific value. About the flag. I suggested the flag so it doesn't change the existing behavior by default but I honestly think that the default behavior should be to don't include the NonReady pods as part of the calculation
do you think we can add this change to 1.10? it's critical bug/feature for us and we are happy to help with code/testing.
It's really late for 1.10, especially since we don't have any code here, and I'd like to know more about what's going on here, and especially see if it reproduces on Kubernetes 1.9 (we've had HPA controller bugs in the past). FWIW, currently unready pods are treated as consuming 0% of their utilization on scale up, and it was intended that this should prevent such issues. That is, the formula is actually: If the pods are marked as not ready, I find it strange that they would be affecting the scaling that much, unless your other pods are under real heavy load (i.e. I would assume that the unready pods would skew the scaling back down so that the number of pods just stayed constant).
I believe there is different code branch here.
Code change:
tc.runTest(t) } <ins> func TestReplicaCalcScaleUpCMExternalIgnoresUnreadyPods(t *testing.T) { tc := replicaCalcTestCase{ currentReplicas:  3, expectedReplicas: 2, // Would expect 6 if we didn't ignore unready pods podReadiness:     []v1.ConditionStatus{v1.ConditionFalse, v1.ConditionTrue, v1.ConditionFalse}, metric: &metricInfo{ name:                "qps", levels:              []int64{8600}, targetUtilization:   4400, expectedUtilization: 8600, selector:            &metav1.LabelSelector{MatchLabels: map[string]string{"label": "value"}}, }, } tc.runTest(t) } </ins> func TestReplicaCalcScaleUpCMExternalNoLabels(t *testing.T) { tc := replicaCalcTestCase{ currentReplicas:  1,

Related discussion:
text: metric definition { "type": "Object", "object": { "target": { "kind": "Service", "name": "prometheus-exporter" }, "metricName": "PercentUtilization", "targetValue": "20" } } which should handle as and doesn't check Pod state.
I think proper handling of unready pods is a difficult problem that will require significant work. I suspect we may find out we need to start distinguishing pods that are booting up from pods that are 'broken' and it took us quite a while to solve analogous problem with nodes in Cluster Autoscaler (to be clear: I don't know if we will have to do that, that's just my intuition for now). That being said I agree the formula in GetObjectMetricReplicas will generally lead to scaling-up too much if the pod takes longer to initialize then backoff period in HPA (3 minutes). Assume it takes pod 4 minutes to boot up and we're currently running 2 pods. Metric value is 20 and target is 10. In this case: scales-up to 4 pods (20/10 utilization 2 pods). are starting up, they're not doing anything yet. 3 minutes later HPA scales-up to 8 pods (20/10 utilization 4 pods). If we only counted ready pods the scale-up in 3 would not occur, because the desired replicas would still be 4 (20/10 * 2). My intuition would be that this is the expected behavior of HPA. Also if there is no space in the cluster we will just keep scaling-up until we hit max replicas. The only case where current behavior would be more correct than filtering out unready pods in this formula is if someone uses a metric that is calculated based on total number of replicas. Do we advertise that as the right way to use HPA? If we add to Object metrics in 1.11 this usage pattern will stop making sense. To sum up - I think we will need to change the formula to only count ready pods at some point. I can see how current behavior could be a problem in any use-case except the one described in paragraph above. I'm inclined to agree with and provide some way to change the behavior in 1.10 (a flag or an annotation?), treating it as a bug fix.
Code change:
tc.runTest(t) } <ins> func TestReplicaCalcScaleUpCMExternalIgnoresUnreadyPods(t *testing.T) { tc := replicaCalcTestCase{ currentReplicas:  3, expectedReplicas: 2, // Would expect 6 if we didn't ignore unready pods podReadiness:     []v1.ConditionStatus{v1.ConditionFalse, v1.ConditionTrue, v1.ConditionFalse}, metric: &metricInfo{ name:                "qps", levels:              []int64{8600}, targetUtilization:   4400, expectedUtilization: 8600, selector:            &metav1.LabelSelector{MatchLabels: map[string]string{"label": "value"}}, }, } tc.runTest(t) } </ins> func TestReplicaCalcScaleUpCMExternalNoLabels(t *testing.T) { tc := replicaCalcTestCase{ currentReplicas:  1,

Related discussion:
text: WDYT
Ah, yeah, I missed that it was object metrics before. I'm not entirely convinced we need a flag here -- it might just make sense to bring Object metrics in line with all the other metrics types. On the other hand, there's a subtlety here -- the other metric types don't quite ignore unready pods -- they just ignore the metrics from unready pods, which causes a heavy bias in the direction of not scaling, but an overwhelming spike can still cause scaling. That behavior is not as achievable using object metrics. I'm inclined to just ignore that subtlety, though, and say that object metrics should ignore unready pods entirely.
I think this is what we should do long term. I was worried about breaking someone who relies on targetValue + averaged metric to get effect similar to targetAverageValue and though about providing something for transitional period, but if you're ok with it I'd rather just change it as you say.
I think it's safe to change as-is -- that feature's still in beta, and it's not an API change, so it shouldn't just hard-break anyone. Plus, we've change stuff like this before (when we did the initial resource metrics change).
As said, we are more than ready to help with the fix/test if required. This since this is a major blocking for us in the implementation of the HPA in our side
is anyone actively working on implementing this? If not, I'm happy to. I think I have a fairly clear picture of the change we need to make and will likely have time early this week to get it done.
(Also, from the conversation above, to we want to tag this as a release blocker for 1.10)?
I probably won't be able to work on this before the end of this week. Happy to do a review if you jump in and implement it.
I don't think this qualifies as a release blocking bug (but I'm willing to have someone try and convince me otherwise ;-)). There doesn't seem to be any behavior here that's explicitly broken -- it's just sub-optimal in some use cases. I'd definitely like to address this in 1.11, though.
it's not release blocker, but to share our experience ;).
Code change:
tc.runTest(t) } <ins> func TestReplicaCalcScaleUpCMExternalIgnoresUnreadyPods(t *testing.T) { tc := replicaCalcTestCase{ currentReplicas:  3, expectedReplicas: 2, // Would expect 6 if we didn't ignore unready pods podReadiness:     []v1.ConditionStatus{v1.ConditionFalse, v1.ConditionTrue, v1.ConditionFalse}, metric: &metricInfo{ name:                "qps", levels:              []int64{8600}, targetUtilization:   4400, expectedUtilization: 8600, selector:            &metav1.LabelSelector{MatchLabels: map[string]string{"label": "value"}}, }, } tc.runTest(t) } </ins> func TestReplicaCalcScaleUpCMExternalNoLabels(t *testing.T) { tc := replicaCalcTestCase{ currentReplicas:  1,

Related discussion:
text: without this feature we cannot use HPA as is and we need to figure out how to build/run fork (which can be challenging because everything inside controller-manager). also we are planning to upgrade to 1.10 quickly, but not sure for 1.11 (e.g. we are two versions behind now).
Sounds like a plan :) Will try and get this done tomorrow morning!
- I submitted a pr for this - would love your eyes on it so you can see if you think it meets your use case :)
/assign
GitHub didn't allow me to assign the following users: mattjmcnaughton. Note that only and repo collaborators can be assigned. <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
I checked the code and it seems good to me. About the comment about scaling down if the readyPods<CurrentPods, we should be fine since our metric is already not including the pods that are not ready.
Is there any advance in this ticket? I'm wondering if this made it to k8s 1.10 or if we need to wait for k8s 1.11?
The PR is lgtm-ed and it will merge once the code freeze is lifted. Meaning it will go to 1.11. To get it into 1.10 you would need to get approval for milestone from (sig-autoscaling lead).
Code change:
var totalMillicores int BeforeEach(func() { <ins> framework.SkipUnlessProviderIs("gce") </ins> ns = f.Namespace.Name nodes := framework.GetReadySchedulableNodesOrDie(f.Client) nodeCount := len(nodes.Items)

Related discussion:
text: https://k8s- Failed: [] Rescheduler [Serial] should ensure that critical pod is scheduled in case there is no resources available {Kubernetes e2e suite}
https://k8s- Failed: [] Rescheduler [Serial] should ensure that critical pod is scheduled in case there is no resources available {Kubernetes e2e suite}
Since it's merge 12 hours ago this test has flaked twice.
https://k8s- Failed: [] Rescheduler [Serial] should ensure that critical pod is scheduled in case there is no resources available {Kubernetes e2e suite}
Code change:
if vs, ok := managed.Fields()[self]; ok { delete(managed.Fields(), self) <del> managed.Times()[manager] = &metav1.Time{Time: time.Now().UTC()} </del> if previous, ok := managed.Fields()[manager]; ok { managed.Fields()[manager] = fieldpath.NewVersionedSet(vs.Set().Union(previous.Set()), vs.APIVersion(), vs.Applied()) } else { managed.Fields()[manager] = vs } <ins> // Update the time only if the manager's fieldSet has changed. if formerSet == nil || !managed.Fields()[manager].Set().Equals(formerSet.Set()) { managed.Times()[manager] = &metav1.Time{Time: time.Now().UTC()} } </ins> } return object, managed, nil

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: I'm trying to automate the usage of to check for changes that need to be applied to the cluster based on a static set of manifests. However, for some manifests, if I run the output contains differences on fields called and , after the manifest was applied to the cluster. I ran . After that, I ran The following output was produced (I copied just the first diff, as many more followed): What you expected to happen: No differences should be detected. How to reproduce it (as minimally and precisely as possible): Run Then run Anything else we need to know?: This does not happen to all manifests. If I try with the manifest no differences are detected. I also tried with manifests loaded from disk, and was able to reproduce the behavior with the following manifest: With the above manifest the following occurs: Empirically, the differences observed always seem to be some seconds apart between the two versions. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: baremetalOS (e.g: ):Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig CLI
Ref: The newest version of has a different result still has a problem when diffing :
Sorry, I was unaware that there was a specific repository on which to report kubectl related issues. If needed, I can recreate this issue on the kubernetes/kubectl repository. Do let me know if this is preferred.
/assign
Hey, thanks for the report About the first issue, applying "". It looks like this yaml is dynamically generated and different every time you get it: So I think this one is totally working as intended. We're showing a difference because there is an actual difference. The second one is actually a bug that we are supposed to have fixed in 1.18. Let me look at it.
Ah, I see. That does account for the differences in the date field. Most unfortunate for me, but definitely not a bug in kubernetes/kubelet. My apologies, I should have checked that first.
Code change:
if vs, ok := managed.Fields()[self]; ok { delete(managed.Fields(), self) <del> managed.Times()[manager] = &metav1.Time{Time: time.Now().UTC()} </del> if previous, ok := managed.Fields()[manager]; ok { managed.Fields()[manager] = fieldpath.NewVersionedSet(vs.Set().Union(previous.Set()), vs.APIVersion(), vs.Applied()) } else { managed.Fields()[manager] = vs } <ins> // Update the time only if the manager's fieldSet has changed. if formerSet == nil || !managed.Fields()[manager].Set().Equals(formerSet.Set()) { managed.Times()[manager] = &metav1.Time{Time: time.Now().UTC()} } </ins> } return object, managed, nil

Related discussion:
text: So the only actual issue is with the changing time field. Thanks for looking into that. Do let me know if there is anything I can do to help.
Can you show me the object before you run that diff? I'm curious what the first "fieldManager" is and why it's different from "kubectl-client-side-apply". Also, did you create the object using ?
I figured out what the problem is in that second message: the cpu goes from an to a : Note that I'm using a non-server-side capable apiserver version, but I think the problem is the same: we can't detect that this object has been changed because cpu goes from to , or from to and we consider this as a change. I have no clue how to solve that "bug".
Hi The test you made is comparing the local yaml against the version the apiserver currently has, correct? That would be similar to running the diff with the option to run server side, which I think yields a suspiciously similar result: I also suspect that it is for this reason that if I run the apply command with the dry-run flag, we always get incoming changes to apply: For comparison sake, the same test with the server-metrics manifest, that does not produce any diff changes, does not detect any incoming changes (notice all of the items are marked with unchanged): I also have no idea how to fix this properly, but perhaps running a yaml formatter on both sources (left and right) before comparison could produce better results? A canonical representation of both inputs might be better suited for comparison. Perhaps such a behavior could be controlled with a new enabling CLI flag. Again, thanks for looking into this. Having a more reliable diff behavior would go a long way for us to detect configuration mismatches against our configuration management system.
Sure thing! I spawned from this bug report to cover the "failed to create typed patch object" problem. I will try to test with the newly minted 1.19 release later today, to see if any previously observed behavior changes.
I recreated the cluster as version 1.19.0, and here are the results of the previous tests: Ran as expected Ran as expected Ran showing unexpected diff results
Thanks for all the details that's actually really useful for me to understand what's going on.
Some more context.
Code change:
if vs, ok := managed.Fields()[self]; ok { delete(managed.Fields(), self) <del> managed.Times()[manager] = &metav1.Time{Time: time.Now().UTC()} </del> if previous, ok := managed.Fields()[manager]; ok { managed.Fields()[manager] = fieldpath.NewVersionedSet(vs.Set().Union(previous.Set()), vs.APIVersion(), vs.Applied()) } else { managed.Fields()[manager] = vs } <ins> // Update the time only if the manager's fieldSet has changed. if formerSet == nil || !managed.Fields()[manager].Set().Equals(formerSet.Set()) { managed.Times()[manager] = &metav1.Time{Time: time.Now().UTC()} } </ins> } return object, managed, nil

Related discussion:
text: A Gatekeeper user reported behavior where always shows a diff in the timestamp for of its CRD objects -- it looks like non-CRDs are unaffected. This happens when re-applying the static manifest found at
Thanks, this is useful, we'll look into it!
Code change:
"k8s.io/client-go/kubernetes/fake" core "k8s.io/client-go/testing" "k8s.io/client-go/tools/clientcmd" <del> bootstrapapi "k8s.io/cluster-bootstrap/token/api" </del> kubeadmapiv1beta1 "k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta1" )

Related discussion:
text: Just got this while running the tests:
let's please move this to /close /sig cluster-lifecycle
Code change:
return subnet, exists, err } <ins> func (az *Cloud) getAzureLoadBalancer(name string) (lb network.LoadBalancer, exists bool, err error) { var realErr error lb, err = az.LoadBalancerClient.Get(az.ResourceGroup, name, "") exists, realErr = checkResourceExistsFromError(err) if realErr != nil { return lb, false, realErr } if !exists { return lb, false, nil } return lb, exists, err } </ins>

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?: What happened: Internal Load Balancer created and associated with availability set but no target network ip configurations on Azure. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Create Kubernetes service of type LoadBalancer, annotate with "". Anything else we need to know?: Refer Environment: Kubernetes version (use ): 1.9.1 Cloud provider or hardware configuration: azure OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig azure
/assign
/kind bug
Root cause: removes the logic for retrieve private ip. This is required however The controller-manager will crash every time new ilb was created, then will restart and get the IP then. Should get the ip in first round.