Hello,
trying to package Rancher install with Zarf for an AirGapped install and struggling with pulling images from Zarf internal registry. Zarf does automatically inject imagePullSecret into Deployments for the images that were deployed by Zarf package. But secret is deployed only to namespaces created by Zarf. This makes sense until package with "shadow" dependencies as Rancher is deployed, i.e. package does post deployment actions after it is deployed and creates own namespaces.
Problem is that such namespaces must have Zarf secret too, but some namespaces CANNOT be created by Zarf in advance as this breaks Rancher component deployment. Such components like Rancher Turtles will attempt to create their own namespaces and will fail if the namespace is created by Zarf.
Are there any way to control secret insertion to all new namespaces? Or is there any other way?
So far I see only "try and fail approach" to insert missing annotations and labels for each such namespace and expect that it will not use some dynamically generated label or there will be no conflicting labels, which seems to be the case with app.kubernetes.io/managed-by.
Hello,
trying to package Rancher install with Zarf for an AirGapped install and struggling with pulling images from Zarf internal registry. Zarf does automatically inject imagePullSecret into Deployments for the images that were deployed by Zarf package. But secret is deployed only to namespaces created by Zarf. This makes sense until package with "shadow" dependencies as Rancher is deployed, i.e. package does post deployment actions after it is deployed and creates own namespaces.
Problem is that such namespaces must have Zarf secret too, but some namespaces CANNOT be created by Zarf in advance as this breaks Rancher component deployment. Such components like Rancher Turtles will attempt to create their own namespaces and will fail if the namespace is created by Zarf.
Are there any way to control secret insertion to all new namespaces? Or is there any other way?
So far I see only "try and fail approach" to insert missing annotations and labels for each such namespace and expect that it will not use some dynamically generated label or there will be no conflicting labels, which seems to be the case with app.kubernetes.io/managed-by.