Bugfix/k8s context

[johrstrom]

Fixes #227 . Users will now have to configure a context to get the --context flag. I'm wondering if we want to supply context = cluster if we're using OIDC? I'll have to check the hooks and what sort of assumptions we make if we're using OIDC.

It's a little bigger of a change that I wanted, but here we are. This also fixes a few bugs that, were just there, I'll try to note them where I can.

The idea here is to get an OOD initializer to run this class method (which has tests).

Batch.configure_kube!(cfg)

[johrstrom]

managed was misspelled here. fixed in this pr.

[Oglopf]

LGTM.

[johrstrom]

@treydock this is still open for review if you like. I think we're going to force folks to set context if they need it, which OIDC does. Again, I have to take a second look at the hooks to see what assumptions they make.

[treydock]

@johrstrom Should this default to @cluster to maintain past behavior? I think forcing a context makes sense since not having forced context can cause a lot of problems and lead to sites easily having weird behavior. If we don't force a context then this will require a Puppet change so OSC side doesn't break. It would still require a Puppet change to expose all options but not required if we have sane default.

[treydock]

Left one inline comment. One issue I see is you made using the context flag based on if context is set but we still call set_context no matter what since that's called by configure_auth. So if we are always going to set a context, it seems like should also always be setting a context and not make contexts optional but, like my other comment, have a sane default for context and always set one.

[treydock]

Also the K8 hooks don't appear to reference any kind of context. One hook just bootstraps RBAC resources and another sets the kubeconfig credentials which only needs the K8 Username so like dev-tdockendorf kind of thing, no context used.

[treydock]

So not sure I fully understand the rationale behind not setting context but I do understand not doing kubectl config set-context because that can cause one OnDemand instance to set default context that collides with another OnDemand instance. I think one possible solution is always set a context, always use --context flag to ensure using proper context but do not run kubectl config set-context to avoid forcing a default context in kube config.

[johrstrom]

We're likely presenting something to SC about kuberenetes, so I want to get it all sorted out and documented by then.

I keep thinking - we can't break something we've never documented. Seems like oidc needs context. so maybe we can throw an error or some indication that they didn't set it? or default only if it's OIDC?

Using a default across the board, I'm not sure about - I'm fairly sure gke sets programatically where you wouldn't know the context beforehand? I'm working on getting creds set back up for that.