LREST and LRPDB conceptual issue / enhancement request

[ilfur]

Basically, I have two requests. One is easy to fix, the other one would require overthinking the principle PDB lifecycle management behaviour in OraOperator.

1. please add or react on the pdbState attribute when CREATING a PDB. I need PDBs to be OPEN READ/WRITE when created, not just MOUNTED as it is now. I cannot deploy an application or helm chart with two LRPDB yamls dealing with the same PDB, one to create and one to modify it. Since there is no order in which those YAMLs can be run during deployment. I need to workaround this currently by opening the PDB in a script in an initContainer, this needs to connect to the CDB. But my deployment should not need to know about the CDBs credentials and connection because thats why the OraOperator is there ...

2. The current concept of modifying a PDB state or config by specifying an action of type create, modify, .... breaks the kubernetes way of thinking.
   The correct way to got would be that the Operator (OraOperator) needs to find out if a resource is created or altered, and which elements have been altered (e.g. by looking into the versioned fields). So the deployer can simply specify the desired state of the resource and the operator tries to reach that state. The deployer should NOT need to specify the "action" by himself. With this current setup, its hard to deploy or upgrade apps with PDBs inside (see issue 1), and deployment tools like argoCD also complain about the managed resources state being out-of-sync with the GIT repository's state ...

But anyway, I'd be very happy if You could implement issue 1 and just think about issue 2 :)
Best regards!

[ilfur]

About the second item in my opened issue, I would like to give another example:
Given that a new LRPDB resource is created, OraOperator knows that this is a "fresh" creation of a resource, not an update to an existing one. It should then look into the CDB and check if the PDB belonging to the resource is already there or not. If not, create it.
Also check if the PDB is to be cloned. If the PDB is already there, then just map it. Then create the desired PDB state like MOUNTED, OPEN READ ONLY or OPEN READ/WRITE.
If the resource is already there but is just updated, then find out what settings have changed and apply those changes to the PDB, like open/close or storage parameters...
Just an idea !

[ilfur]

Second workaround idea: use an initContainer with kubectl inside, run with a systemaccount that can handle LRPDBs.
Check for LRPDB state in that container and patch the resource for a modifyAction and state of OPEN READ/WRITE.

[mmalvezz]

Point one: not a big deal can be implemented in a short run.
I'm sure about the second point .... I'm working on the autodiscover feature: If a pdb is created via sqlplus the operator recognize the new tenant and creates the associated CRD... is that what you mean ?

[ilfur]

The PDB auto-discovery is a cool and desired thing too. But it is not what I meant actually.
My request is:
Current behaviour: there is an attribute in PDB resources called "action". Depending on the type of action (like "Modify"), OraOperator behaves accordingly when these attributes are set.

My request: remove the attributes "action" and "modifyAction" completely. Let OraOperator find out if things need to be created (like upon first time creation of the resource, then also create or map the PDB behind it if another parameter allows mapping) or updated (like intended PDB state open, close, add another admin user, change parameters).

Why: kubernetes deployments are a bit like terraform cloud scripts. They do everything in parallel and the (cloud or kubernetes) environment creates a certain "state" of the managed resources. This intended state is described in the deployment YAMLs (or .tf files) and stored in a database (etcd or terraform state). You should not need to update the same resource multiple times during a single deployment, like pushing out multiple separate "actions" during this rather atomic procedure of deploying something.
Or put in another way: when using typical deployment tools like argocd, flows or even helm charts I must not put the same resource multiple times into the deployment zip (like create a PDB resource, then update a PDB resource to open it, ...). There is no order in which those YAMLs get executed, so I will get errors during deployment about missing resource that are to be updated and so on.

[mmalvezz]

The modify "action" is a legacy which we have to abandon. Unfortunately we cannot do in a short run; please open a git discussion to start the process.