Bug 1958085

Summary: No option to deploy the templates to a non-shared (non default) namespace
Product: Container Native Virtualization (CNV) Reporter: Fabian Deutsch <fdeutsch>
Component: SSPAssignee: Karel Šimon <ksimon>
Status: CLOSED ERRATA QA Contact: Sarah Bennert <sbennert>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 2.6.0CC: akrejcir, cnv-qe-bugs, dholler, dvossel, gouyang, rnetser, stirabos
Target Milestone: ---   
Target Release: 4.10.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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: ---
Clone Of: Environment:
Last Closed: 2022-03-16 15:50:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2054650    
Bug Blocks:    

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
Verified CLI

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