SHM and SRE should not be allowed to share a name

[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
• Data Safe Haven version: develop @ c1d0adc

🚫 Describe the problem

If an SHM and SRE share a name then the keys in pulumi.yaml will be clobbered.

This happens because the YAML file does not distinguish between SHM and SRE projects, e.g.

projects:
  apple:
    encrypted_key: <key>
    stack_config:
      azure-native:location: uksouth
      ...
  green:
    encrypted_key: <key>
    stack_config:
      azure-native:location: uksouth
      ...

🌳 Log messages

Relevant log messages

Your log details here

♻️ To reproduce

• Deploy an SHM
• Attempt to deploy an SRE with the same name

[JimMadge]

Does it let you do that? I thought I had prevented that from happening,

data-safe-haven/data_safe_haven/config/pulumi.py

Lines 41 to 54 in c1d0adc

	def __setitem__(self, key: str, value: DSHPulumiProject) -> None:
	"""
	Add a DSH Pulumi Project.
	This method does not support modifying existing projects.
	"""
	if not isinstance(key, str):
	msg = "'key' must be a string."
	raise TypeError(msg)
	if key in self.project_names:
	msg = f"Stack {key} already exists."
	raise ValueError(msg)
	self.projects[key] = value

Do we want to allow different components to have identical names?

[jemrobinson]

1. You can upload a config which contains an SHM and SRE with the same name.
2. If you run dsh deploy sre <same name as shm> then the deployment starts running.

It's possible that writing pulumi.yaml to Azure after the SRE has been deployed might fail, but I think we should be catching this at (1), not allowing the deployment to go ahead.

Alternatively, we could add an shm- or sre- prefix to the name in the pulumi.yaml file if you prefer?

[JimMadge]

Hmm, In that case I would guess 'create_or_select_project` would fetch the existing Pulumi configuration and stack state. Deploying would presumably then delete the SHM as it isn't defined in the SRE program.

I think adding an enum to DSHPulumiProject which is SHM | SRE would be a good solution. File/project/stack names could be modified based on that.

[JimMadge]

@jemrobinson Does this still need to be done, or are we expecting to remove the SHM entirely for rc2?

[jemrobinson]

Let's leave it until we've worked out whether that's possible.

[JimMadge]

Related to #1900. Will not be necessary if that is closed.