datawire
High confusion potential : service.yaml use same term as "service" obj in K8S
K8S is hard to learn because we need to learn bunch of new concepts that already used on old one. K8S service as an k8s object is a perfect example.
Then, maybe, we should prefer new name to define services on forge. Maybe, forge.yaml should be fine. Isn't ?
@datawire Thank you for your work !
I very much like the values.yaml file for helm. This seems like it is a similar concept. It is very unclear to a forge beginner why this file does not contain apiVersion: v1 \ kind: Service.
Between this issue and #61, I can definitely see growing forge.yaml into something that could supplant service.yaml (including a version/kind indicator). I will try to put together a proposal and post something for you guys to look at, although probably will have to wait until after kubecon next week.
I'm in a agreement. Service is a really overloaded term... In Kubernetes we have:
- "Service" as in the routing concept.
- "Service" as in "microservices" which is what people often use Kubernetes to deploy.
When I say "Write a service" it's sometimes ambiguous. I've struggled to clarify this confusion when doing talks or speaking 1 on 1 with folks.
Forge also overloading "service" for its configuration is additional confusion. Statements like "Modify the service config" are really confusing.
Service in Kubernetes don't provide routing (but, I know, forge permit that. It's cool. ). In my specific case, I need forge as an Ingress solution to manage connections from internet. (+ more maybe).