util: Add MultiTemplateDir to support multi-segment path in template by amartyasinha · Pull Request #682 · openstack-k8s-operators/lib-common

amartyasinha · 2026-04-09T13:29:58Z

A new parameter MultiTemplateDir is introduced in Template struct. It takes the multi-segment path which we have inside templates dir and then continues to execute the templates. Earlier, only single- segment path (kind) was supported through InstanceType.

Follow-up nova-operator PR with the usage of MultiTemplateDir: openstack-k8s-operators/nova-operator#1096

gibizer · 2026-04-14T09:53:42Z

-		// get all scripts templates which are in ../templesPath/cr.Kind/CMType/<OSPVersion - optional>
-		templatesFiles := GetAllTemplates(templatesPath, t.InstanceType, string(t.Type), string(t.Version))
+		// If MultiTemplateDir is set but InstanceType is not, return an error
+		// though we do not use InstanceType here, but it is used in secret.go


Yeah I see it in https://github.com/openstack-k8s-operators/lib-common/blame/3e1007da0cbd673047305e423866c8c50b1e3167/modules/common/secret/secret.go#L272

I'm wondering why we are setting an owner label on a Secret this way instead of using the owner reference way. Also it is strange that we only do that on Secret but not on ConfigMap.
@stuggi Are we still supporting cross namespace Secrets? (That is the most I could extract from the code why we are labelling)
Also it is strange that we only enforce InstanceType if the template is not TemplateTypeNone. So I guess a template with TemplateTypeNone and without a InstanceType cannot be outside of our namespace as secret creation would fail due to the missing InstanceType.

If we don't need to support Secrets outside of the namespace the I suggest to clean that code up and remove this dependency and checks

if we do need to support Secrets outside of the namespace then I suggest

to make the InstanceType mandatory in all template types to avoid surprises

consider supporting the same thing for ConfigMaps as well.

yes, the owner label is coming from creating/tracking object in different namespaces. There is one use case I know of where we create secret in a different namespace and this is for BMH provisioning, where userdata and networkdata secret needs to be created in the bmh namespaces , https://github.com/openstack-k8s-operators/openstack-baremetal-operator/blob/main/internal/openstackbaremetalset/baremetalhost.go#L83 ,

Just from a quick search it is not using the labels, for delete its using name https://github.com/openstack-k8s-operators/openstack-baremetal-operator/blob/main/internal/openstackbaremetalset/baremetalhost.go#L318, but I think its still good to see from the labels who the owner is, if someone checks the env and wonders who created those secrets in the bmh namespace. Therefore I don't think we should remove it. We can consider supporting it for CMs as well in a follow up. I wanted to spend more time on lib-common to cleanup/align things, but got other prios. Maybe after FR6 I can spend some time on this.

gibizer

It is cleaner now and the nova-operator patchs shows the intended usage of it. I wait for @stuggi about the wide question of instanceType usage and namespace external secret support. But other than that I'm OK to land this. Thanks @amartyasinha !

amartyasinha · 2026-04-17T06:45:28Z

It is cleaner now and the nova-operator patchs shows the intended usage of it. I wait for @stuggi about the wide question of instanceType usage and namespace external secret support. But other than that I'm OK to land this. Thanks @amartyasinha !

Thanks @gibizer for the review. IMHO, since secrets using InstanceType is not related to this change, maybe we can unblock this PR, and continue the discussion at other place. WDYT?

stuggi · 2026-04-17T07:14:53Z

-		// get all scripts templates which are in ../templesPath/cr.Kind/CMType/<OSPVersion - optional>
-		templatesFiles := GetAllTemplates(templatesPath, t.InstanceType, string(t.Type), string(t.Version))
+		// If MultiTemplateDir is set but InstanceType is not, return an error
+		// though we do not use InstanceType here, but it is used in secret.go


yes, the owner label is coming from creating/tracking object in different namespaces. There is one use case I know of where we create secret in a different namespace and this is for BMH provisioning, where userdata and networkdata secret needs to be created in the bmh namespaces , https://github.com/openstack-k8s-operators/openstack-baremetal-operator/blob/main/internal/openstackbaremetalset/baremetalhost.go#L83 ,

Just from a quick search it is not using the labels, for delete its using name https://github.com/openstack-k8s-operators/openstack-baremetal-operator/blob/main/internal/openstackbaremetalset/baremetalhost.go#L318, but I think its still good to see from the labels who the owner is, if someone checks the env and wonders who created those secrets in the bmh namespace. Therefore I don't think we should remove it. We can consider supporting it for CMs as well in a follow up. I wanted to spend more time on lib-common to cleanup/align things, but got other prios. Maybe after FR6 I can spend some time on this.

stuggi · 2026-04-17T07:32:40Z

+		if t.MultiTemplateDir != "" {
+			templateSubdir = t.MultiTemplateDir
+		} else {
+			templateSubdir = strings.ToLower(t.InstanceType)


good, we are doing the ToLower here, was wondering above

stuggi · 2026-04-17T07:35:23Z

 		{
 			name:     "Get TemplateTypeConfig templates with no version",
-			kind:     "testservice",
+			subdir:   "testservice",


maybe we should use TestService in one of them to check the ToLower situation? something we did not have right now.

Used TestService at L369.

stuggi · 2026-04-17T07:40:04Z

It is cleaner now and the nova-operator patchs shows the intended usage of it. I wait for @stuggi about the wide question of instanceType usage and namespace external secret support. But other than that I'm OK to land this. Thanks @amartyasinha !

Thanks @gibizer for the review. IMHO, since secrets using InstanceType is not related to this change, maybe we can unblock this PR, and continue the discussion at other place. WDYT?

In general looks good to me. maybe we can adjust one of the tests I commented inline. I can land it later today.

A new parameter MultiTemplateDir is introduced in Template struct. It takes the multi-segment path which we have inside templates dir and then continues to execute the templates. Earlier, only single- segment path (kind) was supported through InstanceType. Signed-off-by: Amartya Sinha <amsinha@redhat.com>

amartyasinha · 2026-04-17T08:12:34Z

It is cleaner now and the nova-operator patchs shows the intended usage of it. I wait for @stuggi about the wide question of instanceType usage and namespace external secret support. But other than that I'm OK to land this. Thanks @amartyasinha !

Thanks @gibizer for the review. IMHO, since secrets using InstanceType is not related to this change, maybe we can unblock this PR, and continue the discussion at other place. WDYT?

In general looks good to me. maybe we can adjust one of the tests I commented inline. I can land it later today.

Thanks @stuggi! Addressed the change.

stuggi

/lgtm

stuggi · 2026-04-17T08:21:15Z

@gibizer I can not merge it as it seems there is still a change request from your review. could you approve it so that it gets cleared?

We agreed that it is good enough

amartyasinha mentioned this pull request Apr 9, 2026

Use MultiTemplateDir for the support of multi-segment dir in template openstack-k8s-operators/nova-operator#1096

Open

amartyasinha force-pushed the template-type-directory branch 2 times, most recently from 612b299 to 1f926c7 Compare April 10, 2026 06:17

bogdando reviewed Apr 10, 2026

View reviewed changes

Comment thread modules/common/util/template_util.go Outdated

bogdando reviewed Apr 10, 2026

View reviewed changes

Comment thread modules/common/secret/secret.go Outdated

bogdando reviewed Apr 10, 2026

View reviewed changes

Comment thread modules/common/util/template_util_test.go

amartyasinha force-pushed the template-type-directory branch from 1f926c7 to eb33f7f Compare April 10, 2026 11:21

gibizer requested changes Apr 14, 2026

View reviewed changes

gibizer previously requested changes Apr 14, 2026

View reviewed changes

Comment thread modules/common/util/template_util.go

Comment thread modules/common/util/template_util.go Outdated

amartyasinha mentioned this pull request Apr 14, 2026

api: add openStackServiceIdentity to Nova service and template specs openstack-k8s-operators/nova-operator#1099

Closed

amartyasinha force-pushed the template-type-directory branch 2 times, most recently from 45b3cb9 to 135bf0a Compare April 16, 2026 07:50

amartyasinha changed the title ~~[DNM] util: Add functions to enable multi-segment path in template~~ [DNM] util: Add MultiTemplateDir to support multi-segment path in template Apr 16, 2026

gibizer reviewed Apr 16, 2026

View reviewed changes

amartyasinha marked this pull request as ready for review April 17, 2026 06:45

amartyasinha changed the title ~~[DNM] util: Add MultiTemplateDir to support multi-segment path in template~~ util: Add MultiTemplateDir to support multi-segment path in template Apr 17, 2026

amartyasinha requested a review from gibizer April 17, 2026 06:48

stuggi reviewed Apr 17, 2026

View reviewed changes

amartyasinha force-pushed the template-type-directory branch from 135bf0a to 67d7fbc Compare April 17, 2026 08:08

stuggi approved these changes Apr 17, 2026

View reviewed changes

stuggi merged commit 4ac834e into openstack-k8s-operators:main Apr 17, 2026
2 checks passed

amartyasinha deleted the template-type-directory branch April 20, 2026 06:25

Conversation

amartyasinha commented Apr 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

gibizer Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

stuggi Apr 17, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

gibizer left a comment

Choose a reason for hiding this comment

Uh oh!

amartyasinha commented Apr 17, 2026

Uh oh!

stuggi Apr 17, 2026

Choose a reason for hiding this comment

Uh oh!

stuggi Apr 17, 2026

Choose a reason for hiding this comment

Uh oh!

stuggi Apr 17, 2026

Choose a reason for hiding this comment

Uh oh!

amartyasinha Apr 17, 2026

Choose a reason for hiding this comment

Uh oh!

stuggi commented Apr 17, 2026

Uh oh!

amartyasinha commented Apr 17, 2026

Uh oh!

stuggi left a comment

Choose a reason for hiding this comment

Uh oh!

stuggi commented Apr 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

amartyasinha commented Apr 9, 2026 •

edited

Loading

stuggi commented Apr 17, 2026 •

edited

Loading