Conversation
116ce2c to
b9f951c
Compare
| name: $scenario_id | ||
| spec: | ||
| foo: bar | ||
| status: |
There was a problem hiding this comment.
question does this work? You typically cannot create a resource with status
There was a problem hiding this comment.
So far, I haven't run into issues. ProvisionedBackend is just a CustomResource here, there's no backing reconciler anywhere.
| apiVersion: apps/v1 | ||
| kind: Deployment | ||
| """ | ||
| Then Service Binding becomes ready |
There was a problem hiding this comment.
question the ServiceBinding won't become ready unless the Deployment is found and projected. Where is the deployment defined for this test case?
There was a problem hiding this comment.
The deployment in this case is implicitly made in line 33, when we set up the generic application. It automatically gets the name $scenario_id (which gets replaced before submission), and it leaves $SERVICE_BINDING_ROOT unset unless you ask for it to be set.
| kind: Deployment | ||
| """ | ||
| Then Service Binding becomes ready | ||
| And The application env var "SERVICE_BINDING_ROOT" has value "/bindings" |
There was a problem hiding this comment.
question in which container is this asserting being made? It may not matter currently, but will once we need to control which container is bound and/or project into initcontainers.
There was a problem hiding this comment.
This gets asserted in the deployment of the generic test app's container. I don't have anything for handling initcontainers specially.
There was a problem hiding this comment.
On reconsideration, since I think I may have misunderstood your question last time:
We use whatever kubectl expose does by default (relevant exposure code can be found here). We might have to revisit this when we do initContainer testing; our current approach approach may or may not work.
25530f7 to
665044f
Compare
89f3590 to
049129e
Compare
|
A general observation: The indentation for YAML is not consistent. I can see a mix of 2 spaces and 4 spaces. Probably we can run the YAML through a linter before running the tests. |
|
We need a test to ensure the runtime validates well-known secret entries. |
|
We need a test to ensure the |
Implements a few common scenarios surrounding provisioned services and their projected values. Signed-off-by: Andy Sadler <[email protected]>
Overriding the provider field in the service binding should be a separate test from overriding the binding root in the workload. This splits them into two separate test cases. Signed-off-by: Andy Sadler <[email protected]>
The generic-test-app image requires an image label to work correctly. For now, tag it with 'main' as a label to get it working. Signed-off-by: Andy Sadler <[email protected]>
We now assert in this test that a SERVICE_BINDING_ROOT environment variable was set and that the bindings we projected under it have the values we expect them to be. Signed-off-by: Andy Sadler <[email protected]>
049129e to
a264645
Compare
Fixed.
Two thoughts:
|
I'll punt this to a separate PR. |
There's nothing for us to directly enforce relating to RBAC. The "must"s in the RBAC section are qualified by a proceeding should. While not a best practice, it's perfectly within spec for an implementation to grant itself cluster-admin and not need any additional permissions. It's also within spec for a cluster to not use RBAC. What we can test is to create a CRD for a provisioned service and a workload, with the respective ClusterRole permissions and then validate that the implementation is able to complete the binding. This should not involve assertions about the specific permissions of any ClusterRole. |
Implement more tests surrounding the provisioned service specification. This should implement coverage for a few scenarios:
typein theServiceBindingproviderin theServiceBinding$SERVICE_BINDING_ROOTin the workload$SERVICE_BINDING_ROOTfall back to a default when not specified