-
Notifications
You must be signed in to change notification settings - Fork 99
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
Automate bootstrap for non-containerized deployment? #178
Comments
It sounds a good idea to me! In which form would you plan to add that? |
Thanks. I was thinking about a CLI utility, in a module within the project. The usage would look like this:
It would have 2 additional arguments:
We already have the list of configurations in the connector config files (example). It's not clear to me yet how to handle generating the configuration. I think there are 2 options:
Option 1 is significantly easier, although the configuration file would be much larger than our examples. Option 2 is more complicated and we would probably need to come up with a mechanism to highlight what is required and what is not. IMHO, I think we could stick w/ option 1. |
looks looks we may need a start.spring.io alike solution but for camel |
@orpiske For the configuration part actually I was planning to add an autogenerated example configuration listing only the required options (the camel catalog should provide that information). We can potentially convey that information using the Kafka connect config priority field (i.e. only the properties with priority = HIGH are the mandatory ones). Probably we would need to specify the version as well? Or directly some GAV? It is a nice idea, it sounds a decent amount of work is needed for a facility to basically run examples and standalone (that nowadays I am not sure how much would be used, as you said containers platforms have these facilities built in somehow. @lburgazzoli well actually this would be something different since it does not generate a starting project for you but rather help you to easily run one. Have I missed something? |
I think I misinterpreted the subject reading the issue on my mobile as points 1,2,3 looks very similar to what you do with start.spring.io or similar tools. |
I think that's a good idea. I think reusing the priority would make it possible to use it for the bootstrapping part as well.
I think we need that too. I think we could use the GAV. IIRC, camel-k CLI already uses the GAV, so overall usage throughout the projects would be consistent.
|
Looking at the AWS-to-JMS example it seems to me that the bootstrap steps are going to be similar most of the time.
I know this is handled automatically that for containerized deployments such as Strimzi, so I was wondering if the project should have a facility for regular deployments.
What do you think? IMHO, it could make even the documentation and example creation simpler, as the project can abstract a few repetitive things and reduce the entry barrier.
The text was updated successfully, but these errors were encountered: