Question: ValidatingAdmissionPolicy: {Default: false, PreRelease: featuregate.Beta}, <del> CustomResourceValidationExpressions: {Default: true, PreRelease: featuregate.Beta}, </del> <ins> CustomResourceValidationExpressions: {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.31 </ins> EfficientWatchResumption: {Default: true, PreRelease: featuregate.GA, LockToDefault: true},

This is the tracking issue of promoting CRD validation rules to GA: Listed the blocking issues/features below: [x] [x] [x] [x] Issues be aware of but should not be a GA blocker [ ] [ ] [ ] [ ] [ ] /sig api-machinery /triage accepted
/assign
/cc


Question: // These imports are the API groups the client will support. // TODO: Remove these manual install once we don't need legacy scheme in convert import ( <ins> _ "k8s.io/kubernetes/pkg/apis/admission/install" _ "k8s.io/kubernetes/pkg/apis/admissionregistration/install" _ "k8s.io/kubernetes/pkg/apis/apiserverinternal/install" </ins> _ "k8s.io/kubernetes/pkg/apis/apps/install" _ "k8s.io/kubernetes/pkg/apis/authentication/install" _ "k8s.io/kubernetes/pkg/apis/authorization/install"

What happened: Tried to convert a v1beta1 Ingress object to v1, and received the following error: What you expected to happen: The conversion to work. How to reproduce it (as minimally and precisely as possible): Then run: /sig cli /assign
Can i work on this issue?
/assign
/triage accepted


Question: "os" "os/exec" "path/filepath" <ins> "regexp" </ins> "strings" "time"

<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: pull-kubernetes-node-crio-e2e Which test(s) are failing: N/A Since when has it been failing: N/A Testgrid link: Reason for failure: Anything else we need to know:
/sig node
/assign


Question: if info.Mapping != nil && !info.Mapping.GroupVersionKind.Empty() { preferredGVKs = append(preferredGVKs, info.Mapping.GroupVersionKind) } <ins> errs := []error{} </ins> for i := range items { item, err := v.mapper.infoForObject(items[i], v.typer, preferredGVKs) if err != nil { <del> return err </del> <ins> errs = append(errs, err) continue </ins> } if len(info.ResourceVersion) != 0 { item.ResourceVersion = info.ResourceVersion } if err := fn(item, nil); err != nil { <del> return err </del> <ins> errs = append(errs, err) </ins> } } <del> return nil </del> <ins> return utilerrors.NewAggregate(errs) </ins> }) }

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

Any objects that came before the not found object in the list will have been visited and will then be included in the output. To make the behavior consistent between the two ways of getting the set of objects, the would need to be updated to support filtering errors.
Just submitted a PR adding that functionality to the FlattenListVisitor. The behavior is now consistent between the two methods.


Question: optional: true containers: - name: kubedns <del> image: gcr.io/google_containers/k8s-dns-kube-dns-amd64:1.14.2 </del> <ins> image: gcr.io/google_containers/k8s-dns-kube-dns-amd64:1.14.3 </ins> resources: # TODO: Set memory limits when we've profiled the container for large # clusters, then set request = limit to keep this container in

A number of addon images have CVEs that have been fixed in the upstream base images. We should update these images before the final 1.7 release. cc
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/cc
cc
The new image appears to have removed . I'm not sure if this was expected, but it caused at least fluentd to stop working on COS (). This might also affect kubeproxy, which uses (a derivative of ).
also the metadata-proxy, prometheus-to-sd, the fluentd-event-exporter, and ip-masq-agent.
anything more to do for this issue?
yes, I need to get merged and update those images again. I also need to bump a few other images (dns and ip-masq-agent).
should be the last update needed.


Question: const ( TableNAT    Table = "nat" TableFilter Table = "filter" <ins> TableBroute Table = "broute" </ins> ) type Chain string

<!-- Please only use this template for submitting enhancement requests --What would you like to be : The ebtables utility in is missing 3 useful features: method in its Interface table chain Why is this needed: The missing features are useful to allow for: rule deletion as there is a way to add (ensure) a rule but not removing it currently. manipulating the broute table and brouting chain The first feature would also align ebtables with iptables, as a DeleteRule method is available there.
/sig network
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
Is there some feature/bugfix you're working on in kubernetes that needs this?
Yes, in kubernetes/dns (node-cache) actually. That PR is working, but it's only in my fork of kubernetes/dns at the moment as it depends on this. It solves this: Adding this code to ebtables would help me avoid re-inventing the wheel there.
... not sure if you've seen that ... but I have created a PR to solve this issue already:
Yes, I saw the PR first. So, kubernetes/kubernetes isn't really intended to be vendored into other repos and kubernetes/dns is being bad here. It's dubious to add methods to that kubernetes itself isn't using because someone else might just end up removing them later when they notice that they're not being used... OTOH the PR needs access to the internals of the ebtables code so you couldn't just add it to kubernetes/dns directly without forking all of ...
Thanks for your comments. I saw iptables used that way in node-cache and I thought it would be good for consistency to go down the same route with ebtables. To be honest I am not very keen on forking the entire package, for obvious reasons, but I can understand your reservations about this change.
/assign
Hi Did you manage to discuss this?
yes, sorry, didn't get a chance to get back to this on Friday. (I /lgtm'ed the PR) /remove-triage unresolved
Thanks!


Question: &ScheduledJob{}, &ScheduledJobList{}, &v1.ListOptions{}, <ins> &v1.DeleteOptions{}, </ins> ) versionedwatch.AddToGroupVersion(scheme, SchemeGroupVersion) }

It seems to me like all of the garbage collection integration tests produce a ton of log messages of the form:


Question: }, } manager.RegisterPod(podWithSecrets("ns1", "name1", s2)) <del> // All secrets should be invalidated - this should trigger get operations. </del> <ins> // Fetch only s3 and s20 secrets - this should trigger get operations. </ins> store.Get("ns1", "s1") store.Get("ns1", "s2") store.Get("ns1", "s20") store.Get("ns1", "s3") actions = fakeClient.Actions() <del> assert.Equal(t, 4, len(actions), "unexpected actions: %#v", actions) </del> <ins> assert.Equal(t, 2, len(actions), "unexpected actions: %#v", actions) </ins> fakeClient.ClearActions() // Create a new pod that is refencing the first three secrets - those should

qps of configmap get request is too high in kube-apiserver. when there are many configmaps in cluster mounted by running pod, the qps of configmap get request will be high and the request will also need to get configmap resource from etcd instead of returned from kube-apiserver cache. DO NOT get configmap from etcd. Get it from cache of kube-apiserver. kubelet configMapAndSecretChangeDetectionStrategy to Cache; kube-apiserver --v=3 lots of configmaps mount to pods kube-apiserver metrics kube-apiserver log I have tested it in v1.22.13 and v1.28.0. The logic to set resourceversion=0 seems never be triggered <details</details<details</details<details</details<details</details<details</details<details</details
/sig node
Thanks can you also fill-in at least the kubernetes version, but the more info the better in your initial comment?
k8s version.
/remove-sig node /sig apimachinery
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /remove-sig node /sig apimachinery 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 apiserver
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig apiserver 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 api-machinery
I think this issue is related to kubelet not kube-apiserver and i have found the root cause i think.
/sig node
Could you add concrete data for some metrics? the request rate you describe timing for the requests. Is there a slowdown?
request rate depends on the total number of configmaps mounted to pods. what i care is not reduce the qps but to use kube-apiserver cache instead of direct request to etcd. for now, the request will redirect to etcd. there is no resourceVersion in the request query.
/cc /triage accepted
/cc
can you add some steps to reproduce the issue?

and a link to the code you think is causing the problem?
steps: code: The invocation chain is quite lengthy and the reason like blow: kubelet has a ticker with 1s interval and will try to get pods from queue to sync if there is data in syncCh; is default set to 1m. pod will be enqueued with a random time between 1m ~ 1.5m by default; is background reconcicler in file. it will run every 100ms to try to mountAttachVolumes which could trigger configmap get operation when the volume is not mounted or require remount; .object will be set to nil each time pod to sync via . pay attention to the comment. to mount or remount volume, a configmap get request will be triggered and because the is nil, the resourceversion query will not be which result to the request goes to etcd finally. volume mounted, the flag will be set to false in ; when next mountAttachVolumes called but volume has been mounted and not require remount, no need to get configmap from kubelet's cache. therefore there will no http request to apiserver to get configmap; may be some configmap get operation can be satisfied by cachebasedmanager by directly returned from local cache or get it from apiserver's cache when cache expired because same configmap can be used by many pods and each pod has a goroutine to execute syncPod but only one goroutine to execute mountAttachVolumes. I think we can always set resourceversion=0 to the query and ignore whether it's the first time to fetch the configmap or just the local cache expired. The implementation of informer is also just to list all specified resources with resourceversion=0 when to start.
That was intentional, so that a newly scheduled pod would be sure to get latest content from the API. However, RegisterPod is called on every resync, and the cacheBasedManager#RegisterPod implementation is calling AddReference on all references every time, not just changed references. I agree we don't want to do that. No, we want to actually fetch a live object the first time we get data for a new pod. I think the fix needs to happen in cacheBasedManager#RegisterPod to only call AddReference for items which are not in c.getReferencedObjects(prev)
make sense to me.


Question: t.Fatal(err) } <del> err = wait.PollImmediate(100*time.Millisecond, informerSyncTimeout, func() (bool, error) { klog.V(8).Infof("Waiting for queue to have 1 item, currently has: %d", dsc.queue.Len()) return dsc.queue.Len() == 1, nil }) if err != nil { t.Fatalf("initial DS didn't result in new item in the queue: %v", err) } </del> <ins> // create of DS adds to queue, processes waitForQueueLength(1, "created DS") </ins> ok = dsc.processNextWorkItem() if !ok { t.Fatal("queue is shutting down")

Which jobs are failing: TestExpectationsOnRecreate unit test, in along with expectations bugfix during 1.19 and cherry-picked to 1.18/1.17 Which test(s) are failing: Reason for failure: Anything else we need to know: These failures are masked in CI because bazel test runs with flake retries (), so the test can fail 2/3 times and the job can still pass (cc
adding to the milestone for triage, in case this is a real bug and not just a test issue /milestone v1.19
cc
/assign
looks like the panic is due to the test continuing in the !exists case (rather than exiting with a Fatal): however, that still means the test is failing in three distinct places:
it looks like the same failure existed in 1.18, so this probably isn't release blocking, but it does need to be resolved in order for us to stop ignoring unit test flakes in CI runs
it actually looks like this test was during the 1.19 dev cycle and cherry-picked back to 1.18/1.17, which is why release-1.18 is failing :-/
figured it out... the controller sync is updating the DS, which is triggering an update event and adding an extra enqueue which the test did not account for good news is that it appears to be a test-only issue
possible test deflake in


Question: cond.Message == "Set from e2e test" { framework.Logf("Found Service %v in namespace %v with annotations: %v & Conditions: %v", svc.ObjectMeta.Name, svc.ObjectMeta.Namespace, svc.Annotations, svc.Status.Conditions) return found, nil <del> } else { framework.Logf("Observed Service %v in namespace %v with annotations: %v & Conditions: %v", svc.ObjectMeta.Name, svc.ObjectMeta.Namespace, svc.Annotations, svc.Status.LoadBalancer) return false, nil </del> } } <ins> framework.Logf("Observed Service %v in namespace %v with annotations: %v & Conditions: %v", svc.ObjectMeta.Name, svc.ObjectMeta.Namespace, svc.Annotations, svc.Status.Conditions) return false, nil </ins> } framework.Logf("Observed event: %+v", event.Object) return false, nil

Test: Reason for failure: The test fails if there already exists some condition in the service's status. The test patches the service appending the test condtition to existing conditions but while checking seems to never go past the first condition (L3490 below). The status field in a case where the test fails: Relevant SIG(s): /sig network
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
what conditions is ? Where did you find these error? is this in a existing CI job?
This is not from a CI job, but from tests run on a local cluster with ACI-CNI, which sets the conditions for LoadBalancer services.
/sig testing
sig testing does not own tests :) each sig owns its own tests, in this case is sig network /remove-sig testing I think your analysis is correct, the test should iterate over the other conditions , I think that something like this will do it, but it will be nice to test it this seems a good opportunity to contribute /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /sig testing 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
/assign


Question: import ( "fmt" "net/http" <ins> "path" </ins> "regexp" "runtime/debug" "strings"

The apiserver proxy rewrites links to the form "/proxy/ns/default/...": But this form stopped working recently, seemingly around The "/proxy/ns/default/..." form always returns "404: Page Not Found", similar to the problem seen in If you remove "/ns/default" from the URL, it works.
/cc
I can investigate this as well.
I see the issue, sending a PR.
The proxy path needs to be built with knowledge of the apiversion of the incoming proxy request, and it needs to be updated to use the knowledge from the restmapper. This is a little trickier than I have time for right now, but it should definitely not be hardcode appending the /ns form. Not clear why this is not also caught by our test case. I can try and look at this more in the AM unless someone else wants to take a look in interim. /cc
Let me steal this one from you, I think I can fix it.
Have at it. /cc me on your PR
Sorry, I see you've already got a PR out!
No problem. I would be happy if you finished my PR relative to the commit I started. It will be a few days before I can go back to looking at this issue. I think v1beta1/v1beta2 proxy urls in go-restful need to always but the namespace scope in the path as the ultimate fix. I do want the proxy to have access to the restmapper per my PR. ----- Original Message ----- From: "Daniel Smith" To: "GoogleCloudPlatform/kubernetes" Cc: "Derek Carr" Sent: Friday, February 13, 2015 4:56:19 PM Subject: Re: [kubernetes] apiserver proxy stopped accepting namespaces () Sorry, I see you've already got a PR out! Reply to this email directly or view it on GitHub:
Any updates ?
This is breaking monitoring since it requires the proxy. Bumping up the priority to P0.
Sorry for dropping this. Working on a fix.


Question: }), } <del> // DeleteOptions.PropagationPolicy should be Foreground, when cascade is true (default). foregroundPolicy := metav1.DeletePropagationForeground policy = &foregroundPolicy </del> <ins> // DeleteOptions.PropagationPolicy should be Background, when cascade is true (default). backgroundPolicy := metav1.DeletePropagationBackground policy = &backgroundPolicy </ins> streams, _, buf, _ := genericclioptions.NewTestIOStreams() cmd := NewCmdDelete(tf, streams) cmd.Flags().Set("namespace", "test")

/kind bug What happened: hang on "kubectl delete" command on my deployer machine, but can run other commands as usual ! can run "kubectl delete" command on master node, deployer and master have the same directory. What you expected to happen: delete some resource How to reproduce it (as minimally and precisely as possible): I don't know Anything else we need to know?: Environment: Kubernetes version (use ): ! Cloud provider or hardware configuration: azure, I am not using cloud provider OS (e.g. from /etc/os-release): centos 7.5 Kernel (e.g. ): Linux cn2-k8s-deployer 3.10.0-862.3.3.el7.x8664 SMP Fri Jun 15 04:15:27 UTC 2018 x8664 x8664 x8664 GNU/Linux Install tools: installed by kubespray Others:
/sig azure
this is caused by a switch to kubectl to use "foreground deletion" in 1.11.0 that relies on server-side garbage collection being responsive to clean up the resource and its dependents, and blocks until it does. the hang means that your controller manager isn't running, or the garbage collection controller isn't responsive at the moment you are deleting the object. because of interactions like this, kubectl is returning to use background deletion in 1.11.1 (see )
fixed in , will be in 1.11.1 /close
The fix in makes me sad :( We have just found out that foreground cascade deletion is not working in kubectl again. The workaround for that would be not to wait, kubectl has a flag for that: Personally I would prefer to get a hanging kubectl in that case. was keeping a backward compatibile behavior the main reason to switch back to ? We should probably have a flag for explicit at least then... Otherwise there is no way to trigger a foreground deletion via kubectl :(
the hang means that your controller manager isn't running, or the garbage collection controller isn't responsive at the moment you are deleting the object. numerous bug reports suggest you are in the minority :) that behavior also means that with just an apiserver running, always hangs, which doesn't seem proper.

to be clear, kubectl still waits until the object you requested to be deleted is actually deleted, which was the priority for scripting compatibility (to make delete-then-recreate cases work properly) the way client-side reapers did cascading deletion in kubectl was foreground out of necessity, since client-side deletion is not re-entrant otherwise. it was only implemented that way for resources which had client-side reapers, which was a small hard-coded set. blocking client comments on controller behavior unnecessarily is problematic (as numerous reports of issues with the switch to foreground deletion revealed). I would not object to an option to run deletion in foreground mode, but it doesn't make for a good default.
the deletion mode is implemented in GC on the server side, and while understand the use case for client-side reapers, I disagree that it is only useful for some client-side blocking. The real use case we have (as I previously described in ) is building a tree of objects where deleting a root will force deletion of all its children first and will block the deletion of itself in the meantime. This has nothing to do with a client-side logic, it's just annoying that won't ever use this mode, and our users obviously deleting objects via . This is very similar to namespace behavior: deleted namespace gets blocked until all objects within it are gone. I understand the concerns of having foreground deletion mode enabled by default though.


Question: func (tc *TokenCleaner) evalSecret(o interface{}) { secret := o.(*v1.Secret) <del> if bootstrapsecretutil.HasExpired(secret, time.Now()) { </del> <ins> ttl, alreadyExpired := bootstrapsecretutil.GetExpiration(secret, time.Now()) if alreadyExpired { </ins> klog.V(3).Infof("Deleting expired secret %s/%s", secret.Namespace, secret.Name) var options *metav1.DeleteOptions if len(secret.UID) > 0 {

What happened: kube-controller-manager with enabled option --controllers=,tokencleaner is not removing newly created tokens. It works only after kube-controller-manager restart or after editing secret with token. What you expected to happen: It should remove all expired tokens from kube-system namespace, without restarting or touching secrets. How to reproduce it (as minimally and precisely as possible): enable tokencleaner in kube-controller-manager start controller manager create bootstrap token, you can use script wait 5 minutes token is still there restart kube-controller-manager OR edit newly created token token should be gone after a while Anything else we need to know?: It could be related with Environment: Kubernetes version (use ): Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-12-03T20:56:12Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
Do you see the following log ? thanks
no errors at all
/sig auth


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 vsphere import ( "context" "fmt" "testing" "k8s.io/kubernetes/pkg/cloudprovider/providers/vsphere/vclib" "github.com/vmware/govmomi" "github.com/vmware/govmomi/simulator" ) func TestGetPathFromFileNotFound(t *testing.T) { ctx := context.Background() // vCenter model + initial set of objects (cluster, hosts, VMs, network, datastore, etc) model := simulator.VPX() defer model.Remove() err := model.Create() if err != nil { t.Fatal(err) } s := model.Service.NewServer() defer s.Close() c, err := govmomi.NewClient(ctx, s.URL, true) if err != nil { t.Fatal(err) } vc := &vclib.VSphereConnection{Client: c.Client} dc, err := vclib.GetDatacenter(ctx, vc, vclib.TestDefaultDatacenter) if err != nil { t.Errorf("failed to get datacenter: %v", err) } requestDiskPath := fmt.Sprintf("[%s] %s", vclib.TestDefaultDatastore, DummyDiskName) _, err = dc.GetVirtualDiskPage83Data(ctx, requestDiskPath) if err == nil { t.Error("expected error when calling GetVirtualDiskPage83Data") } _, err = getPathFromFileNotFound(err) if err != nil { t.Errorf("expected err to be nil but was %v", err) } _, err = getPathFromFileNotFound(nil) if err == nil { t.Errorf("expected err when calling getPathFromFileNotFound with nil err") } } </ins>

<!-- 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: Provsioning a PVC using a storage class with vSphere as the cloud provider failed with error "runtime error: index out of range". What you expected to happen: The PVC should have been created. How to reproduce it (as minimally and precisely as possible): Create a PVC using a storage class with vSphere as the cloud provider and a VMware vCenter Server where the default language is not English. Anything else we need to know?: K8s in conjunction with vSphere PVC relies on English error messages from the VMware API in order to determine the canonical path for a newly created volume (VMDK file). The faulting code (v1.11.3, still the same on master) can be found here (starting at line 312): The line "canonicalVolumePath = match[1]" (340) in the above code is the problem because "File (.*?) was not found" (English) never matches for a different language (e.g. German: "Datei [DATASTORE] kubevols/kube- wurde nicht gefunden") and a “runtime error: index out of range” oocurs in the "kube-controller-manager". This causes the already created volume (VMDK file) not to be reported back to the K8s system which in turn will try to recreate it repeatedly in a loop (fails with "Cannot complete the operation because the file or folder [DATASTORE] /kubevols/kubernetes-dynamic-pvc-[UUID] already exists"). Find below the corresponding log excerpt (kube-controller-manager): Environment: Kubernetes version (use ):Cloud provider or hardware configuration: vSphere OS (e.g. from /etc/os-release): n/a Kernel (e.g. ): n/a Install tools: n/a Others: n/a <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/assign


Question: } return result, status } <ins> type instrumentedPreScorePlugin struct { framework.PreScorePlugin metric compbasemetrics.CounterMetric } var _ framework.PreScorePlugin = &instrumentedPreScorePlugin{} func (p *instrumentedPreScorePlugin) PreScore(ctx context.Context, state *framework.CycleState, pod *v1.Pod, nodes []*v1.Node) *framework.Status { status := p.PreScorePlugin.PreScore(ctx, state, pod, nodes) if !status.IsSkip() { p.metric.Inc() } return status } type instrumentedScorePlugin struct { framework.ScorePlugin metric compbasemetrics.CounterMetric } var _ framework.ScorePlugin = &instrumentedScorePlugin{} func (p *instrumentedScorePlugin) Score(ctx context.Context, state *framework.CycleState, pod *v1.Pod, nodeName string) (int64, *framework.Status) { p.metric.Inc() return p.ScorePlugin.Score(ctx, state, pod, nodeName) } </ins>

metrics to see more details related to scheduler's decisions in Filter phase In some cases (e.g. new feature is in scheduler and want to see if it works or not), we may want to see which filter plugin affected Pod's scheduling results and it would be nice if we can observe that in metrics. Ref: /cc /sig scheduling
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
So, your imagined metrics is like counter that has the label (i.e. one counter for one plugin) the count represents how many times did plugin have an impact on the scheduling of the pod. Am I correct? (I'm not sure if I am understanding your imagined metric correctly.)
I would also add an label that can be or . We probably need some common implementation between this and
do you have time to work on this in 1.26?
Yes, I'm gonna take time to work on this (+ ) in the next release. Let me try. /assign
We should probably extend this to Score as well
/retitle metrics to see which plugins affect to scheduler's decisions in Filter/Score phase
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale After supporting Skip in Filter and Score.
memo: is the issue to support Skip in Score.
/cc Will work on part after
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
It's time! /assign


Question: // Start starts resource collector and connects to the standalone Cadvisor pod // then repeatedly runs collectStats. func (r *ResourceCollector) Start() { <del> // Get the cgroup container names for kubelet and docker </del> <ins> // Get the cgroup container names for kubelet and runtime </ins> kubeletContainer, err := getContainerNameForProcess(kubeletProcessName, "") <del> dockerContainer, err := getContainerNameForProcess(dockerProcessName, dockerPidFile) </del> <ins> runtimeContainer, err := getContainerNameForProcess(framework.TestContext.ContainerRuntimeProcessName, framework.TestContext.ContainerRuntimePidFile) </ins> if err == nil { systemContainers = map[string]string{ stats.SystemContainerKubelet: kubeletContainer, <del> stats.SystemContainerRuntime: dockerContainer, </del> <ins> stats.SystemContainerRuntime: runtimeContainer, </ins> } } else { <del> framework.Failf("Failed to get docker container name in test-e2e-node resource collector.") </del> <ins> framework.Failf("Failed to get runtime container name in test-e2e-node resource collector.") </ins> } wait.Poll(1*time.Second, 1*time.Minute, func() (bool, error) {

<!-- 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: Now, benchmark test make docker as the only runtime. What you expected to happen: benchmark test should be generic to all CRI container runtimes Related to How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/area test /area node-e2e
/sig node


Question: ) func TestAllocate(t *testing.T) { <del> _, cidr, err := net.ParseCIDR("192.168.1.0/24") if err != nil { t.Fatal(err) } r := NewCIDRRange(cidr) t.Logf("base: %v", r.base.Bytes()) if f := r.Free(); f != 254 { t.Errorf("unexpected free %d", f) } if f := r.Used(); f != 0 { t.Errorf("unexpected used %d", f) </del> <ins> testCases := []struct { name             string cidr             string free             int released         string outOfRange1      string outOfRange2      string outOfRange3      string alreadyAllocated string }{ { name:             "IPv4", cidr:             "192.168.1.0/24", free:             254, released:         "192.168.1.5", outOfRange1:      "192.168.0.1", outOfRange2:      "192.168.1.0", outOfRange3:      "192.168.1.255", alreadyAllocated: "192.168.1.1", }, { name:             "IPv6", cidr:             "2001:db8:1::/48", free:             65534, released:         "2001:db8:1::5", outOfRange1:      "2001:db8::1", outOfRange2:      "2001:db8:1::", outOfRange3:      "2001:db8:1::ffff", alreadyAllocated: "2001:db8:1::1", }, </ins> } <del> found := sets.NewString() count := 0 for r.Free() > 0 { ip, err := r.AllocateNext() </del> <ins> for _, tc := range testCases { _, cidr, err := net.ParseCIDR(tc.cidr) </ins> if err != nil { <del> t.Fatalf("error @ %d: %v", count, err) </del> <ins> t.Fatal(err) </ins> } <del> count++ if !cidr.Contains(ip) { t.Fatalf("allocated %s which is outside of %s", ip, cidr) </del> <ins> r := NewCIDRRange(cidr) t.Logf("base: %v", r.base.Bytes()) if f := r.Free(); f != tc.free { t.Errorf("Test %s unexpected free %d", tc.name, f) </ins> } <del> if found.Has(ip.String()) { t.Fatalf("allocated %s twice @ %d", ip, count) </del> <ins> if f := r.Used(); f != 0 { t.Errorf("Test %s unexpected used %d", tc.name, f) } found := sets.NewString() count := 0 for r.Free() > 0 { ip, err := r.AllocateNext() if err != nil { t.Fatalf("Test %s error @ %d: %v", tc.name, count, err) } count++ if !cidr.Contains(ip) { t.Fatalf("Test %s allocated %s which is outside of %s", tc.name, ip, cidr) } if found.Has(ip.String()) { t.Fatalf("Test %s allocated %s twice @ %d", tc.name, ip, count) } found.Insert(ip.String()) } if _, err := r.AllocateNext(); err != ErrFull { t.Fatal(err) </ins> } <del> found.Insert(ip.String()) } if _, err := r.AllocateNext(); err != ErrFull { t.Fatal(err) } released := net.ParseIP("192.168.1.5") if err := r.Release(released); err != nil { t.Fatal(err) } if f := r.Free(); f != 1 { t.Errorf("unexpected free %d", f) } if f := r.Used(); f != 253 { t.Errorf("unexpected free %d", f) } ip, err := r.AllocateNext() if err != nil { t.Fatal(err) } if !released.Equal(ip) { t.Errorf("unexpected %s : %s", ip, released) } </del> <ins> released := net.ParseIP(tc.released) if err := r.Release(released); err != nil { t.Fatal(err) } if f := r.Free(); f != 1 { t.Errorf("Test %s unexpected free %d", tc.name, f) } if f := r.Used(); f != (tc.free - 1) { t.Errorf("Test %s unexpected free %d", tc.name, f) } ip, err := r.AllocateNext() if err != nil { t.Fatal(err) } if !released.Equal(ip) { t.Errorf("Test %s unexpected %s : %s", tc.name, ip, released) } </ins> <del> if err := r.Release(released); err != nil { t.Fatal(err) } err = r.Allocate(net.ParseIP("192.168.0.1")) if _, ok := err.(*ErrNotInRange); !ok { t.Fatal(err) } if err := r.Allocate(net.ParseIP("192.168.1.1")); err != ErrAllocated { t.Fatal(err) } err = r.Allocate(net.ParseIP("192.168.1.0")) if _, ok := err.(*ErrNotInRange); !ok { t.Fatal(err) } err = r.Allocate(net.ParseIP("192.168.1.255")) if _, ok := err.(*ErrNotInRange); !ok { t.Fatal(err) } if f := r.Free(); f != 1 { t.Errorf("unexpected free %d", f) } if f := r.Used(); f != 253 { t.Errorf("unexpected free %d", f) } if err := r.Allocate(released); err != nil { t.Fatal(err) } if f := r.Free(); f != 0 { t.Errorf("unexpected free %d", f) } if f := r.Used(); f != 254 { t.Errorf("unexpected free %d", f) </del> <ins> if err := r.Release(released); err != nil { t.Fatal(err) } err = r.Allocate(net.ParseIP(tc.outOfRange1)) if _, ok := err.(*ErrNotInRange); !ok { t.Fatal(err) } if err := r.Allocate(net.ParseIP(tc.alreadyAllocated)); err != ErrAllocated { t.Fatal(err) } err = r.Allocate(net.ParseIP(tc.outOfRange2)) if _, ok := err.(*ErrNotInRange); !ok { t.Fatal(err) } err = r.Allocate(net.ParseIP(tc.outOfRange3)) if _, ok := err.(*ErrNotInRange); !ok { t.Fatal(err) } if f := r.Free(); f != 1 { t.Errorf("Test %s unexpected free %d", tc.name, f) } if f := r.Used(); f != (tc.free - 1) { t.Errorf("Test %s unexpected free %d", tc.name, f) } if err := r.Allocate(released); err != nil { t.Fatal(err) } if f := r.Free(); f != 0 { t.Errorf("Test %s unexpected free %d", tc.name, f) } if f := r.Used(); f != tc.free { t.Errorf("Test %s unexpected free %d", tc.name, f) } </ins> } }

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When creating an IPv6 cluster, the --pod-network-cidr needs to be a /66, it cannot be for a larger network (smaller value) What you expected to happen: Should be able to use values smaller then /66, /64 or a /48 How to reproduce it (as minimally and precisely as possible): Create a cluster with Kubeadm, and set the podSubnet as below networking: podSubnet: "fd00:1:2:3::/64" Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /area ipv6 /sig network
/assign rpothier


Question: "k8s.io/kubernetes/pkg/runtime" "k8s.io/kubernetes/pkg/watch" <del> "github.com/golang/glog" bindings "github.com/mesos/mesos-go/executor" </del> "github.com/mesos/mesos-go/mesosproto" "github.com/mesos/mesos-go/mesosutil" "github.com/stretchr/testify/assert" "github.com/stretchr/testify/mock" ) <del> type suicideTracker struct { suicideWatcher stops  uint32 resets uint32 timers uint32 jumps  *uint32 } func (t *suicideTracker) Reset(d time.Duration) bool { defer func() { t.resets++ }() return t.suicideWatcher.Reset(d) } func (t *suicideTracker) Stop() bool { defer func() { t.stops++ }() return t.suicideWatcher.Stop() } func (t *suicideTracker) Next(d time.Duration, driver bindings.ExecutorDriver, f jumper) suicideWatcher { tracker := &suicideTracker{ stops:  t.stops, resets: t.resets, jumps:  t.jumps, timers: t.timers + 1, } jumper := tracker.makeJumper(f) tracker.suicideWatcher = t.suicideWatcher.Next(d, driver, jumper) return tracker } func (t *suicideTracker) makeJumper(_ jumper) jumper { return jumper(func(driver bindings.ExecutorDriver, cancel <-chan struct{}) { glog.Warningln("jumping?!") if t.jumps != nil { atomic.AddUint32(t.jumps, 1) } }) } func TestSuicide_zeroTimeout(t *testing.T) { defer glog.Flush() k := New(Config{}) tracker := &suicideTracker{suicideWatcher: k.suicideWatch} k.suicideWatch = tracker ch := k.resetSuicideWatch(nil) select { case <-ch: case <-time.After(2 * time.Second): t.Fatalf("timeout waiting for reset of suicide watch") } if tracker.stops != 0 { t.Fatalf("expected no stops since suicideWatchTimeout was never set") } if tracker.resets != 0 { t.Fatalf("expected no resets since suicideWatchTimeout was never set") } if tracker.timers != 0 { t.Fatalf("expected no timers since suicideWatchTimeout was never set") } } func TestSuicide_WithTasks(t *testing.T) { defer glog.Flush() k := New(Config{ SuicideTimeout: 50 * time.Millisecond, }) jumps := uint32(0) tracker := &suicideTracker{suicideWatcher: k.suicideWatch, jumps: &jumps} k.suicideWatch = tracker k.tasks["foo"] = &kuberTask{} // prevent suicide attempts from succeeding // call reset with a nil timer glog.Infoln("resetting suicide watch with 1 task") select { case <-k.resetSuicideWatch(nil): tracker = k.suicideWatch.(*suicideTracker) if tracker.stops != 1 { t.Fatalf("expected suicide attempt to Stop() since there are registered tasks") } if tracker.resets != 0 { t.Fatalf("expected no resets since") } if tracker.timers != 0 { t.Fatalf("expected no timers since") } case <-time.After(1 * time.Second): t.Fatalf("initial suicide watch setup failed") } delete(k.tasks, "foo") // zero remaining tasks k.suicideTimeout = 1500 * time.Millisecond suicideStart := time.Now() // reset the suicide watch, which should actually start a timer now glog.Infoln("resetting suicide watch with 0 tasks") select { case <-k.resetSuicideWatch(nil): tracker = k.suicideWatch.(*suicideTracker) if tracker.stops != 1 { t.Fatalf("did not expect suicide attempt to Stop() since there are no registered tasks") } if tracker.resets != 1 { t.Fatalf("expected 1 resets instead of %d", tracker.resets) } if tracker.timers != 1 { t.Fatalf("expected 1 timers instead of %d", tracker.timers) } case <-time.After(1 * time.Second): t.Fatalf("2nd suicide watch setup failed") } k.lock.Lock() k.tasks["foo"] = &kuberTask{} // prevent suicide attempts from succeeding k.lock.Unlock() // reset the suicide watch, which should stop the existing timer glog.Infoln("resetting suicide watch with 1 task") select { case <-k.resetSuicideWatch(nil): tracker = k.suicideWatch.(*suicideTracker) if tracker.stops != 2 { t.Fatalf("expected 2 stops instead of %d since there are registered tasks", tracker.stops) } if tracker.resets != 1 { t.Fatalf("expected 1 resets instead of %d", tracker.resets) } if tracker.timers != 1 { t.Fatalf("expected 1 timers instead of %d", tracker.timers) } case <-time.After(1 * time.Second): t.Fatalf("3rd suicide watch setup failed") } k.lock.Lock() delete(k.tasks, "foo") // allow suicide attempts to schedule k.lock.Unlock() // reset the suicide watch, which should reset a stopped timer glog.Infoln("resetting suicide watch with 0 tasks") select { case <-k.resetSuicideWatch(nil): tracker = k.suicideWatch.(*suicideTracker) if tracker.stops != 2 { t.Fatalf("expected 2 stops instead of %d since there are no registered tasks", tracker.stops) } if tracker.resets != 2 { t.Fatalf("expected 2 resets instead of %d", tracker.resets) } if tracker.timers != 1 { t.Fatalf("expected 1 timers instead of %d", tracker.timers) } case <-time.After(1 * time.Second): t.Fatalf("4th suicide watch setup failed") } sinceWatch := time.Since(suicideStart) time.Sleep(3*time.Second - sinceWatch) // give the first timer to misfire (it shouldn't since Stop() was called) if j := atomic.LoadUint32(&jumps); j != 1 { t.Fatalf("expected 1 jumps instead of %d since stop was called", j) } else { glog.Infoln("jumps verified") // glog so we get a timestamp } } </del> // TestExecutorRegister ensures that the executor thinks it is connected // after Register is called. func TestExecutorRegister(t *testing.T) {

<!-- 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: Followed the documentation on rules to limit group Id's to non-superuser (root) using the rule. The creation attempt failed with: From PSP yaml: What you expected to happen: Successfully create a new PSP for non-superuser (root) group privileges using available rule values (which actually seems to be , , according the the ) How to reproduce it (as minimally and precisely as possible): Attempt to create a PSP with a rule set to Anything else we need to know?: I don't think so Environment: Kubernetes version (use ): , looks to affect , and doc as well Cloud provider or hardware configuration: IBM Cloud OS (e.g: ):Kernel (e.g. ): Install tools: Others:
/sig docs
/assign
thanks will send out a fix next week
I wonder whether this is a bug in implementation or the document. Is this really a documentation issue?
yes, RunAsGroup does not support MustRunAsNonRoot
Got it. Thank you!
/priority important-soon


Question: // Install adds the MetricsWithReset handler func (m MetricsWithReset) Install(c *mux.PathRecorderMux) { <ins> register() </ins> defaultMetricsHandler := prometheus.Handler().ServeHTTP c.HandleFunc("/metrics", func(w http.ResponseWriter, req *http.Request) { if req.Method == "DELETE" {

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: endpoint of different k8s components expose Prometheus metrics that are not for them. For example, exposes metrics: or : What you expected to happen: Prometheus metrics only for to appear on kubelet's endpoint. How to reproduce it (as minimally and precisely as possible): Access the endpoint of all Kubernetes components Anything else we need to know?: This problem comes from usage of functions in different packages that automatically register Prometheus metrics. Just importing that package or some package that depends on it can cause those metrics to appear in unexpected places. In the list bellow you can find the different packages that have init functions and affected binaries: [ ] () cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kube-proxy kube-scheduler [ ] () cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kube-proxy kube-scheduler [ ] cloud-controller-manager hyperkube kube-apiserver kube-controller-manager [ ] cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kubelet [ ] cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kube-proxy kube-scheduler [ ] cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kube-proxy kube-scheduler kubectl kubelet [ ] cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kube-proxy kube-scheduler kubelet [ ] hyperkube kube-apiserver kube-controller-manager [ ] hyperkube kube-apiserver [ ] cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kubelet [ ] cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kube-proxy kube-scheduler kubelet Environment: Kubernetes version (use ):Cloud provider or hardware configuration: N/A OS (e.g. from /etc/os-release): N/A Kernel (e.g. ): N/A Install tools: N/A Others: N/A /sig instrumentation
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
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: glog.V(3).Infof("pod %q container %q exists as %v", podFullName, container.Name, containerID) // look for changes in the container. <del> containerChanged := hash != 0 && hash != expectedHash if !containerChanged { </del> <ins> podChanged := hash != 0 && hash != expectedHash if !podChanged { </ins> // TODO: This should probably be separated out into a separate goroutine. // If the container's liveness probe is unsuccessful, set readiness to false. If liveness is succesful, do a readiness check and set // readiness accordingly. If the initalDelay since container creation on liveness probe has not passed the probe will return Success.

cAdvisor API is not accessible from the node. It is accessible from inside the cadvisor container though. This is the reason for the cadvisor e2e test to fail and the recent heapster errors reported by users. The cadvisor version itself hasn't changed recently though.
cc
There were some changes recently around port forwarding ( that may be the cause.
From the node: From the cadvisor container:
reported the same issue today. Restarting the container seems to fix it. So, its something to do with the initial setup.
Could this be due to Docker 1.5? On Feb 23, 2015 6:12 PM, "Rohit Jnagal" wrote:
test machine is running Docker 1.4.1 It looks like cadvisor container is sharing its networking with the pause container as usual, but the pause container got restarted, so the networking setup isn't working anymore. Restarting cadvisor connects it to the newer instance of the pause container and it starts working again. However docker inspect shows that cadvisor is connected to network of a different pause container: And that container died soon after it started Kubelet killed the pause container. I think this is kubelet's doing. It tried to restart both pause and cadvisor container. It kills and restarts cadvisor container which connects to existing pause container. Then, it goes ahead and kills/restarts the pause container, leaving the new cadvisor container hanging. Maybe this is related to infra pods issue reported by earlier, or maybe just an ordering issue in kubelet.
Thanks for the detailed debugging :) with your report I think I found the issue. In we check if the container has changed and print the message above. After that we the POD container. We should be doing this before the container restart as you pointed out. I'm assigning this to myself and I will fix tomorrow. Will also rename the bug and re-purpose it.
cool, I was just staring at that code. All yours :+1:
Thanks for debugging the issue. This is a regression we introduced lately.
And when the test, we all assumed it was the test failing. Sorry, :)
I fell for that until I realized that the basic networking can also fail :)


Question: <ins> /* Copyright 2014 Google Inc. All rights reserved. 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 master import ( "fmt" "log" "sync" "time" "github.com/GoogleCloudPlatform/kubernetes/pkg/client" "github.com/GoogleCloudPlatform/kubernetes/pkg/labels" "github.com/GoogleCloudPlatform/kubernetes/pkg/registry" "github.com/GoogleCloudPlatform/kubernetes/pkg/util" ) // PodCache contains both a cache of container information, as well as the mechanism for keeping // that cache up to date. type PodCache struct { containerInfo client.ContainerInfo pods          registry.PodRegistry podInfo       map[string]interface{} period        time.Duration podLock       sync.Mutex } func NewPodCache(info client.ContainerInfo, pods registry.PodRegistry, period time.Duration) *PodCache { return &PodCache{ containerInfo: info, pods:          pods, podInfo:       map[string]interface{}{}, period:        period, } } // Implements the ContainerInfo interface // The returned value should be treated as read-only func (p *PodCache) GetContainerInfo(host, id string) (interface{}, error) { p.podLock.Lock() defer p.podLock.Unlock() value, ok := p.podInfo[id] if !ok { return nil, fmt.Errorf("Couldn't find any information for %s", id) } else { return value, nil } } func (p *PodCache) updateContainerInfo(host, id string) error { info, err := p.containerInfo.GetContainerInfo(host, id) if err != nil { return err } p.podLock.Lock() defer p.podLock.Unlock() p.podInfo[id] = info return nil } // Update information about all containers.  Either called by Loop() below, or one-off. func (p *PodCache) UpdateAllContainers() { pods, err := p.pods.ListPods(labels.Everything()) if err != nil { log.Printf("Error synchronizing container: %#v", err) return } for _, pod := range pods { err := p.updateContainerInfo(pod.CurrentState.Host, pod.ID) if err != nil { log.Printf("Error synchronizing container: %#v", err) } } } func (p *PodCache) synchronizeContainers() { ticker := time.Tick(p.period) for _ = range ticker { p.UpdateAllContainers() } } // Loop runs forever, it is expected to be placed in a go routine. func (p *PodCache) Loop() { util.Forever(func() { p.synchronizeContainers() }, 0) } </ins>

Which jobs are failing: cip-postsubmit-push-to-staging (cip-postsubmit-push-to-staging) Since when has it been failing: This is a postsubmit of repository. Testgrid link: Reason for failure: Anything else we need to know: /cc /priority critical-urgent /milestone v1.18
So this is the "create a staging image of the promoter upon a merge to its master branch" job so that I don't have to do it manually myself. As for the failure, I am probably doing something wrong but from the logs it's hard to tell what I'm doing wrong. I don't think this is critical as it is not blocking the official promoter or anything.
I think the error could be that the service account for doesn't have creds to push to the buckets. I'll post another update later.
Thanks for the quick response. So, since this job is not critical, can we removed it from testgrid or is there a good reason to keep it there and just ignore the alerts?
I should be able to fix it this week; if that deadline passes then we can move it to another testgrid dashboard.
/sig release
/reopen Let's observe the job first before closing.
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Do we have to rerun the job to make sure that it's fixed or wait for the next PR to be merge?
The behavior I have observed is that the job will re-run for each PR merge. I am now seeing that the latest build is failing due to a MemoryError when joining the heaviest Docker layer that contains gcloud: I am going to change the machine settings in another PR; stay tuned.
Looks like the last couple PRs did the trick. It's green now!
Thanks ! /close
Closing this issue. <detailsIn response to : Thanks ! 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: JSON and YAML formats are accepted. <ins> Please refer to the models in https://htmlpreview.github.io/?https://github.com/GoogleCloudPlatform/kubernetes/HEAD/docs/api-reference/definitions.html to find if a field is mutable. </ins> ``` kubectl patch RESOURCE NAME -p PATCH ```

The current documentation is very vague and doesn't explain what can be updated in this way. Can I rename or stop the pod, change number of replicas in RC etc. For example it seems to be impossible to change pod name:
cc
After an in person discussion with we think the docs should point people to the swagger-ui to find if a field is mutable. I'll add this point into the docs.


Question: // using CSI for all Migrated volume plugins. Then all the CSINode initialization // code can be dropped from Kubelet. // Kill the Kubelet process and allow it to restart to retry initialization <del> klog.Fatalf("Failed to initialize CSINodeInfo after retrying") </del> <ins> klog.Fatalf("Failed to initialize CSINode after retrying: %v", err) </ins> } }() return nil

What happened: Upgraded from 1.16.6 to 1.17.2 and will no longer start on control-plane hosts. It fails with: What you expected to happen: to start, static pods to launch, to connect to in the static pod How to reproduce it (as minimally and precisely as possible): Have the , , , etc in the static pod manifest folder. Try to start the with the container images not preloaded on the host. Just in case it is needed: is used as the backend is run using Anything else we need to know?: This looks to be two things interacting poorly: 1- It takes a long time for static pods to be created for the first time when the can't talk to yet. 2- The new CSI migration code force terminates causing these log lines to appear in : It looks like introduced this new fatal error. Environment: Kubernetes version (use ): 1.17.2 Cloud provider or hardware configuration: Bare-metal OS (e.g: ): Fedora 31..1 (CoreOS preview)" Kernel (e.g. ): 5.3.12-300.fc31.x86_64 Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cluster-lifecycle
Actually, probably: /sig node
The referenced PR was in 1.14, so that interaction is not new. What is likely new is the size increase of hyperkube in 1.17 (xref ). When not pre-pulled, this can increase the time it takes to start hyperkube for the first time. Does the image pull make progress as the kubelet restarts/retries?
It might make sense for the initializeCSINode() method to: first wait to successfully talk to the kube apiserver at all, perhaps indefinitely after successfully talking to the kube apiserver, then try to register the CSINode object with backoff, and fail if it cannot do that successfully
/sig storage /remove-sig cluster-lifecycle
It doesn't seem to. Once the connection to containerd is closed, it cancels the context. Otherwise I would expect this to succeed eventually if the pull happened in the background. That sounds reasonable to me assuming it isn't blocking the static pod creation code. Do you happen to know why it takes a very long time for the static pod creation code to be called?

I would expect the pods to be created very soon after the kubelet is started.
Pulling the image and starting the processes for those pods happens immediately (from the containerd logs, you can see the image pull happening... it just doesn't complete in time before the independent kubelet logic to register the CSI node info times out).
Ah, yes. I just upgraded a couple of days ago so I didn't check whether I still saw the 2 minute delay in creating the "pod sandboxes" (this is before the pull even happens). It now is only a 23 second delay: containerd: kubelet:
ack, I like the idea Will work on a fix today and cherry-pick it as necessary


Question: package apimachinery import ( <ins> "context" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" </ins> utilversion "k8s.io/apimachinery/pkg/util/version" "k8s.io/apiserver/pkg/endpoints/discovery" "k8s.io/kubernetes/test/e2e/framework"

] 20 July 2020 [x] Two weeks soak end date: 3 August 2020 According to this APIsnoop query, there are still an endpoint which is untested. Get a list of all group /apis Iterate through list Query each endpoint List the PreferredVersion for the endpoint Discover useragents: List endpoints hit by the test: Display endpoint coverage change: If a test with these calls gets merged, test coverage will go up by 15 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/retitle Write checkAPIGroupPreferredVersion Test +Promote - +16 Endpoint coverage
/reopen Merged /assign Ready for creation of Promotion PR
Reopened this issue. <detailsIn response to : /reopen Merged /assign Ready for creation of Promotion PR 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: return nil, err } primaryVMSetName := az.VMSet.GetPrimaryVMSetName() <del> if !strings.EqualFold(primaryVMSetName, vmSetName) { </del> <ins> if !strings.EqualFold(primaryVMSetName, vmSetName) && vmSetName != "" { </ins> klog.V(2).Infof("cleanBackendpoolForPrimarySLB: found unwanted vmSet %s, decouple it from the LB", vmSetName) // construct a backendPool that only contains the IP config of the node to be deleted interfaceIPConfigToBeDeleted := network.InterfaceIPConfiguration{

What happened: introduced new dependency on Availability Sets which is too restrictive for some existing installations: What you expected to happen: Azure cloud provider to successfully manage LBs, like it had been doing before. Instead, it died [with][1]: How to reproduce it (as minimally and precisely as possible): Fails every time in OpenShift CI. Can you point us to documentation around the infrastructure options that the Azure cloud provider expects for LB management? https://kubernetes- doesn't say anything about NIC names, and it doesn't have specifics around what things should look like without Availability Sets, or whether "without Availability Sets" is not supported (when previous iterations of the cloud provider had no problem with our lack of Availability Sets). Documenting cloud-provider assumptions about host hardware would have also helped avoid ; CC /sig cloud-provider /area provider/azure [1]:
/triage accepted
/assign
Notes on OpenShift's Azure infrastructure in ARM templates [here][1], in case that helps clarify the infra we use today. Those are OpenShift 4.6 docs, and 4.6 is based on Kubernetes 1.19, and things worked fine. The trouble we've been having when we took the same Azure-infra approach and tried to use it with Kubernetes 1.20, after openshift/kubernetes. [1]:
could you share an example of resourceID (please replace your subscription/resourceName with fake ones)?
Example CI run [here][1] from the NIC-renaming openshift/installer. Installer logs [here][2] include: I'm hoping that the subscription name is not sensitive, because we've been dumping them in public logs for a long time now . Should be IDs for any other resources you're interested in in those logs as well. [1]: [2]: https://gcsweb-
Looks like this is about the master node. Are you using standard LB or a basic one? For standard LB, the master node would be excluded from the LB by default.
[Standard][1] (and [here][2]). Is this documented somewhere? We've been using standard LBs [for years][3], with no problems until the bump to the Kube 1.20 Azure cloud-provider. [1]: [2]: [3]:
Are you referring to the built-in logic of Kube to never target master nodes with a service type LoadBalancer?

That used to be a problem (), but my understanding is that it has since been fixed.
Can we re-open this? kubernetes-sigs/cloud-provider-azure was [not sufficient][1] to get the cloud-provider happy on our infra, which again, contains no Availability Sets. There are some more notes about our infrastructure [here][2] (with discussion in [rhbz][3]), in case that helps. [1]: [2]: [3]:
who has a better grasp on this than me, also just opened . Sounds like fixing that broader issue might obsolete this ticket, because "the cloud-provider expects Availability Sets which OpenShift infra doesn't have in order to figure out which nodes to remove" doesn't matter if the cloud-provider isn't removing any OpenShift nodes in the first place.
can you please confirm the standalone VM scenario is supported? It's a critical use case for CAPZ (our control plane VMs in zone-enabled regions are not placed in availability sets)

What happened: introduced new regex which is too restrictive for some existing installations: This new restriction causes LBs to fail to sync if just one ipConf fails regex. What you expected to happen: This change was to enable optional behavior, any ipConf that fails regex should just be ignored. This will allow existing installs to work as they did prior to the change. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
Suggest putting a continue here: This will restore previous functionality and appears to have no undesirable impact.
/sig cloud-provider /area provider/azure
Unclear if we should also put a continue here as well:
/assign
could you share an example of resourceID (please replace your subscription/resourceName with fake ones)? /triage accepted
Here's the error we're seeing: Just the string


Question: # Directory to store release packages that will be downloaded. RELEASES_DIR=${RELEASES_DIR:-/tmp/downloads} <ins> # Define docker version to use. DOCKER_VERSION=${DOCKER_VERSION:-"1.12.0"} </ins> # Define flannel version to use. FLANNEL_VERSION=${FLANNEL_VERSION:-"0.5.5"}

Did a git clone and trying to build on centos. [root kubernetes]# cat /etc/redhat-release CentOS Linux release 7.2.1511 (Core) [root kubernetes]# make release +++ [0616 17:42:23] Verifying Prerequisites.... +++ [0616 17:42:57] Building Docker image kube-build:build-. +++ [0616 17:44:44] Running build command.... Usage of loopback devices is strongly discouraged for production use. Either use or use to suppress this warning. Go version: go version go1.6.2 linux/amd64 +++ [0616 17:45:01] Multiple platforms requested, but available 0G < threshold 11G, building platforms in serial +++ [0616 17:45:01] Building the toolchain targets: +++ [0616 17:45:04] Building go targets for linux/amd64: cmd/kube-dns cmd/kube-proxy cmd/kube-apiserver cmd/kube-controller-manager cmd/kubelet cmd/kubemark cmd/hyperkube federation/cmd/federation-apiserver federation/cmd/federation-controller-manager plugin/cmd/kube-scheduler go build /usr/local/go/pkg/tool/linuxamd64/compile: signal: killed !!! Error in 'go install "{goflags[ -ldflags "{nonstatics[ exited with status 1 Call stack: 1: kube::golang::buildbinariesforplatform(...) 2: kube::golang::buildbinaries(...) 3: hack/build- main(...) Exiting with status 1 !!! Error in '( kube::golang::setupenv; echo "Go version: (kube::golang::hostplatform); local goflags goldflags; eval "goflags=({KUBEGOLDFLAGS:-} do if [[ "${arg}" == "--usegobuild" ]]; then usegobuild=true; else if [[ "${arg}" == - ]]; then goflags+=("${arg}"); else targets+=("${arg}"); fi; fi; done; if [[ ${#targets[ -eq 0 ]]; then targets=("${KUBEALLTARGETS[ fi; local -a platforms=("{KUBEBUILDPLATFORMS[ if [[ ${#platforms[ -eq 0 ]]; then platforms=("${hostplatform}"); fi; local binaries;

binaries=({targets[ local parallel=false; if [[ ${#platforms[ -gt 1 ]]; then local gigs; gigs={gigs} -ge ${KUBEPARALLELBUILDMEMORY} ]]; then kube::log::status "Multiple platforms requested and available {KUBEPARALLELBUILDMEMORY}G, building platforms in parallel"; parallel=true; else kube::log::status "Multiple platforms requested, but available {KUBEPARALLELBUILDMEMORY}G, building platforms in serial"; parallel=false; fi; fi; kube::golang::buildkubetoolchain; if [[ "${parallel}" == "true" ]]; then kube::log::status "Building go targets for {targets[ local platform; for platform in "${platforms[ do ( kube::golang::setplatformenvs "{platform}: go build started"; kube::golang::buildbinariesforplatform {usegobuild:-}; kube::log::status "{platform////}.build" & done; local fails=0; for job in $(jobs -p); do wait ${job} let "fails+=1"; done; for platform in "${platforms[ do cat "/tmp//${platform////}.build"; done; exit ${fails}; else for platform in "${platforms[ do kube::log::status "Building go targets for {targets[ kube::golang::setplatformenvs "{platform} ${usegobuild:-}; done; fi )' exited with status 1 Call stack: 1: kube::golang::buildbinaries(.) 2: hack/build- main(.) Exiting with status 1 !!! Error in '" exited with status 1 Call stack: 1: kube::build::runbuildcommand(...) 2: main(...) Exiting with status 1 make:  [release] Error 1
Note that Centos downloads a bad "docker" binary that is an image with "404 Error". Centos seems abandonned by Kubernetes team... so I needed to make the entire operation with Ansible. And that is not simple at all :)
There was below info from your log: It seems like that the compiler was OOM killed due to memory pressure. AFAIK, consumes a lot of memory. I used to encounter when running it. We're going to close this issue.

Feel free to file a new issue if you fail to run at latest HEAD and you think there is a bug. Thanks!


Question: } fs.IPVar(&s.BindAddress, "insecure-bind-address", s.BindAddress, ""+ <del> "The IP address on which to serve the --insecure-port (set to 0.0.0.0 or :: for listening in all interfaces and IP families).") </del> <ins> "The IP address on which to serve the --insecure-port (set to 0.0.0.0 or :: for listening on all interfaces and IP address families).") </ins> // Though this flag is deprecated, we discovered security concerns over how to do health checks without it e.g. #43784 fs.MarkDeprecated("insecure-bind-address", "This flag will be removed in a future version.") fs.Lookup("insecure-bind-address").Hidden = false

The docs are ambiguous on whether a socket will be limited to either the IPv4 or IPv6 address familiy. E.g., contains This wording in bold suggests that when is 0.0.0.0, the API server will listen on IPv6 addresses too, potentially. That would be incorrect and prevent limiting the address family from the config (to enforce single-stack). According to a report to me, indeed this incorrect behavior is the case. In any case, the wording is ambiguous. Moreover, the source code base contains quite a few literals that aren't accompanied by , suggesting that IPv4 is assumed in some paths. Unless ... Kubernetes has this special algorithm that equates either {0.0.0.0} or {::} with {0.0.0.0, ::}.
See:
/sig docs
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig doc 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 docs
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
that code is used to discover the advertised address if that is not provided, the family of the IP is used for the discovery. The bind address is passed as is to the listener and in golang, 0.0.0.0 and :: behaves the same, it opens a socket in all the addresses in the host The doc is correct
The docs are ambiguous since the behavior rather than being logical, relies on a Go-based implementation detail.
I can't understand why do you consider it ambiguous if that defines exactly what is going to happen. yeah, sometimes this happens unfortunately, but we can't do much about it without breaking compatibility, can we?

All interfaces could mean all interfaces for the specified address family, or all interfaces across address families. The latter is bizarre (non-standard and unproductive), but the actual behavior. What Go does and that Kubernetes exposes this behavior to the user without modification should be documented.
How do you word it then?
Can you explain where the difficulty is in reading and interpreting my comments? For me, it can't be any clearer.
lol, sorry, now I got it, I was confused because I remembered to change some of them to clarify exactly this and I was not realizing this flag was not correct. It is my fault , I honestly don't know why omitted the IP families but you are right, my apologies again , it was some kind of frequency illusion or bias. This is a good first issue for someone that wants to do a contribution to the project, just update this line I think is easy to understand and is coherent with the other flags /help /triage accepted
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : Can you explain where the difficulty is in reading and interpreting my comments? For me, it can't be any clearer. and I was not realizing this flag was not correct. /triage accepted Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I suggest then:
/assign
Hi, I see that there are another instances where "for listening in all interfaces and IP families" appear, like in: I am thinking to include them along with the change on "" file when submitting a PR WDYT?


Question: maxAge := time.Hour * 24 * 365          // one year self-signed certs baseName := fmt.Sprintf("%s_%s_%s", host, strings.Join(ipsToStrings(alternateIPs), "-"), strings.Join(alternateDNS, "-")) <del> certFixturePath := path.Join(fixtureDirectory, baseName+".crt") keyFixturePath := path.Join(fixtureDirectory, baseName+".key") </del> <ins> certFixturePath := filepath.Join(fixtureDirectory, baseName+".crt") keyFixturePath := filepath.Join(fixtureDirectory, baseName+".key") </ins> if len(fixtureDirectory) > 0 { cert, err := ioutil.ReadFile(certFixturePath) if err == nil {

<!-- 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 --Cert path was generated with wrong slashes What happened: Paths generated with path and not filepath do not work always work on windows. will in general work, however volume guid paths will not This issue is related to rancher/k3s
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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


Question: var containers []corev1.Container ctn := corev1.Container{ Name:  fmt.Sprintf("%s-ctn", w.Name()), <del> Image: "gcr.io/kubernetes-e2e-test-images/node-perf/npb-is-amd64:1.0", </del> <ins> Image: "gcr.io/kubernetes-e2e-test-images/node-perf/npb-is:1.0", </ins> Resources: corev1.ResourceRequirements{ Requests: corev1.ResourceList{ corev1.ResourceName(corev1.ResourceCPU):    resource.MustParse("16000m"),

<!-- 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: test/e2enode/perf tests are referring to adm only images, this need to be replaced with multi-arch fat manifest images. ref:
/assign /sig node


Question: failed = failed || f failMu.Unlock() wg.Done() <del> } if *serial { fn(plat) } else { go fn(plat) } </del> <ins> }(plat) </ins> } wg.Wait() if failed {

Background: We recently introduced Guaranteed Pod QOS on jobs running in GCP project (). Introducing limits on jobs naturally started causing some failures, one of which was (). The original memory limit of caused the pod to be unscheduleable, so it was bumped down to () at which point the pod became scheduleable and the job ran successfully (). At that point, after observing metrics, I mistakenly concluded that this was much higher than needed and suggested bumping down again (). This caused the job to continue to run, but to fail on and sometimes . was recently refactored to not depend on GOPATH (). This was a fairly significant change so I looked at the metrics before and after the rewrite was merged. (June 25th) ! (June 27th) ! Memory usage nearly double for post-merge, which appears to be directly related to the rewrite given that on other branches remained relatively constant. This can be affirmed further by the fact that and are failing with the new resource limits, while older release branches are not. I can see a few options for how we may be able to remedy this issue in the short term: Revert the rewrite to get back to lower (yet still very high) memory usage Separate into a separate job to not reduce signal on the rest of Bump memory limits back up to to get this running successfully again for now I plan to look into fixing up but think it would be a good idea to take one of the directions mentioned above if this cannot be remedied quickly. /priority critical-urgent /sig testing /cc
latest run is green
hmm


Question: get-kubeconfig-basicauth if [[ ${GCE_UPLOAD_KUBCONFIG_TO_MASTER_METADATA:-} == "true" ]]; then <del> gcloud compute instances add-metadata "${MASTER_NAME}" --zone="${ZONE}"  --metadata-from-file="kubeconfig=${KUBECONFIG}" || true </del> <ins> gcloud compute instances add-metadata "${MASTER_NAME}" --project="${PROJECT}" --zone="${ZONE}"  --metadata-from-file="kubeconfig=${KUBECONFIG}" || true </ins> fi echo

<!-- 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 --kube-up tries to add metadata to the wrong project. It is trying to add metadata to the prow project running the tests instead of the target project. This is because is missing a kube-up uses the target project to add metadata Don't set/set a different default project and run cluster/kube-up. originally in kubetest hides the project acquired from boskos under the covers by setting it as the default project uncovered as part of migration to kubetest2 xref: /cc
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
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


Question: service := &remoteImageService{timeout: connectionTimeout} <del> if err := service.determineAPIVersion(conn); err != nil { </del> <ins> if err := service.determineAPIVersion(conn, endpoint); err != nil { </ins> return nil, err }

When installing the latest component, got the error: Then the flag , got error: It is confusing to see these error msgs at the first glance, need to make it more clearly. Add the required field validation, and add more supportive error message. Download the latest v1.25.0 binary, and install it with systemd service or just manually start the binary, will reproduce these errors. <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 node
kubelet 1.24+ is not working with the docker, unless using Are you using it? If not, try switching to other available container runtimes. Please re-open if you have further questions /close
Closing this issue. <detailsIn response to : kubelet 1.24+ is not working with the docker, unless using Are you using it? If not, try switching to other available container runtimes. Please re-open if you have further questions Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Yes, I got to know the , so need to add runtime validation by the fix PR: PTAL thanks.


Question: assert.Equal(t, secret1.Name, createdSecret.Name) assert.True(t, secretsEqual(secret1, *createdSecret)) <ins> // Wait for the secret to appear in the informer store err := WaitForStoreUpdate( secretController.secretFederatedInformer.GetTargetStore(), cluster1.Name, getSecretKey(secret1.Namespace, secret1.Name), wait.ForeverTestTimeout) assert.Nil(t, err, "secret should have appeared in the informer store") </ins> // Test update federated secret. secret1.Annotations = map[string]string{ "A": "B",

https://k8s- Failed: TestNamespaceController {namespace} Previous issues for this test:
GetObjectFromChan() is timing out (20s) and returning nil causing the panic. Happens in TestSecretController (and probably TestIngressController) controller as well. https://k8s-
https://k8s- Failed: TestNamespaceController {namespace}
https://k8s- Failed: TestNamespaceController {namespace}
https://k8s- Failed: TestNamespaceController {namespace}
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: TestNamespaceController {namespace}
https://k8s- Failed: TestNamespaceController {namespace}
I have a fix for this in
https://k8s- Failed: TestNamespaceController {namespace}
https://k8s- Failed: TestNamespaceController {namespace}
https://k8s- Failed: TestNamespaceController {namespace}
/cc OWNERS of :
I think this is also related to Issue .
fix is pending


Question: package job import ( <del> "reflect" </del> "testing" "github.com/google/go-cmp/cmp" "github.com/google/go-cmp/cmp/cmpopts" batchv1 "k8s.io/api/batch/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/apimachinery/pkg/labels" </ins> "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/validation/field" genericapirequest "k8s.io/apiserver/pkg/endpoints/request"

The gets very long testing mulitple functions in such as , and . These checks should be performed in dedicated Test functions using table for different scenarios. Target functions and are being as part of The remaining checks should be migrated to these functions. Also, a test function should be to migrate the remaining tests.
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 apps
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Any progress on this? I'm working on and I noticed that has relatively low coverage so I was going to work on getting the coverage up.
I created that is somewhat related to this.
no progess. go ahead please
/assign


Question: } if le.observedTime.Add(le.config.LeaseDuration).After(now.Time) && oldLeaderElectionRecord.HolderIdentity != le.config.Lock.Identity() { <del> glog.Infof("lock is held by %v and has not yet expired", oldLeaderElectionRecord.HolderIdentity) </del> <ins> glog.V(4).Infof("lock is held by %v and has not yet expired", oldLeaderElectionRecord.HolderIdentity) </ins> return false }

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): "lock is held by" "has not yet expired" Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- 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 ): tested on 1.3.5 and 1.3.8 (upgraded today) Environment: Hardware: vmware guest OS: CoreOs 1122.2.0 kernel: 4.7.0-coreos masters: 3 /etc/kubernetes/manifests/kube- looks like this: /etc/kubernetes/manifests/kube-controller- looks like this: What happened: The logs from kube-scheduler and kube-controller-manager are spamming with: The node holding the lock only logs this: What you expected to happen: If this is expected behaviour i would like to be able to supress those messages with --v=2 How to reproduce it (as minimally and precisely as possible): I think it would be sufficient to run scheduler or controller-manager with . etcdctl get registry/services/endpoints/kube-system/kube-controller-manager looks like this: The cluster seems healthy and are scheduling pods correctly.
Same issue with 1.4.4
Just hit this with 1.4.6 as well.
To state that the spam is overwhelming would be a vast understatement. It dominates all log entries by a factor of 7. Please do something about this sooner rather than latter.
This is expected behavior, this appears from standby controllers and schedulers. You can tune these parameter on the binaries.. see leader-election params under --help. closing, not an bug
i cannot find any way to supress this exept turning upp the duration and thats not what we want.

I only dont want to fill elasticerarch with those messages. Why dont they have a proper loglevel there? When this which seems like an error has a higher log level?
K, I'll adjust the log levels.
Does the controller-manager start with by default? Did I understand this correctly that you moved it to ? Does this by chance have anything to do with the log for Ingress controllers as well and will be fixed in 1.6 ?
default depends on provider, some folks default to 3. Needless to say -v 4 "should be" outside the normal range to prevent spamming. verbosity on ingress controller is controlled by how that component is started, but I applied it to the base so it should hit *.


Question: }, // TODO: Figure out the correct value for the buffer size. incoming:              make(chan watchCacheEvent, 100), <del> dispatchTimeoutBudget: newTimeBudget(stopCh), </del> <ins> dispatchTimeoutBudget: newTimeBudget(), </ins> // We need to (potentially) stop both: // - wait.Until go-routine // - reflector.ListAndWatch

Instead of relying on the clock: we should do something similar to the golang rate-limitter is doing:
/sig api-machinery /priority important-longterm
/help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help 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
Hi, I would like to help on this.
/assign Thanks! /triage accepted
can you please provide more context or some guidance on how to proceed?
Sorry for delayed response. - what we should do is to basically: instead of having an additional go-routine that every 1s refreshes the budget change it roughly to: (a) keep the value of budget and the last time when we were refreshing it (b) on takeAvailable method: first recompute takeAvailable, which will be "min(current budget + time elapsed since last refresh * refreshValue, maxAllowedBudget) update last refresh time to now return that value [We also would need to update the existing tests to match the new logic.] - would you be willing to work on it?
-- I can take this up. One question I had was should the method rely on or the current time should be passed on by the caller like in the following: Having the caller pass the time completely removes the dependency on the clock at least for the implementation.
/assign
Let's may be start with: passing on budget creation to it relying on
-- thank you for the thoughts. I drafted a rough implementation in which still depends on . I will make the change as you suggested and rely solely on a instance passed on initialization. I have to rethink the testing strategy a bit, possibly using a .
Yes - FakeClock is the way to test this.
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
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-contributor-experience at . /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
Reopening - this didn't happen.


Question: } if isGuaranteed && len(requests) == len(limits) { <del> return corev1.PodQOSGuaranteed </del> <ins> return core.PodQOSGuaranteed </ins> } <del> return corev1.PodQOSBurstable </del> <ins> return core.PodQOSBurstable </ins> }

<!-- 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: In kubectl library, logic is not the same as the one in What you expected to happen: logic should be the same. How to reproduce it (as minimally and precisely as possible): Create a pod with a guaranteed QoS class and a best-effort QoS initcontainer. Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cli
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
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-contributor-experience at . /lifecycle stale
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]:
It seems to be duplicate functions here.
The intention for duplicates is coming from the fact that kubectl can't rely on packages from kuberentes main repository. Either way they should both be identical except for the fact that the internval version will use internal APIs, whereas kubectl's version will use versioned.

feel free to open a PR updating kubectl version updating it to match both versions.
/triage accepted /assign
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: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. 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 closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] 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: set = obj.(*apps.StatefulSet) } if set.Status.Replicas != 3 { <del> t.Error("Falied to scale statefulset to 3 replicas") </del> <ins> t.Errorf("set.Status.Replicas = %v; want 3", set.Status.Replicas) </ins> } *set.Spec.Replicas = 5 fakeResourceVersion(set)

Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Unit test error message match the conventional Go style: For example: if got, want := set.Status.Replicas, 3; got != want { t.Errorf("set.Status.Replicas = %v; want %v", got, want) }
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig testing
/assign
/reopen


Question: // only return the user provided mode if at least one was valid if len(mode) > 0 { <del> klog.Warningf("the default kube-apiserver authorization-mode is %q; using %q", strings.Join(defaultMode, ","), strings.Join(mode, ","), ) </del> <ins> if !compareAuthzModes(defaultMode, mode) { klog.Warningf("the default kube-apiserver authorization-mode is %q; using %q", strings.Join(defaultMode, ","), strings.Join(mode, ","), ) } </ins> return strings.Join(mode, ",") } } return strings.Join(defaultMode, ",") } <ins> // compareAuthzModes compares two given authz modes and returns false if they do not match func compareAuthzModes(a, b []string) bool { if len(a) != len(b) { return false } for i, m := range a { if m != b[i] { return false } } return true } </ins> func isValidAuthzMode(authzMode string) bool { allModes := []string{ kubeadmconstants.ModeNode,

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: when i installed k8s using kubeadm and my custom config like then output is It is a bug that the default value(Node,RBAC) is entered but a warning message is displayed. A function must be to compare two string slices. What you expected to happen: If the default value and custom value are the same, no warning message should be displayed. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 17.3 Install tools: kubeadm /area kubeadm /feature bug /sig cluster-lifecycle
/lifecycle active