Move to user-id vs. username for user deployments to avoid potential clashes

[alexellis]

Expected Behaviour

If I change my username I'd like to keep my functions. This may involve storing the GitHub user ID which can't change. I expect this to affect the router, auth and dashboard along with all the other functions in the flow.

Current Behaviour

If I change my user name on GitHub, I expect to keep my functions, but currently they get orphaned/lost because we can't map to the new username.

Possible Solution

Steps to Reproduce (for bugs)

1. Register as "username1"
2. Push a function
3. Rename to "username2"
4. Access dashboard for username2 and see no functions

Context

Do we want a migration script to back-fill GitHub user IDs after this work is done? Is this data public? @martindekov can you link to your previous script that we used for migration?

[alexellis]

We can start to consume the data for GitHub via this issue - https://github.com/openfaas/openfaas-cloud/issues/313

[ivanayov]

Derek assign: me

[ivanayov]

There was a discussion on zoom how to map login.name and userid, so that the mapping is build only once (per big period of time or only when new user is registered) and is also available for all functions. This is one option I've found: configure-all-key-value-pairs-in-a-configmap-as-container-environment-variables configmap user-guide/configmap

I don't find any low-level information how it's implemented, so these are my assumpitons:

• should be similar to how shell reads env-vars; not sure if they can be red with os.Getenv() which AFAIK is cheap
• env-vars should live for the entire time a pod is running and be recreated after restart

If we create a separate map function, being the configMap pod, it can serve all other functions, returning the value of username variable.

We still have the problem with some allowed symbols in usernames, that can't be used as env-var keys, but they are minimised (much less restrictions as for a pod name). What we can do is:

• use unique mapping function to resolve that
• restrict some very corner-case symbols in usernames, like !?*#@, etc
• look for another map option instead.

[alexellis]

The use of the userid in the function name / user deployment means we will also avoid any clashes that arise from similar prefixes.

I.e. alexellis has a function uk-homepage Then alexellis-uk (another username) publishes a function named homepage

In this instance the second user would overwrite the first user's deployment. For this reason we need to use the unique userid as the prefix for all user-artefacts in the cluster.

To go further, in K8s some objects cannot be prefixed with a number, so we'd have to go for "f-userid-name" for instance giving:

f-123-uk-homepage and f-124-uk-homepage meaning we have no clashes.

Originally suggested by @johnmccabe last October.