Question: package editor import ( <del> "fmt" </del> "io" "os" <del> "os/exec" "path/filepath" </del> "runtime" "strings" <del> "k8s.io/klog/v2" "k8s.io/kubectl/pkg/util/term" </del> ) const (

<!-- 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!--I was trying to use a different editor than notepad on windows to be used by by setting the environment variable. Doing this was non trivial and the following did not work all resulting in different errors. What happened: What you expected to happen: I should be able to use normal windows paths, either by quoting them, or not. the workaround is to use a short filename however short paths are optional and may not always be created. () How to reproduce it (as minimally and precisely as possible): try and set an editor on windows where there is a space in the name of the command. Anything else we need to know?: Environment: Kubernetes version (use ): v1.10.3 Cloud provider or hardware configuration: N/A this is client side issue OS (e.g. from /etc/os-release): windows 10 1803 Kernel (e.g. ): :-) Install tools: Others:
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
In case anyone wants an answer, it needs two things: (or ) into system PATH environment variable EDITOR=notepad2 -w (or EDITOR=code -w)
Currently there is no way how to pass path with spaces on Windows with or environment variables. Pull Request addresses this issue. With the fix, you would be able to specify the following: and when is in your , you could do as well: or (this is current workaround for the problem)


Question: api "k8s.io/kubernetes/pkg/apis/core" eventratelimitapi "k8s.io/kubernetes/plugin/pkg/admission/eventratelimit/apis/eventratelimit" "k8s.io/kubernetes/plugin/pkg/admission/eventratelimit/apis/eventratelimit/validation" <ins> "k8s.io/utils/clock" </ins> ) // PluginName indicates name of admission plugin.

<!-- 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 --While working on , I realized that implements another rather than using the one already implemented in I'm not sure why this was re-implemented, but if we can migrate to using itself, then the code in the package can be cleaned up significantly (as part of ). I expect areas of the codebase that make use of a real clock to consistently use instead of re-implementing it NA Another (slightly) related issue: 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:
/remove-kind bug /kind cleanup /sig auth
/cc fyi
/assign
Better yet, use the one in
/sig api-machinery
/assign /triage accepted


Question: if rOpts != nil { hc.Resources = dockercontainer.Resources{ Memory:     rOpts.GetMemoryLimitInBytes(), <del> MemorySwap: -1, </del> <ins> MemorySwap: dockertools.DefaultMemorySwap(), </ins> CPUShares:  rOpts.GetCpuShares(), CPUQuota:   rOpts.GetCpuQuota(), CPUPeriod:  rOpts.GetCpuPeriod(),

What happened: Latest kubelet + Windows Docker version 1.14.0-dev refused to start any containers, error output: "invalid option: Windows does not support MemorySwap" How to reproduce it (as minimally and precisely as possible): It's always reproducible with Windows Docker 1.14.0-dev + latest kubelet code base. Anything else do we need to know: It didn't happen for Windows Docker 1.12.2-cs2-ws-beta. The reason behind the issue was because new code was for Windows Docker to check Resources parameters, it doesn't accept a non-zero value for MemorySwap: But kubelet was default to set an unlimited (-1) value. The issue was gone in my setup after applied a private fix to disable MemorySwap by set it to zero for Windows.


Question: } secretWatch.Modify(&secret1) updatedSecret2 := GetSecretFromChan(cluster1UpdateChan) <del> assert.NotNil(t, updatedSecret) assert.Equal(t, secret1.Name, updatedSecret.Name) </del> <ins> assert.NotNil(t, updatedSecret2) assert.Equal(t, secret1.Name, updatedSecret2.Name) </ins> assert.Equal(t, secret1.Namespace, updatedSecret.Namespace) assert.True(t, secretsEqual(secret1, *updatedSecret2), fmt.Sprintf("expected: %v, actual: %v", secret1, *updatedSecret2))

https://k8s- Failed: TestSecretController {secret} Previous issues for this test:
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
This flake seems to have started after merged (just looking at the merge time line). Can you please take a look?
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
Sorry just saw this, looking at it now
Sent for a fix
nice thanks


Question: } func (o *DescribeOptions) Run() error { <del> r := o.Builder. </del> <ins> r := o.NewBuilder(). </ins> Unstructured(). ContinueOnError(). NamespaceParam(o.Namespace).DefaultNamespace().AllNamespaces(o.AllNamespaces).

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: I run and I got Running with shows What you expected to happen: How to reproduce it (as minimally and precisely as possible): With Kubernetes master branch and in different terminal on the same machine Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: VM via libvirtd OS (e.g. from /etc/os-release): Fedora 27 with golang-1.10.1-1.fc29.x86_64 from rawhide Kernel (e.g. ):Install tools: ?? Others:
/sig cli
/assign
/assign


Question: "//vendor/github.com/onsi/ginkgo/reporters:go_default_library", "//vendor/github.com/onsi/gomega:go_default_library", "//vendor/k8s.io/klog:go_default_library", <ins> "//vendor/k8s.io/utils/net:go_default_library", </ins> ], )

<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: https://k8s-(IPv6),%20master%20(dev) Which test(s) are failing: [sig-scheduling] SchedulerPredicates [Serial] validates that there is no conflict between pods with same hostPort but different hostIP and protocol [Conformance] Since when has it been failing: Testgrid link: https://k8s-(IPv6),%20master%20(dev) Reason for failure: The tests checks for 0.0.0.0 that is IPv4 only Anything else we need to know: Probably I should check with SIG-Testing how can we add an ipv6 job and update the KEP accordingly EDIT Probably I should check with SIG-Testing how can we add an ipv6 job as part of the k/k presubmits, and update the KEP accordingly
/assign /cc
/sig scheduling

<!-- Please only use this template for submitting enhancement requests --What would you like to be : Introduce a mechanism that allows specifying the IP protocol version used in the e2e testing. Why is this needed: This is a followup on , my understanding is that in order to discriminate between IPv4 or IPv6 we have to use the test labels and this adds complexity to the testing automation and doesn't allow to send this information to the context of the tests. Having a mechanism to specify the IP protocol will simplify the testing for IPv4 and IPv6 and will allow reusing most of the code.
/sig testing /cc /assign Does this make sense? If affirmative, what should be the best way to add this functionality? Checking the code I think that or can provide this, don't know if checking some of the cluster config parameters, ...
the testing-commons group (sig-testing) maintains the framework, but ideally the decision on how to proceed in terms of adding ipv6 detection should come from sig-network. possibly having this as agenda for a sig-network meeting is a good start, then discussing it in a testing-commons meeting. /sig network the linked issue is a big one, so i don't have all the context here. but IMO existing tests should just work for ipv6 without the requirement for a new "IPV6" tag in test names. dual-stack or protocol specific tests should have their descriptions contain the details properly (i.e. what is this test doing) we might want to add an utility function under: (there is a PR to move it BTW ) then such an utility might be useful only to tests that need to detect the protocol. one of the goals is to refactor the code in testcontext / framework, so adding this logic there is less preferred.
/area e2e-test-framework
I think that we can add an option to test_context to specify the cluster IP family the same way that exists one for the cloud provider this is simpler because when setting up the CI jobs you will know beforehand what IP family you want to test, it also will allow reusing all the e2e code for IPv6 and Dual Stack (cc: and by default will be IPv4, so it´s backward compatible.
Being able to override and specify exactly what you want the test to beleive about your cluster is nice, but ideally it should generally work without specifying more flags.

Surely we can detect this?
I was thinking during some time about this, detecting the IP family is very simple having IPv4 or IPv6 only clusters, but with the introduction of dual stack I´m afraid about the supportability and reliability of the autodetecting mechanisms in the long term. If you see the dual stack PRs there are still a lot of unknowns about the cluster behavior. My point is, let´s have something first stable that works and is simple, and once dual stack is implemented, we can replace the flag with a function in the framework . I guess that migrating from a flag variable to a function is straight forward, is just replacing by , what do you think?
in is as part of the context. do you mean adding as a function which will auto-detecting the ip family. less flags for the framework binary is preferred.
once we have this I will open a new issue to start cleaning up and , we no longer need to discriminate based on tags


Question: func init() { utilruntime.Must(logsapi.AddFeatureGates(utilfeature.DefaultMutableFeatureGate)) <ins> utilruntime.Must(features.AddFeatureGates(utilfeature.DefaultMutableFeatureGate)) </ins> } const (

As per, , wire up for KCM
/sig instrumentation
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/sig instrumentation


Question: }, }, required: []corev1.ResourceName{corev1.ResourceMemory}, <del> err:      `must specify memory`, </del> <ins> err:      `must specify memory for: bar,foo`, }, "container resource missing multiple": { pod: &api.Pod{ Spec: api.PodSpec{ Containers: []api.Container{{ Name:      "foo", Resources: api.ResourceRequirements{}, }, { Name:      "bar", Resources: api.ResourceRequirements{}, }}, }, }, required: []corev1.ResourceName{corev1.ResourceMemory, corev1.ResourceCPU}, err:      `must specify cpu for: bar,foo; memory for: bar,foo`, </ins> }, } evaluator := NewPodEvaluator(nil, clock.RealClock{})

I deployed a pod with and on a namesapace with a set with and elements and I get the error: The pod to be deployed Create a new namespace Create (using a manifest file named resource-quota-) and verify a named compute-resources Content of the resource-quota- file Create (using a manifest file named ) a pod named high-priority with the and for both and . Content of the file The pod is deployed correctly if I delete the <details</details<detailsaws </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig Scheduling
/wg API Expression
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /wg API Expression 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
/wg <API Expression
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /wg <API ExpressionInstructions 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
/wg "API Expression"
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /wg "API Expression" 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
/wg APIExpression
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /wg APIExpression 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
/wg wg-api-expression
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /wg wg-api-expression Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
hey, v1.18.20 is out of support now, you should try with a newer version. Besides, I tried with an old version v1.18.19, but worked as well.
Are u using some mutating webhook which inject some sidecar into the pod without setting resources fields?
It's probably that, but IDK which WebHook is doing that. The feature you suggested would really help.
hi the fix pr has been merged, maybe u could use it to locate which container is causing the problem.
Thanks


Question: "fmt" "path" "path/filepath" <del> "sort" "strings" </del> "k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/types"

/kind bug What happened: When using the downward api to render a file via a volume mount from and annotation that has newlines in it, it appears that the file is rendered with the content sorted by line. A concrete example: Expected is that would contain But it does not The above is obviously contrived, this is creating a problem for my team when we are trying to use the downward api to render a yaml file (which obviously has newlines) Environment: Kubernetes version (use ): 1.9.7 Cloud provider or hardware configuration: aws OS (e.g. from /etc/os-release): centos
/sig apps Not sure about the sig here
/sig node /sig storage
Just tested it on 1.10.5 and this bug still happens.
thanks!


Question: glog.Errorf("Encountered error for creating alpha feature gate: %v", err) } cloudConfig.AlphaFeatureGate = alphaFeatureGate <ins> } else { // initialize AlphaFeatureGate when no AlphaFeatures are configured. alphaFeatureGate, err := NewAlphaFeatureGate([]string{}) if err != nil { glog.Errorf("Encountered error for initializing alpha feature gate: %v", err) } cloudConfig.AlphaFeatureGate = alphaFeatureGate </ins> } // retrieve projectID and zone

<!-- 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: An error occured when creating a PersistentVolumeClaim on a single node cluster created with kubeadm. The cluster is created by following The PersistentVolumeClaim remains Pending and we see the following errors in the log of the kube-controller-manager: What you expected to happen: A Persistent Volume is created and ready to use How to reproduce it (as minimally and precisely as possible): create a single node cluster on gce with kubeadm, eg create a StorageClasscreate a PersistentVolumeClaim Anything else we need to know?: We are also having this issue on a cluster we try to create from scratch on GCE using CentOS. Environment: Kubernetes version (use ): 1.8.3 Cloud provider or hardware configuration: GCP OS (e.g. from /etc/os-release): Ubuntu 17.04 Kernel (e.g. ): Linux kubeadm-single-node-cluster 4.10.0-38-generic -Ubuntu SMP Tue Oct 10 13:24:27 UTC 2017 x8664 x8664 x86_64 GNU/Linux Install tools: kubeadm Others:
/sig gcp /sig storage
thanks for reporting this! I send a PR to fix this:
/cc


Question: } sc.AllowedTopologies = newTopologies } <ins> sc.AllowedTopologies = t.replaceFailureDomainsToCSI(sc.AllowedTopologies) </ins> sc.Parameters = params

This test fails on Kubernetes cluster in "westus" region (without any number) and with CSI migration enabled: Error: failed to provision volume with StorageClass "e2e-topology-84vk7sp": error generating accessibility requirements: topology map[] from selected node "ci-op-9j1nby77--9zlwv-worker-westus-ljw4g" is not in requisite: [map[]] StorageClass generated by the test: PVC created by the test: <details</detailsLabels of the selected node: The external-provisioner does not even call the CSI driver and reports this event: The volume should get provisioned. See above, "westus" region with no availability zones seems to be the key. It looks like the translation from in-tree StorageClass to CSI one translates topology requirements to , but the CSI one expects <details</details<details</details<detailsOpenShift 4.10 </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
/priority important-soon cc
/sig storage
per https://kubernetes-, is not a zone, it's actually a fault-domain num. valid zone format is , could you change the storage class with setting, and try again? Thanks.
o, if "westus" region does not support zone, then I think you should test setting in another zone, make sure you have created a zoned node first.
I have as SC that works without CSI migration, with CSI migration it does not work. That's a regression. It should not matter if the SC is somehow odd. The labels are selected by test code, some other production code might use these labels too.
Out of curiosity, how reliable are zone numbers in Azure? I can see .. in a region with zones. If is used only in regions without a zone, then the translation can translate to , which the CSI driver expects.
I would say that's a wrong usage for zone.

following config would create a pv that could only be scheduled to a non-zone node with fault domain , if there is no node supports zone, then should not be set.
But nodes report that they are in , therefore it make sense to accept the same input in StorageClass.
if we translation "0" to "", then the pv created by that sc could be scheduled to any non zone node with any fault domain. That's a corner case that cluster is not in zone, and user still wants to set in sc
I am not sure I understand. If I provision a CSI volume in the westus cluster, its PV gets anyway: I have the cluster only with nodes in "westus" region, so all of them are without any zone. What would the CSI driver do if there were nodes in "westus" and say "ukwest", which does not have zones either? I can't test that setup easily, but I think the driver would report for both of them anyway, hence translating to does not make things worse, I think.
/sig storage /sig cloud-provider /area provider/azure
can you please check my previous comment? In what cases would be translating "0" to "" worse than the translation code we have today?
it's not worse or better, a single num () is actually not a valid zone, such in sc is actually not valid.
I mean we could translate the single digit to to make it work while the usage is wrong.
/sig storage
/sig cloud-provider


Question: PATH="${GOBIN}:${PATH}" # Install tools we need, but only from vendor/... <del> go install ./vendor/github.com/bazelbuild/bazel-gazelle/cmd/gazelle go install ./vendor/github.com/kubernetes/repo-infra/kazel </del> <ins> go install k8s.io/kubernetes/vendor/github.com/bazelbuild/bazel-gazelle/cmd/gazelle go install k8s.io/kubernetes/vendor/github.com/kubernetes/repo-infra/kazel </ins> touch "${KUBE_ROOT}/vendor/BUILD" # Ensure that we use the correct importmap for all vendored dependencies.

I am trying to update aws-sdk-go dep version, following the guide in I checkout to the master branch, and I use these commands: But all the "BUILD" files in the "vendor" folder are deleted. What did i do wrongWhat are the right steps? When I use the same commands in the "release-1.9" branch, all these files are not changed.
/sig contributor-experience
I came across this recently as well. same for me. /kind bug
Looks like is the culprit? /cc
you didn't do anything wrong. :) Updating bazel files again will solve the problem for now: But we should either fix the script or update the instructions.
This should run already as a part of godep- Is that step producing any errors?
There are not any error message. Here is the output:
yeah, I can reproduce this - running yields lots of missing files. still investigating, but I'm guessing the files are being generated in the generated gopath (from , rather than the repo root.
... though that shouldn't matter, since it's just a symlink. hm.
I think I found it.. I think it has to do with the fact that the init script uses to strip out symlinks, which doesn't play nice with . I'm testing a fix locally.. if it works, I'll push a PR. I don't know if removing the flag will break other things tho.
Nope. That didn't work. Next test I'm running is a revert of .
after running , if I then run , it still doesn't regenerate the files, which makes me think doesn't like running in the artificial gopath.
oh, I think might full resolve either the or its working directory, which causes problems since we have an artificial gopath. cc if he's seen this before.
seems to need to run from the real (or at least a subdir of the real ). seems to need to run from a valid - i.e. must be in . If I to the real in , works properly, but then explodes.
Just a straight revert of that last change didn't work either. I wonder how long this has been broken for..
When Gazelle starts, it locates the repository root (if is not given, it's the nearest parent directory containing a file named ), then evaluates symlinks in that path.

When Gazelle walks the directory tree, it only follows symlinks to directories that point outside the repository. It checks that by evaluating symlinks, then checking whether the resolved path has the resolved repository root as a prefix. This is all in service of avoiding symlink cycles and preventing the same directory from being visited on more than one path (which would cause incorrect or inconsistent attributes).
I'd guess since .
So I think passing to Gazelle would fix it. Then it won't go looking outside the GOPATH for the WORKSPACE file.
alone doesn't seem to be helping, at least not if I set it to the real repo root. and the files under are still missing. What does seem to help is if I to the real repo root before calling .
note also that it seems that gazelle isn't walking any of the tree when run under ; it's not just that's affected.
Easiest way to reproduce: out kubernetes/kubernetes some file in the tree (e.g. ) that the file you removed wasn't regenerated that the file was now regenerated
yeah, gazelle really doesn't like the symlink. super hacky fix that is probably not a good idea here:
Copying my comment from slack:
Please try again with a fresh master. Fix was merged in last night.
It's ok now!


Question: } // Returns the full path to the loop device associated with the given path. <del> func getLoopDevice(path string, exec utilexec.Interface) (string, error) { </del> <ins> func getLoopDevice(path string) (string, error) { </ins> _, err := os.Stat(path) if os.IsNotExist(err) { return "", errors.New(ErrNotAvailable)

I tried to use a local volume block device in minikube. Its trying to call losetup with the -j option and its failing as the losetup in minikube does not provide this option. This may effect other distro's as well. The end result is lock block devices don't work on the platform.
/sig storage
Probably caused by this code:
Did a strace on losetup -j. looks like the same info can be had by: cat /sys/block/loop0/loop/backing_file
Just had the same problem with Ceph cluster creation in minikube, the osd-prepare doesn't start because of this:
FYI: has the same problem in minikube. Replacing the /sbin/losetup busybox link with a "real" losetup helped for now, but isn't a solution of course.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/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-testing, kubernetes/test-infra and/or . /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
/remove-lifecycle stale
/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 </details


Question: return GetPodStartTime(pod1).Before(GetPodStartTime(pod2)) } <del> // PatchPod calculates the delta bytes change from <old> to <new>, </del> <ins> // PatchPodStatus calculates the delta bytes change from <old.Status> to <newStatus>, </ins> // and then submit a request to API server to patch the pod changes. <del> func PatchPod(cs kubernetes.Interface, old *v1.Pod, new *v1.Pod) error { oldData, err := json.Marshal(old) </del> <ins> func PatchPodStatus(cs kubernetes.Interface, old *v1.Pod, newStatus *v1.PodStatus) error { if newStatus == nil { return nil } oldData, err := json.Marshal(v1.Pod{Status: old.Status}) </ins> if err != nil { return err } <del> newData, err := json.Marshal(new) </del> <ins> newData, err := json.Marshal(v1.Pod{Status: *newStatus}) </ins> if err != nil { return err }

I am aware that the following is a corner case that does not occur in day-to-day business, but it took me a long while to debug, so I thought I would raise this issue to save others from the same pain. Deploying the following job with empty imagePullSecrets leads to it being stuck in forever, and status looking the following way: The status should look something like: This would allow my autoscaler to kick in and add the corresponding nodes. Run Kubernetes version (use ):Cloud provider or hardware configuration: AWS EKS OS (e.g: ): MacOSX 11.3 Kernel (e.g. ): Darwin Kernel Version 20.4.0 Install tools: brew
/sig scheduling (I assume)
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig scheduling (I assume) 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 Scheduler log
Should we instead forbid empty items in ? Is there a use case for using as ?
For me personally that would be totally fine I had no use case for it. It was more produced by chance as I wasn't aware that I had to handle the case separately. An error which led to an early failure would have been fine by me and solved all my problems in tracking this down.
/assign as
Forbidding it is the appropriate solution. However, we can't do it for backwards compatibility of the API. /triage accepted


Question: return &drivers.Hooks{ Pre: func(ctx context.Context, method string, request interface{}) (reply interface{}, err error) { switch expectedExpansionStatus { <ins> case expansionFailedMissingStagingPath: expansionRequest, ok := request.(*csipbv1.NodeExpandVolumeRequest) if ok { stagingPath := expansionRequest.StagingTargetPath if stagingPath == "" { return nil, status.Error(codes.InvalidArgument, "invalid node expansion request, missing staging path") } } </ins> case expansionFailedOnController: expansionRequest, ok := request.(*csipbv1.ControllerExpandVolumeRequest) if ok {

When a pod is quickly deleted and re-created on a node, it may not be necessary to unstage the volume and in which case only node-publish is called for the volume. When this happens - stagepath won't be set for RPC call because volume was not staged even though, volume does have capability. We should try and fix this behaviour so that - nodestagepath is always set in RPC call. We should try and fix this behaviour so that - nodestagepath is always set in RPC call. Quickly delete and recreate a pod No response master Any No response_ <details</details<details</details<details</details
/sig storage /triage accepted


Question: createPodSetsOpcode      = "createPodSets" churnOpcode              = "churn" barrierOpcode            = "barrier" <ins> sleepOpcode              = "sleep" </ins> extensionPointsLabelName = "extension_point" // Two modes supported in "churn" operator.

Note: this issue should be viewed in the context of . What would you like to be : Currently we support three types of ops: , , . This issue proposes adding a op that would simulate user action by causing the main thread to sleep. Note: I don't have a use-case for this in mind, but one can come up with trivial and contrived examples easily. Why is this needed: Not clear at this time. This is just an open discussion where others can chime in with whether this will be useful. /sig scheduling /sig testing (Not assigning myself until we can figure out if/how we want this.)
when you get a chance, can you group all enhancements issues relate to the new benchmark framework under one issue with a task list.
/assign
see
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
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
/unassign
I'd like to take this one /assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-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]:
/remove-lifecycle rotten
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
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
There is still an active pull request for this issue. /remove-lifecycle rotten /reopen
Reopened this issue. <detailsIn response to : There is still an active pull request for this issue. /reopen </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: "net/http" "net/url" "testing" <ins> "k8s.io/apiserver/pkg/endpoints/request" </ins> ) func TestCleanVerb(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 --the issue stays in the CleanScope function where all GET calls will end up with scope "namespace" and end up with verb "LIST" 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: /assign /sig api-machinery
/triage accepted


Question: aws_account="721322707521" # TODO: we could use tags for the image if [[ -z "${AWS_IMAGE_NAME:-}" ]]; then <del> AWS_IMAGE_NAME="k8s-1.2-debian-jessie-amd64-hvm-2016-02-24-ebs" </del> <ins> AWS_IMAGE_NAME="k8s-1.2-debian-jessie-amd64-hvm-2016-03-05-ebs" </ins> fi AWS_IMAGE=`aws ec2 describe-images --owner ${aws_account} --filters Name=name,Values=${AWS_IMAGE_NAME} --query Images[].ImageId --output text` if [[ -z "${AWS_IMAGE-}" ]]; then

Master failed to restart on Debian Jessie. Console logs showed: I have no idea where nobootwait is coming from though...
Aha... it's a bug in jessie's cloud-init. I have a fix, will produce a PR once verified.
Fix in


Question: } for _, test := range tests { t.Run(test.name, func(t *testing.T) { <ins> assignDefaultStartTime(test.pods) </ins> nodes := []*v1.Node{} for _, n := range test.nodes { node := makeNode(n, 1000*5, priorityutil.DefaultMemoryRequest*5)

What would you like to be : TestSelectNodesForPreemption should assign pod.Status.StartTime for test Pod Why is this needed: We can see the following in the output of TestSelectNodesForPreemption: This is due to missing assignment to Status.StartTime
/sig scheduling
/assign


Question: if !reflect.DeepEqual(vol.VolumeContext, test.expectedVolumeContext) { t.Errorf("csi server expected volumeContext %+v, got %+v", test.expectedVolumeContext, vol.VolumeContext) } <ins> // ensure data file is created dataDir := filepath.Dir(mounter.GetPath()) dataFile := filepath.Join(dataDir, volDataFileName) if _, err := os.Stat(dataFile); err != nil { if os.IsNotExist(err) { t.Errorf("data file not created %s", dataFile) } else { t.Fatal(err) } } data, err := loadVolumeData(dataDir, volDataFileName) if err != nil { t.Fatal(err) } if data[volDataKey.specVolID] != csiMounter.spec.Name() { t.Error("volume data file unexpected specVolID:", data[volDataKey.specVolID]) } if data[volDataKey.volHandle] != csiMounter.volumeID { t.Error("volume data file unexpected volHandle:", data[volDataKey.volHandle]) } if data[volDataKey.driverName] != string(csiMounter.driverName) { t.Error("volume data file unexpected driverName:", data[volDataKey.driverName]) } if data[volDataKey.nodeName] != string(csiMounter.plugin.host.GetNodeName()) { t.Error("volume data file unexpected nodeName:", data[volDataKey.nodeName]) } if data[volDataKey.volumeLifecycleMode] != string(csiMounter.volumeLifecycleMode) { t.Error("volume data file unexpected volumeLifecycleMode:", data[volDataKey.volumeLifecycleMode]) } </ins> }) } }

Instantiating the interface causes the creation of pod local volume directory and json data file and not - This causes a problem where is failed (and as a result never gets called) then those pod local volume directories will never be cleaned up. /sig storage cc
Looks like is the PR that introduced this change and moved data file creation calls to .
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
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
/repen /remove-lifecycle stale
/reopen
Reopened this issue. <detailsIn response to : /reopen </details
/remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
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
/reopen /remove-lifecycle rotten
Reopened this issue. <detailsIn response to : /reopen /remove-lifecycle rotten 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
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-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
/reopen /lifecycle frozen
Reopened this issue. <detailsIn response to : /reopen /lifecycle frozen 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
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: if !reflect.DeepEqual(expectedVolumeMounts, pod.Spec.Containers[0].VolumeMounts) { t.Errorf("unexpected volumes: %s", diff.ObjectReflectDiff(expectedVolumeMounts, pod.Spec.Containers[0].VolumeMounts)) } <ins> // ensure result converted to v1 matches defaulted object v1PodOut := &v1.Pod{} if err := v1defaults.Convert_core_Pod_To_v1_Pod(pod, v1PodOut, nil); err != nil { t.Fatal(err) } v1PodOutDefaulted := v1PodOut.DeepCopy() v1defaults.SetObjectDefaults_Pod(v1PodOutDefaulted) if !reflect.DeepEqual(v1PodOut, v1PodOutDefaulted) { t.Error(cmp.Diff(v1PodOut, v1PodOutDefaulted)) } </ins> } func TestFetchesUncachedServiceAccount(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 --my mutating webhook calculates a hash of the , allows reinvocation; no side effects my validating webhook validates the hash of the and fails because the has changed webhook auditing indicates that my webhooks are the only ones processing the upon serializing the spec to JSON for both the mutator and validator, the only change is related to the "kube-api-access-xyz" projected volume, managed by a built-in k8s admission plugin the aforementioned plugin does not appear to mutate the reinvocation context, even through it may mutate a pod (robbing other mutators of the chance to observe the change): it appears that both my hooks see the injected volume, but the validation hook sees the injected SA volume with a "defaultMode" field set, and my mutation hook does NOT see this field set my validation hook should calculate the same hash mutating, validating webhooks are implemented atop controller-runtime v0.8.3, pod objects are being decoded into targets Kubernetes version (use ): 1.21.3 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 api-machinery
cc
interesting... defaults are applied when going from versioned → internal server decodes v1 Pod request → applies defaults → converts to internal Pod -in admission control operates on the internal Pod service account admission injects the kube-api-access volume admission is called internal Pod → converts to v1 Pod → serializes → sends to mutating webhook mutating webhook returns patch patch is applied to v1 Pod JSON resulting v1 Pod JSON is decoded → defaults applied (defaultMode is set on the api-token volume here) → converted to internal Pod webhook admission is called internal Pod → converts to v1 Pod → serializes → sends to validating webhook That means if any built-in admission plugin sets up data that would be modified by applying defaulting to the pod, the data sent to mutating webhooks will be missing those applied defaults until the first mutating webhook that returns a patch that changes the object
Possible solutions: defaults are applied to the internal → versioned object before invoking webhooks built-in admission always populates data matching default values for unset fields
As an aside, I'm not sure what you're using the hashing for, but be aware that hashing is fragile in the presence of defaults and new fields over time. A hash you add to a pod spec in one release might not match a hash computed in a different release, or with different admission in place.
/triage accepted /assign /priority backlog


Question: fs.IPVar(&s.BindAddress, "bind-address", s.BindAddress, ""+ "The IP address on which to listen for the --secure-port port. The "+ "associated interface(s) must be reachable by the rest of the cluster, and by CLI/web "+ <del> "clients. If blank or an unspecified address (0.0.0.0 or ::), all interfaces will be used.") </del> <ins> "clients. If blank or an unspecified address (0.0.0.0 or ::), all interfaces and IP address families will be used.") </ins> desc := "The port on which to serve HTTPS with authentication and authorization." if s.Required {

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: // target pool to use local traffic health check. glog.V(2).Infof("Updating from nodes health checks to local traffic health checks for service %v LB %v", apiService.Name, loadBalancerName) if supportsNodesHealthCheck { <del> hcToDelete = makeHttpHealthCheck(makeNodesHealthCheckName(clusterID), GetNodesHealthCheckPath(), GetNodesHealthCheckPort()) </del> <ins> hcToDelete = makeHttpHealthCheck(MakeNodesHealthCheckName(clusterID), GetNodesHealthCheckPath(), GetNodesHealthCheckPort()) </ins> } tpNeedsUpdate = true }

A couple of gce-scale-performance runs failed due to failing to delete the network, which in turn was due to a couple of leaked firewall-rules (I manually deleted the network later to fix it): Ref: https://k8s- cc (assigning to you, feel free to reassign as apt)
I digged up a bit and seems like the firewall is created by the service-controller as part of , which should've been deleted in but wasn't. Feel free to close the bug if you think it's just a one-off failure.
Took a quick look, both and runs have these firewall rules initially but doesn't, which indicates something happen in the run. But oddly there is no build log, logs in artifacts are empty as well. Likely that run is badly broken so cluster got terminated forcibly in the middle, and resource are leaked. Will observe this suite a bit longer. /assign /unassign
I think it wasn't caused by this job. We're running this one () and on alternating days in the project. And they both create clusters (network, etc) with the same name. And I think of gce-scale-correctness leaked the firewall (and hence the network) as it runs some correctness tests around load-balancer. That likely caused this job to fail.
Ref The resource leak was likely caused by test timeout --- GCE operations took too long to finish and the cluster was terminated ahead. Because heathcheck and firewall cleanup in gce controller are coupled with targetpool deletion, deleting cluster while targetpool deletion is pending will leak the resources.
Fyi - this affected gce-scale-performance again (ref: run 35 of https://k8s-): Is there a way to make sure they get deleted even in case of a timeout? I have a dirty hack in my mind - of deleting those as part of kube-down. Maybe you have some better suggestions?
Consider the frequency this happens, I think it makes sense to implement some cleanup logic within the e2e test. Will give it a try.
Turned out we already have such cleanup logic, it is just we use an incorrect firewall name and forget to cleanup node health check resources as well. Sent to fix.
Thanks for fixing!
Sure thing, thanks for reporting!
Reopening as it seems like the issue is not fixed yet.

For e.g run-16 of https://k8s- failed due to this: This is also affecting our job, both of them being release-blocking jobs. Could you PTAL?
By any chance we could make and use different names so that it will be easier to target the leaking point? Also, in that way one leaking job will not affect the other. Or maybe we could also make different runs use different network names? The scalability job is expensive so it might be great if newer runs wouldn't be affected by the leaked resources from previous run. I haven't figured out how exactly and when the resource are leaked, but given that the operation cycle of service controller and e2e test process proceed in an asynchronous manner (plus always fail ESIPP tests ), there might be chances we will leak resource even after we put cleanup logic in e2e test. Will take a deeper look later. Also what you suggested before --- deleting those as part of kube-down --- may also be a viable solution.
I thought about this option, but it's better for them to share the same name for network and other resources (instance-prefix, etc) because that way we ensure that if one of them leaks some resources, the other will delete them during it's startup. Else we'll run out of quota in the scale-testing project (for e.g wrt routes or VMs) by trying to start another 5k-node cluster while the previous one still exists. I went to pantheon and deleted the network and that went through successfully (though fails). Wonder if the delete command in kube-down can be modified to delete all sub-resources of the network (like firewalls, etc) before deleting it?
Sounds reasonable to me. We may need yet another env to trigger it? As deleting everything correlated to that network sounds a bit dangerous.
Well, took another look, seems like the actual thing that prevented us from deleting the network was mostly firewall rules, and deleting those sounds safe enough if we are going to delete the network anyway. Will try to make a PR for this.
Thanks for fixing the issue with firewalls. However seems like the latest run of gce-scale-correctness still leaked the network (but doesn't seem due to firewall this time): ref: https://k8s-
I thought we're deleting the subnets in this case too when we're using custom subnets mode.

Yep, we are supposed to. I think the scale CI hit the same issue as described. I've sent a PR for fixing it
For the time-being I manually deleted the subnets and then the network to unblock the next scale job run. But it would be good to have this fixed soon. cc
Closing this issue as we're now deleting all remaining firewall rules in the network before deleting the network itself in kube-down. For other networking resources in general, we have issue .


Question: close(stopChan) // Let loops drain <del> wg.Wait() </del> <ins> drained := make(chan struct{}) go func() { defer close(drained) wg.Wait() }() select { case <-drained: case <-time.After(wait.ForeverTestTimeout): t.Error("timed out waiting for clients to complete") } </ins> }

Reproduced on 1.11.7 as well as master-ish () Deleting a CRD doesn't seem to cause the API server to terminate watches referencing the corresponding CRs, but the watches also don't properly resume if the CRD is created again, meaning that you have to wait for watch timeouts to actually get new watch events. We should probably kill open watches on CRD deletion, so that clients are notified and are forced to re-watch. Either that, or seamlessly resume watches if a CRD is recreated. <details</summary</details<details</summary</detailsthe above CRD: the above CR: (elsewhere) and grab a resource version (elsewhere) the lack of watch events After watches time out, things can re-establish, but that can be a while.
/assign
/cc sttts
/area custom-resources
it's sort a related thread w/ . for now CRD's update will terminate CR's watch connection, the other way round we might fix'em together. one possible fix suggested by months ago is that we make the storage to be a runnable object, e.g. by which we can clearily define the lifecycle of CR's storage
fixed in

What happened: If you establish a WATCH request on a list of CRs, then edit the CRD's object, you will stop getting MODIFIED events on the WATCH request. The WATCH request doesn't fail or report an error, but will not return more MODIFIED events until the request is restarted. This causes problems for custom controllers, which become unresponsive until their requests expire. What you expected to happen: Either the request should end (so it can be restarted safely) or it should continue to return MODIFIED events. How to reproduce it (as minimally and precisely as possible): I've attached . It does the following: Create CRD and an initial CR. Start a proxy, wait for it to come up, then start a watch request. Change the CR. (This change to the CR results in a MODIFIED event) Change the section of the CRD. Make another change to the CR. (This change to the CR doesn't result in an event). I've tested this against GKE masters on 1.9, 1.10 and 1.11, as well as a kubeadm 1.12.2 cluster. The output looks like: Note that you only see MODIFIED once despite the CR being changed twice. Environment: Kubernetes version (use ): 1.11.2-gke.18, 1.12.2 Cloud provider or hardware configuration: GKE, kubeadm on amd64 OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): 4.15.0-36-generic ~16.04.1-Ubuntu SMP <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
Reiterating the mentions to trigger a notification: <detailsIn response to : Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/cc
/cc
i suppose it's related w/ yes, b/c we switched to another CR storage when you updated CRD spec.
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
fixed in


/kind bug /sig api-machinery /cc What happened: patching (SMP) any object's annotation using invalid patch content will result in an (500) internal-server error. expecting a (400) bad-request error in this case. patch body: received error: the error is thrown from converter instead of the patcher, so it seems that patcher considers the body as valid then the converter complained. Anything else we need to know?: when my grandpa was 65 years old he started running one mile a day to keep fit. he's 70 now and we have no idea where he is.
I just tried the same patch with "MergePatchType", and it also fails with 500.
I can't make it fail with JSONPatchType, I get a 422
I suspect the error should read "the server rejected your request due to an error in our request"


Question: } // Error caught by validation _, maxUnavailable, _ := ResolveFenceposts(deployment.Spec.Strategy.RollingUpdate.MaxSurge, deployment.Spec.Strategy.RollingUpdate.MaxUnavailable, *(deployment.Spec.Replicas)) <ins> if maxUnavailable > *deployment.Spec.Replicas { return *deployment.Spec.Replicas } </ins> return maxUnavailable }

We need to gracefully handle the case when a Deployment specifies an absolute value of MaxUnavailable larger than its spec.replicas. I don't think we want to add validation for this, simply collapsing maxUnavailable to spec.replicas would suffice.
Are you working on this? I am glad to take this if not.
feel free to work on it


Question: return true, nil } <del> return false, fmt.Errorf("azureDisk - WaitForAttach failed within timeout node (%s) diskId:(%s) lun:(%v)", nodeName, diskName, lun) </del> <ins> // wait until timeout return false, nil </ins> }) <ins> if err == nil && newDevicePath == "" { err = fmt.Errorf("azureDisk - WaitForAttach failed within timeout node (%s) diskId:(%s) lun:(%v)", nodeName, diskName, lun) } </ins> return newDevicePath, err }

<!-- 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: regarding - yes it polls every second, but if /dev/... is not there (findDiskByLun returns "") it returns fmt.Errorf("azureDisk - findDiskByLun(%v) failed within timeout", lun). and exits from wait.Poll It causes to kubelet retry NodePublishVolume with exponensial backoff, and because /dev/disk/azure/... can appear 15-60s after first first call it can reach 2m timeout. So I suggest to just return false, nil and let wait.Poll to retry instead of kubelet. see What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /assign /priority important-soon /sig cloud-provider /area provider/azure


Question: optional bool stdin = 1; // Redirect the standard output stream of the pod for this call. <del> // Defaults to true. </del> // +optional optional bool stdout = 2; // Redirect the standard error stream of the pod for this call. <del> // Defaults to true. </del> // +optional optional bool stderr = 3;

As per the PRs kubernetes/kubernetes kubernetes/kubernetes, the defaulting behaviour of the pod exec parameters had been changed however in the code there is a comment where it is mentioned it defaults to True The comment about the default value must be removed and the openapi spec must be fixed Present in the file as comment and also in the OpenApiSpec swagger If this issue seems appropriate can I take it up please <details</details<details</details<details</details<details</details<details</details<details</details
/sig docs
/sig node
/assign
/assign
/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 : /help /triage accepted </details
/kind documentation


Question: docker build -t $(PREFIX)/logs-generator:$(TAG) . push: <del> gcloud docker push $(PREFIX)/logs-generator:$(TAG) </del> <ins> gcloud docker -- push $(PREFIX)/logs-generator:$(TAG) </ins> clean: rm -f logs-generator  No newline at end of file

Just saw this warning today: Not sure if this is only limited to kubemark, or if there are other places we need to fix, too.
Sorry if this sounds stupid, but as expected, won't show this warning - what needs to be fixed here?
we have a bunch of scripts and Makefiles which are omitting the currently. We need to fix these by adding the missing s.


Question: framework.ExpectNoError(framework.VerifyPodStartupLatency(podStartupLatency)) framework.LogSuspiciousLatency(startupLag, e2eLag, nodeCount, c) <ins> By("Removing additional replication controllers") for i := 1; i <= nodeCount; i++ { name := additionalPodsPrefix + "-" + strconv.Itoa(i) c.ReplicationControllers(ns).Delete(name, nil) } </ins> } cleanupDensityTest(dConfig) <del> By("Removing additional replication controllers if any") for i := 1; i <= nodeCount; i++ { name := additionalPodsPrefix + "-" + strconv.Itoa(i) c.ReplicationControllers(ns).Delete(name, nil) } </del> }) }

As the following code block shows, after running each density test case, it will attempt to delete "additional replication controllers" even though there is no additional replication controller. When we are not running latency test, API Server will return "404 error code". So, I propose to move the above code block inside thedetermine statements , looks like: In this way, removing RC will be executed only if we set to be . It can avoid post some necessary requests to API Server.
Fixed. I am going to close this issue.


Question: }, } <del> for _, test := range tests { imageStates := getNodeImageStates(test.node, test.imageExistenceMap) if !reflect.DeepEqual(test.expected, imageStates) { t.Errorf("expected: %#v, got: %#v", test.expected, imageStates) } </del> <ins> for i, test := range tests { t.Run(fmt.Sprintf("case_%d", i), func(t *testing.T) { imageStates := getNodeImageStates(test.node, test.imageExistenceMap) if !reflect.DeepEqual(test.expected, imageStates) { t.Errorf("expected: %#v, got: %#v", test.expected, imageStates) } }) </ins> } }

<!-- Please only use this template for submitting enhancement requests --What would you like to be : Currently some unit tests in pkg/scheduler is not organized as Use subtests can make it easier to find out which case fails and leverage benefit of parallelism . Why is this needed: Follow Go test practice.
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
/remove-kind feature /kind cleanup /sig scheduling /assign


Question: }) <del> ginkgo.It("should replace a pod template", func() { </del> <ins> /* Release: v1.24 Testname: PodTemplate, replace Description: Attempt to create a PodTemplate which MUST succeed. Attempt to replace the PodTemplate to include a new annotation which MUST succeed. The annotation MUST be found in the new PodTemplate. */ framework.ConformanceIt("should replace a pod template", func() { </ins> ptClient := f.ClientSet.CoreV1().PodTemplates(f.Namespace.Name) ptName := "podtemplate-" + utilrand.String(5)

[x] test approval issue : [x] test pr : [x] two weeks soak end date : 14 March 2022 [X] test promotion pr : According to this APIsnoop query, there is still one remaining PodTemplate endpoint which is untested. Using a number of existing e2e test practices a new has been created for pod templates. The e2e logs for this test are listed below. This query shows the endpoints hit within a short period of running the e2e test If a test with these calls gets merged, test coverage will go up by 1 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
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


Question: - --tls-private-key-file=/srv/kubernetes/server.key - --admission-control={{.FEDERATION_ADMISSION_CONTROL}} - --token-auth-file=/srv/kubernetes/known-tokens.csv <ins> - --anonymous-auth=false </ins> ports: - containerPort: 443 name: https

It looks like the addition of some new e2e tests (by ?) made the test run take a bit longer, and not fit into it's timeout threshold. FYI. root 9001 0.0 0.0 6256 ? Sl 08:48 0:00 /workspace/kubernetes/platforms/linux/amd64/ginkgo -- -- --ginkgo.flakeAttempts=1 --host=https://104.198.234.41 --provider=gce --gce-project=k8s-jkns-e2e-gce-federation --gce-zone=us-central1-f --gke-cluster=jenkins-e2e --kube-master=jenkins-us-central1-f-master --cluster-tag= --repo-root=/workspace/kubernetes/cluster/../cluster/gce/../../cluster/gce/../../cluster/.. --node-instance-group=jenkins-us-central1-f-minion-group --prefix=jenkins-us-central1-f --network=jenkins-e2e --master-os-distro=gci --node-os-distro=debian --num-nodes=3 --minStartupPods=8 --report-dir=/workspace/artifacts --[Feature:Federation] root 9009 0.0 0.1 ? Sl 08:48 0:05  --test.timeout=24h -- --ginkgo.slowSpecThreshold=5.

-- --ginkgo.flakeAttempts=1 --host=https://104.198.234.41 --provider=gce --gce-project=k8s-jkns-e2e-gce-federation --gce-zone=us-central1-f --gke-cluster=jenkins-e2e --kube-master=jenkins-us-central1-f-master --cluster-tag= --repo-root=/workspace/kubernetes/cluster/../cluster/gce/../../cluster/gce/../../cluster/.. --node-instance-group=jenkins-us-central1-f-minion-group --prefix=jenkins-us-central1-f --network=jenkins-e2e --master-os-distro=gci --node-os-distro=debian --num-nodes=3 --minStartupPods=8 --report-dir=/workspace/artifacts --[Feature:Federation] ++ docker stop kubernetes-e2e-gce-federation-5358 kubernetes-e2e-gce-federation-5358 rc=124 [[ 124 -eq 124 ]] echo 'Build timed out' Build timed out echo 'Exiting with code: 124' Exiting with code: 124 exit 124 Build step 'Execute shell' marked build as failure
We should probably increase the overall timeout value to accommodate the new tests, in advance of doing a cleanup to make the tests run faster.
I havent any tests yet :)
One way of reducing the time of our e2e tests is to register the clusters in the framework instead of doing it in BeforeEach in each test. Each test runs it in its own namespace, so no need to delete and register clusters again for each test
I analyzed the logs in Most of the tests are failing because of service spec. [0].protocol and spec.sessionAffinity field were optional before. something have changed.
it seems no new tests are since 9 days. and i see the federated_informer throwing quite a lot of error, the one below: Increasing the timeout will not help. There is something wrong with the code, maybe related to API versioning.
[FLAKE-PING] This flaky-test issue would love to have more attention.
I think the time out is due to a combination of our failing tests and Whenever a test fails, e2e framework tries to print the logs of some of our pods. But fetching logs is timing out after a long time (as discussed in ).

Fixing the tests to not fail should eliminate the timeout failure :)
Regarding [0].protocol and spec.sessionAffinity fields, I see that we are setting them in our tests: Ref
Currently there are 3 testcases which are failing, One is in Federated Ingress and the other two are in Federation API server authentication. I know the cause for API server authentication test failures. By default anonymous-auth is enabled, so api server will accept the request and there are no authorization plugins configured currently, hence the requests are being served. I will send a fix for these 2 failed test cases


Question: - gosimple text: "S1033: unnecessary guard around call to delete" <del> # Only packages listed here opt into the strict "exported symbols must be documented". - linters: - revive text: "(exported: exported .* or be unexported|exported: comment on exported.*should be of the form)" path-except: cmd/kubeadm </del> # Didn't make it into https://github.com/kubernetes/kubernetes/issues/117288. # Discussion on Slack concluded that "it's hard to have a universal policy for all # functions marked deprecated" and thus this can only be a hint which must

Looks like the golangci-lint-pr-hints linter was updated recently to put the feature gate comment ahead of the owner field in All the feature gates in are ordered by the following comments: // owner: // kep: // alpha: // beta: // // Describe the feature gate <declare the feature gateThe new linter changes now requires that the comment describing the feature gate should even precede the owner comment line which goes against the structure followed by the entire file and this needs to be fixed Feature gates should be ordered as follows to maintain parity with the rest of // owner: // kep: // alpha: // beta: // // Describe the feature gate <declare the feature gateUpdate/add new feature gate to No response <details</detailsmaster branch of k8s/k8s <details</detailsN/A <details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
!
cc
cc
it was supposed to only apply to cmd/kubeadm.
/sig testing
/assign
Thank you for fixing that.
If I break it, I fix it... :hot_face:


Question: cmdutil.AddValidateFlags(cmd) cmd.Flags().StringVarP(&options.Selector, "selector", "l", "", "Selector (label query) to filter on") cmd.Flags().Bool("all", false, "[-all] to select all the specified resources.") <del> cmd.Flags().StringArrayP("prune-whitelist", "w", []string{}, "Overwrite the default whitelist with <group/version/kind> for --prune") </del> <ins> cmd.Flags().StringArray("prune-whitelist", []string{}, "Overwrite the default whitelist with <group/version/kind> for --prune") </ins> cmdutil.AddDryRunFlag(cmd) cmdutil.AddPrinterFlags(cmd) cmdutil.AddRecordFlag(cmd)

When writing the docs for , I found there is a flag with short hand flag has been add to in 1.5. The flag is mostly used by add-on manger. I think we only give the flag that is very commonly used a shorthand flag. I think we should keep and save it for other flags in the future. We can make the change before it goes out in 1.5. cc:


Question: import ( "context" <ins> "encoding/json" </ins> "fmt" "time" appsv1 "k8s.io/api/apps/v1" <ins> autoscalingv1 "k8s.io/api/autoscaling/v1" "k8s.io/apimachinery/pkg/types" </ins> v1 "k8s.io/api/core/v1" apierrors "k8s.io/apimachinery/pkg/api/errors" "k8s.io/apimachinery/pkg/api/resource"

[x] two weeks soak end date : 26 Feb 2021 According to this APIsnoop query, there are still some remaining RESOURCENAME endpoints which are untested. with this query you can filter untested endpoints by their category and eligiblity for conformance. e.g below shows a query to find all conformance eligible untested,stable,core endpoints Create a ReplicaSet with a static label Read the ReplicaSetScale Update the ReplicaSetScale Get the ReplicaSetScale to ensure it is updated Patch the ReplicaSetScale Read the ReplicaSetScale to ensure it is Patch Delete the Namespace and ReplicaSet Due to the complexity of setting up the resources for APIService we have used the current e2e test as template. It has been extended in a for review. example endpoint | useragent ----------------------------------------|
patchAppsV1NamespacedReplicaSetScale | (linux/amd64) kubernetes/$Format -- [sig-apps] ReplicaSet Replicaset should have a working scale subresource readAppsV1NamespacedReplicaSetScale | (linux/amd64) kubernetes/$Format -- [sig-apps] ReplicaSet Replicaset should have a working scale subresource replaceAppsV1NamespacedReplicaSetScale | (linux/amd64) kubernetes/$Format -- [sig-apps] ReplicaSet Replicaset should have a working scale subresource (3 rows) If a test with these calls gets merged, test coverage will go up by 3 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture
/triage accepted
Presented in Conformance meeting of 9 Feb 2021 and it was agreed that that method see to achieve the purpose and a PR can be created. A similar approach would be taken for the DepoymentScale endpoints.
/reopen
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


Question: // not provide List. // IMPORTANT: Objects are NOT a superset of lists. Do not use this check to determine whether an // object *is* a List. <del> // TODO: return bool instead of error </del> func ListAccessor(obj interface{}) (List, error) { switch t := obj.(type) { case List:

Anything else we need to know?: I notice there are TODOs in apimachinerypkgapimeta,return bool instead of error func CommonAccessor, ListAccessor, Accessor. If is it necessary to do,I push a PR for it. Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
cc
/sig api-machinery
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


Question: <ins> # Disable inheritance as this is an api owners file options: no_parent_owners: true </ins> approvers: - erictune - lavalamp

I believe this owners file should not inherit permissions from parent OWNERS files; only api approvers should be able to approve api changes.
/kind feature /sig architecture
opened to do this


Question: return false, fmt.Errorf("mountVolume.NodeExpandVolume get PVC failed : %v", err) } <del> if volumeToMount.VolumeSpec.ReadOnly { simpleMsg, detailedMsg := volumeToMount.GenerateMsg("MountVolume.NodeExpandVolume failed", "requested read-only file system") klog.Warningf(detailedMsg) og.recorder.Eventf(volumeToMount.Pod, v1.EventTypeWarning, kevents.FileSystemResizeFailed, simpleMsg) og.recorder.Eventf(pvc, v1.EventTypeWarning, kevents.FileSystemResizeFailed, simpleMsg) return true, nil } </del> pvcStatusCap := pvc.Status.Capacity[v1.ResourceStorage] pvSpecCap := pv.Spec.Capacity[v1.ResourceStorage] if pvcStatusCap.Cmp(pvSpecCap) < 0 { <ins> if volumeToMount.VolumeSpec.ReadOnly { simpleMsg, detailedMsg := volumeToMount.GenerateMsg("MountVolume.NodeExpandVolume failed", "requested read-only file system") klog.Warningf(detailedMsg) og.recorder.Eventf(volumeToMount.Pod, v1.EventTypeWarning, kevents.FileSystemResizeFailed, simpleMsg) og.recorder.Eventf(pvc, v1.EventTypeWarning, kevents.FileSystemResizeFailed, simpleMsg) return true, nil } </ins> rsOpts.NewSize = pvSpecCap rsOpts.OldSize = pvcStatusCap resizeOp := nodeResizeOperationOpts{

Created a RWX volume and mounted it on a pod having readOnly flag set to true. While the volume provisioning happened successfully, we did observe some warning message on describing the pod: Warning FileSystemResizeFailed 27m kubelet MountVolume.NodeExpandVolume failed for volume "pvc--a6ba-49f4-a560-" requested read-only file system It seems like this message is being triggered from here: But we never did an expand volume call, so we should not be seeing warning message. It can be confusing to see this warning message. The warning message should not be displayed when expand volume was not even called. Create a RWX volume and mount it on a pod with readOnly flag set to true. Wait for a few minutes and describe the pod. No response_ 28 vSphere <details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig storage
/assign


Question: // Name of the workload. Name string // Values of parameters used in the workloadTemplate. <del> Params map[string]int </del> <ins> Params params } type params struct { params map[string]int // isUsed field records whether params is used or not. isUsed map[string]bool } // UnmarshalJSON is a custom unmarshaler for params. // // from(json): // 	{ // 		"initNodes": 500, // 		"initPods": 50 // 	} // // to: //	params{ //		params: map[string]int{ //			"intNodes": 500, //			"initPods": 50, //		}, //		isUsed: map[string]bool{}, // empty map //	} // func (p *params) UnmarshalJSON(b []byte) error { aux := map[string]int{} if err := json.Unmarshal(b, &aux); err != nil { return err } p.params = aux p.isUsed = map[string]bool{} return nil } // get returns param. func (p params) get(key string) (int, error) { p.isUsed[key] = true param, ok := p.params[key] if ok { return param, nil } return 0, fmt.Errorf("parameter %s is undefined", key) } // unusedParams returns the names of unusedParams func (w workload) unusedParams() []string { var ret []string for name := range w.Params.params { if !w.Params.isUsed[name] { ret = append(ret, name) } } return ret </ins> } // op is a dummy struct which stores the real op in itself.

Note: this issue should be viewed in the context of . If this happens, this is very likely a typo where someone used a parameter in a way they didn't mean to (for example, ). /sig scheduling /assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/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
/remove-lifecycle stale
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Hi this is my first time contributing to kubernetes. can you provide me some guidance on how to to get started?
Hi, is this issue still valid to work on?
yes, this is still valid. I recommend starting with the and reading from there.
are you still working on this issue or should I work on it.
I would like to work on this issue if you haven't started already.
would it be ok if I took a look at this?
/assign
Hi Can you help me in why its not assigning the values to createNodes and createPods directly and using the opcode and countParam in performance-
We use a field to differentiate between different operations. The value of the field (e.g. "createNodes") determines the operation. The field defines the number of pods/nodes to create. What do you mean by "assigning the values to createNodes and createPods directly"?
Thanks for the information.

By assigning, I just meant that whether we can assign createNodes directly like ( createNodes: $initNodes ).
I don't think that's possible since there can potentially be other parameters besides the countParam. For example: Different operations could potentially have different parameters.
createNodes and createPods aren't the only operations. Other operations (e.g. churn and barrier), including future ones, may not fit that format. It's also easier to parse and more explicit this way.
Thanks , Having a doubt more, in performance- under the name:SchedulingPodAntiAffinity, ! why are we giving the same values in 5000Nodes as given in 500Nodes, or this is an error.
that sounds like a typo indeed
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
Hello Are you still going to work on this issue?
Hi I have worked on the issue but not working for a while as was unsure about the exact problem.
, no problem if you are willing to work on this issue, shall unassign myself
/unassign
Thanks :)
/assign
/remove-lifecycle stale
hey! I am beginner and I interested in scheduling and I know basics of scheduling , so how can I start to contribute on this issue.
Sorry, PR for this issue has already created.
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]:


Question: fi env-to-grains "runtime_config" <ins> env-to-grains "kube_user" </ins> } salt-node-role() {

Looks like this was broken by (which means no cherry pick will be needed :-) ). Fix incoming...


Question: fi env-to-grains "runtime_config" <ins> env-to-grains "kube_user" </ins> } salt-node-role() {

Looks like this was broken by (which means no cherry pick will be needed :-) ). Fix incoming...


Question: echo "== Finished upgrading nodes to ${KUBE_VERSION}. ==" >&2 } <ins> function update-coredns-config() { # Get the current CoreDNS version local -r coredns_addon_path="/etc/kubernetes/addons/0-dns/coredns" local -r tmpdir=/tmp local -r download_dir=$(mktemp --tmpdir=${tmpdir} -d coredns-migration.XXXXXXXXXX) || exit 1 # clean up cleanup() { rm -rf "${download_dir}" } trap cleanup EXIT # Get the new installed CoreDNS version echo "Waiting for CoreDNS to update" until [[ $(${KUBE_ROOT}/cluster/kubectl.sh -n kube-system get deployment coredns -o=jsonpath='{$.metadata.resourceVersion}') -ne ${COREDNS_DEPLOY_RESOURCE_VERSION} ]]; do sleep 1 done echo "Fetching the latest installed CoreDNS version" NEW_COREDNS_VERSION=$(${KUBE_ROOT}/cluster/kubectl.sh -n kube-system get deployment coredns -o=jsonpath='{$.spec.template.spec.containers[:1].image}' | cut -d ":" -f 2) case "$(uname -m)" in x86_64*) host_arch=amd64 corefile_tool_SHA="fd4d8a42d8a1c38cb49b75cca3c7c82677b97c0c6e5ee2a7d5fb02314ccfbb59" ;; i?86_64*) host_arch=amd64 corefile_tool_SHA="fd4d8a42d8a1c38cb49b75cca3c7c82677b97c0c6e5ee2a7d5fb02314ccfbb59" ;; amd64*) host_arch=amd64 corefile_tool_SHA="fd4d8a42d8a1c38cb49b75cca3c7c82677b97c0c6e5ee2a7d5fb02314ccfbb59" ;; aarch64*) host_arch=arm64 corefile_tool_SHA="05503f379eaaa703034c50da7ce7c273d7a7b3569eddb55afe300bd6d6c40988" ;; arm64*) host_arch=arm64 corefile_tool_SHA="05503f379eaaa703034c50da7ce7c273d7a7b3569eddb55afe300bd6d6c40988" ;; arm*) host_arch=arm corefile_tool_SHA="bc826bde6662c11cbb6e6e215397d07d4fedb754c1a6e208271d7d784eb28600" ;; s390x*) host_arch=s390x corefile_tool_SHA="4ed6b7067f65dc8f147a4dd116242495fbec5e6057bb68e1868ef1fb25e07993" ;; ppc64le*) host_arch=ppc64le corefile_tool_SHA="7bce38ed762a2607e158c65b378e6f23e2b80fc4e93dcf50a55f986c7ea2db43" ;; *) echo "Unsupported host arch. Must be x86_64, 386, arm, arm64, s390x or ppc64le." >&2 exit 1 ;; esac # Download the CoreDNS migration tool echo "== Downloading the CoreDNS migration tool ==" wget -P ${download_dir} "https://github.com/coredns/corefile-migration/releases/download/v1.0.2/corefile-tool-${host_arch}" >/dev/null 2>&1 local -r checkSHA=$(sha256sum ${download_dir}/corefile-tool-${host_arch} | cut -d " " -f 1) if [[ "${checkSHA}" != "${corefile_tool_SHA}" ]]; then echo "!!! CheckSum for the CoreDNS migration tool did not match !!!" >&2 exit 1 fi chmod +x ${download_dir}/corefile-tool-${host_arch} # Migrate the CoreDNS ConfigMap depending on whether it is being downgraded or upgraded. ${KUBE_ROOT}/cluster/kubectl.sh -n kube-system get cm coredns -o jsonpath='{.data.Corefile}' > ${download_dir}/Corefile-old if test "$(printf '%sn' ${CURRENT_COREDNS_VERSION} ${NEW_COREDNS_VERSION} | sort -V | head -n 1)" != ${NEW_COREDNS_VERSION}; then echo "== Upgrading the CoreDNS ConfigMap ==" ${download_dir}/corefile-tool-${host_arch} migrate --from ${CURRENT_COREDNS_VERSION} --to ${NEW_COREDNS_VERSION} --corefile ${download_dir}/Corefile-old > ${download_dir}/Corefile ${KUBE_ROOT}/cluster/kubectl.sh -n kube-system create configmap coredns --from-file ${download_dir}/Corefile -o yaml --dry-run | ${KUBE_ROOT}/cluster/kubectl.sh apply -f - else # In case of a downgrade, a custom CoreDNS Corefile will be overwritten by a default Corefile. In that case, # the user will need to manually modify the resulting (default) Corefile after the downgrade is complete. echo "== Applying the latest default CoreDNS configuration ==" gcloud compute --project ${PROJECT}  scp --zone ${ZONE} ${MASTER_NAME}:${coredns_addon_path}/coredns.yaml ${download_dir}/coredns-manifest.yaml > /dev/null ${KUBE_ROOT}/cluster/kubectl.sh apply -f ${download_dir}/coredns-manifest.yaml fi echo "== The CoreDNS Config has been updated ==" } echo "Fetching the previously installed CoreDNS version" CURRENT_COREDNS_VERSION=$(${KUBE_ROOT}/cluster/kubectl.sh -n kube-system get deployment coredns -o=jsonpath='{$.spec.template.spec.containers[:1].image}' | cut -d ":" -f 2) COREDNS_DEPLOY_RESOURCE_VERSION=$(${KUBE_ROOT}/cluster/kubectl.sh -n kube-system get deployment coredns -o=jsonpath='{$.metadata.resourceVersion}') </ins> master_upgrade=true node_upgrade=true node_prereqs=false

Which jobs are failing: Multiple jobs on . Which test(s) are failing: on the following jobs: Since when has it been failing: Since 5/17. Testgrid links: See above. Reason for failure: All the failures mentioned above seem to have to have the same root cause, namely failure while waiting for CoreDNS to be ready. Example: /sig testing /priority critical-urgent /kind failing test /milestone v1.15 /cc
Some of this (possible all of it) is due to , which is dependent on being merged.
/sig cluster-lifecycle
Not the gce jobs thoght. Only the kinder job. So the gce jobs are failing with a problem outside of kubeadm/kinder but possibly still related to the corefile plugin change
/assign (At kubecon this week)
The gce failures appear to show the same behavior, but with kube-up instead of kubeadm. I.e. it appears that kube-up may also be retaining old configs when upgrading/downgrading. If thats true, then we may need to integrate the migration tools into kube-up as well.
I have opened which aims to fix all the failing tests except , which will be fixed via
Great job so far and Would it be possible to ask for the open PRs to be merged and/or a solution found soon? We have these tests failing for quite some time and code freeze coming up in the next days. Thank you in advance for your efforts!
thanks for the heads up. let me know if you don't have the time for the refactor that i requested and i can try to take over there. the alternative is to rollback the coredns version which i assume is not ideal, due to a variety of fixes in the new version.
is there any more work planned for this issue? I see that some of the kinder jobs are still failing after merged:
merging and will resolve and close this issue.
Thank you for the update !
updates: kinder tests were fixed via
/unassign i was here for: it's a bit flaky (which is due to the tooling), but green.
Since and we're moved to 1.16, and we're waiting for to merge, can we move this issue to 1.16?
? is that the right PR?

Good catch, I meant
The GCE test failures were fixed by and /close
Closing this issue. <detailsIn response to : The GCE test failures were fixed by and /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: name:                      "reject redirection disabled in proxy, backend server sending 301 response", rejectForwardingRedirects: false, serverStatusCode:          301, <ins> redirect:                  "/", </ins> expectStatusCode:          301, expectBody:                originalBody, },

Upgraded from Kubernetes v1.25.0 to v1.25.1. Standard metrics-server deployment now causes the following message to appear in the kube-apiserver logs on a recurring basis: Adding a quick hack debug Infof print shows: It appears that the apiserver is sending an If-None-Match cache control header when refreshing the openapi spec, and the metrics-server service is correctly responding with a 304 Not Modified. No errors logged; proper refresh of OpenAPI specs Deploy metrics-server, or any other service that uses apiserver aggregation and honors caching headers such as , to a Kubernetes 1.25.1 cluster. made bad assumptions; not all HTTP 3XX responses are redirects. It should probably only reject the response if it is 300-399 AND the header is set. <details</detailsnone <details</detailsk3s containerd flannel
Taking a stab at some tags here... /cc /cc /cc /area apiserver /sig api-machinery
thanks for the report, looks like this should be /priority critical-urgent /kind regression cc since this requires a respin of a final 1.22 patch release :-/
Fix open in , will get cherry-picks open to start greening up CI
/triage accepted
I need to make a redirect to the external URL but it's not allowed :(