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 2021/03/02 17:10:28 UTC
[GitHub] [camel-k] nicolaferraro opened a new pull request #2086: chore(kamelets): embed kamelet repository and remove lookup from gith…
nicolaferraro opened a new pull request #2086:
URL: https://github.com/apache/camel-k/pull/2086
…ub strategy
<!-- Description -->
This automatically syncs kamelets from the catalog into the operator, without relying on github APIs.
I've added a guard to prevent us releasing a non-tagged revision of the catalog during release.
<!--
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
The Kamelet catalog is automatically installed on Kubernetes to let other platforms use it
```
----------------------------------------------------------------
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 pull request #2086: chore(kamelets): embed kamelet repository and remove lookup from gith…
Posted by GitBox <gi...@apache.org>.
lburgazzoli commented on pull request #2086:
URL: https://github.com/apache/camel-k/pull/2086#issuecomment-789469079
I think it is ok as long as the number of kamelet is low but as long term strategy I'd advocate for copy the kamelet to the container image and use a local catalog (we then need to add an option to the operator and the kamel cli to point to that location so it would work also for local run)
----------------------------------------------------------------
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 edited a comment on pull request #2086: chore(kamelets): embed kamelet repository and remove lookup from gith…
Posted by GitBox <gi...@apache.org>.
lburgazzoli edited a comment on pull request #2086:
URL: https://github.com/apache/camel-k/pull/2086#issuecomment-789469079
I think it is ok as long as the number of kamelet is low but as long term strategy I'd advocate for copy the kamelet to the container image and use a local kamelet repository (we then need to add an option to the operator and the kamel cli to point to that location so it would work also for local run)
----------------------------------------------------------------
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 commented on pull request #2086: chore(kamelets): embed kamelet repository and remove lookup from gith…
Posted by GitBox <gi...@apache.org>.
nicolaferraro commented on pull request #2086:
URL: https://github.com/apache/camel-k/pull/2086#issuecomment-789524867
> I think it is ok as long as the number of kamelet is low but as long term strategy I'd advocate for copy the kamelet to the container image and use a local kamelet repository (we then need to add an option to the operator and the kamel cli to point to that location so it would work also for local run)
I'm in favor of this solution for the short term, bundling the kamelets in the binary is useful to implement `kamel local bind`, but we agreed on making the CLI lighter and "version independent" in the future, so embedding kamelets goes against this. The local bind can be still implemented and require setting the repo location in advance.
For the long run, an external image may be the solution. It can be shipped directly as release artifact of https://github.com/apache/camel-kamelets. But decoupling kamelet catalog version from operator version require more thinking, especially from an operational point of view.
----------------------------------------------------------------
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 #2086: chore(kamelets): embed kamelet repository and remove lookup from gith…
Posted by GitBox <gi...@apache.org>.
nicolaferraro merged pull request #2086:
URL: https://github.com/apache/camel-k/pull/2086
----------------------------------------------------------------
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] heiko-braun commented on pull request #2086: chore(kamelets): embed kamelet repository and remove lookup from gith…
Posted by GitBox <gi...@apache.org>.
heiko-braun commented on pull request #2086:
URL: https://github.com/apache/camel-k/pull/2086#issuecomment-789470136
How about shipping the kameletes in a separate image, rather than embedded in the operator? It would help if the Kameletes could be updated without touching the operator image. Food for thought.
----------------------------------------------------------------
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