jiebi/CodeConvo huggingface dataset:
Change:
framework.ExpectEqual(configMapFromUpdate.Data, configMap.Data) }) <del> ginkgo.It("should run through a ConfigMap lifecycle", func() { </del> <ins> /* Release : v1.19 Testname: ConfigMap lifecycle Description: Attempt to create a ConfigMap. Patch the created ConfigMap. Fetching the ConfigMap MUST reflect changes. By fetching all the ConfigMaps via a Label selector it MUST find the ConfigMap by it's static label and updated value. The ConfigMap must be deleted by Collection. */ framework.ConformanceIt("should run through a ConfigMap lifecycle", func() { </ins> testNamespaceName := f.Namespace.Name testConfigMapName := "test-configmap" + string(uuid.NewUUID())

Discussion:
[x] Original approval issue: [x] Two weeks soak end date: 8 May 2020 [x] Two weeks soak end date: 23 June 2020 This issue is created to allow edit by /wip /hold This issue proposes the writing of a new test for the API endpoints , with the intention of promoting it to Conformance. This issue contains a very basic mock test in order to start the conversation about what a good e2e test would look like for this endpoint. The code below is verified to be hitting the intended endpoint, show as per the queries in APIsnoop's live view of the cluster's audit logs. According to this APIsnoop query, there are still some remaining ConfigMap endpoints which are untested. a ConfigMap with a static label the ConfigMap with a new Label and updated data the ConfigMap to ensure it's patched all ConfigMaps in all Namespaces find the ConfigMap(1) ensure that the ConfigMap is found and is patched Namespaced ConfigMap(1) via a Collection with a LabelSelector This mock test uses client-go's standard functions for talking to the Event area of the API. Discover useragents: Display endpoints hit by the test: Show the change in coverage after the mock test: If a test with these calls gets merged, Conformance coverage will go up by 2 points
/sig testing /sig architecture /area conformance
/assign Issue created to replace
GitHub didn't allow me to assign the following users: raymonddeng99. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/reopen On hold & soaking
Reopened this issue. <detailsIn response to : /reopen On hold & soaking 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:
} if len(strings.Split(stringValue, "/")) == 1 { if !standardFinalizers.Has(stringValue) { <del> allWarnings = append(allWarnings, fmt.Sprintf("%s: %q: prefer a domain-qualified finalizer name to avoid accidental conflicts with other finalizer writers", fldPath.String(), stringValue)) </del> <ins> if strings.Contains(stringValue, ".") { allWarnings = append(allWarnings, fmt.Sprintf("%s: %q: prefer a domain-qualified finalizer name including a path (/) to avoid accidental conflicts with other finalizer writers", fldPath.String(), stringValue)) } else { allWarnings = append(allWarnings, fmt.Sprintf("%s: %q: prefer a domain-qualified finalizer name to avoid accidental conflicts with other finalizer writers", fldPath.String(), stringValue)) } </ins> } } return allWarnings

Discussion:
k8s component developers are using FQDNs as finalizers (e.g. or which triggers an error message that isn't particularly easy for an end user to understand: To a naive end user, a fully qualified domain name is a pretty safe thing that is unlikely to conflict with anything else (as long as it's only used by someone from within the domain that owns it, which is a reasonable assumption). If the finalizer has s inside it but no , the message should suggest that finalizers need a . Something like: Do whatever it is that triggered the warning in (this is probably simpler than installing cert-manager and asking for a certificate) introduced: <details</details<detailsGKE </details<details</details<details</details<details</details<details</details
/sig api-machinery
If thats ok I would like to work on that.
/assign
/triage accepted
Change:
return true, objv1, nil }) testClient.PrependReactor("update", "horizontalpodautoscalers", func(action core.Action) (handled bool, ret runtime.Object, err error) { <del> tc.Lock() defer tc.Unlock() </del> assert.Fail(t, "should not have attempted to update the HPA when nothing changed") // mark that we've processed this HPA tc.processed <- ""

Discussion:
What happened: The unit test for Horizontal Pod Autoscaler frequently deadlocked on the OpenShift CI system. What you expected to happen: The unit test should be robust and succeed without having to win a race condition to avoid deadlock. How to reproduce it (as minimally and precisely as possible): I'm not sure. Anything else we need to know?: Here are some logs of the problem happening: https://openshift-gce- The deadlocks seem to happen when the chan fills up while waiting for events. If that happens, there's a race where immediately after an event is read but before it can acquire the lock to verify the test, 2 event reactors are able to acquire the lock and write to the chan. The second will block forever since the chan is full and there's nobody to read from it. I've opened a PR with the fix. See
/sig autoscaling
/assign
Change:
return template }(), }, <ins> "good-parameters-apigroup": { template: func() *resource.ResourceClaimTemplate { template := testClaimTemplate(goodName, goodNS, goodClaimSpec) template.Spec.Spec.ParametersRef = &resource.ResourceClaimParametersReference{ APIGroup: goodAPIGroup, Kind:     "foo", Name:     "bar", } return template }(), }, "bad-parameters-apigroup": { wantFailures: field.ErrorList{field.Invalid(field.NewPath("spec", "spec", "parametersRef", "apiGroup"), badAPIGroup, "a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')")}, template: func() *resource.ResourceClaimTemplate { template := testClaimTemplate(goodName, goodNS, goodClaimSpec) template.Spec.Spec.ParametersRef = &resource.ResourceClaimParametersReference{ APIGroup: badAPIGroup, Kind:     "foo", Name:     "bar", } return template }(), }, </ins> "missing-parameters-kind": { wantFailures: field.ErrorList{field.Required(field.NewPath("spec", "spec", "parametersRef", "kind"), "")}, template: func() *resource.ResourceClaimTemplate {

Discussion:
Following YAML file is accepted without error. Notice the field, it is an instead of , containing character. This can lead to an issue when resource driver generates structured parameters' in-tree object with being just without version. The DRA scheduler plugin will try to match the parameters object based on the reference here: In latest master the code appears to use an indexer, and the issue might be hidden, if applicable at all. I did not check the reproducibility in master yet. However, main question is whether the should allow value with character in general. An error is expected from the apiserver upon object creation request, reporting that APIGroup containes APIVersion. Maybe. Have any resource driver that supports structured parameters, , for instance, also puts (gpucrd.APIGroup) value into . v1.30.1 <details</details<details</details<details</details<details</details<detailsscheduler's dynamicresources plugin </details
/sig node /triage accepted
/assign
Change:
// LabelNodeRoleExcludeBalancer specifies that the node should be // exclude from load balancers created by a cloud provider. <del> LabelNodeRoleExcludeBalancer = "alpha.node.role.kubernetes.io/exclude-balancer" </del> <ins> LabelNodeRoleExcludeBalancer = "alpha.service-controller.kubernetes.io/exclude-balancer" </ins> ) type cachedService struct {

Discussion:
For various reasons (network topology, heterogenous nodes, etc) a user may want to control the addition of a node to a cloud load balancer. A specific issue with the Azure Container Instances connector which introduces a virtual node can be found here: The right way to do this is via a node annotation, e.g.
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 stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
/reopen This is still a problem.. any word on when feature gate goes out of alpha?
Setup the enhancement tracking issue for this Still discussing with sig-network on how we want to move forward with this.
Change:
<del> v1.11.1-2 </del> <ins> v1.11.2-1 </ins>

Discussion:
go 1.11.2 is out 11/2 and this bug tracks upgrade to the latest version. Is it something we should absolutely needed in the 1.13 timeframe? are there any that should absolutely take? how long does the associated image updates and push take? If we chose to upgrade in 1.13, we should do it before code slush targeted for Friday 11/6. /assign can you please clarify the above ques and and help evaluate timing of the upgrade. /cc /sig release /sig testing /priority important-soon /kind cleanup
/cc I’ve already got a branch cooking for this, but waiting for rules_go support first. I think said in Slack that this will happen this week.
Ahh so is the earliest expected timeframe when we can upgrade falls into Code slush period for 1.13 (post 11/9?) Depending on when it lands we might want to see if its safe to wait for 1.13.1. are you aware of any critical fixes that make this compelling for 1.13 timeframe?
The risk for patch golang point releases is typically low (the minor releases, like 1.10 -1.11, are higher risk). I don't see anything that's critical or of known impact, but at the same time, I see compiler fixes and go/types package fixes. They are more subtle and could present issues later. I'd suggest that if we can tolerate getting it in, even if we're in slush, we should.
Ack that :) Plz ping this bug as soon as we are ready to build and push the upgraded images. we'll will make a final call depending on the timeframe and CI signal going in. thanks!
Change:
// TODO: Make it work for all providers and distros. supportedProviders := []string{"gce", "aws", "vsphere"} if !ProviderIs(supportedProviders...) { <del> return fmt.Errorf("unsupported provider: %s, supported providers are: %v", TestContext.Provider, supportedProviders) </del> <ins> return fmt.Errorf("unsupported provider for RestartKubelet: %s, supported providers are: %v", TestContext.Provider, supportedProviders) </ins> } if ProviderIs("gce") && !NodeOSDistroIs("debian", "gci") { return fmt.Errorf("unsupported node OS distro: %s", TestContext.NodeOSDistro)

Discussion:
is failing with "framework.RestartControllerManager() = unsupported provider: gke; want nil" /kind failing-test
/sig network
Introduced in , should be fixed by
Change:
import ( "fmt" "reflect" <ins> "sort" </ins> "sync" jsonpatch "github.com/evanphx/json-patch"

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: I used to fake a clientset to test my code. I found that it became very slow to init the clientset with a big number of objects when I was trying to simulate a large scale cluster, and the time seemed exponential increasing. For example: Initializing a clientset with: 5000 objects took 300ms objects took 2.58s objects took 11.82s objects took 54.64s. It's because the fake clientset used a slice to store each kind of objects, so it's quite slow to init the clientset with massive objects because it checked existence of an object by traversing all objects and comparing with them before adding one, which leads to O(n^2) time complexity. What you expected to happen: The fake clientset is very useful for development, it should have a reasonable time complexity to allow developers to use it for large scale scenario. How to reproduce it (as minimally and precisely as possible): Run this code: You would see the time spent on each operation, like: Anything else we need to know?: Environment: Kubernetes version (use ): 1.15.0-1.18.0 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
I had PR that uses map to store objects, which can reduce the init time to a reasonable value (tens of ms for objects). /assign
Change:
} func (loader *fsLoader) Load() (*kubeletconfig.KubeletConfiguration, error) { <del> errfmt := fmt.Sprintf("failed to load Kubelet config files from %q, error: ", loader.configDir) + "%v" </del> // require the config be in a file called "kubelet" <del> path := filepath.Join(loader.configDir, "kubelet") </del> <ins> path := filepath.Join(loader.configDir, kubeletFile) </ins> data, err := loader.fs.ReadFile(path) if err != nil { return nil, fmt.Errorf("failed to read init config file %q, error: %v", path, err)

Discussion:
From in The most important things I want to see through node e2e tests: 1) the kubelet is started from last-known-good-config file 2) kubelet can download the new config properly to the node; and restart itself from the new config file 3) kubelet can mark the config bad properly after several round of crashing caused the bad config 4) Kubelet can roll back the last-known-good-config and restart itself from that good one 5) kubelet can properly reports its configuration status Note: (2) is covered by existing e2enode tests (1, 4, 5) were covered by the , all of which I plan to turn into automated tests after this PR merges - but I'm trying not to increase the size of this PR any further ~(3) we need to figure out how to test this. I don't want to rely on a "valid" config that causes a crash loop - because the very existence of such a config should be viewed as a bug. I also don't want to include a "please crash loop for our tests" field in the config, because that's an ugly API. The best solution is not clear here.~ We decided to remove crash-loop detection, see . Filing this issue to track this work: into e2e_node tests [x] remote config [x] local (from file) config [x] ~test the crash-loop detection~ removed, see above /cc
[MILESTONENOTIFIER] Milestone Removed Important: This issue was missing labels required for the v1.8 milestone for more than 7 days: kind: Must specify exactly one of [, , ]. priority: Must specify exactly one of [, , ]. Removing it from the milestone. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
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
/remove-lifecycle stale
The test cases in the OP have been covered by our e2e_node tests for a while.
Change:
} // Currently two modes of proxying are available: 'userspace' (older, stable) or 'iptables' <del> // (experimental). If blank, look at the Node object on the Kubernetes API and respect the // 'net.experimental.kubernetes.io/proxy-mode' annotation if provided.  Otherwise use the // best-available proxy (currently userspace, but may change in future versions).  If the // iptables proxy is selected, regardless of how, but the system's kernel or iptables // versions are insufficient, this always falls back to the userspace proxy. </del> <ins> // (newer, faster). If blank, use the best-available proxy (currently iptables, but may // change in future versions).  If the iptables proxy is selected, regardless of how, but // the system's kernel or iptables versions are insufficient, this always falls back to the // userspace proxy. </ins> type ProxyMode string const (

Discussion:
This annotation dates back almost a year. This is a relatively easy project for someone to contribute.
I'll work on getting a pull request in tomorrow for this. Ive been looking at contributing and think this would be a great place to start
nevermind. Looks like a pull request already exists. Overlooked the mention due to being on mobile. Cheers
We'll file more :)
Change:
} func (c *nodePlugin) admitNode(nodeName string, a admission.Attributes) error { <del> if a.GetName() != nodeName { return admission.NewForbidden(a, fmt.Errorf("cannot modify other nodes")) </del> <ins> requestedName := a.GetName() // On create, get name from new object if unset in admission if len(requestedName) == 0 && a.GetOperation() == admission.Create { node, ok := a.GetObject().(*api.Node) if !ok { return admission.NewForbidden(a, fmt.Errorf("unexpected type %T", a.GetObject())) } requestedName = node.Name } if requestedName != nodeName { return admission.NewForbidden(a, fmt.Errorf("node %s cannot modify node %s", nodeName, requestedName)) </ins> } return nil }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one):BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"7+", GitVersion:"v1.7.0-alpha.4.52+", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-05-19T06:57:30Z", GoVersion:"go1.8.1", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"7+", GitVersion:"v1.7.0-alpha.4.52+", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-05-19T06:57:30Z", GoVersion:"go1.8.1", Compiler:"gc", Platform:"linux/amd64"} Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know: None
Change:
var quotaTestCases = []quotaTestCase{ { <ins> "SupportsQuotaOnQuotaVolume", </ins> "/quota1/a", "", 1024, "Supports", "", "", true, true, 0, 0, 0, 0, 1, 1, 0, 0, 1, 1, 1, }, { <ins> "AssignQuotaFirstTime", </ins> "/quota1/a", "", 1024, "Set", projects1, projid1, true, true, 1, 1, 1, 1, 0, 0, 1, 1, 0, 0, 0, }, { <ins> "AssignQuotaFirstTime", </ins> "/quota1/b", "x", 1024, "Set", projects2, projid2, true, true, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 1, }, { <ins> "AssignQuotaFirstTime", </ins> "/quota2/b", "x", 1024, "Set", projects3, projid3, true, true, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, }, { <ins> "AssignQuotaSecondTimeWithSameSize", </ins> "/quota1/b", "x", 1024, "Set", projects3, projid3, <ins> true, true, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, }, { "AssignQuotaSecondTimeWithDifferentSize", "/quota2/b", "x", 2048, "Set", projects3, projid3, </ins> true, false, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, }, { <ins> "ClearQuotaFirstTime", </ins> "/quota1/b", "", 1024, "Clear", projects4, projid4, true, true, -1, -1, -1, -1, 0, -1, -1, -1, -1, -1, -1, }, { <ins> "SupportsQuotaOnNonQuotaVolume", </ins> "/noquota/a", "", 1024, "Supports", projects4, projid4, false, false, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, }, { <ins> "ClearQuotaFirstTime", </ins> "/quota1/a", "", 1024, "Clear", projects5, projid5, true, true, -1, -1, -1, -1, 0, -1, -1, -1, -1, -1, -1, }, { <ins> "ClearQuotaSecondTime", </ins> "/quota1/a", "", 1024, "Clear", projects5, projid5, true, false, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, }, { <ins> "ClearQuotaFirstTime", </ins> "/quota2/b", "", 1024, "Clear", "", "", true, true, -1, -1, -1, -1, 0, -1, -1, -1, -1, -1, -1, },

Discussion:
When sizeLimit is specified subsequent invocations will fail with the message: No error should be raised. Create a pod with emptyDir and sizeLimit with FSQuotaMonitoring enabled, MountVolume.SetUp is called again only if the first iteration takes longer then the actual reconciler loop interval (100ms). No response <detailsversion.Info{Major:"1", Minor:"27+", GitVersion:"v1.27.0-beta.0.87+", GitCommit:"", GitTreeState:"clean", BuildDate:"2023-04-10T09:05:56Z", GoVersion:"go1.20.2", Compiler:"gc", Platform:"linux/amd64"} </details<detailsSelf-managed cluster in Azure </details<detailsNAME="Red Hat Enterprise Linux" VERSION="9.1 (Plow)" ID="rhel" IDLIKE="fedora" VERSIONID="9.1" Linux test-master-0 6.3.0-rc3 SMP PREEMPTDYNAMIC Thu Apr 6 20:44:15 UTC 2023 x8664 x8664 x8664 GNU/Linux </details<detailsContainerd 1.6.15 </details<detailsCNI: CANAL 3.24.1 </details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig node
May you please share more information? Which version of Kubernetes you are using? OS version etc.
The problem occurs with the latest master branch, I updated the initial post with versions.
Thank you.