jiebi/CodeConvo huggingface dataset:
Code change:
<!-- Please only use this template for submitting enhancement requests --The built-in and cluster roles here are deprecated in 1.13 when this issue was resolved: /sig storage /milestone v1.17 /priorit important-longterm
You must be a member of the GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your and have them propose you as an additional delegate for this responsibility. <detailsIn response to : <!-- Please only use this template for submitting enhancement requests -- /milestone v1.17 /priorit important-longterm 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 /priority important-longterm
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
/remove-lifecycle stale /assign
Bug triage for 1.17 here with a gentle reminder that code freeze for this release is on November 14. Is this issue still intended for 1.17?

Related discussion:
text: Rules:      kubeSchedulerRules, }) <del> externalProvisionerRules := []rbacv1.PolicyRule{ rbacv1helpers.NewRule("create", "delete", "get", "list", "watch").Groups(legacyGroup).Resources("persistentvolumes").RuleOrDie(), rbacv1helpers.NewRule("get", "list", "watch", "update", "patch").Groups(legacyGroup).Resources("persistentvolumeclaims").RuleOrDie(), rbacv1helpers.NewRule("list", "watch").Groups(storageGroup).Resources("storageclasses").RuleOrDie(), rbacv1helpers.NewRule("get", "list", "watch", "create", "update", "patch").Groups(legacyGroup).Resources("events").RuleOrDie(), rbacv1helpers.NewRule("get", "list", "watch").Groups(legacyGroup).Resources("nodes").RuleOrDie(), } if utilfeature.DefaultFeatureGate.Enabled(features.CSINodeInfo) { externalProvisionerRules = append(externalProvisionerRules, rbacv1helpers.NewRule("get", "watch", "list").Groups("storage.k8s.io").Resources("csinodes").RuleOrDie()) } roles = append(roles, rbacv1.ClusterRole{ // a role for the csi external provisioner ObjectMeta: metav1.ObjectMeta{Name: "system:csi-external-provisioner"}, Rules:      externalProvisionerRules, }) </del> addClusterRoleLabel(roles) return roles }
Code change:
<!-- Please only use this template for submitting enhancement requests --The built-in and cluster roles here are deprecated in 1.13 when this issue was resolved: /sig storage /milestone v1.17 /priorit important-longterm
You must be a member of the GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your and have them propose you as an additional delegate for this responsibility. <detailsIn response to : <!-- Please only use this template for submitting enhancement requests -- /milestone v1.17 /priorit important-longterm 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 /priority important-longterm
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
/remove-lifecycle stale /assign
Bug triage for 1.17 here with a gentle reminder that code freeze for this release is on November 14. Is this issue still intended for 1.17?

Related discussion:
text: creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults <del> name: system:csi-external-attacher rules: - apiGroups: - "" resources: - persistentvolumes verbs: - get - list - patch - update - watch - apiGroups: - "" resources: - nodes verbs: - get - list - watch - apiGroups: - storage.k8s.io resources: - volumeattachments verbs: - get - list - patch - update - watch - apiGroups: - "" resources: - events verbs: - create - get - list - patch - update - watch - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults name: system:csi-external-provisioner rules: - apiGroups: - "" resources: - persistentvolumes verbs: - create - delete - get - list - watch - apiGroups: - "" resources: - persistentvolumeclaims verbs: - get - list - patch - update - watch - apiGroups: - storage.k8s.io resources: - storageclasses verbs: - list - watch - apiGroups: - "" resources: - events verbs: - create - get - list - patch - update - watch - apiGroups: - "" resources: - nodes verbs: - get - list - watch - apiGroups: - storage.k8s.io resources: - csinodes verbs: - get - list - watch - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults </del> name: system:discovery rules: - nonResourceURLs:
Code change:
<!-- 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: kubelet terminated unexpectedly during hack/local-up-cluster kubelet log as a result apiserver cannot find the node to schedule pods What you expected to happen: kubelet runs successfully and hack/local-up-cluster creates a single node cluster How to reproduce it (as minimally and precisely as possible): run hack/local-up-cluster from HEAD Anything else we need to know?: additional cgroups check seemed to be introduced in ; hack/local-up-cluster works when I check out the parent commit have CI for hack/local-up-cluster and , so I'm not sure if it's an error on my side. It would be greatly appreciated if someone could explain it to me Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Debian GNU/Linux Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig node cc
Thanks for raising such a detailed issue! cc any thoughts here? Confusingly, I think the kubelet has been assigned a different cgroup for memory and for cpu... however the fact that its using makes me think the user is relying on system defaults. out of curiosity, have you made any mods to how your system assigns cgroups?
It sounds like we might want to handle the error more gracefully. If we can't get the kubelet's cgroup, we should fall back to collecting metrics from all cgroups.
collecting metrics from all the cgroups on the system? Any concerns about how many cgroups there could be? Also, or any interest in implementing this fix (assuming we go with the fallback behavior)? If not, I can try.
thanks for looking into this! Sorry I'm not familiar with cgroups. I'm don't know any modification to my system assigns cgroups in particular
I can put out a PR this week
xref
Thanks!

Related discussion:
text: cgroupRoots = append(cgroupRoots, cm.NodeAllocatableRoot(s.CgroupRoot, s.CgroupDriver)) kubeletCgroup, err := cm.GetKubeletContainer(s.KubeletCgroups) if err != nil { <del> return fmt.Errorf("failed to get the kubelet's cgroup: %v", err) } if kubeletCgroup != "" { </del> <ins> klog.Warningf("failed to get the kubelet's cgroup: %v.  Kubelet system container metrics may be missing.", err) } else if kubeletCgroup != "" { </ins> cgroupRoots = append(cgroupRoots, kubeletCgroup) } runtimeCgroup, err := cm.GetRuntimeContainer(s.ContainerRuntime, s.RuntimeCgroups) if err != nil { <del> return fmt.Errorf("failed to get the container runtime's cgroup: %v", err) } if runtimeCgroup != "" { </del> <ins> klog.Warningf("failed to get the container runtime's cgroup: %v. Runtime system container metrics may be missing.", err) } else if runtimeCgroup != "" { </ins> // RuntimeCgroups is optional, so ignore if it isn't specified cgroupRoots = append(cgroupRoots, runtimeCgroup) }
Code change:
Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /sig instrumentation /assign
GitHub didn't allow me to assign the following users: solodov. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /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
recommends that we generate those metrics in the GenericPLEG during the relist. We can generate the data directly from the pods call there ().
I would be interested to work on this issue if no one else is working on it currently
Go for it!
/assign

Related discussion:
text: }, []string{"runtime_handler"}, ) <ins> // RunningPodCount is a gauge that tracks the number of Pods currently running RunningPodCount = metrics.NewGauge( &metrics.GaugeOpts{ Subsystem:      KubeletSubsystem, Name:           "running_pod_count", Help:           "Number of pods currently running", StabilityLevel: metrics.ALPHA, }, ) // RunningContainerCount is a gauge that tracks the number of containers currently running RunningContainerCount = metrics.NewGaugeVec( &metrics.GaugeOpts{ Subsystem:      KubeletSubsystem, Name:           "running_container_count", Help:           "Number of containers currently running", StabilityLevel: metrics.ALPHA, }, []string{"container_state"}, ) </ins> ) var registerMetrics sync.Once
Code change:
Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /sig instrumentation /assign
GitHub didn't allow me to assign the following users: solodov. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /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
recommends that we generate those metrics in the GenericPLEG during the relist. We can generate the data directly from the pods call there ().
I would be interested to work on this issue if no one else is working on it currently
Go for it!
/assign

Related discussion:
text: legacyregistry.MustRegister(CgroupManagerDuration) legacyregistry.MustRegister(PodWorkerStartDuration) legacyregistry.MustRegister(ContainersPerPodCount) <del> legacyregistry.RawMustRegister(newPodAndContainerCollector(containerCache)) </del> legacyregistry.MustRegister(PLEGRelistDuration) legacyregistry.MustRegister(PLEGDiscardEvents) legacyregistry.MustRegister(PLEGRelistInterval)
Code change:
Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /sig instrumentation /assign
GitHub didn't allow me to assign the following users: solodov. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /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
recommends that we generate those metrics in the GenericPLEG during the relist. We can generate the data directly from the pods call there ().
I would be interested to work on this issue if no one else is working on it currently
Go for it!
/assign

Related discussion:
text: legacyregistry.MustRegister(DeprecatedEvictionStatsAge) legacyregistry.MustRegister(DeprecatedDevicePluginRegistrationCount) legacyregistry.MustRegister(DeprecatedDevicePluginAllocationLatency) <ins> legacyregistry.MustRegister(RunningContainerCount) legacyregistry.MustRegister(RunningPodCount) </ins> if utilfeature.DefaultFeatureGate.Enabled(features.DynamicKubeletConfig) { legacyregistry.MustRegister(AssignedConfig) legacyregistry.MustRegister(ActiveConfig)
Code change:
Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /sig instrumentation /assign
GitHub didn't allow me to assign the following users: solodov. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /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
recommends that we generate those metrics in the GenericPLEG during the relist. We can generate the data directly from the pods call there ().
I would be interested to work on this issue if no one else is working on it currently
Go for it!
/assign

Related discussion:
text: deps = [ "//pkg/kubelet/container:go_default_library", "//pkg/kubelet/container/testing:go_default_library", <ins> "//pkg/kubelet/metrics:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/types:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/clock:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/diff:go_default_library", <ins> "//vendor/github.com/prometheus/client_model/go:go_default_library", </ins> "//vendor/github.com/stretchr/testify/assert:go_default_library", ], )
Code change:
Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /sig instrumentation /assign
GitHub didn't allow me to assign the following users: solodov. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /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
recommends that we generate those metrics in the GenericPLEG during the relist. We can generate the data directly from the pods call there ().
I would be interested to work on this issue if no one else is working on it currently
Go for it!
/assign

Related discussion:
text: g.updateRelistTime(timestamp) pods := kubecontainer.Pods(podList) <ins> // update running pod and container count updateRunningPodAndContainerMetrics(pods) </ins> g.podRecords.setCurrent(pods) // Compare the old and the current pods, and generate events.
Code change:
Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /sig instrumentation /assign
GitHub didn't allow me to assign the following users: solodov. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /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
recommends that we generate those metrics in the GenericPLEG during the relist. We can generate the data directly from the pods call there ().
I would be interested to work on this issue if no one else is working on it currently
Go for it!
/assign

Related discussion:
text: return state } <ins> func updateRunningPodAndContainerMetrics(pods []*kubecontainer.Pod) { // Set the number of running pods in the parameter metrics.RunningPodCount.Set(float64(len(pods))) // intermediate map to store the count of each "container_state" containerStateCount := make(map[string]int) for _, pod := range pods { containers := pod.Containers for _, container := range containers { // update the corresponding "container_state" in map to set value for the gaugeVec metrics containerStateCount[string(container.State)]++ } } for key, value := range containerStateCount { metrics.RunningContainerCount.WithLabelValues(key).Set(float64(value)) } } </ins> func (pr podRecords) getOld(id types.UID) *kubecontainer.Pod { r, ok := pr[id] if !ok {
Code change:
Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /sig instrumentation /assign
GitHub didn't allow me to assign the following users: solodov. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /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
recommends that we generate those metrics in the GenericPLEG during the relist. We can generate the data directly from the pods call there ().
I would be interested to work on this issue if no one else is working on it currently
Go for it!
/assign

Related discussion:
text: "testing" "time" <ins> dto "github.com/prometheus/client_model/go" </ins> "github.com/stretchr/testify/assert" "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/clock" "k8s.io/apimachinery/pkg/util/diff" kubecontainer "k8s.io/kubernetes/pkg/kubelet/container" containertest "k8s.io/kubernetes/pkg/kubelet/container/testing" <ins> "k8s.io/kubernetes/pkg/kubelet/metrics" </ins> ) const (
Code change:
What happened: tried promoting a test with a tag in its full test description. The hierarchy of ginko-relevant AST's was . The tag was a in the top level . The full test description only came from , so the tag was missed. What you expected to happen: The conformance test list generator should have logged and ERROR and failed a test on the PR, calling out Disruptive as an invalid tag How to reproduce it (as minimally and precisely as possible): Check out locally and follow the directions in to generate the conformance list. The invalid test is in the list. Anything else we need to know?: Is there a function we can use to get the full test description from Ginkgo instead of rolling our own? If not, we should probably be maintaining a stack rather than just the last FYI who ran into this FYI who wrote the code to keep track of last
/sig architecture /area conformance
/milestone v1.16
/priority important-soon
/assign
GitHub didn't allow me to assign the following users: devaips. Note that only and repo collaborators can be assigned and that 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

Related discussion:
text: ) const regexDescribe = "Describe|KubeDescribe|SIGDescribe" <del> const regexContext = "Context" </del> <ins> const regexContext = "^Context$" </ins> type visitor struct { <del> FileSet      *token.FileSet lastDescribe describe cMap         ast.CommentMap </del> <ins> FileSet   *token.FileSet describes []describe cMap      ast.CommentMap </ins> //list of all the conformance tests in the path tests []conformanceData } //describe contains text associated with ginkgo describe container type describe struct { <ins> rparen      token.Pos </ins> text        string lastContext context }