It seems that okteto manifest files could be treated as environment “Makefiles” for your cluster. Has the team had any thought on making the manifest hierarchical?
i.e. Instead of having to define my dev section in one manifest, I can have a tree of manifests for each component in a sub-directory which a root manifest picks up by scanning for child okteto.yaml files.
Then from the root I could pick one of them and enter that environment. But more importantly, it would be nice if I could share Pod descriptions (for example, I have a slew of services that all use the same container and Pod specification which I believe I have to duplicate across services).
This is super interesting. In the past we have discussed implementing a templating engine of some sorts to help with cutting down on repetitive manifests, and to make it easier to share definitions across teams.
This takes it to the next level. I don’t think we’ve thought about it from a hierarchical perspective.
In this tentative approach, would the subfolders only include the definitions for a specific microservice?
Sorry for the delay: Basically, top level could define contexts that could be reused at lower levels and passed along (similar to your templating engine, think kustomize or even make).
The issue right now is every okteto has to be repeated for every microservice. Would be great to have a common global okteto and then reference it from lower level services but make the small changes needed. This would also allow me for instance to stay at a higher-level directory for development and do 'okteto up foobar-web-service` and it could read the hierarchy and then do the right thing. This also promotes shared configuration as you said.
Even if you did a templating engine, it would still need to be hierarchical to be truly powerful. I realize yaml does not have a built in include directive but I think either custom tag or some path search logic that registers contexts etc. (again think make).