first thoughts about Servicebox claim resource definition #1
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,26 @@ | ||
| apiVersion: servicebox.apps.rh.com/v1alpha1 | ||
| kind: ServiceClaim | ||
| metadata: | ||
| name: backing-svc-claim | ||
| namespace: development | ||
| spec: | ||
| ref: | ||
| apiVersion: backingsvc.com/v1alpha1 | ||
| 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: 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, ...) To be defined: Application CRD & Claim CRD |
||
| 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 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. |
||
| history: | ||
| - lastTransitionTime: "2019-10-22T16:29:25Z" | ||
| status: "True" | ||
| type: Ready | ||
| - lastTransitionTime: "2019-10-22T16:29:24Z" | ||
| status: "True" | ||
| type: ResourceClaimed | ||
| - lastTransitionTime: "2019-10-22T16:29:23Z" | ||
| status: "True" | ||
| type: ResourceMatched | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 thisThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.