|
|
|
|
|
by hyscale
2127 days ago
|
|
Thanks for your encouraging comments :) Answers to your Questions: 1. The expectation is that people deploying through hyscale don’t want to go and modify K8s resources directly on the cluster behind the scenes. If they do, then it either deviates from the hspec files in git or they have parallel K8s yamls which won’t make much sense either. As of now, hyscale deploys and doesn’t keep anything (eg. controller) running, But it's a good suggestion to keep the K8s resources in sync with the desired state (hspec) and we’ll certainly put some thought into it. 2. HyScale outputs standard K8s manifest yamls which are as readable as any well hand-coded.
On the other hand, if there was a way to generate back hspec files from existing K8s yamls, would that be interesting/useful? 3. Suppose you have K8s resources/snippets already written for some of your services, you can refer to them in hspec and add application context to it and make use of profiles for environment variations.
If the question is more about off-the-shelf services (eg postgres, redis, etc), we have helm chart support coming up. https://github.com/hyscale/hyscale/wiki/Roadmap#2-ots-off-th... |
|
> 2
I don't mean literally generating hspec from yaml -- I mean more like operational "source map" support. For example if I look at a pod taking up more CPU than I expect in a dashboard somewhere, I should be able to trace it back to the hspec file.