jiebi/CodeConvo huggingface dataset:
Change:
package main import ( <ins> "bufio" </ins> "flag" "fmt" "go/ast"

Discussion:
/assign /cc /sig instrumentation
GitHub didn't allow me to assign the following users: serathius. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign /cc /sig instrumentation 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
Hey Looks like this test is passing on testgrid, https://k8s- Which would point to problem being related to specific environment. From your log looks like problem is specific to Macs. I will try to reproduce it to confirm it. My current ideas for solution are: Disabling test on Mac Instead of passing files as arguments, pass them in STDIN WDYT?
FWIW ARG_MAX can technically vary even on linux ...? STDIN SGTM
Change:
glog.Infof("Done creating replication controllers") // Give the controllers some time to actually create the pods <del> if err := wait.Poll(time.Second, time.Second*10, c.ControllerHasDesiredReplicas(controllerRequest)); err != nil { </del> <ins> if err := wait.Poll(time.Second, time.Second*30, c.ControllerHasDesiredReplicas(controllerRequest)); err != nil { </ins> glog.Fatalf("FAILED: pods never created %v", err) }

Discussion:
https://travis- Setting as P0 since scheduling pods is pretty basic...
Looks like it's the "podBackoff" thing. IMO exponential backoff makes little sense for this; there's either pods that permanently won't schedule, or there's pods having some temporary problem. The former we should give up on and the latter we should retry at some fixed interval.
Actually it's not that because there's no error messages. Hm...
I think fixed this for the moment. But looking at the Travis logs the problem isn't slowness, it's a race-- the pods show up immediately after the 10 second timeout. Probably something is caching something and not updating for 10 seconds.
Actually, not fixed yet: https://travis-
Just extending timeouts isn't sufficient to fix this, or should have worked.
Could this be the problem "fixed" by
I'm betting it was actually fixed by: That's definitely a race/flake inducing bug. (but I'm not 100% positive) --brendan , bgrant0607 wrote:
Closing this as I think we found the cause, and we haven't seen it in a while.
Change:
--network "${NETWORK}"  $2  --can-ip-forward  <del> --metadata-from-file "$3" "$4"; then </del> <ins> --metadata-from-file "$3","$4"; then </ins> if (( attempt > 5 )); then echo -e "${color_red}Failed to create instance template $1 ${color_norm}" >&2 exit 2

Discussion:
WARNING: Lists should be separated by commas, try "--metadata-from-file=kube-env=/tmp/kubernetes.sCQI6j/master-kube-,startup-". If you intend to use startup- for positional arguments, put them before the flag.
Change:
Burst:       100, ContentType: "application/vnd.kubernetes.protobuf", }, <del> PercentageOfNodesToScore: 50, BindTimeoutSeconds:       &defaultBindTimeoutSeconds, </del> <ins> BindTimeoutSeconds: &defaultBindTimeoutSeconds, </ins> }, }, {

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Kubernetes scheduler has that specifies what percentage of the cluster nodes should be scored in each scheduling cycle. The scheduler stops scanning more nodes once that many nodes are found feasible for running the pod under consideration. The default value of this config option is 50 (for 50%). We should let the scheduler determine this value based on the size of the cluster when this config option is not provided. I'd propose this formula for finding the percentage: . This is a linear formula that gives us 50 when the cluster size is 100 nodes and 10 for a 5000 node cluster. The scheduler already has a lower bound of 50 nodes per scheduling cycle. As a part of this change, we should also add a 5% lower bound for the formula (If the result of the formula is below 5, we should return 5). Why is this needed: To improve scheduler performance in large clusters. <!-- DO NOT EDIT BELOW THIS LINE --/kind feature /sig scheduling
/assign /remove-help
/assign wgliang
Thanks
Change:
} tcases := []struct { <del> name          string newK8sVersion string dryRun        bool flags         applyPlanFlags expectedErr   string </del> <ins> name               string newK8sVersion      string dryRun             bool flags              applyPlanFlags expectedErr        string expectedErrNonRoot string </ins> }{ { name: "Fail pre-flight check", flags: applyPlanFlags{ kubeConfigPath: fullPath, }, <del> expectedErr: "ERROR CoreDNSUnsupportedPlugins", </del> <ins> expectedErr:        "ERROR CoreDNSUnsupportedPlugins", expectedErrNonRoot: "user is not running as", // user is not running as (root || administrator) </ins> }, { name: "Bogus preflight check specify all with individual check",

Discussion:
unit tests should run without root. This test should be refactored or otherwise removed from . should pass as an ordinary user. run tests as non-root
/sig cluster-lifecycle /area kubeadm
thanks for logging the issue. this was changed in so this root preflight test must be excluded.
/triage accepted link
Change:
IFS=" " read -ra KUBE_TEST_SERVER_TARGETS <<< "$(kube::golang::server_test_targets)" readonly KUBE_TEST_SERVER_TARGETS readonly KUBE_TEST_SERVER_BINARIES=("${KUBE_TEST_SERVER_TARGETS[@]##*/}") <del> readonly KUBE_TEST_SERVER_PLATFORMS=("${KUBE_SERVER_PLATFORMS[@]}") </del> <ins> readonly KUBE_TEST_SERVER_PLATFORMS=("${KUBE_SERVER_PLATFORMS[@]:+"${KUBE_SERVER_PLATFORMS[@]}"}") </ins> # Gigabytes necessary for parallel platform builds. # As of January 2018, RAM usage is exceeding 30G

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: Make release of v1.14.2 failed. After facing the error () we did 4 : eaafa5952f8073f51b13dbeafe406019995c8c0ba commit in 's opening PR () Then the build process failed again: What we did was: we ran two commands called , after that, we did . And right after this command, the error happened. Environment: Kubernetes version (use ): v1.14.2 OS (e.g: ): ubuntu 16.04, bash version 4.3
/sig release
Change:
# Apply the configuration in manifest.yaml and delete all the other configmaps that are not in the file. kubectl apply --prune -f manifest.yaml --all --prune-whitelist=core/v1/ConfigMap`)) <del> warningNoLastAppliedConfigAnnotation = "Warning: %[1]s apply should be used on resource created by either %[1]s create --save-config or %[1]s applyn" </del> <ins> warningNoLastAppliedConfigAnnotation = "Warning: resource %[1]s is missing the %[2]s annotation which is required by %[3]s apply. %[3]s apply should only be used on resources created declaratively by either %[3]s create --save-config or %[3]s apply. The missing annotation will be patched automatically.n" </ins> ) // NewApplyOptions creates new ApplyOptions for the `apply` command

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : show a clearer message that better informs the user of a potential conflict between changes done declaratively vs imperatively on the same object, inform whether the changes have been applied, what may have been overwritten based on closed issue resource that has been directly modified imperatively (for example via a kubectl edit command) try to update it again declaratively (for example by kubectl apply -f yamlfile) The following confusing info message appears: "Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply... " Why is this needed: the error message is confusing. is it really an error message or just an informative message? Did the command successfully execute the changes being asked? Were the changes applied successfully? Was there anything overwritten? If changes were successfully applied, what is the reason for this message to show?
/sig cli
background references: and
/assign
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
Agree that this is a confusing message. Could probably use some love. First-round search indexing brought me here.
Change:
Subsystem:         KubeletSubsystem, Name:              ConfigErrorKey, Help:              "This metric is true (1) if the node is experiencing a configuration-related error, false (0) otherwise.", <del> DeprecatedVersion: "1.23.0", </del> <ins> DeprecatedVersion: "1.22.0", </ins> StabilityLevel:    metrics.ALPHA, }, )

Discussion:
This shipped in 1.22 as deprecated in 1.22. As a hacky fix to unbreak tests on 1.23 dev, I bumped the deprecation policy one release: We will need to revert that before 1.23 ships and figure out a better solution. /kind cleanup /milestone v1.23 /sig node
/triage accepted
I want to try it. Can I take this issue?
I have explained how to fix this on PR:
/reopen reverted in as fix did not work
Reopened this issue. <detailsIn response to : /reopen 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
/cc
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
Hi, Im the bug triage shadow. Since we're in 1.23 milestone code freeze, could we move this issue to milestone 1.24?
this is critical for 1.23 and I think it just got forgotten... we need to get this fixed before test freeze
/priority important-soon
Change:
// PodMetrics sets resource usage metrics of a pod. message PodMetrics { <ins> // Standard object's metadata. // More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata // +optional </ins> optional k8s.io.apimachinery.pkg.apis.meta.v1.ObjectMeta metadata = 1; // The following fields define time interval from which metrics were

Discussion:
no explanation for metadata filed of NodeMetrics/PodMetrics, code: should be like $ kubectl explain NodeMetrics KIND: NodeMetrics VERSION: DESCRIPTION: NodeMetrics sets resource usage metrics of a node. FIELDS: apiVersion <stringAPIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: kind <stringKind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: metadata <Objecttimestamp <string-required- The following fields define time interval from which metrics were collected from the interval [Timestamp-Window, Timestamp]. usage <map[string]string-required- The memory usage is the memory working set. window <string-required- and $ kubectl explain PodMetrics KIND: PodMetrics VERSION: DESCRIPTION: PodMetrics sets resource usage metrics of a pod. FIELDS: apiVersion <stringAPIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: containers <[]Object-required- Metrics for all containers are collected within the same time window. kind <stringKind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: metadata <Objecttimestamp <string-required- The following fields define time interval from which metrics were collected from the interval [Timestamp-Window, Timestamp]. window <string-required- able to see the explanation for metadata filed of NodeMetrics/PodMetrics Kubernetes Version: v1.22.0-rc.0+
/sig instrumentation
/kind documentation /assign /triage accepted
Change:
} } <del> func createFakePluginDir() (string, error) { </del> <ins> func createFakePluginDirs() (string, error) { </ins> dir, err := ioutil.TempDir("", "refcounter") if err != nil { return "", 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: Deletion of a Pod with an ISCSI volume in mode results in an error during , leaving an ISCSI target logged into on the kubelet node despite the target being unused. In my case, the ISCSI Target server enforces a single session per LUN, which blocks the Pod from starting on another Node in the cluster. What you expected to happen: For the kubelet to issue a logout request for the given target once the refcounter hits zero. How to reproduce it (as minimally and precisely as possible): Have an ISCSI Target server Create a target/LUN that contains an ext4 filesystem. Have a Node configured as an ISCSI Initiator capable of logging into the those targets. Create a Pod on the Node that includes an volume referring the LUN, using (rather than ) mode. minimally: Delete the Pod Wait for the Pod to be destroyed and the related ISCSI block device to be removed. on the Node will show the target is still logged in Kubelet error: Anything else we need to know?: Environment: Kubernetes version (use ): 1.16.2 Cloud provider or hardware configuration: Reproducible on a bare metal (Intel NUC) lab and DigitalOcean DOKS. OS (e.g: ): Ubuntu 18.04 Kernel (e.g. ): 4.15 (NUC) / 4.19 (DigitalOcean) Install tools: Ubuntu package /sig storage
Change:
docs/man/man1/kubectl-delete.1 docs/man/man1/kubectl-describe.1 docs/man/man1/kubectl-drain.1 <del> docs/man/man1/kubectl-edit-configmap.1 </del> docs/man/man1/kubectl-edit.1 docs/man/man1/kubectl-exec.1 docs/man/man1/kubectl-explain.1

Discussion:
kubectl edit is not working on HEAD. It's working on 1.5.
Change:
expectedConditions: statusOkWithOverrides(autoscalingv2.HorizontalPodAutoscalerCondition{ Type:   autoscalingv2.ScalingLimited, Status: v1.ConditionTrue, <del> Reason: "ScaleUpLimit", }, autoscalingv2.HorizontalPodAutoscalerCondition{ Type:   autoscalingv2.ScalingLimited, Status: v1.ConditionTrue, </del> Reason: "TooManyReplicas", }), }

Discussion:
We recently had 2 serious bugs caused by non-trivial logic calculating desiredReplicas in hpa reconcileAutoscaler method (, ). I think we should extract this part of logic (starting around ) to a separate function and make sure it's covered with unittests for different possible edge condition. The logic itself takes a few ints as input (calculated desiredReplicas, min/max replicas, currentReplicas, ...) to produce a single integer value and set some status conditions, making it very easily unittestable if we extract it to a separate function. WDYT
+100. It would be super unfortunate if we had yet another issue in this area of the code.
agreed. you've been going over these pieces of code recently, you want to tackle this?
Yes, I'd love to! Thanks for the ping. I'll tackle this this weekend :)
Change:
Status: api.NamespaceStatus{ Phase: api.NamespaceTerminating, }, <ins> }, false}, // Can update phase via status update {api.Namespace{ ObjectMeta: api.ObjectMeta{ Name:              "foo", DeletionTimestamp: &now}}, api.Namespace{ ObjectMeta: api.ObjectMeta{ Name:              "foo", DeletionTimestamp: &now}, Status: api.NamespaceStatus{ Phase: api.NamespaceTerminating, }, </ins> }, true}, {api.Namespace{ ObjectMeta: api.ObjectMeta{

Discussion:
Honestly I'm not sure if this is a bug or a feature, but didn't expect it. Filing this to track.
I think it's a bug. Nothing in the code base depends on it that I can see (edit: namespace deletion does, but only via an in-server call which I'd like to see fixed), and we don't let other delete-related fields mutate during update (deleteGracePeriodSeconds)
Change:
// uses the name from the file, not the response expectRC := "replicationcontroller/" + nameRC + "n" <del> expectWarning := fmt.Sprintf(warningNoLastAppliedConfigAnnotation, "kubectl") </del> <ins> expectWarning := fmt.Sprintf(warningNoLastAppliedConfigAnnotation, "replicationcontrollers/test-rc", corev1.LastAppliedConfigAnnotation, "kubectl") </ins> if errBuf.String() != expectWarning { t.Fatalf("unexpected non-warning: %snexpected: %s", errBuf.String(), expectWarning) }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : show a clearer message that better informs the user of a potential conflict between changes done declaratively vs imperatively on the same object, inform whether the changes have been applied, what may have been overwritten based on closed issue resource that has been directly modified imperatively (for example via a kubectl edit command) try to update it again declaratively (for example by kubectl apply -f yamlfile) The following confusing info message appears: "Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply... " Why is this needed: the error message is confusing. is it really an error message or just an informative message? Did the command successfully execute the changes being asked? Were the changes applied successfully? Was there anything overwritten? If changes were successfully applied, what is the reason for this message to show?
/sig cli
background references: and
/assign
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
Agree that this is a confusing message. Could probably use some love. First-round search indexing brought me here.
Change:
t.Errorf("Failed to scale statefulset to %v replicas, got %v replicas", desiredReplicas, set.Status.Replicas) } <del> if (diff < -1 || diff > 1) && om.createPodTracker.maxParallel <= 1 { t.Errorf("want max parallel requests > 1, got %v", om.createPodTracker.maxParallel) </del> <ins> if om.createPodTracker.maxParallelRequests < expectedMinParallelRequests { t.Errorf("want max parallelRequests requests >= %v, got %v", expectedMinParallelRequests, om.createPodTracker.maxParallelRequests) </ins> } }

Discussion:
https://prow.ppc64le- TestStatefulSetControl/CreatePodFailure/Burst/ScaleDownOnly/StatefulSetAutoDeletePVCEnabled of Have started observing more flakes recently since last week. No response_ Able to reproduce using stress tool. /sig testing /sig apps
/triage accepted /assign
opened a PR with a fix:
Change:
}, { <del> name: "spec:v6 ip:v4 dualstack:on", </del> <ins> name: "spec:v6 ip:v4 dualstack:on isIPv6Primary:false", isIPv6Primary:          false, </ins> specExpctPrimary:       false, clusterIPExpectPrimary: true, enableDualStack:        true,

Discussion:
What happened: When K8s is started in dual-stack mode with IPv6 as the "main" (or base) family services specified with ipFamily:IPv4 still get a ipv6 ; The is expicitly set to "10.0.0.0" using . What you expected to happen: Services with ipFamily:IPv4 shall get ipv4 ClusterIP addresses. How to reproduce it (as minimally and precisely as possible): Setup a K8s cluster in dual-stack mode with family IPv6 as base Define a service with ipFamily: IPv4 To make K8s think IPv6 is the main family the cue is to define ipv6 addresses to K8s binaries. Below are my settings as an example. I do not use but install "from scratch"; Master processes; is accessed with ipv4 which does not affect the K8s family. Worker processes; Anything else we need to know?: There are other problems with dual-stack/ipv6-base but may be caused by this one. For example does not work and some processes does not become "ready". Ipv6 traffic to ipv6 services and DNS works; Environment: Kubernetes version (use ):Cloud provider or hardware configuration: - OS (e.g: ): BusyBox based own setup. Kernel (e.g. ):Install tools: "from scratch" Network plugin and version (if this is a network-related bug): Others:
/sig network /cc
The problem seem to be; The problem occurs when an ipv6 range is specified first, even in an ipv4-based dual-stack cluster. But the ipv6 range must be specified first otherwise the "kubernetes" service gets an ipv4 address but an ipv6 backend; ~Perhaps the way to fix this problem is to make sure the service address is from the right family and require that the order to is "ipv4,ipv6".~ Bad idea!
There seem to be a option; But I can't see it in the help printout. I will try to use it...
:disappointed:
Here it where the kubernetes service address is set;
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍