jiebi/CodeConvo huggingface dataset:
Change:
} vmID, err := pc.InstanceID(nodeName) <ins> if err == cloudprovider.InstanceNotFound { glog.Infof("Instance %q does not exist, its disks will be detached automatically.", nodeName) // make all the disks as detached. return attached, nil } </ins> if err != nil { glog.Errorf("Photon Cloud Provider: pc.InstanceID failed for DiskIsAttached. Error[%v]", err) return attached, err

Discussion:
Cloud provider volume has a function DiskIsAttached to check whether the volume is still attached to the instance. If the instance is no longer exist (deleted by cloud provider), we can safely assume that the volume is no longer attached to the instance and return false without error for DiskIsAttached(). Currently GCE PD and AWS has the correct behavior, but all other volume plugins do not.
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
In order to be easier to review, I split it for every cloud provider.
cinder plugin (openstack, rackspace):
Anyone can merge this PR:?
Change:
case err := <-injectedError: return nil, err } <del> // Never get here. return nil, nil </del> }

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 reviewing Windows kubelet logs noticed errors like: What you expected to happen: The stats should be returned How to reproduce it (as minimally and precisely as possible): This occurs when the pods has just started or during termination. To simulate the issue: Then deploy pod: Anything else we need to know?: The container is in a state but is has not started running so the call to get the stats fails: This is handled in other places like moby: and Environment: Kubernetes version (use ): 1.18+ Cloud provider or hardware configuration: aks-engine OS (e.g: ): Windows Kernel (e.g. ): 2019 Install tools: Network plugin and version (if this is a network-related bug): Others: Dockershim /sig windows /priority critical-urgent /assign
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
cc:
Change:
t.Fatal(spew.Sdump(test.Infos)) } } <ins> func TestFlattenListVisitorWithVisitorError(t *testing.T) { b := newDefaultBuilder(). FilenameParam(false, &FilenameOptions{Recursive: false, Filenames: []string{"../../artifacts/deeply-nested.yaml"}}). Flatten() test := &testVisitor{InjectErr: errors.New("visitor error")} err := b.Do().Visit(test.Handle) if err == nil || !strings.Contains(err.Error(), "visitor error") { t.Fatal(err) } if len(test.Infos) != 6 { t.Fatal(spew.Sdump(test.Infos)) } } </ins>

Discussion:
What happened: When using a yaml file for input, silently fails at the first missing resource, not returning any further results. What you expected to happen: Searching with cli arguments properly ignores missing resources and continues the query, eg: Would expect similar results with a file input, eg: How to reproduce it (as minimally and precisely as possible): With an input file of : the command fails at apparently the first missing resource: Note: that rearranging the inputs in (so that the missing resource is last) produces the "expected" output: Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: local OS (e.g: ): fedora 30 Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: x-ref:
/sig cli
/assign
Got around to reproducing it and can confirm that I'm getting the same behavior. I'm looking into fixing it now
thanks, any updates on this?
I've learned that in the case of a fake entry, kubectl stops sending API get requests altogether. Learned by running kubectl get -f --ignore-not-found --v=10, the result is shown below. Till now I've been looking into the cobra command framework but now I'm trying to find out where kubectl is making these API calls from(working on finding out where this connection is happening from Slack+debugging, I've asked a more detailed question here ). <img width="1440" alt="Screen Shot 2019-08-12 at 4 13 41 PM" src="https://user-"
that's an interesting find, definitely helpful. When I looked into this I got to the section of get's main run function, and it seems like it should be continuing on any errors (see ) but maybe the ResourceBuilder is actually stopping when it hits a 404?
This behavior comes from where the not found errors are being ignored and where the input list is flattened. Errors are ignored here: While flattening occurs here: As the visitor iterates through the objects in the list if an error occurs, such as not found, it will stop iterating over the objects in the list and return that not found error. The logic will then ignore it and continue.

Any objects that came before the not found object in the list will have been visited and will then be included in the output. To make the behavior consistent between the two ways of getting the set of objects, the would need to be updated to support filtering errors.
Just submitted a PR adding that functionality to the FlattenListVisitor. The behavior is now consistent between the two methods.
Change:
return false } <del> klog.Infof("OpenAPI AggregationController: Processing item %s", key) </del> <ins> if aggregator.IsLocalAPIService(key.(string)) { // for local delegation targets that are aggregated once per second, log at // higher level to avoid flooding the log klog.V(5).Infof("OpenAPI AggregationController: Processing item %s", key) } else { klog.Infof("OpenAPI AggregationController: Processing item %s", key) } </ins> action, err := c.syncHandler(key.(string)) if err == nil {

Discussion:
What happened: Set up an APIService object pointing to a service that does not service openapi What you expected to happen: Aggregation would attempt to aggregate, fail, and back off How to reproduce it (as minimally and precisely as possible): openapi aggregation logs continuously /sig api-machinery /cc
actually, this is happening without any external APIService objects registered as well
This is just too verbose logging. We have nothing better than polling of the delegation chain for changes. But the good thing is that with etags this should not be heavy on the CPU because nothing is recomputed (and if it is, it would be a bug).
/reopen
You can't reopen an issue/PR unless you authored it or you are a collaborator. <detailsIn response to : /reopen </details
Kube-apiserver outputs the same log every second and takes up 10% more CPU than normal
cc
This problem has been fixed in some . Someone has covered up the problem. It makes it harder for us to find the CPU problem behind it. thanks.
Change:
make test-integration WHAT=./test/integration/scheduler_perf KUBE_TIMEOUT="-timeout=3600s" KUBE_TEST_VMODULE="''" KUBE_TEST_ARGS="-alsologtostderr=false -logtostderr=false -run=^$$ -benchtime=1ns -bench=BenchmarkPerfScheduling -cpuprofile ~/cpu-profile.out" ``` <ins> ### How to configure bechmark tests Configuration file located under config/performance-config.yaml contains a list of templates. Each template allows to set: - node manifest - manifests for initial and testing pod - number of nodes, number of initial and testing pods - templates for PVs and PVCs - feature gates See `simpleTestCases` data type implementation for available configuration for each template. Initial pods create a state of a cluster before the scheduler performance measurement can begin. Testing pods are then subject to performance measurement. The configuration file under config/performance-config.yaml contains a default list of templates to cover various scenarios. In case you want to add your own, you can extend the list with new templates. It's also possible to extend `simpleTestCases` data type, respectively its underlying data types to extend configuration of possible test cases. </ins> <!-- BEGIN MUNGE: GENERATED_ANALYTICS --> [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/test/component/scheduler/perf/README.md?pixel)]() <!-- END MUNGE: GENERATED_ANALYTICS -->

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We are making a series of enhancements to scheduler benchmarks. Once we are done, we should update the Ref , Why is this needed: /sig scheduling cc
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
Change:
SyncPeriod:    metav1.Duration{Duration: 5 * time.Second}, MinSyncPeriod: metav1.Duration{Duration: 2 * time.Second}, }, <del> Mode: kubeproxyconfig.ProxyModeIPVS, </del> <ins> Mode: proxyMode, </ins> IPVS: kubeproxyconfig.KubeProxyIPVSConfiguration{ SyncPeriod:    metav1.Duration{Duration: 10 * time.Second}, MinSyncPeriod: metav1.Duration{Duration: 5 * time.Second},

Discussion:
<!-- 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 bug /sig network Fix windows UT for proxy mode. Run UTs for in windows, That's because proxy mode "IPVS" is not valid in windows. What happened: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/assign
Change:
function start_nodelocaldns { cp "${KUBE_ROOT}/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml" nodelocaldns.yaml <del> # .* because of the __PILLLAR__ references that eventually will be removed ${SED} -i -e "s/_.*_DNS__DOMAIN__/${DNS_DOMAIN}/g" nodelocaldns.yaml ${SED} -i -e "s/_.*_DNS__SERVER__/${DNS_SERVER_IP}/g" nodelocaldns.yaml ${SED} -i -e "s/_.*_LOCAL__DNS__/${LOCAL_DNS_IP}/g" nodelocaldns.yaml </del> <ins> # eventually all the __PILLAR__ stuff will be gone, but theyre still in nodelocaldns for backward compat. ${SED} -i -e "s/__PILLAR__DNS__DOMAIN__/${DNS_DOMAIN}/g" nodelocaldns.yaml ${SED} -i -e "s/__PILLAR__DNS__SERVER__/${DNS_SERVER_IP}/g" nodelocaldns.yaml ${SED} -i -e "s/__PILLAR__LOCAL__DNS__/${LOCAL_DNS_IP}/g" nodelocaldns.yaml </ins> # use kubectl to create nodelocaldns addon ${KUBECTL} --kubeconfig="${CERT_DIR}/admin.kubeconfig" --namespace=kube-system create -f nodelocaldns.yaml echo "NodeLocalDNS addon successfully deployed."

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: gci-gce-serial-kube-dns-nodecache Which test(s) are failing: N/A Since when has it been failing: 10/13 Testgrid link: https://k8s- Reason for failure: Cluster failed to start: Anything else we need to know: /cc
So, is a failing job, we can see that there is a error around binding to a specific IP address. In passing jobs, the initial core file isn't printed out () so not sure how to do an apples to apples comparison of what is broken here yet.
/kind bug I have been looking at this offline with and The only difference between a failing and a passing job is the arguments to the bind plugin. Failing Job: Link - Image - Config: Passing Job: Link - Image: Config:
Issue is reproducible when spinning up a cluster via kubetest using:
changes to lines 907-910 in hack/local-up- and lines 2467 to 2469 in configure- seem like the issue.
What we see is substitution works correctly for line , but for line , it replaces "PILLARLOCALDNS" with empty string.
/assign Can you investigate?
Yeah lookin into it
Regex is matching the entire line :). Should be easy fix . Will verify in hack local up and issue PR shortly
/sig network /triage accepted
Change:
if err != nil { t.Fatalf("Couldn't create cacher: %v", err) } <ins> if utilfeature.DefaultFeatureGate.Enabled(features.ResilientWatchCacheInitialization) { // The tests assume that Get/GetList/Watch calls shouldn't fail. // However, 429 error can now be returned if watchcache is under initialization. // To avoid rewriting all tests, we wait for watchcache to initialize. if err := cacher.Wait(context.Background()); err != nil { t.Fatal(err) } } </ins> d := destroyFunc s = cacher destroyFunc = func() {

Discussion:
pull-kubernetes-unit TestStoreListResourceVersion in seems like July 7th 2024: ! Don't know, here is the log: No response /sig
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 api-machinery
See also
/sig etcd
/assign /cc
Bisected this to cc
I'm not sure if this is the proper way to fix it, but setting a limit in the ListOptions deflakes the test. The flakiness comes from the fact that the cache is sometimes not initialized in time which causes it to return a "too many requests". Perhaps in tests we could wait till the cache is ready in order to proceed?
Right, setting a limit when a resource version is set would delegate the list to etcd when cache is not initialized based on the KEP description. It is due to this type of request is not that costly to etcd. Looks like it is exactly how the wait cache ready is in See below So I think we should implement this same thing in when initializing the .
Agree - waiting for cacher to be initialized when creating it here is a better fix for it:
I thought about this as well, but waiting on is not possible outside of the cacher module, since it is a private field. I'm thinking to either add an option to cacherstorage.Config and make wait or add a new public method to . Do you guys have a better idea? Thanks.
Exposing Wait(context) method sounds fine
I have pushed the changes we discussed. Thank you all for your guidance.
Change:
"iface-127.0.0.1:3260:pv1/127.0.0.1:3260-iqn.2003-01.io.k8s:e2e.volume-1-lun-3", "iface-127.0.0.1:3260:pv2/127.0.0.1:3260-iqn.2003-01.io.k8s:e2e.volume-1-lun-2", "iface-127.0.0.1:3260:pv2/192.168.0.1:3260-iqn.2003-01.io.k8s:e2e.volume-1-lun-1", <ins> filepath.Join(config.DefaultKubeletVolumeDevicesDirName, "iface-127.0.0.1:3260/192.168.0.2:3260-iqn.2003-01.io.k8s:e2e.volume-1-lun-4"), filepath.Join(config.DefaultKubeletVolumeDevicesDirName, "iface-127.0.0.1:3260/192.168.0.3:3260-iqn.2003-01.io.k8s:e2e.volume-1-lun-5"), </ins> } for _, d := range subdirs {

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:
shouldDeny:     true, }, } <del> for _, c := range evictionCases { </del> <ins> for i := range evictionCases { c := evictionCases[i] </ins> expectation := "should allow an eviction" if c.shouldDeny { expectation = "should not allow an eviction"

Discussion:
Due to a bug in the disruption e2e test, we really only run one test case 5 times instead of all 5 test cases. This will be fixed when is merged.
Change:
srcs = [ "controller.go", "doc.go", <del> "patch.go", </del> ], importpath = "k8s.io/kubernetes/pkg/controller/service", visibility = ["//visibility:public"], deps = [ "//staging/src/k8s.io/api/core/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/api/errors:go_default_library", <del> "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", </del> "//staging/src/k8s.io/apimachinery/pkg/labels:go_default_library", <del> "//staging/src/k8s.io/apimachinery/pkg/types:go_default_library", </del> "//staging/src/k8s.io/apimachinery/pkg/util/runtime:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", <del> "//staging/src/k8s.io/apimachinery/pkg/util/strategicpatch:go_default_library", </del> "//staging/src/k8s.io/apimachinery/pkg/util/wait:go_default_library", "//staging/src/k8s.io/apiserver/pkg/util/feature:go_default_library", "//staging/src/k8s.io/client-go/informers/core/v1:go_default_library",

Discussion:
PR service patch methods to Once there is a release with that PR included, the code in service-controller and legacy-cloud-providers/gce can be updated to use those. /area platform/gce /assign
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Those labels are not set on the issue: <detailsIn response to : /remove-triage unresolved 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
Created a PR to use these new functions in Service-controllers.
Change:
// same status. newStatus.ObservedGeneration = rc.Generation <del> var getErr error </del> <ins> var getErr, updateErr error var updatedRC *v1.ReplicationController </ins> for i, rc := 0, &rc; ; i++ { <del> glog.V(4).Infof(fmt.Sprintf("Updating replica count for rc: %s/%s, ", rc.Namespace, rc.Name) + </del> <ins> glog.V(4).Infof(fmt.Sprintf("Updating status for rc: %s/%s, ", rc.Namespace, rc.Name) + </ins> fmt.Sprintf("replicas %d->%d (need %d), ", rc.Status.Replicas, newStatus.Replicas, *(rc.Spec.Replicas)) + fmt.Sprintf("fullyLabeledReplicas %d->%d, ", rc.Status.FullyLabeledReplicas, newStatus.FullyLabeledReplicas) + fmt.Sprintf("readyReplicas %d->%d, ", rc.Status.ReadyReplicas, newStatus.ReadyReplicas) +

Discussion:
Is this a request for help? No. What keywords did you search in Kubernetes issues before filing this one? dangling ReplicaSet Is this a BUG REPORT or FEATURE REQUEST? BUG REPORT Kubernetes version (use ): Environment: Cloud provider or hardware configuration: Azure A1 OS (e.g. from /etc/os-release): NAME="Container Linux by CoreOS" ID=coreos VERSION=1235.9.0 VERSIONID=1235.9.0 BUILDID=2017-02-02-0235 PRETTYNAME="Container Linux by CoreOS 1235.9.0 (Ladybug)" ANSICOLOR="38;5;75" HOMEURL="" BUGREPORTURL="" Kernel (e.g. ): Linux node-3-vm 4.7.3-coreos-r2 SMP Thu Feb 2 02:26:10 UTC 2017 x8664 Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz GenuineIntel GNU/Linux Install tools: own Others: What happened: Created new deployment by altering the image tag of the deployment descriptor and using kubectl apply -f "". Noticed that one container of the previous deployment stayed there. What you expected to happen: All containers from the previous deployment should have been terminated. How to reproduce it (as minimally and precisely as possible): I cannot reliably trigger this, I do several deployments per hour and sometimes this problem manifests itself. Anything else we need to know: Deployment descriptor:
Can you also post the output of kubectl get deployment tviftttapp -o yaml kubectl get rs (dangling rs) -o yaml When this manifests again?
Here are the current deployment, the dangling RS, and the "good" RS. Deployment: Dangling RS: Current RS:
It seems that status.availableReplicas for the new replica set is never correctly updated to 2. Short term if you stop using minReadySeconds (minReadySeconds=2 doesn't offer you much anyway), this problem should stop. Long term, we should fix the status update. cc:
can one of you guys paste logs from the controller manager when this issue occurs? Log level should be ideally set to 2.

I managed to reproduce it:
Will close this one once is cherry-picked into 1.5
4 is out and contains a fix that should force the Deployment to be resynced eventually and have availableReplicas updated. Not optimal yet but eventually consistent. I have queued up some follow-up work to refine the resync.
Does anyone know when version 1.5.4 OR 1.6 will be available using Redhat package downloads (in RPM form) ? I only see version 1.5.2 being the latest there. I have the same problem that is being discussed in this thread and want to upgrade so that my K8S cluster can support Deployments.
Change:
framework.ExpectNoErrorWithOffset(0, err) for _, node := range nodeList.Items { if node.Labels[gkeNodepoolNameKey] == poolName { <ins> node := node </ins> nodes = append(nodes, &node) } }

Discussion:
At , within the loop , variable is shared by all the loop iterations, as described in the Go specification (). All instances of &pv within the loop may refer to the last tem updated by the loop. As a consequence, may hold multiple instances of the same item. Later on these remaining PVs are deleted, so it is possible that the same is deleted multiple times: More information on the bug can be found at A fix is to avoid reusing the shared variable node: Found by #deepgo.
/triage accepted /area e2e-test-framework
Thanks for pointing out, makes complete sense. I'm happy to fix it. /assign
/sig testing

At , within the loop , variable is shared by all the loop iterations, as described in the Go specification (). All instances of &node within the loop may refer to the last node item updated by the loop. As a consequence, may hold multiple instances of the same node. Note that the following unit test checks only the number of nodes rather than the nodes themselves (otherwise the bug may be revealed): More information on the bug can be found at A fixe is to avoid reusing the shared variable : Found by #deepgo.
/triage accepted /area e2e-test-framework /sig testing
Thanks for pointing out, makes complete sense. I'm happy to fix it. /assign