lburgazzoli commented on PR #5597: URL: https://github.com/apache/camel-k/pull/5597#issuecomment-2158805001
Since the `Pipe` is an higher level resource, I think it is fine if it has access to any of the spec properties of the `Integration` CRD like if it were any other client (in fact, in the `KameletBinding` reconciler has been originally implemented as a dedicated operator, and then merged in the camel-k operator). For the specific question about the fact that a binding resolver has access to the traits, then I think it is perfectly fine as the resolver should be able to influence how an integration behave. In term of code, I don't know if there is any better, less coupled option, but given it is already the way it works as today, then I'm fine with the implementation. The only two notes I can add are about UX, probably something not strictly related to this PR but, let me write them down here: - the fact that there is no subgroup for filter elements may be a little bit confusing as you don’t really know which properties are part of the filter and which are not. i.e. I recall one can add name property and that property would be used to determine the name of the broker if not provided in the ref - about the knative trait, the same as above can apply as there (maybe) are some conflicting properties maybe ? i.e. what happen if you set a filter for a non broker resource ? -- 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: commits-unsubscr...@camel.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
