Environment should come with a default user logged or not logged at all about learn-katacoda HOT 12 CLOSED

from learn-katacoda.

I can't remember setting to login as system:admin, I thought that was the default :)

Within the launch script we can change the environment to match. https://github.com/openshift-evangelists/intro-katacoda/blob/master/environments/openshift/scripts/openshift.sh

Could you tell me how to login as a different user please?

from learn-katacoda.

I guess it's not logged in on purpose, but it's there.

I would probably have no user logged in, by default, so asking for an implicit login, but if you want to login:

oc login -u default -p default

Would login a user named default. In default install of OpenShift, it uses anyuserandpassword, so you can log in with whatever you want.

We're still discussing this though. Copy involved parties for them to chime in.

cc/ @GrahamDumpleton @marekjelen @gshipley @mhausenblas @thesteve0 @Charlaxy

from learn-katacoda.

Yeah, developer:developer, I also use it here: https://www.katacoda.com/mhausenblas/courses/intro-openshift/kubectl-to-oc-new-app

from learn-katacoda.

I raised the issue of initial project and default user a long time back, probably before we were using issue tracker, so was in email. Was raised as part of discussion noting that stuff run from env-init.sh runs in parallel and not before user gets access. So although I was creating initial project and logging in user from script env-init.sh to get it, if user was very quick in firing off first command they could do it as wrong user or in wrong project as script hadn't fired the command.

What we possibly want is a way for initial project and user to be optionally set up. That is, not always do it. If we always enable doing it with 'developer/developer' as user and 'myproject' as default project (matching oc cluster up etc), then that project pre-created will break existing scenarios which say to create project. So need a way of saying what it done.

from learn-katacoda.

One issue with forcing a logged in user by default, is that you make it harder to run commands as an admin. You would need to reference the credentials from file in OpenShift config directory.

What I suggest is following.

• Create a new user called katacoda and have it logged in as that by default.
• Give the user katacoda sudoer role access so that if is this user at startup, still have a way of running admin commands from env-init.sh file by using impersonation, although still have issue those being in parallel, so need to be careful of doing that if telling user to login as different user.
• Create a new project called katacoda created by katacoda user and have it as default.
• Set up an admin user with cluster-admin role so have a user can login as to do admin stuff.

This shouldn't break existing scenario flows as someone would still be able to login as developer as are doing now and create myproject.

Can have them log in as admin if need to run administrator stuff.

from learn-katacoda.

I could agree, but I don't :-D

I think that from env-init.sh, we can reference a KUBECONFIG file that logs a user as admin and just for that shell execution, so that can do provisioning without any boilerplate.

Then, I would in the VM have no user logged in and no project logged in, so that a user needs to explicitly login and create the project.

That would not break any scenario.

OK, with having the user admin precreated, for easy of use.

from learn-katacoda.

Don't disagree with referencing kubconfig in env-init.sh.

After having written five scenarios, working on sixth now, having to have the login/project creation as first exercise in all of them is getting to be a pain.

from learn-katacoda.

@GrahamDumpleton maybe we then need just to keep that for the "complete" tutorials. And the "deep dives" just use a logged in user and project.

from learn-katacoda.

Yep, which is why suggested a default logged in user and project of 'katacoda'. That way when login as 'developer' and create 'developer' project it still works and no conflict.

from learn-katacoda.

@GrahamDumpleton ok, then. You have convinced me.

from learn-katacoda.

Seems stale, please re-open if it persists.

from learn-katacoda.