jiebi/CodeConvo huggingface dataset:
Code change:
NodeAllocatableChange = framework.ClusterEvent{Resource: framework.Node, ActionType: framework.UpdateNodeAllocatable, Label: "NodeAllocatableChange"} // NodeLabelChange is the event when node label is changed. NodeLabelChange = framework.ClusterEvent{Resource: framework.Node, ActionType: framework.UpdateNodeLabel, Label: "NodeLabelChange"} <ins> // NodeAnnotationChange is the event when node annotation is changed. NodeAnnotationChange = framework.ClusterEvent{Resource: framework.Node, ActionType: framework.UpdateNodeAnnotation, Label: "NodeAnnotationChange"} </ins> // NodeTaintChange is the event when node taint is changed. NodeTaintChange = framework.ClusterEvent{Resource: framework.Node, ActionType: framework.UpdateNodeTaint, Label: "NodeTaintChange"} // NodeConditionChange is the event when node condition is changed.

Related discussion:
text: Let me summarize each: Born from from is right. But, that's the problem with preCheck. (Some preCheck depends on some in-tree plugins' logic and it affects badly to other plugins enqueueing ) The preCheck is removed after is completed. After preCheck is removed, will be the correct behavior. So, we can do the optimization that changes node to a specific event. will be fixed in: It's kind of rare case, but I feel we need to have some improvement like Edit: create another issue for this: I'd say (2) and (3) are kind of rare cases. So, the blocker here is (1). (And, (1) is blocked by the removal of preCheck, which is blocked by ) As my conclusion, it's safer to add after (1) is done so that we can make sure the performance won't be affected badly. what do you think?
Instead, can we just keep an event for "node updated", then individual plugins can decide whether a annotations change is worth requeuing or not?
Yes, (1) can be replaced with that idea. But, I'd say changing to a specific is slightly better because the scheduling queue could filter out some Node update events without executing the hint functions.
If rescheduling can be triggered with precise events, that would be great. I haven't revisit since last time, I'll take a look again.
Since we are missing an event for , can we add it? But we also have to modify existing events like so: Because change of such field is also an Update. And in future releases we can get rid of some fine-grained events.
Since we will add hintFuncs for all in-tree plugins, so I think it's ok to add nodeAnnotationsChanged event now, we can filter out unrelated events in hitFuncs. Any other concerns? cc Prefer to keep them as people can register fine-gained events instead a general event.
If by "now" you mean v1.30, then I'm ok with that.
Code change:
// Verify the correct network configuration was passed inputConfig := struct { RuntimeConfig struct { <del> Bandwidth    map[string]interface{}   `json:"bandwidth"` PortMappings []map[string]interface{} `json:"portMappings"` </del> <ins> PortMappings []map[string]interface{}   `json:"portMappings"` Bandwidth    map[string]interface{}     `json:"bandwidth"` IpRanges     [][]map[string]interface{} `json:"ipRanges"` </ins> } `json:"runtimeConfig"` }{} inputBytes, inerr := ioutil.ReadFile(inputFile)

Related discussion:
text: /kind feature The CNI "capability arguments" parameter - currently used to pass port mappings - has a few new capabilities: bandwidth limiting and network address management. The dockershim's networking driver should use them. The network address is just passing the PodCIDR dynamically to the plugin, so it no longer has to retrieve it from the APIServer. Bandwidth limiting is already implemented in Kubenet. It is configured via annotations. There is no upgrade risk in providing these values; non-compliant plugins will simply ignore them. Administrators need to explicitly enable each capability individually in their CNI configuration file. To avoid skew between runtimes, the other runtimes should also be upgraded to pass these. We may also wish to look in to a way to add this more directly to the CRI, so we don't have this skew problem, but that's a different issue.
/sig network
/assign
fyi.
Looks like this was never done for CRI?
cc
Code change:
// CustomResourceDefinitionCondition contains details for the current condition of this pod. type CustomResourceDefinitionCondition struct { <del> // Type is the type of the condition. </del> <ins> // Type is the type of the condition. Types include Established, NamesAccepted and Terminating. </ins> Type CustomResourceDefinitionConditionType // Status is the status of the condition. // Can be True, False, Unknown.

Related discussion:
text: What would you like to be : A comment in that includes the possible values of . I got the possible values from . The should contain the further explanation available in the linked code that explains what each condition type means. Why is this needed: Currently the output of is incomplete: It is important to include the values of because that's the value used to . It is not user-friendly to require users to guess the possible string values for condition or require them to read the code to deduce what the possible values are.
/sig cli
Please let me do it~
oops, I just notice your message. I already submitted a PR for this.
It's ok~
Code change:
return base } <del> // multiply by the appropriate exponential scale switch q.Format { case DecimalExponent, DecimalSI: return base * math.Pow10(exponent) default: // fast path for exponents that can fit in 64 bits if exponent > 0 && exponent < 7 { return base * float64(int64(1)<<(exponent*10)) } return base * math.Pow(2, float64(exponent*10)) } </del> <ins> return base * math.Pow10(exponent) </ins> } // AsInt64 returns a representation of the current value as an int64 if a fast conversion

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 --I found that for with returns a very small value. The value should be almost the same as the one of . My minimal : Result: While the top three lines () are good, the float values in the bottom three lines () might be broken. Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig api-machinery
/assign
/cc /triage accepted
Code change:
// Update implements Manager. func (f *managedFieldsUpdater) Update(liveObj, newObj runtime.Object, managed Managed, manager string) (runtime.Object, Managed, error) { self := "current-operation" <ins> formerSet := managed.Fields()[manager] </ins> object, managed, err := f.fieldManager.Update(liveObj, newObj, managed, self) if err != nil { return object, managed, err

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:
// Update implements Manager. func (f *managedFieldsUpdater) Update(liveObj, newObj runtime.Object, managed Managed, manager string) (runtime.Object, Managed, error) { self := "current-operation" <ins> formerSet := managed.Fields()[manager] </ins> object, managed, err := f.fieldManager.Update(liveObj, newObj, managed, self) if err != nil { return object, managed, err

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:
// Update implements Manager. func (f *managedFieldsUpdater) Update(liveObj, newObj runtime.Object, managed Managed, manager string) (runtime.Object, Managed, error) { self := "current-operation" <ins> formerSet := managed.Fields()[manager] </ins> object, managed, err := f.fieldManager.Update(liveObj, newObj, managed, self) if err != nil { return object, managed, err

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:
"//test/images/nettest:all-srcs", "//test/images/no-snat-test:all-srcs", "//test/images/no-snat-test-proxy:all-srcs", <ins> "//test/images/nonewprivs:all-srcs", </ins> "//test/images/port-forward-tester:all-srcs", "//test/images/porter:all-srcs", "//test/images/resource-consumer:all-srcs",

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 feature This issue is for creating image as multiarch
/assign
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
Code change:
// NodeAddresses is an implementation of Instances.NodeAddresses. func (gce *GCECloud) NodeAddresses(instance string) ([]api.NodeAddress, error) { <del> externalIP, err := gce.metadataAccess(EXTERNAL_IP_METADATA_URL) </del> <ins> externalIP, err := gce.getExternalIP(instance) </ins> if err != nil { <del> return nil, err </del> <ins> return nil, fmt.Errorf("couldn't get external IP for instance %s: %v", instance, err) </ins> } <del> nodeAddresses := []api.NodeAddress{{Type: api.NodeExternalIP, Address: externalIP}} if legacyHostAddress, err := gce.getLegacyHostAddress(instance); err == nil { nodeAddresses = append(nodeAddresses, *legacyHostAddress) } return nodeAddresses, nil </del> <ins> return []api.NodeAddress{ {Type: api.NodeExternalIP, Address: externalIP}, // TODO(mbforbes): Remove NodeLegacyHostIP once v1beta1 is removed. {Type: api.NodeLegacyHostIP, Address: externalIP}, }, nil </ins> } <del> func (gce *GCECloud) getLegacyHostAddress(instance string) (*api.NodeAddress, error) { </del> <ins> func (gce *GCECloud) getExternalIP(instance string) (string, error) { </ins> inst, err := gce.getInstanceByName(instance) if err != nil { <del> return nil, err </del> <ins> return "", err </ins> } ip := net.ParseIP(inst.NetworkInterfaces[0].AccessConfigs[0].NatIP) if ip == nil { <del> return nil, fmt.Errorf("invalid network IP: %s", inst.NetworkInterfaces[0].AccessConfigs[0].NatIP) </del> <ins> return "", fmt.Errorf("invalid network IP: %s", inst.NetworkInterfaces[0].AccessConfigs[0].NatIP) </ins> } <del> return &api.NodeAddress{Type: api.NodeLegacyHostIP, Address: ip.String()}, nil </del> <ins> return ip.String(), nil </ins> } // ExternalID returns the cloud provider ID of the specified instance.

Related discussion:
text: When we populate the addresses of the nodes in we call NodeAddresses, which for the gce provider gets the external IP from the which as expected puts the IP address of the master into the external IP field. The Legacy IP field is still filled in by asking the cloud provider for the instance data, so it contains the public IP of the node. /cc
If we merge this should get fixed, because the external IPs will be calculated on the nodes rather than on the master.
Since we are going to delay adding until I can rebase on top of it seems like it's worth fixing this separately.
This is blocking so assigning to him.
Code change:
func ValidatePersistentVolumeUpdate(newPv, oldPv *api.PersistentVolume) field.ErrorList { allErrs := field.ErrorList{} allErrs = ValidatePersistentVolume(newPv) <ins> // PersistentVolumeSource should be immutable after creation. if !apiequality.Semantic.DeepEqual(newPv.Spec.PersistentVolumeSource, oldPv.Spec.PersistentVolumeSource) { allErrs = append(allErrs, field.Forbidden(field.NewPath("spec", "persistentvolumesource"), "is immutable after creation")) } </ins> newPv.Status = oldPv.Status return allErrs }

Related discussion:
text: /kind bug Right now we do not validate PV updates so admin can update at any time. Kubernetes has no facility to reflect this update - it won't magically re-mount an existing volume to e.g. a different NFS server. IMO the PersistentVolumeSource to be read-only and set to stone once created.
/assign
I think it is a good idea to make the VolumeSource read-only but I am afraid ship has sailed in v1 and existing code/tooling that relies on the ability to modify PVs will break as a result of this change.
- do you have any advice on how we should proceed on fixing this issue?
Code change:
} framework.ExpectNoError(framework.RunRC(controllerRcConfig)) <del> // Make sure endpoints are propagated. // TODO(piosz): replace sleep with endpoints watch. time.Sleep(10 * time.Second) </del> <ins> // Wait for endpoints to propagate for the controller service. framework.ExpectNoError(framework.WaitForServiceEndpointsNum( c, ns, controllerName, 1, startServiceInterval, startServiceTimeout)) </ins> }

Related discussion:
text: https://k8s- Failed: [] [HPA] Horizontal pod autoscaling (scale resource: CPU) [] ReplicationController light Should scale from 1 pod to 2 pods {Kubernetes e2e suite} Previous issues for this test:
Builds: ci-kubernetes-e2e-gce-release-1.5 ci-kubernetes-e2e-gci-gce-release-1.5 ci-kubernetes-e2e-gci-gke-release-1.5 ci-kubernetes-e2e-gci-gke-staging-parallel Failed: [] [HPA] Horizontal pod autoscaling (scale resource: CPU) [] ReplicationController light Should scale from 1 pod to 2 pods {Kubernetes e2e suite}
Builds: ci-kubernetes-e2e-gke-release-1.5 ci-kubernetes-e2e-gke-staging-parallel Failed: [] [HPA] Horizontal pod autoscaling (scale resource: CPU) [] ReplicationController light Should scale from 1 pod to 2 pods {Kubernetes e2e suite}
There is a problem w/contacting controller service. This is already fixed by on master. The fix needs to propagated to the 1.5 branch.
ping looks like this is still occasionally happening, PTAL
Looking at the most recent issues here: it looks like there were a lot of instances where it wasn't this bug -- something else failed (like cluster networking, or connection to the API server), which caused this test to fail. There are a couple where there weren't a bunch of simultaneous failures, and on those I see some failures to collect metrics at all (but hard to tell anything w/o getting the Heapster logs). Finally, I do see a test run (https://k8s-) from 9 days ago where it looks like we are getting metrics from Heapster, just perhaps not the right ones. I'll do a bit more digging. P.S. Is there any way we can get the Heapster logs as part of the saved artifacts from test runs
How does heapster run? Is it possible to get the logs into the artifact directory?Here's the script that dumps the logs:
I've inspected https://k8s- run.
Code change:
} framework.ExpectNoError(framework.RunRC(controllerRcConfig)) <del> // Make sure endpoints are propagated. // TODO(piosz): replace sleep with endpoints watch. time.Sleep(10 * time.Second) </del> <ins> // Wait for endpoints to propagate for the controller service. framework.ExpectNoError(framework.WaitForServiceEndpointsNum( c, ns, controllerName, 1, startServiceInterval, startServiceTimeout)) </ins> }

Related discussion:
text: HPA correctly scales "from 2 to 1" in the previous test case, but there are no HPA logs at all for subsequent test case for "from 1 to 2". Anyway, this problem appeared to happen only once 14 days ago, many bugs have been fixed since then. Most probably the root of the problem was not related to HPA. In my opinion, this should not be a release blocker.
This Issue hasn't been active in 53 days. It will be closed in 36 days (Jun 12, 2017). cc You can add 'keep-open' label to prevent this from happening, or add a comment to keep it open another 90 days
Closing as obsolete.
Code change:
name := name tc := tc t.Run(name, func(t *testing.T) { <del> if name == "this ran but done, time drifted back, F" { println("hello") } </del> cj := cronJob() cj.Spec.ConcurrencyPolicy = tc.concurrencyPolicy cj.Spec.Suspend = &tc.suspend

Related discussion:
text: <!-- Please only use this template for submitting enhancement requests --What would you like to be : Cronjob should include the last time when a job was successfully completed. Why is this needed: Currently, a Cronjob's only includes the last time when a job was scheduled. This makes monitoring cronjobs much more complicated, because instead of simply comparing to the current timestamp, the monitoring system now has to hunt for the last job related to the cronjob and persist the state somewhere.
Reiterating the mentions to trigger a notification: <detailsIn response to : 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'd be interesting in picking this up if the apps team thinks this is a good ticket - it seems like it's fairly beginner friendly.
Hi how is this going on? I could take it over if you don't have the time for this issue. :)
Yes please do! I meant to update that I actually wasn't able to pick this up, but it slipped my mind
/assign
Hi do you have any thoughts on this feature?
/unassign
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
Any updates?
Reiterating the mentions to trigger a notification: <detailsIn response to : Any updates? 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
Trying to understand the usage of lastSuccessfulTime. In a normally working case, lastSuccessfulTime lastScheduledTime =last job completed lastSuccessfulTime < lastScheduledTime =last job completed, but a newer one is running Is that the expectation ?
We wanted to use it in monitoring (e.g. fire an alert if is more than X ago). could also mean that the job has been failing for some time, so I don't know what would you get out of that. I guess you could also use as a proxy for "job has failed at least once"?