-
Notifications
You must be signed in to change notification settings - Fork 270
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose provisioned service binding #615
Conversation
- following provisioned service service binding duck type See: https://k8s-service-bindings.github.io/spec/#provisioned-service
- follow recommendation on provisioned service binding spec
32c46ee
to
59b8ffc
Compare
Looks like the Secret includes I understand if you want to think more deeply about the value of |
@ChunyiLyu I wanted to provide a couple points of spec guidance that you might not be aware of.
|
@scothis @nebhale To clarify, this PR is not a final solution of what RabbitmqCluster service binding should look like. My intent was to expose some information through the binding as soon as possible so it can be used in a different operator which is still under development. As for broker url to connect to RabbitMQ, there has been some discussion within the team that it might make sense to expose it at a different level. I just realized the type of secret is immutable. This is a problem for the cluster operator because default user secret is in use already. If the operator sets service type to be something else, clusters created by new versions of the operator would have a different secret type for its default user secret, which is not ideal. Perhaps having a dedicated service binding secret would be a cleaner solution. I will close this PR for now because more consideration is needed. |
👍
There are two |
- following provisioned service binding duck type requirement
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.
LGTM. Do we also want to comply with:
To facilitate discoverability, it is RECOMMENDED that a CustomResourceDefinition exposing a Provisioned Service add service.binding/provisioned-service: "true" as a label.
@coro fyi, the key |
@scothis thanks for the heads up |
This closes #605
Note to reviewers: remember to look at the commits in this PR and consider if they can be squashed
Summary Of Changes
This PR is to conform to the provisioned service binding, defined in Service Binding Specifications for K8s. The main purpose is to consume is in the messaging topology operator, and it is not meant to be the final solution for what RabbitmqCluster would expose in its service binding.
username
andpassword
provider
andtype
which sets torabbitmq
to the default user secret.provider
andtype
are recommended by the provisioned service spec. Adding a new key to the default user secret object does impact the conf.d file we mount onto rabbitmq container because the operator copies only the default user username and password into the conf.d file (see initContainer logic here)username
,password
,type
, andprovider
which are information that's already there and unlikely to change its format.ServiceReference
andSecretReference
that's already exposed in our rabbitmqcluster.Status. I think some more digging is going to be needed for us to determine whether we can safely delete them (to not be redundant) I don't think deleting them is a blocker to merge this PR. I've created a followup issue to look into it.service.binding/{type}
. However secret type is immutable, so I am leaving it out.Additional Context
Local Testing
All tests passed.