Skip to content
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

Make it possible to define the container image without IntegrationKit #2360

Merged
merged 1 commit into from
Jun 7, 2021

Conversation

lburgazzoli
Copy link
Contributor

Release Note

NONE

@astefanutti
Copy link
Member

Thinking out loud, I wonder whether we could skip the creation of the kit altogether, by setting the Integration .status.image field directly from the new container trait configuration parameter? I find creating an empty IntegrationKit rather useless, even misleading.

@lburgazzoli
Copy link
Contributor Author

Thinking out loud, I wonder whether we could skip the creation of the kit altogether, by setting the Integration .status.image field directly from the new container trait configuration parameter? I find creating an empty IntegrationKit rather useless, even misleading.

Yep, that would be an option however I wasn't sure if the IntegrationKit is maybe referenced somewhere in the processing pipeline

@lburgazzoli
Copy link
Contributor Author

@astefanutti so yes, at the moment the IntegrationKit is likely needed as the environment requires it and some of the trait expect it to be defined i.e. to borrow configurations & so on so we may need a deep refactor if we want to have an option to entirely skip it.

@astefanutti
Copy link
Member

@astefanutti so yes, at the moment the IntegrationKit is likely needed as the environment requires it and some of the trait expect it to be defined i.e. to borrow configurations & so on so we may need a deep refactor if we want to have an option to entirely skip it.

The opposite would have been surprising :) It should be fine to do it in two steps, and implement the kitless approach in a second issue. Even after an upgrade to the later version, the Integration should work seamlessly.

@astefanutti
Copy link
Member

Now if we decide to stick to the proposed approach, would enlisting the IntegrationKit into the environment resources, and let the deployer trait apply it work, instead of creating it explicitly?

@lburgazzoli
Copy link
Contributor Author

@astefanutti so yes, at the moment the IntegrationKit is likely needed as the environment requires it and some of the trait expect it to be defined i.e. to borrow configurations & so on so we may need a deep refactor if we want to have an option to entirely skip it.

The opposite would have been surprising :) It should be fine to do it in two steps, and implement the kitless approach in a second issue. Even after an upgrade to the later version, the Integration should work seamlessly.

We really need to sit down ad rethink a little how traits are implemented, guess there is room for improvement.

@astefanutti astefanutti changed the title Make it possible to define the ocontainer image without IntegrationKit Make it possible to define the container image without IntegrationKit Jun 4, 2021
@lburgazzoli
Copy link
Contributor Author

Partial implementation of #2232

@lburgazzoli lburgazzoli marked this pull request as ready for review June 4, 2021 15:15
@astefanutti astefanutti merged commit c37f1f7 into apache:main Jun 7, 2021
@lburgazzoli lburgazzoli deleted the binding-no-kamelets branch June 7, 2021 06:55
@nicolaferraro nicolaferraro mentioned this pull request Jul 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants