jiebi/CodeConvo huggingface dataset:
Change:
destroy-network } <del> function find-release-tars { SERVER_BINARY_TAR="${KUBE_ROOT}/server/kubernetes-server-linux-amd64.tar.gz" if [[ ! -f "$SERVER_BINARY_TAR" ]]; then SERVER_BINARY_TAR="${KUBE_ROOT}/_output/release-tars/kubernetes-server-linux-amd64.tar.gz" fi if [[ ! -f "$SERVER_BINARY_TAR" ]]; then echo "!!! Cannot find kubernetes-server-linux-amd64.tar.gz" exit 1 fi } </del> # The kubernetes binaries are pushed to a host directory which is exposed to the VM function upload-server-tars { tar -x -C "$POOL_PATH/kubernetes" -f "$SERVER_BINARY_TAR" kubernetes

Discussion:
I suspect we're going through an if/else clause where KUBETARURL isn't defined, and not defaulting it, though the function header seems to indicate it should be set in the callee.
Will take a look.
Is this in Jenkins, or on a local run? The Jenkins push job is borked as well, but it looks like it's for a different reason: Which I'm taking care of in .
Jobs are generating incredibly large log files (300 Megs?) with lots of repeated lines like this: Failure trying to curl release .sha1 /jenkins-master-data/jobs/kubernetes-push-gce-step1-deploy/workspace/kubernetes/hack/e2e-internal/../../cluster/../cluster/../c line 283: KUBETARURL: unbound variable Failure trying to curl release .sha1 /jenkins-master-data/jobs/kubernetes-push-gce-step1-deploy/workspace/kubernetes/hack/e2e-internal/../../cluster/../cluster/../c line 283: KUBETARURL: unbound variable Failure trying to curl release .sha1 I think this needs to be resolved, since it already caused an out-of-disk in Jenkins.
Okiedokie. Yes, this was my fault. silently expects and to be set in . I the extra expectation that be set, but didn't think about how would then also have to set that. Working on a fix.
(For anyone who cares, culprit is .)
Change:
"testing" "golang.org/x/net/context" <ins> "k8s.io/kubernetes/pkg/cloudprovider" </ins> "k8s.io/kubernetes/pkg/util/rand" )

Discussion:
ExternalID/InstanceID do not return 'cloudprovider.InstanceNotFound' error when the VM is not found. This can occur when a node VM is deleted entirely. In this case InstanceID method would throw an nil pointer exception here: since returned error here: is not being handled, vm would be nil. vm object is then dereferenced in getVirtualMachineManagedObjectReference func. In ExternalID method, the error is being handled by just passing it up. Node controller then prints out error and continues: e.g. ExternalID/InstanceID should handle the 'nod found' error being returned from vCenter and return 'cloudprovider.InstanceNotFound'.
Change:
exit 1 fi kube::log::status "Checking kubectl version" <del> export KUBERNETES_MASTER=http://127.0.0.1:${API_PORT} </del> kubectl version # Generate a random namespace name, based on the current time (to make

Discussion:
What happened: I am using a command like below in GitHub actions: I get the following error: What you expected to happen: Since I am using flag, it should work without requiring a valid kubeconfig file. How to reproduce it (as minimally and precisely as possible): Just delete your local kubeconfig file and try the above command. Anything else we need to know?: Environment: 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 cli
/assign /kind regression
This likely breaks some scripted usage of kubectl
This is related to /assign
Or
Yes, sorry I mentioned you in this issue. Because my first thought is this brings and which will check the config file existence but in fact that's not the root cause. Actually the root cause This checks config has the server or not. And with this , this function will return error when there's no local config file. I think there might be two solutions? the similar logic like to every , , ..... when or is set. Seems not a good idea. reverse this to have the default server which is better than ? By the way, is equals ? Since This works only for .
The plan I agreed on with Jordan is that I will revert since that seems to be the main culprit behind all these problems. I'll add a test ensuring this works as required. This will allow us to backport the fix to 1.18. For 1.19 I'll put together a proper fix supporting and flags.
Change:
return nil }, framework.StatefulPodTimeout, 2*time.Second).Should(BeNil()) }) <del> /* Comment it for now until scale sub-resource is finalized in ref:pull/53679 for scale-sub resource specific comment. </del> It("should have a working scale subresource", func() { By("Creating statefulset " + ssName + " in namespace " + ns) ss := framework.NewStatefulSet(ssName, ns, headlessSvcName, 1, nil, nil, labels)

Discussion:
What would you like to be : e2e test suites for: GET /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}/scale PUT /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}/scale Why is this needed: PR has already been merged, but the following tests are still commented out. Therefore, scale sub-resource of statefulsets is not tested and test should be . /sig testing
Change:
package plugin import ( <ins> "context" "errors" "net" </ins> "sync" <ins> "time" "google.golang.org/grpc" "google.golang.org/grpc/connectivity" "google.golang.org/grpc/credentials/insecure" </ins> utilversion "k8s.io/apimachinery/pkg/util/version" <ins> "k8s.io/klog/v2" </ins> ) // Plugin is a description of a DRA Plugin, defined by an endpoint // and the highest DRA version supported. type Plugin struct { <ins> sync.RWMutex conn                    *grpc.ClientConn </ins> endpoint                string highestSupportedVersion *utilversion.Version } <ins> func (p *Plugin) getOrCreateGRPCConn() (*grpc.ClientConn, error) { p.Lock() defer p.Unlock() if p.conn != nil { return p.conn, nil } network := "unix" klog.V(4).InfoS(log("creating new gRPC connection"), "protocol", network, "endpoint", p.endpoint) conn, err := grpc.Dial( p.endpoint, grpc.WithTransportCredentials(insecure.NewCredentials()), grpc.WithContextDialer(func(ctx context.Context, target string) (net.Conn, error) { return (&net.Dialer{}).DialContext(ctx, network, target) }), ) if err != nil { return nil, err } ctx, cancel := context.WithTimeout(context.Background(), time.Second) defer cancel() if ok := conn.WaitForStateChange(ctx, connectivity.Connecting); !ok { return nil, errors.New("timed out waiting for gRPC connection to be ready") } p.conn = conn return p.conn, nil } </ins> // PluginsStore holds a list of DRA Plugins. type PluginsStore struct { sync.RWMutex

Discussion:
See comment for details:
/sig node
/area kubelet
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues 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 as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
/triage accepted
Change:
// We can use the same metadata producer for all nodes. meta := metadataProducer(pod, nodeNameToInfo) <ins> var equivCacheInfo *equivalenceClassInfo if ecache != nil { // getEquivalenceClassInfo will return immediately if no equivalence pod found equivCacheInfo = ecache.getEquivalenceClassInfo(pod) } </ins> checkNode := func(i int) { nodeName := nodes[i].Name <del> fits, failedPredicates, err := podFitsOnNode(pod, meta, nodeNameToInfo[nodeName], predicateFuncs, ecache, schedulingQueue, alwaysCheckAllPredicates) </del> <ins> fits, failedPredicates, err := podFitsOnNode( pod, meta, nodeNameToInfo[nodeName], predicateFuncs, ecache, schedulingQueue, alwaysCheckAllPredicates, equivCacheInfo, ) </ins> if err != nil { predicateResultLock.Lock() errs[err.Error()]++

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Today, . This seems unnecessary and should be done once for all the nodes. Is this a BUG REPORT or FEATURE REQUEST?: /kind enhancement /sig scheduling cc:
/assign Thanks, will send fix per slack discussion.
/cc
Change:
} return "", err } <del> func formatIfNotFormatted(disk string, fstype string, exec mount.Exec) { notFormatted, err := diskLooksUnformatted(disk, exec) if err == nil && notFormatted { args := []string{disk} // Disk is unformatted so format it. // Use 'ext4' as the default if len(fstype) == 0 { fstype = "ext4" } if fstype == "ext4" || fstype == "ext3" { args = []string{"-E", "lazy_itable_init=0,lazy_journal_init=0", "-F", disk} } glog.Infof("azureDisk - Disk %q appears to be unformatted, attempting to format as type: %q with options: %v", disk, fstype, args) _, err := exec.Run("mkfs."+fstype, args...) if err == nil { // the disk has been formatted successfully try to mount it again. glog.Infof("azureDisk - Disk successfully formatted with 'mkfs.%s %v'", fstype, args) } else { glog.Warningf("azureDisk - Error formatting volume with 'mkfs.%s %v': %v", fstype, args, err) } } else { if err != nil { glog.Warningf("azureDisk - Failed to check if the disk %s formatted with error %s, will attach anyway", disk, err) } else { glog.Infof("azureDisk - Disk %s already formatted, will not format", disk) } } } func diskLooksUnformatted(disk string, exec mount.Exec) (bool, error) { args := []string{"-nd", "-o", "FSTYPE", disk} glog.V(4).Infof("Attempting to determine if disk %q is formatted using lsblk with args: (%v)", disk, args) dataOut, err := exec.Run("lsblk", args...) if err != nil { glog.Errorf("Could not determine if disk %q is formatted (%v)", disk, err) return false, err } output := libstrings.TrimSpace(string(dataOut)) return output == "", nil } </del>

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When use an existing azure disk(also called ) in pod, if that disk has partitions, the disk will be formatted in the pod mounting. What you expected to happen: How to reproduce it (as minimally and precisely as possible): create a disk with source from an os disk, e.g. that disk is already formatted before pod could access it Anything else we need to know?: Root cause: current diskLooksUnformatted func is using command to check whether disk is formatted or not while common k8s code() is using to detect disk format, could detect multiple partitions so if we use common k8s code(), following error will be returned for mulitple partition disks, which is expected: Environment: Kubernetes version (use ): v1.7 - v1.11 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig azure /assign
cc
iirc we don't support partitions on Azure volumes. There was a specific hang long ago. in all cases i think should be safe to based check now via the underlaying api
thanks for the info, I am writing this PR, and also testing carefully. And this issue depends on , could you review it first? Thanks.
Change:
ensure-install-dir set-kube-env create-salt-pillar <ins> download-release </ins> run-salt echo "== kube-push node config done ==" fi

Discussion:
I made several attempts to update the apiserver (i.e. on the master) using and but they failed to update the binary. I noticed the same PID on the master for and a long uptime. If I tore the cluster down and rebuilt it then I could see the change I made to the apiserver.
I'm actively working on it.
I noticed exact the same issue today by update my kubelet binary.
Push is broken, sorry. I thought I tested it, but the binaries aren't getting bonked appropriately.
kubelet binary push actually worked before? That path looked dubious at best. On Mar 12, 2015 3:56 PM, "Dawn Chen" wrote:
I would appreciate external testing. I have done some sniff testing, but push is a really broad use-case. , Satnam Singh wrote:
reopen this since the fix is reversed.

On GCE, when I run to push new binaries to e2e cluster, the binaries are not pushed.
I lost a lot of time due to this bug today. I was debugging failing e2e tests, and I was using this command often. I took me some time before I realized it doesn't work and I need to do each time.
Can you be specific? I verified apiserver push at least, and I manually inspected kubelet, but it's fidgety to test push. On Mar 12, 2015 8:16 AM, "Satnam Singh" wrote:
The scenario: compiled the old version and installed it with -v -build -up; run some e2e tests, cluster with the old version was running; changed source code of some files in pkg/apiserver or pkg/registry/pod; compiled the new version and was trying to install it with -v -build -push; run some e2e tests, hoping the new version of apiserver was deployed. However, the old version was still running during step 5. It seemed that step 4. compiled the new version, but didn't deploy it. To deploy the new version I needed to run -up.
I did tests to verify that I was no longer seeing version mismatches after a push (which is a good sign that a push succeeded in bonking the apiserver), but I'll see if I can do more rigorous testing soon. To be honest, the master push hasn't changed much - the node deployment was the part that changed much more radically with the Salt changes. So I'm not exactly sure what you're seeing here. , Jerzy Szczepkowski < :
Change:
// ControllerRevisionNamespaceLister. type ControllerRevisionNamespaceListerExpansion interface{} <del> // DaemonSetListerExpansion allows custom methods to be added to // DaemonSetLister. type DaemonSetListerExpansion interface{} // DaemonSetNamespaceListerExpansion allows custom methods to be added to // DaemonSetNamespaceLister. type DaemonSetNamespaceListerExpansion interface{} // DeploymentListerExpansion allows custom methods to be added to // DeploymentLister. type DeploymentListerExpansion interface{} // DeploymentNamespaceListerExpansion allows custom methods to be added to // DeploymentNamespaceLister. type DeploymentNamespaceListerExpansion interface{} // ReplicaSetListerExpansion allows custom methods to be added to // ReplicaSetLister. type ReplicaSetListerExpansion interface{} // ReplicaSetNamespaceListerExpansion allows custom methods to be added to // ReplicaSetNamespaceLister. type ReplicaSetNamespaceListerExpansion interface{} </del> // ScaleListerExpansion allows custom methods to be added to // ScaleLister. type ScaleListerExpansion interface{}

Discussion:
As a prerequisite of moving the , , , and controllers to use the apps/v1beta2 APIs, we need to add list expansions for , , , and to .
/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 apps
Change:
# KUBE_TEST_API_VERSIONS=${KUBE_TEST_API_VERSIONS:-"v1,experimental/v1alpha1"} KUBE_TEST_API_VERSIONS=${KUBE_TEST_API_VERSIONS:-"v1,experimental/v1alpha1"} <ins> # Give integration tests longer to run KUBE_TIMEOUT=${KUBE_TIMEOUT:--timeout 240s} </ins> KUBE_INTEGRATION_TEST_MAX_CONCURRENCY=${KUBE_INTEGRATION_TEST_MAX_CONCURRENCY:-"-1"} LOG_LEVEL=${LOG_LEVEL:-2}

Discussion:
The first line logged from the integration test is the last line from the service account token test is then the test panics with: I think the tests are just running too close the the timeout. On successful runs, the tests take ~115 seconds, which is ridiculously close to the threshold. For example: see
ok, do you want to send a PR to increase the timeout to 3 or 4 minutes?
Sure, I can do that tonight

cc
Has this test failed more than once, or did the two-minute timeout just happen to occur in the middle of it?
I think 2 minutes is not sufficient for the integration tests. See comment at
Change:
Message: "CustomResource deletion is in progress", }) crd, err = c.crdClient.CustomResourceDefinitions().UpdateStatus(crd) <ins> if apierrors.IsNotFound(err) || apierrors.IsConflict(err) { // deleted or changed in the meantime, we'll get called again return nil } </ins> if err != nil { return err }

Discussion:
k8s version: v1.9.3 When I create customresourcedefinition, There is error like Operation cannot be fulfilled on "": the object has been modified; please apply your changes to the latest version and try again . apiVersion: kind: CustomResourceDefinition metadata: name: annotations: "": crd-install labels: app: istio-pilot spec: group: names: kind: VirtualService listKind: VirtualServiceList plural: virtualservices singular: virtualservice categories: istio-io networking-istio-io scope: Namespaced version: v1alpha3 So what is the reason of it?
a few questions: where are you seeing the error, in the apiserver log or in the output of the kubectl command? what kubectl command are you using to create the object? are you running HA apiservers?
The log is shown by apiserver. I run k8s in HA apiservers. The command I used is "kubectl apply -f "+file.
API servers attempt to update CRD status to indicate whether the names were available. In an HA apiserver setup, the API servers race to do so, and all but the first lose the race with a resource conflict error. That is not unexpected. Opened to avoid logging normal API responses in that scenario.
Thanks ! But I want to know whether the CRD has been set successfully in HA apiservers ? I use the command " kubectl get crd -o yaml" and get the following results. ! I see its status is true. But when i create a virtualservices, it returns error. Error from server (Timeout): error when creating "cms-api-": Timeout: request did not complete within allowed duration ! So i want to know how to solve this error.
/assign
Excuse me. Do you have some greate ideas to solve this issue??
There is a PR for this sent by
I see your request is timed-out not failed. In HA, I expect the request to fail in the first seconds of the CRD creation, but after that it should go through. I need more logs during this timeout or a consistent way to reproduce it.
Change:
} __EOF__ <ins> # Ensure the API server has recognized and started serving the associated CR API local tries=5 for i in $(seq 1 $tries); do local output output=$(kubectl "${kube_flags[@]:?}" api-resources --api-group mygroup.example.com -oname) if kube::test::if_has_string "$output" resources.mygroup.example.com; then break fi echo "${i}: Waiting for CR API to be available" sleep "$i" done </ins> # Dry-run create the CR kubectl "${kube_flags[@]:?}" apply --dry-run=server -f hack/testdata/CRD/resource.yaml "${kube_flags[@]:?}" # Make sure that the CR doesn't exist

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: Which test(s) are flaking: Testgrid link: Reason for failure: Anything else we need to know: /sig cli /cc /milestone v1.20 /prority important-soon
after creating the CRD, before applying the CR, kubectl should wait until includes :
/assign
/assign is this issue related to ?
no, this is simply kubectl trying to apply a CR before the server has made the API available at all
Got it! and I have filed to address this issue.
Still happening:
still happening: looks like the root cause is not related to CRD: I think the message Error from server (NotFound): "myobj" not found is expected, as the CR was not actually created: /reopen
Reopened this issue. <detailsIn response to : still happening: I think the message Error from server (NotFound): "myobj" not found is expected, as the CR was not actually created: 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, the actual error is later: Line 177 succeeds, and the next line fails:
Change:
apiVersion: v1 kind: ReplicationController metadata: <del> name: kube-dns-v17 </del> <ins> name: kube-dns-v17.1 </ins> namespace: kube-system labels: k8s-app: kube-dns <del> version: v17 </del> <ins> version: v17.1 </ins> kubernetes.io/cluster-service: "true" spec: replicas: __PILLAR__DNS__REPLICAS__ selector: k8s-app: kube-dns <del> version: v17 </del> <ins> version: v17.1 </ins> template: metadata: labels: k8s-app: kube-dns <del> version: v17 </del> <ins> version: v17.1 </ins> kubernetes.io/cluster-service: "true" spec: containers:

Discussion:
Observed weird memory spikes for both the dns healthz and kube-dns pods in production. Kube-dns didn't oom because there's enough headroom, but healthz did. I can't explain the spikes yet. I tried a bunch of different repros: no , bad nslookup command, sharing the node with cpu hogs etc, but was unable to trigger it. The memory grows, but stays under 10Mi. As a short term mitigation, we stole some ram from kube-dns, because it was always comfortably within limits. Related b/
can be closed -- healthz has been removed
-- close issue?
Change:
v1 "k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> utilfeature "k8s.io/apiserver/pkg/util/feature" "k8s.io/kubernetes/pkg/features" </ins> kubeletconfig "k8s.io/kubernetes/pkg/kubelet/apis/config" "k8s.io/kubernetes/test/e2e/framework" e2epod "k8s.io/kubernetes/test/e2e/framework/pod"

Discussion:
The swap fedora job is failing consistently for OOM. For a while. It looks like OOM is not actually killing these pods when swap is enabled. I did not see any examples of this failing without swap enabled so I think this is a real issue. There is a failure in OOMKilled as part of the serial fedora job but that is not related to this. This is part of and should be required for promotion to Beta2. /sig node
/triage accepted /priority important-longterm
Change:
name = "cri_tools_%s" % arch, downloaded_file_path = "cri_tools.tgz", sha256 = sha, <del> urls = mirror("https://github.com/kubernetes-incubator/cri-tools/releases/download/v%s/crictl-v%s-linux-%s.tar.gz" % (CRI_TOOLS_VERSION, CRI_TOOLS_VERSION, arch)), </del> <ins> urls = mirror("https://github.com/kubernetes-incubator/cri-tools/releases/download/v%s/crictl-v%s-%s.tar.gz" % (CRI_TOOLS_VERSION, CRI_TOOLS_VERSION, arch)), </ins> ) # Use go get -u github.com/estesp/manifest-tool to find these values

Discussion:
Right now cri-tools only include tarballs for linux /cc /cc
/sig release
/area release-eng /milestone v1.16 /help /priority important-soon
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /area release-eng /milestone v1.16 /help /priority important-soon 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
Hello! I'm a bug triage shadow for the 1.16 release cycle and considering this issue is tagged for 1.16, I'd like to check its status. Code freeze is starting on August 29th (about 2 days from now). Do we still target this issue to be fixed for 1.16?
No, nobody is working on this for 1.16. cc
/milestone clear
anything we can do in release team to move this forward?
I'm working on this one now if nobody else minds. :) /assign