introduce a forward-compatible way of specifying different sources for the apiserver CA that osprey's cluster-info endpoint needs
through the previous mechanism, introduce support for reading the apiserver ca from the cluster-info config map that the standard kubernetes kubeadm tool populates.
Specific changes introduced:
command line interface (cmd package)
refactor the code for handling some shared cli options (port, tls-key, ...) so that's it's shared by the auth and cluster-info serve subcommands, rather than being duplicated
add a (fairly rudimentary) unit test suite
add the apiServerCASource argument with file, in-cluster and config-map arguments. file is the current release behavior, and the default. in-cluster represents the current default behavior when the apiServerCA cli arg is not specified (and is added to make it easier to be explicit in osprey configs). config-map implements the new behavior.
the server library (server package)
refactor the NewXXXServer functions to take a single struct with config, rather than umpteen positional arguments
also pass this config struct to NewServer in the web package rather than some booleans
test suite
add e2e tests for the osprey serve cluster-info command
small refactorings
move ReadAndEncodeFile helper into a utility module
aecay
commented
2 years ago
The goal of this PR is to:
cluster-infoconfig map that the standard kuberneteskubeadmtool populates.Specific changes introduced:
cmdpackage)apiServerCASourceargument withfile,in-clusterandconfig-maparguments.fileis the current release behavior, and the default.in-clusterrepresents the current default behavior when theapiServerCAcli arg is not specified (and is added to make it easier to be explicit in osprey configs).config-mapimplements the new behavior.serverpackage)NewXXXServerfunctions to take a single struct with config, rather than umpteen positional argumentsNewServerin the web package rather than some booleansosprey serve cluster-infocommandReadAndEncodeFilehelper into a utility module