jiebi/CodeConvo huggingface dataset:
Change:
"//pkg/master/ports:go_default_library", "//pkg/scheduler/nodeinfo:go_default_library", "//staging/src/k8s.io/api/apps/v1:go_default_library", <ins> "//staging/src/k8s.io/api/autoscaling/v1:go_default_library", </ins> "//staging/src/k8s.io/api/batch/v1:go_default_library", "//staging/src/k8s.io/api/batch/v1beta1:go_default_library", "//staging/src/k8s.io/api/core/v1:go_default_library",

Discussion:
According to this APIsnoop query, there are still some remaining ReplicationController endpoints which are untested. Create a ReplicationController with a static label Patch the ReplicationController with a new Label and updated data Patch the ReplicationController's status Patch/Scale the ReplicationController's Replica count to 2 Replicas Get the ReplicationController Replace the ReplicationController's Status List all ReplicationControllers in all Namespaces find the ReplicationControllers(1) ensure that the ReplicationController is found and is patched Delete Namespaced ReplicationControllers(1) via a Collection with a LabelSelector Discover useragents: See all endpoints hit from this test Display test coverage change If a test with these calls gets merged, test coverage will go up by 7 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
Deployment replaced ReplicationController a while back. It should be part of conformance. We need to check more than the data-aspect (beyond crud), we need to verify the data-plane. In this case we need to check the pods as well and not just the ReplicationController status. Moved to backlog by conformance subgroup.
PR:
/open /reopen We need this open to track the test promotion and flakyness. We can't write a promotion PR until the test has no flakes for 2 weeks.
Reopened this issue. <detailsIn response to : /open /reopen We can't write a promotion PR until the test has no flakes for 2 weeks. 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
/retitle Promote CoreV1ReplicationController lifecycle mock test - +7 coverage Need to verify two weeks on non-flakeyness.
/retitle Write CoreV1ReplicationController lifecycle test+promote - +7 coverage
Closing in favour of /close
Closing this issue. <detailsIn response to : Closing in favour of /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
Change:
"os" "strconv" "time" <ins> "golang.org/x/text/encoding/unicode" "golang.org/x/text/transform" </ins> ) const VHD_COOKIE = "636f6e6563746978"     // conectix

Discussion:
I ran an OSS license scan of a codebase that has this project as a dependency and came across an interesting hit. This go-vhd dependency specified here: has a snippet of code from StackOverflow which is license under creative commons sharealike. Here's the code in question: I'm not a license expert, so I don't know if there are any real issues/conflicts here or not, but wanted to share to see what you all think. Here's SO's license info for reference: My understanding is that the potential issue would be with this clause: which could potentially require go-vhd and projects that depend on it to use the Creative Commons license as well.
Thanks for the report! can you please take a look if this is concerning? If so, we'll check if we can avoid this dependency (looks unlikely unless we duplicate what it's ) or we'll follow up upstream to update the code. /cc OWNERS for this repo
CC-BY-SA can be problematic in Apache-2.0 projects like k8s because of the ShareAlike aspect as noted. I'd recommend working with upstream to rewrite just that one function particularly since it looks like it's fairly limited.
let's please move this issue to kubernetes/kubernetes?
/provider azure
/sig release /area code-organization
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig release /area code-organization 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 /assign
/area code-organization
/assign
/milestone v1.19 /priority important-soon
Not a huge difference, but this is likely actually licensed under , not 4.0. See
the k/k code actually does not reference , since that function is in , do you mean we should remove from k/k totally?
Yes, we would either need to remove from k/k or ask the maintainers of to update . This means that (and k/k if we end up using it) would need to be licensed until CC-BY-SA.
Would this ultimately be backported to older versions of k8s or would you just do it in 1.19?

thanks, Let me remove the code in v1.19, actually that part of functionality is deprecated in Azure cloud provider already. My initial thought is only do this in v1.19
/kind bug /priority important-soon /sig cloud-provider /area provider/azure
Since it isn't trivial to remove as a dependency entirely (), I've created upstream to track updating the code there.
Change:
} // no cached CIDR is Ok during teardown <del> if cidr, ok := plugin.podCIDRs[id]; ok { </del> <ins> cidr, hasCIDR := plugin.podCIDRs[id] if hasCIDR { </ins> glog.V(5).Infof("Removing pod CIDR %s from shaper", cidr) // shaper wants /32 if addr, _, err := net.ParseCIDR(cidr); err != nil {

Discussion:
Kubelet log is full of errors from tearing down network at HEAD. From the log, a lot of them were the result of trying to access . Note that if you an exited container, the returned PID will be 0. Therefore, my guess is that kubelet tried to tear down the network after the container has already exited. I didn't dig further. could you take a look?
/cc
Is this a dup of ? We can add a safe guard to prevent TearDown to proceed, but it will not solve the root cause. IIUC,the root cause is the race between syncPod and podKiller.
See also
I don't think failed because of this. this is probably caused by , like you said. The fact that we are seeing more errors than before is likely due to , which enforces graceless namespace deletions. Before that, most objects in the e2e were deleted gracefully and the race condition was rarely hit. Now most objects will hit this path. It'd still be a good idea to add a safeguard to check whether the pid is 0.
Change:
} } <ins> func TestCreateDeploymentRollbackValidation(t *testing.T) { storage, server := newStorage(t) rollbackStorage := storage.Rollback rollback := apps.DeploymentRollback{ Name:               name, UpdatedAnnotations: map[string]string{}, RollbackTo:         apps.RollbackConfig{Revision: 1}, } ctx := genericapirequest.WithNamespace(genericapirequest.NewContext(), namespace) if _, err := storage.Deployment.Create(ctx, validNewDeployment(), rest.ValidateAllObjectFunc, &metav1.CreateOptions{}); err != nil { t.Fatalf("Unexpected error: %v", err) } validationError := fmt.Errorf("admission deny") alwaysDenyValidationFunc := func(obj runtime.Object) error { return validationError } _, err := rollbackStorage.Create(ctx, &rollback, alwaysDenyValidationFunc, &metav1.CreateOptions{}) if err == nil || validationError != err { t.Errorf("expected: %v, got: %v", validationError, err) } storage.Deployment.Store.DestroyFunc() server.Terminate(t) } </ins> // Ensure that when a deploymentRollback is created for a deployment that has already been deleted // by the API server, API server returns not-found error. func TestEtcdCreateDeploymentRollbackNoDeployment(t *testing.T) {

Discussion:
What happened: I'm unable to configure the api-server through a to pass admission requests to my for the resource. I'm adding the following rule to the When performing rollbacks, I'm not seeing any calls to the admission webhook. What you expected to happen: To receive validation requests when performing rollbacks. How to reproduce it (as minimally and precisely as possible): Create a ValidatingAdmissionWebhook and perform a rollback request. Anything else we need to know?: Mentioned this on the #sig-api-machinery channel on Slack, and suggested the error was that the -object never is used: Environment: Kubernetes version (use ): 12.3 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Container Linux by CoreOS 1911.5.0 (Rhyolite) 4.14.84-coreos docker://18.6.1 Kernel (e.g. ): Install tools: Others: /kind bug
/sig apps
/sig api-machinery
Good point, should call .
Change:
// IngressClass resource create/read/update/watch verbs ginkgo.By("creating") <del> ingressClass1, err := createIngressClass(cs, "ingressclass1", true, f.UniqueName) </del> <ins> ingressClass1, err := createIngressClass(cs, "ingressclass1", false, f.UniqueName) </ins> framework.ExpectNoError(err) <del> _, err = createIngressClass(cs, "ingressclass2", true, f.UniqueName) </del> <ins> _, err = createIngressClass(cs, "ingressclass2", false, f.UniqueName) </ins> framework.ExpectNoError(err) <del> _, err = createIngressClass(cs, "ingressclass3", true, f.UniqueName) </del> <ins> _, err = createIngressClass(cs, "ingressclass3", false, f.UniqueName) </ins> framework.ExpectNoError(err) ginkgo.By("getting")

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 --Which jobs are flaking: gce-master-scale-correctness Which test(s) are flaking: [sig-network] Ingress API should support creating Ingress API operations [Conformance] Testgrid link: https://k8s- Reason for failure: Anything else we need to know: /kind flake /sig scalability /sig network /cc
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
this is caused by the issue described in a different test is creating a default ingressclass, which breaks creation of ingress objects if there was already a default ingressclass set up in the cluster /assign
this should resolve the issue:
I take it back, looks like the conformance test is also creating default ingressclass objects... it should not fix in
Change:
// CleanupLeftovers clean up all ipvs and iptables rules created by ipvs Proxier. func CleanupLeftovers(ipvs utilipvs.Interface, ipt utiliptables.Interface, ipset utilipset.Interface, cleanupIPVS bool) (encounteredError bool) { <ins> if canUse, _ := CanUseIPVSProxier(NewLinuxKernelHandler(), ipset); !canUse { return false } </ins> if cleanupIPVS { // Return immediately when ipvs interface is nil - Probably initialization failed in somewhere. if ipvs == nil {

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?: What happened: kube proxy report following error even if ipvs not enabled. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Install kubernetes and start proxy. Anything else we need to know?: Environment: Kubernetes version (use ): We are using 1.9.1 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /cc comments?
/sig network
It's a noise, but it's thrown by libnetwork/ipvs util. Is that a big deal?
please take a look when you have a chance :)
Yes, it always bring noise for production when customer got warning messages. Why printing some ipvs message even it was not enabled?
/area ipvs
Change:
<del> apiVersion: v1 clusters: - cluster: certificate-authority: /etc/secret-volume/kube-ca server:  https://146.148.35.28 name: kubernetes contexts: - context: cluster: kubernetes user: kubernetes-admin name: kubernetes current-context: kubernetes kind: Config preferences: {} users: - name: kubernetes-admin user: auth-path: /etc/secret-volume/kube-auth-path </del>

Discussion:
This PR was prematurely merged: Need to update the PR based on the actual steps that were needed to get what was demonstrated at the public Kubernetes meet-up last week.
Any chance you can get rid of the hostPort from the example?
- depending on the Kubernetes provider, yes. For Vagrant based provider, I think I still need the hostPort because I do not have routes. For the GCE provider, I should be able to get rid of it because I have routes. In both providers, there were a number of setup steps that did not make the merged PR. For those that are tracking this issue (which I know folks have pinged me on separately) needs to be configured to allow privelaged containers needs to be configured to allow pushing to an insecure registry (this is point in time) Ideally, I could use a ReplicationController in the example to load balance OpenShift, but until we can provide a pattern to run etcd as a pod, I am unable to do this and need to use the embedded etcd we end up running.
Note: I will resolve this issue in 2 phases. Vagrant (which was demonstrated) to document using GCE (which has some additional steps on firewall rules)
Turns out OpenShift Origin is too secure now ;-) This is blocked until OpenShift Origin allows you to mint certs on the client, and then supply the certs on startup as a secret to the pod. This feature is coming soon. /cc
I now have all the required pieces to get this to work. I hope to get a PR submitted to fix this issue by end of this week.
Change:
close(sched.config.StopEverything) } <ins> // Cache returns the cache in scheduler for test to check the data in scheduler. func (sched *Scheduler) Cache() schedulercache.Cache { return sched.config.SchedulerCache } </ins> // Configurator defines I/O, caching, and other functionality needed to // construct a new scheduler. An implementation of this can be seen in // factory.go.

Discussion:
While lookint into , I spent few minutes looking into this test: And there is a problem that is relatively easy to reproduce. The problem is that we are running its test cases one by one. But nothing in the meantime is ensuring that the current state that the test assumes is reflected in scheduler. In particular the problem that I observed couple time is that: we finished one test case we call cleanupNodes [but we don't ensure that scheduler actually cleaned up this node] we start the next test case we try to schedule a pod that has some toleration (but shouldn't fit on our node) by accident the toleration make it fit on to the previous node so scheduler schedules it on the node from previous test case
/assign
Change:
"kuberuntime_container_test.go", "kuberuntime_gc_test.go", "kuberuntime_image_test.go", <del> "kuberuntime_logs_test.go", </del> "kuberuntime_manager_test.go", "kuberuntime_sandbox_test.go", "labels_test.go",

Discussion:
We should make the CRI log parsing code in kubelet to be a library. So that container runtimes and external tools don't need to copy the whole code ( vendor it instead ). Referring
/assign
/sig node
I can help on it.
/assign
GitHub didn't allow me to assign the following users: yanxuean. Note that only can be assigned. <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
Thanks. I have a branch ready for this. Will open a PR later and ping you when it is out.
ok
Change:
type RlimitStats struct { Time metav1.Time `json:"time"` <del> // The max PID of OS. </del> <ins> // The max number of extant process (threads, precisely on Linux) of OS. See RLIMIT_NPROC in getrlimit(2). // The operating system ceiling on the number of process IDs that can be assigned. // On Linux, tasks (either processes or threads) consume 1 PID each. </ins> MaxPID *int64 `json:"maxpid,omitempty"` <del> // The number of running process in the OS. </del> <ins> // The number of running process (threads, precisely on Linux) in the OS. </ins> NumOfRunningProcesses *int64 `json:"curproc,omitempty"` }

Discussion:
PIDPressure is not set to true when the system has insufficient pid resource. PIDPressure is set to true correctly when the system is insufficient in pid resource. See cause below The max pid is not solely controlled by which is referred by . But it is also controlled by (whichever is smaller). However, they have different semantics resulting in the same constraint to how many processes/threads can be running on the system. <details</details<details</details<details</details<details</details<details</details<details</details
/sig node
I asked the same issue before,
My opinion: the minimum of and is the right number to count, for Linux. That will provide better instrumentation. If you're reserving a number of task IDs (PIDs) for system use, that minimum is the number that you're reserving from.
/triage accepted /priority important-longterm
/retitle System maximum PID inconsiderate of sysctl 'threads-max'
BTW I made a thing that might help folks test a fix: Originally I used it to create PIDs, to test whether apps cope with long PIDs. This version keeps the threads around so that you see them in .
Change:
{"", "v1", "Service", true}, {"batch", "v1", "Job", true}, {"batch", "v1beta1", "CronJob", true}, <del> {"extensions", "v1beta1", "Ingress", true}, </del> <ins> {"networking.k8s.io", "v1", "Ingress", true}, </ins> {"apps", "v1", "DaemonSet", true}, {"apps", "v1", "Deployment", true}, {"apps", "v1", "ReplicaSet", true},

Discussion:
What happened: Sweeping uses of extensions/v1beta1 in preparation for , the addon manager stood out as using extensions/v1beta1 Ingress by default: What you expected to happen: All components shipped in 1.21 must use Ingress in order to work properly against a 1.22 API server. /sig networking cc per cluster/addons/addon-manager/OWNERS cc I'm not sure what the addon manager does if given a prune list of Ingress objects while still using a manifest containing extensions/v1 Ingress objects... this needs to be tested. /milestone v1.21 /priority important-soon /lifecycle frozen
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : What happened: cc /priority important-soon /lifecycle frozen 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
/triage accepted
how "urgent" is this? Can wait until next tuesday? Otherwise I can work on the tests this weekend :)
important, not urgent. it should happen early in the 1.21 cycle, but does not require work out of business hours
Hello! I am from the Bug Triage team! This issue has not been updated for a few weeks, so I'd like to check on the status. Code freeze is starting March 9th, 2021 (about 1 week from now). We want to ensure that each PR has a chance to be merged before code freeze. As the Issue is tagged for 1.21, is it still planned for this release?
we're waiting to the PR to get merged :) I guess it's important for the v1.21 release, for the sake of extensions apiGroup deprecation :) Will ping reviewers on the PR
Change:
<-called close(ch) <del> <-called </del> <ins> // wait for 'called' to be closed for { if _, ok := <-called; !ok { break } } </ins> //-- ch = make(chan struct{}) <del> called = make(chan struct{}) </del> <ins> called2 := make(chan struct{}) </ins> running := make(chan struct{}) After(func() { Until(func() { close(running) <del> called <- struct{}{} </del> <ins> called2 <- struct{}{} </ins> }, 2*time.Second, ch) <del> }).Then(func() { close(called) }) </del> <ins> }).Then(func() { close(called2) }) </ins> <-running close(ch) <del> <-called // unblock the goroutine </del> <ins> <-called2 // unblock the goroutine </ins> now := time.Now() <del> <-called </del> <ins> // wait for 'called2' to be closed for { if _, ok := <-called2; !ok { break } } </ins> if time.Since(now) > 1800*time.Millisecond { t.Fatalf("Until should not have waited the full timeout period since we closed the stop chan") }

Discussion:
It failed on cc - please fix or reassign.
ping I am tempted to just disable the test per our standard protocol for dealing with Mesos test problems that aren't fixed in a timely fashion, but since it's a flake I'm willing to wait until it flakes again (unless you fix it first).
FYI - I've opened a PR w/ a fix , David Oppenheimer
Change:
echo "OPTIONS='-b=kbr0 --selinux-enabled ${DOCKER_OPTS}'" >/etc/sysconfig/docker systemctl daemon-reload systemctl start docker } EOF

Discussion:
It appears that the provision-network script that is run on the kubernetes-master can cause salt provisioning on the minions to fail or block in a forever retry timeout error loop. I think it's because of the service network.restart that happens after openvswitch is installed in provision-network. I only say this because when I disable installing docker on kubernetes-master in vagrant, I do not have an issue. - is there a different way we can structure this on the kubernetes-master? For example, could we run the script in or something?
Change:
res.Body.Close() } <del> func captureStdErr() (func() string, func(), error) { </del> <ins> func TestErrConnKilled(t *testing.T) { </ins> var buf bytes.Buffer <del> reader, writer, err := os.Pipe() if err != nil { return nil, nil, err } stderr := os.Stderr readerClosedCh := make(chan struct{}) stopReadingStdErr := func() string { writer.Close() <-readerClosedCh return buf.String() } klog.LogToStderr(true) cleanUp := func() { os.Stderr = stderr klog.LogToStderr(false) stopReadingStdErr() } os.Stderr = writer go func() { io.Copy(&buf, reader) readerClosedCh <- struct{}{} close(readerClosedCh) }() klog.LogToStderr(true) </del> <ins> klog.SetOutput(&buf) klog.LogToStderr(false) defer klog.LogToStderr(true) </ins> <del> return stopReadingStdErr, cleanUp, nil } func TestErrConnKilled(t *testing.T) { readStdErr, cleanUp, err := captureStdErr() if err != nil { t.Fatalf("unable to setup the test, err %v", err) } defer cleanUp() </del> handler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { // this error must be ignored by the WithPanicRecovery handler // it is thrown by WithTimeoutForNonLongRunningRequests handler when a response has been already sent to the client and the handler timed out

Discussion:
/sig api-machinery /kind bug /priority important-soon
It seems something is racing writhing the logs ? cc:
/cc /triage accepted
Failed with this: pull-kubernetes-unit
this looks like a test-only race where the test overwriting the global os.Stderr in order to capture error output races with an async attempt to log to it from another test in the same package
which still needs to be fixed
It seems to me that this bug can not be fixed with as it is, namely used without a logger object or even a . The smallest tweak that occurs to me would be to add an option to to add an output destination, and later remove that addition. Thus, a test could add logging to its own buffer for the duration of running the code under test.
This may be similar to . How can I reproduce this issue?
Change:
} if len(longest_tag) > 0 { tags.Insert(longest_tag) <del> } else if len(tags) > 0 { return nil, fmt.Errorf("Some, but not all, instances have prefix tags (%s is missing)", instance.Name) </del> <ins> } else { return nil, fmt.Errorf("Could not find any tag that is a prefix of instance name for instance %s", instance.Name) </ins> } } }

Discussion:
In some custom setup cases the prefix-matching logic for GCE load-balancers can break and end up creating a firewall rule with no tags. We should instead refuse to create the rule. In fact, if we find it, we should probably delete the rule, but that's maybe too aggressive. Looking at the logic, if we return error in the tag-selection, we'll abort the whole load-balancer creation, which is unfortunate, but not TERRIBLE. We could just silently not create the firewall but not return error, which will just retry over and over.
/cc
Are you active on this? may have some starter-project bandwidth to help.
Not active. It would indeed be a good starter project :)