Arvados

depoyments needs lot's of admin actions like, that happen in random order. Here are examples.

standard objects:¶

~$ prefix=`arv --format=uuid user current | cut -d- -f1`
~$ echo "Site prefix is '$prefix'" 
~$ all_users_group_uuid="$prefix-j7d0g-fffffffffffffff" 
~$ repo_uuid=`arv --format=uuid repository create --repository "{\"owner_uuid\":\"$prefix-tpzed-000000000000000\", \"name\":\"arvados\"}"`
~$ echo "Arvados repository uuid is '$repo_uuid'" 

~$ read -rd $'\000' newlink <<EOF; arv link create --link "$newlink" 
{
 "tail_uuid":"$all_users_group_uuid",
 "head_uuid":"$repo_uuid",
 "link_class":"permission",
 "name":"can_read" 
}
EOF
~$ project_uuid=`arv --format=uuid group create --group "{\"owner_uuid\":\"$prefix-tpzed-000000000000000\", \"name\":\"Arvados Standard Docker Images\"}"`
~$ echo "Arvados project uuid is '$project_uuid'" 
~$ read -rd $'\000' newlink <<EOF; arv link create --link "$newlink" 
{
 "tail_uuid":"$all_users_group_uuid",
 "head_uuid":"$project_uuid",
 "link_class":"permission",
 "name":"can_read" 
}
EOF

object creations:

~$ prefix=`arv --format=uuid user current | cut -d- -f1`
~$ echo "Site prefix is '$prefix'" 
~$ read -rd $'\000' keepservice <<EOF; arv keep_service create --keep-service "$keepservice" 
{
 "service_host":"keep0.$prefix.your.domain",
 "service_port":25107,
 "service_ssl_flag":false,
 "service_type":"disk" 
}
EOF

arv --format=uuid virtual_machine create --virtual-machine '{"hostname":"shell.bd44f.arvadosapi.com"}'

tokens for services¶

apiserver:~$ arv api_client_authorization create --api-client-authorization '{"scopes":["GET /arvados/v1/virtual_machines/zzzzz-2x53u-zzzzzzzzzzzzzzz/logins"]}'

  arv api_client_authorization create_system_auth \
    --scopes "[\"GET /arvados/v1/jobs/queue\",
               \"GET /arvados/v1/nodes\",
               \"PUT /arvados/v1/nodes\",
               \"PUT /arvados/v1/nodes/\",
               \"POST /arvados/v1/nodes\",
               \"POST /arvados/v1/nodes/\"]" 

We've been doing all this as users, and there is a trackable actions who did what and when. If we implement privileges "sudo style" we should not loose the trackability.

Also take in account the user experience from the admin perspective. If we're going down the path of self discovery services, each services should bee able to add itself to the api without admin intervention. or at least to have a period of time (i.e. a Deployment flag somewhere) that lowers the need of a token just to make things easier to make deployments. The flag could be turned off once the deployment is done, of course.

We should be careful to not make Ops any more difficult than it already is, but deployments are a very small fraction of our usage. Perhaps we can have a special deployment account or Ops team members can have accounts which have admin privileges permanently enabled if we can't find a good sudo-style implementation that works for deployments.

I agree with the general trend of having developers, at least, run with admin privileges turned off most of the time. Otherwise too many errors and performance issues get masked.