feat(#5354): Allow adding toleration into builder pod

[vkrejcirik]

Closes: #5354

Release Note

feat: Allow defining tolerations for Builder pod.

[squakez]

Thanks for the work. I think it would be better to reuse the same approach we've used for Integrations' tolerations. See https://github.com/apache/camel-k/blob/main/pkg/apis/camel/v1/trait/toleration.go - you may reuse entirely the same logic. Ideally we should provide the concept of taint, and have a way to express it in the same syntax so it is easier from CLI to set via -t builder.taint=... (which should also the way we unit test it).

[squakez]

BTW, also better to squash the commits into a single one in order to have a cleaner history.

[squakez]

Maybe some alternative approach would be to work directly on the Toleration trait, having an additional option like -t toleration.pipeline-taint=... and have all the logic encapsulated in a single place. In the same way we may rework the affinity etc.

[vkrejcirik]

Thanks for the work. I think it would be better to reuse the same approach we've used for Integrations' tolerations. See https://github.com/apache/camel-k/blob/main/pkg/apis/camel/v1/trait/toleration.go - you may reuse entirely the same logic. Ideally we should provide the concept of taint, and have a way to express it in the same syntax so it is easier from CLI to set via -t builder.taint=... (which should also the way we unit test it).

I was essentially following the approach from #4968 as we discussed. I like the approach of extending Toleration trait with new option for Builder pod and having the logic in a single place. So, if we are on the same page and that's what you prefer, I can look into adding this functionality there.

Thanks

[squakez]

I was essentially following the approach from #4968 as we discussed. I like the approach of extending Toleration trait with new option for Builder pod and having the logic in a single place. So, if we are on the same page and that's what you prefer, I can look into adding this functionality there.

Thanks

Yeah, I would have preferred that. However, I think that now we've already taken the other path, ie, the nodeselector is already on the builder trait, so, it would feel weird to require another trait for toleration. Let's keep this here for now, but try to reuse the logic already available in the other trait (ie, transforming the taints).

[vkrejcirik]

Okay, I will look into it.

[github-actions]

⚠️ Unit test coverage report - coverage decreased from 40% to 39.9% (-0.1%)

[squakez]

Any update on this development? I'd like to understand if it may be ready to be included in 2.4.0 (#5678)

[vkrejcirik]

Im currently busy with our client. We are finishing project. I would like to pick up on this next or following week. I apologize for delay.

[squakez]

Im currently busy with our client. We are finishing project. I would like to pick up on this next or following week. I apologize for delay.

No problem, there's no hurry. I understand that if it does not make in time for 2.4 will be fine to defer for 2.5.

[github-actions]

This PR has been automatically marked as stale due to 90 days of inactivity.
It will be closed if no further activity occurs within 15 days.
If you think that’s incorrect or the issue should never stale, please simply write any comment.
Thanks for your contributions!