Commit Graph

10 Commits

Author SHA1 Message Date
Matt Moyer
434e3fe435
Refactor integration test environment helpers to be more structured.
This change replaces our previous test helpers for checking cluster capabilities and passing external test parameters. Prior to this change, we always used `$PINNIPED_*` environment variables and these variables were accessed throughout the test code.

The new code introduces a more strongly-typed `TestEnv` structure and helpers which load and expose the parameters. Tests can now call `env := library.IntegrationEnv(t)`, then access parameters such as `env.Namespace` or `env.TestUser.Token`. This should make this data dependency easier to manage and refactor in the future. In many ways this is just an extended version of the previous cluster capabilities YAML.

Tests can also check for cluster capabilities easily by using `env := library.IntegrationEnv(t).WithCapability(xyz)`.

The actual parameters are still loaded from OS environment variables by default (for compatibility), but the code now also tries to load the data from a Kubernetes Secret (`integration/pinniped-test-env` by default). I'm hoping this will be a more convenient way to pass data between various scripts than the local `/tmp` directory. I hope to remove the OS environment code in a future commit.

Signed-off-by: Matt Moyer <moyerm@vmware.com>
2020-09-24 18:03:45 -05:00
Matt Moyer
2d4d7e588a
Add Go vanity import paths.
Signed-off-by: Matt Moyer <moyerm@vmware.com>
2020-09-18 14:56:24 -05:00
Matt Moyer
8c9c1e206d
Update module/package names to match GitHub org switch.
Signed-off-by: Matt Moyer <moyerm@vmware.com>
2020-09-17 12:56:54 -05:00
Andrew Keesler
eab5c2b86b
Save 2 lines by using inline-style comments for Copyright
Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-09-16 10:35:19 -04:00
Andrew Keesler
e7b389ae6c
Update copyright to reference Pinniped contributors
Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-09-16 10:05:51 -04:00
Ryan Richard
80153f9a80 Allow app to start despite failing to borrow the cluster signing key
- Controller and aggregated API server are allowed to run
- Keep retrying to borrow the cluster signing key in case the failure
  to get it was caused by a transient failure
- The CredentialRequest endpoint will always return an authentication
  failure as long as the cluster signing key cannot be borrowed
- Update which integration tests are skipped to reflect what should
  and should not work based on the cluster's capability under this
  new behavior
- Move CreateOrUpdateCredentialIssuerConfig() and related methods
  to their own file
- Update the CredentialIssuerConfig's Status every time we try to
  refresh the cluster signing key
2020-08-25 18:22:53 -07:00
Ryan Richard
6e59596285 Upon pod startup, update the Status of CredentialIssuerConfig
- Indicate the success or failure of the cluster signing key strategy
- Also introduce the concept of "capabilities" of an integration test
  cluster to allow the integration tests to be run against clusters
  that do or don't allow the borrowing of the cluster signing key
- Tests that are not expected to pass on clusters that lack the
  borrowing of the signing key capability are now ignored by
  calling the new library.SkipUnlessClusterHasCapability test helper
- Rename library.Getenv to library.GetEnv
- Add copyrights where they were missing
2020-08-24 18:07:34 -07:00
Ryan Richard
3929fa672e Rename project 2020-08-20 10:54:15 -07:00
Matt Moyer
1b9a70d089
Switch back to an exec-based approach to grab the controller-manager CA. (#65)
This switches us back to an approach where we use the Pod "exec" API to grab the keys we need, rather than forcing our code to run on the control plane node. It will help us fail gracefully (or dynamically switch to alternate implementations) when the cluster is not self-hosted.

Signed-off-by: Matt Moyer <moyerm@vmware.com>
Co-authored-by: Ryan Richard <richardry@vmware.com>
2020-08-19 13:21:07 -05:00
Ryan Richard
4cb0fd3949 Use a DaemonSet instead of a Deployment to deploy our app
- For high availability reasons, we would like our app to scale linearly
  with the size of the control plane. Using a DaemonSet allows us to run
  one pod on each node-role.kubernetes.io/master node.
- The hope is that the Service that we create should load balance
  between these pods appropriately.
2020-08-11 17:55:34 -07:00