Question: } func TestURLTemplate(t *testing.T) { <del> uri, _ := url.Parse("http://localhost") r := NewRequest(nil, "POST", uri, "", ContentConfig{GroupVersion: &schema.GroupVersion{Group: "test"}}, Serializers{}, nil, nil, 0) r.Prefix("pre1").Resource("r1").Namespace("ns").Name("nm").Param("p0", "v0") full := r.URL() if full.String() != "http://localhost/pre1/namespaces/ns/r1/nm?p0=v0" { t.Errorf("unexpected initial URL: %s", full) } actualURL := r.finalURLTemplate() actual := actualURL.String() expected := "http://localhost/pre1/namespaces/%7Bnamespace%7D/r1/%7Bname%7D?p0=%7Bvalue%7D" if actual != expected { t.Errorf("unexpected URL template: %s %s", actual, expected) } if r.URL().String() != full.String() { t.Errorf("creating URL template changed request: %s -> %s", full.String(), r.URL().String()) </del> <ins> uri, _ := url.Parse("http://localhost/some/base/url/path") testCases := []struct { Request          *Request ExpectedFullURL  string ExpectedFinalURL string }{ { // non dynamic client Request: NewRequest(nil, "POST", uri, "", ContentConfig{GroupVersion: &schema.GroupVersion{Group: "test"}}, Serializers{}, nil, nil, 0). Prefix("api", "v1").Resource("r1").Namespace("ns").Name("nm").Param("p0", "v0"), ExpectedFullURL:  "http://localhost/some/base/url/path/api/v1/namespaces/ns/r1/nm?p0=v0", ExpectedFinalURL: "http://localhost/some/base/url/path/api/v1/namespaces/%7Bnamespace%7D/r1/%7Bname%7D?p0=%7Bvalue%7D", }, { // non dynamic client with wrong api group Request: NewRequest(nil, "POST", uri, "", ContentConfig{GroupVersion: &schema.GroupVersion{Group: "test"}}, Serializers{}, nil, nil, 0). Prefix("pre1", "v1").Resource("r1").Namespace("ns").Name("nm").Param("p0", "v0"), ExpectedFullURL:  "http://localhost/some/base/url/path/pre1/v1/namespaces/ns/r1/nm?p0=v0", ExpectedFinalURL: "http://localhost/%7Bprefix%7D", }, { // dynamic client with core group + namespace + resourceResource (with name) // /api/$RESOURCEVERSION/namespaces/$NAMESPACE/$RESOURCE/%NAME Request: NewRequest(nil, "DELETE", uri, "", ContentConfig{GroupVersion: &schema.GroupVersion{Group: "test"}}, Serializers{}, nil, nil, 0). Prefix("/api/v1/namespaces/ns/r1/name1"), ExpectedFullURL:  "http://localhost/some/base/url/path/api/v1/namespaces/ns/r1/name1", ExpectedFinalURL: "http://localhost/some/base/url/path/api/v1/namespaces/%7Bnamespace%7D/r1/%7Bname%7D", }, { // dynamic client with named group + namespace + resourceResource (with name) // /apis/$NAMEDGROUPNAME/$RESOURCEVERSION/namespaces/$NAMESPACE/$RESOURCE/%NAME Request: NewRequest(nil, "DELETE", uri, "", ContentConfig{GroupVersion: &schema.GroupVersion{Group: "test"}}, Serializers{}, nil, nil, 0). Prefix("/apis/g1/v1/namespaces/ns/r1/name1"), ExpectedFullURL:  "http://localhost/some/base/url/path/apis/g1/v1/namespaces/ns/r1/name1", ExpectedFinalURL: "http://localhost/some/base/url/path/apis/g1/v1/namespaces/%7Bnamespace%7D/r1/%7Bname%7D", }, { // dynamic client with core group + namespace + resourceResource (with NO name) // /api/$RESOURCEVERSION/namespaces/$NAMESPACE/$RESOURCE Request: NewRequest(nil, "DELETE", uri, "", ContentConfig{GroupVersion: &schema.GroupVersion{Group: "test"}}, Serializers{}, nil, nil, 0). Prefix("/api/v1/namespaces/ns/r1"), ExpectedFullURL:  "http://localhost/some/base/url/path/api/v1/namespaces/ns/r1", ExpectedFinalURL: "http://localhost/some/base/url/path/api/v1/namespaces/%7Bnamespace%7D/r1", }, { // dynamic client with named group + namespace + resourceResource (with NO name) // /apis/$NAMEDGROUPNAME/$RESOURCEVERSION/namespaces/$NAMESPACE/$RESOURCE Request: NewRequest(nil, "DELETE", uri, "", ContentConfig{GroupVersion: &schema.GroupVersion{Group: "test"}}, Serializers{}, nil, nil, 0). Prefix("/apis/g1/v1/namespaces/ns/r1"), ExpectedFullURL:  "http://localhost/some/base/url/path/apis/g1/v1/namespaces/ns/r1", ExpectedFinalURL: "http://localhost/some/base/url/path/apis/g1/v1/namespaces/%7Bnamespace%7D/r1", }, { // dynamic client with core group + resourceResource (with name) // /api/$RESOURCEVERSION/$RESOURCE/%NAME Request: NewRequest(nil, "DELETE", uri, "", ContentConfig{GroupVersion: &schema.GroupVersion{Group: "test"}}, Serializers{}, nil, nil, 0). Prefix("/api/v1/r1/name1"), ExpectedFullURL:  "http://localhost/some/base/url/path/api/v1/r1/name1", ExpectedFinalURL: "http://localhost/some/base/url/path/api/v1/r1/%7Bname%7D", }, { // dynamic client with named group + resourceResource (with name) // /apis/$NAMEDGROUPNAME/$RESOURCEVERSION/$RESOURCE/%NAME Request: NewRequest(nil, "DELETE", uri, "", ContentConfig{GroupVersion: &schema.GroupVersion{Group: "test"}}, Serializers{}, nil, nil, 0). Prefix("/apis/g1/v1/r1/name1"), ExpectedFullURL:  "http://localhost/some/base/url/path/apis/g1/v1/r1/name1", ExpectedFinalURL: "http://localhost/some/base/url/path/apis/g1/v1/r1/%7Bname%7D", }, { // dynamic client with named group + namespace + resourceResource (with name) + subresource // /apis/$NAMEDGROUPNAME/$RESOURCEVERSION/namespaces/$NAMESPACE/$RESOURCE/%NAME/$SUBRESOURCE Request: NewRequest(nil, "DELETE", uri, "", ContentConfig{GroupVersion: &schema.GroupVersion{Group: "test"}}, Serializers{}, nil, nil, 0). Prefix("/apis/namespaces/namespaces/namespaces/namespaces/namespaces/namespaces/finalize"), ExpectedFullURL:  "http://localhost/some/base/url/path/apis/namespaces/namespaces/namespaces/namespaces/namespaces/namespaces/finalize", ExpectedFinalURL: "http://localhost/some/base/url/path/apis/namespaces/namespaces/namespaces/%7Bnamespace%7D/namespaces/%7Bname%7D/finalize", }, { // dynamic client with named group + namespace + resourceResource (with name) // /apis/$NAMEDGROUPNAME/$RESOURCEVERSION/namespaces/$NAMESPACE/$RESOURCE/%NAME Request: NewRequest(nil, "DELETE", uri, "", ContentConfig{GroupVersion: &schema.GroupVersion{Group: "test"}}, Serializers{}, nil, nil, 0). Prefix("/apis/namespaces/namespaces/namespaces/namespaces/namespaces/namespaces"), ExpectedFullURL:  "http://localhost/some/base/url/path/apis/namespaces/namespaces/namespaces/namespaces/namespaces/namespaces", ExpectedFinalURL: "http://localhost/some/base/url/path/apis/namespaces/namespaces/namespaces/%7Bnamespace%7D/namespaces/%7Bname%7D", }, { // dynamic client with named group + namespace + resourceResource (with NO name) + subresource // /apis/$NAMEDGROUPNAME/$RESOURCEVERSION/namespaces/$NAMESPACE/$RESOURCE/%SUBRESOURCE Request: NewRequest(nil, "DELETE", uri, "", ContentConfig{GroupVersion: &schema.GroupVersion{Group: "test"}}, Serializers{}, nil, nil, 0). Prefix("/apis/namespaces/namespaces/namespaces/namespaces/namespaces/finalize"), ExpectedFullURL:  "http://localhost/some/base/url/path/apis/namespaces/namespaces/namespaces/namespaces/namespaces/finalize", ExpectedFinalURL: "http://localhost/some/base/url/path/apis/namespaces/namespaces/namespaces/%7Bnamespace%7D/namespaces/finalize", }, { // dynamic client with named group + namespace + resourceResource (with NO name) + subresource // /apis/$NAMEDGROUPNAME/$RESOURCEVERSION/namespaces/$NAMESPACE/$RESOURCE/%SUBRESOURCE Request: NewRequest(nil, "DELETE", uri, "", ContentConfig{GroupVersion: &schema.GroupVersion{Group: "test"}}, Serializers{}, nil, nil, 0). Prefix("/apis/namespaces/namespaces/namespaces/namespaces/namespaces/status"), ExpectedFullURL:  "http://localhost/some/base/url/path/apis/namespaces/namespaces/namespaces/namespaces/namespaces/status", ExpectedFinalURL: "http://localhost/some/base/url/path/apis/namespaces/namespaces/namespaces/%7Bnamespace%7D/namespaces/status", }, { // dynamic client with named group + namespace + resourceResource (with no name) // /apis/$NAMEDGROUPNAME/$RESOURCEVERSION/namespaces/$NAMESPACE/$RESOURCE/%NAME Request: NewRequest(nil, "DELETE", uri, "", ContentConfig{GroupVersion: &schema.GroupVersion{Group: "test"}}, Serializers{}, nil, nil, 0). Prefix("/apis/namespaces/namespaces/namespaces/namespaces/namespaces"), ExpectedFullURL:  "http://localhost/some/base/url/path/apis/namespaces/namespaces/namespaces/namespaces/namespaces", ExpectedFinalURL: "http://localhost/some/base/url/path/apis/namespaces/namespaces/namespaces/%7Bnamespace%7D/namespaces", }, { // dynamic client with named group + resourceResource (with name) + subresource // /apis/$NAMEDGROUPNAME/$RESOURCEVERSION/namespaces/$NAMESPACE/$RESOURCE/%NAME Request: NewRequest(nil, "DELETE", uri, "", ContentConfig{GroupVersion: &schema.GroupVersion{Group: "test"}}, Serializers{}, nil, nil, 0). Prefix("/apis/namespaces/namespaces/namespaces/namespaces/finalize"), ExpectedFullURL:  "http://localhost/some/base/url/path/apis/namespaces/namespaces/namespaces/namespaces/finalize", ExpectedFinalURL: "http://localhost/some/base/url/path/apis/namespaces/namespaces/namespaces/%7Bname%7D/finalize", }, { // dynamic client with named group + resourceResource (with name) + subresource // /apis/$NAMEDGROUPNAME/$RESOURCEVERSION/namespaces/$NAMESPACE/$RESOURCE/%NAME Request: NewRequest(nil, "DELETE", uri, "", ContentConfig{GroupVersion: &schema.GroupVersion{Group: "test"}}, Serializers{}, nil, nil, 0). Prefix("/apis/namespaces/namespaces/namespaces/namespaces/status"), ExpectedFullURL:  "http://localhost/some/base/url/path/apis/namespaces/namespaces/namespaces/namespaces/status", ExpectedFinalURL: "http://localhost/some/base/url/path/apis/namespaces/namespaces/namespaces/%7Bname%7D/status", }, { // dynamic client with named group + resourceResource (with name) // /apis/$NAMEDGROUPNAME/$RESOURCEVERSION/$RESOURCE/%NAME Request: NewRequest(nil, "DELETE", uri, "", ContentConfig{GroupVersion: &schema.GroupVersion{Group: "test"}}, Serializers{}, nil, nil, 0). Prefix("/apis/namespaces/namespaces/namespaces/namespaces"), ExpectedFullURL:  "http://localhost/some/base/url/path/apis/namespaces/namespaces/namespaces/namespaces", ExpectedFinalURL: "http://localhost/some/base/url/path/apis/namespaces/namespaces/namespaces/%7Bname%7D", }, { // dynamic client with named group + resourceResource (with no name) // /apis/$NAMEDGROUPNAME/$RESOURCEVERSION/$RESOURCE/%NAME Request: NewRequest(nil, "DELETE", uri, "", ContentConfig{GroupVersion: &schema.GroupVersion{Group: "test"}}, Serializers{}, nil, nil, 0). Prefix("/apis/namespaces/namespaces/namespaces"), ExpectedFullURL:  "http://localhost/some/base/url/path/apis/namespaces/namespaces/namespaces", ExpectedFinalURL: "http://localhost/some/base/url/path/apis/namespaces/namespaces/namespaces", }, { // dynamic client with wrong api group + namespace + resourceResource (with name) + subresource // /apis/$NAMEDGROUPNAME/$RESOURCEVERSION/namespaces/$NAMESPACE/$RESOURCE/%NAME/$SUBRESOURCE Request: NewRequest(nil, "DELETE", uri, "", ContentConfig{GroupVersion: &schema.GroupVersion{Group: "test"}}, Serializers{}, nil, nil, 0). Prefix("/pre1/namespaces/namespaces/namespaces/namespaces/namespaces/namespaces/finalize"), ExpectedFullURL:  "http://localhost/some/base/url/path/pre1/namespaces/namespaces/namespaces/namespaces/namespaces/namespaces/finalize", ExpectedFinalURL: "http://localhost/%7Bprefix%7D", }, } for i, testCase := range testCases { r := testCase.Request full := r.URL() if full.String() != testCase.ExpectedFullURL { t.Errorf("%d: unexpected initial URL: %s %s", i, full, testCase.ExpectedFullURL) } actualURL := r.finalURLTemplate() actual := actualURL.String() if actual != testCase.ExpectedFinalURL { t.Errorf("%d: unexpected URL template: %s %s", i, actual, testCase.ExpectedFinalURL) } if r.URL().String() != full.String() { t.Errorf("%d, creating URL template changed request: %s -> %s", i, full.String(), r.URL().String()) } </ins> } }

<!-- 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: In Kubernetes 1.11.x, the controller-manager metrics are providing histogram records for every api endpoint ever called during namespace cleanup. For every namespace that is deleted since a controller has been the leader, 1000+ new lines of metrics are created / served indefinitely. When creating/deleting namespaces at a rate of 100/hour, that's 100,000+ new metrics lines being served for every request of controller-manager/metrics. spun up a 1.10 environment, and says it looks like the namespace names were replaced with {namespace}: In 1.11 this has changed (short clip of 1 histogram): What you expected to happen: Don't generate so many metrics. How to reproduce it (as minimally and precisely as possible): To replicate in 1.11.x, simply create and then delete a namespace and query the metrics endpoint of your controller-manager. Anything else we need to know?: Repro steps and bug reported by /sig api-machinery Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
did some more debugging and believes that the root cause is He says that PR switched to the new dynamic client so when a request is made, this function is called: He explains that function in the old client checks if is set, the following is an example call: In the new client, the following is an example call: In this new dynamic client, the delete operation calls: whereas in the old client, it ran: The , he says, is the critical component, which sets the request client namespace field without namespace being set, when is called then the metrics are populated without renaming the Namespace to which causes tons of unique metrics to be generated and cause metrics data grow very quickly. This seems to be a pretty critical bug. Will mark it for v1.12. Please triage. /milestone v1.12 CC
- friendly reminder that Code Freeze is next week; if this is critical enough for 1.12 it needs to be triaged accordingly.

This isn't a regression (1.11 had it), but it's a big enough bug that I'd take a fix for it in 1.12. I think that a fix should take the form of fixing the to handle cases where the abspath is set. That would fix it for all future callers instead of just a one off for this client. That method is only called for metrics and our api paths follow a very fixed format. I expect that it should be fairly easy to recognize and you only have to do the analysis if you have no hits for the namespace being set.
please apply a priority/critical-urgent label to keep track for 1.12
/assign
GitHub didn't allow me to assign the following users: wenjiaswe. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I applied the label. We will have to un-apply it if a targeted fix doesn't show up very soon :)
If no one has started working on it, I am on this now. I will try fix it ASAP.
please do!
/assign
GitHub didn't allow me to assign the following users: wenjiaswe. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
please update on a daily basis, as we're in Code Freeze. :)
I have reproduced the problem and also wrote a unit test case for confirmation. Basically with the current dynamic client implementation, the actually string of namespace is in url here: , so when finalURLTemplate function checks (), it returns false and would not replace namespace with "{namespace}". I am working on fixing it by replacing the url segment after /namespaces/ by . I should be able to submit the PR tomorrow if not today.


Question: func (proxier *Proxier) getLegacyBindAddr(activeBindAddrs map[string]bool, currentBindAddrs []string) map[string]bool { legacyAddrs := make(map[string]bool) <ins> isIpv6 := utilnet.IsIPv6(proxier.nodeIP) </ins> for _, addr := range currentBindAddrs { <ins> addrIsIpv6 := utilnet.IsIPv6(net.ParseIP(addr)) if addrIsIpv6 && !isIpv6 || !addrIsIpv6 && isIpv6 { continue } </ins> if _, ok := activeBindAddrs[addr]; !ok { legacyAddrs[addr] = true }

<!-- 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?: /kind bug /sig network /area ipvs /area ipv6 What happened: with IPVS mode creates a interface for binding service IPs. kube-proxy periodically addresses it doesn't know about from the interface. It tries to unbind the IPv6 address over and over. The error is a little vague, but see below. The IP parsing or address deletion code may be a suspect. What you expected to happen: Either ignore the IPv6 address on the interface (its not hurting anything) or remove it correctly. How to reproduce it (as minimally and precisely as possible): Its perfectly natural for a new interface to have an inet6 address by default. If for some reason your interface doesn't have a similar address, you can add one to repro. Anything else we need to know?: Environment: Kubernetes version (use ): v1.12.1 Cloud provider or hardware configuration: AWS, GCP, DigitalOcean, bare-metal, Azure OS (e.g. from /etc/os-release): Container Linux 1855.4.0 Kernel (e.g. ): 4.14.67-coreos Install tools: Typhoon
The error message from is a little vague. Hop on a node to help out with its deletion. This gives a clue about where goes wrong. With IPv4 addresses, leaving off the is permitted (though with a scary warning). Having the wrong prefix size produces the same error. With more verbose logging, we see the mask was stripped before calling 's AddrDel, so the bug lies in kube-proxy's construction of . The mask is dropped . should be (, net.IPNet). However, it looks like much of kube-proxy ipvs deals in string IPs (e.g. 1.2.3.4, 1002:ab8::2:1) so propagating a or adding a mask could be a large change. One might also point to called as the source - it assumes a mask for IPv4 and a mask for IPv6.

Neither is neccessarily right for arbitrary addresses that might end up bound on a interface, but for IPv4 happens to work for Kubernetes IPv4 service IPs. for the IPv6 address does not. We could construct a netlink.IPNet without the helper, but by the time we reach , kube-proxy has already thrown away the mask information.
Any relation with this you think? Doesn't seem so since this is in and the other is ipvs targets...
Hm, I think adapting the sync'er for IPv6 might be a different fix. I was working on a fix for the IPv6 cleanup on the interface, lemme see if I can get that to a state it can be posted.
I can only reproduce this fault if I do; This will automatically assign a link-local generated address to the interface and the problem occurs. But the should not be up. By default if I start v1.12.0 it is down. Is some program, e.g network-manager, brings the interface up? Anyway I think it is possible to suspress auto-generated link-local ipv6 addresses. I will try to find the setting.
After creation; should fix this problem. I will try to get time to do a PR.


Question: By("verifying pod deletion was observed") deleted := false <del> timeout := false </del> var lastPod *v1.Pod <del> timer := time.After(30 * time.Second) for !deleted && !timeout { </del> <ins> timer := time.After(2 * time.Minute) for !deleted { </ins> select { case event, _ := <-w.ResultChan(): <del> if event.Type == watch.Deleted { </del> <ins> switch event.Type { case watch.Deleted: </ins> lastPod = event.Object.(*v1.Pod) deleted = true <ins> case watch.Error: framework.Logf("received a watch error: %v", event.Object) Fail("watch closed with error") </ins> } case <-timer: <del> timeout = true </del> <ins> Fail("timed out waiting for pod deletion") </ins> } } if !deleted {

https://k8s-
is looking into this.
Seems like a lot of flakes are caused by the watch issue: Maybe we should switch to polling in the test.
I'm taking this
Opened a fix that will at minimum give us more info, but also increases timeout
This is the last failure before my changed merged: https://k8s- Still waiting for a post.
Do you think is enough to address this issue? Or there are some other pending issues in watching code? Can we close this one?
We can close this, the issue is almost certainly the one fixed.


Question: "testdevice": { {ID: "Dev1"}, {ID: "Dev2"}, <ins> {ID: "Dev3", Topology: &pluginapi.TopologyInfo{Nodes: []*pluginapi.NUMANode{}}}, {ID: "Dev4", Topology: &pluginapi.TopologyInfo{Nodes: nil}}, </ins> }, }, expectedHints: map[string][]topologymanager.TopologyHint{

A node with: fails a pod that uses device plugin resources (empty but non-nil ) : Our device plugin sends the following registration: So we send an empty which is interpreted as "no possible NUMA affinities": How is this different from value? I can workaround the problem by sending but it's not how this is supposed to work. Can the two if's combined or should we updated the documentation? My environment: a single-node k8s cluster w/ device plugin that does The node needs to run two kinds of pods: those that need/use topology single-numa-node and pods that just use a device plugin resources that does not provide topologyhints. <details</details<detailsN/A (kubeadm single node cluster) </details<details</details<detailskubeadm </details<detailscontainerd </details<detailsintel SGX device plugin v0.24 </details
/cc
It's possible that better documentation is needed, but we could also probably do more to handle this better in the device plugin. The implementation you pointed out above relies on depicting "don't care" and depicting "I tried but couldn't generate any hints that provide alignment". One could argue though that should have generated a set of hints and not a . I would need to look at the code again to know for sure if this makes sense or not though.
This interpretation makes sense but Right, if the hint provider fails to provide hints, I guess the pod should not be blamed (by not making it to run) for that. /sig node
/triage accepted /priority backlog
/cc
I can at least help with the documentation part if we decide that it alone needs changing.
I'm reviewing this area for other reasons, we should indeed calrify the hint API expectations. Up until now my rule of thumb was pretty much "what cpumanager does" which has room for improvement.
This could be isolated to only by returning when : when running is pointless, IMO
Submitted a
The corresponding documentation update:


Question: <ins> // +build !providerless /* Copyright 2020 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ // The external controller manager is responsible for running controller loops that // are cloud provider dependent. It uses the API to listen to new events on resources. package main import ( // NOTE: Importing all in-tree cloud-providers is not required when // implementing an out-of-tree cloud-provider. _ "k8s.io/legacy-cloud-providers/aws" _ "k8s.io/legacy-cloud-providers/azure" _ "k8s.io/legacy-cloud-providers/gce" _ "k8s.io/legacy-cloud-providers/openstack" _ "k8s.io/legacy-cloud-providers/vsphere" ) </ins>

make verify WHAT=typecheck-providerless outputs /cc /milestone v1.19
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
see example successful run:
For reference -
fix in
screaming


Question: glog.Errorf("iscsi: failed to attach disk:Error: %s (%v)", string(out), err) return err } <del> exist = waitForPathToExist(devicePath, 10, b.iface) </del> <ins> exist = waitForPathToExist(devicePath, 10, iscsiTransport) </ins> if !exist { return errors.New("Could not attach disk: Timeout after 10s") }

open-iscsi software initiators are currently broken for non- interfaces due to the fact that the devicePath (in ) is assumed to use the prefixing scheme for all interfaces not named . This causes waitForPathToExist to timeout after 10 seconds since the device path that it is waiting for is not the - prefixed path that is created, resulting in host logging such as: or K8S event logs such as: open-iscsi support for hardware transports was in the following commit: In this commit, software iSCSI support was assumed to be done through only the use of the default interface. According to the documentation at (Section 5.1.1) both software and offload/hardware interfaces are intended to be configured using named interface specifications and is only a backwards-compatibility vehicle. Configuration of cannot be done via the use of as this approach is specifically forbidden in the documentation: Leaving this here to help others associate various failure modes with this issue and possible resolution: In my case I am just learning and this is my first iSCSI deployment. My initial error was that I was receiving an message at discovery-time even though I had used to define a name. This approach failed because I didn't realize that iscsid needed to be bounced before it would pick up changes to that file. I had defined a custom specification and was using that to accomplish the task of setting my initiator name. I was able to unwind this mess and return to the use of once I read the code and understood what it was attempting to do.
i'm marking this as a feature request against the iscsi volume driver. RFE: support iscsi interfaces named something besides 'default'.
In theory the fix should be easy, just move the path check from iface name to transport_name. I will take a look asap, unfortunately I am travelling till monday
Sorry about the previous comment, I was logged in to the wrong account. In theory the fix should be easy, just move the path check from iface name to transport_name. I will take a look asap, unfortunately I am travelling till monday. can you share your iface file ? It will help me validate
I no longer have the file precisely as it was. However, I did have some version of what I had used committed into my VCS. While not 100% sure this is what I was using while encountering the failure it does looks to be about what I'd expect:


Question: func (j *TestJig) checkClusterIPServiceReachability(svc *v1.Service, pod *v1.Pod) error { clusterIP := svc.Spec.ClusterIP servicePorts := svc.Spec.Ports <ins> externalIPs := svc.Spec.ExternalIPs </ins> err := j.waitForAvailableEndpoint(ServiceEndpointsTimeout) if err != nil {

What would you like to be : e2e test for service ExternalIPs Why is this needed: There is no test covering Service ExternalIPs Since we can not assume that the e2e binary will have connectivity against the nodes and that we can add routes to the environment, we are going to test it from a pod. I've verified that this works locally with the following commands: The test should leverage current framework, maybe something as A good example is here, maybe adding a ?
/sig network /help wanted /triage accepted
/help wanted /good-first-issue
/assign
I'd like to pick this up!
Ok,I'm not started :) /unassign /assign
There are two different externalIP codepaths, one for the case where the claimed external IP exists as an IP on the default interface, and one for where it does not. I suppose we could just temporarily add an IP to the default interface...
good idea Dan Please remember, it has to work for IPv6 and for IPv4 ... anyway, we can address these things during the review
This has been partially implemented with . Covering the code path for when an IP is does not exist on a node. I'll assign this back to you so you can split this issue or close it in favor of another issue. Thanks! /unassign /assign
what is the different codepath for ExternalIPs that already exist on the host? ~My reading is that the only difference is that it opens a local socket on that port, can you expand on this?~ Found it
so, it seems that this work in some environments because they are not using the bridge plugin why is not allowed that pods can reach ExternalIPs?
Wow, this is ancient and needs some fixing. This is not about preventing pod traffic from reaching those IPs. I had to really stare at it, and I am not 100% in my interpretation. First, we recognize such traffic from "off machine" (!physdev-is-in && !src=LOCAL, which we should probably switch to localDetector) and steer it to the Service. Second, we recognize ANY such traffic that is destined for a LOCAL address and shortcut that to the Service, Implicitly, traffic destined for this IP where the IP is not local goes to the system's default routing logic.

The reliance on the bridge plugin is awful and archaic and I will buy a beverage of your choice for whomever gets rid of that. I think localDetector can cover this, but not 100% sure
but the ExternalIP belongs to a service and we(kube-proxy) "knows" where to send it (to the service) , that is the part I'm not sure to understand, because whatever the user is doing with that ExternalIP it has to send it back to the cluster to reach the service. However, there is always context that is important and maybe I'm missing something. Assuming we want to handle ALL the ExternalIP traffic with kube-proxy, the logic will be much simpler: traffic to an externalIP will be ALWAYS sent to the Service (DNAT) if traffic is NOT LOCAL, we also SNAT
/remove-good-first-issue /remove-help-wanted


Question: w.Write(LEVEL_0, "Selector:t%sn", selector) printLabelsMultiline(w, "Labels", ps.Labels) printAnnotationsMultiline(w, "Annotations", ps.Annotations) <del> w.Write(LEVEL_0, "Replicas:t%d desired | %d totaln", ps.Spec.Replicas, ps.Status.Replicas) </del> <ins> w.Write(LEVEL_0, "Replicas:t%d desired | %d totaln", *ps.Spec.Replicas, ps.Status.Replicas) </ins> w.Write(LEVEL_0, "Update Strategy:t%sn", ps.Spec.UpdateStrategy.Type) if ps.Spec.UpdateStrategy.RollingUpdate != nil { ru := ps.Spec.UpdateStrategy.RollingUpdate

<!-- 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!--/kind bug /sig cli /area kubectl What happened: What you expected to happen: Should only be one desired replica How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Right here Environment: Kubernetes version (use ):


Question: }, fakeCloud: &fake_cloud.FakeCloud{ Machines: []string{"node0"}, <ins> ExtID: map[string]string{ "node0": "ext-node0", "node1": "ext-node1", }, </ins> }, matchRE:              ".*", expectedRequestCount: 2, // List + Delete <del> expectedCreated:      []string{}, </del> <ins> expectedNameCreated:  []string{}, expectedExtIDCreated: []string{}, </ins> expectedDeleted:      []string{"node1"}, }, {

I see the following in the kube-controller-manager log: - This is happening to me on HEAD and is the reason why pod status is always showing unknown even when they are scheduled and running.
This is with the vagrant cloud provider. It looks like the delta between the new and old minion is the Node.Spec.ExternalID is being set on the incoming minion but is not set in the originally created minion.
I am not sure how this is not affecting other cloud providers. It looks to me that NodeController populated the node ExternalID here: It looks like the Kubelet provided value is missing the ExternalID
Actually, I am now confused on what the NodeController may or may not be doing here that is causing the status to not get updated.
It looks like the client is passing an ExternalID on the incoming request, but the original value that is in etcd does not have an ExternalID set. Not sure what changed that would have caused this issue to appear.
I think this causes problems: The memory is re-used in a for-loop by Go so referring to a pointer value in a map here will cause problems I think.
Ok, the referenced line is the problem. Sending a PR.
Well, I go back on that now. A simple way to reproduce this is to delete all the minions in your cluster, and verify the node controller is able to add them back. For me, this is causing the node controller to add them back in an unknown status, and then all updates to the node fail. The update fails because the node controller is not setting an ExternalID on the original object.
I am looking into this now. cc/ too
Related issue opened while debugging this:
Debugged through here: I can via manual fmt see that the object has an ExternalID set prior to the call Create. When I look at etcd, I end up with this persisted: Note: it is missing an ExternalID somehow ;-)
Ok, I think I see the issue Nodes returned from here: Do not have an ExternalID Which can make Nodes created from here: End up without an External ID. Having two different nodeClient.Create() paths in this code is confusing. Also we are doing bad things in maps holding pointers to memory allocated in for-loop. We need to fix that ;-)
Yeah, this is bug we should fix. Thanks for looking into this.

If you already have a potential fix, please feel free to grab the issue from me.
I think I have a PR that should fix. Testing that now. Will cc you on the PR.
Thanks for fixing - it did end up affecting AWS as well (AWS isn't in a fully working state just yet, particularly with node discovery).


Question: }, }), output: `Name:             bar <ins> Labels:           <none> </ins> Namespace:        foo Address: Default backend:  default-backend:80 (<error: endpoints "default-backend" not found>)

When command 'kubectl describe ing' Name: test-ing Namespace: practice Address: 10.10.01.10 Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found) TLS: test terminates Rules: Host Path Backends ---- ---- -------- / test-svc:80 (<none) Annotations: nginx Events: <noneResult has no information about labels. But Pod, Deployment, Service resources has label information like below. Name: test-room-test-mjsbz Namespace: test Priority: 0 Node: aks-test-test-test/22.22.222. Start Time: Fri, 09 Jul 2021 05:45:26 +0000 Labels: app=test pod-template-hash=test role=mediatest Why ingress has no information about labels? Actually when delete ingresss with labels is working correctly. Kubernetes version (use ): 1.18.14 Cloud provider or hardware configuration: AKS (Azure) OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig
/sig
/sig cli
/assign
/assign
/triage accepted /remove-kind bug /kind feature


Question: expectReason: `forbidden sysctls`, expectDetail: `net.ipv4.tcp_keepalive_time`, }, <ins> { name: "new supported sysctls not supported: net.ipv4.tcp_fin_timeout", pod: &corev1.Pod{Spec: corev1.PodSpec{ SecurityContext: &corev1.PodSecurityContext{ Sysctls: []corev1.Sysctl{{Name: "net.ipv4.tcp_fin_timeout", Value: "60"}}, }, }}, allowed:      false, expectReason: `forbidden sysctls`, expectDetail: `net.ipv4.tcp_fin_timeout`, }, { name: "new supported sysctls not supported: net.ipv4.tcp_keepalive_intvl", pod: &corev1.Pod{Spec: corev1.PodSpec{ SecurityContext: &corev1.PodSecurityContext{ Sysctls: []corev1.Sysctl{{Name: "net.ipv4.tcp_keepalive_intvl", Value: "75"}}, }, }}, allowed:      false, expectReason: `forbidden sysctls`, expectDetail: `net.ipv4.tcp_keepalive_intvl`, }, { name: "new supported sysctls not supported: net.ipv4.tcp_keepalive_probes", pod: &corev1.Pod{Spec: corev1.PodSpec{ SecurityContext: &corev1.PodSecurityContext{ Sysctls: []corev1.Sysctl{{Name: "net.ipv4.tcp_keepalive_probes", Value: "9"}}, }, }}, allowed:      false, expectReason: `forbidden sysctls`, expectDetail: `net.ipv4.tcp_keepalive_probes`, }, </ins> } for _, tc := range tests {

Add the following to be safe sysctls: net.ipv4.tcpfintimeout net.ipv4.tcpkeepaliveintvl net.ipv4.tcpkeepaliveprobes These are related settings to net.ipv4.tcpkeepalivetime that was enabled in These are related ipv4 TCP settings for tuning network connections between a client and a pod.
/sig network
May you help provide some tests to ensure that setting this sysctl can't affect any other pods or the node.
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : May you help provide some tests to ensure that setting this sysctl can't affect any other pods or the node. /sig nodes 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 node
I adjusted it with the plugin.
Would this change apply at the node level or the pod level? I assumed it would be at the pod level, and should not affect any other pods--however Kubernetes does not natively have any limits on network connections that I am aware of--but only the pod with the changed net settings would be affected.
To verify that a sysctl has an effect on other pods, we need to verify that it's a namespace sysctl.
Here's a simple test Use net.ipv4.tcpfintimeout sysctl to create a container check if it set on the host =It is the default value on host run another container attach to the network namespace of the one where the sysctl is set =results in sysctl being set Verify in another container under a different network namespace that it is not set =It is the default value According to the test results, net.ipv4.tcpfintimeout is a namespaced sysctl
I likewise verified and , which are also namespaced sysctl, and I believe we can add them to the safe sysctl /assign
Probably need to wait for to finish before start working on it
/triage accepted


Question: NS="${8:-$NS}"          # namespace echo "Running w/ args: kubectl $kubectl version $VERSION sec $_SECONDS fe $FE lg $LG slave $SLAVE test $TEST NAMESPACE $NS" <ins> function create_ns { case "$NS" in "default" ) ;; "kube-system" ) ;; * ) cat << EOF > ns.json { "apiVersion": "v1", "kind": "Namespace", "metadata": { "name": "$NS" } } EOF $kubectl create -f ns.json esac } </ins> function create { cat << EOF > fe-rc.json

During the review of , it's better to also update and to use non-default namespace. cc .
cc
/ , I can continue to work on this one :).
/ , can you help to assign this issue to me? So I can trace the tasks in my hand :).
I'd be happy to assign you once you accept the invitation to the org. Do you plan to work on this now? If you're not actively working on it, I'd prefer to leave it unassigned.
, would you help to send the invitation ? Yes, I'd like to work on this now, that's a good start for me to learn example & e2e test suite :).
Already sent. Visit to accept. See
, I'm kuber now , thanks. I'm working on this now :). Checked and , openshift-origin is not using default namespace now; and we can update 's script to update namespace. But it seems and other example are still using default namespace, should we go through all example and update them accordingly?
, should I update all ns in one commit or one commit per example?
In which examples do you plan to make this change? cc
Making this change in some examples would be useful, but only if we explain why we're doing it. Additionally, linking to existing docs and blogs about namespaces would be helpful: I don't want to do this in all of the examples, because it does add an extra step, and labels also provide a means of managing a group of related resources within a namespace. Perhaps could recommend examples where this would make sense.


Question: // CreateVolumeResource constructs a VolumeResource for the current test. It knows how to deal with // different test pattern volume types. func CreateVolumeResource(driver TestDriver, config *PerTestConfig, pattern TestPattern, testVolumeSizeRange e2evolume.SizeRange) *VolumeResource { <ins> return CreateVolumeResourceWithAccessModes(driver, config, pattern, testVolumeSizeRange, driver.GetDriverInfo().RequiredAccessModes) } // CreateVolumeResourceWithAccessModes constructs a VolumeResource for the current test with the provided access modes. func CreateVolumeResourceWithAccessModes(driver TestDriver, config *PerTestConfig, pattern TestPattern, testVolumeSizeRange e2evolume.SizeRange, accessModes []v1.PersistentVolumeAccessMode) *VolumeResource { </ins> r := VolumeResource{ Config:  config, Pattern: pattern,

For the ReadWriteOncePod feature to graduate to beta, we need to have E2E test coverage for its current alpha behavior. See this section of KEP-2485 for more context on what cases we need to cover for alpha: This is a requirement for beta graduation, see:
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


Question: glog.Infof("Using configuration file %s", *configFile) loadBalancer := proxy.NewLoadBalancerRR() <del> proxier := proxy.NewProxier(loadBalancer) </del> <ins> proxier := proxy.NewProxier(loadBalancer, *bindAddress) </ins> // Wire proxier to handle changes to services serviceConfig.RegisterHandler(proxier) // And wire loadBalancer to handle changes to endpoints to services

kube-proxy listens on all ports, but should be configurable. create a flag to specify which interface to listen on. Thanks for finding this bug.
For context, some providers apparently do external IPs by having a whole interface that gets 1:1 NAT without any firewalling. We do not want service ports on those interfaces. , Brian Ketelsen wrote:


Question: // Run starts syncing instances from cloudprovider periodically, or create initial minion list. func (s *MinionController) Run(period time.Duration) { if s.cloud != nil && len(s.matchRE) > 0 { <del> go util.Forever(func() { s.Sync() }, period) </del> <ins> go util.Forever(func() { s.SyncCloud() }, period) </ins> } else { <ins> go s.SyncStatic(period) } } // SyncStatic registers list of machines from command line flag. It returns after successful // registration of all machines. func (s *MinionController) SyncStatic(period time.Duration) error { registered := util.NewStringSet() for { </ins> for _, minionID := range s.minions { <del> s.kubeClient.Minions().Create(&api.Minion{ </del> <ins> if registered.Has(minionID) { continue } _, err := s.kubeClient.Minions().Create(&api.Minion{ </ins> ObjectMeta:    api.ObjectMeta{Name: minionID}, NodeResources: *s.staticResources, }) <ins> if err == nil { registered.Insert(minionID) } } if registered.Len() == len(s.minions) { return nil </ins> } <ins> time.Sleep(period) </ins> } <ins> return nil </ins> } <del> // Sync syncs list of instances from cloudprovider to master etcd registry. func (s *MinionController) Sync() error { </del> <ins> // SyncCloud syncs list of instances from cloudprovider to master etcd registry. func (s *MinionController) SyncCloud() error { </ins> matches, err := s.cloudMinions() if err != nil { return err

gives but gives If minions were already in etcd from some previous launch of the apiserver/controller things work just fine no matter what the order. So to reproduce you have to clear everything from etcd before you try...
can you take a look at this? Probably just need to retry in background until etcd comes up?
Yep, there is no control loop for static machine config. Adding one should be trivial.
Blocked by Basically, apiserver returns inconsistent response.
I have observed a similar sort of thing, but what it appeared to be is more like the is not listening on it's socket at the time tries to connect to it and it never retries. So my work-around is to run before it like so: What I then observed is that the connection is indeed being refused at first attempt, but works on the second.
what do you see in the logs? I was seeing that it basically fails to connect to once and doesn't retry (although it said that it will try to retry).
should fix it, sorry for the trouble wondering where did you see that "it will try to retry"?
that wasn't the exact wording there... let me see if I can find out what exactly it said.
Ok, so what I'm seeing now is: I hope that PIDs would be a good enough proof to what order services have started up: I could provide some systemd graph dumps, but that would probably be too verbose, PIDs seem clearer. So really don't see how got //apisevercontroller-managerapiserver` didn't open the socket yet...


Question: // ExpectedIptablesRule is the expected iptables rules with jump chain and match ipset name type ExpectedIptablesRule struct { <del> JumpChain string MatchSet  string </del> <ins> SourceAddress string JumpChain     string MatchSet      string </ins> } // ExpectedIPSet is the expected ipset with set name and entries name

Loopback addresses (127.0.0.0/8, ::1/128) can't be used by services in proxy-mode=ipvs it makes sense to dismiss those early, add RETURN rule to KUBE-NODE-PORT,KUBE-SERVICES No response <details</details25 <details</detailsnone <details</details<details</details<details</details<details</details
/sig network
As mentioned in , this is not a bug since the nodeport and ephemeral ranges overlap.
/kind cleanup /kind remove-bug
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /kind cleanup /kind remove-bug </details
/remove-kind bug
The title of this issue should be changed to something like; Which would indicate that this is not a bug fix but an improvement. Also remove the invalid use-case in the description and add references to comments in like I think to dismiss nodePort connects to localhost early for proxy-mode=ipvs is an improvement, and in the majority of systems traffic to localhost is more common than traffic to nodePorts so this change will also improve overall performance. This is not a fix for overlapping ephemeral and nodePort ranges! So if the title and description is not updated the correct triage is to close this issue as it violates the non overlapping rule for ephemeral/nodeport ranges, please see
/area ipvs
Ok, i will change issue title and descripiton
/triage accepted


Question: return err } <del> // Throw an error when the daemon pods fail, to use ratelimiter to prevent kill-recreate hot loop if failedPodsObserved > 0 { return fmt.Errorf("deleted %d failed pods of DaemonSet %s/%s", failedPodsObserved, ds.Namespace, ds.Name) } </del> return nil }

<!-- 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 feature What happened: I have a daemonsets with 250 replicas and maxUnavailable is 20%. When I try to update its image, the ds will scale down 50 old replicas and wait for SatisfiedExpectations, after that it will scale up 50 new replicas. But if a pod delete failed (node is notready, and pod stuck at terminating status), ds controller will never reach the expectation and just stuck here. What you expected to happen: When a pod stuck at terminating, ds controller should start new pods like deployment controller, instead of waiting for the delete batch finish and ready for next poll. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.1-8+", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-10-25T13:04:04Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig apps /cc
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/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
DaemonSet controller waits for old pods to terminate before creating new ones for best-effort at-most-one pod per node. This is a deliberate design decision.

In most cases, DaemonSets won't tolerate two pods scheduled on the same node at the same time; for example, it's common to communicate with DaemonSet pods via . I'm going to close this ticket as this works as designed. Please feel free to reopen the ticket if you think there are still issues to be resolved.
/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
why does the DaemonSet controller wait for all pods 50 to be done, before moving to the NEXT 50 ? I completely understand that we want only at most 1 pod per node. But if a pod deletion fails on the node, move on to the next pod as long as the total unavailable pods are less than maxUnavailable. This will allow us to make progress in the face of bad nodes or failed pod deletions due to failing tear down of bad volumes or other reasons.
/assign
thoughts on this one ?
Any progress on this issue? We also encountered this problem. There are thousands of nodes in our prod cluster and nodes often go down, which cause daemonset rolling update stucked, this problem really bother us.
PTAL
/reopen
You can't reopen an issue/PR unless you authored it or you are a collaborator. <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
/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
/reopen
You can't reopen an issue/PR unless you authored it or you are a collaborator. <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: if retries != 1 { t.Fatalf("%s: expected exactly 1 retry, got %d", job.Name, retries) } <ins> // await for the actual requeue after processing of the pending queue is done awaitForQueueLen(ctx, t, manager, 1) </ins> // the queue is emptied on success fakePodControl.Err = nil <del> manager.clock.Sleep(fastJobApiBackoff) </del> manager.processNextWorkItem(context.TODO()) verifyEmptyQueue(ctx, t, manager) }

pull-kubernetes-unit TestJobApiBackoffReset Unclear, test was last modified in June in Seen most recently in No response No response No response /sig batch cc
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : ### Which jobs are flaking? cc 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
/sig apps /assign mimowo It could be related to ? Or maybe it was always flaky. just in case cc
/wg batch
Thanks for the heads up, I will take a look
Ok, I think I know the issue, which is very similar to another flaky test fixed in the past. The issue is when we shift the fake clock with during (invoked by ), which processes the pending queue () asynchronously. More details on the similar past issue: (). I was able to repro this manually by inserting short real-clock sleeps like here: I think the issue was introduced actually here by the use of fake clock: This commit was to master after 1.27 so no need for cherry-picking the fix. I think the fix is to call instead of , because it repeatedly shifts the fake clock after is processed.


Question: }, "invalid-cross-namespace-affinity": { rq:        core.ResourceQuota{ObjectMeta: metav1.ObjectMeta{Name: "abc", Namespace: "foo"}, Spec: invalidCrossNamespaceAffinitySpec}, <del> errDetail: "must be 'Exist' when scope is any of ResourceQuotaScopeTerminating, ResourceQuotaScopeNotTerminating, ResourceQuotaScopeBestEffort, ResourceQuotaScopeNotBestEffort or ResourceQuotaScopeCrossNamespacePodAffinity", </del> <ins> errDetail: "must be 'Exists' when scope is any of ResourceQuotaScopeTerminating, ResourceQuotaScopeNotTerminating, ResourceQuotaScopeBestEffort, ResourceQuotaScopeNotBestEffort or ResourceQuotaScopeCrossNamespacePodAffinity", </ins> }, } for name, tc := range testCases {

On the document, the operator should be 'Exists' ! But in the Error message, it becomes 'Exist' ! the error message should be create a yaml and apply it It's my first time, I am not sure should we change to ? <details</details<detailsK3S </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
/assign
/assign


Question: ginkgo.By("Run a high priority pod that has same requirements as that of lower priority pod") // Create a high priority pod and make sure it is scheduled on the same node as the low priority pod. <del> runPausePodWithTimeout(ctx, f, pausePodConfig{ </del> <ins> runPausePod(ctx, f, pausePodConfig{ </ins> Name:              "preemptor-pod", PriorityClassName: highPriorityClassName, Resources: &v1.ResourceRequirements{ Requests: podRes, Limits:   podRes, }, <del> }, framework.PodStartShortTimeout) </del> <ins> }) </ins> preemptedPod, err := cs.CoreV1().Pods(pods[0].Namespace).Get(ctx, pods[0].Name, metav1.GetOptions{}) podPreempted := (err != nil && apierrors.IsNotFound(err)) ||

master-blocking kind-ipv6-master-parallel RuntimeClass should run a Pod requesting a RuntimeClass with scheduling without taints AdmissionWebhook [Privileged:ClusterAdmin] should honor timeout [Conformance] 01-27-2023 16:08 PST https://k8s- { failed [FAILED] timed out while waiting for pod runtimeclass-3517/without-label to be running In [It] at: @ 01/28/23 22:33:45.607 } No response kind cc
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
It looks like that “Kubernetes e2e suite: . Would we want to reopen this issue? I will keep a close eye on to see if it continues to flake.
Reopen to monitor failures cc
/sig node /cc
/retitle [It] [sig-node] RuntimeClass should run a Pod requesting a RuntimeClass with scheduling without taint
Example failure:
Failure The pod was created at , from the kubelet logs: so the pod started at , but it was deleted at because the 1 minute timeout was hit. It looks like the container startup took a while based on containerd logs: there is a gap there of and between and
It is hitting this timeout - That uses which is 1 min which seems to be too short. We should probably use or which is 5min or 2min, because the whole pod needs to start and it seems like 1min is too short in this case.


Question: if ! which /usr/libexec/cockpit-ws &>/dev/null; then pushd /etc/yum.repos.d <del> wget https://copr.fedoraproject.org/coprs/sgallagh/cockpit-preview/repo/fedora-22/sgallagh-cockpit-preview-fedora-22.repo </del> <ins> curl -OL https://copr.fedorainfracloud.org/coprs/g/cockpit/cockpit-preview/repo/fedora-23/msuchy-cockpit-preview-fedora-23.repo </ins> dnf install -y cockpit cockpit-kubernetes popd

The latest vagrant always restarts nfs when nfs is used to share folders: This doesn't work with the default kube libvirt image: Attempting to restart nfs (systemctl restart nfs) on this image results in a failure from /usr/sbin/exportfs (invoked in the nfs unit file via ExecStartPre) of 'No file systems exported!' and this halts vagrant provisioning. To replicate (centos 7.1+vagrant 1.8.1+vagrant-libvirt 0.0.32):
This issue should be resolved by (already merged) and .
I marked as lgtm, so its basically blocked by the submit queue being fixed.


Question: Help:      "Cumulative proxy rules Service changes", }, ) <ins> // IptablesRestoreFailuresTotal is the number of iptables restore failures that the proxy has // seen. IptablesRestoreFailuresTotal = prometheus.NewCounter( prometheus.CounterOpts{ Subsystem: kubeProxySubsystem, Name:      "sync_proxy_rules_iptables_restore_failures_total", Help:      "Cumulative proxy iptables restore failures", }, ) </ins> ) var registerMetricsOnce sync.Once

What would you like to be : kube-proxy should expose better metrics around tracking success and failures. Administrators should be able to alert on failure counts. Why is this needed: There are several motivating cases: iptables lock contention causes to fail at an increasing rate as services + endpoints grows or are failing to execute Ultimately, there is essentially no feedback from kube-proxy if it fails to program the service network. This makes it annoyingly difficult to debug when things go wrong. As many reasonable hints we can provide should be . /sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
is anyone working one this..
what cases do you think are poorly covered? /assign
thanks for triaging this :-) The specific cases are when fails - that function logs an error but doesn't otherwise surface any information. We should have a top-level metric for failing, along with any other lower-level metrics that might make sense for administrators, e.g. fails, fails.
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry.
/help-wanted
/assign


Question: ], ) <ins> go_test( name = "go_default_test", srcs = ["util_test.go"], library = ":go_default_library", deps = [ "//vendor/k8s.io/client-go/util/flowcontrol:go_default_library", ], ) </ins> filegroup( name = "package-srcs", srcs = glob(["**"]),

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Shows that prometheus.MustRegister will panic on things like dashes in the metric name. There are currently 138 calls to prometheus.MustRegister in the Kubernetes code base almost exclusively from controllers. We should audit the code to ensure that panic is the desirable response to a bad metric name for these calls vs. something like prometheus.Register which will instead return an error. What you expected to happen: See above How to reproduce it (as minimally and precisely as possible): See Anything else we need to know?: No Environment: All Kubernetes version (use ): 1.9 Cloud provider or hardware configuration**: All OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
I did an analysis on this issue, and this is what I found: of the calls use a static metric name (hardcoded at the method invocation via a string and/or constant); is only a single case where the metric name is constructed dynamically (from a parameter), at the file (and happens to be where panicked); My proposal is: a. For static metric names (1), leave them as they are; b. For dynamic metric names (2), where the caller might not know that a parameter will be used to construct a metric name: Update the file to use instead of , and return the error if the metric cannot be registered (already submitted PR ); A quick search from the method invocation (from the above file) results in 17 invocations, mostly controllers, but although returns an error, no one of those 17 results is catching the error. So, we need to update all invocations to catch the error (I plan to submit new PRs to address this).

/sig instrumentation
We can trace all the task for update metrics.RegisterMetricAndTrackRateLimiterUsage invocations, and I am very happy to help fix it. [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [ ] [ ] [x] [x] [x]
Please go ahead with the ones not yet updated if you want.
OK, thanks!
now, we catch the error and when there return an error, we return in the function . But in the test file we use function for many times and Then there will be a lot of error in the test file, such as: then the test will always go fail. I think we should distinguish the error and when the error is Duplicate registration we dhould ignore it and return the normal controller.
Can you please provide an example where this is happening? I ran the tests on several controllers and haven't found that error. Ignoring this error doesn't seem a good idea IMO, if there're some tests that fail, we should investigate why are failing and fix them appropriately.
Sorry, I thought you were talking about the unit tests, didn't see the integration tests problem. I've submitted to fix this and ran the integration tests to check that creating multiple controllers don't fail anymore.
actually in some cases the unit tests is also failed such as endpoint controllerreplicaset controller. because different set up before test. So we should take a action to resolve it.


Question: // We now wait for the minimum duration if at least one plugin asked to // wait (and no plugin rejected the pod) if statusCode == Wait { <ins> startTime := time.Now() </ins> w := newWaitingPod(pod, pluginsWaitTime) f.waitingPods.add(w) defer f.waitingPods.remove(pod.UID) klog.V(4).Infof("waiting for pod %q at permit", pod.Name) s := <-w.s <ins> metrics.PermitWaitDuration.WithLabelValues(s.Code().String()).Observe(metrics.SinceInSeconds(startTime)) </ins> if !s.IsSuccess() { if s.IsUnschedulable() { msg := fmt.Sprintf("pod %q rejected while waiting at permit: %v", pod.Name, s.Message())

<!-- Please only use this template for submitting enhancement requests --What would you like to be : metric name Description -- -- permitwaitduration_seconds Duration of permit extension point finishes waiting. Why is this needed: In permit extension point, if the status is "Wait", we block until the pod is scheduled or timeout: Blocking is an important behavior that we should monitor. /sig scheduling
/assign


Question: [[ -n ${1-} ]] || { kube::log::error_exit "!!! Internal error. No platform set in kube::golang::set_platform_envs" } <ins> # make sure we have a clean slate first kube::golang::unset_platform_envs </ins> export GOOS=${platform%/*} export GOARCH=${platform##*/}

Similar to this is to test the first contributor experience fails on ubuntu 16.04, docker version 1.12.3:
Got the same error on Linux ubuntu 4.2.0-27-generic ~14.04.1-Ubuntu SMP Fri Jan 22 15:32:26 UTC 2016 x8664 x8664 x86_64 GNU/Linux Docker Client version: 1.6.2 Client API version: 1.18 Go version (client): go1.2.1 Git commit (client): OS/Arch (client): linux/amd64 Server version: 1.6.2 Server API version: 1.18 Go version (server): go1.2.1 Git commit (server): OS/Arch (server): linux/amd64
What git sha of were you building from?
I have cloned the head. I think the reason might be missing package: gccgo-4.8-aarch64-linux-gnu I'm compiling right now and update on result.
were you running or ? runs inside docker, so the gcc error is confusing.
I run: sudo make release in Ubuntu VM running in VMWare workstation if that matters. Are you in kubernetes-users slack channel?
does fail in the same way?
Do you need to run , instead of just ? Can you try running the following:
well, if I don't do sudo docker does not work :) I need to run as root. I'll try the commands as soon as quick-release ends.
ah, gotcha. you can probably fix the docker access issue by following in the docker manual. that's probably not why it's failing, though.
make release still does not work :(
can you please run and then paste the results? ( turns up the debugging verbosity.)
for me: works (using your PR to fixes the gobindata dep) -local Go build- works (docker build) works if you have Docker running. does not work: on OSX did not seem to give more verbosity.
V=4 make release did not help :(
oops, that was not the correct environment variable, sorry. I meant .
here we go:
Aha, I think I figured it out. Sorry for making you rebuild so many times; the issue still isn't super obvious from the logs.

Basically, the bug only occurs if you don't have enough memory to do the docker builds in parallel; if that happens, you fall into this . On the parallel side of the branch, we set the platform env vars within a subshell, so each of the cross-compilation builds won't affect each other. On the non-parallel side of the branch, we don't use a subshell. Inside , there's no overrides done for . As a result, we end up incorrectly reusing the value for , , which doesn't recognize the flag being applied for the darwin build. The fix should be easy; I'll get that sent out ASAP. we probably want this fix for 1.5, since if you fall back to non-parallel crossbuilds we're doing the wrong thing.
Ack. Will keep an eye out for the fix. Please mark it as cherrypick-candidate
Thank you guys!
I think it is almost there. Got much further in the build (4 GB of RAM). Towards the end there is a failed test that makes the build fail: This is probably a different bug, as your PR got passed the misconfigured compilation.
FWIW, the worked on ubuntu 16.06. It did ran some tests apparently but the build succeeded.
I just tried with and it worked fine
since we have a PR ready and working, can we please switch this to non-release-blocker?


Question: etpLocalNodePredicates []NodeConditionPredicate = []NodeConditionPredicate{ nodeIncludedPredicate, nodeUnTaintedPredicate, <ins> nodeReadyPredicate, </ins> } stableNodeSetPredicates []NodeConditionPredicate = []NodeConditionPredicate{ nodeNotDeletedPredicate,

In 1.26 the service controller in the Kubernetes cloud controller manage (KCCM) introduced a new mechanism for syncing load balancers based on predicates. The predicates applied will depend on "service classes", specifically if it's or , see: This implementation is not well suited for internal GCP load balancers which use InstanceGroups. from Google, feel free to correct me: any cluster has all nodes grouped together into an instance group. Service of have individual GCP load balancers, but these load balancers end up referencing the same instance group (which is the cluster's instance group). This means that the inclusion/exclusion predicates for any service, will trickle down and impact the cluster's global instance group, thereby impacting other services which don't necessarily apply the same set of predicates. Ex: services exclude nodes, whereas do not. A Node going will therefore be removed from all backends for services, however on GCP with load balancer solution based on InstanceGroups: this means that the same node will be removed from all backends for services too. This is NOT a problem on = 1.27 using the feature , because all services on 1.27 using that feature gate will have the same set of predicates. Node updates requiring the removal of the instance from load balancers belonging to services of should not impact other services of . Bring up a cluster using "Internal load balancers" on GCP. Define two services, one being and the other . Have one node go . The instance corresponding to that Node might be removed from the InstanceGroup backend of the service. This will depend on the order the services are synced, if the service is synced last then the instance will be removed. This is actually not really that bad, because the only different predicate between both is the readiness condition - and a node should go back to if all is fine, and finally be included. But I wanted to raise this for issue for completeness sake so that it is known. <details</details<detailsGCP </details<details</details<details</details<details</details<details</details
/sig network /sig cloud-provider /cc
/triage accepted


Question: logger:               logger, } <ins> if len(f.extenders) > 0 { // Extender doesn't support any kind of requeueing feature like EnqueueExtensions in the scheduling framework. // We register a defaultEnqueueExtension to framework.ExtenderName here. // And, in the scheduling cycle, when Extenders reject some Nodes and the pod ends up being unschedulable, // we put framework.ExtenderName to pInfo.UnschedulablePlugins. f.enqueueExtensions = []framework.EnqueueExtensions{&defaultEnqueueExtension{pluginName: framework.ExtenderName}} } </ins> if profile == nil { return f, nil }

When Extender filters out some Nodes, we don't set any unschedulable plugins at all. It means Extender is completely ignored during the requeueing process. So, what's happening is: If Extender filters out all Nodes during scheduling, this Pod is soon retried because this Pod doesn't have any plugin name in unschedulable plugins. If Extender filters out some Nodes during scheduling and plugins filter out all other Nodes, this Pod is retried based on plugins' QueueingHint. Even if any cluster events happen and it could change Extender's decision (but not any plugins' decision), this Pod won't be requeued to activeQ/backoffQ. The latter case is serious because it could make Pods being stuck in unschedulable pod pool in 5min. We should have a short-term solution for the latter case. We can requeue Pods, which were rejected by Extender, by any kind of cluster events because we cannot know which events make Pods schedulable. Eventually, this issue makes us wonder how Pods rejected by Extender should be requeued. We cannot implement QHint equivalent in Extenders because it'd be too slow to call Extender every time any cluster events happen. Probably, somehow implementing EventsToRegister equivalent in Extender? Use Extender which does something in Filter. No response master <detailsn/a </details<details</details<details</details<details</details<details</details
/assign
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig scheduling
/reopen We'll close it when all cherry-picks are done.
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
/close Cherry-picks are done.


Question: } mapper, typer := f.Object() <del> r := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand(cmd)). </del> <ins> r := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand()). </ins> ContinueOnError(). NamespaceParam(cmdNamespace).RequireNamespace(). FilenameParam(filenames...).

I think the need for this argument to the factory methods has passed - it means that callers who want to provide configurable behavior have to do it through the factory itself, which is acceptable. We can remove it whenever.
I removed most of the unused arguments. But, There are a few methods still using the argument. Namely, , , and . Before proceeding any further I wanted to ask what should be done about these methods? Deprecated/Refactored/Removed ?
The factory methods were the most important. The pattern before was people using the flags by name (cmd.Flags().Get("foo")), but now factory methods must use pointer flag vars, so there's nothing that should need the command there. The printer methods are optional units that can be used when you add the flags for them to your command. Unless we refactor the definition of those flags to use pointers and return a printer struct (something I had started a while back and never finished), it's not worth changing them right now. The other consumer of factory is OpenShift - we wrap the factory to add our additional types (implementations of things like describers, action verbs, etc): - but we will pick up and remove use of cmd when we rebase.
Thanks for the explanation. I've cleaned the as well. Print method APIs are untouched as you suggested.
cc
Looks like this was done by PR


Question: /* Release: v1.28 <del> Testname: Validating Admission webhook, validating webhook exclude leases using match conditions field. Description: Create a validating webhook configuration with matchConditions field that will reject all resources except the coordination.k8s.io/lease ones. Try to create pods until the webhook is ready and rejecting the pods with "denied" error message. Create a Lease object and validate that it bypasses the webhook. Create a configMap and validate that it's rejected by the webhook. */ ginkgo.It("should reject everything except leases", func(ctx context.Context) { excludeLeasesMatchConditions := []admissionregistrationv1.MatchCondition{ { Name:       "exclude-leases", Expression: `!(request.resource.group == "coordination.k8s.io" && request.resource.resource == "leases")`, }, } ginkgo.By("creating a validating webhook with match conditions") validatingWebhookConfiguration := newValidatingWebhookWithMatchConditions(f, servicePort, certCtx, excludeLeasesMatchConditions) _, err := createValidatingWebhookConfiguration(ctx, f, validatingWebhookConfiguration) framework.ExpectNoError(err, "registering webhook config %s", f.UniqueName) defer func() { err := client.AdmissionregistrationV1().ValidatingWebhookConfigurations().Delete(ctx, validatingWebhookConfiguration.Name, metav1.DeleteOptions{}) framework.ExpectNoError(err, "Deleting mutating webhook configuration") }() err = waitWebhookConfigurationReady(ctx, f, f.Namespace.Name) framework.ExpectNoError(err, "waiting for webhook configuration to be ready") ginkgo.By("validate that the validating webhook configuration does not reject leases") _, err = client.CoordinationV1().Leases(f.Namespace.Name).Create(ctx, &coordinationv1.Lease{ ObjectMeta: metav1.ObjectMeta{ Name: "lease" + f.UniqueName, }, Spec: coordinationv1.LeaseSpec{}, }, metav1.CreateOptions{}) framework.ExpectNoError(err, "creating coordination.k8s.io/lease object") ginkgo.By("validate that the validating webhook configuration does reject configMaps") _, err = client.CoreV1().ConfigMaps(f.Namespace.Name).Create(ctx, &v1.ConfigMap{ ObjectMeta: metav1.ObjectMeta{ Name: "cm" + f.UniqueName, }, Data: map[string]string{ "reject": "this", }, }, metav1.CreateOptions{}) framework.ExpectError(err, "creating configmap object") expectedErrMsg := "denied the request: this webhook denies all requests" gomega.Expect(strings.Contains(err.Error(), expectedErrMsg)).To(gomega.BeTrue()) }) /* Release: v1.28 </del> Testname: Mutating Admission webhook, mutating webhook excluding object with specific name Description: Create a mutating webhook configuration with matchConditions field that will reject all resources except ones with a specific name 'skip-me'. Create

Kubernetes e2e suite: [It] [sig-api-machinery] AdmissionWebhook [Privileged:ClusterAdmin] should reject everything except leases The job was run on Aug 5th. I had a PR fixing typos in comments of kubelet source code. It is not related to api-machinery ipv6 but the test failed. The re-test passed. No response No response It seems the test is recently . /sig api-machinery /sig testing
It is failing considerably , it seems it fails to connect to the webhook that matches the time the test was I don't fully understand the test but it seems that is interacting with the cluster, I don't have clear if the deny policy affects everything and this is causing the race with the pod that implements the webhook /priority critical-urgent /release blocker /cc
/assign
cc
Debugged with Joe offline, paste for reference click open stderr on the failure to get the timeline
still failing after merge of
/triage accepted
It's suspicious that of all the admission webhook tests that start up a webhook pod, this is the one that flakes. I'll look more closely.
Looks like the webhook in this test may be configured to deny requests except leases globally in the cluster once enabled., which might create a race where, if the webhook is registered first , the controller setting up the webhook pod is denied requests by the webhook. I'll scope the webhook matching to the test namespace per offline suggestion.
Please let me know if I can be of help debugging this.Have free cycle and would like to contribute.
/assign
I can still see references to the expression that gives error Example run: Could you help confirm that the tests are completely removed? Thank you. cc
I think this is another test that is impacting the rest of the tests. Probably because the tests are running in parrallel. We might want to scope things down. Currently working on a fix.
/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
this is a new bug, please review all the test that were and verify they are scoped to the custom created namespaces by the test framework, and if not, please tag them as cc:
/cc
I assume this could be closed with merged? /cc
Looks like the exact flak as reported in this issue has been resolved. /close
Closing this issue. <detailsIn response to : Looks like the exact flak as reported in this issue has been resolved. /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: # Install a few things needed by the verification tests. command -v etcd &>/dev/null || ./hack/install-etcd.sh <del> go get -u github.com/tools/godep </del> make verify

Didn't see an issue for this. Godep recently updated its version to v80. This broke several builds that directly godep, grabbing latest. /kind bug cc Example https://k8s- Here are some examples where we grab master:
We have helpers to grab godep. We should use them everywhere.
/cc
/assign


Question: ValidateOrFail(k8s, model, &TestCase{FromPort: 81, ToPort: 81, Protocol: v1.ProtocolTCP, Reachability: reachabilityPort81}) }) <ins> ginkgo.It("should support denying of egress traffic on the client side (even if the server explicitly allows this traffic) [Feature:NetworkPolicy]", func() { // x/a --> y/a and y/b // Egress allowed to y/a only. Egress to y/b should be blocked // Ingress on y/a and y/b allow traffic from x/a // Expectation: traffic from x/a to y/a allowed only, traffic from x/a to y/b denied by egress policy nsX, nsY, _, model, k8s := getK8SModel(f) // Building egress policy for x/a to y/a only allowedEgressNamespaces := &metav1.LabelSelector{ MatchLabels: map[string]string{ "ns": nsY, }, } allowedEgressPods := &metav1.LabelSelector{ MatchLabels: map[string]string{ "pod": "a", }, } egressPolicy := GetAllowEgressByNamespaceAndPod("allow-to-ns-y-pod-a", map[string]string{"pod": "a"}, allowedEgressNamespaces, allowedEgressPods) CreatePolicy(k8s, egressPolicy, nsX) // Creating ingress policy to allow from x/a to y/a and y/b allowedIngressNamespaces := &metav1.LabelSelector{ MatchLabels: map[string]string{ "ns": nsX, }, } allowedIngressPods := &metav1.LabelSelector{ MatchLabels: map[string]string{ "pod": "a", }, } allowIngressPolicyPodA := GetAllowIngressByNamespaceAndPod("allow-from-xa-on-ya-match-selector", map[string]string{"pod": "a"}, allowedIngressNamespaces, allowedIngressPods) allowIngressPolicyPodB := GetAllowIngressByNamespaceAndPod("allow-from-xa-on-yb-match-selector", map[string]string{"pod": "b"}, allowedIngressNamespaces, allowedIngressPods) CreatePolicy(k8s, allowIngressPolicyPodA, nsY) CreatePolicy(k8s, allowIngressPolicyPodB, nsY) // While applying the policies, traffic needs to be allowed by both egress and ingress rules. // Egress rules only // 	xa	xb	xc	ya	yb	yc	za	zb	zc // xa	X	X	X	.	*X*	X	X	X	X // xb	.	.	.	.	.	.	.	.	. // xc	.	.	.	.	.	.	.	.	. // ya	.	.	.	.	.	.	.	.	. // yb	.	.	.	.	.	.	.	.	. // yc	.	.	.	.	.	.	.	.	. // za	.	.	.	.	.	.	.	.	. // zb	.	.	.	.	.	.	.	.	. // zc	.	.	.	.	.	.	.	.	. // Ingress rules only // 	xa	xb	xc	ya	yb	yc	za	zb	zc // xa	.	.	.	*.*	.	.	.	.	. // xb	.	.	X	X	.	.	.	.	. // xc	.	.	X	X	.	.	.	.	. // ya	.	.	X	X	.	.	.	.	. // yb	.	.	X	X	.	.	.	.	. // yc	.	.	X	X	.	.	.	.	. // za	.	.	X	X	.	.	.	.	. // zb	.	.	X	X	.	.	.	.	. // zc	.	.	X	X	.	.	.	.	. // In the resulting truth table, connections from x/a should only be allowed to y/a. x/a to y/b should be blocked by the egress on x/a. // Expected results // 	xa	xb	xc	ya	yb	yc	za	zb	zc // xa	X	X	X	.	*X*	X	X	X	X // xb	.	.	.	X	X	.	.	.	. // xc	.	.	.	X	X	.	.	.	. // ya	.	.	.	X	X	.	.	.	. // yb	.	.	.	X	X	.	.	.	. // yc	.	.	.	X	X	.	.	.	. // za	.	.	.	X	X	.	.	.	. // zb	.	.	.	X	X	.	.	.	. // zc	.	.	.	X	X	.	.	.	. reachability := NewReachability(model.AllPods(), true) // Default all traffic flows. // Exception: x/a can only egress to y/a, others are false // Exception: y/a can only allow ingress from x/a, others are false // Exception: y/b has no allowed traffic (due to limit on x/a egress) reachability.ExpectPeer(&Peer{Namespace: nsX, Pod: "a"}, &Peer{}, false) reachability.ExpectPeer(&Peer{}, &Peer{Namespace: nsY, Pod: "a"}, false) reachability.ExpectPeer(&Peer{Namespace: nsX, Pod: "a"}, &Peer{Namespace: nsY, Pod: "a"}, true) reachability.ExpectPeer(&Peer{}, &Peer{Namespace: nsY, Pod: "b"}, false) ValidateOrFail(k8s, model, &TestCase{FromPort: 81, ToPort: 80, Protocol: v1.ProtocolTCP, Reachability: reachability}) }) </ins> ginkgo.It("should enforce egress policy allowing traffic to a server in a different namespace based on PodSelector and NamespaceSelector [Feature:NetworkPolicy]", func() { nsX, nsY, _, model, k8s := getK8SModel(f) allowedNamespaces := &metav1.LabelSelector{

In reference to conversation on #sig-network-policy-api.  What would you like to be : Add a test to the netpol validation framework to validate a scenario where traffic between two pods has egress and ingress rules defined. Why is this needed: To ensure consistent behavior between different implementations of networkPolicy. For example, describes different behavior between Calico networkPolicy and Azure networkPolicy
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 sig-network
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig sig-network 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 network
thanks for offering to hack on this
/sig network
cc
I reviewed the current networkpolicy tests, and I believe this case is already captured in the currents tests.
Thanks for digging into this ... so Your case, yesterday was more then just combining egress and ingress. Your case , was one where Egress blocked a traffic that was allowed by other rules. Which is quite interesting and confuses alot of people. ... It highlights the 'podselector centric' nature of policies.... I think you want to do , right? In that case, Egress rule is specifically created that disallows but Ingress rules explicitly allow And the result is that Egress wins, and traffic is blocked ...
This is an interesting test case, I'd be happy to hack on this and look at adding a table-driven netpol test case but don't want to step on your toes if you're already looking into ! Definitely see the value of illuminating this corner case with a clear test scenario!
Thx for the feedback. You are right that it's still a different case. : I'm looking at what I can throw together today. Stay tuned, and would love your input.
I created the initial version of the test.

The code (and comments) are likely a bit verbose at this point. Should I open a PR against this repo now, or do you want me to make changes to that code prior to the PR?
Looks awesome, I'd go ahead with the PR!
can you reference this issue in your new PR ?
/assign


Question: Skip ) <ins> const ( // MaxNodeScore is the maximum score a Score plugin is expected to return. MaxNodeScore int = schedulerapi.MaxPriority // MinNodeScore is the minimum score a Score plugin is expected to return. MinNodeScore int = 0 ) </ins> // Status indicates the result of running a plugin. It consists of a code and a // message. When the status code is not `Success`, the status message should // explain why.

What would you like to be : a default normalize score function in the scheduling framework. the plugin and log an error when the normalizing phase returns an invalid range of scores. Why is this needed: Per discussion in , we should enforce the range of score returned by the scoring plugin. /sig scheduling /priority important-soon /assign


Question: kubetypes "k8s.io/kubernetes/pkg/kubelet/types" ) <ins> var ( defaultCFSQuota = metav1.Duration{Duration: 100 * time.Millisecond} ) </ins> // ValidateKubeletConfiguration validates `kc` and returns an error if it is invalid func ValidateKubeletConfiguration(kc *kubeletconfig.KubeletConfiguration) error { allErrors := []error{}

<!-- 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 --See for more context. What happened: When you set and , you'd expect container cfs quota period to be . However, unless you also set in the feature flags, the quota value will be silently ignored. What you expected to happen: At least a warning be logged if the feature is not enabled but is set. 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:
/sig node /assign karan
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig node 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: ENV GOARCH  amd64 # Get the code coverage tool and godep <del> RUN go get code.google.com/p/go.tools/cmd/cover github.com/tools/godep </del> <ins> RUN go get golang.org/x/tools/cmd/cover github.com/tools/godep </ins> # We use rsync to copy some binaries around.  It is faster (0.3s vs. 1.1s) on my # machine vs. `install`

Building still fails at Step 5 : : <precore ~/kubernetes/build $ ./make-build- You don't have a local copy of the golang docker image. This image is 450MB. Download it now? [y/n] y +++ Pulling docker image: golang:1.3 Pulling repository golang : Download complete : Download complete : Download complete : Download complete : Download complete : Download complete : Download complete : Download complete : Download complete : Download complete : Download complete : Download complete : Download complete +++ Building Docker image kube-build:cross. +++ Building Docker image kube-build:build-. +++ Docker build command failed for kube-build:build- Sending build context to Docker daemon 1.326 MB Sending build context to Docker daemon Step 0 : FROM kube-build:cross --- Step 1 : MAINTAINER Joe Beda in --- Removing intermediate container Step 2 : ENV GOARM 5 ---Running in --- Removing intermediate container Step 3 : ENV GOOS linux ---Running in --- Removing intermediate container Step 4 : ENV GOARCH amd64 ---Running in --- Removing intermediate container Step 5 : RUN go get ---Running in package 403 Forbidden abort: HTTP Error 403: Forbidden package imports imports exit status 255 2014/11/18 19:08:46 The command [/bin/sh -c go get ] returned a non-zero code: 1 To retry manually, run: docker build -t kube-build:build- /home/core/kubernetes/output/images/kube-build:build- !!!

Error in 'return 1' exited with status 1 Call stack: 1: kube::build::buildimage(...) 2: ./make-build- main(...) Exiting with status 1 core ~/kubernetes/build $ </preIt also fails by manually running : <precore ~/kubernetes/build $ docker build -t kube-build:build- /home/core/kubernetes/_output/images/kube-build:build- Sending build context to Docker daemon 1.326 MB Sending build context to Docker daemon Step 0 : FROM kube-build:cross --- Step 1 : MAINTAINER Joe Beda cache --- Step 2 : ENV GOARM 5 ---Using cache --- Step 3 : ENV GOOS linux ---Using cache --- Step 4 : ENV GOARCH amd64 ---Using cache --- Step 5 : RUN go get ---Running in package 403 Forbidden abort: HTTP Error 403: Forbidden package imports imports exit status 255 2014/11/18 19:22:27 The command [/bin/sh -c go get ] returned a non-zero code: 1 core ~/kubernetes/build $ </pre
Where are you running this? is rejecting your requests to clone. If you try: hg clone -U On your computer, does it work? --brendan , Luca G. Soave wrote:
Note: I just ran this and wasn't able to reproduce the error (I cleaned out all of my images first).
Can you confirm that this is still happening to you? Perhaps this is a transient event as part of the golang migration to github. Or it could be that your IP is being geolocated to a country that Google doesn't serve to. See: !topic/golang-nuts/9wUiTAnqGCQ
I confirm it is still happening. I run it in a DigitalOcean CoreOS located in London (now dropped off actually): <prePublic Network IP Address: 178.62.77.84 Gateway: 178.62.64.1 Netmask: 255.255.192.0 Private Network Private IP: 10.131.217.146 Netmask: 255.255.0.0 </preIt seems the same case you just mentioned in your link.
Asking around inside Google. Related:
is going away if it hasn't already. We need to fix if we're still referring to it.

I merged something earlier today that should have fixed this, but maybe we missed something. , Joe Beda wrote:
The line that is hitting this is here: What should we change that to?
I think ""