Question: // preempt tries to create room for a pod that has failed to schedule, by preempting lower priority pods if possible. // If it succeeds, it adds the name of the node where preemption has happened to the pod spec. // It returns the node name and an error if any. <del> func (sched *Scheduler) preempt(preemptor *v1.Pod, scheduleErr error) (string, error) { </del> <ins> func (sched *Scheduler) preempt(fwk framework.Framework, preemptor *v1.Pod, scheduleErr error) (string, error) { </ins> preemptor, err := sched.config.PodPreemptor.GetUpdatedPod(preemptor) if err != nil { klog.Errorf("Error getting the updated preemptor pod object: %v", err)

<!-- Please only use this template for submitting enhancement requests --What would you like to be : When preempting a pod that is a that permit plugins are waiting for , we need send a message(actually send a ) to the , otherwise permit plugins might wait until time out, and do not know the pod has been preempted. Why is this needed: /sig scheduling /kind cleanup /assign
cc
Interesting interaction between the permit and preempt, I will take a look at the PR you sent, thanks!


Question: var waitForReplicas *scale.RetryParams if o.Timeout != 0 && o.dryRunStrategy == cmdutil.DryRunNone { <del> waitForReplicas = scale.NewRetryParams(1*time.Second, timeout) </del> <ins> waitForReplicas = scale.NewRetryParams(1*time.Second, o.Timeout) </ins> } counter := 0

<!-- 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: if I figure out --timeout,but the timeout is fixed in source not customized the timeout 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:
/assign
/sig cli


Question: "//pkg/features:go_default_library", "//pkg/kubelet/container:go_default_library", "//staging/src/k8s.io/api/core/v1:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/types:go_default_library", </ins> "//staging/src/k8s.io/apiserver/pkg/util/feature:go_default_library", "//vendor/github.com/prometheus/client_golang/prometheus:go_default_library", "//vendor/k8s.io/klog:go_default_library",

What would you like to be : It would be useful if the kubelet exported a metric that contained its own name as a label, for instance: . This name should be consistent with the output of . Why is this needed: This would allow us to join the kubelet metrics against metrics exported by kube-state-metrics. An example of this can be seen in We've arranged in our cluster for the labels to be set to the node's name, but this is controlled by Prometheus and depends on your scrape & relabelling config. As such, in general we can't rely on this to be the case - for instance, with the prometheus-operator the label is a IP:Port combo. /cc
/sig instrumentation
This metric as it is right now doesn’t conform to the instrumentation guidelines, so yes we should changes this as part of the metrics overhaul targeted for 1.14.
you mean to add a label in kubelet metrics ?
precisely.
/assign


Question: const ( timeout       = 1 * time.Minute <del> maxRetries    = 10 sleepDuration = time.Minute </del> <ins> maxRetries    = 6 sleepDuration = 10 * time.Second </ins> ) var _ = Describe("Cadvisor", func() {

Once is fixed, the cadvisor timeouts should be dropped back down and the test cleaned up. Just noting a work-item that I meant to open when we merged .


Question: // Set up logger for etcd client etcd.SetLogger(util.NewLogger("etcd ")) <del> endpoint := "unix:///var/run/docker.sock" </del> <ins> var endpoint string if len(*dockerEndpoint) > 0 { endpoint = *dockerEndpoint } else if len(os.Getenv("DOCKER_HOST")) > 0 { endpoint = os.Getenv("DOCKER_HOST") } else { endpoint = "unix:///var/run/docker.sock" } glog.Infof("Connecting to docker on %s", endpoint) </ins> dockerClient, err := docker.NewClient(endpoint) if err != nil { glog.Fatal("Couldn't connnect to docker.")

When using or with a key/value that has a multi-line string as value, that value will appear as quoted string in the log message, i.e. the log message will still be a single line. It would be nicer to print the value in text mode so that it goes across multiple lines, with clear indicators for start and end of the value. Indention could be used to avoid mistaking some embedded line as the start of a new log message. In JSON mode, the value should be formatted normally. /sig instrumentation /wg structured-logging Always printing as a single line can can make the log output unreadable ().
When adding something like this, can be reverted and implemented differently.
My original thinking was that only objects that explicitly ask for multi-line output get formatted that way. But that means that we need to review log calls very carefully. An alternative is to automatically switch from quoting strings to multi-line output based on some heuristic, for example when there's more than one line break.
Here's a potential implementation:
If structured logging is needed in any other case I can contribute, please inform if needed.
/triage accepted /assign /priority important-soon /area logging /cc /cc
We have the same problem as in kube-scheduler also in kubelet, it's just that no-one has seen and/or complained about the multi-line strings. With the benchmark + log analysis tool from I found the following multi-line string parameters in a kubelet log: <details</details


Question: set +o errexit } <ins> # Runs tests for kubectl alpha diff run_kubectl_diff_tests() { set -o nounset set -o errexit create_and_use_new_namespace kube::log::status "Testing kubectl alpha diff" kubectl apply -f hack/testdata/pod.yaml # Ensure that selfLink has been added, and shown in the diff output_message=$(kubectl alpha diff -f hack/testdata/pod.yaml) kube::test::if_has_string "${output_message}" 'selfLink' output_message=$(kubectl alpha diff LOCAL LIVE -f hack/testdata/pod.yaml) kube::test::if_has_string "${output_message}" 'selfLink' output_message=$(kubectl alpha diff LOCAL MERGED -f hack/testdata/pod.yaml) kube::test::if_has_string "${output_message}" 'selfLink' output_message=$(kubectl alpha diff MERGED MERGED -f hack/testdata/pod.yaml) kube::test::if_empty_string "${output_message}" output_message=$(kubectl alpha diff LIVE LIVE -f hack/testdata/pod.yaml) kube::test::if_empty_string "${output_message}" output_message=$(kubectl alpha diff LAST LAST -f hack/testdata/pod.yaml) kube::test::if_empty_string "${output_message}" output_message=$(kubectl alpha diff LOCAL LOCAL -f hack/testdata/pod.yaml) kube::test::if_empty_string "${output_message}" kubectl delete -f  hack/testdata/pod.yaml set +o nounset set +o errexit } </ins> # Runs tests for --save-config tests. run_save_config_tests() { set -o nounset

/kind bug /sig cli /area kubectl Hello. This is my first interaction with the Kubernetes community, so please forgive me if i have left out any crucial details, or if, perhaps, this is PEBKAC after all! I am keen to have a working feature, as described in and I am running K8s v1.9.3 and realise that this feature is in alpha, but i thought i would ask anyway. We're not on v1.9.4 yet, but the changelog doesn't mention the feature. What you expected to happen: I have some services deployed to Kubernetes with YAML files, that has been working reliably. We always use to deploy things. When a service is already deployed, and i make a minor change in the config file, for example the service port, i expect to see that in the diff. Instead, gives no output and exits with a . How to reproduce it (as minimally and precisely as possible): Consider the file : I make sure that it is correctly running on the cluster: Great, looking good. Now, i change the value to use Docker image tag and save. Now, i run: The stderr/stdout output is empty, and the exit code is . Anything else we need to know?: Environment: Kubernetes version: Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-02-09T21:50:44Z", GoVersion:"go1.9.4", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.3+coreos.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-02-10T01:42:55Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
I have this same issue - if I change, say, to in my , running returns empty. If I try tweaking the version I'm diffing (which I don't understand) - e.g. - then I see a bunch of differences, but not actually the change I was expecting in the number of replicas.
I'll take this. Sorry for the inconvenience.


Question: const sysctlRouteLocalnet = "net/ipv4/conf/all/route_localnet" const sysctlBridgeCallIPTables = "net/bridge/bridge-nf-call-iptables" <ins> const sysctlNFConntrackTCPBeLiberal = "net/netfilter/nf_conntrack_tcp_be_liberal" </ins> // internal struct for string service information type servicePortInfo struct {

When packets with sequence number out-of-window arrived k8s node, conntrack marked them as INVALID. kube-proxy will ignore them, without rewriting DNAT. However, there is no corresponding session link on the host, and the host sends a reset packet, causing the session link to be interrupted connection not reset This problem can be solved by command iptables -t filter -I INPUT -p tcp -m conntrack --ctstate INVALID -j DROP Similar But this issue "drop" is placed on the forward chain, our scenario needs to be placed on the input chain. $ kubectl version Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2021-08-04T18:03:20Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2021-08-04T17:57:25Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"} <details</details<details</details<details</details<details</details<details</details
/sig network is this about pods with hostNetwork: true ? if not, why is this a kube-proxy issue if the problem is in INPUT?
/assign
Yeah, to be clear - filter INPUT applies to packets which are going to be delivered to a process. Is that kube-proxy's job to define?
The "How can we reproduce" sounds a bit like this always happens. Here is a better instruction
IMO is the best description of the problem:
This may be a better solution than let add rules in the INPUT chain
hehe, ironically we should decide to or , one is a sysctl call the other is one (or two) iptables rules. The iptables rule has also the side effect of breaking people (cc ) If we switch to set the option, the change does not seem to be backportable. I tend to agree with Lars, remove the iptables INVALID drop rule and set the sysctl, we are already setting more host sysctls what do you think?

it will be nice to have some iptables hackers opinion too
I tried to recreate this problem on virtual en (kvm/qemu) by requsting a 100MB file with curl and do; to provoke some packet loss. The transfer took longer time, but never failed.
IMO kube-proxy should not set any sysctls that are not literally required for functionality that the user has explicitly opted into (eg for most network plugins). Kube-proxy does not own the host network namespace, and it should not be doing things that will affect other people's host-network traffic, because if we do it's going to break some users. (See also: .) We can document that we think it's a good idea for users/distros to set , and if we think it's almost always a better idea than not, we can warn at startup if it's not set, but (IMO) we shouldn't set it ourselves. If we can get the same effect with an iptables rule that only affects kube-proxy's own traffic, then I think that's better than setting a sysctl that will also affect non-kube-proxy traffic. If I understand the situation here correctly, if kube-proxy a drop rule for the invalid conntrack packets, but then the administrator set , then the result would be that conntrack would not mark some packets as invalid, and so our drop rule would just not get hit, and so our drop rule wouldn't interfere with the "better" sysctl-based solution?
Agree in general. We have done it in the past (e.g. route-localnet) and mostly it seems like a not-great idea. Also agree.
If we see this as a known bug, please consider documenting it in - even if latest Kubernetes includes a fix (we can nevertheless point that out!)
I'll fix this in the next few days.
From further googling, it seems like there have been situations in the past where people were setting that sysctl to work around bugs in conntrack, which were later fixed. I think this may be another such situation; it seems like our problem is that there is some state involving dropped or retransmitted packets which linux would cope with fine in the non-conntrack case, but which it doesn't handle in the conntrack case, unless "be_liberal" is set, and that seems like a bug.

Every time I look away from this set of issues/PRs for longer than 15 minutes I forget the exact scenario that causes the bug, but if someone could summarize it very clearly we could try dragging some kernel developers in. (The regression test in the e2e suite creates a packet with an intentionally-bad sequence number, but it's not clear to me what sort of real-world issue that's supposed to be representing.)
Thanks now that was an excellent article! Well written (not TL;DR that is), and IMO perfect technical level. If there is some collection of recommended reading for persons who want to know about K8s networking, this article should be in it.
Hi thank you for the , it's really helpful! I have some questions: , should we update this sentence accordingly ==we use the above workaround, would there any side effect for the cluster network or cluster nodes?
That says "this problem will occur if conntrack is unable to recognize a packet", but it doesn't explain the real-world scenario that causes conntrack to be unable to recognize a packet. If we go to the kernel developers and say "manually injecting random incorrect packets into a conntrack'ed connection causes it to get confused", then they'll likely respond either "don't do that then" or "use ". But if we can tell them something like "if a connection has a duplicated packet after a dropped packet, then conntrack gets confused", then that sounds a lot more like a bug in conntrack that they ought to fix, such that then everything will just work for everyone in the future without needing any DROP rules or sysctls.
So do we need to revert the drop rules? As mentioned in , it now seems that this makes sense.
There are three potential "fixes" here: this is unambiguously a conntrack bug, then we should figure out the details, and get the kernel devs to fix it. However, getting kernel bug fixes into all k8s clusters in the world takes "a long time", so even if it is a kernel bug, we should still think about the other fixes. cluster admins can use . We should advertise this better, but we feel that it would be dubious to have kube-proxy set this flag itself ().

per we could probably tweak the existing rule so that it didn't interfere with non-k8s packets ~and as suggested by the OP of this issue, we could add a similar rule to the INPUT chain (though this would need a bit of further thinking about to make sure we weren't introducing any new conflicts with non-k8s traffic)~.
We could revert the DROP rules and tell people to use the sysctl instead (and actually, probably that's a better answer for this issue than adding a new DROP rule to the INPUT chain is). But we'd need to warn users in advance if we were going to do that, since it would break existing clusters.
Totally agree, This is a better fix for this issue. If this is a kernel bug and it gets fixed someday, we can easily tell the user that you don't need to set anymore. Also, If we revert the DROP rule, which can solve the routing asymmetry issue mentioned in , which is a big fix for us Yes, We need to document it and tell the user. and In order not to break the existing cluster, Do we need a flag to decide if we need the DROP rule? I'll make it default to , and make it consistent with the current logic.
but the change to only apply the DROP rule to pod traffic should also fix that We should not require administrators to choose between "high-traffic TCP services work" and "asymmetric routing works". The current DROP rule is broken. We should either fix it to work with asymmetric routing, or else remove it and tell people who needed it to use the sysctl instead. In the latter case, we might want to make the transition via a feature gate. Then people who need asymmetric routing to work can enable the feature gate in Alpha (to make kube-proxy stop creating the DROP rule), and people who need high-traffic services to work but who didn't get the memo about using the sysctl can disable the feature gate in Beta until they have a chance to update their node configs to set the right sysctl.
Refer to , The DROP rule to pod doesn't fix our case. In our case, the pods of the external cluster subnet failed to access the pods of the cluster subnet to connect due to asymmetric routing, So the packet still matches The DROP rule to pod. Do we need a KEP for this or only a feature gate?

In general, feature gates imply KEPs (and any change that will take multiple releases to complete, where we want to make sure we don't forget about it halfway through, should get a KEP, because we have processes for tracking those). It doesn't have to be a big KEP, and some of the sections of the KEP template will be irrelevant and can be omitted, because you're not introducing a new feature. (See for example.)
We are going to break users, unfortunatly features gates does not have the effect that we are assuming, and we know that all the users have to set the "ipconntracktcpbeliberal" because eventually some connections will be broken. I do no like to set sysctl, but 'm not in favor of replacing the rule and leaving the problem to users that may not even know what a sysctl is ... agree the DROP rule is broken and breaks some esoteric but legit scenarios, but we are already setting sysctls, so I think that if we don't find any alternative to the DROP rule we should try to set the sysctl for the user by default
If we skip a KEP, make sure that the release team know to track the details (comms, docs, etc) as if it were a KEP. This is an important thing to track.
Should we at least triage this as Accepted?
/triage accepted Some alternatives DROP rule and ask users to set sysctl (I'm not in favor per my previous comment and the least surprise principle) DROP rule and we set sysctl set DROP rule if is not set the DROP rule with a flag/config so users can opt-out if don't want to set it (they can decide to use the sysctl or live with that risk) ...
I can accept KEP, but I think this may take multiple releases to complete. how about this? We remove the DROP rule Control the sysctl with a flag or a feature-gate. If it's a flag, I believe it's relatively simple and we can finish it in 1.29. In the case of feature-gate, this may take multiple releases to complete.
If sets the to true by default, we can safely remove the DROP rule
Yes, but if we were doing it that way, that would be because we considered that to be a feature rather than a bug.

We want to avoid breaking working clusters on upgrade. Maybe just having a release note saying "you may need to pass to kube-proxy" is enough. I think we agreed we don't want to change any sysctls except by explicit admin request (because that affects the behavior of non-kubernetes networking as well).
Agree, but we need to think in the users, this is a problem where the fix that solve a sublte and complex bug that may affect 100% of kubernetes users and most probably they don't know they are affected, impact a esoteric network configuration on the cluster networking, and the solution we are offering is "please read the release notes", that we know only 20% of users do ... I think that advanced users can opt-out to the DROP rule if we don't want to mess with the sysctl,
If setting was a no-brainer good idea, then the kernel would just have that behavior by default. There must be some reason why they don't, and so I worry that if we set that flag by default, then we're just going to start breaking some other subset of users. Also, if it turns out that this is all just a conntrack bug, which eventually gets fixed, then we wouldn't want to be setting the sysctl after it got fixed. But at that point it would be likely that there were some users unknowingly relying on the sysctl for some other side effect.
We could potentially have an iptables rule to count invalid conntrack packets, and expose the count as a metric
I completely and absolutely agree. we should not make that sysctl a default in kube-proxy ... what if we read the sysctl and install the DROP rule only if it is not set? Users that apply the sysctl we no longer have the DROP rule
/assign let me send a PR , I think that approach covers all cases
FWIW, my kernel conntrack informant tells me that there really aren't any bad side effects of setting it ("I don't see anything that could break by enabling this mode"), and in fact OVN sets it unconditionally on hosts it's running on. He also tells me that the bug (at least in ) is fixed in kernel ~6.2~ 6.1 ("").

So I'm not sure if that means "we should just go ahead and set the sysctl because it's harmless" or "we should just keep it like it is now and not set the sysctl since it won't be needed in the future"... (NB: if the latter we still need a docs update to go along with this PR, telling admins about the sysctl.)
If we can determine that the kernel fixes the issue in a certain version, then I think we can do this: Do not install the DROP rule.If the kernel version of the host is greater than the safe kernel version, we do not set sysctl.If less than, we have a flag to set sysctl. I'll make it default to 1. (refer to ), And let the user know that we may remove this sysctl in the future.
Exactly my thought. I made this mistake with route_localnet, and we still pay for it. Let me do some internal outreach too, see if I can get a concurring opinion?
Kernel ppl here concur: "I say : if kernel can not be fixed, set tcpbeliberal to one " "having Kubernetes set net.netfilter.nfconntracktcpbeliberal=1 always SGTM, since you want it to work on any kernel version" argues for a flag, default to true (or a hegative flag, defsult false) which seems a bit paranoid, but probably smart :) Are we all in agreement? Who wants to do the PR?
already has a PR to add to the existing set of configurable conntrack sysctls in kube-proxy () so it's just a matter of flipping the default
If the sysctl defaults to true, I think this still keeps backward compatibility, So we don't need the DROP rule anymore.
I just realized that we need this to be a flag because there are cases that run kube-proxy on environments with readonly /sys subsystem, so trying to set it always will fail will and make kube-proxy unusable for those environments
if people does not set it, they will hit the bug until they use kernel 6.1
I mean this sysctl defaults to true in kube-proxy, I can't imagine why users would need to set it to false unless the kernel version is safe (6.1). Of course, we can also document that the user that it is better not to do this.

There are cases where we CAN'T set sysctls but should not hard-fail kube-proxy. On Wed, Sep 6, 2023, 11:25 PM Cyclinder
after setting the jobs for nftables and hitting the conntrack bug continuously I think we should default the flag to true and set the sysctl nfconntracktcpbeliberal to 1 , We are already setting some sysctl and for rootless or other environment they can always opt out, this is what we do in kind
Sounds OK to me. Risk should be ~zero, right?
Yes, I assumed the risk is when to 1, we do not set it by default, so default to 0(see ). I'd be happy with it, Can I have this one?
Talked with offline, I don't have very strong arguments to make this enable by default , so let's wait for more user feedback, nftables will move to beta this release, we can revisit if we have more feedback from users
we are considering turning on by default in our kube-proxy 1.29+ deployments. Based on the recent discussion here that seems fine and the risk should "be ~zero"(), correct? And you are all even discussing turning this on by default in kube-proxy in some future version? One thing I'm a little confused on: is doing the same thing as turning on ? So by setting you're just turning on behavior that will be on by default in 6.1. Did I get that right?
Not exactly. affects a handful of situations. 6.1 only "normalized" one of them. The general intent of is something like "make conntrack work better with packets from broken TCP implementations". But the netfilter devs realized that one of the places it was being used was actually something that could happen due to totally normal TCP packet drops/retransmissions. And so in 6.1+, that particular situation is just handled correctly automatically, whether is enabled or not. My argument against this is that once we do it, we have to keep doing it forever, because people might start unwittingly depending on the other side effects of that sysctl. And particularly given that people never hit the bug anyway.

(It seems like we got more reports of the "my cluster is broken because of the DROP rule" bug than we ever got of the "my cluster is broken because of conntrack invalid packet handling" bug.) day once everyone has moved to 6.1 the bug will be gone forever ISTM that it's better to still not set it by default.
Thanks for the clarification on the 6.1 bugfix That's true and they probably will. I'm just trying to leverage some of the earlier discussion here to make a decision about the safety of flipping this to true, as it seems like the concern was not too high / basically nil.


Question: for line, pairs := range item.steps { p.sync(testEnumerator(pairs)) <del> ids := s.Contains() </del> <ins> ids := s.ContainedIDs() </ins> for _, pair := range pairs { if !ids.Has(pair.id) { t.Errorf("%v, %v: expected to find entry for %v, but did not.", testCase, line, pair.id)

The client/cache interface has a method which is supposed to return a of the IDs in a store. This is a bit misleading and should probably be renamed to 'Contents' or 'ContainedIDs'.
Thoughts
I tend to agree. contains to me should always return a bool and take an input key. Sent from my iPhone
Yeah, I agree, both of the suggested names would be an improvement.


Question: - level: Metadata ` <ins> const policyWithUnknownField = ` apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: None resources: - group: coordination.k8s.io resources: - "leases" verbs: ["watch", "get", "list"] # invalid indentation on verbs ` </ins> var expectedPolicy = &audit.Policy{ Rules: []audit.PolicyRule{{ Level:           audit.LevelNone,

Currently the [audit policy decoder][1] silently drops unknown fields. For backwards compatibility, we probably cannot fail on unknown fields, but it would be good to at least log a warning when they're encountered. [1]: /sig api-machinery
/triage accepted
/help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I'm not familiar with apiserver, but this seems like a simple one. /assign
How can we find unknown fields in the yaml file? Currently I'm think of converting both the yaml file and the decoded Policy struct to two map[string]interface{}, and compare both map to find out which keys are in the yaml file but not in the decoded struct, is there any better solution?
Courtesy on slack:


Question: <del> # See the OWNERS docs at https://go.k8s.io/owners approvers:  #sig-cluster-lifecycle is the owner of this feature - luxas - wanghaoran1988 reviewers: - mikedanese - luxas - dmmcquay - krousey - wanghaoran1988 emeritus_approvers: - jbeda </del>  No newline at end of file

/assign Cannot find either of these aliases ref
thanks /sig cluster-lifecycle let me know if want me to PR a fix, yet i don't know what action to take. do you wish to keep these aliases?
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
/lifecycle frozen
/assign /lifecycle active


Question: }, }, }, <ins> { name:          "v1beta1 Ingress to extensions Ingress", file:          "../../../../test/fixtures/pkg/kubectl/cmd/convert/v1beta1ingress.yaml", outputVersion: "extensions/v1beta1", fields: []checkField{ { expected: "apiVersion: extensions/v1beta1", }, }, }, </ins> } for _, tc := range testcases {

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


Question: } klog.V(2).Infof("Trying to attach volume %q lun %d to node %q.", diskURI, lun, nodeName) <ins> c.diskAttachDetachMap.Store(strings.ToLower(diskURI), "attaching") defer c.diskAttachDetachMap.Delete(strings.ToLower(diskURI)) </ins> return lun, vmset.AttachDisk(isManagedDisk, diskName, diskURI, nodeName, lun, cachingMode, diskEncryptionSetID) }

<!-- 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: We found that cloud provider tries to attach a disk, it totally costs 121s in the end one minute(disk still in being detaching state), azure cloud provider tries to delete that disk and it succeeded 121s, attach disk operation succeeded and finally azure vm has attached one non-existing disk What you expected to happen: should not delete an azure disk when that disk is being attached How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: The difficulty here is when a disk is being attached or detached, the disk state is still "unattached", would be the reason why delete disk at that time would succeed: Azure disk RP would have two options to fix this issue: a new disk state: , disk delete operation when disk is being attached or detached Otherwise on azure provider(client) side, we cannot know whether that disk is being attached or detached since the second delete disk operation is done after 1 min 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: // pod created, no more work possible for this round continue } <ins> // If the Pod is in pending state then trigger PVC creation to create missing PVCs if isPending(replicas[i]) { klog.V(4).Infof( "StatefulSet %s/%s is triggering PVC creation for pending Pod %s", set.Namespace, set.Name, replicas[i].Name) if err := ssc.podControl.createMissingPersistentVolumeClaims(set, replicas[i]); err != nil { return &status, err } } </ins> // If we find a Pod that is currently terminating, we must wait until graceful deletion // completes before we continue to make progress. if isTerminating(replicas[i]) && monotonic {

User cordons a node with a pvc bound to a local persistent volume User deletes a stateful set pod from that node The pod is in pending because the pvc is still bound to a local pv on the cordoned node (expected) The node dies and the pvc is deleted The pod is still stuck in pending because the pvc is missing (bug) The pod now needs to be manually deleted so that the pod+pvc can be recreated After the pvc was deleted, the statefulset controller should have recreated it and bound it to a new node's local pv so that the pending pod could be scheduled. Currently the only way to get the pod out of pending is to manually delete it so that it recreates itself and its pvc We used for the local PVs, but the problem is not limited to this particular provisioner create a stateful set with a pvc that is bound to a local PV use to cordon a node with a local pv delete a statefulset pod from that node delete the pvc from that node the pod is now stuck in pending due to a missing pvc There was a related issue but this only fixed the issue when the order of operations was delete pvc -delete pod. but in this case, it is delete pod -delete pvc <details</details<detailsTested on aws and gcp </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 apps storage
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
/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
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]:
This issue was fixed by The new issues look different. /close
Closing this issue. <detailsIn response to : This issue was fixed by The new issues look different. 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: } mods := strings.Split(string(out), "n") <del> return mods, nil </del> <ins> return append(mods, bmods...), nil </ins> } // CanUseIPVSProxier returns true if we can use the ipvs Proxier.

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Deploying kube-proxy with mode ipvs on a system with the required ipvs support compiled into the kernel rather than as modules causes the kube-proxy deployment to fall back to using iptables. tryIPVSProxy is only checking for the presence of kernel modules and not if the running kernel has the required support compiled in. What you expected to happen: tryIPVSProxy should succeed if either the required modules are found or support is compiled into the running kernel. How to reproduce it (as minimally and precisely as possible): Boot a system using a kernel with ipvs support compiled in rather than as a module (such as the kernel used by and a host without iptables installed Add --config=/etc/kubernetes/kubelet- to the kubelet arguments using the following kubelet- contents: Install using kubeadm with the following config: Check the output of the kube-proxy pod: Anything else we need to know?: From , it should be possible to check for the existence of modules.builtin and if present use that in addition to using modprobe and the contents of /proc/modules. Environment: Kubernetes version (use ): v1.10.2 Cloud provider or hardware configuration: local kvm host OS (e.g. from /etc/os-release): custom linuxkit build Kernel (e.g. ): Linux linuxkit- 4.14.40-linuxkit SMP Thu May 10 10:06:57 UTC 2018 x86_64 Linux Install tools: kubeadm
/sig network
/cc
cc
cc please take a look.


Question: gen_deepcopy: $(DEEPCOPY_FILES) if [[ -f $(META_DIR)/$(DEEPCOPY_GEN).todo ]]; then                 $(DEEPCOPY_GEN)                                                <del> -i $$(cat $(META_DIR)/$(DEEPCOPY_GEN).todo | paste -sd,)   </del> <ins> -i $$(cat $(META_DIR)/$(DEEPCOPY_GEN).todo | paste -sd, -)   </ins> --bounding-dirs $(PRJ_SRC_PATH)                            -O $(DEEPCOPY_BASENAME);                                   fi

I don't know where the at the beginning of the target comes from, but probably from assumptions about sed version that are wrong. I had to update to gnu-sed 4.2.2 to build.
Also ootb on a Mac doesn't work with the rules specified (on el capitan):
does work
I take it back - updating sed did not appear to work. EDIT: I take that back, I had to clean after fixing paste.
most recent OSX version is UNIX certified, a POSIX requires as file argument when reading input from stdin. For , is only guaranteed to work in GNU sed, you need to insert literal newline and tab character there for portability.
Can someone with a mac send a patch? I don't have a mac...
It's update and every should end in instead of having no arguments. , Tim Hockin wrote:
(user should update sed, make needs changes to paste) , Clayton Coleman wrote:
I think we should stick to portable way for , it's too risky for relying on GNUism. If you don't mind, I will make a PR.
Sure, thanks , Cuong Manh Le wrote:
Are you sure the worked? I pull the latest from master, then run the same command above, I got: File is empty.
Make sure you are in your GOPATH in the correct spot for Kube On Jul 14, 2016, at 2:47 AM, Cuong Manh Le wrote: Are you sure the Makefile worked? I pull the latest from master, then run the same command above, I got: F0714 13:36:50. ] Error: Failed making a parser: unable to add directory "": unable to import "": expected 'package', found 'EOF' make: * [Makefile.generatedfiles:201: gendeepcopy] Error 255 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .
If you get the "expected 'package', found 'EOF'" message it is usually because something somewhere failed, and left an empty .go file. make cleangenerated , Cuong Manh Le wrote:
From BSD sed man page: Maybe try that?
It's not about ERE ( enables it), it's about expanding escape sequences in RHS of search and replace .


Question: } func (c *CompositedCompiler) CompileAndStoreVariable(variable NamedExpressionAccessor, options OptionalVariableDeclarations, mode environment.Type) CompilationResult { <del> c.CompositionEnv.AddField(variable.GetName()) </del> result := c.Compiler.CompileCELExpression(variable, options, mode) <ins> c.CompositionEnv.AddField(variable.GetName(), result.OutputType) </ins> c.CompositionEnv.CompiledVariables[variable.GetName()] = result return result }

Variables field is to ValidatingAdmissionPolicy in 1.28. Currently the usage of variables would expect a operator associated. e.g. (thanks to Mariam Fahmy for raising the issue) Above will fail with error: Meanwhile the will pass. The reason is when variables be evaluated to non dyn type(like bool or string), it will require special handling(like casting) since we use dyn type everywhere. It might confuse user.
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
/triage accepted /sig api-machinery /cc
Tests I'd expect to see verify this behavior: PASS: A variable is of type bool, an expression returns the variable PASS: A variable is of type string, a messageExpression returns the variable PASS: A variable is of type dyn, at runtime the dyn is a bool, an expression returns the variable PASS: A variable is of typedyn, at runtime the dyn is a string, an messageExpression returns the variable PASS: A expression is of type dyn, at runtime the dyn is of type bool PASS: A messageExpression is of type dyn, at runtime the dyn is of type string COMPILE ERROR: A variable is of type bool, an expression tries to perform a non-bool (e.g. string replace) operation on the variable, this should resultsin a compile error COMPILE ERROR: A variable is of type string, an expression tries to perform a non-string (e.g. less than) operation on the variable, this should result in a compile error RUNTIME ERROR: A variable is of type dyn, at runtime the dyn is a bool, an expression tries to perform a non-bool (e.g. string replace) operation on the variable, this should result in a runtime error I'd also expect to see some cases covering variables of other types (maps, lists, duration, quantity, ...) to make sure we're over-fitting for bool and string.
/retitle ValidatingAdmissionPolicy: variable expression type not recognized as return type in expression that evaluates the variable
/assign


Question: } } <ins> func TestDoubleOccupyRelease(t *testing.T) { // Run a sequence of operations and check the number of occupied CIDRs // after each one. clusterCIDRStr := "10.42.0.0/16" operations := []struct { cidrStr     string operation   string numOccupied int }{ // Occupy 1 element: +1 { cidrStr:     "10.42.5.0/24", operation:   "occupy", numOccupied: 1, }, // Occupy 1 more element: +1 { cidrStr:     "10.42.9.0/24", operation:   "occupy", numOccupied: 2, }, // Occupy 4 elements overlapping with one from the above: +3 { cidrStr:     "10.42.8.0/22", operation:   "occupy", numOccupied: 5, }, // Occupy an already-coccupied element: no change { cidrStr:     "10.42.9.0/24", operation:   "occupy", numOccupied: 5, }, // Release an coccupied element: -1 { cidrStr:     "10.42.9.0/24", operation:   "release", numOccupied: 4, }, // Release an unoccupied element: no change { cidrStr:     "10.42.9.0/24", operation:   "release", numOccupied: 4, }, // Release 4 elements, only one of which is occupied: -1 { cidrStr:     "10.42.4.0/22", operation:   "release", numOccupied: 3, }, } // Check that there are exactly that many allocatable CIDRs after all // operations have been executed. numAllocatable24s := (1 << 8) - 3 _, clusterCIDR, _ := net.ParseCIDR(clusterCIDRStr) a, err := NewCIDRSet(clusterCIDR, 24) if err != nil { t.Fatalf("Error allocating CIDRSet") } // Execute the operations for _, op := range operations { _, cidr, _ := net.ParseCIDR(op.cidrStr) switch op.operation { case "occupy": a.Occupy(cidr) case "release": a.Release(cidr) default: t.Fatalf("test error: unknown operation %v", op.operation) } if a.allocatedCIDRs != op.numOccupied { t.Fatalf("Expected %d occupied CIDRS, got %d", op.numOccupied, a.allocatedCIDRs) } } // Make sure that we can allocate exactly `numAllocatable24s` elements. for i := 0; i < numAllocatable24s; i++ { _, err := a.AllocateNext() if err != nil { t.Fatalf("Expected to be able to allocate %d CIDRS, failed after %d", numAllocatable24s, i) } } _, err = a.AllocateNext() if err == nil { t.Fatalf("Expected to be able to allocate exactly %d CIDRS, got one more", numAllocatable24s) } } </ins> func TestGetBitforCIDR(t *testing.T) { cases := []struct { clusterCIDRStr string

<!-- 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: With a /22 pod network and a /24 assigned to each node, a third node cannot get a pod CIDR if kube-controller-manager has ever been restarted. What you expected to happen: Once a third or fourth node joins, it gets a /24. How to reproduce it (as minimally and precisely as possible): 150% usage on the IPAM controller is not a good sign. Anything else we need to know?: During the creation of the rangeAllocator, Occupy() is called twice on the pod networks. The first time is before subscribing to the node informer. The second time is during the node informer callbacks because on subscribing it calls Add for all existing nodes. I will submit a proposed fix shortly. Environment: Kubernetes version (use ): 1.19.2
/sig network
/triage accepted thanks for finding the bug I 've introduced :)


Question: <ins> /* Copyright 2016 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package cmd import ( "bytes" "fmt" "io" "os" "github.com/spf13/cobra" "k8s.io/apimachinery/pkg/apis/meta/v1" cmdutil "k8s.io/kubernetes/pkg/kubectl/cmd/util" "k8s.io/kubernetes/pkg/kubectl/cmd/util/editor" "k8s.io/kubernetes/pkg/kubectl/resource" ) // NewCmdEditConfigMap is a macro command to edit config maps func NewCmdEditConfigMap(f cmdutil.Factory, cmdOut, errOut io.Writer) *cobra.Command { options := &resource.FilenameOptions{} cmd := &cobra.Command{ Use:     "configmap", Aliases: []string{"cm"}, Short:   "Edit a config map object.", Long:    "Edit and update a config map object", Run: func(cmd *cobra.Command, args []string) { RunEditConfigMap(cmd, f, args, cmdOut, errOut, options) }, } addEditFlags(cmd, options) cmd.Flags().String("config-map-data", "", "If non-empty, specify the name of a data slot in a config map to edit.") return cmd } // RunEditConfigMap runs the edit command for config maps. It either edits the complete map // or it edits individual files inside the config map. func RunEditConfigMap(cmd *cobra.Command, f cmdutil.Factory, args []string, cmdOut, errOut io.Writer, options *resource.FilenameOptions) error { dataFile := cmdutil.GetFlagString(cmd, "config-map-data") if len(dataFile) == 0 { // We need to add the resource type back on to the front args = append([]string{"configmap"}, args...) return RunEdit(f, cmdOut, errOut, cmd, args, options) } cmdNamespace, _, err := f.DefaultNamespace() if err != nil { return err } cs, err := f.ClientSet() if err != nil { return err } configMap, err := cs.Core().ConfigMaps(cmdNamespace).Get(args[0], v1.GetOptions{}) if err != nil { return err } value, found := configMap.Data[dataFile] if !found { keys := []string{} for key := range configMap.Data { keys = append(keys, key) } return fmt.Errorf("No such data file (%s), filenames are: %vn", dataFile, keys) } edit := editor.NewDefaultEditor(os.Environ()) data, file, err := edit.LaunchTempFile(fmt.Sprintf("%s-edit-", dataFile), "", bytes.NewBuffer([]byte(value))) defer func() { os.Remove(file) }() if err != nil { return err } configMap.Data[dataFile] = string(data) if _, err := cs.Core().ConfigMaps(cmdNamespace).Update(configMap); err != nil { return err } return nil } </ins>

Kubernetes version : What happened: When I try to display configmap content with yaml output (kubectl get configmap webapp-inifile -o yaml), the output is sometimes pretty, and sometimes not -depending newlines are effectively displayed or not - just n char- I can't find what's the difference between some file and some others. (limit on numer of lines ?) Configmap is created with --from-file option Ex : What you expected to happen: More human readable display, in order to be able to easily change parameter when kubectl edit congifmap How to reproduce it :
Hrm, this seems to me like the right answer is to special case 'kubectl edit' for configmaps, rather than try to hack around with the YAML decoder. I suppose we could use block quotes (e.g. ) if we see newlines but that seems error prone...
Closing this, pretty print is there, kubectl configMap edit support is there.
This still happens on kube 1.7 :-( I'm not 100% sure how to reproduce, but what I did was: have an existing configmap and edit a few lines exit the editor ... now I see the characters instead of actual newlines. even shows the characters
I'm also seeing this issue in kube 1.7. During the past few days I have edited a configmap ~110 times, and seen the formatting get destroyed (spaces messed up, characters visible) twice. I can't determine anything specific that I did in those two edits that would have triggered the formatting messup.
I'm still seeing this issue too. Pushed a lot of identical configmaps, some ones are displaying good, and some other bad. For example, I have a configmap with 3 files in ; they all are identical except one variable ; 2 of them display normally, and the last one displays with n ...
also seeing this issue on 1.7
can we reopen this issue? or open a new one?
I created a brand new configmap using and when I viewed the yaml with it's full of n characters and escape characters. This makes it very difficult to edit.
I am experiencing the same. n character is messing up a configmap I'm creating with --from-file option. Anyone found a reason why this is happening ?

Also failing in 1.8.4
I am also facing the same issue of formatting .. I have a application configuration of 400-500 lines. Tryied many times. For fist 40-50 lines the format is good ans easily readable.. However, when i try to create config for entire configuration file its very difficult to edit the config map..
Same issue here. No idea what makes one configmap show better than another.
This issue corrupted my aws-auth configMap that authenticates my user to access the EKS cluster and while trying to add other users to the configMap the formatting corrupted the configMap file and now I am locked out of my EKS cluster. Version: 1.10.3
I don't know if this will help somebody else but I was facing the same issue with escaped data in a config map edit and get (the config map had a single .conf file), and it seems that I had a unneeded extra space at the end of a single line in my data. When I removed that extra space the pretty printing was maintained in edit and get.
11 Still same
still same ( there is an example if install helm install stable/prometheus , you will find cm/prometheus-server )
I agree with - I can recreate it every time If you were to execute the following (ensuring no trailing spaces), the configmap remains "pretty" However, repeat the above (or edit the existing one with ), and put a trailing space after one of the key/value pairs, and that then messes up the configmap contents
Can we reopen this issue? I need this feature to change the yaml in cm, and I have been struggling with the intent and n for several days ...
Please reopen this ticket, it's incredibly frustrating to have to deal with this even on small configmaps
Got this also. I had to remove tabs from my config file to get the yaml multiline display.
Just created a messed up configmap on kuberntes 1.12.2.
Likewise.
OMG thank you!
Just ran into this in EKS (1.10.3) -- highly annoying. I have one config map that will come out OK if I use create directly, but if I pipe the output of to apply then it gets munged. Does seem like this is something that needs addressing.

Have the same issue and fixed by removing tabs
Have the same issue, don't have any tabs in file. This issue totally should be reopened.
This issue is valid and I am not sure why it was closed
Not only spaces. Trail symbols too. I uses vim for it
"n n" (spaces between end of lines) in one of my files also messed up the pretty display.
Created a new issue when I hit this again and was able to repro using the trailing whitespace
I've removed all the trailing whitespaces and tabs. The problem is gone.
Check any possible special chars. It solve my problem some time ago
I have seen this issue in K8 1.7 -1.13 kubectl create configmap NAMESPACE --from-file=$PATCHFILE --dry-run=true --output=yaml where PATCHFILE is attached file below. I renamed it from .json to .log so this webpage would let me include it.
Solve the issue by delete whitespace at each end of line.
The output of is ugly. Wether using json or yaml, k8s injects a whole bunch of escape characters and messes up the formatting of the original config file. It would be very nice to have a switch that tells it to dump the config out "normally"!
I a new line in a configMap using Tab for identation. After changing to Spaces instead of Tab, I was able to see the configmap as expected...
Same here, white space/s at the end of line ruin the output, everything back to pretty when white space/s removed.
This worked for me.
Since I've still met this on 1.16, I'll point a bullet list of the regular culprits for the configmap messing: spaces before newline:Tabs:Special characters like ãẽõ, áéó, öß will also mess your files. Look up for them in your comments, they might pass through!
An easy one liner to remove trailing whitespaces in a ConfigMap:
Please reopen. This issue still remains. This format makes eks aws-auth configmap very hard to maintain. Once the file is applied with trailing whitespaces the whole thing gets lots of n and . As a temporary measurement is there a way to reformat the configmap in the "readable" way? after the n are created?

if you use way didn't reformat the file for me.
Nurza's method works. But you may have a space before EOF as well: Or you may have CR's in there , in which case you should remove the CRs. Or you may have a TAB, which you should replace with one or more spaces.
No CR/TAB/new lines. I have a "clean" file that after I apply it all works great. (display as expected) After I add one trailing white space to it, it gets those n. I tried to run Nurza's method but it didn't work. Any other Ideas why Nurza's method is not working for me ? This a part of the output I'm getting with
has a space after it, although you don't see it. Because the LF is on the next line, there must be a space before it.
Correct but if I run Nurza's method the n are still there. Am I still missing anything? This is what I run
Nobody said that sed expression was perfect. Once you know this is your doing -- and you know how to fix it -- you're not bothered by this behaviour anymore.
This is scary shit :hankey: ... what is the industry practice to edit the file like these: aws-auth...? I managed to type 20+lines by hand :disappointed: and it worked on 3rd attempt :disappointed_relieved:
Cant' say about the 'like this', but aws-auth you can use eksctl to do the hard work for you:
If the formatting of cm goes wierd a simple hack to get it back to normal is : kubectl get cm configmapname -o yaml cm.yamlNow copy the contents of file and past it on is powerful tool to check the linting of yaml files. This will provide you with the configmap as expected with correct formatting. Paste the output in another yaml file (for e.g - )kubectl apply -f
Anyone knows why the issue is closed? It's not fixed as far as I can tell.

If you just want the raw output as it was read in when created --from-file, you can use jq to get the raw string (without escaped newlines etc) If you created a configmap from a file like this: Get the data:
Edited a cm, came back in, and had n all over. Something about white space in my previous edit? Not great overall :/ On kubectl version Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.5", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-07-04T15:01:15Z", GoVersion:"go1.14.4", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.6", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-11-13T11:11:50Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}
Awesome, very good website~
Thank You very much
I was able to fix this behavior by: 1) Don't use tabs, convert to spaces 2) To remove spaces before a newline character, use this: It will also convert CRLF to LF only, by removing .
Something small that exacerbates this issue is that in python's standard lib module , up to some version (I think python 3.4, see ), pretty printing adds a trailing space after every comma by default, unless you supply a list of separators yourself that omit the spaces (e.g. like ) So if you have old-ish glue (e.g. python 2.7) that parses a k8s configmap into a file for archival purposes, and you made that file readable by pretty-printing it, using that file to regenerate a new configmap results in this gross escape behaviour.
Hello There, One of our colleague has edited configmap with wrong data, now whole cluster inaccessible with any of role, need help on immediate basis and much appreciated. Error: through eksctl - Error: getting auth ConfigMap: Unauthorized through kubectl error: You must be logged in to the server (Unauthorized)
yaml marshallers will write a string to a multiline string e.g.

UNLESS string contains a character string terminates in a space character string contains a substring which matches the regex
I am in the same situation. Were you able to solve this?
Also reproduce in v1.22.3 :(
I occasionally encountered this problem in v1.15.6 or v1.21.2, but eventually I was able to deal with it by using edit and then using vim's own set list to back-propagate the original static configmap code configuration under gitlab to see if there were extra spaces, and then modifying the local configmap file based on the online configmap's set list display under edit. The state of the online configmap under edit, to modify the local configmap file, is ultimately able to deal with this problem, but if there is a better official way to do it would be good.
yes if you are working on linux
i would like to share an observation that helped me sort out the line merging and n. it appears to be related to the last line of the file you are using (--from-) if the last line ends with empty space or tab. the config map is merged up in one line with n as line feed if you remove the empty space from the last line, the ConfigMap will import file as is with +
I got the same error after editing the ConfigMap file. I used an online tool to remove the trailing white space that we cannot see in the text. After copying the content which removed trailing whitespaces I was able to resolve this issue FYI - (online tool which I used)
in v1.24 also i can see same issue. how we can edit cm with many lines.
Finally, I found that the absence of a value defined or the value is empty string in will cause the issue. data: {{ }} is not defined in my yaml just use quote to the value resolved
delete space before n or after n it works for me
did anyone find solution when we edit cm how we can see in proper format as for me really difficult to edit cm as we have many n char and I can still see this issue in k8s version 1.28


Question: <ins> .PHONY:	build push IMAGE = pause TAG = 0.8.0 build: ./prepare.sh docker build -t gcr.io/google_containers/$(IMAGE):$(TAG) . push:	build gcloud preview docker push gcr.io/google_containers/$(IMAGE):$(TAG) all:	push </ins>

I believe this just requires changing the image name , but I wanted to check that there isn't other work to do before we move it. IIRC, the pause pod is cached on containervm, so we should make sure the tag is also cached. cc
kubernetes/pause is cached in ContainerVM image, should we remove it after host kubernetes/pause?
I am going to do this, since I plan to push etcd_server to today.
I think we still want to cache it in ContainerVM image, just with the tag.


Question: deps = [ "//pkg/features:go_default_library", "//pkg/scheduler/listers:go_default_library", <ins> "//pkg/scheduler/metrics:go_default_library", </ins> "//pkg/scheduler/nodeinfo:go_default_library", "//pkg/scheduler/nodeinfo/snapshot:go_default_library", "//pkg/util/node:go_default_library",

<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add a metric to track scheduler cache size. metric name Description -- -- schedulercachesize Number of elements in scheduler cache. Why is this needed: Gives better observability of scheduler cache. For, the number of "assumedpods" gives us an idea of how many pods are "assumed" and therefore being "bound". We can compare this with number of to make sure assume-bind works as expected. /sig scheduling
Is anyone already working on these metrics? If not I'd like to help out /assign
Thanks . Feel free to work on this one. Just a reminder, we may need feedback/approval from sig-instrumentation.


Question: framework.ConformanceIt("should function for node-pod communication: http [LinuxOnly] [NodeConformance]", func() { config := e2enetwork.NewCoreNetworkingTestConfig(f, true) for _, endpointPod := range config.EndpointPods { <del> config.DialFromNode("http", endpointPod.Status.PodIP, e2enetwork.EndpointHTTPPort, config.MaxTries, 0, sets.NewString(endpointPod.Name)) </del> <ins> err := config.DialFromNode("http", endpointPod.Status.PodIP, e2enetwork.EndpointHTTPPort, config.MaxTries, 0, sets.NewString(endpointPod.Name)) if err != nil { framework.Failf("Error dialing HTTP node to pod %v", err) } </ins> } })

What happened: final passing output: What you expected to happen: Probably if this test passes, it should be showing several real endpoints. I don't know exactly what it does, but im assuming that the output could be clarified a little. How to reproduce it (as minimally and precisely as possible): run and look at the logs. Anything else we need to know?: Environment: Kubernetes version (use ): 1.20 (sonobuoy)
/sig-network
/assign
/triage accepted
^ an interesting case here was that was but there was no SIG (typo in the command that did). should the label be only if there is label on the ticket? /sig network
the PR that adds triage/accepeted automation () was merged 3 hours ago, but it'll "actually" get rolled out in the next prow bump. Mostly when merges. Thanks for flagging though, appreciate it! :)
sorry, missed the actual question! :woman_facepalming: (need moar coffee!! :coffee: ) I don't think we should require a label for adding the label. In case someone comments with the following, we'd still want it to be valid.
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
The above test cleans up the By directives and so on, After reading through the test more its clear that every test sets up a scaffold measures a property of that scaffold sometimes deletes something that is recovered in that scaffold (i.e. a pod that is behind a UDP service) So, the thing that was confusing I guess to me is that we validate empty conditions (i.e. no pods available) once we delete a nodePort svc. Meanwhile also noticed that the original work to clean up error reporting needed to cascade over to these tests as well.Have just finished all that, and also updated comments to reflect the Todo around the statistical computation (we have the ability to do extra polling via but we don't actually have any test that leverages this.As a follow on I guess it would be nice if we did have a test that confirmed that pods were load balanced evenly, esp with the new proliferation of different proxy technologies , I.e. a (or something similar


Question: test.predicates[algorithmpredicates.MatchInterPodAffinityPred] = algorithmpredicates.NewPodAffinityPredicate(FakeNodeInfo(*nodes[0]), schedulertesting.FakePodLister(test.pods)) } nodeNameToInfo := schedulercache.CreateNodeNameToInfoMap(test.pods, nodes) <ins> // newnode simulate a case that a new node is added to the cluster, but nodeNameToInfo // doesn't have it yet. newnode := makeNode("newnode", 1000*5, priorityutil.DefaultMemoryRequest*5) newnode.ObjectMeta.Labels = map[string]string{"hostname": "newnode"} nodes = append(nodes, newnode) </ins> nodeToPods, err := selectNodesForPreemption(test.pod, nodeNameToInfo, nodes, test.predicates, PredicateMetadata, nil, nil) if err != nil { t.Error(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!--What happened: kube-scheduler crashes (panics) in rare circumstances. Stack trace: What you expected to happen: flawless operation ;) How to reproduce it (as minimally and precisely as possible): Unclear. The error above looks like it was associated with some cloning of node metadata. Perhaps due to a race during node scale-up/scale-down and cache interactions. Anything else we need to know?: Environment: Kubernetes version (use ): <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig scheduling
are you using hostPort for your workload?
is there a specific workload you had in mind? The does, as well as daemonsets for our service mesh, which are in host networking mode.
There was a PR () in v1.12/v1.11.3 fixing issue when workloads uses hostNetwork, and the solution is to correct the NodeInfo cloning logic. So it's quite likely related with the symptom you described. Could you give a try on v1.11.3?
BTW: the issue that PR fixed is only reproducible on some circumstances.
Thanks - I'll give this a whirl. I think I can optimistically close this issue - we'll reopen if it persists with a more recent autoscaler release. Cheers!
Sounds good! Thanks for the feedback.
we just had a similar issue this morning and our cluster is running kube 1.11.4: and these are the error logs : we do have hostNetwork work load running inside our cluster but not sure if that's caused by other issues since you mentioned that hostNetwork issue has been fixed since 1.11.3.
could you re-open this issue ? or I can raise a new issue for it.
/reopen I will take a look.
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
thanks
are the worker nodes auto scaled out/in? e.g. by an auto-scaler component?

yes, we do have an autoscaler to auto scale our worker nodes and we are using since most of our workloads are job based.
I see. It's likely an internal cache inconsistency. (not related with the hostPort issue I fixed earlier) /assign
One thing I'm curious is from the log it points to L386 of Then it means is nil, but should't give a panic trace at the first call inside ? Say: I looked through the code, but can't find a place that could be nil. So are you using raw v1.11.4-beta.0 branch, or did some modification? As in my opinion, it makes sense the panic comes from L385:
No, in Go if n.requestedResource is nil, you will get a stack trace similar to what is given in this issue.
I read it differently. I wrote an example , it shows deepest trace at L12, rather than L17.
I was actually wondering if it's possible that the stack trace isn't 100% line accurate.. Either that it systematically hits the next line in this case, or that the order in which field copies are executed isn't a simple 1:1 (linear) relationship to the code.
it's interesting, maybe it's some trick (or bug) in apimachinery's runtime.HandleCrash()? And I wrote a test to reproduce the issue, even the same line on the deepest stack trace: (although I think it should be line above)
/reopen I will raise cherrypick PRs to 1.12 and 1.11, and close this issue by then.
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
Hi i have scaled my cluster to 100 node from 40 nodes as there were 400 pending pods and for some of the nodes all pods get schedule properly while around 28 nodes have only dnsmasq and kube-proxy was running. after around 40 min those node had weave and other pods started running. i coundn't able to find any other issue in my cluster apart from kube-scheduler got restarted because same error mentino in the issue. though it restarted in few second.

i was just wondering that if after restart would it takes 30-40 min to schedule pods? cause after 40 min everything seems to be working properly. I am running kubernetes 1.12.1 and i have installed it using kops 1.10.0
fix of this issue is cherrypicked (PR ) into v1.12.4. Could you give a try on v1.12.4?
Close this as fix has been applied to 1.11+ k8s versions. /close
Closing this issue. <detailsIn response to : Close this as fix has been applied to 1.11+ k8s versions. 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: go_rules_dependencies() go_register_toolchains( <del> go_version = "1.11.1", </del> <ins> go_version = "1.11.2", </ins> ) docker_repositories()

go 1.11.2 is out 11/2 and this bug tracks upgrade to the latest version. Is it something we should absolutely needed in the 1.13 timeframe? are there any that should absolutely take? how long does the associated image updates and push take? If we chose to upgrade in 1.13, we should do it before code slush targeted for Friday 11/6. /assign can you please clarify the above ques and and help evaluate timing of the upgrade. /cc /sig release /sig testing /priority important-soon /kind cleanup
/cc I’ve already got a branch cooking for this, but waiting for rules_go support first. I think said in Slack that this will happen this week.
Ahh so is the earliest expected timeframe when we can upgrade falls into Code slush period for 1.13 (post 11/9?) Depending on when it lands we might want to see if its safe to wait for 1.13.1. are you aware of any critical fixes that make this compelling for 1.13 timeframe?
The risk for patch golang point releases is typically low (the minor releases, like 1.10 -1.11, are higher risk). I don't see anything that's critical or of known impact, but at the same time, I see compiler fixes and go/types package fixes. They are more subtle and could present issues later. I'd suggest that if we can tolerate getting it in, even if we're in slush, we should.
Ack that :) Plz ping this bug as soon as we are ready to build and push the upgraded images. we'll will make a final call depending on the timeframe and CI signal going in. thanks!


Question: <ins> #!/usr/bin/env bash # Copyright 2021 The Kubernetes Authors. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # #     http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. set -o errexit set -o nounset set -o pipefail # This will canonicalize the path KUBE_ROOT=$(cd "$(dirname "${BASH_SOURCE[0]}")"/../.. && pwd -P) cd "${KUBE_ROOT}" # convert dumped spec (see dump-spec.sh) to conformance.yaml go run ./test/conformance/walk.go --source="${KUBE_ROOT}" ./_output/specsummaries.json > ./_output/conformance.yaml </ins>  No newline at end of file

The currently provided command for generating requires bazel, the command should be updated to one which does not require bazel Currently: Suggested: /sig testing /sig architecture /area conformance
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
/assign /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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
/remove-lifecycle rotten /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 : /remove-lifecycle rotten /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository.

</details
We're going to need to update this to verify under as well instead of under the bazel "unit tests", ref: I'll work on this.
done in
This is wonderful to see. Thank you


Question: "context" "encoding/json" "fmt" <del> "strconv" </del> "time" kubeletconfigv1beta1 "k8s.io/kubelet/config/v1beta1"

The test : is failing because it assumes the memory is the same across all nodes. A change in the configuration changed that assumption and the test started to fail. the test to assign the correct amount of memory to each of the nodes to fill them up. create a Windows cluster with 3 nodes. Two have 6gb of allocatable memory, 1 has 14gb of allocatable memory. Run the test above and it will fail because it tries to create 3 pods with 9 gb of memory. The first pod will land on the node with 14gb of memory but the other two pods won't be able to find a node with enough memory (9gb pod 6 gb nodes). fixes this in the configuration /sig windows <details</details<details</details<details</details<details</details<details</details<details</details
/triage accepted /priority important-long-term
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /triage accepted /priority important-long-term 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
Please inform that Am I reasonable here or not. We need to update the in all the cases inside the (, and ) similar to what was done in PR, but now we need to update it in all cases. If you could please confirm that I am reasonable here then I can begin to make these changes in a PR.
sorry I could have been clearer in the issue. The test it's self needs to be updated to handle nodes that do not have consistent memory. The logic in the test is wrong if the nodes don't all have the same memory values: This results in pods that won't fit on some of the nodes and leaves the pods pending. The test should handle this situation by making sure pods filled up memory but can be scheduled across the nodes. Let me know of need more clarification.
So, here we have to fix the logic because the logic is wrong for the case when the nodes don't have the same memory values.

Is the node memory value is equal to which gets assigned to variable in ?My understanding of tackling the issue : So, we need to change because it is the total memory and when it is fixed then the pods present will get appropriate memory limit by . So, if updating the logic for the value of is our focus, such that the it (memory limit) is changed according to the nodes, how can we achieve that ? Am I thinking reasonable here? If my understanding is correct till now then how we will be changing the code for assigning the memory value for a node such that each of the nodes get relevant amount of memory based on there need to work properly.
Yes, I think think the simplest thing to so would be get a list of windows nodes iterate though each one, looking up the allocatable memory for the node, creating a pod to fill that memory and assign it to that node for scheduling via , ensuring the scheduling was successful. Then once the nodes are all full deploy the pod that should go into pending (code should stay the same). pseudo code:
Do we have some examples in the repo where we do something similar for other nodes ? First we need to make function or is it already present ? Confirming : Also Do we need to run the whole code(After Modifying) inside in loop for every windows node and if even one return fails, the test fails.
I need some guidance. Could you please take a look on previous comment.
example of getting the nodes and memory total: no, basically need to replace some of the code in that function with the sudo code in
Why are we not deploying both the pods of in one loop only (if we want memory of pending pods memory same as nodes memory). Also after we deploys both the pods, do we will be running another loop similar to for checking the failure. I am not much sure about my changes, can I make a PR so that I can discuss about my code and make appropriate changes further ?
Sounds good
Does functions , and already exists or we have to make them because I am not able to find, have you used these names as short forms for other functions which do same as their names ?


Question: test/e2e/common/pods.go: "should contain environment variables for services" test/e2e/common/pods.go: "should support remote command execution over websockets" test/e2e/common/pods.go: "should support retrieving logs from the container over websockets" <del> test/e2e/common/projected.go: "should be consumable from pods in volume" test/e2e/common/projected.go: "should be consumable from pods in volume with defaultMode set" test/e2e/common/projected.go: "should be consumable from pods in volume as non-root with defaultMode and fsGroup set" test/e2e/common/projected.go: "should be consumable from pods in volume with mappings" test/e2e/common/projected.go: "should be consumable from pods in volume with mappings and Item Mode set" test/e2e/common/projected.go: "should be consumable in multiple volumes in a pod" test/e2e/common/projected.go: "optional updates should be reflected in volume" test/e2e/common/projected.go: "should be consumable from pods in volume" test/e2e/common/projected.go: "should be consumable from pods in volume with defaultMode set" test/e2e/common/projected.go: "should be consumable from pods in volume as non-root" test/e2e/common/projected.go: "should be consumable from pods in volume with mappings" test/e2e/common/projected.go: "should be consumable from pods in volume with mappings and Item mode set" test/e2e/common/projected.go: "should be consumable from pods in volume with mappings as non-root" test/e2e/common/projected.go: "updates should be reflected in volume" test/e2e/common/projected.go: "optional updates should be reflected in volume" test/e2e/common/projected.go: "should be consumable in multiple volumes in the same pod" test/e2e/common/projected.go: "should provide podname only" test/e2e/common/projected.go: "should set DefaultMode on files" test/e2e/common/projected.go: "should set mode on item file" test/e2e/common/projected.go: "should update labels on modification" test/e2e/common/projected.go: "should update annotations on modification" test/e2e/common/projected.go: "should provide container's cpu limit" test/e2e/common/projected.go: "should provide container's memory limit" test/e2e/common/projected.go: "should provide container's cpu request" test/e2e/common/projected.go: "should provide container's memory request" test/e2e/common/projected.go: "should provide node allocatable (cpu) as default cpu limit if the limit is not set" test/e2e/common/projected.go: "should provide node allocatable (memory) as default memory limit if the limit is not set" test/e2e/common/projected.go: "should project all components that make up the projection API" </del> <ins> test/e2e/common/projected_combined.go: "should project all components that make up the projection API" test/e2e/common/projected_configmap.go: "should be consumable from pods in volume" test/e2e/common/projected_configmap.go: "should be consumable from pods in volume with defaultMode set" test/e2e/common/projected_configmap.go: "should be consumable from pods in volume as non-root" test/e2e/common/projected_configmap.go: "should be consumable from pods in volume with mappings" test/e2e/common/projected_configmap.go: "should be consumable from pods in volume with mappings and Item mode set" test/e2e/common/projected_configmap.go: "should be consumable from pods in volume with mappings as non-root" test/e2e/common/projected_configmap.go: "updates should be reflected in volume" test/e2e/common/projected_configmap.go: "optional updates should be reflected in volume" test/e2e/common/projected_configmap.go: "should be consumable in multiple volumes in the same pod" test/e2e/common/projected_downwardapi.go: "should provide podname only" test/e2e/common/projected_downwardapi.go: "should set DefaultMode on files" test/e2e/common/projected_downwardapi.go: "should set mode on item file" test/e2e/common/projected_downwardapi.go: "should update labels on modification" test/e2e/common/projected_downwardapi.go: "should update annotations on modification" test/e2e/common/projected_downwardapi.go: "should provide container's cpu limit" test/e2e/common/projected_downwardapi.go: "should provide container's memory limit" test/e2e/common/projected_downwardapi.go: "should provide container's cpu request" test/e2e/common/projected_downwardapi.go: "should provide container's memory request" test/e2e/common/projected_downwardapi.go: "should provide node allocatable (cpu) as default cpu limit if the limit is not set" test/e2e/common/projected_downwardapi.go: "should provide node allocatable (memory) as default memory limit if the limit is not set" test/e2e/common/projected_secret.go: "should be consumable from pods in volume" test/e2e/common/projected_secret.go: "should be consumable from pods in volume with defaultMode set" test/e2e/common/projected_secret.go: "should be consumable from pods in volume as non-root with defaultMode and fsGroup set" test/e2e/common/projected_secret.go: "should be consumable from pods in volume with mappings" test/e2e/common/projected_secret.go: "should be consumable from pods in volume with mappings and Item Mode set" test/e2e/common/projected_secret.go: "should be consumable in multiple volumes in a pod" test/e2e/common/projected_secret.go: "optional updates should be reflected in volume" </ins> test/e2e/common/runtime.go: "should run with the expected status" test/e2e/common/secrets.go: "should be consumable from pods in env vars" test/e2e/common/secrets.go: "should be consumable via the environment"

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: Running the non- conformance tests with produces unpredictable results, sometimes tests show up again with a on the end. This is due to the following tests having multiple tests with identical names: - - What you expected to happen: Tests should have unique names. How to reproduce it (as minimally and precisely as possible): run the conformance tests with a skip on and Anything else we need to know?: example here: https://k8s- /sig node /sig testing cc
er this is probably better /sig storage cc
/assign /assign
/area conformance
/milestone v1.13


Question: _, ok := original[k] if !ok { <del> // If it's not in the original document, just take the patch value. original[k] = patchV </del> <ins> if !isDeleteList { // If it's not in the original document, just take the patch value. original[k] = patchV } </ins> continue } originalType := reflect.TypeOf(original[k]) patchType := reflect.TypeOf(patchV) if originalType != patchType { <del> original[k] = patchV </del> <ins> if !isDeleteList { original[k] = patchV } </ins> continue } // If they're both maps or lists, recurse into the value.

<!-- 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 --Patching an object without finalizers using results in the given finalizers being . is idempotent in case there are other list elements than the removed one. I expected to also be idempotent in case the list is already empty. an arbitrary object: an arbitrary finalizer to the object via strategic merge patch: the finalizer again by using the directive: the same patch again: Kubernetes version (use ):
/sig api-machinery
Strange. It looks like attempting to delete a nonexistent primitive actually adds it. Below is a slightly different take on your example, client-side only and without any finalizers to start with. It tries to delete which is nonexistent and it ends up being : I also tested with some previous versions of kubectl (back to 1.10.2 even) and saw the same thing, so it appears to have always been this way.
I just checked: the same thing happens when directly talking to the API server (so it's not a kubectl-only bug):
that's good to know. But I guess, this is not expected behavior, right?
I don't think it is expected behavior. It is surprising to me at least. I am curious to know what someone who has more experience with Strategic Merge Patch has to say though.
looks like this was reported in as well
/cc /triage accepted
The best workaround for now is probably to json merge patch the whole list with the resourceVersion set. I don't know much about the code nor the bug, but it really looks like a bug rather than a feature, so we should be able to fix it without causing too much surprise to other users. We generally have limited interest fixing smp but that seems worthy. Is somone interested in looking at it?
/assign