squakez commented on PR #4808: URL: https://github.com/apache/camel-k/pull/4808#issuecomment-1752590370
> From what I see the Kamelet reconciliation is doing sanity checks on properties and names. Also it computes the Kamelet properties and sets the computed list of properties on the Kamelet status for later usage of default values as application properties. > > I think it is not a bad idea to check the Kamelet when a user changes/adds a Kamelet as a CR. In case we ignore changes and just add the Kamelet as source to the runtime without such a check errors will be reported late in the process at Integration runtime only. Isn't it a good idea to fail fast when the Kamelet is changed and avoid adding it to the Integration when it is broken? > > In general I think having the Kamelets as CRs is a huge benefit Thanks for the feedback. As I mentioned in the description, in order to understand this PR we need to have a look at #4797 first. In that PR we are letting the management of default properties to the runtime. This PR won't remove Kamelets as CR, it will remove its dynamic nature. However the reconciliation today its just making sure that it's a valid name [1]. We can make sure that any validation around names is performed statically when we submit the CR (this is something Kubernetes already does). Mind that this Kamelets mechanics was introduced when Kamelets were not yet a Camel thing, so, likely the reconciliation had a sense back in time. Today it really does nothing that cannot be performed statically. [1] https://github.com/apache/camel-k/pull/4808/files#diff-cdf7e0a6d3147483dcf44a245614fd61ed854341b53c70c9618aac51845ff97aL31 -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
