-
Notifications
You must be signed in to change notification settings - Fork 344
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
fix(trait): define synthetic Kit #5399
Conversation
While working on apache#5378 I realized the concept of external Kit is used widely also for the concept of what is a Synthetic Kit. An external Kit is a kit coming from a build from the operator, whilst a synthetic Kit is not coming from an operator.
d432937
to
48a0e6c
Compare
Sorry for being late but wonder if a better name would have been
Another observation is that, the |
@lburgazzoli that's exactly the goal of this PR, regardless the name used for the parameter. Definitely, |
I wonder if this should be a kit only property/annotation rather than a trait, in fact even if the container image was built by camel-k, the absence of a kit may not make it 100% usable (my memory may not be 100% up to date, but the kit was also supposed to carry some traits, even some runtime traits so that all the integration executed with that kit had some common characteristics) |
I think we're talking about slight different things then. The problem we have is that when the user is running an Integration with I understand that you're proposing to force the possibility to run a container image previously built by the operator only with the associated IntegrationKit (which must be copied from its source), is it correct? This feature already exists (ie, In that case what we need to do is just removing the new parameter included in this PR (only the parameter as the rest of the PR goes in the direction to let a user run an opaque container image without the execution of those traits that need an IntegrationKit). And we need to adjust our test, as, the main reason of this PR was to address certain failing tests that were assuming that we can run an Integration with a |
It is a little bit broader than this because as today you can instruct camel-k to run an integration against a pre-existing container image in two ways:
Now I think is where things gets a little bit confusing as yes you can use This is why I think, the information about the image format is more a Kit specific trait (maybe it can be part of the spec, along with the image property).
I think @valdar did some work in #5119 to fix this issue , may be worth having a look. |
As discussed in apache#5399 we need to clarify the intent of each IntegrationKit types. * removal of imageWasKit * usage of external IntegrationKit when we are certain that the image comes from an IK * usage of syntetic IntegrationKit when the image are coming from any container image * rework of promote command to clone an external IntegrationKit beside the Integration and use it accordingly. Closes apache#5408
As discussed in #5399 we need to clarify the intent of each IntegrationKit types. * removal of imageWasKit * usage of external IntegrationKit when we are certain that the image comes from an IK * usage of syntetic IntegrationKit when the image are coming from any container image * rework of promote command to clone an external IntegrationKit beside the Integration and use it accordingly. Closes #5408
As discussed in apache#5399 we need to clarify the intent of each IntegrationKit types. * removal of imageWasKit * usage of external IntegrationKit when we are certain that the image comes from an IK * usage of syntetic IntegrationKit when the image are coming from any container image * rework of promote command to clone an external IntegrationKit beside the Integration and use it accordingly. Closes apache#5408
As discussed in #5399 we need to clarify the intent of each IntegrationKit types. * removal of imageWasKit * usage of external IntegrationKit when we are certain that the image comes from an IK * usage of syntetic IntegrationKit when the image are coming from any container image * rework of promote command to clone an external IntegrationKit beside the Integration and use it accordingly. Closes #5408
As discussed in apache#5399 we need to clarify the intent of each IntegrationKit types. * removal of imageWasKit * usage of external IntegrationKit when we are certain that the image comes from an IK * usage of syntetic IntegrationKit when the image are coming from any container image * rework of promote command to clone an external IntegrationKit beside the Integration and use it accordingly. Closes apache#5408 (cherry picked from commit apache/camel-k@aa6202c51)
While working on #5378 I realized the concept of external Kit is used widely also for the concept of what is we can define as a synthetic Kit. For this user generated container image (likely not from the operator build) we cannot make any assumption when it come to certain traits which require the presence of a CamelCatalog bound to a given runtime provider and version.
This PR would define the new type of kit, giving the possibility to the user to leverage
container.imageWasKit=true
configuration to instruct the operator that the image imported (ie, viakamel run --image
) was coming from a Kit, hence, it can make all the assumptions about it. Conversely, in presence of a "synthetic" kit, the operator cannot make any assumption, above all when coming to the execution of JVM trait.Prerequisite of #5378
Release Note