jiebi/CodeConvo huggingface dataset:
Change:
HostIP:        p.HostIP, } <ins> // We need to determine the address family this entry applies to. We do this to ensure // duplicate containerPort / protocol rules work across different address families. // https://github.com/kubernetes/kubernetes/issues/82373 family := "any" if p.HostIP != "" { if utilsnet.IsIPv6String(p.HostIP) { family = "v6" } else { family = "v4" } } </ins> // We need to create some default port name if it's not specified, since <del> // this is necessary for rkt. // http://issue.k8s.io/7710 </del> <ins> // this is necessary for the dockershim CNI driver. // https://github.com/kubernetes/kubernetes/pull/82374#issuecomment-529496888 </ins> if p.Name == "" { <del> pm.Name = fmt.Sprintf("%s-%s:%d", container.Name, p.Protocol, p.ContainerPort) </del> <ins> pm.Name = fmt.Sprintf("%s-%s-%s:%d", container.Name, family, p.Protocol, p.ContainerPort) </ins> } else { pm.Name = fmt.Sprintf("%s-%s", container.Name, p.Name) } <del> // Protect against exposing the same protocol-port more than once in a container. </del> <ins> // Protect against a port name being used more than once in a container. </ins> if _, ok := names[pm.Name]; ok { klog.Warningf("Port name conflicted, %q is defined more than once", pm.Name) continue

Discussion:
What happened: I tried to create a deployment with duplicate containerPorts with hostIPs of two different address families. Only the first mapping was provided as input into my CNI plugin chain. Also, a log message from kubelet warning about a duplicate containerPort was created. What you expected to happen: Both mappings to be provided as input into my CNI plugins. No log messages should be created. How to reproduce it (as minimally and precisely as possible): Create this deployment: Then grab kubelet logs on the host e.g: Anything else we need to know?: This issue here provides some context as to how I ran into this issue: Environment: Kubernetes version (use ): v1.15.1 Cloud provider or hardware configuration: DigitalOcean, custom setup OS (e.g: ):Kernel (e.g. ):Install tools: None Network plugin and version (if this is a network-related bug): Cilium v1.6.0 and Portmap v0.8.2 Others: N/A I've already identified the problem and will submit a PR which fixes this shortly. /sig network
is this dual-stack only? if so, does the fix for this need to target 1.16?
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
This applies to dual-stack only yes. I don't know if it should target 1.16, personally I'd like to get this out so I don't have to run a forked version of kubelet.
/assign
I would agree that this should hit v1.16 if possible.
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. ‍
Change:
// NOTE: The $Format strings are replaced during 'git archive' thanks to the // companion .gitattributes file containing 'export-subst' in this same // directory.  See also https://git-scm.com/docs/gitattributes <del> gitVersion   = "v0.0.0-master+$Format:%h$" </del> <ins> gitVersion   = "v0.0.0-master+$Format:%H$" </ins> gitCommit    = "$Format:%H$" // sha1 from git, output of $(git rev-parse HEAD) gitTreeState = ""            // state of git tree, either "clean" or "dirty"

Discussion:
Ref. includes: // NOTE: The $Format strings are replaced during 'git archive' thanks to the // companion .gitattributes file containing 'export-subst' in this same // directory. See also https://git- gitVersion string = "v0.0.0-master+" This directive, activated by and the  containing the line , results in file contents served by GitHub Archives that can change in unexpected ways. For example, the length of the commit SHA can expand over time as there are collisions. This non-determinism can lead to surprises, such as , where a client-go dependency resulted in unexpectedly different tar hashes, which was detected when a new version of the ko binary was being to Homebrew. tl;dr: though the client-go dependency itself didn't change for ko, later runs of (via GitHub Archives) resulted in different contents for the string to avoid a new collision for the previous prefix length, which cascaded into different content SHAs and shady-looking binary SHAs. I'm not sure, but after reading docs I believe you could naively solve this by replacing with so the string includes the full commit hash instead of the abbreviated one. I have no idea if anything depends on being a shorter string, but presumably things are fine with it having been a variable-length string so . Given enough time/collisions, I suppose theoretically will slow grow to be equal to , but I don't think that will happen during any of our lifetimes 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
Thanks for the report. Moving to kubernetes/kubernetes where this source comes from. There's not a lot we can do for past releases, but I'd be in favor of switching to %H going forward. Reproducibility of source archives is important.
/sig release
/kind bug
Thanks for taking this on !!
since we don't actually use to full-fill the commit info as version, should we just delete that file? containerd a issue about checksum mismatch due to this.

and before that it was and before that , so everywhere
I have created to stop including the files in k8s libraries. For anyone vendoring these libraries in the future, you should no longer be affected by this issue.
Change:
ginkgo.Describe("NFSv3", func() { ginkgo.It("should be mountable for NFSv3", func() { config, _, serverIP := volume.NewNFSServer(c, namespace.Name, []string{}) <del> defer volume.TestCleanup(f, config) </del> <ins> defer volume.TestServerCleanup(f, config) </ins> tests := []volume.Test{ {

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : In block volume tests, wait for the Pod to be deleted instead of letting it be handled by the framework's namespace deletion Why is this needed: I think the regression caused by could have been caught if the tests check for Pod deletion because the Pod object shouldn't be deleted if TearDown fails.
/assign
This issue is not specific to block tests. We should in ideally wait for pod deletion at the end of all types of tests to confirm cleanup logic is functioning
I checked the tests under test/e2e/storage/testsuites/ where DeletePodWithWait is used to wait for the deletion.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten is this still an issue? One way to check is to make a breaking change in cleanup and see if the pull job fails.
I went through all block volume usage in e2e tests: All of them but one wait for their pods to be deleted. I'm fixing the remaining test in
Change:
for _, test := range tests { t.Run(test.name, func(t *testing.T) { <ins> testCtx := initTestPreferNominatedNode(t, "perfer-nominated-node") t.Cleanup(func() { testutils.CleanupTest(t, testCtx) }) cs := testCtx.ClientSet nsName := testCtx.NS.Name </ins> var err error var preemptor *v1.Pod <del> for _, nodeConf := range test.nodes { _, err := createNode(cs, st.MakeNode().Name(nodeConf.name).Capacity(nodeConf.res).Obj()) </del> <ins> for _, nodeName := range test.nodeNames { _, err := createNode(cs, st.MakeNode().Name(nodeName).Capacity(defaultNodeRes).Obj()) </ins> if err != nil { <del> t.Fatalf("Error creating node %v: %v", nodeConf.name, err) </del> <ins> t.Fatalf("Error creating node %v: %v", nodeName, err) </ins> } } pods := make([]*v1.Pod, len(test.existingPods)) // Create and run existingPods. for i, p := range test.existingPods { <ins> p.Namespace = nsName </ins> pods[i], err = runPausePod(cs, p) if err != nil { t.Fatalf("Error running pause pod: %v", err) } } <ins> test.pod.Namespace = nsName </ins> preemptor, err = createPausePod(cs, test.pod) if err != nil { t.Errorf("Error while creating high priority pod: %v", err)

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Integration tests are sometimes flaking locally: PreferNominatedNode Once the node gets deleted, the nodelifecycle controller is racing to update pod status and the pod deletion logic is failing causing tests to flake. Ultimately, we call testCtx.CleanUp() which cleans the nodes and the pods involved the test namespace so we are not going to leak any resources. links to appreciated links to specific failures in spyglass appreciated <!-- You can identify the SIG from the "prowjobconfigurl" on the testgrid dashboard for a test --/sig scheduling <!-- Please see the deflaking doc () for more guidance! --/assign
cc Tried addressing it via
/triage accepted thanks!
Change:
batchclient "k8s.io/kubernetes/pkg/client/clientset_generated/internalclientset/typed/batch/internalversion" coreclient "k8s.io/kubernetes/pkg/client/clientset_generated/internalclientset/typed/core/internalversion" extensionsclient "k8s.io/kubernetes/pkg/client/clientset_generated/internalclientset/typed/extensions/internalversion" <del> "k8s.io/kubernetes/pkg/controller" </del> deploymentutil "k8s.io/kubernetes/pkg/controller/deployment/util" "k8s.io/kubernetes/pkg/util" )

Discussion:
StatefulSet now as of 1.6. That means the TODO on can be fixed in 1.7. We could not fix it in 1.6 because that code is used by kubectl, which must work against servers that are one minor version ahead of or behind the client.
/cc
I am volunteered to take this job if no one start working on this.
I don't think anyone's working on it, so you are welcome to take it. Feel free to tag me as a reviewer. Thanks!
Change:
Server-side support: <del> Only finishing v1beta3 is a requirement for 1.0. The others are strong nice-to-haves. 1. Finish v1beta3 </del> 1. Default selectors from labels [#1698](https://github.com/GoogleCloudPlatform/kubernetes/issues/1698#issuecomment-71048278) <del> 1. List supported resources [#2057](https://github.com/GoogleCloudPlatform/kubernetes/issues/2057) </del> 1. Stop [#1535](https://github.com/GoogleCloudPlatform/kubernetes/issues/1535) 1. Deleted objects [#2789](https://github.com/GoogleCloudPlatform/kubernetes/issues/2789) 1. Clone [#170](https://github.com/GoogleCloudPlatform/kubernetes/issues/170) 1. Resize [#1629](https://github.com/GoogleCloudPlatform/kubernetes/issues/1629) 1. Useful /operations API: wait for finalization/reification <del> 1. Readiness [#620](https://github.com/GoogleCloudPlatform/kubernetes/issues/620) </del> <ins> 1. List supported resources [#2057](https://github.com/GoogleCloudPlatform/kubernetes/issues/2057) </ins> 1. Reverse label lookup [#1348](https://github.com/GoogleCloudPlatform/kubernetes/issues/1348) 1. Field selection [#1362](https://github.com/GoogleCloudPlatform/kubernetes/issues/1362) 1. Field filtering [#1459](https://github.com/GoogleCloudPlatform/kubernetes/issues/1459)

Discussion:
Simple version is done, more complex version needs work. Done, now that readiness corresponds to Running and is tracked by Kubelet status if the readiness hook is set? Done Done Do we want to do a more generic one or a less generic one? OpenShift was looking more at specific topical plugin commands ("add-volume", "set-default-resources"), but not sure how much hand-holding users need. Getting close. Exec has landed and is a replacement for ssh Attach on start remains hard. Implemented
I/we should also file issues for outstanding items without issues, and add lines for newly filed issues (e.g., command flag for run-container). Readiness is not yet used by rollingupdate. With respect to patch on the command line: I was thinking of a generic mechanism, but I could see the case for domain-aware commands, also. I think we need to better factor the command code and library code, and generic functionality vs. domain-aware functionality. Neither should ever convert to the internal representation. Domain-aware functionality (e.g., describe) should target a specific API version. Configuration generators, such as run-container, should be provided as services, or at least as separate plugin commands.
ref
ref
ref
ref
ref
ref
Change:
policyapiv1beta1.SchemeGroupVersion, rbacv1.SchemeGroupVersion, rbacv1beta1.SchemeGroupVersion, <del> // Don't copy this pattern. We enable rbac/v1alpha1 and settings/v1laph1 // by default only because they were enabled in previous releases. // See https://github.com/kubernetes/kubernetes/pull/47690. // TODO: disable rbac/v1alpha1 and settings/v1alpha1 by default in 1.8 rbacv1alpha1.SchemeGroupVersion, settingv1alpha1.SchemeGroupVersion, schedulingapiv1alpha1.SchemeGroupVersion, </del> storageapiv1.SchemeGroupVersion, storageapiv1beta1.SchemeGroupVersion, certificatesapiv1beta1.SchemeGroupVersion,

Discussion:
Need to follow-up on and i assigned it to you because turning off settings/v1alpha1 requires some changes in the tests.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig api-machinery
/assign
did you mean I should add a priority label?
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/api-machinery: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</a</details
Change:
protocol: protocol, } if proxier.portsMap[lp] != nil { <del> newLocalPorts[lp] = proxier.portsMap[lp] </del> <ins> glog.V(4).Infof("Port %s was open before and is still needed", lp.String()) replacementPortsMap[lp] = proxier.portsMap[lp] </ins> } else { socket, err := openLocalPort(&lp) if err != nil { glog.Errorf("can't open %s, skipping this nodePort: %v", lp.String(), err) continue } <del> newLocalPorts[lp] = socket </del> <ins> replacementPortsMap[lp] = socket </ins> } // We're holding the port, so it's OK to install iptables rules. args := []string{

Discussion:
The symptom is the nodeport service is accessible thru hostip:hostport. But the port on host is not occupied. This is exposed by e2e on kubenet. I noticed in the kube- Kube-proxy did open the port. But later, kube-proxy closed the ports upon iptables-restore failure. It never reopen the ports. Hence causing the e2e failure. The code section in question: Not sure why failed. Error messge is not helpful since line 139 is ref:
Also of interest: did it exit with 1? This should be clear from the iptables commands it executed before the commit, which are hopefully in the logs (can you post them). If it's something like a non-exist chain, we should fix that. we retry on exit 1? Handwaving without looking at code: I'd expect something to get requeued, and to reinvoke syncProxyRules once again, in a time frame << test timeout.
Yeah, what was line 139 in the restore output? , Prashanth B wrote:
is No retry though. It is going to catch up in the next sync. So I think no retry for is needed.
FYI Jenkins job:
That iptables restore is 139 lines long, so it's unhappy about the last line? can you hunt ths? , Minhan Xia wrote:
The next sync is whenver the next service/endpoint changes right? Errors during the sync should cause an immediate retry of sync, preferably with backoff. If a service or endpoint never changes we should still recover. Yes we should hunt down the bad line, but it's not the last one right? COMMIT will fail if eg: Even though it's obviously not commit but the tcp/upd thing.
iptables resyncs every 30s, not ideal but in this case I don't expect that to fix the error I meant that we need to root cause it :) , Prashanth B wrote:
But in this case, iptables-restore is going to complain . Not line 2
Hmm
I manually restored the 139 lines above it worked fine - no errors. Even more curious. , Prashanth B wrote:
I also tried to execute the same sequence of iptables-restore. It worked. No errors.

Was this a one-time thing? Were there any other changes in your git repo? , Minhan Xia wrote:
This happened in kubenet suite. Only difference is . I looked at a few runs where e2e failed. This happened 3-4 times over the whole test, but not consecutively. In all-passed runs I checked, this never happened (Maybe I am lucky).
Of , Minhan Xia wrote:
Change:
if err != nil { t.Errorf("Failed to get ipvs services, err: %v", err) } <del> if len(services) != 3 { t.Errorf("Expect 3 ipvs services, got %d", len(services)) </del> <ins> if len(services) != 4 { t.Errorf("Expect 4 ipvs services, got %d", len(services)) </ins> } found := false for _, svc := range services {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? /kind bug What happened: In ipvs proxy mode, most service functions like "nodeport/loadbalance" is realized by the association of iptables/ipset/ipvs, yet most ipvs proxier ut only verified ipvs rules, which can't ensure service is functional. What you expected to happen: Check both ipvs rules and iptables chains/rules, ipset entries in ipvsproxier ut.
/sig network /area ipvs /assign
What's the current UT coverage number?
Current is 50.2%.
So, can we achieve 70%?
Yeah, we can do that, and that's definitely necessary.
Change:
import ( "fmt" "net/http" <del> "time" </del> "k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/util/sets"

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /priority failing-test /sig network What happened: From https://k8s-, seems to be broken right after they were by Example error message: and Anything else we need to know?: Is it as expected?
Oct 11 16:37:49.106: test session affinity, cost time: 1m31.742990485s This is a mistake. Sorry for my debug lines sneak in. I was just wondering why this test case doesn't run in upstream CI, so I this debug line. Now, I see because this test case only runs in . Oct 11 16:39:42.406: Expect endpoints: map[], got: map[netserver-1:{}] This check failed unexpectedly, let me try to find out why. I am working on it and will let you know soon when I have some updates.
Thanks. These two tests don't run on pull jobs as they are marked as , though https://k8s-, https://k8s- (and other CIs that include ) would have them running.
Do you mean when I raise a PR, these test cases will not be triggered? My question is how can I make sure my follow-up PR can fix this bug? Where can I access the log message when I raise a new PR?
Can I see the updated test results via directly visiting https://k8s-, https://k8s-
Yep, that is the current behavior. A hacky way to make it run on PR --- add a temporary commit to remove the word from test name so some pull jobs ( I think?) will run it. And you could view logs by clicking the button.
Nope, this CI only includes changes that are merged. It is basically a cronjob that runs tests against head.
Change:
}, ServiceNodePortRange: kubeoptions.DefaultServiceNodePortRange, } <ins> s.ServiceClusterIPRange = kubeoptions.DefaultServiceIPCIDR </ins> // Overwrite the default for storage data format. s.Etcd.DefaultStorageMediaType = "application/vnd.kubernetes.protobuf"

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: There is currently no easy way to know what Kubernetes is using as the default CIDR for service cluster IPs. What you expected to happen: should be able to tell users that "10.0.0.0/24" is used as the default. They'd better check if their deployment environment has a conflict with this assumption. They need to customize this parameter to avoid such overlaps if any. How to reproduce it (as minimally and precisely as possible): Run , from the help, the default value for --service-cluster-ip-range is not mentioned. Anything else we need to know?: No. Environment: Kubernetes version (use ): Any Cloud provider or hardware configuration**: Any OS (e.g. from /etc/os-release): Any Kernel (e.g. ): Any Install tools: N/A Others: N/A
/sig api-machinery
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Change:
genericapiserver "k8s.io/apiserver/pkg/server" "k8s.io/apiserver/pkg/storage/storagebackend" clientset "k8s.io/client-go/kubernetes" <del> kclient "k8s.io/client-go/kubernetes" </del> restclient "k8s.io/client-go/rest" "k8s.io/client-go/tools/clientcmd" clientcmdapi "k8s.io/client-go/tools/clientcmd/api"

Discussion:
Seeing a variety of failures Address already in use failures https://k8s- Stack traces: https://k8s- https://k8s- Creation errors: https://k8s-
cc
Here's another false negative in TestEtcdStoragePath: https://k8s-
Change:
package config import ( <ins> "fmt" </ins> "github.com/spf13/pflag" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" )

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: When use remote container runtime, the remote can't get any PodSandboxImage config set by kubelet What you expected to happen: We want the all container runtime should know what's right PodSandboxImage How to reproduce it (as minimally and precisely as possible): in new node with into k8s cluster kubelet with options expect frakti can create sandbox container with , but get default (k8s version: v1.8.2) Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: bootstrap by kubeadm v1.8.2 OS (e.g. from /etc/os-release): Debian GNU/Linux 9 (stretch) Kernel (e.g. ): SMP Debian 4.9.30-2+deb9u2 (2017-06-26) x8664 GNU/Linux Install tools: kubeadm Others:
/sig node
good news! thanks!
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Actually we do a no-op when the container runtime is . This is why config can not be set by flag for . In your case, the correct place to change the default sandbox image is in .