Enhance GitOps generation for Kubernetes resources
Opened this issue · 0 comments
With the PR #34, we are updating how the GitOps resources are to be generated. In summary, #34 skips generation of GitOps resources if the GitOps resources were passed in instead. For instance, if Deployment resource was passed in and Service or Route were not; Service and Route would be generated.
However, this PR also allows N Kubernetes resources of various types to be passed in. First resource of Deployment, Service and Route are saved in their respective files - deployment.yaml, service.yaml and route.yaml; whereas the other N-1 deployments, N-1 services, N-1 routes, other N Kubernetes resources are saved in a file other_resources.yaml
.
During the PR review discussion #34 (comment), it was suggested that resources be saved in their specific type. For instance; 100-service.yaml, 101-service.yaml, 102-service.yaml, etc.
This approach needs to be thought out more before being implemented. I have raised a few questions in the discussion that perhaps need to be expanded and thought on:
- what happens if there are N resources, do we want to actually create N no of files?
- what happens if the type is a custom resource, we need to think more about that from a logic POV
- think more around file name clash, if someone is going to commit a custom file in between GitOps generation