search

alan-turing-institute / data-safe-haven

https://data-safe-haven.readthedocs.io
BSD 3-Clause "New" or "Revised" License
61 stars 15 forks source link

Add ansible vars file #2115

Closed JimMadge closed 1 month ago

JimMadge commented 3 months ago

:white_check_mark: Checklist

:vertical_traffic_light: Depends on

2092

:arrow_heading_up: Summary

Adds an ansible vars file, which is constructed in the infrastructure code and uploaded to the desired state share by Pulumi. Includes changes from https://github.com/alan-turing-institute/data-safe-haven/pull/2103 for release v5.0.0

:closed_umbrella: Related issues

Closes #2075

:microscope: Tests

Tested on a fresh deployment. All vars and templates as expected and system is working.

github-actions[bot] commented 3 months ago

Coverage report

Click to see where and how coverage changed

FileStatementsMissingCoverageCoverage
(new stmts)		Lines missing
  data_safe_haven/infrastructure/common
  ip_ranges.py
  data_safe_haven/infrastructure/components/composite
  __init__.py
  nfsv3_blob_container.py 22-29, 39-75
  data_safe_haven/infrastructure/components/wrapped
  __init__.py
  nfsv3_storage_account.py 34-35
  data_safe_haven/infrastructure/programs
  declarative_sre.py 342, 367
  data_safe_haven/infrastructure/programs/sre
  data.py 463, 477, 492
  desired_state.py 63-84, 98-220, 224
  networking.py 486, 1561, 1969-1974
  workspaces.py 50
Project Total  

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

jemrobinson commented 3 months ago

It might be easier to wait until release 5.0.0 is tagged (next week?) and merged back into develop before looking further into this. What do you think @JimMadge ? We could migrate other variables into this file too and close #2075 in the process.

JimMadge commented 3 months ago

I don't think this would have to wait for the release, as those changes will be merged back into develop anyway.

In the first instance, I'd want to check that this works before moving all variables from cloud init across. If it does, we could move all of them in this PR though :+1:.

jemrobinson commented 3 months ago

I think I'd like to see:

I agree there's no explicit problem in merging into develop before we tag v5.0.0 but note that this branch contains some changes that are already in release-v5.0.0 and aren't in develop so it would be cleaner if we could:

JimMadge commented 3 months ago

I think I'd like to see:

* test that this works on a fresh deployment

* if it does, see how many other variables can be moved across

:+1:

I agree there's no explicit problem in merging into develop before we tag v5.0.0 but note that this branch contains some changes that are already in release-v5.0.0 and aren't in develop so it would be cleaner if we could:

* merge `release-v5.0.0` into `latest`
* tag release 5.0.0
* merge `latest` into `develop`
* THEN merge this PR into `develop`

I can't see that. They are the same changes end up in develop either way and it won't cause any conflicts.

jemrobinson commented 3 months ago

Sorry, I meant cleaner in terms of the logic not whether there will be git conflicts (I agree - there won't be). If we merge release-v5.0.0 first then the logic is:

rather than

JimMadge commented 3 months ago
Screenshot 2024-08-13 at 09 53 39

The vars file is being templated.

JimMadge commented 3 months ago

Templating works

root@shm-daimyo-sre-hojo-vm-workspace-01:~# ls /etc/skel/Desktop/
gitea.desktop  hedgedoc.desktop  input.desktop  output.desktop  shared.desktop
root@shm-daimyo-sre-hojo-vm-workspace-01:~# cat /etc/skel/Desktop/{gitea,hedgedoc}.desktop
[Desktop Entry]
Version=1.0
Type=Link
Name=Gitea
Comment=
Icon=/usr/local/share/icons/gitea.png
URL=http://gitea.hojo.daimyo.develop.turingsafehaven.ac.uk
[Desktop Entry]
Version=1.0
Type=Link
Name=HedgeDoc
Comment=
Icon=/usr/local/share/icons/hedgedoc.png
URL=http://hedgedoc.hojo.daimyo.develop.turingsafehaven.ac.uk
jemrobinson commented 2 months ago

@JimMadge: worth picking up after RSECon?