suse-edge/Factory
SHA256
17
0
Fork 17
Code Issues Pull Requests 3 Actions Packages Projects Releases Wiki Activity

sriov webhooks to reload the renewed certificate. #348

Merged
antaloala merged 2 commits from antaloala/Factory:edge-1759 into main 2025-12-24 00:52:05 +01:00
Conversation 1 Commits 2 Files Changed 4 +96
antaloala commented 2025-12-23 00:23:32 +01:00
Owner
Copy Link

This PR provides patches for each of the 2 rpms used to build the 2 sriov related webhooks, so these webhooks can automatically detect and reload renewed certificates; these patches are based on already merged but not-yet-released commits in the related upstream related repos:

Resulting webhook images (built from those 2 patched rpms) have been tested in a suse-edge 3.4 release running on top of an SLM6.2 instance and with a pre-3.5 sriov-network-operator deployed Helm chart (so using the bumped sriov images planned for 3.5)

  1. first checking the two sriov webooks fail to automatically detect and load the (self-signed cert-manager provided) manually renewed certs (using cert-manager cmctl tool to force the cert renewal); the operator-webhook is invoked through a kubectl apply command trying to create a wrong SriovNetwork API object (what invokes this webhook in its role of Validating webhook) and the network-resources-injector webhook is invoked through a kubectl apply command trying to create a pod which refers to multus NADs reated to some (previously created) SRIOV VF networks but not asking for the related VFs in the .spec.resources.request|limits stanza (so expecting this mutating webhook to add them).
    kubectl logs -f commands are being run in parallel for each of these webhook pods to see the logs reporting, after the cert renewal, that bad TLS certs are being received at invokation.
  2. after kubectl edit-ing the sriov-network-operator deployment API object (re-setting the value of the two involved env vars to now point to the new webhook container images just built) I repeated the same test, seeing (through the logs) that now the 2 sriov-related webook processes can automatically detect and reload the updated/renewed tls material (once kubelet detects the updated cert-related secret and re-bind_mount them in the webhook pods' mount namespace).
This PR provides patches for each of the 2 rpms used to build the 2 sriov related webhooks, so these webhooks can automatically detect and reload renewed certificates; these patches are based on already merged but not-yet-released commits in the related upstream related repos: - sriov-network-operator rpm (used to build the sriov-network-operator webhook image): the included patch introduces the updates provided by https://github.com/k8snetworkplumbingwg/sriov-network-operator/pull/946 (to come in a future sriov-network-operator release); patching the current solution/code being based on v1.6.0 up. - network-resources-injector rpm (used to build the network-resources-injector webhook image): the included patch introduces the updates provided by hhttps://github.com/k8snetworkplumbingwg/network-resources-injector/pull/187 (to come in a future network-resources-injector release); patching the current solution/code being based on v1.8.0 up. Resulting webhook images (built from those 2 patched rpms) have been tested in a suse-edge 3.4 release running on top of an SLM6.2 instance and with a pre-3.5 sriov-network-operator deployed Helm chart (so using the bumped sriov images planned for 3.5) 1. first checking the two sriov webooks fail to automatically detect and load the (self-signed cert-manager provided) manually renewed certs (using cert-manager `cmctl` tool to force the cert renewal); the operator-webhook is invoked through a `kubectl apply ` command trying to create a wrong `SriovNetwork` API object (what invokes this webhook in its role of Validating webhook) and the network-resources-injector webhook is invoked through a `kubectl apply ` command trying to create a pod which refers to multus NADs reated to some (previously created) SRIOV VF networks but not asking for the related VFs in the `.spec.resources.request|limits` stanza (so expecting this mutating webhook to add them). `kubectl logs -f` commands are being run in parallel for each of these webhook pods to see the logs reporting, after the cert renewal, that `bad TLS certs` are being received at invokation. 2. after `kubectl edit`-ing the `sriov-network-operator` deployment API object (re-setting the value of the two involved env vars to now point to the new webhook container images just built) I repeated the same test, seeing (through the logs) that now the 2 sriov-related webook processes can automatically detect and reload the updated/renewed tls material (once kubelet detects the updated cert-related secret and re-bind_mount them in the webhook pods' mount namespace).
antaloala added 2 commits 2025-12-23 00:23:33 +01:00
Adds injector-webhook-load-renewed-certs.patch to network-resources-injector srpm 5f8741631d
Adds operator-webhook-load-renewed-certs.patch to sriov-network-operator srpm
All checks were successful
Check Release Manifest Local Charts Versions / Check Release Manifest Local Charts Versions (pull_request) Successful in -3s
Details
Build PR in OBS / Build PR in OBS (pull_request_target) Successful in 7m47s
Details
0ca79320f9
antaloala changed title from WIP: sriov webhooks to reload the renewed certificate. to sriov webhooks to reload the renewed certificate. 2025-12-23 00:57:09 +01:00
antaloala requested review from amorgante 2025-12-23 12:06:35 +01:00
antaloala requested review from nbelouin 2025-12-23 12:06:36 +01:00
antaloala requested review from steven.hardy 2025-12-23 12:06:36 +01:00
nbelouin approved these changes 2025-12-23 12:45:06 +01:00
nbelouin left a comment
Owner
Copy Link

LGTM, some nits for better clarity.

LGTM, some nits for better clarity.
network-resources-injector/network-resources-injector.spec Outdated
@@ -24,6 +24,8 @@ License: Apache-2.0
URL: https://github.com/k8snetworkplumbingwg/network-resources-injector
Source: %{name}-%{version}.tar
Source1: vendor.tar.gz
# Patch1 below added as we wait for next upstrean release v1.9.0 (providing it) to come
nbelouin commented 2025-12-23 12:44:31 +01:00
Owner
Copy Link

nit: can you add a link to the PR you are backporting here ?

nit: can you add a link to the PR you are backporting here ?
👍 1
antaloala marked this conversation as resolved
sriov-network-operator/sriov-network-operator.spec Outdated
@@ -24,6 +24,8 @@ License: Apache-2.0
URL: https://github.com/k8snetworkplumbingwg/sriov-network-operator
Source: sriov-network-operator-%{version}.tar
Source1: vendor.tar.gz
# Patch1 below added as we wait for next upstrean release v1.7.0 (providing it) to come
nbelouin commented 2025-12-23 12:44:41 +01:00
Owner
Copy Link

nit: can you add a link to the PR you are backporting here ?

nit: can you add a link to the PR you are backporting here ?
👍 1
antaloala marked this conversation as resolved
antaloala force-pushed edge-1759 from 0ca79320f9 to a164be3522 2025-12-24 00:07:04 +01:00 Compare
antaloala merged commit a8221ba07f into main 2025-12-24 00:52:05 +01:00
antaloala deleted branch edge-1759 2025-12-24 00:52:06 +01:00
Sign in to join this conversation.
Reviewers
No Reviewers
amorgante
steven.hardy
nbelouin
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
amorgante antaloala atanasdinov atrendafilov dbekhit dprodanov eminguez fdegirmenci geoagriogiannis ipetrov117 jarndt jtomasek kzhelyazkov mchiappero mkrutov nbelouin roxenham steven.hardy
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: suse-edge/Factory#348
Delete Branch "antaloala/Factory:edge-1759"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?