Best practices for running a workshop on Nebari?

[rsignell-usgs]

We have a workshop coming up on May 10 where we would like to make it easy for folks to use Nebari for a limited time. There will be about 50 people in the workshop, with many scientists who don't have github accounts (and don't really want them!).

Hoping for something easy:

• login with their email as username and have a common password?
• load a CSV file with username/passwords into keycloak?
• other?

We are thinking we will create the deployment before the workshop, then destroy it a few weeks later.

What is the best practice for this type of Nebari use?

[iameskild]

Hi @rsignell-usgs, even for deployments that rely on using OIDC (Auth0, GitHub, etc), Keycloak allows you to add users who only require a username/password to log in.

I quickly created a function below that will take a CSV of users (first name, last name, email) and then generates an output.json file that you can import from the keycloak admin console -- see this gist.

In my opinion, this function would be a handy addition to the Nebari CLI ;)

cc @kcpevey @dharhas

[iameskild]

Hey @rsignell-usgs I think this is because the user isn't included in any of the groups. I update the gist to include a groups section. With this, it should work. I just tested it again and it worked for me.

[rsignell-usgs]

@iameskild we discovered the hard way that we could only import 10 users at a time using this method. If we had more than 10 users in the CSV (and in the JSON), we got the following screen:

Is this a setting in keycloak that could be changed?

[rsignell-usgs]

@iameskild and if we are stuck with 10 imports at a time, is there an easier way? Like just letting anyone sign up with their email as username and a specified password that they need to change? This would probably be easiest for people running workshops like @kcpevey and myself

[kcpevey]

There is an option to allow anyone to register with ANY email address (read: fake is okay). They set their own password. This essentially leaves the whole system wide open though.

I'm not sure if there is an additional step we can add in to force an admin to verify each newly registered user before granting access?

[iameskild]

Hey @rsignell-usgs @kcpevey I just tested this myself and I was able to add more than 10 users in one go. Perhaps try selecting Skip if the user already exists.

[dharhas]

@rsignell-usgs If you are planning to use Dask, you might have an issue. I did a big data Dask tutorial on Nebari at PyCon with about 50 ppl and Dask-Gateway fell over due to the load of everyone requesting a cluster at the same time. Dask worked fine once you had a client but starting a cluster and getting a client through Dask Gateway was basically impossible.

@iameskild have you opened an issue about this yet?

[iameskild]

This issue captures our high-level findings: #1750

[kcpevey]

Opened up a docs issue to get this added as a tutorial page nebari-dev/nebari-docs#316

[rsignell-usgs]

We are making progress on configuring our Nebari workshop deployment, but still struggling a bit.

We added a users group with the same client roles as the developer group, namely:
- argo-server-sso: argo_developer
- conda-store: conda_store_developer
- grafana: grafana_developer
- jupyterhub: dask_gateway_developer, jupyterhub_developer

Members of this group can create dask gateway clusters and they can select user namespace environments from the kernel selecter and activate user environments from the terminal (although they get back messages like this when they do so:

mkdir: cannot create directory ‘/home/conda/users/envs/users-pangeo/share/gdb/auto-load//home/conda/users/envs’: Permission denied

Members of this users group don't seem to be able to create or modify environments in conda-store in the users namespace. That might be okay for training since you don't want them changing the environment anyway, but this is different behavior than we had on our previous deployment.

Is there some other client role that is needed for environment creation to work?

[pavithraes]

@iameskild Do you have thoughts on this?