jiebi/CodeConvo huggingface dataset:
Change:
assert.Nil(t, err, "unexpected error in NewProxyServer, addr: %s", addr) assert.NotNil(t, proxyserver, "nil proxy server obj, addr: %s", addr) assert.NotNil(t, proxyserver.IptInterface, "nil iptables intf, addr: %s", addr) <ins> assert.True(t, proxyserver.CleanupAndExit, "false CleanupAndExit, addr: %s", addr) </ins> // Clean up config for next test case configz.Delete("componentconfig")

Discussion:
<!-- 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?: bug What happened: Got panic after running: Panic: What you expected to happen: No panic and exit successfully. How to reproduce it (as minimally and precisely as possible): Run the following command on both CoreOS v1298.7.0(bare metal) and Ubuntu 16.04.2 LTS(OpenStack) Happened with the following versions: v1.7.0-alpha.3 v1.7.0-alpha.4 v1.7.0-beta.0 v1.7.0-beta.1 v1.7.0-beta.2 v1.7.0-rc.1 v1.8.0-alpha.0 v1.8.0-alpha.1 Anything else we need to know?: I guess it caused by . Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Both CoreOS v1298.7.0(bare metal) and Ubuntu 16.04.2 LTS(OpenStack) Kernel (e.g. ): CoreOS v1298.7.0: Linux node- 4.9.16-coreos-r1 SMP Tue Apr 4 19:09:38 UTC 2017 x8664 Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz GenuineIntel GNU/Linux Ubuntu 16.04.2 LTS: Linux ubuntu- 4.4.0-62-generic -Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: Others:
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig network /area kube-proxy
/cc
cc/ Looks like there is a new regression in v1.7. Please triage this to decide if it is a release blocker. If not, please provide the workaround for the users. Thanks!

cc/
Digging into the code, will send a PR.
PR sent. Folks review it please.
Added the release-blocker label. We got a PR for it very fast so it won't delay the release anyway, thanks
Change:
deps = [ "//vendor:github.com/davecgh/go-spew/spew", "//vendor:github.com/ghodss/yaml", <ins> "//vendor:k8s.io/apimachinery/pkg/runtime", </ins> "//vendor:k8s.io/apimachinery/pkg/util/mergepatch", ], )

Discussion:
Extracted from The RawExtension type allows an API object to inline arbitrary JSON. strategicpatch.CreateTwoWayMergePatch returns an error trying to map that inlined JSON to struct fields. It should be able to compute a patch for an object containing a field of that type.
cc
We need to decide what strategic merge patch should do in the following scenarios: unknown fields (can be encountered when the API or a user-defined object has a new field the compiled-in struct doesn't have yet) unmergeable fields (like RawExtension) cc
The current behavior is: unknown fields: trying to merge a unknown field will fail when lookup the metadata in the struct tags unmergeable fields: will be replaced as raw byte array Maybe we can use generic json merge for unmergeable fields?
Did that change since 1.5? In 1.5, we were getting an error during patch computation for objects with a RawExtension field
Sorry. This behavior is in 1.4.7. e.g . It will error in 1.5.
Yeah, the field gets replaced. Even in 1.4.7, an unknown field (like initcontainers in pods) or an object including a RawExtension (anything with a field of type or ) would error
My personal favor would be to instruct the patch to ignore such field, seems the cleanest approach to me. Similarly to how we allow annotating deletion and merging.
wouldn't it be confusing to submit a patch with stuff in that field, have the patch accepted, and have none of your submitted changes take effect? seems like the least surprising thing would be to treat struct fields like or as
How about both, iow. having as a default and as an opt-in. This would allow the resource author to decide how his resource should be treated. Eventually on we could return the ignored fields. Having said that we could start with right away. I think I could work on a patch implementing that if majority agrees (
I think is a good place to start when computing/applying patches for known struct fields like RawExtension. I'll open a separate issue for client-side handling of computing patches for unknown fields
Ignore the field sounds like a really good solution. WDYT of printing a warning to stdeer?
what does ignoring instead of replacing get us?
Sorry I was reading the comment on my phone between other things. Ignore my comment.
Change:
} func (c *cephFSDriver) CreateDriver() { <del> // Reset config. It might have been modified by a previous CreateVolume call. c.driverInfo.Config.ServerConfig = nil </del> } func (c *cephFSDriver) CleanupDriver() {

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: gce/gke multizone/regional jobs Which test(s) are failing: Only PD tests Since when has it been failing: Around 12/21 with the 16:49 run Testgrid link: https://k8s- Reason for failure: TBD Anything else we need to know: <!-- DO NOT EDIT BELOW THIS LINE --/kind failing-test
The runs started flaking after merged. cc Here's one failing run: Pod pod-subpath-test-gcepd-dynamicpv-pfsm failed to schedule because of conflicting node selectors: We shouldn't need to set the node selector for PD tests using PVs.
The PR broke the subpath test because the modification to the config struct embedded in the driver info now persists across tests: A quick fix would be to reset that field in CreateDriver. The long-term fix is the change discussed in My preference is to do the quick fix now, then either merge or close PRs in this order: (needs a decision about logging of tests that aren't getting defined, see ) a future PR for What I'd like to avoid is having to rebase PR on top of the long-term solution for issue - that'll be lots of code conflicts.
/assign PR is here: PR
Change:
} } } <del> delete(plugin.podCIDRs, id) glog.V(3).Infof("Calling cni plugins to remove container from network with cni runtime: %+v", rt) if err := plugin.cniConfig.DelNetwork(plugin.netConfig, rt); err != nil { return fmt.Errorf("Error removing container from network: %v", err) </del> <ins> if err = plugin.delContainerFromNetwork(id, rt); err != nil { return err </ins> } return nil

Discussion:
I gathered e2e test results of suite for last 100 runs. The following is the list of flaky tests. Some might not be related to . I will start with the service tests. Any help would be appreciated. Detail list: Jenkins project:
cc/ Cluster team is working on to make kubenet default. Once we switch this to production, we don't need to restart docker to configure cbr0.
After a bunch of PRs got merged, the kubenet suite is much more stable. One more known flake can be fixed by I will post new flake tests here.
Just bump into a new failure: One of the nodes () got panic: Looks like it crashed at shaper reset.: Can you take a look?
Change:
} // Wrap EmptyDir, let it do the setup. <del> wrapped, err := b.plugin.host.NewWrapperMounter(b.volName, wrappedVolumeSpec, &b.pod, b.opts) </del> <ins> wrapped, err := b.plugin.host.NewWrapperMounter(b.volName, wrappedVolumeSpec(), &b.pod, b.opts) </ins> if err != nil { return err }

Discussion:
Data as of June 3rd, 9:00 PM Eastern. Latest data can be found here: Prow link to the 2 jobs: * Additional Context:
/sig storage cc
I'm working on , it's hard to get a job yaml right at the first time. I'll check iscsi. /assign
/triage accepted /kind failing-test
ci-kubernetes-e2e-storage-kind-disruptive fixed: has 1 green run pull-kubernetes-e2e-storage-kind-disruptive fixed: , it fails when it should fail, it's green otherwise, I'll continue with iscsi.
/reopen it's still red, but at least it installs now:
Reopened this issue. <detailsIn response to : /reopen it's still red, but at least it installs now: 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
e2e-gce-iscsi-serial job passes now: e2e-gce-iscsi is getting greener: I'll let it run for few more days to see if today's failures are flakes. /reopen
Reopened this issue. <detailsIn response to : It's getting greener: /reopen </details
iscsi-serial is green:
Change:
switch label { case "name": fallthrough <del> case "Status.Phase": </del> <ins> case "status.phase": </ins> fallthrough <del> case "Status.Host": </del> <ins> case "status.host": </ins> return label, value, nil default: return "", "", fmt.Errorf("field label not supported: %s", label)

Discussion:
We use capitals for Pod fields (ex: Status.Host) and camelCase for Event fields (ex: involvedObject.resourceVersion). We should be consistent. Should it be capitals? camelCase? Or should we be case insensitive?
IMO, we should use camelCase for pod fields, to match the way it's serialized in JSON.
I agree with The goal here is to be consistent with the API, not with the internal Go representation.
I'd like to fix this before v1beta3 is cast in stone.
ok. Event field selectors are correct then. I will update the selectors for pods to make them camelCase.
I am wondering if I should change this only for v1beta3 or for 1 and 2 as well? This will be a breaking change for beta1 and 2 if we decide to do that.
v1beta3 only, though that's hard, we should reconsider. We're contemplating another "breakage day", and I doubt this is widely used.
Change:
kube::build::run_build_command make test-integration fi <ins> kube::build::copy_output </ins> if [[ "${FEDERATION:-}" == "true" ]];then ( source "${KUBE_ROOT}/build/util.sh"

Discussion:
It fails with: cc
Looking at the generated I see that FEDERATIONIMAGETAG is "" which is resulting in this error. I see that before , FEDERATIONIMAGETAG was being set to but that docker tag file does not exist for hyperkube. I see the following exist in my : but does not exist there. Trying to figure out why.
cc
make sure you are running the scripts with env var exported. That is what controls whether gets created.
With , we are not generating the federation-apiserver binary and instead using the hyperkube binary.
sorry, i copied the wrong line. The droid you're looking for: File conditionally written during process File consumed when templating federation control plane yaml
Right. My is also empty. I am trying to run federation e2e tests. The command I am running is: which is what I have always used. I guess something changed in
that should definitely work. Please and then run the step, capture the output and email to me? I was literally doing exactly this process for another PR today, and I verified the image tag file was getting written correctly as well.
I figured out this is happening because after make clean or a fresh clone, kubectl will not be available when we are trying to get the semanticimagetag_version() in here.
Awesome! Thanks
Change:
} func TestWithMaxWaitRateLimiter(t *testing.T) { <del> limiter := NewWithMaxWaitRateLimiter(DefaultControllerRateLimiter(), 500*time.Second) </del> <ins> limiter := NewWithMaxWaitRateLimiter(NewStepRateLimiter(5*time.Millisecond, 1000*time.Second, 100), 500*time.Second) </ins> for i := 0; i < 100; i++ { if e, a := 5*time.Millisecond, limiter.When(i); e != a { <del> t.Errorf("expected %v, got %v", e, a) </del> <ins> t.Errorf("expected %v, got %v ", e, a) </ins> } } <del> for i := 100; i < 5100; i++ { if e, a := 500*time.Second, limiter.When(i); e < a { </del> <ins> for i := 100; i < 200; i++ { if e, a := 500*time.Second, limiter.When(i); e != a { </ins> t.Errorf("expected %v, got %v", e, a) } } <ins> } </ins> <del> for i := 5100; i < 5200; i++ { if e, a := 500*time.Second, limiter.When(i); e != a { t.Errorf("expected %v, got %v", e, a) } </del> <ins> var _ RateLimiter = &StepRateLimiter{} func NewStepRateLimiter(baseDelay time.Duration, maxDelay time.Duration, threshold int) RateLimiter { return &StepRateLimiter{ baseDelay: baseDelay, maxDelay:  maxDelay, threshold: threshold, } } type StepRateLimiter struct { count     int threshold int baseDelay time.Duration maxDelay  time.Duration } func (r *StepRateLimiter) When(item interface{}) time.Duration { r.count += 1 if r.count <= r.threshold { return r.baseDelay </ins> } <ins> return r.maxDelay } func (r *StepRateLimiter) NumRequeues(item interface{}) int { return 0 } func (r *StepRateLimiter) Forget(item interface{}) { </ins> }

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --The unit test which was recently is flaking Sample failure error trace Full test report can be found The test is flaking because of the time mismatch in a condition and its observed that the while the control arrives some times its few milliseconds(8m19.997445973s) lesser than the expected time(8m20s) <!-- You can identify the SIG from the "prowjobconfigurl" on the testgrid dashboard for a test --
/assign
/sig api-machinery /kind flake A flake according to the job history: https://prow.ppc64le-
/cc who got the PR assigned /triage accepted
Change:
_ "k8s.io/kubernetes/pkg/api/v1" _ "k8s.io/kubernetes/pkg/apis/extensions" _ "k8s.io/kubernetes/pkg/apis/extensions/v1beta1" <del> pkg_runtime "k8s.io/kubernetes/pkg/runtime" </del> <ins> kruntime "k8s.io/kubernetes/pkg/runtime" </ins> "k8s.io/kubernetes/pkg/util/sets" "github.com/golang/glog"

Discussion:
Forked from pointed out that all package names should be lower case, no under_scores or mixedCaps. The same rule applies to renaming imported packages. () generated a list of mixedCaps package names in our codebase: I will upload a PR later to rename kubeletTypes to kubetypes, and the rest is up for grabs.
sorry i have not saw this issue as i open a similar one(), do you mind i participate in this issue? i would happy to do some work for this. best regards.
of course, fixes are welcome. Thanks for picking up on this! We'll try to expedite the review and merge process of such PRs to avoid a lot of churns, but chances are that some rebases are needed :)
ok, i will send some fix sonner, and tag you for review. thanks again.
Not done:
Change:
epCount := len(config.EndpointPods) config.MaxTries = epCount*epCount + testTries <ins> framework.Logf("Setting MaxTries for pod polling to %v for networking test based on endpoint count %v", config.MaxTries, epCount) </ins> } // setup includes setupCore and also sets up services

Discussion:
What would you like to be : Right now we poll one node at a time for intra-pod tests. We ultimately fail a test if any one node is unreachable. If we instead polled all nodes, multiple times, and collected the number of times a node was unreachable, this would tell us what % of nodes on the cluster were broken, rather then just telling us the first node that was broken. not break the testing contract (were still verifying intra-pod connectivity, just doing so in a way that gives us holistic cluster info) Why is this needed: I described why this would make triage alot easier, and in general make it easier to see why tests are failing, here ... i'll collect a little more data on this to justify the decision .... as this is a conformance test so the bar for modification is higher (even if the test itself isnt changing) then regular tests.
/sig network
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Change:
} // getContainersToDeleteInPod returns the exited containers in a pod whose name matches the name inferred from exitedContainerID, ordered by the creation time from the latest to the earliest. <del> func (p *podContainerDeletor) getContainersToDeleteInPod(exitedContainerID string, podStatus *kubecontainer.PodStatus) containerStatusbyCreatedList { </del> <ins> func getContainersToDeleteInPod(exitedContainerID string, podStatus *kubecontainer.PodStatus, containersToKeep int) containerStatusbyCreatedList { </ins> var matchedContainer *kubecontainer.ContainerStatus var exitedContainers []*kubecontainer.ContainerStatus // Find all exited containers in the pod

Discussion:
Kubelet evicts pods whenever there is memory or disk pressure. It marks the pods as to evict them. To help with reducing disk pressure, kubelet should delete all containers belonging to pods right away. This will result in loss of logs. In the future, we can copy out logs from dead containers before deleting them. Logs can be rotated separately from dead containers. IMO, this feature is required for disk usage based evictions to work reliably in kubelet.
Change:
} } <ins> // ensureBridgeTxQueueLen() ensures that the bridge interface's TX queue // length is greater than zero.  Due to a CNI <= 0.3.0 'bridge' plugin bug, // the bridge is initially created with a TX queue length of 0, which gets // used as the packet limit for FIFO traffic shapers, which drops packets. // TODO: remove when we can depend on a fixed CNI func (plugin *kubenetNetworkPlugin) ensureBridgeTxQueueLen() { bridge, err := netlink.LinkByName(BridgeName) if err != nil { return } if bridge.Attrs().TxQLen > 0 { return } req := nl.NewNetlinkRequest(syscall.RTM_NEWLINK, syscall.NLM_F_ACK) msg := nl.NewIfInfomsg(syscall.AF_UNSPEC) req.AddData(msg) nameData := nl.NewRtAttr(syscall.IFLA_IFNAME, nl.ZeroTerminated(BridgeName)) req.AddData(nameData) qlen := nl.NewRtAttr(syscall.IFLA_TXQLEN, nl.Uint32Attr(1000)) req.AddData(qlen) _, err = req.Execute(syscall.NETLINK_ROUTE, 0) if err != nil { glog.V(5).Infof("Failed to set bridge tx queue length: %v", err) } } </ins> func (plugin *kubenetNetworkPlugin) Name() string { return KubenetPluginName }

Discussion:
I'm not sure where the defaults come from but they sometimes drop all packets causing container IPs to become unreachable. ARP fails. I'm not sure if this is related but I also noticed on this machine that the default pfifo qdisc drops all packets. pfifo is the default qdisc for an htb node so it's used in the unconfigured htb qdisc: This is because the default value for queue size is zero. On other machines I've seen the default value set to 1 packet and 1000 packets. When I set the limit explicitly the container becomes reachable again. The broken configuration is applied by kubelet to implement traffic shapping and there is no option to turn this off. This patch fixes the kubelet on broken machines by disabling traffic shapping: cc
does this happen with --configure-cbr0 and packet shaping too? The kubenet implementation just uses the existing kubernetes shaping code that --configure-cbr0 does.
It seems the *fifo qdiscs default their packet limit to the txquelen of the interface (man tc-pfifo). It also seems most virtual interface types (bridge, etc) set a dev-txqueuelen of 0. It further seems that relies on the default packet limit. I could swear this worked before with kubenet, and it must have worked with --configure-cbr0 when the code was originally . I'll check around to figure out what the default limit should be for interfaces that don't specify a tx queue length.
Note that to test with --configure-cbr0 you'd also need --reconcile-cidr.
Upstream CNI fix is here: and we'll also work around it in kubenet for now.
FWIW, the upstream CNI fix got merged for CNI 0.3.0
Change:
"k8s.io/client-go/util/workqueue" "k8s.io/kubernetes/pkg/printers" <ins> utilversion "k8s.io/kubernetes/pkg/util/version" </ins> "k8s.io/kubernetes/test/e2e/framework" imageutils "k8s.io/kubernetes/test/utils/image" ) <ins> var serverPrintVersion = utilversion.MustParseSemantic("v1.10.0") </ins> var _ = SIGDescribe("Servers with support for Table transformation", func() { f := framework.NewDefaultFramework("tables") <ins> BeforeEach(func() { framework.SkipUnlessServerVersionGTE(serverPrintVersion, f.ClientSet.Discovery()) }) </ins> It("should return pod details", func() { ns := f.Namespace.Name c := f.ClientSet

Discussion:
the tests are failing in http://k8s- /sig sig-api-machinery /priority failing-test /priority critical-urgent /kind bug /status approved-for-milestone /milestone v1.10 cc /assign
The provided milestone is not valid for this repository. Here are the available milestones: 1.clear 1.v1.6 1.v1.13 1.v1.10 1.v1.11 1.v1.8 1.v1.4 1.v1.5 1.v1.12 1.next-candidate 1.v1.9 1.v1.7 <detailsIn response to : the tests are failing in http://k8s- /priority failing-test /priority critical-urgent /kind bug /status approved-for-milestone /milestone v1.10 /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
xref
/sig api-machinery
/assign /assign
The three tests in should be run only on 1.10+ servers. I'm just putting a PR together, should be up within next hour or so.
Master fix is in .
/reopen still failing in upgrade tests: http://k8s- the 1.9 e2e tests are checking alpha response types that don't exist any more in 1.10 requires changing 1.9 to not test these alpha features in 1.10 that dropped support for those alpha features
you can't re-open an issue/PR unless you authored it or you are assigned to it. <detailsIn response to : /reopen still failing in upgrade tests: http://k8s- 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
Is there anyone from that can look into this?
looking into this
/status in-progress
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed.

: Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
fixed by