IBM / operand-deployment-lifecycle-manager

Managing the lifecycle for a group of operands
Apache License 2.0
32 stars 46 forks source link

The customized name of CR is ignored when create OperandRequests #747

Closed LiJunBJZhu closed 3 years ago

LiJunBJZhu commented 3 years ago

/kind bug

What steps did you take and what happened: [A clear and concise description of what the bug is.] Create below OperandRequest by "oc apply" command. The name of Issuer and Certificate is defined by the property "name" under "metadata". However, an Issuer is created as expected, but its name is cert-crs-fab53673af8578, and the name of created certificate is cert-crs-46b4240c9f92f5. Seems the name defined in spec is ignored.

apiVersion: operator.ibm.com/v1alpha1 kind: OperandRequest metadata: name: cert-crs namespace: zlj-bedrock spec: requests:

What did you expect to happen: Issuer and certificate should be created with the name defined in spec.

Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.]

Environment:

Daniel-Fan commented 3 years ago

Hi @LiJunBJZhu

I noticed that you are trying to create custom resources for cert-manager-operator by OperandRequest.

May I ask that whether you follow this document to the do that? https://github.com/IBM/operand-deployment-lifecycle-manager/blob/master/docs/design/create-cr-by-operandrequest.md

The CR's name is defined by instanceName: ibm-sample-selfsigned-issuer

Here is a complete example, and you can also find it in the above link.

apiVersion: operator.ibm.com/v1alpha1
kind: OperandRequest
metadata:
  name: db2-instance1
  namespace: my-service
spec:
  requests:
  - registry: common-service
    registryNamespace: ibm-common-services
    operands:
    - name: ibm-db2-operator
      kind: db2
      apiVersion: operator.ibm.com/v1alpha1
      instanceName: db2-instance1
      spec:
        replicas: 3
    - name: ibm-db2-operator
      kind: db2
      apiVersion: operator.ibm.com/v1alpha1
      instanceName: db2-instance2
      spec:
        replicas: 3
LiJunBJZhu commented 3 years ago

Cool. That does work. Thank you.

I got an additional question. May we define the resource requests/limits of an operator in the operandrequest. I am asking that because the cert-manager operator in our cluster always reports OOM error even if I haven't created any issues/certs yet. I have to increase the requested memory from 50M to 100M manually to workaround the issue now. Thanks.

Daniel-Fan commented 3 years ago

No, currently we do not support to change the resource limits and requests from OperandRequest.

But it could be done by configuring the Common Service CR or OperandConfig. Please see this document for more details. We would recommend to use the former one. https://www.ibm.com/docs/en/cpfs?topic=services-configuring-foundational-by-using-custom-resource#cert_mgmt

LiJunBJZhu commented 3 years ago

I see. I will give a try. Thank you.

And I am able to use OperandRequest to install a cert-manager operator after increasing the memory requests of ibm-cert-manager-operator. However, two cert-manager-webhook pods, which seems to be created automatically, keep restarting due to CrashLoopBackOff. I checked their log, an error is reported. " W0927 07:54:56.197156 1 authentication.go:262] Unable to get configmap/extension-apiserver-authentication in kube-system. Usually fixed by 'kubectl create rolebinding -n kube-system ROLEBINDING_NAME --role=extension-apiserver-authentication-reader --serviceaccount=YOUR_NS:YOUR_SA' Error: configmaps "extension-apiserver-authentication" is forbidden: User "system:serviceaccount:ibm-common-services:cert-manager" cannot get resource "configmaps" in API group "" in the namespace "kube-system" " I don't want to ask client to manually create the rolebinding manually. I am wondering is there a way create it in operandRequest, which is actually the only entrypoint we create common service related crs in our product, automatically? Thanks.

Daniel-Fan commented 3 years ago

Hi @LiJunBJZhu

I am wondering is there a way create it in operandRequest, which is actually the only entrypoint we create common service related crs in our product, automatically? Thanks.

No, we should not create the k8s resource through OperandRequest.

And also from Common Service perspective, we usually install ibm-cert-manager-operator without any additional issuer and certificate. Because the cert-manager-operator will create the cert-manager CR through the OperandConfig.(Creating CR from OperandRequest and Create CR from OperandConfig are two different installation paths in ODLM)

Besides, if you hit any problem during the installation of Common Service, could you please create the ticket in our internal Github repo? We would follow the procedures to solve the adopters' issues