phantomjinx commented on pull request #2284: URL: https://github.com/apache/camel-k/pull/2284#issuecomment-857569798
> I'd like to keep the `config` directory structure as simple as possible, and as close to the Kustomize way as possible. It is important for developers that maintain the configuration, and for users relying on it. I find it a bit difficult with the current structure to understand the graph of resources (thinking how to use this without the Makefile can help). Noted. Maybe an ancillary directory structure targetting install-type operations would be more transparent? I am concerned about the differentiation between `openshift` and `kubernetes` resources. The 'mutually exclusive' question I have eluded to elsewhere but will determine what we do about this aspect of the directory structure. The original kustomize way makes no provision for this. > > Here are a few propositions that I have in mind: > > * Merge the `manager` and the `operator` directories (maybe keep `manager` which is the Kustomize way) > The `operator` directory's `kustomize.yaml` does more than the manager directory since its adds the infrastructure resources as well. They cannot be added to manager since they are operand-related and not operator-related. > * "Revert" the `infrastructure` directory: move the SA back into the `manager` directory, move the RBAC resources into the main `rbac` directory Discussed elsewhere but to summarize, these are operand resources that the operator should be installing rather than resources required to get the operator installed. These 2 concepts are fundamentally different and that division should be maintained, in my view. > > * Flatten the structure as much as possible: simplify the `rbac` directory, move patches into the same directory, rather than creating a dedicated directory. > I can certainly run with that philosophy for the main config directory. Anything that requires 'Makefile-magic' I can migrate to the 'install' directory instead. > > I've been reviewing this "interruptibly", so I apologise if the review sounds inconsistent or even off sweat_smile. Absolutely, not a problem. This is a longstanding issue with some rather knotty problems so happy to label this WIP and we'll keep returning to it, iteratively. -- 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
