astefanutti commented on issue #2320: URL: https://github.com/apache/camel-k/issues/2320#issuecomment-922742227
> > > One possibility would be to get rid of `file`. After all, the user should have familiarity with cloud native way of storing resources (ie, `configmap`) and create them beside the integration. The same would apply to `--openapi` and would deprecate `.integration.spec.resources` as well. > > > > > > Right. Alternatively, the `kamel run` CLI could be responsible for creating the ConfigMap corresponding to the `file:` config option. to avoid that two-stepped experience. Anyway, I agree we should avoid storing arbitrary files into the Integration resources. > > Yeah, I thought the same, but we even complicate the process as we need to parse twice. The first time in the `cmd` in order to process the content, the second time in the `trait` as we need to locate the resource. Moreover, I am not sure if we would actually able to scale or recreate the Pod properly. Right now we leverage the presence of the content in the `Integration`, if we create an attached `configmap` we will have to make sure this is not deleted unless the user is deliberately deleting the `Integration`. I think we can enter in a dangerous path. You're right, but I think Camel K should not concern about it. This should be delegated to the underlying Kubernetes controller, like the Deployment controller, as much as possible. For example, if the user deletes the ConfigMap, the Deployment controller will handle it. For the use case of responding to changes, it's also a vast area with long standing issues like kubernetes/kubernetes#22368. -- 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
