Skip to content
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

Merged
merged 6 commits into from
Feb 9, 2021

Conversation

johnpoth
Copy link
Member

Adds the ServiceBinding Trait:

kamel run MyDbIntegration.java --connect Database.version.group/my-postgresql

Thanks !

Release Note

[ServiceBinding](https://github.com/k8s-service-bindings/spec) support has been added via the ServiceBinding trait 

@johnpoth johnpoth added the kind/feature New feature or request label Jan 27, 2021
Copy link
Member

@nicolaferraro nicolaferraro left a 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{
Copy link
Member

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?

Copy link
Member

@nicolaferraro nicolaferraro Jan 28, 2021

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:

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.

Copy link
Member Author

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 ?

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member Author

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...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -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
Copy link
Member

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.

Copy link
Member Author

@johnpoth johnpoth Jan 29, 2021

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, sounds good

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, thanks

// IsAllowedInProfile overrides default
func (t *serviceBindingTrait) IsAllowedInProfile(profile v1.TraitProfile) bool {
return profile == v1.TraitProfileKubernetes ||
profile == v1.TraitProfileOpenShift
Copy link
Member

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)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, removed

Copy link
Member

@nicolaferraro nicolaferraro left a 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?

@johnpoth
Copy link
Member Author

johnpoth commented Feb 8, 2021

Rebased, thanks !

@nicolaferraro
Copy link
Member

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

@johnpoth
Copy link
Member Author

johnpoth commented Feb 9, 2021

@nicolaferraro done! Thanks

@nicolaferraro nicolaferraro merged commit d36f4d0 into apache:master Feb 9, 2021
@johnpoth johnpoth deleted the service-binding branch February 9, 2021 12:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants