jiebi/CodeConvo huggingface dataset:
Change:
} } <ins> func TestNonRacyShutdown(t *testing.T) { // Attempt to simulate previously racy conditions, and ensure that no race // occurs: Nominally, calling "Eventf" *followed by* shutdown from the same // thread should be a safe operation, but it's not if we launch recorder.Action // in a goroutine. caster := NewBroadcasterForTests(0) clock := clock.NewFakeClock(time.Now()) recorder := recorderWithFakeClock(v1.EventSource{Component: "eventTest"}, caster, clock) var wg sync.WaitGroup wg.Add(100) for i := 0; i < 100; i++ { go func() { defer wg.Done() recorder.Eventf(&v1.ObjectReference{}, v1.EventTypeNormal, "Started", "blah") }() } wg.Wait() caster.Shutdown() } </ins> func TestEventf(t *testing.T) { testPod := &v1.Pod{ ObjectMeta: metav1.ObjectMeta{

Discussion:
The standard event recorder, when recording an event, calls the underlying Broadcaster in a goroutine, so that even recording is non-blocking. Things like leader election emit events over the course of their lifecycle via this broadcaster. Consider the following scenario: GR1: spawn leader election ----GR2 GR2: Leader election: emit event "Lease Acquired" ----spawn GR3 () GR1: Shutdown leader election ----blocks until GR2 is done GR1: Shutdown broadcaster --() GR3: ----send on closed channel () Practically, we've observed this behavior popping up occaisionally in tests in controller-runtime:
/sig api-machinery /kind bug
<details<summaryrelevant race detector output/stack traces</summary</details
were you planning on sending a fix, or need our help to send one to fix it?
I can probably try to figure out a fix if you want, but the whole model for how event broadcasters currently work is inverse to how Go suggests you manage channels (only writers should ever close channels, not readers). I'll need to do a bit of playing around with things.
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
/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
cc
I think this is fixed by . Please reopen if it's not the case.
/triage accepted
Would be possible to cherry-pick this fix in 1.20?
Change:
log-wrap 'CreateDirs' create-dirs log-wrap 'EnsureLocalSSDs' ensure-local-ssds log-wrap 'SetupKubeletDir' setup-kubelet-dir <ins> log-wrap 'SetupJournald' setup-journald </ins> log-wrap 'SetupLogrotate' setup-logrotate if [[ "${KUBERNETES_MASTER:-}" == "true" ]]; then log-wrap 'MountMasterPD' mount-master-pd

Discussion:
Example using a random PR for , take a look at: in this set of logs, at least 4 files are empty kube-container-runtime- kube-node- kube- kubelet- The reason tracked down using was that the journald configuration was defaulting to something that wipes the logs quickly!
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
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
Change:
// checkHostPortConflicts checks for colliding Port.HostPort values across // a slice of containers. func checkHostPortConflicts(containers []api.Container) errs.ValidationErrorList { <del> allPorts := map[int]bool{} return AccumulateUniquePorts(containers, allPorts, func(p *api.ContainerPort) int { return p.HostPort }) </del> <ins> allPorts := util.StringSet{} return AccumulateUniqueHostPorts(containers, &allPorts) </ins> } func validateExecAction(exec *api.ExecAction) errs.ValidationErrorList {

Discussion:
Pods which use to bind both TCP and UDP sockets to the same port number are rejected with the error: An example pod follows.
Looks like we don't check protocol
The issue was discussed before in , which was closed due to it being low priority.
Hmm, that's 2 pods and the scheduler, this is 2 containers in the same pod and validation at create time. Maybe we should just be more clear about where we stand with hostPort.
Posting here what I posted in the other bug: This can't be worked around when running NFS from a pod. Linux does not allow the NFS port (2049) to be changed, and the Portmap port (111) also cannot be changed. Additionally, you can't separate the UDP from the TCP ports.
Why does NFS need host ports? , Russell Harmon wrote:
Fix is in , Tim Hockin wrote:
Change:
package azure import ( <del> "fmt" </del> "net/http" "strings"

Discussion:
What happened: made sure that API calls to Azure that return a HTTP code 200 with an embedded error are retried. Nevertheless, we observe a series of errors during the Azure Disk detach backoff while calling , and the detach operation is immediately cancelled. Happy scenario: the disk is to be re-attached to the same VM. The reconciler's will update the VMSS instance and the previous detach error will be masked. It takes 15 min for the detach call to timeout but the disk will eventually get re-attached after several VMSS updates (). Not-so-happy scenario: the disk is to be re-attached to another VM. The same errors as in will be thrown indefinitely. controller-manager's logs: What you expected to happen: The backoff succeeds and the failed detach operation gets retried. How to reproduce it: A single Pod with a single Azure Disk. This seems quite hard to reproduce, but it is happening consistently in one of our customer's resource group (eastus). Anything else we need to know?: Environment: Kubernetes version: branch (kubernetes/kubernetes Cloud provider: Azure (via AKS-Engine) OS: Ubuntu 16.04.6 LTS Kernel: 4.15.0-1042-azure Install tools: Network plugin and version: Others: /sig azure paging
/assign
Change:
// schedulable. Won't have any effect if register-node is false. // DEPRECATED: use registerWithTaints instead RegisterSchedulable bool <del> // RequireKubeConfig is deprecated! A valid KubeConfig is now required if --kubeconfig is provided. RequireKubeConfig bool </del> // nonMasqueradeCIDR configures masquerading: traffic to IPs outside this range will use IP masquerade. NonMasqueradeCIDR string // This flag, if set, instructs the kubelet to keep volumes from terminated pods mounted to the node.

Discussion:
This will be the end of the deprecation period for --require-kubeconfig.
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 .
ref
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
Change:
volumeMounts: - name: config mountPath: /etc/config <ins> nodeSelector: beta.kubernetes.io/masq-agent-ds-ready: "true" </ins> volumes: - name: config configMap:

Discussion:
https://k8s- is failing to run the follow up e2es because the ip-masq-agent daemonset is scheduling pods that get stuck in a pending state on 1.5 nodes. This short-circuits the logic for the skewed e2es, and they never run. from https://k8s-
So I see that in 1.7.0 we start setting the non-masq-cidr to 0/0 gce/config-"0.0.0.0/0" We set the addon if non-masq-cidr is 0/0 if [[ "${NONMASQUERADECIDR:-}" == "0.0.0.0/0" ]]; then setup-addon-manifests "addons" "ip-masq-agent" fi Also the agent cannot run on nodes prior to 1.7 so this seems to be correct. Once the nodes are upgraded to 1.7 then the ip-masq agent should be running and should get out of the pending state. I think this is just a general problem with the way addons are handled. I may want to enable a new addon when a master is upgraded to 1.7 by default. That addon may be a DaemonSet that wants to run on nodes meeting a certain criteria. That criteria may not be met in 1.5 but may be met when they are updated to 1.7. A few things that come to mind to fix this: -Fix the test's expectations to allow this until the nodes are updated to 1.7. -rollback the PR that made this the default: -set NONMASQUERADECIDR=10.0.0.0/8 in the test properties so that the ip-masq-agent doesn't get .
It seems like the most conservative way forward is to revert the PR (). Customers who want to use the feature can set the variable () during to be able to get the feature. What do you guys think?
I think I asked the similar question related to ip-masq-agent, but my question was dropped. At this stage, I think reverting the preferred fix.

ip-masq-agent was a daemonset introduced in 1.7 which I questioned at The problem is that after master is upgraded to 1.7, addons is trying to schedule ip-masq-agent daemonset to every node no matter which Kubelet version the node is on. The problem is that ip-masq-agent can only run on node with 1.7 release.
Even if we fix the test it doesn't fix GKE or any other environment where the master is upgraded to 1.7 and the nodes are < 1.7. I think the real problem here is that there is no distinction between staging an addon and enabling an addon. Essentially staging = running. So we end up adding labels to nodes as a way of keeping the DaemonSet disabled until those labels are to nodes. While that works fine for addons that are DaemonDets, it doesn't work for deployments and replica sets. I feel like this is going to happen again regardless of what we do here with ip-masq-agent. It also creates a secondary step. Who applies those addons? What if they forget? what if it's deleted?
Fixed by (the formatting wasn't quite right in the IR to auto-close this issue).
got reverted as it broke tests.
Change:
expected []string }{ { <del> name: "custom certs dir", </del> <ins> name: "custom certs dir for v1.12.0-beta.2", </ins> cfg: &kubeadmapi.ClusterConfiguration{ CertificatesDir:   testCertsDir, <del> KubernetesVersion: "v1.7.0", </del> <ins> KubernetesVersion: "v1.12.0-beta.2", </ins> }, expected: []string{ "kube-controller-manager",

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When I use kubeadm to create an old version k8s cluster, the controller manager pod can not work well. The command like this : "kubeadm init --kubernetes-version=v1.11.2" The error of kube controller manager pod like this : What you expected to happen: The controller manager pod can work well. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.12.0 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): CentOS 7 Kernel (e.g. ): Install tools: kubeadm Others:
Reiterating the mentions to trigger a notification: <detailsIn response to : Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/remove-sig contributor-experience /area kubeadm
Please, use when filing kubeadm issues. /sig cluster-lifecycle
OK, thank you for reminding me.
Change:
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/watch" <ins> cachetools "k8s.io/client-go/tools/cache" watchtools "k8s.io/client-go/tools/watch" </ins> "k8s.io/kubernetes/test/e2e/framework" "github.com/onsi/ginkgo"

Discussion:
By inspection, the "should receive events on concurrent watches in same order" conformance test does two things that are not stable: Starts watches from resourceVersion=0 Relies on watch connections without handling timeouts/restarts This test can fail on clusters that have configmaps autocreated in namespaces already because ordering of watch events for resourceVersion=0 watches is undefined (see ) Watch connections used by conformance tests should use well-defined ordering (starting from resourceVersions other than 0) and handle interruptions properly. 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:
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
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
Change:
proxyRoundTripper = transport.NewAuthProxyRoundTripper(user.GetName(), user.GetGroups(), user.GetExtra(), proxyRoundTripper) <ins> if utilfeature.DefaultFeatureGate.Enabled(genericfeatures.APIServerTracing) && !upgrade { tracingWrapper := tracing.WrapperFor(r.tracerProvider) proxyRoundTripper = tracingWrapper(proxyRoundTripper) } </ins> // If we are upgrading, then the upgrade path tries to use this request with the TLS config we provide, but it does // NOT use the proxyRoundTripper.  It's a direct dial that bypasses the proxyRoundTripper.  This means that we have to // attach the "correct" user headers to the request ahead of time.

Discussion:
Extension API servers do not currently receive the header when requests are proxied through kube-aggregator, so spans are not linked properly. Traces from the extension API sever should be linked to the parent in kube-aggregator. tracing for kube-apiserver tracing for sample-apiserver and aggregate it to kube-apiserver a request to kube-apiserver for one of the resources from sample-apiserver sample-apiserver traces will not be linked to the kube-apiserver traces No response <detailsThis problem currently exists on . </details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/cc /triage accepted
Change:
t.Error("Allocator expected to be full") } } <ins> func TestAllocateReservedDynamicBlockExhausted(t *testing.T) { defer featuregatetesting.SetFeatureGateDuringTest(t, utilfeature.DefaultFeatureGate, features.ServiceIPStaticSubrange, true)() _, storage, _, si, destroyFunc := newStorage(t) defer destroyFunc() if err := si.Create(context.TODO(), key(), validNewRangeAllocation(), nil, 0); err != nil { t.Fatalf("unexpected error: %v", err) } // allocate all addresses both on the dynamic and reserved blocks // once the dynamic block has been exhausted // the dynamic allocator will use the reserved block max := 254 for i := 0; i < max; i++ { if _, err := storage.AllocateNext(); err != nil { t.Errorf("Unexpected error trying to allocate: %v", err) } } for i := 0; i < max; i++ { ip := fmt.Sprintf("192.168.1.%d", i+1) if !storage.Has(netutils.ParseIPSloppy(ip)) { t.Errorf("IP %s expected to be allocated", ip) } } if _, err := storage.AllocateNext(); err == nil { t.Error("Allocator expected to be full") } } </ins>

Discussion:
In a enabled cluster, Kubernetes assigns duplicate IP addresses when the dynamic block is exhausted. I expected all clusterIPs are uniquely assigned. a enabled Kubernetes v1.24 cluster with a small service-cluster-ip-range. I confirmed on the minikube with the following command. services until the dynamic block is exhausted. see some clusterIPs are duplicated. No response <details</details<detailsminikube v1.25.2 </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
When the dynamic block is exhausted, we expect the service creation to fail with an error message like "No IP address available", right?
According to , Dynamically IP assignment will use the upper band by default, once this has been exhausted it will use the lower range. So I think using the reserved block (the lower range) is expected behavior
/sig network
upps /assign
/assign great catch, thanks
Change:
gen_conversion: $(CONVERSION_FILES) if [[ -f $(META_DIR)/$(CONVERSION_GEN).todo ]]; then                 $(CONVERSION_GEN)                                                <del> -i $$(cat $(META_DIR)/$(CONVERSION_GEN).todo | paste -sd,)   </del> <ins> -i $$(cat $(META_DIR)/$(CONVERSION_GEN).todo | paste -sd, -)   </ins> -O $(CONVERSION_BASENAME);                                   fi

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

Discussion:
It seems to me like all of the garbage collection integration tests produce a ton of log messages of the form:
Change:
var fakeOutputs []fakeexec.FakeAction var fcmd fakeexec.FakeCmd for _, expected := range expecteds { <ins> expected := expected </ins> if expected.cmd[1] == "clone" { <ins> // Calculate the subdirectory clone would create (if any) // git clone -- https://github.com/kubernetes/kubernetes.git target_dir --> target_dir // git clone -- https://github.com/kubernetes/kubernetes.git            --> kubernetes // git clone -- https://github.com/kubernetes/kubernetes.git .          --> . // git clone -- https://github.com/kubernetes/kubernetes.git ./.        --> . cloneSubdir := path.Base(expected.cmd[len(expected.cmd)-1]) if cloneSubdir == "kubernetes.git" { cloneSubdir = "kubernetes" } </ins> fakeOutputs = append(fakeOutputs, func() ([]byte, []byte, error) { // git clone, it creates new dir/files <del> os.MkdirAll(filepath.Join(fcmd.Dirs[0], expected.dir), 0750) </del> <ins> os.MkdirAll(filepath.Join(fcmd.Dirs[0], expected.dir, cloneSubdir), 0750) </ins> return []byte{}, nil, nil }) } else {

Discussion:
Apply this patch: Then run: make test WHAT=./pkg/volume/git_repo The test fails: Test should pass. See above. The full loop is: The first problem is that fakeOutputs is capturing , so all the funcs on that list use the from the final iteration, not the one from the iteration with the [1] == "clone". But then this problem appears to be covering up a different problem in the test scenarios themselves. I looked at it for a little bit but I haven't puzzled out what the test is trying to do exactly. Hopefully someone with more knowledge of the test can take a look. It seems like a buggy test, accidentally passing due to this other loopvar sharing bug. HEAD N/A N/A N/A N/A N/A
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 /priority important-soon /cc Thanks for the report and the detailed explanation
/assign
I wonder if it could be beneficial to invest some time and effort to identify a maximum of loops that contain the loopvar sharing bug maybe with comment and a todo ?