squakez commented on pull request #2771: URL: https://github.com/apache/camel-k/pull/2771#issuecomment-978997002
Thanks for the review @astefanutti, those are very good points to discuss. > A couple of points: > > * Would the ultimate place to reference these ConfigMaps be in a new _configuration_ trait, as discussed in #2320, maybe as a second iteration to this? That is partially correct. The idea is to move configmap/secret managment there as soon as this part would be completed. So, once autogenerated, the configmaps will be managed as any user provided configmap into the `configuration` trait. However, the generation part must be done in the CLI, because the trait is executed by the operator and won't be able to access the local file content. > > * Should the operator watch these owned ConfigMaps for changes, and reconcile the parent Integration? > > * If yes, as a sub-case, the Integration phase could be set to `Error` if a referenced ConfigMap got deleted by mistake. > * It relates to #1235 and #2106 possibly > I don't think this would apply to autogenerated configmaps. In my view, these kind of configmaps are just a support to the local file content. I've worked to support `sync` option and have an Integration redeploy when we detect a change in the local file, that will translate in a **new** configmap. However, in a production environment, I expect the user to provide "normal" configmaps if there is the possibility to change the underlying content (and in that case still apply the issues reported above). > * Are the generated ConfigMaps really immutable? They must be, IMO. The name is generated from a SHA based on the file content and nobody should alter them as they are thought as a representation of the local file. > > * Would that make sense to go the same direction for the `SourceSpec` field? Not sure if it makes sense. I think that the `SourceSpec` is a core part of the Integration, and we must allow anybody that want to provide an Integration with `kubectl` to do that without adding additional steps (ie, creating a configmap, then setting it in the Integration). A resource, instead, is already something complementary to the Integration. If we go in this direction, in fact, the user that creates directly Integration won't be allowed any longer to create a `ResourceSpec` with content and will need to create a configmap on his own. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
