You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by GitBox <gi...@apache.org> on 2020/12/15 15:26:32 UTC
[GitHub] [camel-k] johnpoth opened a new pull request #1864: proposal: add Service Binding proposal (#1445)
johnpoth opened a new pull request #1864:
URL: https://github.com/apache/camel-k/pull/1864
<!-- Description -->
Proposal for #1445
Thanks !
<!--
Enter your extended release note in the below block. If the PR requires
additional action from users switching to the new release, include the string
"action required". If no release note is required, write "NONE".
You can (optionally) mark this PR with labels "kind/bug" or "kind/feature" to make sure
the text is added to the right section of the release notes.
-->
**Release Note**
```release-note
NONE
```
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] johnpoth commented on a change in pull request #1864: proposal: add Service Binding proposal (#1445)
Posted by GitBox <gi...@apache.org>.
johnpoth commented on a change in pull request #1864:
URL: https://github.com/apache/camel-k/pull/1864#discussion_r543504761
##########
File path: proposals/service-binding/service-binding.adoc
##########
@@ -0,0 +1,101 @@
+---
+title: Service Binding
+authors:
+ - "@johnpoth"
+reviewers:
+ - TBD
+approvers:
+ - TBD
+creation-date: 2020-15-12
+last-updated: 2020-15-12
+status: implementable
+see-also: []
+replaces: []
+superseded-by: []
+---
+
+[[service-binding]]
+= Service Binding
+
+== Summary
+
+This proposal aims at leveraging the https://github.com/k8s-service-bindings/spec#service-binding[Service Binding Specification] in Camel-k.
+
+=== Terminology
+
+* _Provisioned Service_
+** A service e.g a Database or a Broker that can be _bound_ to an application by means definied in the https://github.com/k8s-service-bindings/spec#provisioned-service[specification]
+* _Application_
+** In the context of Camel-k is an `Integration`
+
+== Motivation
+
+Users should be able to connect to a _Provisioned Service_ by specifying one or more __Service Binding__s in the command line:
+
+```
+kamel run intergration --connect database,broker
+```
+
+The _Service Binding_ could be referenced by name like shown above, in which case the _Service Binding_ already exists, or it could be created and managed by Camel-k in which case the user would have to explicitly specify the _Provisioned Service_ they want to connect to:
+
+```
+kamel run intergration --connect Database.v1alpha1.postgresql.baiju.dev/db-demo
+```
+
+The user may then reference the binding properties inside the integration just like any other properties.
+
+== Goals
+
+The goal of this proposal is to provide the current state of the https://github.com/k8s-service-bindings/spec#service-binding[Service Binding Specification] and how it might be leveraged in Camel-k to ease route configuration and facilitate their reusability.
+
+== Context
+
+The specification can be split into two categories: the _Service Binding Operator_ and the _Provisioned Service_ implementation. Several implementations of the _Service Binding Operator_ can be found readily available. Two have have been tried in the context of this proposal: https://github.com/vmware-labs/service-bindings and https://github.com/redhat-developer/service-binding-operator. _Provisioned Services_ implementations are still work in progress and aren't readily available. A list of https://github.com/k8s-service-bindings/spec/issues/16[first] and https://github.com/k8s-service-bindings/spec/issues/19[second] wave of specification adopters is maintained. Knowing this, usability of the `Service Binding Specification` remains limited. However an initial effort may be done in order to better understand how Camel-k can benefit from it.
+
+=== Workflow
+
+Two main workflows have been identified in the specification that allows user applications to bind to a _Provisioned Service_. Let's review them and see which one would suit Camel-k the best.
+
+The first way outlined in the specification is for the user to create a `ServiceBinding` indicating which _application_ to bind to which set of _Provisioned Services_:
+
+[source,yaml]
+----
+kind: ServiceBinding
+metadata:
+ name: account-service
+spec:
+ application:
+ apiVersion: apps/v1
+ kind: Deployment
+ name: camel-k-integration
+
+ service:
+ apiVersion: com.example/v1alpha1
+ kind: Database
+ name: my-database
+----
+
+Once created, it is the responsibility of the _Service Binding Operator_ to inject the binding information into the _application_. The _application_ is any `PodSpec`-able resource e.g a `Deployment`. The way it does this is that it first scales the `Deployment` down to 0. Then it injects the binding information into the `Deployment` in the form of a `Secret` or a `ConfigMap`. Finally it scales the `Deployment` back up.
+
+The second way is through https://github.com/k8s-service-bindings/spec#custom-projection-service-binding-example-resource[Custom Projection]. The difference between this approach and the first one is that the binding information injection into the _application_ is not the responsibility of the _Service Binding Operator_ anymore. It wil be the responsibility of another Operator. In our case it will be Camel-k's responsibility to retrieve the binding information and inject it into the `Integration`.
+
+The drawback of the first approach, in the context of Camel-k, is that the ``Integration``'s `Deployment` would be created in an incomplete state and would result in an error the first time the underlying container is started because the binding information is not present. The second drawback is that the ``Integration``'s `Deployment` resource should ideally _not_ be altered by someone other than the Camel-k operator itself. The advantage of using this approach is that less work is needed in Camel-k as injection is taken care of by the _Service Binding Operator_.
+
+Conversely, the drawback of implementing the second approach is that more work is needed as Camel-k would have to retrieve and inject the binding information.
+The advantage would be that Camel-k retains full control of the ``Integration``'s `Deployment/Cron/Knative` resource and we can delay the startup until the binding information is available.
+
+For these reasons, it seems that the second approach is preferred in the context of Camel-k.
Review comment:
Thanks for reviewing! It would require the camel-k operator to have `read` access to the `ServiceBinding` and it's corresponding `Secret`. It would also need to have rights to `create` a `ServiceBinding`
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] lburgazzoli commented on a change in pull request #1864: proposal: add Service Binding proposal (#1445)
Posted by GitBox <gi...@apache.org>.
lburgazzoli commented on a change in pull request #1864:
URL: https://github.com/apache/camel-k/pull/1864#discussion_r544188798
##########
File path: proposals/service-binding/service-binding.adoc
##########
@@ -0,0 +1,101 @@
+---
+title: Service Binding
+authors:
+ - "@johnpoth"
+reviewers:
+ - TBD
+approvers:
+ - TBD
+creation-date: 2020-15-12
+last-updated: 2020-15-12
+status: implementable
+see-also: []
+replaces: []
+superseded-by: []
+---
+
+[[service-binding]]
+= Service Binding
+
+== Summary
+
+This proposal aims at leveraging the https://github.com/k8s-service-bindings/spec#service-binding[Service Binding Specification] in Camel-k.
+
+=== Terminology
+
+* _Provisioned Service_
+** A service e.g a Database or a Broker that can be _bound_ to an application by means definied in the https://github.com/k8s-service-bindings/spec#provisioned-service[specification]
+* _Application_
+** In the context of Camel-k is an `Integration`
+
+== Motivation
+
+Users should be able to connect to a _Provisioned Service_ by specifying one or more __Service Binding__s in the command line:
+
+```
+kamel run intergration --connect database,broker
+```
+
+The _Service Binding_ could be referenced by name like shown above, in which case the _Service Binding_ already exists, or it could be created and managed by Camel-k in which case the user would have to explicitly specify the _Provisioned Service_ they want to connect to:
+
+```
+kamel run intergration --connect Database.v1alpha1.postgresql.baiju.dev/db-demo
+```
+
+The user may then reference the binding properties inside the integration just like any other properties.
+
+== Goals
+
+The goal of this proposal is to provide the current state of the https://github.com/k8s-service-bindings/spec#service-binding[Service Binding Specification] and how it might be leveraged in Camel-k to ease route configuration and facilitate their reusability.
+
+== Context
+
+The specification can be split into two categories: the _Service Binding Operator_ and the _Provisioned Service_ implementation. Several implementations of the _Service Binding Operator_ can be found readily available. Two have have been tried in the context of this proposal: https://github.com/vmware-labs/service-bindings and https://github.com/redhat-developer/service-binding-operator. _Provisioned Services_ implementations are still work in progress and aren't readily available. A list of https://github.com/k8s-service-bindings/spec/issues/16[first] and https://github.com/k8s-service-bindings/spec/issues/19[second] wave of specification adopters is maintained. Knowing this, usability of the `Service Binding Specification` remains limited. However an initial effort may be done in order to better understand how Camel-k can benefit from it.
+
+=== Workflow
+
+Two main workflows have been identified in the specification that allows user applications to bind to a _Provisioned Service_. Let's review them and see which one would suit Camel-k the best.
+
+The first way outlined in the specification is for the user to create a `ServiceBinding` indicating which _application_ to bind to which set of _Provisioned Services_:
+
+[source,yaml]
+----
+kind: ServiceBinding
+metadata:
+ name: account-service
+spec:
+ application:
+ apiVersion: apps/v1
+ kind: Deployment
+ name: camel-k-integration
+
+ service:
+ apiVersion: com.example/v1alpha1
+ kind: Database
+ name: my-database
+----
+
+Once created, it is the responsibility of the _Service Binding Operator_ to inject the binding information into the _application_. The _application_ is any `PodSpec`-able resource e.g a `Deployment`. The way it does this is that it first scales the `Deployment` down to 0. Then it injects the binding information into the `Deployment` in the form of a `Secret` or a `ConfigMap`. Finally it scales the `Deployment` back up.
+
+The second way is through https://github.com/k8s-service-bindings/spec#custom-projection-service-binding-example-resource[Custom Projection]. The difference between this approach and the first one is that the binding information injection into the _application_ is not the responsibility of the _Service Binding Operator_ anymore. It wil be the responsibility of another Operator. In our case it will be Camel-k's responsibility to retrieve the binding information and inject it into the `Integration`.
+
+The drawback of the first approach, in the context of Camel-k, is that the ``Integration``'s `Deployment` would be created in an incomplete state and would result in an error the first time the underlying container is started because the binding information is not present. The second drawback is that the ``Integration``'s `Deployment` resource should ideally _not_ be altered by someone other than the Camel-k operator itself. The advantage of using this approach is that less work is needed in Camel-k as injection is taken care of by the _Service Binding Operator_.
+
+Conversely, the drawback of implementing the second approach is that more work is needed as Camel-k would have to retrieve and inject the binding information.
+The advantage would be that Camel-k retains full control of the ``Integration``'s `Deployment/Cron/Knative` resource and we can delay the startup until the binding information is available.
+
+For these reasons, it seems that the second approach is preferred in the context of Camel-k.
Review comment:
The reference issue is here: https://github.com/quarkusio/quarkus/issues/13617
As side note, for some components we may benefit directly from the work done in Quarkus as example, if the jdbc set-up is auto-magically done by a Quarkus extension, then we can consume it as we do as today without having anything to change (same could happen for kafka, infinispan, jms, etc.)
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] lburgazzoli commented on a change in pull request #1864: proposal: add Service Binding proposal (#1445)
Posted by GitBox <gi...@apache.org>.
lburgazzoli commented on a change in pull request #1864:
URL: https://github.com/apache/camel-k/pull/1864#discussion_r543524123
##########
File path: proposals/service-binding/service-binding.adoc
##########
@@ -0,0 +1,101 @@
+---
+title: Service Binding
+authors:
+ - "@johnpoth"
+reviewers:
+ - TBD
+approvers:
+ - TBD
+creation-date: 2020-15-12
+last-updated: 2020-15-12
+status: implementable
+see-also: []
+replaces: []
+superseded-by: []
+---
+
+[[service-binding]]
+= Service Binding
+
+== Summary
+
+This proposal aims at leveraging the https://github.com/k8s-service-bindings/spec#service-binding[Service Binding Specification] in Camel-k.
+
+=== Terminology
+
+* _Provisioned Service_
+** A service e.g a Database or a Broker that can be _bound_ to an application by means definied in the https://github.com/k8s-service-bindings/spec#provisioned-service[specification]
+* _Application_
+** In the context of Camel-k is an `Integration`
+
+== Motivation
+
+Users should be able to connect to a _Provisioned Service_ by specifying one or more __Service Binding__s in the command line:
+
+```
+kamel run intergration --connect database,broker
+```
+
+The _Service Binding_ could be referenced by name like shown above, in which case the _Service Binding_ already exists, or it could be created and managed by Camel-k in which case the user would have to explicitly specify the _Provisioned Service_ they want to connect to:
+
+```
+kamel run intergration --connect Database.v1alpha1.postgresql.baiju.dev/db-demo
+```
+
+The user may then reference the binding properties inside the integration just like any other properties.
+
+== Goals
+
+The goal of this proposal is to provide the current state of the https://github.com/k8s-service-bindings/spec#service-binding[Service Binding Specification] and how it might be leveraged in Camel-k to ease route configuration and facilitate their reusability.
+
+== Context
+
+The specification can be split into two categories: the _Service Binding Operator_ and the _Provisioned Service_ implementation. Several implementations of the _Service Binding Operator_ can be found readily available. Two have have been tried in the context of this proposal: https://github.com/vmware-labs/service-bindings and https://github.com/redhat-developer/service-binding-operator. _Provisioned Services_ implementations are still work in progress and aren't readily available. A list of https://github.com/k8s-service-bindings/spec/issues/16[first] and https://github.com/k8s-service-bindings/spec/issues/19[second] wave of specification adopters is maintained. Knowing this, usability of the `Service Binding Specification` remains limited. However an initial effort may be done in order to better understand how Camel-k can benefit from it.
+
+=== Workflow
+
+Two main workflows have been identified in the specification that allows user applications to bind to a _Provisioned Service_. Let's review them and see which one would suit Camel-k the best.
+
+The first way outlined in the specification is for the user to create a `ServiceBinding` indicating which _application_ to bind to which set of _Provisioned Services_:
+
+[source,yaml]
+----
+kind: ServiceBinding
+metadata:
+ name: account-service
+spec:
+ application:
+ apiVersion: apps/v1
+ kind: Deployment
+ name: camel-k-integration
+
+ service:
+ apiVersion: com.example/v1alpha1
+ kind: Database
+ name: my-database
+----
+
+Once created, it is the responsibility of the _Service Binding Operator_ to inject the binding information into the _application_. The _application_ is any `PodSpec`-able resource e.g a `Deployment`. The way it does this is that it first scales the `Deployment` down to 0. Then it injects the binding information into the `Deployment` in the form of a `Secret` or a `ConfigMap`. Finally it scales the `Deployment` back up.
+
+The second way is through https://github.com/k8s-service-bindings/spec#custom-projection-service-binding-example-resource[Custom Projection]. The difference between this approach and the first one is that the binding information injection into the _application_ is not the responsibility of the _Service Binding Operator_ anymore. It wil be the responsibility of another Operator. In our case it will be Camel-k's responsibility to retrieve the binding information and inject it into the `Integration`.
+
+The drawback of the first approach, in the context of Camel-k, is that the ``Integration``'s `Deployment` would be created in an incomplete state and would result in an error the first time the underlying container is started because the binding information is not present. The second drawback is that the ``Integration``'s `Deployment` resource should ideally _not_ be altered by someone other than the Camel-k operator itself. The advantage of using this approach is that less work is needed in Camel-k as injection is taken care of by the _Service Binding Operator_.
+
+Conversely, the drawback of implementing the second approach is that more work is needed as Camel-k would have to retrieve and inject the binding information.
+The advantage would be that Camel-k retains full control of the ``Integration``'s `Deployment/Cron/Knative` resource and we can delay the startup until the binding information is available.
+
+For these reasons, it seems that the second approach is preferred in the context of Camel-k.
Review comment:
does the camel-k operator really need to access the secret ? I mean, the operator should add the service binding secret among the list of the secrets the integration needs, nothing more right ?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] johnpoth commented on a change in pull request #1864: proposal: add Service Binding proposal (#1445)
Posted by GitBox <gi...@apache.org>.
johnpoth commented on a change in pull request #1864:
URL: https://github.com/apache/camel-k/pull/1864#discussion_r543555139
##########
File path: proposals/service-binding/service-binding.adoc
##########
@@ -0,0 +1,101 @@
+---
+title: Service Binding
+authors:
+ - "@johnpoth"
+reviewers:
+ - TBD
+approvers:
+ - TBD
+creation-date: 2020-15-12
+last-updated: 2020-15-12
+status: implementable
+see-also: []
+replaces: []
+superseded-by: []
+---
+
+[[service-binding]]
+= Service Binding
+
+== Summary
+
+This proposal aims at leveraging the https://github.com/k8s-service-bindings/spec#service-binding[Service Binding Specification] in Camel-k.
+
+=== Terminology
+
+* _Provisioned Service_
+** A service e.g a Database or a Broker that can be _bound_ to an application by means definied in the https://github.com/k8s-service-bindings/spec#provisioned-service[specification]
+* _Application_
+** In the context of Camel-k is an `Integration`
+
+== Motivation
+
+Users should be able to connect to a _Provisioned Service_ by specifying one or more __Service Binding__s in the command line:
+
+```
+kamel run intergration --connect database,broker
+```
+
+The _Service Binding_ could be referenced by name like shown above, in which case the _Service Binding_ already exists, or it could be created and managed by Camel-k in which case the user would have to explicitly specify the _Provisioned Service_ they want to connect to:
+
+```
+kamel run intergration --connect Database.v1alpha1.postgresql.baiju.dev/db-demo
+```
+
+The user may then reference the binding properties inside the integration just like any other properties.
+
+== Goals
+
+The goal of this proposal is to provide the current state of the https://github.com/k8s-service-bindings/spec#service-binding[Service Binding Specification] and how it might be leveraged in Camel-k to ease route configuration and facilitate their reusability.
+
+== Context
+
+The specification can be split into two categories: the _Service Binding Operator_ and the _Provisioned Service_ implementation. Several implementations of the _Service Binding Operator_ can be found readily available. Two have have been tried in the context of this proposal: https://github.com/vmware-labs/service-bindings and https://github.com/redhat-developer/service-binding-operator. _Provisioned Services_ implementations are still work in progress and aren't readily available. A list of https://github.com/k8s-service-bindings/spec/issues/16[first] and https://github.com/k8s-service-bindings/spec/issues/19[second] wave of specification adopters is maintained. Knowing this, usability of the `Service Binding Specification` remains limited. However an initial effort may be done in order to better understand how Camel-k can benefit from it.
+
+=== Workflow
+
+Two main workflows have been identified in the specification that allows user applications to bind to a _Provisioned Service_. Let's review them and see which one would suit Camel-k the best.
+
+The first way outlined in the specification is for the user to create a `ServiceBinding` indicating which _application_ to bind to which set of _Provisioned Services_:
+
+[source,yaml]
+----
+kind: ServiceBinding
+metadata:
+ name: account-service
+spec:
+ application:
+ apiVersion: apps/v1
+ kind: Deployment
+ name: camel-k-integration
+
+ service:
+ apiVersion: com.example/v1alpha1
+ kind: Database
+ name: my-database
+----
+
+Once created, it is the responsibility of the _Service Binding Operator_ to inject the binding information into the _application_. The _application_ is any `PodSpec`-able resource e.g a `Deployment`. The way it does this is that it first scales the `Deployment` down to 0. Then it injects the binding information into the `Deployment` in the form of a `Secret` or a `ConfigMap`. Finally it scales the `Deployment` back up.
+
+The second way is through https://github.com/k8s-service-bindings/spec#custom-projection-service-binding-example-resource[Custom Projection]. The difference between this approach and the first one is that the binding information injection into the _application_ is not the responsibility of the _Service Binding Operator_ anymore. It wil be the responsibility of another Operator. In our case it will be Camel-k's responsibility to retrieve the binding information and inject it into the `Integration`.
+
+The drawback of the first approach, in the context of Camel-k, is that the ``Integration``'s `Deployment` would be created in an incomplete state and would result in an error the first time the underlying container is started because the binding information is not present. The second drawback is that the ``Integration``'s `Deployment` resource should ideally _not_ be altered by someone other than the Camel-k operator itself. The advantage of using this approach is that less work is needed in Camel-k as injection is taken care of by the _Service Binding Operator_.
+
+Conversely, the drawback of implementing the second approach is that more work is needed as Camel-k would have to retrieve and inject the binding information.
+The advantage would be that Camel-k retains full control of the ``Integration``'s `Deployment/Cron/Knative` resource and we can delay the startup until the binding information is available.
+
+For these reasons, it seems that the second approach is preferred in the context of Camel-k.
Review comment:
no it doesn't, I added it for convenience to create property mappings like `{DB_PORT}` instead of `{secret:name/DB_PORT}`. Doesn't camel-k already have rights to read `Secret`s ?
Nevertheless I think we can achieve this by adding the logic in camel-k-runtime via a customizer and avoid camel-k reading the `Secret`.
Ideally though, I think we would want to add some prefix to the property to avoid clashes like `{binding:name/DB_PORT}` where the user could elegantly choose the name
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] johnpoth commented on a change in pull request #1864: proposal: add Service Binding proposal (#1445)
Posted by GitBox <gi...@apache.org>.
johnpoth commented on a change in pull request #1864:
URL: https://github.com/apache/camel-k/pull/1864#discussion_r544183913
##########
File path: proposals/service-binding/service-binding.adoc
##########
@@ -0,0 +1,101 @@
+---
+title: Service Binding
+authors:
+ - "@johnpoth"
+reviewers:
+ - TBD
+approvers:
+ - TBD
+creation-date: 2020-15-12
+last-updated: 2020-15-12
+status: implementable
+see-also: []
+replaces: []
+superseded-by: []
+---
+
+[[service-binding]]
+= Service Binding
+
+== Summary
+
+This proposal aims at leveraging the https://github.com/k8s-service-bindings/spec#service-binding[Service Binding Specification] in Camel-k.
+
+=== Terminology
+
+* _Provisioned Service_
+** A service e.g a Database or a Broker that can be _bound_ to an application by means definied in the https://github.com/k8s-service-bindings/spec#provisioned-service[specification]
+* _Application_
+** In the context of Camel-k is an `Integration`
+
+== Motivation
+
+Users should be able to connect to a _Provisioned Service_ by specifying one or more __Service Binding__s in the command line:
+
+```
+kamel run intergration --connect database,broker
+```
+
+The _Service Binding_ could be referenced by name like shown above, in which case the _Service Binding_ already exists, or it could be created and managed by Camel-k in which case the user would have to explicitly specify the _Provisioned Service_ they want to connect to:
+
+```
+kamel run intergration --connect Database.v1alpha1.postgresql.baiju.dev/db-demo
+```
+
+The user may then reference the binding properties inside the integration just like any other properties.
+
+== Goals
+
+The goal of this proposal is to provide the current state of the https://github.com/k8s-service-bindings/spec#service-binding[Service Binding Specification] and how it might be leveraged in Camel-k to ease route configuration and facilitate their reusability.
+
+== Context
+
+The specification can be split into two categories: the _Service Binding Operator_ and the _Provisioned Service_ implementation. Several implementations of the _Service Binding Operator_ can be found readily available. Two have have been tried in the context of this proposal: https://github.com/vmware-labs/service-bindings and https://github.com/redhat-developer/service-binding-operator. _Provisioned Services_ implementations are still work in progress and aren't readily available. A list of https://github.com/k8s-service-bindings/spec/issues/16[first] and https://github.com/k8s-service-bindings/spec/issues/19[second] wave of specification adopters is maintained. Knowing this, usability of the `Service Binding Specification` remains limited. However an initial effort may be done in order to better understand how Camel-k can benefit from it.
+
+=== Workflow
+
+Two main workflows have been identified in the specification that allows user applications to bind to a _Provisioned Service_. Let's review them and see which one would suit Camel-k the best.
+
+The first way outlined in the specification is for the user to create a `ServiceBinding` indicating which _application_ to bind to which set of _Provisioned Services_:
+
+[source,yaml]
+----
+kind: ServiceBinding
+metadata:
+ name: account-service
+spec:
+ application:
+ apiVersion: apps/v1
+ kind: Deployment
+ name: camel-k-integration
+
+ service:
+ apiVersion: com.example/v1alpha1
+ kind: Database
+ name: my-database
+----
+
+Once created, it is the responsibility of the _Service Binding Operator_ to inject the binding information into the _application_. The _application_ is any `PodSpec`-able resource e.g a `Deployment`. The way it does this is that it first scales the `Deployment` down to 0. Then it injects the binding information into the `Deployment` in the form of a `Secret` or a `ConfigMap`. Finally it scales the `Deployment` back up.
+
+The second way is through https://github.com/k8s-service-bindings/spec#custom-projection-service-binding-example-resource[Custom Projection]. The difference between this approach and the first one is that the binding information injection into the _application_ is not the responsibility of the _Service Binding Operator_ anymore. It wil be the responsibility of another Operator. In our case it will be Camel-k's responsibility to retrieve the binding information and inject it into the `Integration`.
+
+The drawback of the first approach, in the context of Camel-k, is that the ``Integration``'s `Deployment` would be created in an incomplete state and would result in an error the first time the underlying container is started because the binding information is not present. The second drawback is that the ``Integration``'s `Deployment` resource should ideally _not_ be altered by someone other than the Camel-k operator itself. The advantage of using this approach is that less work is needed in Camel-k as injection is taken care of by the _Service Binding Operator_.
+
+Conversely, the drawback of implementing the second approach is that more work is needed as Camel-k would have to retrieve and inject the binding information.
+The advantage would be that Camel-k retains full control of the ``Integration``'s `Deployment/Cron/Knative` resource and we can delay the startup until the binding information is available.
+
+For these reasons, it seems that the second approach is preferred in the context of Camel-k.
Review comment:
> the main goal is to be able to auto configure components without the user intervention
The Camel Dream :+1:
> on quarkus one of the option that has been taken into account is to have a binding aware config source that is in charge to translate binding parameters to the related quarkus property
This sounds promising, do you have a Camel or a Quarkus example I could look at ? I wasn't aware this was possible
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] johnpoth commented on a change in pull request #1864: proposal: add Service Binding proposal (#1445)
Posted by GitBox <gi...@apache.org>.
johnpoth commented on a change in pull request #1864:
URL: https://github.com/apache/camel-k/pull/1864#discussion_r544215807
##########
File path: proposals/service-binding/service-binding.adoc
##########
@@ -0,0 +1,101 @@
+---
+title: Service Binding
+authors:
+ - "@johnpoth"
+reviewers:
+ - TBD
+approvers:
+ - TBD
+creation-date: 2020-15-12
+last-updated: 2020-15-12
+status: implementable
+see-also: []
+replaces: []
+superseded-by: []
+---
+
+[[service-binding]]
+= Service Binding
+
+== Summary
+
+This proposal aims at leveraging the https://github.com/k8s-service-bindings/spec#service-binding[Service Binding Specification] in Camel-k.
+
+=== Terminology
+
+* _Provisioned Service_
+** A service e.g a Database or a Broker that can be _bound_ to an application by means definied in the https://github.com/k8s-service-bindings/spec#provisioned-service[specification]
+* _Application_
+** In the context of Camel-k is an `Integration`
+
+== Motivation
+
+Users should be able to connect to a _Provisioned Service_ by specifying one or more __Service Binding__s in the command line:
+
+```
+kamel run intergration --connect database,broker
+```
+
+The _Service Binding_ could be referenced by name like shown above, in which case the _Service Binding_ already exists, or it could be created and managed by Camel-k in which case the user would have to explicitly specify the _Provisioned Service_ they want to connect to:
+
+```
+kamel run intergration --connect Database.v1alpha1.postgresql.baiju.dev/db-demo
+```
+
+The user may then reference the binding properties inside the integration just like any other properties.
+
+== Goals
+
+The goal of this proposal is to provide the current state of the https://github.com/k8s-service-bindings/spec#service-binding[Service Binding Specification] and how it might be leveraged in Camel-k to ease route configuration and facilitate their reusability.
+
+== Context
+
+The specification can be split into two categories: the _Service Binding Operator_ and the _Provisioned Service_ implementation. Several implementations of the _Service Binding Operator_ can be found readily available. Two have have been tried in the context of this proposal: https://github.com/vmware-labs/service-bindings and https://github.com/redhat-developer/service-binding-operator. _Provisioned Services_ implementations are still work in progress and aren't readily available. A list of https://github.com/k8s-service-bindings/spec/issues/16[first] and https://github.com/k8s-service-bindings/spec/issues/19[second] wave of specification adopters is maintained. Knowing this, usability of the `Service Binding Specification` remains limited. However an initial effort may be done in order to better understand how Camel-k can benefit from it.
+
+=== Workflow
+
+Two main workflows have been identified in the specification that allows user applications to bind to a _Provisioned Service_. Let's review them and see which one would suit Camel-k the best.
+
+The first way outlined in the specification is for the user to create a `ServiceBinding` indicating which _application_ to bind to which set of _Provisioned Services_:
+
+[source,yaml]
+----
+kind: ServiceBinding
+metadata:
+ name: account-service
+spec:
+ application:
+ apiVersion: apps/v1
+ kind: Deployment
+ name: camel-k-integration
+
+ service:
+ apiVersion: com.example/v1alpha1
+ kind: Database
+ name: my-database
+----
+
+Once created, it is the responsibility of the _Service Binding Operator_ to inject the binding information into the _application_. The _application_ is any `PodSpec`-able resource e.g a `Deployment`. The way it does this is that it first scales the `Deployment` down to 0. Then it injects the binding information into the `Deployment` in the form of a `Secret` or a `ConfigMap`. Finally it scales the `Deployment` back up.
+
+The second way is through https://github.com/k8s-service-bindings/spec#custom-projection-service-binding-example-resource[Custom Projection]. The difference between this approach and the first one is that the binding information injection into the _application_ is not the responsibility of the _Service Binding Operator_ anymore. It wil be the responsibility of another Operator. In our case it will be Camel-k's responsibility to retrieve the binding information and inject it into the `Integration`.
+
+The drawback of the first approach, in the context of Camel-k, is that the ``Integration``'s `Deployment` would be created in an incomplete state and would result in an error the first time the underlying container is started because the binding information is not present. The second drawback is that the ``Integration``'s `Deployment` resource should ideally _not_ be altered by someone other than the Camel-k operator itself. The advantage of using this approach is that less work is needed in Camel-k as injection is taken care of by the _Service Binding Operator_.
+
+Conversely, the drawback of implementing the second approach is that more work is needed as Camel-k would have to retrieve and inject the binding information.
+The advantage would be that Camel-k retains full control of the ``Integration``'s `Deployment/Cron/Knative` resource and we can delay the startup until the binding information is available.
+
+For these reasons, it seems that the second approach is preferred in the context of Camel-k.
Review comment:
That's definitely something we want to leverage :+1: I'll start hacking on this
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] nicolaferraro merged pull request #1864: proposal: add Service Binding proposal (#1445)
Posted by GitBox <gi...@apache.org>.
nicolaferraro merged pull request #1864:
URL: https://github.com/apache/camel-k/pull/1864
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] lburgazzoli commented on a change in pull request #1864: proposal: add Service Binding proposal (#1445)
Posted by GitBox <gi...@apache.org>.
lburgazzoli commented on a change in pull request #1864:
URL: https://github.com/apache/camel-k/pull/1864#discussion_r544048941
##########
File path: proposals/service-binding/service-binding.adoc
##########
@@ -0,0 +1,101 @@
+---
+title: Service Binding
+authors:
+ - "@johnpoth"
+reviewers:
+ - TBD
+approvers:
+ - TBD
+creation-date: 2020-15-12
+last-updated: 2020-15-12
+status: implementable
+see-also: []
+replaces: []
+superseded-by: []
+---
+
+[[service-binding]]
+= Service Binding
+
+== Summary
+
+This proposal aims at leveraging the https://github.com/k8s-service-bindings/spec#service-binding[Service Binding Specification] in Camel-k.
+
+=== Terminology
+
+* _Provisioned Service_
+** A service e.g a Database or a Broker that can be _bound_ to an application by means definied in the https://github.com/k8s-service-bindings/spec#provisioned-service[specification]
+* _Application_
+** In the context of Camel-k is an `Integration`
+
+== Motivation
+
+Users should be able to connect to a _Provisioned Service_ by specifying one or more __Service Binding__s in the command line:
+
+```
+kamel run intergration --connect database,broker
+```
+
+The _Service Binding_ could be referenced by name like shown above, in which case the _Service Binding_ already exists, or it could be created and managed by Camel-k in which case the user would have to explicitly specify the _Provisioned Service_ they want to connect to:
+
+```
+kamel run intergration --connect Database.v1alpha1.postgresql.baiju.dev/db-demo
+```
+
+The user may then reference the binding properties inside the integration just like any other properties.
+
+== Goals
+
+The goal of this proposal is to provide the current state of the https://github.com/k8s-service-bindings/spec#service-binding[Service Binding Specification] and how it might be leveraged in Camel-k to ease route configuration and facilitate their reusability.
+
+== Context
+
+The specification can be split into two categories: the _Service Binding Operator_ and the _Provisioned Service_ implementation. Several implementations of the _Service Binding Operator_ can be found readily available. Two have have been tried in the context of this proposal: https://github.com/vmware-labs/service-bindings and https://github.com/redhat-developer/service-binding-operator. _Provisioned Services_ implementations are still work in progress and aren't readily available. A list of https://github.com/k8s-service-bindings/spec/issues/16[first] and https://github.com/k8s-service-bindings/spec/issues/19[second] wave of specification adopters is maintained. Knowing this, usability of the `Service Binding Specification` remains limited. However an initial effort may be done in order to better understand how Camel-k can benefit from it.
+
+=== Workflow
+
+Two main workflows have been identified in the specification that allows user applications to bind to a _Provisioned Service_. Let's review them and see which one would suit Camel-k the best.
+
+The first way outlined in the specification is for the user to create a `ServiceBinding` indicating which _application_ to bind to which set of _Provisioned Services_:
+
+[source,yaml]
+----
+kind: ServiceBinding
+metadata:
+ name: account-service
+spec:
+ application:
+ apiVersion: apps/v1
+ kind: Deployment
+ name: camel-k-integration
+
+ service:
+ apiVersion: com.example/v1alpha1
+ kind: Database
+ name: my-database
+----
+
+Once created, it is the responsibility of the _Service Binding Operator_ to inject the binding information into the _application_. The _application_ is any `PodSpec`-able resource e.g a `Deployment`. The way it does this is that it first scales the `Deployment` down to 0. Then it injects the binding information into the `Deployment` in the form of a `Secret` or a `ConfigMap`. Finally it scales the `Deployment` back up.
+
+The second way is through https://github.com/k8s-service-bindings/spec#custom-projection-service-binding-example-resource[Custom Projection]. The difference between this approach and the first one is that the binding information injection into the _application_ is not the responsibility of the _Service Binding Operator_ anymore. It wil be the responsibility of another Operator. In our case it will be Camel-k's responsibility to retrieve the binding information and inject it into the `Integration`.
+
+The drawback of the first approach, in the context of Camel-k, is that the ``Integration``'s `Deployment` would be created in an incomplete state and would result in an error the first time the underlying container is started because the binding information is not present. The second drawback is that the ``Integration``'s `Deployment` resource should ideally _not_ be altered by someone other than the Camel-k operator itself. The advantage of using this approach is that less work is needed in Camel-k as injection is taken care of by the _Service Binding Operator_.
+
+Conversely, the drawback of implementing the second approach is that more work is needed as Camel-k would have to retrieve and inject the binding information.
+The advantage would be that Camel-k retains full control of the ``Integration``'s `Deployment/Cron/Knative` resource and we can delay the startup until the binding information is available.
+
+For these reasons, it seems that the second approach is preferred in the context of Camel-k.
Review comment:
> Ideally though, I think we would want to add some prefix to the property to avoid clashes like `{binding:name/DB_PORT}` where the user could elegantly choose the name
I'm not very sure about this one as the main goal is to be able to auto configure components without the user intervention, on quarkus one of the option that has been taken into account is to have a binding aware config source that is in charge to translate binding parameters to the related quarkus property and I think we should do something similar for components.
If users want to directly reference binding parameters, they should use the same syntax as for secrets `{secret:$name/$property}` as it is already namespaced.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] lburgazzoli commented on a change in pull request #1864: proposal: add Service Binding proposal (#1445)
Posted by GitBox <gi...@apache.org>.
lburgazzoli commented on a change in pull request #1864:
URL: https://github.com/apache/camel-k/pull/1864#discussion_r543568098
##########
File path: proposals/service-binding/service-binding.adoc
##########
@@ -0,0 +1,101 @@
+---
+title: Service Binding
+authors:
+ - "@johnpoth"
+reviewers:
+ - TBD
+approvers:
+ - TBD
+creation-date: 2020-15-12
+last-updated: 2020-15-12
+status: implementable
+see-also: []
+replaces: []
+superseded-by: []
+---
+
+[[service-binding]]
+= Service Binding
+
+== Summary
+
+This proposal aims at leveraging the https://github.com/k8s-service-bindings/spec#service-binding[Service Binding Specification] in Camel-k.
+
+=== Terminology
+
+* _Provisioned Service_
+** A service e.g a Database or a Broker that can be _bound_ to an application by means definied in the https://github.com/k8s-service-bindings/spec#provisioned-service[specification]
+* _Application_
+** In the context of Camel-k is an `Integration`
+
+== Motivation
+
+Users should be able to connect to a _Provisioned Service_ by specifying one or more __Service Binding__s in the command line:
+
+```
+kamel run intergration --connect database,broker
+```
+
+The _Service Binding_ could be referenced by name like shown above, in which case the _Service Binding_ already exists, or it could be created and managed by Camel-k in which case the user would have to explicitly specify the _Provisioned Service_ they want to connect to:
+
+```
+kamel run intergration --connect Database.v1alpha1.postgresql.baiju.dev/db-demo
+```
+
+The user may then reference the binding properties inside the integration just like any other properties.
+
+== Goals
+
+The goal of this proposal is to provide the current state of the https://github.com/k8s-service-bindings/spec#service-binding[Service Binding Specification] and how it might be leveraged in Camel-k to ease route configuration and facilitate their reusability.
+
+== Context
+
+The specification can be split into two categories: the _Service Binding Operator_ and the _Provisioned Service_ implementation. Several implementations of the _Service Binding Operator_ can be found readily available. Two have have been tried in the context of this proposal: https://github.com/vmware-labs/service-bindings and https://github.com/redhat-developer/service-binding-operator. _Provisioned Services_ implementations are still work in progress and aren't readily available. A list of https://github.com/k8s-service-bindings/spec/issues/16[first] and https://github.com/k8s-service-bindings/spec/issues/19[second] wave of specification adopters is maintained. Knowing this, usability of the `Service Binding Specification` remains limited. However an initial effort may be done in order to better understand how Camel-k can benefit from it.
+
+=== Workflow
+
+Two main workflows have been identified in the specification that allows user applications to bind to a _Provisioned Service_. Let's review them and see which one would suit Camel-k the best.
+
+The first way outlined in the specification is for the user to create a `ServiceBinding` indicating which _application_ to bind to which set of _Provisioned Services_:
+
+[source,yaml]
+----
+kind: ServiceBinding
+metadata:
+ name: account-service
+spec:
+ application:
+ apiVersion: apps/v1
+ kind: Deployment
+ name: camel-k-integration
+
+ service:
+ apiVersion: com.example/v1alpha1
+ kind: Database
+ name: my-database
+----
+
+Once created, it is the responsibility of the _Service Binding Operator_ to inject the binding information into the _application_. The _application_ is any `PodSpec`-able resource e.g a `Deployment`. The way it does this is that it first scales the `Deployment` down to 0. Then it injects the binding information into the `Deployment` in the form of a `Secret` or a `ConfigMap`. Finally it scales the `Deployment` back up.
+
+The second way is through https://github.com/k8s-service-bindings/spec#custom-projection-service-binding-example-resource[Custom Projection]. The difference between this approach and the first one is that the binding information injection into the _application_ is not the responsibility of the _Service Binding Operator_ anymore. It wil be the responsibility of another Operator. In our case it will be Camel-k's responsibility to retrieve the binding information and inject it into the `Integration`.
+
+The drawback of the first approach, in the context of Camel-k, is that the ``Integration``'s `Deployment` would be created in an incomplete state and would result in an error the first time the underlying container is started because the binding information is not present. The second drawback is that the ``Integration``'s `Deployment` resource should ideally _not_ be altered by someone other than the Camel-k operator itself. The advantage of using this approach is that less work is needed in Camel-k as injection is taken care of by the _Service Binding Operator_.
+
+Conversely, the drawback of implementing the second approach is that more work is needed as Camel-k would have to retrieve and inject the binding information.
+The advantage would be that Camel-k retains full control of the ``Integration``'s `Deployment/Cron/Knative` resource and we can delay the startup until the binding information is available.
+
+For these reasons, it seems that the second approach is preferred in the context of Camel-k.
Review comment:
yes, you can tell camel-k to mount a secret and make its content available as properties
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] lburgazzoli commented on a change in pull request #1864: proposal: add Service Binding proposal (#1445)
Posted by GitBox <gi...@apache.org>.
lburgazzoli commented on a change in pull request #1864:
URL: https://github.com/apache/camel-k/pull/1864#discussion_r543462692
##########
File path: proposals/service-binding/service-binding.adoc
##########
@@ -0,0 +1,101 @@
+---
+title: Service Binding
+authors:
+ - "@johnpoth"
+reviewers:
+ - TBD
+approvers:
+ - TBD
+creation-date: 2020-15-12
+last-updated: 2020-15-12
+status: implementable
+see-also: []
+replaces: []
+superseded-by: []
+---
+
+[[service-binding]]
+= Service Binding
+
+== Summary
+
+This proposal aims at leveraging the https://github.com/k8s-service-bindings/spec#service-binding[Service Binding Specification] in Camel-k.
+
+=== Terminology
+
+* _Provisioned Service_
+** A service e.g a Database or a Broker that can be _bound_ to an application by means definied in the https://github.com/k8s-service-bindings/spec#provisioned-service[specification]
+* _Application_
+** In the context of Camel-k is an `Integration`
+
+== Motivation
+
+Users should be able to connect to a _Provisioned Service_ by specifying one or more __Service Binding__s in the command line:
+
+```
+kamel run intergration --connect database,broker
+```
+
+The _Service Binding_ could be referenced by name like shown above, in which case the _Service Binding_ already exists, or it could be created and managed by Camel-k in which case the user would have to explicitly specify the _Provisioned Service_ they want to connect to:
+
+```
+kamel run intergration --connect Database.v1alpha1.postgresql.baiju.dev/db-demo
+```
+
+The user may then reference the binding properties inside the integration just like any other properties.
+
+== Goals
+
+The goal of this proposal is to provide the current state of the https://github.com/k8s-service-bindings/spec#service-binding[Service Binding Specification] and how it might be leveraged in Camel-k to ease route configuration and facilitate their reusability.
+
+== Context
+
+The specification can be split into two categories: the _Service Binding Operator_ and the _Provisioned Service_ implementation. Several implementations of the _Service Binding Operator_ can be found readily available. Two have have been tried in the context of this proposal: https://github.com/vmware-labs/service-bindings and https://github.com/redhat-developer/service-binding-operator. _Provisioned Services_ implementations are still work in progress and aren't readily available. A list of https://github.com/k8s-service-bindings/spec/issues/16[first] and https://github.com/k8s-service-bindings/spec/issues/19[second] wave of specification adopters is maintained. Knowing this, usability of the `Service Binding Specification` remains limited. However an initial effort may be done in order to better understand how Camel-k can benefit from it.
+
+=== Workflow
+
+Two main workflows have been identified in the specification that allows user applications to bind to a _Provisioned Service_. Let's review them and see which one would suit Camel-k the best.
+
+The first way outlined in the specification is for the user to create a `ServiceBinding` indicating which _application_ to bind to which set of _Provisioned Services_:
+
+[source,yaml]
+----
+kind: ServiceBinding
+metadata:
+ name: account-service
+spec:
+ application:
+ apiVersion: apps/v1
+ kind: Deployment
+ name: camel-k-integration
+
+ service:
+ apiVersion: com.example/v1alpha1
+ kind: Database
+ name: my-database
+----
+
+Once created, it is the responsibility of the _Service Binding Operator_ to inject the binding information into the _application_. The _application_ is any `PodSpec`-able resource e.g a `Deployment`. The way it does this is that it first scales the `Deployment` down to 0. Then it injects the binding information into the `Deployment` in the form of a `Secret` or a `ConfigMap`. Finally it scales the `Deployment` back up.
+
+The second way is through https://github.com/k8s-service-bindings/spec#custom-projection-service-binding-example-resource[Custom Projection]. The difference between this approach and the first one is that the binding information injection into the _application_ is not the responsibility of the _Service Binding Operator_ anymore. It wil be the responsibility of another Operator. In our case it will be Camel-k's responsibility to retrieve the binding information and inject it into the `Integration`.
+
+The drawback of the first approach, in the context of Camel-k, is that the ``Integration``'s `Deployment` would be created in an incomplete state and would result in an error the first time the underlying container is started because the binding information is not present. The second drawback is that the ``Integration``'s `Deployment` resource should ideally _not_ be altered by someone other than the Camel-k operator itself. The advantage of using this approach is that less work is needed in Camel-k as injection is taken care of by the _Service Binding Operator_.
+
+Conversely, the drawback of implementing the second approach is that more work is needed as Camel-k would have to retrieve and inject the binding information.
+The advantage would be that Camel-k retains full control of the ``Integration``'s `Deployment/Cron/Knative` resource and we can delay the startup until the binding information is available.
+
+For these reasons, it seems that the second approach is preferred in the context of Camel-k.
Review comment:
assuming the camel-k operator is installed at global scope, using this approach would require the camel-k operator to have basically have access to any resource in any namespaces ?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org