propagating operatorGroup doesnt works right

[zfrhv]

when having operatorGroup in parent namespace:

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: simple-og
  namespace: parent
spec:
  serviceAccountName: restricted-sa
  targetNamespace:
  - parent

and propagating it to a child namespace we get:

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: simple-og
  namespace: child
spec:
  serviceAccountName: restricted-sa
  targetNamespace:
  - parent

the operatorGroup targets his parent instead of himself.

i suggest to add field namespaceFields to the propagation configuration:

apiVersion: hnc.x-k8s.io/v1alpha2
kind: HNCConfiguration
metadata:
  name: config
spec:
  resources:
  - group: operators.coreos.com
    resource: operatorgroups
    namespaceFields:
    - spec.targetNamespaces[0]

and then HNC will know which other field he needs to modify when propagating.

similar problem may occur in other custom resources that im not aware of

[adrianludwin]

Eek, that's a bit of a complicated one. Can you tell me anything more about how OperatorGroup is and how it works, and why you might want to propagate it? The fact that it's a namespaced object that can refer to a different namespace is a bit of a red flag for me.

[zfrhv]

Sure
As far as I know its made to tell the operator which namespaces he has access to, and give permissions on those namespaces when installing with OLM.

Only cluster-admin can create as manage operatorGroup, so if I give permissions for a namespace to manage other namespace via OperatorGroup, each operator that will be installed in source namespace will have those permissions.

Reason why i expect the propagation to work is the same as clusterRoleBindings, when i give a client permissions to manage some namespace (creating operatorGroup), I shouldn't care in which of sub-namespaces he wants to use it.

It's not really a must to support propagating operatorGroup, but it would be a really nice way to allow client to install operators with permissions only on their own namespaces.

Though now im thinking of it maybe its more OLM problem, that they dont have option to give permission on local namespace without harcoded specifying the name.

[zfrhv]

Alright so i really think its OperatorGroup fault,
I will close this case, if I will have any extra thoughts i will reopen