-
Notifications
You must be signed in to change notification settings - Fork 347
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
feat: Add ServiceBinding trait (#1445) #1952
Conversation
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.
It sounds really good that the binding is done operator side and that the complexity is delegated to the runtime, where we know we can later leverage Quarkus OOB support.
I've just a few comments about issues that can happen when servicebinding is not installed in the cluster (or it's installed later).
I think you also forgot to add something like this thing we did with Strimzi to install the role and cluster role (for kamel install
), plus adding the rules to OLM and HELM installation.
After this is merged, we can think to add a specific E2E test on a cluster with ServiceBinding installed to see how it goes.
@@ -217,6 +218,15 @@ func add(mgr manager.Manager, r reconcile.Reconciler) error { | |||
return err | |||
} | |||
|
|||
// Watch ServiceBindings created | |||
err = c.Watch(&source.Kind{Type: &sb.ServiceBinding{}}, &handler.EnqueueRequestForOwner{ |
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.
I think this may cause issues in case the ServiceBinding
resource is not present in the cluster (or not yet present when the Camel K operator is installed). We have a similar issue with Knative where we ended up watching the ReplicaSet
instead of specific Knative resources (right @astefanutti ?). Is there a child standard resource that we can watch?
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.
Ok, I see you're already targeting this. There's also a safer way to look if you can watch a resource by using these APIs:
camel-k/pkg/util/kubernetes/permission.go
Line 33 in 51a5c23
func CheckPermission(ctx context.Context, client client.Client, group, resource, namespace, name, verb string) (bool, error) { |
Also adding a watch on sub-resources (if possible) that change can help in case the servicebinding operator is installed after the camel k operator is started.
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.
Thanks for reviewing! There is the status subresource if that helps ?
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.
No, I was referring to a child-resource. Like if you know that servicebinding always syncs a secret with some labels when updating the binding resource, then listening for changes in the secrets (all or with filter) triggers the reschedule of the integration, so it proceeds.
Secrets are an example of "watchable" resource being in core v1.
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.
That would be useful only in cases where ServiceBinding is installed after camel k.
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.
Ah right no not by labels, here's a sample secret:
apiVersion: v1
data:
...
kind: Secret
metadata:
name: sample-service-binding-request
namespace: service-binding
ownerReferences:
- apiVersion: operators.coreos.com/v1alpha1
controller: true
kind: ServiceBinding
name: sample-service-binding-request
selfLink: /api/v1/namespaces/service-binding/secrets/sample-service-binding-request
type: Opaque
We could check in the owner references and work our way up to the integration name by checking if it exists but it may be simpler to file a request on the Service Binding Operator side to copy labels from the ServiceBinding
to the generated Secret
which seems at first glance like a reasonable request...
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.
Tracked with redhat-developer/service-binding-operator#852
@@ -46,7 +46,8 @@ func (action *platformSetupAction) Name() string { | |||
// CanHandle tells whether this action can handle the integration | |||
func (action *platformSetupAction) CanHandle(integration *v1.Integration) bool { | |||
return integration.Status.Phase == v1.IntegrationPhaseNone || | |||
integration.Status.Phase == v1.IntegrationPhaseWaitingForPlatform | |||
integration.Status.Phase == v1.IntegrationPhaseWaitingForPlatform || | |||
integration.Status.Phase == v1.IntegrationPhaseWaitingForServiceBindingCollectionReady |
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.
Is this needed? I think it does not do anything related.
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.
I added the IntegrationPhaseWaitingForServiceBindingCollectionReady phase to the platform_setup action but I could create a new one and add it there? It was convenient because it's the first one called and setting up the servicebinding should be done as early as possible. Also this Action does not modify the IntegrationPhase which allowed me to set it in the trait.
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, sounds good
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.
Done, thanks
pkg/trait/service_binding.go
Outdated
// IsAllowedInProfile overrides default | ||
func (t *serviceBindingTrait) IsAllowedInProfile(profile v1.TraitProfile) bool { | ||
return profile == v1.TraitProfileKubernetes || | ||
profile == v1.TraitProfileOpenShift |
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.
Is there a reason why the 3rd profile is excluded (Knative)?
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.
No, removed
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.
Everything sounds good! Can you just check the conflicts?
64a6bcb
to
619bada
Compare
Rebased, thanks ! |
619bada
to
c58ca42
Compare
Ok, conflicts again and I've tried to use this nice UI tool that github provides but made things worse XD Can you check again (and delete my commit).. We'll merge before waiting the CI this time |
…ow ServiceBinding trait on all profiles (apache#1445)
c3868f0
to
cd8a603
Compare
@nicolaferraro done! Thanks |
Adds the ServiceBinding Trait:
kamel run MyDbIntegration.java --connect Database.version.group/my-postgresql
Thanks !
Release Note