Open manusa opened 2 years ago
This might also be interesting for CI purposes.
@manusa to implement this, can we directly edit the ./kube/config file in our new goal using oc config? I think this is a simple and straightforward solution, or am I missing something?
Sorry, I don't think this is a straightforward solution. We also need to check whether we even need to download oc
CLI since we deal with REST API directly.
The solution should basically do whatever the oc login
execution does. So the very first step is to identify where the oc login
code is and analyze what path is followed when executed when the token is provided as an argument.
Downloading the oc
client binary should be completely avoided (unless this is required for some reason).
I can work on this
As agreed internally and based on @juazugas notes:
oc:login
ocLogin
token
: The login token as retrieved from the OpenShift web consoleserver
: The server address as retrieved from the OpenShift web consolekubernetes.trust.certificates
: Trust the remote cluster's certificate in case it's unknown (n.b. this is a standard Fabric8 Kubernetes Client property that might not need to be handled by JKube's logic. However, it should be documented for this feature)token
and server
flags
The server uses a certificate signed by an unknown authority.
You can bypass the certificate check, but any data you send to the server could be intercepted by others.
To use insecure connections, repeat the command including the kubernetes.trust.certificates property.
kubernetes.trust.certificates
flag to skip the certificate verification, continue to 2.The token provided is invalid or expired.
.kube/config
(or the one configured as environment variable KUBECONFIG
-Fabric8 Kubernetes Client supports this-) with the following logic:
clusters
: Add/update entry with:
name
(copy logic from oc to sanitize the name)cluster.server
: server URL as passed from the command-line (server
property)cluster.insecure-skip-tls-verify
: if applicable, as passed from the command-line (kubernetes.trust.certificates
property)users
: Add/update entry with:
name
: Follows pattern $username/$clusterName
$username
should be retrieved by getting the ~
user (see Other notes)user.token
: token as passed from the command-line (token
property)contexts
: Add/update entry with:
name
: Follows pattern $namespace/$clusterName
(namespace must be inferred, see _Current namespace computation logic`context.cluster
: Value used in clusters[].name
context.user
: Value used in users[].name
context.namespace
: Value as inferred using the Current namespace computation logic
current-context
: Value used in contexts[].name
The namespace/project is automatically selected, following is the logic and order of precedence (needs to match logic in oc client, spec probably needs updating):
default
exists and is accessible.kube/config
contexts and get first matching */cluster.name/user.name
''
blank otherwise.kube/config
naming convention is namespace/cluster.name/user.name
self
user by getting the ~
resource from the user.openshift.io/v1
/users
API
/apis/user.openshift.io/v1/users/~
motd
ConfigMap in the openshift
namespace
api/v1/namespaces/openshift/configmaps/motd
I would like to add that I use my password instead of a token when logging in from the commandline with oc
. This saves me a round-trip to the web-based GUI to retrieve my token. So if this issue is about workflow speed-up / better experience, one might need to consider adding support for logging in with password also (not just logging in with token).
I would like to add that I use my password instead of a token when logging in from the commandline with
oc
. This saves me a round-trip to the web-based GUI to retrieve my token. So if this issue is about workflow speed-up / better experience, one might need to consider adding support for logging in with password also (not just logging in with token).
Right! Given the complexity of the issue/story at hand, I'd consider this as a separate issue to be completed once this one is done.
Context
I was in a Java user group (JUG) meetup yesterday giving a workshop about Kubernetes for Java developers.
The workshop includes several activities, the first one being deploying a Java application into OpenShift using the OpenShift Maven|Gradle plugin. Then it continues with other tasks involving the interaction with Kubernetes using Java (this includes tools such as the Fabric8 Kubernetes Client and JBang).
When performing the first task, users login into an OpenShift console with a user and credentials provided. The following steps apply:
example-user-nn
|example-password
oc
tool from the consoleoc new-project example-user-nn
Experience issues
The purpose of steps 3 to 5 is just to add the appropriate entry in your
.kube/config
file so that JKube->Fabric8 can pick those up.When performing step
3
, we need to download a very big file and extract it just to achieve this very simple purpose. This simply adds a network overhead and extra steps that really won't provide much value for the Java only experience.When performing step
5
, most users will need to execute./oc login $token
which might cause a number of issues. The first thing is that most users won't haveoc
in their path, so they will need to open a terminal in the location of theirDownloads
directory. In some operating systems (OS)s this step might be prevented (security) and will need some override settings.The last hassle during the workshop was the creation of the project (step
6
). The provided cluster didn't have an assigned default project for each user and this step was required. We need to make sure (maybe this already works) that we can overcome this issue by using the JKube's built-in features to create a Namespace->Project and use it.Possible solutions
Implement an OpenShift specific login goal/task that would allow the users to skip steps 3 to 5.