Pulumi: Context issues

[jemrobinson]

✅ Checklist

• I have searched open and closed issues for duplicates.
• This is a problem observed when deploying a Data Safe Haven.
• I can reproduce this with the latest version.
• I have read through the documentation.
• This isn't an open-ended question (open a discussion if it is).

💻 System information

• Operating System: macOS 13.6.3
• Data Safe Haven version: python-migration

🚫 Describe the problem

Questions/thoughts about the dsh context command when using it for the first time

• Non-existent context settings file should be gracefully handled #1897

dsh context available
2024-01-23 14:23:46 [    INFO] Reading project settings from '/Users/jrobinson/Library/Application Support/data_safe_haven/contexts.yaml'.                                                                                                             context_settings.py:208
2024-01-23 14:23:46 [   ERROR] Could not find file /Users/jrobinson/Library/Application Support/data_safe_haven/contexts.yaml.                                                                                                                                       cli.py:98
2024-01-23 14:23:46 [   ERROR] [Errno 2] No such file or directory: '/Users/jrobinson/Library/Application Support/data_safe_haven/contexts.yaml'

• Explain difference between Context key and name #1898

╭─ Arguments ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ *    key      TEXT  Key of the context to add. [default: None] [required]                                                                                                                                                                                                  │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
╭─ Options ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ *  --admin-group           TEXT  The ID of an Azure group containing all administrators. [default: None] [required]                                                                                                                                                        │
│ *  --location              TEXT  The Azure location to deploy resources into. [default: None] [required]                                                                                                                                                                   │
│ *  --name                  TEXT  The human friendly name to give this Data Safe Haven deployment. [default: None] [required]                                                                                                                                               │
│ *  --subscription          TEXT  The name of an Azure subscription to deploy resources into. [default: None] [required]                                                                                                                                                    │
│    --help          -h            Show this message and exit.                                                                                                                                                                                                               │
╰──────────────────────────────────────────────────────────────────────────────

Edit: in light of @JimMadge's comment, maybe we should update the helptext for key to something like Short descriptor used to refer to this context.

• Do we need dsh context add and dsh context create? Is there benefit in having a context in the settings file that hasn't yet been deployed onto Azure?

• Failed context creation should be gracefully handled #1899

dsh context create
2024-01-23 14:30:50 [    INFO] Reading project settings from '/Users/jrobinson/Library/Application Support/data_safe_haven/contexts.yaml'.                                                                                                             context_settings.py:208
2024-01-23 14:31:00 [   ERROR] Failed to create context resources.                                                                                                                                                                                                   cli.py:98
2024-01-23 14:31:00 [   ERROR] Failed to create resource group shm-green-rg-context.                                                                                                                                                                                 cli.py:98
2024-01-23 14:31:00 [   ERROR] Failed to authenticate with Azure.                                                                                                                                                                                                    cli.py:98
2024-01-23 14:31:00 [   ERROR] Failed to invoke the Azure CLI

• Pulumi: storage container not created #1710

🌳 Log messages

Relevant log messages

Your log details here

♻️ To reproduce

[JimMadge]

Discussion of name and key here.
The basic distinction is key is a unique, hashable identifier that you and the code uses to refer to a context. name is a human friendly name that is used to create the names for objects.
I would be against changing this (unless someone has a really good idea). Both for our quality of lives as programmers and for the user (dsh context switch acme vs dsh context switch 'ACME Deployment')

[JimMadge]

Do we need dsh context add and dsh context create? Is there benefit in having a context in the settings file that hasn't yet been deployed onto Azure?

I very much like them to be separate. I see defining a context and creating the infrastructure as clearly distinct. I wouldn't want the infrastructure to be automatically created.

Thinking of analogy with Git, git remote add doesn't git pull or git push or even git fetch.

[JimMadge]

Closing as broken into new issues.