-
Notifications
You must be signed in to change notification settings - Fork 345
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
Refactoring traits to allow addons and add master trait (as addon) #1274
Conversation
I am curious, you are talking about |
Not directly related. There was the need to move some logic out of the core, and it was easier for me to do this kind of refactoring while developing a new trait (master). The leader election is part of the camel master component. The why/how is explained here: https://www.nicolaferraro.me/2017/10/17/creating-clustered-singleton-services-on-kubernetes/ That example was for spring-boot and required some configuration to work. In Camel K now it works out-of-the-box (just use a |
} | ||
|
||
/* Base trait */ | ||
|
||
func newBaseTrait(id string) BaseTrait { | ||
// NewBaseTrait -- | ||
func NewBaseTrait(id string, order int) BaseTrait { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wonder if we should have some constants that could help choosing the right value for the order
field
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking the same, but couldn't find a good strategy since we have so many traits ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've opted for defining some relevant constants that addons may need (I've though to the cases mentioned above), but still use numbers for the core. Have a look.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, so as future step we could think to generalize this pattern as is exactly the same we are using for the builder so we should probably come up with a sort of a reusable finite step machine framework
fab4b85
to
22dd722
Compare
22dd722
to
f81fda3
Compare
Let's merge this.. GH actions are flacky today.. |
Fix #1234
Needs apache/camel-k-runtime#242
This removes the trait static lists and allow to dynamically define traits also in other packages. This added the possibility to define an "addons" package. Currently addons are always loaded, but technically they can be easily disabled at both build time or runtime.
The idea is, for the future, to include addons for other external projects, so that Camel K can leverage them to auto-configure the integrations.
Examples of traits that are best placed in the addon package are:
About the master component: it's using the
camel-k-runtime-master
module, which embedscamel-kubernetes
to do leader election.It's enabled by default when someone uses a route like:
So that that route is started only once, no matter how many
replicas
you set in the integration (works also with auto-scaling integrations).By default, each integration has its own lock domain (i.e. configmap), but configuration can be tweaked to let two different integrations share the same lock if needed.
Release Note