first thoughts about Servicebox claim resource definition #1
Conversation
| namespace: my-namespace # optional (if claiming across namespaces) | ||
| status: | ||
| binding: | ||
| name: service-secret # copied from BackingService/my-svc |
There was a problem hiding this comment.
Using this approach implies that a system has populated a k8s secret and has updated the ClaimCRD. Which component/system will be responsible for that ?
There was a problem hiding this comment.
At this moment I think it would be the ServiceBox because it is reacting to the Claim CR received.
| apiVersion: backingsvc.com/v1alpha1 | ||
| kind: BackingService |
There was a problem hiding this comment.
Why are you proposing a new GVK / CRD ? How will be possible based on that to find a MySQL 8.0.30 backend or Postgresql 13?8 or ... ?
There was a problem hiding this comment.
Not sure to follow, I just wanted to reference a generic backing service and gave that name, but if we reference a postgresql 13 it would be kind: Postgresqlor something like this
There was a problem hiding this comment.
So the question that we should have here is: "Do we plan to pass within the ClaimCRD a kubernetes CRD or to have a way to declare something which can be matched next ?". The idea of the Claim is to express that we want to access as a service (sql, nosql, openid, ldap, ...) without any knowledge about how the platform is handling the service. So, the service has maybe been created using a CRD, no CRD (= k8s resources), is perhaps running externally but available at the address IP:port or hostname.dnsname:port, etc. This is why I dont think that we need the fields apiVersion and kind. WDYT ?
There was a problem hiding this comment.
Yes, ok. I agree it is a good idea not depend on strict kubernetes resources, in that case we need to find an alternative way to describe the need.
| kind: BackingService | ||
| name: my-svc #optional | ||
| labels: #optional | ||
| foo: bar |
There was a problem hiding this comment.
Which labels do you plan to pass here ?
There was a problem hiding this comment.
Labels helping to discover the backend service, for example: app: database-postgresql
There was a problem hiding this comment.
I think that it is needed that we describe the use cases starting from the Microservice creation (= what folks call now a workload) till a Claim will be issued. Why: to be able to see the data needed, what the different systems will pass, ...
Example:
Microservice x.y.z --> use a CLI (dekorate, quarkus ext, ...)
CLI --> create an Application CRD
App CRD --> consumed by the Application Controller
Application Ctrl -> extract the claim section
Application Ctrl -> populate a Claim CRD
Claim CRD --> consumed by the ServiceBox
To be defined: Application CRD & Claim CRD
No description provided.