Review the claiming code logic

[cmoulliard]

TODO

Review the claiming code logic when the service can be discovered or is installable (using crossplane helm releaseby example) on a k8s cluster.

The existing code do not seem to follow this flow here and here

[cmoulliard]

Ideally the flow should be implemented part of a Service (or job running every x seconds) to check about the new claims CRs or Claim sql records and then starting to process them when status is equal to New.

As soon as a claim is processed, then the job/service change the status from New to Pending to indicate that it is currently processed and to avoid that it is processed twice, etc. The status Pending indicates also that the claim is locked till the service will go through the different steps to reach the end (= bound) or to fail (error) for different reasons

[aureamunoz]

I think we should review the architecture code in order to move the business logic to the service layer. Currently we have methods called doXXXX in the Resource classes containing business logic (for example, binding claims or creating K8s resources). IMO we should move this logic to the corresponding service class. I would also do the persist tasks in the service layer.

Regarding the claiming, if we let only an entry point to the claiming action from the Applications UI, why would we need a job? Shouldn't we just create the claim + bind the application if all needed elements exist?
WDYT @cmoulliard @Sgitario ?

[Sgitario]

I think we should review the architecture code in order to move the business logic to the service layer. Currently we have methods called doXXXX in the Resource classes containing business logic (for example, binding claims or creating K8s resources). IMO we should move this logic to the corresponding service class. I would also do the persist tasks in the service layer.

+100

Regarding the claiming, if we let only an entry point to the claiming action from the Applications UI, why would we need a job? Shouldn't we just create the claim + bind the application if all needed elements exist? WDYT @cmoulliard @Sgitario ?

If this is not an automatic action (we don't need to discover the services or something like this), then we don't need a job. Though if we need to verify the claim status every X minutes (for example, to check whether the service still exists), then we would need a job to do this.

[cmoulliard]

If this is not an automatic action (we don't need to discover the services or something like this), then we don't need a job.

Even if we dont need a job, we need one or some services able to handle the different steps of the flow. Having a job or service scheduler able to process the different steps allows to perform the work in an async mode

[aureamunoz]

Ok, let's keep the scheduled job at the moment