astefanutti commented on pull request #2771: URL: https://github.com/apache/camel-k/pull/2771#issuecomment-1003988144
> I've finished another iteration of development in order to address the points discussed previously. With [d85257c](https://github.com/apache/camel-k/commit/d85257c2e180826df677b472da5a484093ae8b69) we're now validating the input submitted to the trait: we won't allow anything but `configmap` or `secret`. With [78e62f4](https://github.com/apache/camel-k/commit/78e62f4742bc1347218496a3be09348c979b7608) we're introducing a new trait, called `mount` which can be used to _mount_ volumes from the different resources we allow. > > I prefer this name to a generic `resource` as it declare exactly its purpose. It sounds and looks great to me 👍🏼. > The last outstanding point is about garbage collecting the autogenerated configmaps that are used and later removed. Right now they will live beside the Integration, until this one is deleted. I cannot figure out how to manage differently and let them be garbage collected as soon as they are updated (unless we do a manual clean). IMO we can keep them along. What I'm thinking is a process like this: 1. The CLI creates the ConfigMap with the `camel.apache.org/generated` annotation, and does only that 2. The _mount_ trait adds the ConfigMap to the Integration resources, by iterating over its configured ConfigMaps, and filtering those annotated with `camel.apache.org/generated` 3. The _owner_ trait sets ownership on the ConfigMap OOTB 4. The _gc_ trait associates the ConfigMap to the Integration current generation, and eventually garbages it OOTB -- 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]
