Service Binding Operator Helm chart #1132
Conversation
Kartikey-star
force-pushed
the
helm-chart
branch
2 times, most recently
from
56873a4 to
018cbe0
Compare
| spec: | ||
| containers: | ||
| - name: "{{ .Release.Name }}-test" | ||
| image: "quay.io/kmamgain/sboat:latest" |
There was a problem hiding this comment.
Please include the Dockerfile for this image
There was a problem hiding this comment.
The Dockerfile and shell script cannot be kept in the charts directory . Can u suggest some other directory to place those.
Kartikey-star
force-pushed
the
helm-chart
branch
2 times, most recently
from
a83011d to
0e390fa
Compare
Codecov Report
@@ Coverage Diff @@
## master #1132 +/- ##
=======================================
Coverage 57.50% 57.50%
=======================================
Files 31 31
Lines 2673 2673
=======================================
Hits 1537 1537
Misses 974 974
Partials 162 162 Continue to review full report at Codecov.
|
Kartikey-star
force-pushed
the
helm-chart
branch
8 times, most recently
from
6e2bdf0 to
0e8de4e
Compare
Kartikey-star
force-pushed
the
helm-chart
branch
3 times, most recently
from
f868eba to
de48910
Compare
|
/retest |
|
/retest |
|
/test 4.8-acceptance |
|
/lgtm |
| description: A Helm chart to deploy service binding operator | ||
| type: application | ||
| version: 1.0.0 | ||
| appVersion: "1.0.1" |
There was a problem hiding this comment.
similar to OLM bundle, the chart needs to specify what is minimal supported kube version, add same set of keywords and other metadata available in OLM bundle.
/hold
There was a problem hiding this comment.
kubeVersion: '>= 1.21.0' for OCP 4.8 right? https://access.redhat.com/solutions/4870701
There was a problem hiding this comment.
CI tests with 1.19: https://github.com/redhat-developer/service-binding-operator/blob/master/.github/workflows/pr-checks.yaml#L13 so why putting the bar higher here? Also, there are plenty of useful metadata https://github.com/redhat-developer/service-binding-operator/blob/master/config/manifests/bases/service-binding-operator.clusterserviceversion.yaml that could be reused here as well, at least this is what I would expect from a chart carrying 1.0 version.
There was a problem hiding this comment.
Majority of data looks like field used by OLM ,as the target for our chart is non OLM i think it is fine just to mention the kubeversion.
There was a problem hiding this comment.
In the chart you can find a few relevant counterparts, and the content that already exits for OLM could be transferred to Chart.yaml, for example:
- icon
- keywords
- maintainer information
- home
- sources
If the idea is to publish this chart eventually to Artifacthub, you can also use a set of annotations supported by them to enrich the metadata.
|
/retest |
1 similar comment
|
/retest |
|
The chart should contain the appropriate license as well. |
|
/retest |
|
@Kartikey-star for license we can use this one: https://github.com/redhat-developer/service-binding-operator/blob/master/LICENSE place it in an md file like this: https://github.com/openshift-helm-charts/charts/blob/main/charts/partners/hashicorp/vault/0.19.0/src/LICENSE.md |
|
/retest |
1 similar comment
|
/retest |
Kartikey-star
force-pushed
the
helm-chart
branch
3 times, most recently
from
fc0a528 to
2406f7a
Compare
|
/retest |
2 similar comments
|
/retest |
|
/retest |
Signed-off-by: Kartikey Mamgain <[email protected]>
|
/lgtm |
There was a problem hiding this comment.
@Kartikey-star Left some review suggestions. PTAL and apply the changes in a different PR. Thanks!
| - servicebindings.binding.operators.coreos.com | ||
| - servicebindings.servicebinding.io | ||
|
|
||
| The resources required for the Service Binding Operator will also be installed. |
There was a problem hiding this comment.
| The resources required for the Service Binding Operator will also be installed. | |
| The resources required for the Service Binding Operator are also installed. |
| - `image.testRepository` | ||
| - `keepTestResources` | ||
|
|
||
| A user can define values for the image PullPolicy. |
There was a problem hiding this comment.
| A user can define values for the image PullPolicy. | |
| You can define values for the image pull policy. |
OR
| A user can define values for the image PullPolicy. | |
| You can define values for the `image.pullPolicy` value. |
I am not sure about the technical accuracy of the previous sentence though. The 1st option that I have suggested makes more sense to me compared to the 2nd one.
| - `keepTestResources` | ||
|
|
||
| A user can define values for the image PullPolicy. | ||
| A user can define values for `image.repository` and `image.testRepository`. If user is not able to pull image from quay.io registry, they can copy the image to their own container registry. |
There was a problem hiding this comment.
| A user can define values for `image.repository` and `image.testRepository`. If user is not able to pull image from quay.io registry, they can copy the image to their own container registry. | |
| You can define values for the `image.pullPolicy`, `image.repository`, and `image.testRepository` values. If you are not able to pull an image from the quay.io registry, then copy the image to your own container registry. |
If combining both the sentences and saying that you can define values for all 3 values does not change the technical meaning, then you can implement the above suggestion. PTAL and decide.
There was a problem hiding this comment.
looks good to change.
|
|
||
| A user can define values for the image PullPolicy. | ||
| A user can define values for `image.repository` and `image.testRepository`. If user is not able to pull image from quay.io registry, they can copy the image to their own container registry. | ||
| As part of Helm test we delete the deploymemt,service binding resource and secret used for testing. If a user is interested to view them, then he has to install the chart with keepTestResources set to `true`. |
There was a problem hiding this comment.
| As part of Helm test we delete the deploymemt,service binding resource and secret used for testing. If a user is interested to view them, then he has to install the chart with keepTestResources set to `true`. | |
| As part of the Helm test, objects such as deployment, service binding resources, and secrets used for testing are deleted. To view them, you can install the chart with the `keepTestResources` flag value set to `true`. |
| kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.6.0/cert-manager.yaml | ||
|
|
||
| ### Adding the Helm chart repository | ||
| You need to add our helm repository to your local repository. Name the repository as per your convenience. |
There was a problem hiding this comment.
| You need to add our helm repository to your local repository. Name the repository as per your convenience. | |
| Add the `service-binding-operator-helm-chart` repository to your local repository and name the repository as per your convenience: |
|
|
||
| The previous output verifies that the `my-k-config` secret is created. | ||
|
|
||
| Run the Helm test (specify the namespace if applicable) using : |
There was a problem hiding this comment.
. Run the Helm test and specify the namespace if applicable:
| ---- | ||
| The `Succeeded` phase from the output indicates that the Helm test has run successfully. | ||
|
|
||
| Verify that the Helm test has run successfully: |
There was a problem hiding this comment.
. Verify that the Helm test has run successfully:
| service-binding-operator-release-test 0/1 Completed 0 4m28s | ||
| ---- | ||
|
|
||
| This implies that you have successfully installed the service binding operator using a Helm chart and are able to bind your workload to backing services. |
There was a problem hiding this comment.
The output verifies that you have successfully installed the {servicebinding-title} using a Helm chart and are able to bind your workload to backing services.
|
|
||
| This implies that you have successfully installed the service binding operator using a Helm chart and are able to bind your workload to backing services. | ||
|
|
||
| Please ensure to delete the secret (specify the namespace if applicable) created : |
There was a problem hiding this comment.
. As a safety measure, delete the secret created and specify the namespace if applicable:
| Please ensure to delete the secret (specify the namespace if applicable) created : | ||
| ---- | ||
| kubectl delete secret my-k-config --namespace service-binding-operator | ||
| ---- |
There was a problem hiding this comment.
After L240, add this:
.Example output
[source,terminal]
secret "my-k-config" deleted
The output verifies that the secret that you had created is now deleted.
Deleting the secret avoids exposing the secret credentials of the cluster to which you are connected.
This PR defines the Service Binding Operator Helm chart.