|Summary:||No option to deploy the templates to a non-shared (non default) namespace|
|Product:||Container Native Virtualization (CNV)||Reporter:||Fabian Deutsch <fdeutsch>|
|Component:||SSP||Assignee:||Karel Šimon <ksimon>|
|Status:||CLOSED ERRATA||QA Contact:||Sarah Bennert <sbennert>|
|Version:||2.6.0||CC:||akrejcir, cnv-qe-bugs, dholler, dvossel, gouyang, rnetser, stirabos|
|Fixed In Version:||hyperconverged-cluster-operator-container-v4.9.0-22, kubevirt-ssp-operator-container-v4.10.0-5||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2022-03-16 15:50:56 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||2054650|
Description Fabian Deutsch 2021-05-07 07:11:36 UTC
Description of problem: As a user I would like to limit which templates SSP is deploying in order to limit what my users can use. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Install SSP 2. 3. Actual results: All tempaltes that SSP ships areinstalled Expected results: Selected templates that SSP ships get installed Additional info:
Comment 3 Fabian Deutsch 2021-05-07 09:05:59 UTC
Adjusting the title of the bug: Instead of not deploying them, a better alternative could be to deploy the templates to a different namespace than the regular "openshift" one, because this a) will make the templates exclusive to the admin (no other user is seeing them) b) the admin still has them in cluster for reference i.e. to create custom tempaltes based on them
Comment 5 David Vossel 2021-05-07 16:14:41 UTC
(In reply to Fabian Deutsch from comment #3) > Adjusting the title of the bug: Instead of not deploying them, a better > alternative could be to deploy the templates to a different namespace than > the regular "openshift" one, because this a) will make the templates > exclusive to the admin (no other user is seeing them) b) the admin still has > them in cluster for reference i.e. to create custom tempaltes based on them so the workflow for the cluster admin who wants to only expose a small subset of templates would be - admin sets a field on HCO cr indicating template namespace override (which ultimately influences where ssp installs the common templates) - admin manually copies over subset of approved templates to the visible "openshift" namespace where they become visible to users boot sources are cross namespace and independent of this, so this seems like a viable approach.
Comment 6 Andrej Krejcir 2021-05-11 12:35:25 UTC
The SSP CR already has a parameter to specify the namespace for templates: apiVersion: ssp.kubevirt.io/v1beta1 kind: SSP metadata: name: ssp-example namespace: kubevirt spec: commonTemplates: namespace: openshift ... But it is not configurable form HCO. HCO uses a hardcoded "openshift" namespace.
Comment 7 Kevin Wiesmueller 2021-05-11 14:27:19 UTC
That's great, so we'd only be looking at extending the HCO API and setting a default there. How do we move that on their radar? @stirabos do you think that is a change you'd be fine with?
Comment 8 Kevin Wiesmueller 2021-06-30 18:29:14 UTC
I just had a chat with nunnatsa and we should be fine sending a PR to HCO exposing the API we already have on SSP on their end. That should give us what we need here. And it should be a small enough change to still make it for 4.9 if we're quick enough as QE also needs to test it.
Comment 11 Guohua Ouyang 2022-02-07 10:09:55 UTC
This can be done by adding "commonTemplatesNamespace: <custom ns>" to HCO in 4.10, moving the bug to verified status. Feel free to reopen the bug if it's not the case.
Comment 12 Sarah Bennert 2022-02-15 16:09:02 UTC
Comment 15 errata-xmlrpc 2022-03-16 15:50:56 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Virtualization 4.10.0 Images security and bug fix update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:0947