berops/claudie

Current Behaviour DynamicNodePool.AutoscalerConfig is optional, but two definitions of "defined" are in play. The struct tags treat any non-zero block as present, so required_without=Count is satisfied and count is no longer required. Runtime uses isDefined() (Min >= 0 && Max > 0). A block that is non-zero but not usable passes validation, is then ignored by CreateNodepools, and the nodepool is created with count: 0 and no autoscaler. No error anywhere. Accepted today: autoscaler: {min: 3} (max omitted) autoscaler: {min: -1, max: 5} autoscaler: {max: -3} autoscaler: {min: 5, max: 2} is usable per isDefined() and reaches the cluster-autoscaler with min > max. Expected Behaviour A non-zero autoscaler block must be usable: 0 <= min <= max <= 255 and max >= 1, otherwise validation fails. Omitting the block keeps requiring count. min: 0 stays valid for scale-from-zero. Steps To Reproduce Define a dynamic nodepool with autoscaler: {min: 3} and no count. Apply the InputManifest. Validation

Current Behaviour validateExternalNet (internal/api/manifest/validate_node_pool.go, api/manifest/... after #2216) compares ProviderSpec.Name with the literal "openstack". ProviderSpec.Name is the provider instance name, so: an OpenStack provider named anything else (e.g. openstack-1, as in the docs example) skips the check and externalNetworkName is never required; a non-OpenStack provider that happens to be named openstack is wrongly required to set it. Expected Behaviour externalNetworkName is required when the referenced provider's type is openstack, regardless of the instance name. Steps To Reproduce Define an OpenStack provider named openstack-1 and a dynamic nodepool referencing it without externalNetworkName. Apply the InputManifest. Validation passes although the field is documented as required for OpenStack. Anything else to note drop the external_net tag, callback and pretty-print case, add a test. test-set1 sets the field on an OVH nodepool; drop it since this is intende

Feature request: add RFC 1918 private ranges to the default noProxy list Problem The default noProxy list in services/ansibler/internal/worker/service/internal/proxy.go#L14 only excludes 127.0.0.1/8, localhost, cluster.local, kubeone's default PodCIDR (10.244.0.0/16) and ServiceCIDR (10.96.0.0/12), plus the exact IPs of the cluster's own nodes. Any other private address is routed through the HTTP proxy, which cannot reach it. Proposal Add the RFC 1918 ranges 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 to noProxyDefault. Follow-up: appending each node's private IP becomes redundant and can be dropped. Acceptance criteria noProxyDefault includes the three RFC 1918 ranges. Unit test for createNoProxyList() covering the defaults and a user-supplied noProxy Docs updated Follow up, will we need to add private IPs of nodes once this is implemented ?

commit-proxy-envs-changes.yml: a leaked containerd task causes a permanent reconcile loop, and its retries restart containerd+kubelet fleet-wide Claudie: v0.14.1 (manager, ansibler, kube-eleven) Cluster: k8s v1.34.0, containerd 1.7.29, Ubuntu 24.04.4 LTS, kernel 6.8.0-106-generic Topology: 3 dynamic control-plane nodes (Hetzner Cloud) + 4 static worker nodes (Hetzner dedicated), Cilium with kube-proxy replacement Summary A single leaked containerd task on one control-plane node put our cluster into a reconcile loop that could not clear itself. Every ~65 minutes Claudie retried proxy/commit-proxy-envs-changes.yml; each attempt restarted containerd and kubelet on every node five times in ~4 minutes before reaching the step that fails. That was long enough to drop every pod to NotReady, which stripped all Service endpoints and took down every workload in the cluster for ~4 minutes, once an hour. It ran for 4 consecutive cycles (~3.5h) until we cleared the stale task by hand. It would not