Question: return o.f.PrintObject(o.cmd, mapper, outputObj, o.out) } <del> cmdutil.PrintSuccess(mapper, false, o.out, info.Mapping.Resource, info.Name, false, "tainted") </del> <ins> cmdutil.PrintSuccess(mapper, false, o.out, info.Mapping.Resource, info.Name, false, operation) </ins> return nil }) } // validateNoTaintOverwrites validates that when overwrite is false, to-be-updated taints don't exist in the node taint list (yet) <del> func validateNoTaintOverwrites(obj runtime.Object, taints []v1.Taint) error { node, ok := obj.(*v1.Node) if !ok { return fmt.Errorf("unexpected type %T, expected Node", obj) } </del> <ins> func validateNoTaintOverwrites(node *v1.Node, taints []v1.Taint) error { </ins> allErrs := []error{} oldTaints := node.Spec.Taints for _, taint := range taints {

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.0-alpha.3.1185+-dirty Server Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.0-alpha.3.1185+-dirty" What happened: Kubectl is always reporting as node <XYZis tainted irrespective of operation when used with local cluster. taint nodes XYZ dedicated- node "XYZ" tainted What you expected to happen: It should have shown exact operation like tainted, untainted modified and overwritten but because of it is always returning tainted. How to reproduce it (as minimally and precisely as possible): taint nodes XYZ dedicated-
cc/
Regarding Yes I agree we should provide more clearer output/feedback. But providing something that makes output more confusing than existing is something would be even more concerning. So as I stated , it would be good to discuss/decide how the output/feedback should like for various operations for one and multi nodes scenarios.
I think having 1 return values is an exponential improvement on what we have now, even if they aren't perfect for all cases. Rather then a disproportionately long debate over a relatively simple improvement.... Could you guys suggest something simple that you're confident it will be easy to agree on, and we can implement it as a second pass ? we are happy to implement anything with n 1 return values :).
I think we'd be happy to consider any reasonable PR. I'm not sure why was closed; I didn't look at it though so I don't know if it solves the problem.
(hit close accidentally)
, I am not sure why was closed. But I raised a PR around 15 days ago() to address this.


Question: pvc, err = c.CoreV1().PersistentVolumeClaims(pvc.Namespace).Create(pvc) Expect(err).NotTo(HaveOccurred()) Expect(pvc).ToNot(Equal(nil)) <del> defer func() { framework.Logf("Deleting claim %q/%q", pvc.Namespace, pvc.Name) framework.ExpectNoError(c.CoreV1().PersistentVolumeClaims(pvc.Namespace).Delete(pvc.Name, nil)) }() </del> claims := []*v1.PersistentVolumeClaim{pvc}

In 1.8, we a new feature to expose PVC information through summary API so user can check the volume belongs to which PVC. We should add e2e test in under test/e2enode.
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
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/storage: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/cleanup: Adding tests, refactoring, fixing old bugs. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
/assign
GitHub didn't allow me to assign the following users: vkamra. Note that only 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
Can we please move this out of 1.8 milestone?
- I'm looking into adding this but yes we should move this out of 1.8. I don't have permissions to do that though.
ack Can we please move this out of 1.8?
Sorry am not sure why was this removed from 1.8 milestone. Are we not aiming to add the tests in 1.8? Or Are we disabling the feature or are we fine shipping it without any e2e tests in 1.8?
The test is in . I think we can keep this feature in 1.8


Question: buildImageRegistry      = registry.BuildImageRegistry gcAuthenticatedRegistry = registry.GcAuthenticatedRegistry gcEtcdRegistry          = registry.GcEtcdRegistry <del> gcHttpdRegistry         = registry.GcHttpdRegistry </del> gcRegistry              = registry.GcRegistry sigStorageRegistry      = registry.SigStorageRegistry gcrReleaseRegistry      = registry.GcrReleaseRegistry

<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --/sig windows /cc After was merged I think.
I agree that looks like the issue. It started failing between the two commits: on this run:
/triage accepted
/assign


Question: buildImageRegistry      = registry.BuildImageRegistry gcAuthenticatedRegistry = registry.GcAuthenticatedRegistry gcEtcdRegistry          = registry.GcEtcdRegistry <del> gcHttpdRegistry         = registry.GcHttpdRegistry </del> gcRegistry              = registry.GcRegistry sigStorageRegistry      = registry.SigStorageRegistry gcrReleaseRegistry      = registry.GcrReleaseRegistry

<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Kubernetes e2e suite: [sig-apps] StatefulSet [] Basic StatefulSet functionality [StatefulSetBasic] should have a working scale subresource [Conformance] Kubernetes e2e suite: [sig-apps] StatefulSet [] Basic StatefulSet functionality [StatefulSetBasic] should perform canary updates and phased rolling updates of template modifications [Conformance] and a few others.
/sig windows
/triage accepted
/cc should be resolved by
Currently blocked because there are some issues pushing the httpd test images to . Slack thread:
Latest thread:
The job failing is:
is where the fixes for publishing this image is being tracked


Question: for url in "${urls[@]}"; do local file="${url##*/}" rm -f "${file}" <del> if ! curl -f --ipv4 -Lo "${file}" --connect-timeout 20 --max-time 80 --retry 6 --retry-delay 10 "${url}"; then </del> <ins> if ! curl -f --ipv4 -Lo "${file}" --connect-timeout 20 --max-time 300 --retry 6 --retry-delay 10 "${url}"; then </ins> echo "== Failed to download ${url}. Retrying. ==" elif [[ -n "${hash}" ]] && ! validate-hash "${file}" "${hash}"; then echo "== Hash validation of ${url} failed. Retrying. =="

We download the kube bundle from S3 with curl . But, now that the bundle is well over 1GB, 80 seconds is often not long enough on some of the smaller AWS instances (I think it's a combo of disk slowness, CPU slowness for the SSL and network slowness). PR coming which bumps it to 300 once I have tested it.


Question: func TestNodeShouldRunDaemonPod(t *testing.T) { cases := []struct { <ins> predicateName                                    string </ins> podsOnNode                                       []*v1.Pod nodeCondition                                    []v1.NodeCondition ds                                               *extensions.DaemonSet

Is this a BUG REPORT or FEATURE REQUEST?: /kind enhancement /sig apps Description: is a key function of DaemonSet; it's better to have more unit test case for it, e.g. node status, pod on the node. There's several test cases to the DaemonSet's finial decision, which are kind of integration test to me; prefer to provide more unit test case for this key function.
GitHub didn't allow me to assign the following users: mathspanda. Note that only 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
do you have any specific cases or shall I figure out something? I can take a look at this issue if you don't mind.
, , thanks very much for our effort on this enhancement; as you known, DaemonSet will use scheduler's predicates to decide which node can place pods; there's several predicates errors , the purpose of this issue is to trigger every error in unit test for code coverage.
Sure, thanks. I'll cover these predicates.
Also I've found interesting issue when I wanted to add test for predicate. It looks like is not handled or maybe I did something wrong, I couldn't find check. According following comments it should fail because AWS EBS forbids any two pods mounting the same volume ID : Test case: Any thoughts? is it correct behavior?


Question: CFSSLJSON_BIN="${cfssldir}/cfssljson" if [[ ! -x ${CFSSL_BIN} || ! -x ${CFSSLJSON_BIN} ]]; then echo "Failed to download 'cfssl'. Please install cfssl and cfssljson and verify they are in $PATH." <del> echo "Hint: export PATH=$PATH:$GOPATH/bin; go get -u github.com/cloudflare/cfssl/cmd/..." </del> <ins> echo "Hint: export PATH=$PATH:$GOPATH/bin; go install github.com/cloudflare/cfssl/cmd/...@latest" </ins> exit 1 fi popd > /dev/null || return 1

While trying to run with a valid ibmcloud account, the following error happened I also tried to run and got the same error. Looks like a compatibility issue. ibmcloud CLI shouldn't return error Run with a valid IBM cloud account. No response I am trying to build kubemark from source <details</details<detailsIBM cloud IKS </details<details</details<details</details<details</details<details</details
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 scalability
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]:
The Kubernetes project currently lacks enough active 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 Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:


Question: <ins> /* Copyright 2024 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ // This is an empty file to avoid "build constraints exclude all Go files" error while running unit tests on non-linux platforms. package nftables </ins>

Tried running make test against local latest fork of kubernetes master Go version Go env Successfully able to run the test Try running make test on darwin os. No response <details</detailsLatest master <details</details<details</details<details</details<details</details<details</details
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
/assign
Bro i think there might be problem with your setup , its not an issue .
test cases are working fine
Thanks for verifying, I will double check from my side, I hope you verified it on darwin os.
/sig release
Also seeing this when trying to run on mac


Question: } } } <ins> // NumNodes returns the number of nodes. func (nt *NodeTree) NumNodes() int { nt.mu.RLock() defer nt.mu.RUnlock() return nt.numNodes } </ins>

Description: , part of the is exporting a field which allows to modify its value externally. This also means that this field is not thread-safe. Solution: Expose a method that returns this value in a thread-safe way and do not export the field. /kind bug /sig scheduling


Question: <rect style="fill: #ffffff" x="126.911" y="92.49" width="189.4" height="38"/> <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="126.911" y="92.49" width="189.4" height="38"/> <text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="221.611" y="115.39"> <del> <tspan x="221.611" y="115.39">kubecfg (user commands)</tspan> </del> <ins> <tspan x="221.611" y="115.39">kubectl (user commands)</tspan> </ins> </text> </g> <text font-size="12.8" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="142.476" y="866.282">

Architecture picture: says kubecfg is deprecated. The architecture picture should be updated to show kubectl instead of kubecfg.
ref /cc


Question: <ins> /* Copyright 2020 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package logs import ( "fmt" "github.com/go-logr/logr" "github.com/spf13/pflag" "k8s.io/klog/v2" ) const ( logFormatFlagName = "logging-format" defaultLogFormat  = "text" ) // Options has klog format parameters type Options struct { LogFormat string } // NewOptions return new klog options func NewOptions() *Options { return &Options{ LogFormat: defaultLogFormat, } } // Validate check LogFormat in registry or not func (o *Options) Validate() []error { if _, err := o.Get(); err != nil { return []error{fmt.Errorf("unsupported log format: %s", o.LogFormat)} } return nil } // AddFlags add logging-format flag func (o *Options) AddFlags(fs *pflag.FlagSet) { fs.StringVar(&o.LogFormat, logFormatFlagName, defaultLogFormat, "Set log format") } // Apply set klog logger from LogFormat type func (o *Options) Apply() { // if log format not exists, use nil loggr loggr, _ := o.Get() klog.SetLogger(loggr) } // Get logger with LogFormat field func (o *Options) Get() (logr.Logger, error) { return logRegistry.Get(o.LogFormat) } </ins>

What would you like to be : As part of should add logging configuration allowing to change logging implementation. Things to implement: --logging-format - flag to pick between available implementations. Defaults to "text" using unchanged klog. LoggingConfig - structure storing component configuration for logging LogFormatRegistry - Used for registration of additional log formats. New formats should be registered by providing unique name and implementation of interface LoggingConfig.Complete method should configure klog by passing logr interface implementation into klog.SetLogger method Why is this needed: Subtask of /help /wg component-standard
The klog 1.0.0 version looks like no SetLogger method, should update klog version in vendor?
yes, forgot about that. I remember saying that it will require some changes, but shouldn't be to hard. I will help with it if needed.
/assign /remove-help
Klog was upgraded to v2.


Question: shouldContinueRunning: false, }, { <ins> predicateName: "ErrPodNotFitsHostPorts", </ins> podsOnNode: []*v1.Pod{ { Spec: v1.PodSpec{


Question: nt.tree[zone] = &nodeArray{nodes: []string{n.Name}, lastIndex: 0} } klog.V(5).Infof("Added node %v in group %v to NodeTree", n.Name, zone) <del> nt.NumNodes++ </del> <ins> nt.numNodes++ </ins> } // RemoveNode removes a node from the NodeTree.


Question: // +groupName=wardle.k8s.io // Package v1alpha1 is the v1alpha1 version of the API. <del> package v1alpha1 </del> <ins> package v1alpha1 // import "k8s.io/sample-apiserver/pkg/apis/wardle/v1alpha1" </ins>

Look at one of the directories under (Please don't pick more than one directory for one PR as it will cause issues for reviewers) Find all the files named (example find -name ) See the following link it has a this tells tools how this package needs to be imported. So we should ensure that each has an import Add a description appropriate to the package (similar to the one below) Look through sub directories and see if there are any other important directories that are likely to be used by outside users and add a Why are we doing this? We perfer to use vanity urls instead of directly using to refer to code, so this helps ensure that tools honor our wish. See It would be good to have some package level documentation since these directories under staging/ are meant to be for use by folks outside of kubernetes github org. /good-first-issue
/kind documentation /sig architecture
currently working my through Not going to use / assign since there could be a number of PRs for this issue.
/lifecycle active /good-first-issue edit: hmm..
This request has been marked as suitable for new contributors. 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 : /lifecycle active /good-first-issue 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
May I try on
IIUC this means that there needs to be a even at the root of the repo? Then how does work? :thinking:
Hi , can I make a PR for this directory ?
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or .


Question: // +groupName=wardle.k8s.io // Package v1alpha1 is the v1alpha1 version of the API. <del> package v1alpha1 </del> <ins> package v1alpha1 // import "k8s.io/sample-apiserver/pkg/apis/wardle/v1alpha1" </ins>

/lifecycle rotten
I guess this is still not done, was supposed to partially fix this issue. /reopen
Reopened this issue. <detailsIn response to : I guess this is still not done, was supposed to partially fix this issue. 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
/remove-lifecycle rotten /area code-organization


Question: }) framework.ExpectNoError(err, "while waiting for all CSI calls") <del> ginkgo.By("Waiting for PVC resize to finish") pvc, err = testsuites.WaitForFSResize(ctx, pvc, m.cs) framework.ExpectNoError(err, "while waiting for PVC to finish") </del> pvcConditions := pvc.Status.Conditions framework.ExpectEqual(len(pvcConditions), 0, "pvc should not have conditions") })

Seen in pull-kubernetes-e2e-gce-cos-alpha-features Specific job failure
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
from the error message I don't know if it refers to the sig-storage error or to the sig-auth one
/sig storage
/kind failing-test
/assign From : ... I am not sure if it's related:
is the culprit. cannot be used inside a . This only gets caught when the test actually runs, otherwise Ginkgo never sees the incorrect .
I don’t understand why sometimes it can get the pv by namebut sometimes it failed
but then is a sig-auth test , not storage , sorry /sig auth this seems that was recently in
/remove sig-storage
/assign /priority important-soon
/unassign
is still failed. seems not fixing the whole problem. /reopen feel free to close if the ci is green.
Reopened this issue. <detailsIn response to : is still failed. /reopen feel free to close if the ci is green. 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
the failure now looks like it is just a sig storage issue:
cc
/assign looks like the new test is still an issue
I think this line is the problem: When the test creates the object, it may take time for the PV to be provisioned and to be bound to the PVC. So you should do another before this call so you can get the latest PVC object with the bound PV.
I opened to get PVC again before using .
Only do PersistentVolumeClaims.Get() is not enough, whether we need to wait for sometimes to wait it bound? because sometimes the testcase is successful and sometime is failed.
If the Pod was able to run, then the PVC has to be bound.
so I can't understand why sometimes the testcase is successful and sometimes is failed.


Question: }) framework.ExpectNoError(err, "while waiting for all CSI calls") <del> ginkgo.By("Waiting for PVC resize to finish") pvc, err = testsuites.WaitForFSResize(ctx, pvc, m.cs) framework.ExpectNoError(err, "while waiting for PVC to finish") </del> pvcConditions := pvc.Status.Conditions framework.ExpectEqual(len(pvcConditions), 0, "pvc should not have conditions") })

By default, the DelayBinding is false, it will wait for PVC bound during creation. This is weird.
It waits for the claim to be bound, but the test case still needs to refresh its pvc object.
Because of the refresh is async, so after the pvc was bound, we need to get the pvc again, isn't it?


Question: import ( "crypto/tls" <ins> "fmt" </ins> "io/ioutil" "net/http" "net/http/httptest"

https://k8s- https://k8s- https://k8s- https://k8s- https://k8s- ... A lot of them /cc
/assign
Still see this failure after is merged, although less frequently: https://k8s- https://k8s- Reopen.
Looks like the client doesn't differentiate between 500 and 503 here: It should. Will open a fix shortly
opened
fix merged, will monitor https://k8s-
Thanks! :)
haven't seen this in the 12 hours since the fix merged, was seeing it every 2-3 hours before. /close


Question: metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" k8sruntime "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/util/wait" <ins> fake "k8s.io/client-go/kubernetes/fake" </ins> "k8s.io/client-go/kubernetes/scheme" restclient "k8s.io/client-go/rest" ref "k8s.io/client-go/tools/reference"

<!-- 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 wrote a test creating multiple isomorphic Events with an "". and stumbled upon a data race. The data race happens in the function. It seems that the Event Series field can be read and written at the same time by two different goroutines. . This seems to happen in only one scenario: (1) a singleton Event is created (2) an isomorphic Event is created (1) lock addition to cache (2) wait for the lock to be released (1) unlock (2) lock + the Series (1) the freshly created Series (1) singleton Event is now considered as a series That being said, this seems to lead to some data inconsistencies as the singleton Event would be created with an unexpected Series. <details<summaryData race</summary|================== WARNING: DATA RACE Write at 0x00c0001237a0 by goroutine 23: (eventBroadcasterImpl).recordToSink.func1.1() +0x536 (eventBroadcasterImpl).recordToSink.func1() +0x84 Previous read at 0x00c0001237a0 by goroutine 24: (Event).DeepCopyInto() +0x64 (Event).DeepCopy() +0x56 (Event).DeepCopyObject() +0x33 () +0xe8 (CreateActionImpl).DeepCopy() <autogenerated:1 +0xb7 (Fake).Invokes() +0x103 (FakeEvents).Create() +0x214 (EventSinkImpl).Create() +0x195 () +0x32c (eventBroadcasterImpl).attemptRecording() +0xe4 (eventBroadcasterImpl).recordToSink.func1() +0x9d Goroutine 23 (running) created at: (eventBroadcasterImpl).recordToSink() +0x159 (eventBroadcasterImpl).startRecordingEvents.func1() +0x75 (eventBroadcasterImpl).StartEventWatcher.func2() +0x91 Goroutine 24 (running) created at: (eventBroadcasterImpl).


Question: metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" k8sruntime "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/util/wait" <ins> fake "k8s.io/client-go/kubernetes/fake" </ins> "k8s.io/client-go/kubernetes/scheme" restclient "k8s.io/client-go/rest" ref "k8s.io/client-go/tools/reference"

recordToSink() +0x159 (eventBroadcasterImpl).startRecordingEvents.func1() +0x75 (eventBroadcasterImpl).StartEventWatcher.func2() +0x91 |================== |================== WARNING: DATA RACE Read at 0x00c0001236f0 by goroutine 23: (Event).DeepCopyInto() +0x64 (Event).DeepCopy() +0x72 () +0x4d () +0x98 (eventBroadcasterImpl).attemptRecording() +0xe4 (eventBroadcasterImpl).recordToSink.func1() +0x9d Previous write at 0x00c0001236f0 by goroutine 24: () +0x2e4 (eventBroadcasterImpl).attemptRecording() +0xe4 (eventBroadcasterImpl).recordToSink.func1() +0x9d Goroutine 23 (running) created at: (eventBroadcasterImpl).recordToSink() +0x159 (eventBroadcasterImpl).startRecordingEvents.func1() +0x75 (eventBroadcasterImpl).StartEventWatcher.func2() +0x91 Goroutine 24 (running) created at: (eventBroadcasterImpl).recordToSink() +0x159 (eventBroadcasterImpl).startRecordingEvents.func1() +0x75 (*eventBroadcasterImpl).StartEventWatcher.func2() +0x91 |================== </detailsWhat you expected to happen: No data race. How to reproduce it (as minimally and precisely as possible): You can run the following code snippet alongside any data race detector. I personally used . Anything else we need to know?: Environment: v0.25.0
/sig api-machinery
/assign Would you mind taking a look to this one? thanks!
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity.


Question: metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" k8sruntime "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/util/wait" <ins> fake "k8s.io/client-go/kubernetes/fake" </ins> "k8s.io/client-go/kubernetes/scheme" restclient "k8s.io/client-go/rest" ref "k8s.io/client-go/tools/reference"

If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-contributor-experience at . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close 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
We might also want to look into that again for /reopen /assign /unassign
/remove-lifecycle rotten
Reopened this issue. <detailsIn response to : We might also want to look into that again for /unassign 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
/cc
I was able to reproduce this issue with client-go v0.25.0. I updated the reproducer to be compatible with the latest version of the client and attached the data race trace.
are you gong to submit a fix for this one? thanks. /triage accepted
Yes, I am planning to submit a fix for this issue.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.


Question: metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" k8sruntime "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/util/wait" <ins> fake "k8s.io/client-go/kubernetes/fake" </ins> "k8s.io/client-go/kubernetes/scheme" restclient "k8s.io/client-go/rest" ref "k8s.io/client-go/tools/reference"

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]:
A PR is out to fix this issue: /remove-lifecycle stale


Question: <ins> /* Copyright 2019 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package azure_dd // about how to get all VM size list, // refer to https://github.com/kubernetes/kubernetes/issues/77461#issuecomment-492488756 var maxDataDiskCountMap = map[string]int64{ "BASIC_A0":               1, "BASIC_A1":               2, "BASIC_A2":               4, "BASIC_A3":               8, "BASIC_A4":               16, "STANDARD_A0":            1, "STANDARD_A10":           32, "STANDARD_A11":           64, "STANDARD_A1":            2, "STANDARD_A1_V2":         2, "STANDARD_A2":            4, "STANDARD_A2M_V2":        4, "STANDARD_A2_V2":         4, "STANDARD_A3":            8, "STANDARD_A4":            16, "STANDARD_A4M_V2":        8, "STANDARD_A4_V2":         8, "STANDARD_A5":            4, "STANDARD_A6":            8, "STANDARD_A7":            16, "STANDARD_A8":            32, "STANDARD_A8M_V2":        16, "STANDARD_A8_V2":         16, "STANDARD_A9":            64, "STANDARD_B1LS":          2, "STANDARD_B1MS":          2, "STANDARD_B1S":           2, "STANDARD_B2MS":          4, "STANDARD_B2S":           4, "STANDARD_B4MS":          8, "STANDARD_B8MS":          16, "STANDARD_D11":           8, "STANDARD_D11_V2":        8, "STANDARD_D11_V2_PROMO":  8, "STANDARD_D12":           16, "STANDARD_D12_V2":        16, "STANDARD_D12_V2_PROMO":  16, "STANDARD_D13":           32, "STANDARD_D13_V2":        32, "STANDARD_D13_V2_PROMO":  32, "STANDARD_D1":            4, "STANDARD_D14":           64, "STANDARD_D14_V2":        64, "STANDARD_D14_V2_PROMO":  64, "STANDARD_D15_V2":        64, "STANDARD_D16S_V3":       32, "STANDARD_D16_V3":        32, "STANDARD_D1_V2":         4, "STANDARD_D2":            8, "STANDARD_D2S_V3":        4, "STANDARD_D2_V2":         8, "STANDARD_D2_V2_PROMO":   8, "STANDARD_D2_V3":         4, "STANDARD_D3":            16, "STANDARD_D32S_V3":       32, "STANDARD_D32_V3":        32, "STANDARD_D3_V2":         16, "STANDARD_D3_V2_PROMO":   16, "STANDARD_D4":            32, "STANDARD_D4S_V3":        8, "STANDARD_D4_V2":         32, "STANDARD_D4_V2_PROMO":   32, "STANDARD_D4_V3":         8, "STANDARD_D5_V2":         64, "STANDARD_D5_V2_PROMO":   64, "STANDARD_D64S_V3":       32, "STANDARD_D64_V3":        32, "STANDARD_D8S_V3":        16, "STANDARD_D8_V3":         16, "STANDARD_DC2S":          2, "STANDARD_DC4S":          4, "STANDARD_DS11-1_V2":     8, "STANDARD_DS11":          8, "STANDARD_DS11_V2":       8, "STANDARD_DS11_V2_PROMO": 8, "STANDARD_DS12":          16, "STANDARD_DS12-1_V2":     16, "STANDARD_DS12-2_V2":     16, "STANDARD_DS12_V2":       16, "STANDARD_DS12_V2_PROMO": 16, "STANDARD_DS13-2_V2":     32, "STANDARD_DS13":          32, "STANDARD_DS13-4_V2":     32, "STANDARD_DS13_V2":       32, "STANDARD_DS13_V2_PROMO": 32, "STANDARD_DS1":           4, "STANDARD_DS14-4_V2":     64, "STANDARD_DS14":          64, "STANDARD_DS14-8_V2":     64, "STANDARD_DS14_V2":       64, "STANDARD_DS14_V2_PROMO": 64, "STANDARD_DS15_V2":       64, "STANDARD_DS1_V2":        4, "STANDARD_DS2":           8, "STANDARD_DS2_V2":        8, "STANDARD_DS2_V2_PROMO":  8, "STANDARD_DS3":           16, "STANDARD_DS3_V2":        16, "STANDARD_DS3_V2_PROMO":  16, "STANDARD_DS4":           32, "STANDARD_DS4_V2":        32, "STANDARD_DS4_V2_PROMO":  32, "STANDARD_DS5_V2":        64, "STANDARD_DS5_V2_PROMO":  64, "STANDARD_E16-4S_V3":     32, "STANDARD_E16-8S_V3":     32, "STANDARD_E16S_V3":       32, "STANDARD_E16_V3":        32, "STANDARD_E20S_V3":       32, "STANDARD_E20_V3":        32, "STANDARD_E2S_V3":        4, "STANDARD_E2_V3":         4, "STANDARD_E32-16S_V3":    32, "STANDARD_E32-8S_V3":     32, "STANDARD_E32S_V3":       32, "STANDARD_E32_V3":        32, "STANDARD_E4-2S_V3":      8, "STANDARD_E4S_V3":        8, "STANDARD_E4_V3":         8, "STANDARD_E64-16S_V3":    32, "STANDARD_E64-32S_V3":    32, "STANDARD_E64IS_V3":      32, "STANDARD_E64I_V3":       32, "STANDARD_E64S_V3":       32, "STANDARD_E64_V3":        32, "STANDARD_E8-2S_V3":      16, "STANDARD_E8-4S_V3":      16, "STANDARD_E8S_V3":        16, "STANDARD_E8_V3":         16, "STANDARD_F1":            4, "STANDARD_F16":           64, "STANDARD_F16S":          64, "STANDARD_F16S_V2":       32, "STANDARD_F1S":           4, "STANDARD_F2":            8, "STANDARD_F2S":           8, "STANDARD_F2S_V2":        4, "STANDARD_F32S_V2":       32, "STANDARD_F4":            16, "STANDARD_F4S":           16, "STANDARD_F4S_V2":        8, "STANDARD_F64S_V2":       32, "STANDARD_F72S_V2":       32, "STANDARD_F8":            32, "STANDARD_F8S":           32, "STANDARD_F8S_V2":        16, "STANDARD_G1":            8, "STANDARD_G2":            16, "STANDARD_G3":            32, "STANDARD_G4":            64, "STANDARD_G5":            64, "STANDARD_GS1":           8, "STANDARD_GS2":           16, "STANDARD_GS3":           32, "STANDARD_GS4-4":         64, "STANDARD_GS4":           64, "STANDARD_GS4-8":         64, "STANDARD_GS5-16":        64, "STANDARD_GS5":           64, "STANDARD_GS5-8":         64, "STANDARD_H16":           64, "STANDARD_H16M":          64, "STANDARD_H16M_PROMO":    64, "STANDARD_H16MR":         64, "STANDARD_H16MR_PROMO":   64, "STANDARD_H16_PROMO":     64, "STANDARD_H16R":          64, "STANDARD_H16R_PROMO":    64, "STANDARD_H8":            32, "STANDARD_H8M":           32, "STANDARD_H8M_PROMO":     32, "STANDARD_H8_PROMO":      32, "STANDARD_HB60RS":        4, "STANDARD_HC44RS":        4, "STANDARD_L16S":          64, "STANDARD_L16S_V2":       32, "STANDARD_L32S":          64, "STANDARD_L32S_V2":       32, "STANDARD_L4S":           16, "STANDARD_L64S_V2":       32, "STANDARD_L80S_V2":       32, "STANDARD_L8S":           32, "STANDARD_L8S_V2":        16, "STANDARD_M128-32MS":     64, "STANDARD_M128":          64, "STANDARD_M128-64MS":     64, "STANDARD_M128M":         64, "STANDARD_M128MS":        64, "STANDARD_M128S":         64, "STANDARD_M16-4MS":       16, "STANDARD_M16-8MS":       16, "STANDARD_M16MS":         16, "STANDARD_M208MS_V2":     64, "STANDARD_M208S_V2":      64, "STANDARD_M32-16MS":      32, "STANDARD_M32-8MS":       32, "STANDARD_M32LS":         32, "STANDARD_M32MS":         32, "STANDARD_M32TS":         32, "STANDARD_M64-16MS":      64, "STANDARD_M64-32MS":      64, "STANDARD_M64":           64, "STANDARD_M64LS":         64, "STANDARD_M64M":          64, "STANDARD_M64MS":         64, "STANDARD_M64S":          64, "STANDARD_M8-2MS":        8, "STANDARD_M8-4MS":        8, "STANDARD_M8MS":          8, "STANDARD_NC12":          48, "STANDARD_NC12_PROMO":    48, "STANDARD_NC12S_V2":      24, "STANDARD_NC12S_V3":      24, "STANDARD_NC24":          64, "STANDARD_NC24_PROMO":    64, "STANDARD_NC24R":         64, "STANDARD_NC24R_PROMO":   64, "STANDARD_NC24RS_V2":     32, "STANDARD_NC24RS_V3":     32, "STANDARD_NC24S_V2":      32, "STANDARD_NC24S_V3":      32, "STANDARD_NC6":           24, "STANDARD_NC6_PROMO":     24, "STANDARD_NC6S_V2":       12, "STANDARD_NC6S_V3":       12, "STANDARD_ND12S":         24, "STANDARD_ND24RS":        32, "STANDARD_ND24S":         32, "STANDARD_ND6S":          12, "STANDARD_NV12":          48, "STANDARD_NV12_PROMO":    48, "STANDARD_NV12S_V2":      24, "STANDARD_NV12S_V3":      12, "STANDARD_NV24":          64, "STANDARD_NV24_PROMO":    64, "STANDARD_NV24S_V2":      32, "STANDARD_NV24S_V3":      24, "STANDARD_NV48S_V3":      32, "STANDARD_NV6":           24, "STANDARD_NV6_PROMO":     24, "STANDARD_NV6S_V2":       12, "STANDARD_PB6S":          12, } </ins>

<!-- Please only use this template for submitting enhancement requests -- What would you like to be : related to Why is this needed: /assign /sig azure
here is the way about how to get MaxDataDiskCount: and then build kubelet, copy kubelet to agent node and then get MaxDataDiskCount data: There are 207 VM sizes totally.
Update: this command could get VM size list easily:


Question: stopCh := make(chan struct{}) fakeClientset := fake.NewSimpleClientset(&v1.PodList{Items: item.pods}) sort.Sort(item.expectedDeleteTimes) <del> controller := NewNoExecuteTaintManager(fakeClientset, getPodFromClientset(fakeClientset), (&nodeHolder{item.newNode}).getNode, getPodsAssignedToNode(fakeClientset)) </del> <ins> controller := NewNoExecuteTaintManager(fakeClientset, getPodFromClientset(fakeClientset), (&nodeHolder{node: item.newNode}).getNode, getPodsAssignedToNode(fakeClientset)) </ins> controller.recorder = testutil.NewFakeRecorder() go controller.Run(stopCh) controller.NodeUpdated(item.oldNode, item.newNode)

What happened: A Pod was scheduled for deletion because a taint w/ effect was observed in the Node the Pod was assigned to, and after the taint is removed from the Node, the Pod scheduled deletion isn't canceled. After scheduling pod deletion, the only cancels pod deletion if all taints are removed from the node, including any taints that the user relies on for their use-cases (example below). What you expected to happen: After the taint that triggered scheduling pod deletion is removed, cancels the scheduled pod deletion. How to reproduce it (as minimally and precisely as possible): A node is tainted w/ , so any workloads already assigned to it which don't tolerate this taint are evicted. A pod is created w/ tolerations: w/ unspecified and w/ . is assigned to . At some point in time after the previous steps took place, is tainted as . gets an update event for and observes two taints. It proceeds to calculate the minimum time (in seconds) that tolerates for the two taints which at this point is 300 seconds, and marks for deletion in ~300 seconds - this happens in-memory, in a timed-queue. At some point in time after the previous steps took place, and before the 300 seconds trigger happen, taint is removed from . gets an update event for and observes only one taint, . It proceeds to calculate the minimum time (in seconds) that tolerates for the this taint which is infinity, and returns, not canceling the previous deletion. It completely ignores the fact that the taint that triggered deletion is no longer observed. Anything else we need to know?: Worked w/ to figure this out after all pods in a node got evicted without apparent reason. Environment: Kubernetes version (use ): 1.17.3 (but looking at the code seems to affect all of 1.17.x and 1.18.x and master. Cloud provider or hardware configuration: N/A OS (e.g: ): N/A Kernel (e.g. ): 5.x Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A cc (owners of this code)
There seems to be at least .


Question: stopCh := make(chan struct{}) fakeClientset := fake.NewSimpleClientset(&v1.PodList{Items: item.pods}) sort.Sort(item.expectedDeleteTimes) <del> controller := NewNoExecuteTaintManager(fakeClientset, getPodFromClientset(fakeClientset), (&nodeHolder{item.newNode}).getNode, getPodsAssignedToNode(fakeClientset)) </del> <ins> controller := NewNoExecuteTaintManager(fakeClientset, getPodFromClientset(fakeClientset), (&nodeHolder{node: item.newNode}).getNode, getPodsAssignedToNode(fakeClientset)) </ins> controller.recorder = testutil.NewFakeRecorder() go controller.Run(stopCh) controller.NodeUpdated(item.oldNode, item.newNode)

You can sort of get a feel for what's going on here by looking at these two code snippets: This is what happens in when the node does not have any NoExecute taints: If you have any NoExecute taints on the node processPodOnNode gets called and this routine is really, really eager to evict pods. So : We are currently working around this issue by changing over our NoExecute taints to NoSchedule.
/sig scheduling node
/cc
/remove-sig scheduling scheduler isn't involved in this case.
Which SIG owns the controller-manager or is the node lifecycle manager (and its NoExecuteTaintManager) owned by sig-node alone?
I think node lifecycle is jointly owned by sig-node and sig-cloud-provider
API machinery owns the mechanics of the controller manager (controller loop setup and management), but the individual controllers are SIG-specific
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
Looks like we lost some momentum here and I'd like to avoid this falling into the abyss of bugs that never get fixed. When this bug is triggered the outcome is pretty terrible and once it does happen it is very difficult to dig into and understand what actually happened. Did we ever get this routed to the right owner?
adding sig-node leads for triage/routing. this seems like a clearly reproducible bug with significant correctness issues. /assign
thanks for the detailed report and reproducer. to help accelerate this, do you have a form of your reproducer we could add in the e2e suite (even if its failing initially)?
custom taints are considered disruptive, so it couldn't run in the main suite
It's been a while since I wrote tests for the e2e suite but if you are available over slack in case guidance is needed, I'm willing to put the effort.
Do all suites need to pass for a fix to be merged? I'd assume it is the case, otherwise how would a regression be prevented after the fix lands?


Question: stopCh := make(chan struct{}) fakeClientset := fake.NewSimpleClientset(&v1.PodList{Items: item.pods}) sort.Sort(item.expectedDeleteTimes) <del> controller := NewNoExecuteTaintManager(fakeClientset, getPodFromClientset(fakeClientset), (&nodeHolder{item.newNode}).getNode, getPodsAssignedToNode(fakeClientset)) </del> <ins> controller := NewNoExecuteTaintManager(fakeClientset, getPodFromClientset(fakeClientset), (&nodeHolder{node: item.newNode}).getNode, getPodsAssignedToNode(fakeClientset)) </ins> controller.recorder = testutil.NewFakeRecorder() go controller.Run(stopCh) controller.NodeUpdated(item.oldNode, item.newNode)

i was more inquiring if there was a test that could automate the reproduction, so even just a linked commit may be helpful for someone that wants to pick this up. i am happy to help if you want to reach out over slack later this week.
looks like a unit test could reproduce the issue, opened a WIP fix in
our code is not publicly accessible, I'm sorry. PR linked by seems to cover both the fix and the test that proves it.
/remove-lifecycle frozen
frozen keeps the bot from auto-closing
Ah, sorry then.


Question: <del> /* Copyright 2018 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package factory import "os" // compareSignal is the signal to trigger cache compare. For windows, // it's SIGINT. var compareSignal = os.Interrupt </del>

PLEASE COORDINATE WITH SIG-SCHEDULING BEFORE WORKING ON THIS ISSUE. We want to avoid the situation where two people accidentally start work on the same fix. Main tracking issue: Currently, the feature is set up at the end of in . This setup should be moved into its own helper function, preferably in the package. /sig scheduling /kind cleanup /help
/assign /remove-help
I'd like to take this one
/remove-help
the PR I sent should resolve this one. :disappointed: Are any of the others still available?


Question: "//pkg/api/pod:go_default_library", "//pkg/apis/extensions:go_default_library", "//pkg/apis/extensions/validation:go_default_library", <ins> "//vendor/k8s.io/api/apps/v1:go_default_library", </ins> "//vendor/k8s.io/api/apps/v1beta2:go_default_library", "//vendor/k8s.io/api/extensions/v1beta1:go_default_library", "//vendor/k8s.io/apimachinery/pkg/api/equality:go_default_library",

/priority failing-test /priority critical-urgent /sig apps This test case has been failing for a while and affects a number of jobs: This is affecting multiple jobs on the testgrid dashboard, and prevents us from cutting 1.9.0-alpha.2 (kubernetes/sig-release). Is there work ongoing to bring this job back to green?
All test failures look similar: . ~Is it due to network issue instead of DaemonSet?~
This seems related to the new DaemonSet. The connection refused error is happening because kube-apiserver is crashing:
needs an update
Ah, well... I guess it's halfway working as intended. We put that there to make the tests fail if we forgot to update it when adding a new version. We had hoped it would fail during presubmit tests though. :(
Sending a fix now
I wonder why the test is not failing on submit queue tests. Do i need to fix deployment and replicaset?
The rest of the group is not merged, and the v1 PR takes the selector mutability into account.
Since this bug crashes apiserver I'd expect it to affect many other e2e tests.
Noted, we need to fix deployment and replicaset when the v1 PR is merged.
Not quite sure how this test isn't failing before but is now consistently failing. I'd expect the commit that triggers this to block the submit queue. The e2e test is still accessing DaemonSet through extensions/v1beta1 endpoints. From the above apiserver log it's hard to tell what updates DaemonSet via apps/v1 before the code panics. I tried to reproduce it locally, and found that garbage collector PUT apps/v1 DaemonSet:
When apps/v1 gets introduced, it may be ordered before apps/beta1 alphabetically. IIRC, there is a code change on the apps/v1 PR that changes the order of API versions such that apps/v1 is ranked before apps/v1beta2 and apps/v1beta2 before apps/v1beta1. Perhaps this problem can be fixed when the PR merges.
Since crashes apiserver and makes debugging harder, which defeats the purpose of using it, we should return error on unsupported versions instead.
The first run with this change is still in progress, but this test already passed: https://k8s- Thanks for the quick fix


Question: VolumeSelectorKey = "e2e-pv-pool" ) <ins> var ( // Common selinux labels SELinuxLabel = &v1.SELinuxOptions{ Level: "s0:c0,c1"} ) </ins> // Map of all PVs used in the multi pv-pvc tests. The key is the PV's name, which is // guaranteed to be unique. The value is {} (empty struct) since we're only interested // in the PV's name and if it is present. We must always Get the pv object before

It would better to have e2e for iSCSI persistent volume. /sig storage
/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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close


Question: } // Create corresponding write and read commands <del> // to be executed inside containers with local PV attached </del> <ins> // to be executed via SSH on the node with the local PV </ins> func createWriteAndReadCmds(testFileDir string, testFile string, writeTestFileContent string) (writeCmd string, readCmd string) { testFilePath := filepath.Join(testFileDir, testFile) writeCmd = fmt.Sprintf("mkdir -p %s; echo %s > %s", testFileDir, writeTestFileContent, testFilePath)

8 tests failed, 2 jobs failed, 88 builds failed. Failure stats cover 1 day time range '3 Aug 2017 03:31 UTC' to '4 Aug 2017 03:31 UTC'.
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 storage
This should have been fixed by /cc
The test panic is fixed, but now it's failing because it can't SSH into the node.
/assign


Question: with one container running the specified image. release: v1.9 file: test/e2e/kubectl/kubectl.go <ins> - testname: Kubectl, server-side dry-run Pod codename: '[sig-cli] Kubectl client Kubectl server-side dry-run should check if kubectl can dry-run update Pods [Conformance]' description: The command 'kubectl run' must create a pod with the specified image name. After, the command 'kubectl replace --dry-run=server' should update the Pod with the new image name and server-side dry-run enabled. The image name must not change. release: v1.19 file: test/e2e/kubectl/kubectl.go </ins> - testname: Kubectl, version codename: '[sig-cli] Kubectl client Kubectl version should check is all data is printed  [Conformance]'

and server-side dry-run are being promoted to stable features in 1.18. Conformance should ensure that cloud providers support these features. As a user, I expect to work, which requires that cloud providers for cloud default webhooks. Conformance would generally avoid cloud-specific issues like this one: This suggestion is from /area conformance
/sig testing /sig architecture
/wg apply
There are some good references for conformance tests in the conformance meeting notes:
once merges, we need to promote the e2e test to conformance in a follow up PR, in accordance to this doc: It seems like we meet the conformance test requirements. Here's the process specifically, which includes sig-arch and a review board group:


Question: return stats, nil } <ins> func fetchContainerStats(c hcsshim.ContainerProperties) (stats hcsshim.Statistics, err error) { var ( container hcsshim.Container ) container, err = hcsshim.OpenContainer(c.ID) if err != nil { return } defer func() { if closeErr := container.Close(); closeErr != nil { if err != nil { err = fmt.Errorf("failed to close container after error %v; close error: %v", err, closeErr) } else { err = closeErr } } }() return container.Statistics() } </ins> // hcsStatsToNetworkStats converts hcsshim.Statistics.Network to statsapi.NetworkStats func hcsStatsToNetworkStats(timestamp time.Time, hcsStats []hcsshim.NetworkStats) *statsapi.NetworkStats { result := &statsapi.NetworkStats{

<!-- 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: 's memory usage is increasing over time. When more pods are run, it increases even more. What you expected to happen: it should not keep increasing How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.14.0 Cloud provider or hardware configuration: AKS OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: !
/sig windows /sig azure
/assign


Question: // An underlying storage.Versioner. Versioner Versioner <del> // Whether to serve Lists from in-memory cache. // // NOTE: DO NOT SET TO TRUE IN PRODUCTION CODE! ListFromCache bool </del> // The Cache will be caching objects of a given Type and assumes that they // are all stored under ResourcePrefix directory in the underlying database. Type           interface{}

The label(s) cannot be applied. These labels are supported: <detailsIn response to : This one is trying to use with a generator to create an rc. This was deprecated and now is removed, so the test is failing now. /label sig/undefined 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
/label failing-test
The label(s) cannot be applied. These labels are supported: <detailsIn response to : /label failing-test 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
/kind failing-test
At first I thought this was because generators were removed from . That still might be the cause of this, but I'm not 100% sure off-hand.
/sig cli
/assign
Funny thing about this is if you look in the build logs it is not immediately obvious that it is caused by generators being removed from because actually has sort of an unexpected behavior, where it tells you it is deprecated and gives you a pod instead... For example: Output:
/reopen should fix this is one of the affected jobs
Reopened this issue. <detailsIn response to : /reopen should fix this 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
Since it's been a few weeks, I wanted to provide an update on this. I'm still waiting to confirm this is resolved by It looks like it is still running the old tests not marked as . Since 1.17.9 was released 14 days ago, and k8s-ci-robot only merged the PR 13 days ago, I'm guessing we need to wait until there is a 1.17.10 to see it skip the deprecated tests.
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
Stale issues rot after 30d of inactivity.


Question: // An underlying storage.Versioner. Versioner Versioner <del> // Whether to serve Lists from in-memory cache. // // NOTE: DO NOT SET TO TRUE IN PRODUCTION CODE! ListFromCache bool </del> // The Cache will be caching objects of a given Type and assumes that they // are all stored under ResourcePrefix directory in the underlying database. Type           interface{}

Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close 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


Question: } g.Do(""$.$",", k) } <ins> g.Do("},n", nil) if err := g.generateExtensions(t.CommentLines); err != nil { return err } g.Do("},n", nil) } return nil } func (g openAPITypeWriter) generateExtensions(CommentLines []string) error { tagValues := getOpenAPITagValue(CommentLines) anyExtension := false for _, val := range tagValues { if strings.HasPrefix(val, tagExtensionPrefix) { if !anyExtension { g.Do("spec.VendorExtensible: {nExtensions: spec.Extensions{n", nil) anyExtension = true } parts := strings.SplitN(val, ":", 2) if len(parts) != 2 { return fmt.Errorf("Invalid extension value: %v", val) } g.Do(""$.$": ", parts[0]) g.Do(""$.$",n", parts[1]) } } if anyExtension { </ins> g.Do("},n},n", nil) } return nil

Background: kubectl and the Kubernetes reference docs both depend on the spec to operate on Kubernetes resources. The lacks important information required by kubectl and the docs. Usecase: kubectl can identify the patchStrategy and mergeKey for resource fields kubectl can identify the columns to print for on resources docs can parse and display the default value for fields docs can identify top-level objects Solution: Add items to the comment tag: Example: The long term plan is to remove the and struct tags once all code has been updated to use the swagger spec instead. Until then, comments should be for the struct tags and . Some verification process will need to be written to make sure the struct tags and comments remain in sync.
I think this wouldn't fall under sig-apps. cc
I would not do the columns stuff - we're moving get to the server side. Top level objects is already available in some form by the client - specifically the list that we use (should use) to get the swagger doc tells us what the top level type is (or is that for something like explain). Merge key, patch strategy, default values all belong as "real" attributes, although we had not necessarily intended those to be arguments to k8s:openapi-gen, but actual tags in their own right (like "+optional")
Thanks Is there a design proposal / eta for this? This is for generating the docs from swagger. Right now the list of top level resources for the docs to display is hardcoded in a . I would like to move the majority of the metadata out of the config file so that: same tool can generate reference docs for federated apiservers without writing a custom config. don't need to manually maintain and update the config for each release - e.g. adding new types I have no strong opinion about this as long as they appear in the swagger so it is possible right tools the can use this data. Can you comment on why openapi-gen vs specific tags?
Describe in the server makes sense to me. IIUC, just prints out a set of columns. Was the idea that the server would just print out the columns or return a list of column / values or something more complicated? No need to answer if it is in the issue / proposal already.


Question: } g.Do(""$.$",", k) } <ins> g.Do("},n", nil) if err := g.generateExtensions(t.CommentLines); err != nil { return err } g.Do("},n", nil) } return nil } func (g openAPITypeWriter) generateExtensions(CommentLines []string) error { tagValues := getOpenAPITagValue(CommentLines) anyExtension := false for _, val := range tagValues { if strings.HasPrefix(val, tagExtensionPrefix) { if !anyExtension { g.Do("spec.VendorExtensible: {nExtensions: spec.Extensions{n", nil) anyExtension = true } parts := strings.SplitN(val, ":", 2) if len(parts) != 2 { return fmt.Errorf("Invalid extension value: %v", val) } g.Do(""$.$": ", parts[0]) g.Do(""$.$",n", parts[1]) } } if anyExtension { </ins> g.Do("},n},n", nil) } return nil

is the bigger issue that touches on a rough overview, I can't find my rambling brain dump of the problem, but get would be rough tabular json, you could also get that as csv, and describe could be a richer but not quite full structured key/value structure.
regarding tags, they do not need to be in the same k8s:openapi-gen tag, it can be repeated: they can also be separate tags but still general like this: The idea is to have a general way to add arbitrary extension to a type so we don't need to change code generator for each specific tag. I have no strong feeling about the format, but I would like it to be general vs tags like +optional. The difference is +optional is a defined tag in OpenAPI () but extensions does not have any meaning for code generator. They better to be general so generate can pass them without change.
No, I mean we should define conventions in our API code that match the intent (optional) rather than have tons and tons of repeated code that is setting x-kubernete-describe-columns (or similar)
I spent some time thinking about your comments last night. I don't think this is mutually exclusive with , and could be complementary. IMHO this is general metadata associated with the type, and including it in the doesn't preclude supporting an api endpoint that pre-parses and formats the data. However, including it in the swagger does allow clients using the swagger to take advantage of it. Following is an example of where the swagger would be useful even if get was in the sever. A generated Java client could use the display columns for the "toString" method of the resource. Another use case that had mentioned to me was to allow some kubectl commands to operate on directly on local files. e.g. (strawman) could print the columns. I don't think we want to do this now, but it is an example of why keeping this object metadata private to the server limits what we can do. My hope is that this swagger tags solution will also oprove portable to easily work with ThirdPartyResources as well by writing the display-columns as an annotation on the TPR and keeping the same format. is a can of worms, and I would agree that the solution is capable of providing a richer experience for aggregating information across multiple resource types - e.g.


Question: } g.Do(""$.$",", k) } <ins> g.Do("},n", nil) if err := g.generateExtensions(t.CommentLines); err != nil { return err } g.Do("},n", nil) } return nil } func (g openAPITypeWriter) generateExtensions(CommentLines []string) error { tagValues := getOpenAPITagValue(CommentLines) anyExtension := false for _, val := range tagValues { if strings.HasPrefix(val, tagExtensionPrefix) { if !anyExtension { g.Do("spec.VendorExtensible: {nExtensions: spec.Extensions{n", nil) anyExtension = true } parts := strings.SplitN(val, ":", 2) if len(parts) != 2 { return fmt.Errorf("Invalid extension value: %v", val) } g.Do(""$.$": ", parts[0]) g.Do(""$.$",n", parts[1]) } } if anyExtension { </ins> g.Do("},n},n", nil) } return nil

how describing Nodes fetches Pod information. I still think that the solution is compatible with the richer solution you proposed and there is not much additional cost in doing it. Howv What would you think of supporting a set of optional ALPHA extensions for "display-columns" and "describe-columns" allowing any consumers of the swagger to print the objects. In theory it could also be used by the UI to provide a summary view without having to do separate lookups. As an ALPHA feature we could try it for supporting sig-service-catalog and revisit it in 1.7. If we consider it successful, the solution outlined in could become another consumer of the display-columns tag? I like this approach. My biggest concern here is being able to get this into 1.6. Since kubectl supports +/-1 version skew, we need will need to maintain the old logic for at least 1 full release after we add support for the new swagger based logic. That puts us at 6 months from now to fully migrate if we don't have any swagger extensions in 1.6.
I think that's a nice to have in the long run - but then people will say "why are the columns different when the server prints them from the local print"? And most of the pod columns in no way can represent the full complexity of what they print with swagger, so the best effort local printing is going to be really, really, really best effort. Also, local print is a really specialized case - if we just did the generic metadata print that would probably be ok. So while I agree it's valid, it seems like a lot of work for very little practical value. Again, not opposed, just don't want to do two things halfway and then have nothing. So just biased towards not adding more client complexity in the near term. So you want to hack this in for service catalog in 1.6 on TPR? I feel like that's a lot of hacks - the generic printer stuff at least gives you name and namespace, and I'd rather do nothing in 1.7 for generic client printer rather than jump ahead. I won't stop you if you want to spend time and effort on it, but it's a lot of specialized work that will then be neglected while we do the server side stuff.


Question: } g.Do(""$.$",", k) } <ins> g.Do("},n", nil) if err := g.generateExtensions(t.CommentLines); err != nil { return err } g.Do("},n", nil) } return nil } func (g openAPITypeWriter) generateExtensions(CommentLines []string) error { tagValues := getOpenAPITagValue(CommentLines) anyExtension := false for _, val := range tagValues { if strings.HasPrefix(val, tagExtensionPrefix) { if !anyExtension { g.Do("spec.VendorExtensible: {nExtensions: spec.Extensions{n", nil) anyExtension = true } parts := strings.SplitN(val, ":", 2) if len(parts) != 2 { return fmt.Errorf("Invalid extension value: %v", val) } g.Do(""$.$": ", parts[0]) g.Do(""$.$",n", parts[1]) } } if anyExtension { </ins> g.Do("},n},n", nil) } return nil

My intend here was avoiding repeated code for adding each of these tags somewhere (in openapi-gen code or some root level place). Let me distinguish these tags in two categories with respect to OpenAPI code generator: that need some sort of processing that affects OpenAPI spec (e.g. +optional removes the field from OpenAPI field) that need no more processing and will be directly put into OpenAPI spec (e.g. +gvk that we don't have but we can define as a way to define Group/Version/Kind of an object vs register method) My argument is about the second one. I think patch strategy here falls into this category. The question is only about naming it. Naming Option 1: +patch-strategy=... This looks cleaner but we need to define an alias somewhere to tell generator this is the same as x-kubernetes-patch-strategy. The alias definition and the tags are in two places. Putting them in the generator code make the code non-generic and we don't want to do that. Putting these aliases somewhere as an argument to the generator begs for bugs as people that look at the type and add this tag to their types need to know (maybe by reading a doc, but who do that) that it needs to pass the alias to the generator. I, in 6 month, will look at a type and see a tag and copy the tag to my type and expect it to work that will not with this option. Naming Option 2: use something generic for these type of tags. after all generator does not need to do any processing. I suggest +openapi-tag:tag=value that will result in "x-kubernetes-tag: value" in OpenAPI spec. There is no alias defined anywhere and without any code change or alias copying or any knowledge about passing any argument, a tag can be to OpenAPI spec. The value of these tags and their use cases are outside of the scope of what I am arguing about. Anyway a solution is better than no solution, I would suggest we continue with Option 2 as Alpha and change it later if we see fit. Adding an aliasing mechanism to this option later should be easy.
On patch strategy, I had assumed we'd read the value from what's in the struct tag, rather than requiring a net new tag?


Question: } g.Do(""$.$",", k) } <ins> g.Do("},n", nil) if err := g.generateExtensions(t.CommentLines); err != nil { return err } g.Do("},n", nil) } return nil } func (g openAPITypeWriter) generateExtensions(CommentLines []string) error { tagValues := getOpenAPITagValue(CommentLines) anyExtension := false for _, val := range tagValues { if strings.HasPrefix(val, tagExtensionPrefix) { if !anyExtension { g.Do("spec.VendorExtensible: {nExtensions: spec.Extensions{n", nil) anyExtension = true } parts := strings.SplitN(val, ":", 2) if len(parts) != 2 { return fmt.Errorf("Invalid extension value: %v", val) } g.Do(""$.$": ", parts[0]) g.Do(""$.$",n", parts[1]) } } if anyExtension { </ins> g.Do("},n},n", nil) } return nil

, Mehdy Bohlool <:
The get stuff is less urgent for me as long as we aren't doing even more hacky things to work around the current limitations, and can make a commitment to delivering it in a specific release (sounds like 1.7). For service catalog there was a plan to fork kubectl, compile the service catalog types into the binary, and provide the fork as a separate binary. I have some concerns with this approach. I would rather provide a temporary hack in the code that can provide a consistent user experience from day one and re-implement later vs having users get used to downloading separate binaries for each aggregated apiserver. I have no plans to do any work for on this for the core Kubernetes types, and can punt on it until the scope of the work is understood to be relatively small and easily upgraded to the server-side get.


Question: } }() } <ins> // nodeResourceString returns a string representation of node resources. func nodeResourceString(n *v1.Node) string { if n == nil { return "N/A" } return fmt.Sprintf("Capacity: %s; Allocatable: %s.", resourceString(&n.Status.Capacity), resourceString(&n.Status.Allocatable)) } func resourceString(r *v1.ResourceList) string { return fmt.Sprintf("CPU<%s>|Memory<%s>|Pods<%s>|StorageEphemeral<%s>", r.Cpu().String(), r.Memory().String(), r.Pods().String(), r.StorageEphemeral().String()) } </ins>

<!-- Please only use this template for submitting enhancement requests --What would you like to be : 1) Increase the log level of info logs to "v=2" when the scheduler or a node from its cache. 2) Increase the log level of info logs to "v=2" when the scheduler can't schedule a pod , , and add a log message for 2) report memory/cpu status of . Why is this needed: With cluster autoscaler now being used in production by some vendors, we want to have more visibility to events that could be related to the auto scaler to help debug customer issues. /sig scheduling /priority important-soon /assign
GitHub didn't allow me to assign the following users: congliu01. 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 : <!-- Please only use this template for submitting enhancement requests --1) Increase the log level of info logs to "v=2" when the scheduler or a node from its cache. 2) report memory/cpu status of . Why is this needed: With cluster autoscaler now being used in production by some vendors, we want to have more visibility to events that could be related to the auto scaler to help debug customer issues. /priority important-soon /assign </details
will consider this assigned to you.
/assign


Question: loadBalancer = createResponse.LoadBalancers[0] // Create Target Groups <del> addTagsInput := &elbv2.AddTagsInput{ ResourceArns: []*string{}, Tags:         []*elbv2.Tag{}, } </del> <ins> resourceArns := make([]*string, 0, len(mappings)) </ins> for i := range mappings { // It is easier to keep track of updates by having possibly

<!-- 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!--What happened: We created a LoadBalancer service with type 'nlb' with two listeners forwarding traffic on two different ports. The service was created correctly along with the target groups and was functionning correctly. Around 20 hours later, no traffic was flowing from clients to any k8s nodes. While troubleshooting we discovered that the k8s node instance security group was lacking the input rules allowing traffic to the node ports for this LB. We deleted the service and recreated it. The service started working normally again, but we found out that the two target groups were missing their k8s tags. The logs contain the following error: What you expected to happen: We expected the NLB target groups to have k8s tags, so that k8s could remember it created them. How to reproduce it (as minimally and precisely as possible): Create a k8s service with NLB: Add a simple deployment that is matched by this service. Anything else we need to know?: Looking at AWS cloudtrail we could see the following error event: So the API request was called with two Resource ARNs, which is confirmed by the code: Since we have two target groups, there are two resources to tag. Except that the AWS API while allowing to send more than one resource ARNs doesn't allow it returning a validation error. This could be solved by doing one per target groups. Note that this can't happen on a Classic LB because there's no target groups.


Question: loadBalancer = createResponse.LoadBalancers[0] // Create Target Groups <del> addTagsInput := &elbv2.AddTagsInput{ ResourceArns: []*string{}, Tags:         []*elbv2.Tag{}, } </del> <ins> resourceArns := make([]*string, 0, len(mappings)) </ins> for i := range mappings { // It is easier to keep track of updates by having possibly

I believe that those missing tags on the target groups are the root cause of the deletion of the security group rules allowing traffic to reach the nodeports, with this (hypothetical and unproved) scenario: 8s creates the target groups, the NLB, the listeners, the sg input rules 8s fails to tag the target groups, but doesn't rollback anything a subsequent convergence loops, k8s notices that there are two k8s-managed Security Group input rules, but those don't match any Target Groups or match Target Groups that are not managed by k8s (because they don't have the owner tags) 8s deletes those rules Unfortunately we don't see the rule deletion in the controller manager logs, but it appears in Cloudtrail: Let me know if you have any questions, Environment: Kubernetes version: 1.10.7 Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): CoreOS 1967.3.0 Kernel (e.g. ): Linux 4.14.88-coreos Install tools: home grown Others:
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
/sig aws /assign
Hi, the root cause of your problem should already be solved by It's cherry-picked into old versions and available as v1.11.7, v1.12.5 and v1.13.3(hasn't released yet)
, Thanks, you're most certainly right about the root cause of the issue being . It indeed looks exactly like what we've experienced. Still there's the problem of target groups not being tagged.


Question: pluginDir: pluginDir, watcher:   watcher, fs:        fs, <del> factory:   fakePluginFactory{error: true}, </del> <ins> factory:   fakePluginFactory{errorDriver: driverName}, </ins> } installDriver(driverName, fs) prober.Init()

When kubelet is running if you create two volume plugin directories here: /usr/libexec/kubernetes/kubelet-plugins/volume/exec /usr/libexec/kubernetes/kubelet-plugins/volume/exec/cifs /usr/libexec/kubernetes/kubelet-plugins/volume/exec/nodeagent~uds You will see these expected logs: Now if you copy over the cifs plugin file to cifs directory and then copy the uds plugin the errors go away. The pods using the uds volume will function but any pods attempting to use the cifs volume will fail with the following error from kubelet: desiredStateOfWorld. err=failed to get Plugin from volumeSpec for volume "pv" err=no volume plugin matched Restarting kubelet fixes this problem as then both plugins are present and properly . A functional volume plugin should be to kubelet even if another volume plugin is missing or invalid. Fixing the invalid volume plugin currently only adds the one that was invalid and fixed and other valid plugins that were previously present are skipped. Start kubelet service on a node. Create two directories for two flex volume plugins in the /usr/libexec/kubernetes/kubelet-plugins/volume/exec/ directory. Eg. nodeagent~uds and cifs Kubelet logs will now start complaining that the plugins are missing. Add the files to the plugin folders and then start a pod using the plugin. Notice that only the last plugin file copied is available to be used by pods. The first plugin will generate this error if used by a volume "err=no volume plugin matched" Performing a touch on the folder of the missing plugin will cause kubelet to properly index it. <details</details<detailsLocal kube cluster </details<details</details<details</details<details</details<details</details
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 k8s-infra
/sig storage /remove-sig k8s-infra


Question: ) func TestTokenAuthenticator(t *testing.T) { <ins> now := metav1.Now() </ins> tests := []struct { name string

Resources can be deleted, but still exist in the API before they are reaped. They should not be valid during this time.
I'll add this to my pile. Thanks for filing :+1: FYI
FYI as well


Question: <ins> .generated_docs admin/ man/ user-guide/ yaml/ </ins>

Instead, have a presubmit test that verifies that the docs can be generated. This will reduce the number of conflicts & rebases, therefore increase speed through the queue. Confirmed with that nothing depends on these docs at the moment. fyi, some manual process might have to change once this is in.
Yes, we want to generate the docs into , anyway. cc
Excellent. One closer step to YAML generation, I hope. :)
was interested in working on this.
Want to get started on this?
is this still a goal of ours?
I've seen a thread this week-end about that. I think docs have moved but we still need to generate them there.
can this issue be closed then?
related to ?
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. Prevent issues from auto-closing with an comment. 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 /lifecycle frozen There's still cruft in the docs directory.
/remove-help I don't think this meets . Please add back via if I'm incorrect
/sig docs /sig release /remove-area test-infra /area build-release /area kubeadm /area kubectl All of the following dirs/files have the following content. Do we need them? This file is autogenerated, but we've stopped checking such files into the repository to reduce the need for rebases. Please run hack/generate- to populate this file. docs/admin: .md files for kube components and kubeadm commands man/man1: .1 files for same user-guide/kubectl: .md files for kubectl commands yaml/kubectl: .yaml files for kubectl commands
/help Now that we have /good-first-issue, I think this does meet the criteria for help wanted. Probably need to talk to someone from sig-docs and figure out if/how these are used.
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.


Question: <ins> .generated_docs admin/ man/ user-guide/ yaml/ </ins>

<detailsIn response to : /help Now that we have /good-first-issue, I think this does meet the criteria for help wanted. Probably need to talk to someone from sig-docs and figure out if/how these are used. 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
/remove-priority important-soon /priority important-longterm This hasn't been committed to for any release cycle in a while. I hope someone does commit to it, but I personally cannot, so I'm bumping down to the "hopefully next time" priority. /kind cleanup in addition to docs This impacts merge velocity of any kubectl/kubeadm changes because the docs/OWNERS file is small. We're going to work around by adding OWNERS files for the relevant sigs to the relevant dirs. But if these files don't have to exist in the first place, that'd be even better.
as discovered today this would not work as OWNERS in sub-folders do not solve the problem with the /docs/.generated_docs file which is in the parent folder. i've been looking into a solution to remove the placeholders completely and make verify-docs only consist of kube::util::gen-docs. this will: ensure that godoc errors and such still block presubmits the contributors are not blocked having to commit placeholder files
/lifecycle active
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 /lifecycle active as PR is still in flight.


Question: } } <del> var insecurePort = 8081 </del> <ins> var insecurePort = 8082 </ins> var serverIP = fmt.Sprintf("http://localhost:%v", insecurePort) var groupVersion = fed_v1a1.SchemeGroupVersion

Not much info on why or how it failed. cc
Cc On Apr 28, 2016 5:08 PM, "Mike Danese" wrote:
cc
cant open the link, would you mind paste the content?
can you access http://ci- ?
It failed due to bind address already in use. The same address were used in example/apiserver (which runs befor federated-apiserver) as well. I wonder if the tests are run in parallel? If it is the case, I can change the port to other values (8082 for example) Otherwise, it may indicate that the address:port was not proper released for some reason
Yes, tests run in parallel. Can you perhaps use a random port number each time? This will reduce the probability of collision to nearly zero (close enough to zero for practical purposes). See . also provides other background reading, but is focussed on end-to-end tests. Much of the discussion applies to unit tests also though.
I think changing the Insecure Port at from 8081 to some other value (say, 8082) should be fine.
Which should I use? 8082 or random? Personally I wouldn't be so optimistic about using random port number since no matter how small the probability is, it will happen eventually, which would be a surprise to those who's not aware of this.
Yes I am fine with changing the port to 8082. Feel free to send me the PR for review.
If you specify port 0 when you bind, the kernel will hand you an available port so there won't be a conflict.
We also want to know the port to be able to curl it in the test.


Question: return nil, err } <ins> for i := range table.Rows { row := &table.Rows[i] if row.Object.Raw == nil || row.Object.Object != nil { //if row already has Object.Object //we don't change it continue } converted, err := runtime.Decode(unstructured.UnstructuredJSONScheme, row.Object.Raw) if err != nil { //if error happens, we just continue continue } row.Object.Object = converted } </ins> return table, nil }

<!-- 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: namespace disappears in the output of What you expected to happen: namespace exists How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: It is related to Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig cli


Question: // Get returns the election record from a ConfigMap Annotation func (cml *configMapLock) Get(ctx context.Context) (*LeaderElectionRecord, []byte, error) { var record LeaderElectionRecord <del> var err error cml.cm, err = cml.Client.ConfigMaps(cml.ConfigMapMeta.Namespace).Get(ctx, cml.ConfigMapMeta.Name, metav1.GetOptions{}) </del> <ins> cm, err := cml.Client.ConfigMaps(cml.ConfigMapMeta.Namespace).Get(ctx, cml.ConfigMapMeta.Name, metav1.GetOptions{}) </ins> if err != nil { return nil, nil, err } <ins> cml.cm = cm </ins> if cml.cm.Annotations == nil { cml.cm.Annotations = make(map[string]string) }

The lock acquired by tryAcquireOrRenew is released when the leader ends leadership. However, due to the cancellation of the context, the lock may be set as an empty lock, so the Update cannot be run normally, resulting in a failure to release the lock. The lock can be released every time the leader ends. run this: and then you can got a log like these: and you when you watch the leases at the same time: you can see that was failed to release because of No response <details</details<details</details<details</details<details</details<details</detailsrelated packages: v1.3.0 v0.25.0 v0.25.0 v2.70.1
/sig api-machinery
/triage accepted thanks!
/unassign
/assign
/unassign
/unassign me


Question: t.Errorf("expect response HTTP header Connection to be empty, but got: %s", v) } } <ins> // TestGOAWAYConcurrency tests GOAWAY frame will not affect concurrency requests in a single http client instance. // Known issues in history: https://github.com/kubernetes/kubernetes/issues/91131. func TestGOAWAYConcurrency(t *testing.T) { s, err := newTestGOAWAYServer() if err != nil { t.Fatalf("failed to set-up test GOAWAY http server, err: %v", err) } s.StartTLS() defer s.Close() client, err := newGOAWAYClient(nil) if err != nil { t.Fatalf("failed to set-up client, err: %v", err) } const ( requestCount = 300 workers      = 10 ) expectWatchers := 0 urlsForTest := []string{urlGet, urlPost, urlWatch, urlGetWithGoaway, urlPostWithGoaway, urlWatchWithGoaway} urls := make(chan string, requestCount) for i := 0; i < requestCount; i++ { index := rand.Intn(len(urlsForTest)) url := urlsForTest[index] if url == urlWatch || url == urlWatchWithGoaway { expectWatchers++ } urls <- url } close(urls) wg := &sync.WaitGroup{} wg.Add(workers) watchers := make(chan (<-chan watchResponse), expectWatchers) for i := 0; i < workers; i++ { go func() { defer wg.Done() for { url, ok := <-urls if !ok { return } w, err := requestGOAWAYServer(client, s.URL, url) if err != nil { t.Errorf("failed to request %q, err: %v", url, err) } if w != nil { watchers <- w } } }() } wg.Wait() // check if watch request is broken by GOAWAY frame watchTimeout := time.NewTimer(time.Second * 10) defer watchTimeout.Stop() for i := 0; i < expectWatchers; i++ { var watcher <-chan watchResponse select { case watcher = <-watchers: default: t.Fatalf("expect watcher count: %d, but got: %d", expectWatchers, i) } select { case watchResp := <-watcher: if watchResp.err != nil { t.Fatalf("watch response got an unexepct error: %v", watchResp.err) } if !reflect.DeepEqual(responseBody, watchResp.body) { t.Fatalf("in-flight watch was broken by GOAWAY frame, expect response body: %s, got: %s", responseBody, watchResp.body) } case <-watchTimeout.C: t.Error("watch receive timeout") } } } </ins>

What happened: We enabled feature in our large-scale cluster, and we found client(Kubelet) may got error(500 http code response) like after received GOAWAY frame. I had already re-produce this bug and open an in golang repo. So far I think this bug only occur with a small probability when client request server in high concurrency use a same httpclient instance, and it's a golang sdk bug in http client. Before I solved this issue, I suggest do NOT enable GOAWAY() feature. As it's a golang sdk bug(currently I known and doubt) in http client, revert GOAWAY feature(codes) is not necessary.
cc
/sig api-machinery
Thanks for the report.
Based on not setting the field, I think it defaults that way, so that's good. We will leave the option and filter so that when golang updates its client, we will have a simple way to turn it on and execute it.
Sure. I am trying to fix the golang http client issue and will update progress at . After golang http client issue fixed, I will add more concurrent test cases to see if there are any other bugs may occur by GOAWAY feature. BTW, we still enable GOAWAY feature in our production cluster, because there is no any evidence told us this error will influence SLO, as all most components(kubelet, controller-manager, scheduler) is controller work mode and will re-try after got error. /assign
Golang version or required, which will release at 07/01/2020.
Kubernetes v1.19(or master branch) now is using golang 1.15, and golang 1.15 has fixed the issue. And is on going. Let me add more test cases to ensure the error will not happen again.
I think we should re-open this issue because of . /re-open


Question: # Remove any existing mounts for block_device in ${block_devices}; do echo "Unmounting ${block_device}" <del> /bin/umount ${block_device} </del> <ins> /bin/umount ${block_device} || echo "Ignoring failure umounting ${block_device}" </ins> sed -i -e "|^${block_device}|d" /etc/fstab done <ins> # Remove any existing /mnt/ephemeral entry in /etc/fstab sed -i -e "|/mnt/ephemeral|d" /etc/fstab # Mount the storage </ins> if [[ ${docker_storage} == "btrfs" ]]; then apt-get-install btrfs-tools

On AWS we (will) now run our bootstrap script on every boot. The function to initialize ephemeral volumes doesn't tolerate being re-run, and we probably shouldn't re-run it anyway for speed. This does preserve the contents, which may be a good thing to save user's data (it doesn't belong on ephemeral drives, but...). On the other hand, if the ephemeral drives are corrupted, we lose the opportunity to reformat them and recover. Arguably, if the ephemeral storage is corrupted the right thing to do is to terminate the instance entirely.


Question: Expect(err).NotTo(HaveOccurred()) sst.BreakProbe(ss, testProbe) <ins> sst.WaitForStatus(ss, 0) </ins> sst.WaitForRunningAndNotReady(3, ss) sst.UpdateReplicas(ss, 0) sst.ConfirmStatefulPodCount(3, ss, 10*time.Second)

https://k8s- do you know the statefulset owners?
cc
I did not see this happening until recently.
The controller misses that the first pod transitioned to unready and proceeds to create the second pod. The test uses a client to hit the api server and will scale up the statefulset as soon as the broken pod is observed but the controller uses caches so it may observe the scaled up statefulset quicker than the updated pod.
I will update the test to ensure that we wait until the unreadiness is observed on StatefulSet.Status.Replicas field prior to the scaling operation
SGTM


Question: glog.V(2).Infof("ensure(%s) abort backoff: lb(%s) - updating", serviceName, lbName) return nil, err } <ins> if isInternal { // Refresh updated lb which will be used later in other places. newLB, exist, err := az.getAzureLoadBalancer(lbName) if err != nil { glog.V(2).Infof("getAzureLoadBalancer(%s) failed: %v", lbName, err) return nil, err } if !exist { return nil, fmt.Errorf("load balancer %q not found", lbName) } lb = &newLB } </ins> } }

<!-- 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.


Question: "//pkg/kubelet/config:go_default_library", "//pkg/volume:go_default_library", "//pkg/volume/util:go_default_library", <ins> "//pkg/volume/util/types:go_default_library", </ins> "//pkg/volume/util/volumepathhandler:go_default_library", "//staging/src/k8s.io/api/core/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library",

What happened: An iSCSI PV with is mounted without these options. What you expected to happen: The volume is mounted with . Anything else we need to know?: iSCSI volume is mounted in and passes as : This can be fixed trivially, however, why is it mounted in at all? There is another mount attempt in , with correct mount options: This code is skipped, because the volume is already mounted. Environment: Kubernetes version (use ): today's master, v1.19.0-alpha.0.781+-dirty , do you remember why we mount stuff in ? iSCSI and FibreChannel does so, the others don't.
/sig storage


Question: expectedCode   int expectedError  error }{ <del> {`echo "Hello"`, true, "Hello", "", 0, nil}, // Same as previous, but useful for test output diagnostics. </del> <ins> // Keep this test first - this variant runs on all nodes. </ins> {`echo "Hello from $(whoami)@$(hostname)"`, false, "", "", 0, nil}, {`echo "foo" | grep "bar"`, true, "", "", 1, nil}, {`echo "Out" && echo "Error" >&2 && exit 7`, true, "Out", "Error", 7, nil}, } <del> // Run commands on all nodes via SSH. for _, testCase := range testCases { By(fmt.Sprintf("SSH'ing to all nodes and running %s", testCase.cmd)) for _, host := range hosts { </del> <ins> for i, testCase := range testCases { // Only run the first testcase against max 100 nodes. Run // the rest against the first node we find only, since // they're basically testing SSH semantics (and we don't // need to do that against each host in the cluster). nodes := len(hosts) if i > 0 { nodes = 1 } else if nodes > maxNodes { nodes = maxNodes } testhosts := hosts[:nodes] By(fmt.Sprintf("SSH'ing to %d nodes and running %s", len(testhosts), testCase.cmd)) for _, host := range testhosts { </ins> result, err := framework.SSH(testCase.cmd, host, framework.TestContext.Provider) stdout, stderr := strings.TrimSpace(result.Stdout), strings.TrimSpace(result.Stderr) if err != testCase.expectedError {

On 2k nodes, this test took 53m. We should either do it in batches of nodes, or just subsample the nodes.
And it probably doesn't need to test 4 different variant command sets against all of the nodes, either. :P
When you asked me about the 2k node test, this was the test that was running. I'm not sure why other tests weren't also running in parallel or if this was just the final long pole, but it's a beastly test. PR incoming.
- thanks for looking into it. THe PR is already lgtm-ed by me.