merge vCluster charts & new values.yaml #1583
Conversation
✅ Deploy Preview for vcluster-docs canceled.
|
FabianKramm
force-pushed
the
main
branch
2 times, most recently
from
fe58b7c
to
13a290b
Compare
FabianKramm
force-pushed
the
main
branch
2 times, most recently
from
e9de85c
to
ddce771
Compare
FabianKramm
force-pushed
the
main
branch
21 times, most recently
from
547d2be
to
fdd2b9c
Compare
FabianKramm
force-pushed
the
main
branch
4 times, most recently
from
c8e4d84
to
5260a0c
Compare
FabianKramm
changed the title
| case config.K3SDistro: | ||
| distroConfig = config.VirtualClusterKubeConfig{ | ||
| KubeConfig: "/data/server/cred/admin.kubeconfig", | ||
| ServerCAKey: "/data/server/tls/server-ca.key", | ||
| ServerCACert: "/data/server/tls/server-ca.crt", | ||
| ClientCACert: "/data/server/tls/client-ca.crt", | ||
| RequestHeaderCACert: "/data/server/tls/request-header-ca.crt", | ||
| } | ||
| case config.K0SDistro: | ||
| distroConfig = config.VirtualClusterKubeConfig{ | ||
| KubeConfig: "/data/k0s/pki/admin.conf", | ||
| ServerCAKey: "/data/k0s/pki/ca.key", | ||
| ServerCACert: "/data/k0s/pki/ca.crt", | ||
| ClientCACert: "/data/k0s/pki/ca.crt", | ||
| RequestHeaderCACert: "/data/k0s/pki/front-proxy-ca.crt", | ||
| } | ||
| case config.EKSDistro, config.K8SDistro: | ||
| distroConfig = config.VirtualClusterKubeConfig{ | ||
| KubeConfig: "/pki/admin.conf", | ||
| ServerCAKey: "/pki/ca.key", | ||
| ServerCACert: "/pki/ca.crt", | ||
| ClientCACert: "/pki/ca.crt", | ||
| RequestHeaderCACert: "/pki/front-proxy-ca.crt", | ||
| } | ||
| } |
There was a problem hiding this comment.
wouldn't this be a good occasion to put the certs in the same directory?
There was a problem hiding this comment.
problem is that the certs are generated not always by us and are called different even if in the same directory. Its a good idea, but I would separate this change from this PR
| retConfig := v.Config.Experimental.VirtualClusterKubeConfig | ||
| if retConfig.KubeConfig == "" { | ||
| retConfig.KubeConfig = distroConfig.KubeConfig | ||
| } | ||
| if retConfig.ClientCACert == "" { | ||
| retConfig.ClientCACert = distroConfig.ClientCACert | ||
| } | ||
| if retConfig.ServerCAKey == "" { | ||
| retConfig.ServerCAKey = distroConfig.ServerCAKey | ||
| } | ||
| if retConfig.ServerCACert == "" { | ||
| retConfig.ServerCACert = distroConfig.ServerCACert | ||
| } | ||
| if retConfig.RequestHeaderCACert == "" { | ||
| retConfig.RequestHeaderCACert = distroConfig.RequestHeaderCACert | ||
| } |
There was a problem hiding this comment.
could we use something like mergo to set those ? That would simplify the process
There was a problem hiding this comment.
I guess its not too bad to have this explicit for now since its just 5 fields and people don't know how mergo operates and we rely on another dependency for 10 lines of code
| if v.Config.ControlPlane.Distro.K3S.Enabled { | ||
| return config.K3SDistro | ||
| } else if v.Config.ControlPlane.Distro.K0S.Enabled { |
There was a problem hiding this comment.
this is a little redundant no? without that if the function is the same
There was a problem hiding this comment.
Thing is more that we want to have k3s if all are disabled, so we need that function
There was a problem hiding this comment.
yeah but it's not the point, if you lose
if v.Config.ControlPlane.Distro.K3S.Enabled {
return config.K3SDistro
} elsethe end result is the same still. because the default will be to return k3s
| var ( | ||
| verbs = []string{"get", "list", "create", "update", "patch", "watch", "delete", "deletecollection"} | ||
| ) |
There was a problem hiding this comment.
you can add enums with jsonschema using tags so that will even work within the helm chart
There was a problem hiding this comment.
We need this within golang code as well, e.g. if people don't use our helm chart
There was a problem hiding this comment.
but now if they do only use our helm charts they don't have the validation
We can run jsonschema validator within go and get the errors, that way validation would be consistent across the board
There was a problem hiding this comment.
https://github.com/santhosh-tekuri/jsonschema/tree/v5.3.1 for example would allow us to validate the schema for everything that we can, and then rely on go code to only validate things that aren't possible with the schema
That also would allow us to be able to validate for more than 1 version when we introduce breaking changes
FabianKramm
force-pushed
the
main
branch
4 times, most recently
from
baaff7e
to
3e40c46
Compare
FabianKramm
changed the title
FabianKramm
force-pushed
the
main
branch
5 times, most recently
from
d332a17
to
f24afb3
Compare
What does this pull request do? Which issues does it resolve? (use
resolves #<issue_number>if possible)resolves ENG-2955