jiebi/CodeConvo huggingface dataset:
Change:
}) // createBalancedPodForNodes creates a pod per node that asks for enough resources to make all nodes have the same mem/cpu usage ratio. <del> func createBalancedPodForNodes(f *framework.Framework, cs clientset.Interface, ns string, nodes []v1.Node, requestedResource *v1.ResourceRequirements, ratio float64) { </del> <ins> func createBalancedPodForNodes(f *framework.Framework, cs clientset.Interface, ns string, nodes []v1.Node, requestedResource *v1.ResourceRequirements, ratio float64) error { </ins> // find the max, if the node has the max,use the one, if not,use the ratio parameter <del> var maxCpuFraction, maxMemFraction float64 = ratio, ratio </del> <ins> var maxCPUFraction, maxMemFraction float64 = ratio, ratio </ins> var cpuFractionMap = make(map[string]float64) var memFractionMap = make(map[string]float64) for _, node := range nodes { cpuFraction, memFraction := computeCpuMemFraction(cs, node, requestedResource) cpuFractionMap[node.Name] = cpuFraction memFractionMap[node.Name] = memFraction <del> if cpuFraction > maxCpuFraction { maxCpuFraction = cpuFraction </del> <ins> if cpuFraction > maxCPUFraction { maxCPUFraction = cpuFraction </ins> } if memFraction > maxMemFraction { maxMemFraction = memFraction } } // we need the max one to keep the same cpu/mem use rate <del> ratio = math.Max(maxCpuFraction, maxMemFraction) </del> <ins> ratio = math.Max(maxCPUFraction, maxMemFraction) </ins> for _, node := range nodes { memAllocatable, found := node.Status.Allocatable["memory"] Expect(found).To(Equal(true))

Discussion:
Chronically failing test. Perhaps covers deprecated behavior? /sig scalability /assign
shows up in
/sig scheduling is one of scheduling e2e test.
/assign I'll check this one.
According to the log, the balanced pods were not created by scheduler, the cpu/mem usage was unchanged.
This test failing every other run. Fix or disable? Blocking 1.7?
similar to , move to 1.8, but I'll still working on that.
Change:
MaxContainerCount:       *maxContainerCount, Runonce:                 *runonce, Port:                    *port, <ins> CAdvisorPort:            *cAdvisorPort, </ins> EnableServer:            *enableServer, EnableDebuggingHandlers: *enableDebuggingHandlers, DockerClient:            kubelet.ConnectToDockerOrDie(*dockerEndpoint),

Discussion:
Currently, kubelet uses a for communicating with cAdvisor. , were having an issue because we didn't realize making port available was required for kubernetes.
I prefer not do this since we plan to make 4194 publically reserved port for cAdvisor. Also cAdvisor is the default deamon running on every node of a kubernetes cluster. The issue you encountered sounds like a bad document issue we had for cAdvisor. We should fix the document instead of allow the port being configurable.
can you expound on 'bad document' issue?
Change:
} } <ins> func makeContainersByQOS(class v1.PodQOSClass) []v1.Container { resource := newResourceList("100m", "1Gi", "") switch class { case v1.PodQOSGuaranteed: return []v1.Container{newContainer("guaranteed-container", resource, resource)} case v1.PodQOSBurstable: return []v1.Container{newContainer("burtable-container", resource, nil)} case v1.PodQOSBestEffort: fallthrough default: return []v1.Container{newContainer("best-effort-container", nil, nil)} } } func TestAdmitUnderNodeConditions(t *testing.T) { manager := &managerImpl{} pods := []*v1.Pod{ newPod("guaranteed-pod", scheduling.DefaultPriorityWhenNoDefaultClassExists, makeContainersByQOS(v1.PodQOSGuaranteed), nil), newPod("burstable-pod", scheduling.DefaultPriorityWhenNoDefaultClassExists, makeContainersByQOS(v1.PodQOSBurstable), nil), newPod("best-effort-pod", scheduling.DefaultPriorityWhenNoDefaultClassExists, makeContainersByQOS(v1.PodQOSBestEffort), nil), } expected := []bool{true, true, true} for i, pod := range pods { if result := manager.Admit(&lifecycle.PodAdmitAttributes{Pod: pod}); expected[i] != result.Admit { t.Errorf("Admit pod: %v, expected: %v, actual: %v", pod, expected[i], result.Admit) } } manager.nodeConditions = []v1.NodeConditionType{v1.NodeMemoryPressure} expected = []bool{true, true, false} for i, pod := range pods { if result := manager.Admit(&lifecycle.PodAdmitAttributes{Pod: pod}); expected[i] != result.Admit { t.Errorf("Admit pod: %v, expected: %v, actual: %v", pod, expected[i], result.Admit) } } manager.nodeConditions = []v1.NodeConditionType{v1.NodeMemoryPressure, v1.NodeDiskPressure} expected = []bool{false, false, false} for i, pod := range pods { if result := manager.Admit(&lifecycle.PodAdmitAttributes{Pod: pod}); expected[i] != result.Admit { t.Errorf("Admit pod: %v, expected: %v, actual: %v", pod, expected[i], result.Admit) } } } </ins> // parseQuantity parses the specified value (if provided) otherwise returns 0 value func parseQuantity(value string) resource.Quantity { if len(value) == 0 {

Discussion:
<!-- STOP -- PLEASE READ! GitHub is not the right place for support requests. If you're looking for help, check and the . You can also post your question on the or the forum. If the matter is security related, please disclose it privately via --In the code below, kubelet rejects pods with QOS type guaranteed when under disk pressure, but when kubelet is also under memory pressure, those pods are accepted, is this behavior expected? Why is that?
/area kubelet /sig node
See this comment: It came with commit
you can find an answer from the proposal doc:
thank you ! I think current code is not following the eviction design of condition. the proposal is: but the code is: , guaranteed pods are not rejected any more. seems to be working fine though, maybe here's the reason: PS: above content can be found in
Change:
rbac.NewRule("create", "get", "list", "watch").Groups(legacyGroup).Resources("nodes").RuleOrDie(), // TODO: restrict to the bound node once supported rbac.NewRule("update", "patch").Groups(legacyGroup).Resources("nodes/status").RuleOrDie(), <ins> rbac.NewRule("update", "patch", "delete").Groups(legacyGroup).Resources("nodes").RuleOrDie(), </ins> // TODO: restrict to the bound node as creator once supported rbac.NewRule("create", "update", "patch").Groups(legacyGroup).Resources("events").RuleOrDie(),

Discussion:
What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): kubelet RBAC Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG Kubernetes version (use ): Environment: Cloud provider or hardware configuration: GCE Install tools: make quick-release && go run -up What happened: I upgraded the cluster with After which the master node was not ready. What you expected to happen: I expected the master node to be ready. How to reproduce it (as minimally and precisely as possible): Anything else we need to know: In the api server logs: In the kubelet logs:
cc since you were running into this.
cc
c.f. it seems wrong for the node to delete itself
In the case where a kubelet starts up and sees a mismatch between the externalid field and its own idea of what its external id is, it is trying to delete itself. Questions I have: what can make the external id mismatch occur (in cloudprovider and non-cloudprovider cases)? is it even safe for a kubelet to summarily delete itself (as it is trying to do today), or can that mess up apiserver/controller logic around node cleanup, like the attach/detach controller, etc? can we limit the node to reporting the mismatch by updating node status and stay in the tryRegisterWithApiServer loop, and let something like the node controller remove a node that gets in this situation instead? cc
happens in both GCE and GKE upgrades. who can update node status. I would view this as strictly worse than giving kubelets node delete privileges.
If a node instance is recreated with the same name, it will register as the same node. This apparently also happens in tests (). AFAIK, attach/detach controller annotates the node object to keep states. If the node is backed by a new (VM) instance, it is probably safe/better to recreate the node object and start afresh. Of course, upon any node update/delete/add events, the detach/attach controller should examine and reconcile the status. Hm......AFAIK node controller also does not coordinate with other controllers (e.g., detach/attach). I am not sure how this would help the second point you made.

would you be ok with adding delete permissions for kubelet because it has them and uses them today, and then taking the argument about whether it should be done another way to it's own issue?
yeah, convinced me that if the node is the authority of the spec during self-registration cases, update/delete permissions are reasonable, and we'd need to figure out how to scope those to update/delete self in the future, just like we do for update status
see
Change:
func ReadOrDie(filePath string) []byte { data, err := Read(filePath) if err != nil { <del> ginkgo.Fail(err.Error(), 1) </del> <ins> e2elog.Fail(err.Error(), 1) </ins> } return data }

Discussion:
/help /kind cleanup /area e2e-testing-framework mini guide: make sure you have signed the CNCF clone kubernetes;/kubernetes search for ginkgo.Fail calls under test/e2e/framework e.g. replace them with this that was in this PR: send a PR for kubernetes/kubernetes
/remove-kind feature /area e2e-test-framework
/sig testing
I will take this.
thank you! Please feel free to ping #testing-commons in the Kubernetes slack if you have any questions :smiley: /cc
/remove-help
/assign
Change:
"//staging/src/k8s.io/apimachinery/pkg/util/wait:go_default_library", "//staging/src/k8s.io/apiserver/pkg/endpoints/metrics:go_default_library", "//staging/src/k8s.io/apiserver/pkg/server/httplog:go_default_library", <del> "//staging/src/k8s.io/client-go/informers:go_default_library", </del> "//vendor/k8s.io/klog/v2:go_default_library", ], )

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: for extension API server panics with: Apparently introduces this panic with . What you expected to happen: to do not panic. How to reproduce it (as minimally and precisely as possible): extension API server with - for example the endpoint that the apiserver panics with Anything else we need to know?: Environment: 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:
/kind regression
/sig api-machinery
/assign
cc
Oops - sorry for that. It seems it is basically this comment: that I blindly applied without e2e retesting (the problem seem to be lack of tests, which is a bit surprising because bugs in my previous implementations were caught by tests). ^^ BTW - this has been cherrypicked to previous releases: 16: 17: 18: so it's actually even more critical...
I can file the automated cherry-pick PRs once the PR against the master branch is merged. :)
Reopening - since we need to cherrypick it still.
I now opened the cherry-picks: 16 - 17 - 18 -
Fix and picks are merged
Change:
} } <ins> func TestRemoveDuplicateAltNames(t *testing.T) { tests := []struct { args *certutil.AltNames want *certutil.AltNames }{ { &certutil.AltNames{}, &certutil.AltNames{}, }, { &certutil.AltNames{ DNSNames: []string{"a", "a"}, IPs:      []net.IP{{127, 0, 0, 1}}, }, &certutil.AltNames{ DNSNames: []string{"a"}, IPs:      []net.IP{{127, 0, 0, 1}}, }, }, { &certutil.AltNames{ DNSNames: []string{"a"}, IPs:      []net.IP{{127, 0, 0, 1}, {127, 0, 0, 1}}, }, &certutil.AltNames{ DNSNames: []string{"a"}, IPs:      []net.IP{{127, 0, 0, 1}}, }, }, { &certutil.AltNames{ DNSNames: []string{"a", "a"}, IPs:      []net.IP{{127, 0, 0, 1}, {127, 0, 0, 1}}, }, &certutil.AltNames{ DNSNames: []string{"a"}, IPs:      []net.IP{{127, 0, 0, 1}}, }, }, } for _, tt := range tests { RemoveDuplicateAltNames(tt.args) if !reflect.DeepEqual(tt.args, tt.want) { t.Errorf("Wanted %v, got %v", tt.want, tt.args) } } } </ins>

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: Duplicate altnames in certs which generated by kubeadm ! What you expected to happen: No Duplicate altnames in certs which generated by kubeadm How to reproduce it (as minimally and precisely as possible): Anytime Anything else we need to know?: ! Environment: 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:
/sig cluster-lifecycle
/area kubeadm
Can you describe your detailed usage scenarios and reproduction steps, and explain the kubernetes version so that we can quickly locate
Thank for your response! I have found why and will fix it soon.
i have commented on the PR. /priority awaiting-more-evidence
/remove-priority awaiting-more-evidence /priority backlog
Change:
"//pkg/kubelet/types:go_default_library", "//pkg/security/apparmor:go_default_library", "//staging/src/k8s.io/api/core/v1:go_default_library", <ins> "//staging/src/k8s.io/api/scheduling/v1beta1:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/api/equality:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/api/errors:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/api/resource:go_default_library",

Discussion:
https://k8s- The following tests are broken: NVIDIA GPU Device Plugin PriorityLocalStorageEvictionOrdering PriorityMemoryEvictionOrdering Looks like some new validation was to prevent two things: PodPriority directly system-critical priority classes outside of the kube-system namespace. To fix this, we need to create new priority classes for these tests. cc /kind failing-test /sig node /sig scheduling /priority important-soon
/kind bug
/assign
This doesn't appear to have fixed the tests. Tests now panic during the Aftereach in which the PriorityClass is deleted. /reopen
Panic:
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
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
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /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:
$ kubectl create -f /tmp/secret.json secret "nginxsecret" created <del> $ kubectl create configmap nginxconfigmap --from-file=examples/https-nginx/default.conf </del> <ins> $ kubectl create configmap nginxconfigmap --from-file=examples/https-nginx/default.conf </ins> configmap "nginxconfigmap" created ```

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT on sample file I was using the /examples/https-nginx sample application for some small testing purposes and was surprised by the relative high load it kept having in the nginx pods. After some inspection I found out that kubernetes/examples/https-nginx/auto-reload- is basically running a busy loop. the command doesn't filter out some of the events it should filter out. At least on my system with just this sample config I always get a OPEN on basically immediately so I would recommend adding as arguments to the inotifywait command
I can take this.
I already have a PR in flight for this.
OK thanks for info
Change:
if len(address.Hostname) > 0 { allErrs = append(allErrs, ValidateDNS1123Label(address.Hostname, fldPath.Child("hostname"))...) } <del> // During endpoint update, validate NodeName is DNS1123 compliant and transition rules allow the update </del> <ins> // During endpoint update, verify that NodeName is a DNS subdomain and transition rules allow the update </ins> if address.NodeName != nil { <del> allErrs = append(allErrs, ValidateDNS1123Label(*address.NodeName, fldPath.Child("nodeName"))...) </del> <ins> for _, msg := range ValidateNodeName(*address.NodeName, false) { allErrs = append(allErrs, field.Invalid(fldPath.Child("nodeName"), *address.NodeName, msg)) } </ins> } allErrs = append(allErrs, validateEpAddrNodeNameTransition(address, ipToNodeName, fldPath.Child("nodeName"))...) if len(allErrs) > 0 {

Discussion:
introduced a new requirement for node names to be DNS1123Labels. In case of hack/local-up-, an IP address is used as node name and thus endpoints aren't created for services, e.g. kube-dns doesn't work anymore. There are other projects that use IP addresses as node names for running simplified k8s dev environment: Probably there are other projects where it's convenient to have just an IP address as a node name. Verified against . On affected installs, service latency e2e test hangs, see e.g. Example ( some newlines):
Change:
} } // TODO: Once we get rid of /healthz consider changing this to post-start-hook. <del> err := s.addReadyzChecks(healthz.NewInformerSyncHealthz(c.SharedInformerFactory)) </del> <ins> err := s.AddReadyzChecks(healthz.NewInformerSyncHealthz(c.SharedInformerFactory)) </ins> if err != nil { return nil, err }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : When using GenericAPIServer you can only add new checks via function which adds them to all , , and endpoints. All other methods like are private. I would like to request those methods to be made public: Why is this needed: Developers of apiservers should be able to define their readiness probes add them to specific endpoint of their choosing. For example in case of Metrics Server we defined probes: Readiness - Metrics cache is full. As MS serves data only from cache, traffic will be only sent after cache is full. Liveness - Metric scraping loop is not deadlocked. It doesn't make sense to have those probes to both endpoints. Not ready metric cache should not cause MS being killed via liveness probe. Delayed scrape should not cause traffic not being served from cache due failing readiness probe. /assign
/sig apimachinery
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig apimachinery 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 api-machinery
/cc /triage accepted
I can see this. PR welcome.
Change:
BeforeEach(func() { nodes, err := framework.Client.Nodes().List(labels.Everything(), fields.Everything()) expectNoError(err) <del> numNodes = len(nodes.Items) </del> nodeNames = sets.NewString() for _, node := range nodes.Items { nodeNames.Insert(node.Name)

Discussion:
For example: I'm disabling the test in But we need to re-enable it, or roll-back the test.
fyi
Shouldn't this is part slow test, and the fix should be either: 1) Increase Kubernetes-e2-gke-ci timeout value if decide to include slow to that project or 2) disable all slow tests on that project? cc/ Which one is required here?
The test runs 50 pods per node, which is over the default --max-pod limit of kubelet. The test relies on the flag --max-pods=100 being set in cluster/gce/config- I will disable it for all GKE tests in On the other hand, it's not clear to me where the timeout is set for a specific build. /cc
Timeouts for each Jenkins build are in the Jenkins project configurations themselves, which are not currently saved in version control anywhere. :
Discussed with about the test offline. There are several issues: Do we want to run any kind of kubelet resource monitoring test on GKE? Is it useful? We only override max-pods in GCE. Should the test itself figure out what platform it can run based on the #pods in the test (see ) Per-test configuration allows greater flexibility (e.g., we may run 100 pods on GCE to test kubelet's scalability), but it'd make the tests more complicated as they need to be aware of the test environment (which many e2e tests already do); there is also the burden of updating the tests once the max-pod value changes. Does this test belong to SLOW tests or should it belong to a new category? Not all slow tests have the same attributes. Arguably this test could be enabled only on selective builds. The downside would be more flags -- less readable/manageable e2e configs. Not all builds which run SLOW tests have the proper timeout value to run this test. We need to manually change them every time a slow test is . Re-assigning this back to since she has more concerns about the PR.
Had offline discussion with We are going to split current Kubelet resource usage tracking test into two, one is targeted for GCE, another one is for GKE. In this case, we won't mess up the test code itself by introducing knobs. Re-assign this back to
Change:
Versions:         expAPIVersions, PreferredVersion: unversioned.GroupVersion{GroupVersion: storageVersion, Version: apiutil.GetVersion(storageVersion)}, } <del> apiserver.AddGroupWebService(m.handlerContainer, c.APIGroupPrefix+"/"+latest.GroupOrDie("extensions").Group+"/", group) </del> <ins> apiserver.AddGroupWebService(m.handlerContainer, c.APIGroupPrefix+"/"+latest.GroupOrDie("extensions").Group, group) </ins> allGroups = append(allGroups, group) apiserver.InstallServiceErrorHandler(m.handlerContainer, m.newRequestInfoResolver(), []string{expVersion.Version}) }

Discussion:
Loading returns Looking at the code is registered in the same way as which works fine. So not sure why is this broken.
Change:
import ( "errors" "os" <ins> "github.com/golang/glog" </ins> ) type Mounter struct { mounterPath string } <ins> var unsupportedErr = errors.New("util/mount on this platform is not supported") </ins> // New returns a mount.Interface for the current system. // It provides options to override the default mounter behavior. // mounterPath allows using an alternative to `/bin/mount` for mounting.

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Calls to on unsupported platforms do not report any error and potentially misbehave. What you expected to happen: I would expect an error to be reported, that can be consumed by the caller. How to reproduce it (as minimally and precisely as possible): for and were failing on darwin, and no error was being reported. See: & Environment: OS (e.g. from /etc/os-release): I have been testing on osx/darwin, which is not a supported platform.
/sig storage
/assign