Use a single resource group for all SRE resources

[jemrobinson]

✅ Checklist

• You have given your pull request a meaningful title (e.g. Enable foobar integration rather than 515 foobar).
• You are targeting the appropriate branch. If you're not certain which one this is, it should be develop.
• Your branch is up-to-date with the target branch (it probably was when you started, but it may have changed since then).

🚦 Depends on

n/a

⤴️ Summary

Use a single Azure resource group for all SRE resources

🌂 Related issues

n/a

🔬 Tests

Tested on a new SRE deployment

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
data_safe_haven/infrastructure/components/composite
local_dns_record.py					18
data_safe_haven/infrastructure/programs
declarative_sre.py					133
data_safe_haven/infrastructure/programs/sre
apt_proxy_server.py					37
backup.py					20
data.py					77-78
database_servers.py					35
dns_server.py					39
gitea_server.py					58
hedgedoc_server.py					52, 61
identity.py					45
monitoring.py					34
networking.py					47, 52, 1842
remote_desktop.py					76
software_repositories.py					48
user_services.py					62
workspaces.py					64
Project Total

This report was generated by python-coverage-comment-action

[JimMadge]

Is there an advantage to this?

I'm not sure if it is better for findability to have one RG per SRE or many RGs for different types of resource. @craddm what do you think?

[craddm]

Is there an advantage to this?

I'm not sure if it is better for findability to have one RG per SRE or many RGs for different types of resource. @craddm what do you think?

I was just wondering exactly the same thing - I feel like things will get buried.

[jemrobinson]

It's a good question. I mildly prefer one resource group for the whole SRE just because some of our existing resource groups either only have a single resource in them (e.g. apt proxy server and backup) or refer to resources in other groups. There's currently not a clean separation between what lives in each resource group (apart from the fact that they're deployed from a single Component) and it's actually a bit annoying to keep switching RGs when trying to debug something.

However, this isn't something I feel very strongly about, so happy to drop it if you both prefer.

[JimMadge]

Might ask to hang back on merging until #1892 is merged to avoid the conflicts.

[jemrobinson]

Thoughts @JimMadge @craddm ?

• arguments for:
  • fewer resources to deploy (and correspondingly less code)
  • easier to find things in the portal
  • no confusion about which resources live in which RG
• arguments against:
  • lots of resources in a single RG

[craddm]

Thoughts @JimMadge @craddm ?

• arguments for:

  • fewer resources to deploy (and correspondingly less code)
  • easier to find things in the portal
  • no confusion about which resources live in which RG

• arguments against:

  • lots of resources in a single RG

I think the "lots of resources in a single RG" point slightly contradicts the "easier to find things in the portal" point, but I have to admit I sometimes am unsure which resources live in which RG, just like you say.

I'm actually sort of coming round to the single RG viewpoint, having just gone back to the portal and realized you can sort by type etc

[jemrobinson]

Watching how other people use the portal, I think it's quite rare to have the "RGs are folders" mindset. Mostly people search by name or type (or occasionally by tag).

[craddm]

Now we've got a few SREs up at once, i'm just running a test deployment with this, and I think I'm converted. As said above, can easily group by type or other fields, or even (shock horror) just filter