Good First Issues in Jinja

What would you like to be added Extract the tasks related to DNS management from kubernetes/preinstall in a new role, and change the playbooks using it (cluster.yml, upgrade-cluster.yml, check also the others) accordingly. Why is this needed A number of include in kubernetes preinstall are guarded with a when: not dns_late. This is because the role is reused at the end of kubespray playbook to finish DNS configuration after the cluster configuration has been setup. This is however bad architecture. There is no reason to couple DNS config like this, and we could instead have a specific role to call at the end of the playbooks. The tasks related to DNS in kubernetes/preinstall should therefore be extracted in a new role, which will replace kubernetes/preinstall where it is invoked with dns_late: true. /good-first-issue

What would you like to be added Bump the default CRI-O version from v1.36.3 to v1.36.4. Add v1.36.4 checksums to roles/kubespray_defaults/vars/main/checksums.yml using the update-hashes tool Ensure the derived default crio_version resolves to v1.36.4 Run propagate-ansible-variables to update generated version references Release notes: https://github.com/cri-o/cri-o/releases/tag/v1.36.4 Diff: cri-o/[email protected] Why is this needed CRI-O v1.36.4 fixes a nil pointer dereference in ListPodSandboxStats when a container cgroup is removed during teardown. It also adds per-container targeting for CPU load balancing, IRQ load balancing, and CPU quota annotations. Keeping CRI-O on the latest 1.36 patch release reduces runtime crash risk and brings the current upstream fixes to Kubespray users.

The spec currently says: "Events SHOULD NOT use body except to represent a string display message of the event." I think there should be more guidance for instrumentations - should it be optional, recommended, or required? Should the description be defined as part of every event's sem conventions, similar to span names? Related issues: #3343 open-telemetry/opentelemetry-browser#282

What happened? Kubespray generates different ownership and permissions for etcd certificates on the first control-plane/etcd node compared to the remaining control-plane nodes. First control plane / etcd node shows following ownership and permissions for pem certificates in /etc/ssl/etcd/ssl/ -rw------- root root for *key.pem and -rw-r--r-- root root for pem files. Additional control planes / etcd nodes shows following: -rw-r----- etcd root for all *.pem files This is reproducible on all our cluster (4 clusters). Issue is probably because certificates seems to be generated on the first node, and only then copied with appropriate permissions and ownership to other nodes. If my understanding is right than they get generated in task roles/etcd/tasks/gen_certs_script.yml in task name Gen_certs | run cert generation script for etcd and kube control plane nodes and then copied to other nodes with task name name: Gen_certs | Write etcd member/admin and kube_control_plane client certs to other

What happened? Hi all, we are trying setting up our airgapped cluster using: KUBESPRAY 2.31.0 K8S: 1.35.0 Our cluster is not open to internet public registries and uses an AZURE ACR as pull-through cache. Due to this infrastructure configuration we are working with following variables: download_run_once: true download_localhost: true download_force_cache: true download_cache_dir: /opt/gitlab-runner/ansible/kubespray_cache download_container: true Containerd is hosted on our ansible controller host and always succeeds pulling from acr. Some months ago we have tried to setup and upgrade the cluster with kubespray 2.29 and 2.30, but always failed at download container time with error like the following: ctr: failed to get reader: content digest sha256:045fc1c20da893bef6d0ed64e92b243213b0cebcd478389573bdfb095e212a98: not found We have added some tasks before kubespray playbook execution to be sure to have the registry completely clean/empty and then we succeeded. We were pretty sure to h

Forked from #3627 (comment) In #3627, I want users to be able to opt-in to more detailed label values. This primarily because the "detailed" values are not a stable API provided by the Go runtime, and I would like to avoid exposing the detailed values to users by default. The solution i've come up with is to have two labels: go.memory.type, and go.memory.detailed_type, where the detailed_type label is opt-in. Questions: Is this an acceptable pattern to use? Is there an alternative I should consider instead? Is this something we should codify in the semantic conventions guidelines? cc @kamphaus

Problem There are two related problems that stem from the same root cause: the aggregation interval is not part of the metric's schema. Metric name proliferation Some metrics are already aggregated at the source over a fixed time window. Without a dedicated field for the interval, the current option is to encode it in the metric name. For example, the hostmetrics CPU load average is reported as three separate metrics: system.cpu.load_average.1m system.cpu.load_average.5m system.cpu.load_average.15m The same pattern appears in the JVM conventions with jvm.system.cpu.load_1m. For load averages this is manageable since the OS only provides three fixed windows (1, 5, and 15 minutes). But for other sources like Linux PSI metrics, which have pressure values at 10s, 1m, and 5m windows across four resource types (CPU, memory, IO, IRQ) and two stall types (some, full), this pattern produces 24 nearly identical metrics differentiated only by a name suffix: system.cpu.linux.pressure.10s syst

What would you like to be added Metallb included is dated Oct 20, 2023, there was a few releases back then. Any specific reason to use an d version? Shouldn't be keep update? Why is this needed Just to make sure use latest technology available, general bugfix from streamline package and maintain high level of security I think packages should be updated to reflect state of art of their own lifecycle

What would you like to be added Basically: ansible-collections/community.general#10920 (Upstreaming the strategy into community.general would also work) Once we switch to collection only (#12227 ) we'll be able to handle ansible plugins more easily. WARNING: This is not an easy task, and requires to dive deep into Ansible internals and do a fair bit of Python. This not at all a "good first issue" Why is this needed There is 2 purpose for this strategy: faster cluster upgrade, because there is no longer a "all nodes in a batch wait for all other nodes" bottleneck. make possible cluster upgrades with bigger "batch size" (currently, a PodDisruptionBudbget can block your upgrade if enoug eligible nodes for a deployment are in the same batch. With that scenario, some of the nodes where the eviction succeded would finish instead of waiting of the rest of the batch, allowing pods to be scheduled on them and the other node drain to succeed). /lifecycle frozen /help

What would you like to be added Kubespray currently exposes several variables related to the loadbalancer of the apiserver (which can be configured separately by the user, or handled with a localhost LB on each node). Those are: loadbalancer_apiserver.address: loadbalancer_apiserver.port: apiserver_loadbalancer_domain_name: kubeadm_config_api_fqdn: # mostly internal use These variables are inconsistent and should to be changed, to use two variables only in all Kubespray # variables names are only suggestionsu kube_apiserver_endpoint: # used to access the api from outside. Should use sane default for HA, non HA, localhost LB. kube_apiserver_cluster_internal_endpoint: # used to access the api from inside the cluster (nodes, pod with hostNetwork). Optionnal, default to kube_apiserver_endpoint / localhost LB. Steps to make the changes: Come up with good variables names, replace in kubespray_defaults/defaults/main/main.yml Replace all use sites in kubespray. Update the documentation in doc