From 1f3a60fe50df1125f5c52ff24709681cb7f885f1 Mon Sep 17 00:00:00 2001 From: "dj.cando" Date: Mon, 13 Jul 2026 20:29:31 +0800 Subject: [PATCH] docs: fix typo in dnn-fn README.md Signed-off-by: dj.cando --- krm-functions/dnn-fn/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/krm-functions/dnn-fn/README.md b/krm-functions/dnn-fn/README.md index 6d4abfcdb..29d41304e 100644 --- a/krm-functions/dnn-fn/README.md +++ b/krm-functions/dnn-fn/README.md @@ -21,7 +21,7 @@ `dnn-fn` keeps track of the resources it created by setting their `specializer.nephio.org/owner` annotation to point to the `DataNetwork` resource that it was created for. -Based on these owner annotations `dnn-fn` automatically deletes (actually marks for deletion) all of the resources that it created and whose owner doesn't exist anymore. This can happen by deleting the owner `DataNetwork` resource from the package, or by deleting the corresponding `pool` form the `spec` of the owner `DataNetwork`. All in all, the role of `specializer.nephio.org/owner` annotation for Nephio KRM functions is very similarly to the role of the `ownerReference` field in the Kubernetes API server. +Based on these owner annotations `dnn-fn` automatically deletes (actually marks for deletion) all of the resources that it created and whose owner doesn't exist anymore. This can happen by deleting the owner `DataNetwork` resource from the package, or by deleting the corresponding `pool` from the `spec` of the owner `DataNetwork`. All in all, the role of `specializer.nephio.org/owner` annotation for Nephio KRM functions is very similarly to the role of the `ownerReference` field in the Kubernetes API server. `dnn-fn` never deletes `IPClaim` resources directly, but it marks them for deletion if needed, by setting the `specializer.nephio.org/delete` annotation to `"true"`. It expects the IPClaim specializer to actually delete the marked resources after properly releasing the IP ranges.