Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ees 5814 add premium storage accounts #5558

Merged
merged 4 commits into from
Jan 27, 2025

Conversation

duncan-at-hiveit
Copy link
Collaborator

@duncan-at-hiveit duncan-at-hiveit commented Jan 27, 2025

This PR:

  • swaps the "Standard" storage account used for the Public API for a "Premium", File share-centric storage account.

Config changes

Our Public API storage account is now set up as a Premium, FileStorage storage account, meaning that it is tailored towards providing file shares with extremely low latency.

Currently all environments are the same, each provisioning a file share of 100GBs (the minimum amount allowed in a Premium storage account.

All other existing storage accounts (e.g. the 3 used by the Data Processor) remain StandardV2.

In order to roll out these changes, existing Public API storage accounts firstly needed to be backed up, and then deleted completely, as these settings cannot be applied retrospectively.

Other changes in this PR

File share naming convention

As we had to rebuild any existing Public API storage accounts in Resource Groups prior to deploying this, it seemed like a good opportunity to update our file share naming convention, from fs to share which is the recommended one.

Data Processor deploy process

I removed the Data Processor from Dev during the roll-out of this PR. As part of that, I noticed that the deploy of the Data Processor would fail if there wasn't already a deployment in the staging slot (i.e. it would fail the first time you tried to deploy the infrastructure, or after removing the function app for whatever reason).

To fix this, I've now set it to allow 404s from an endpoint check while waiting for the function app to come back to life after appsetting updates, which only occurs the first time the deployment takes place.

YAML template for checking existence of a function app

I broke this piece of logic out into a template as I though we'd need it multiple times. Turns out we didn't but it's neater being extracted out so I have left this change in!

@@ -24,7 +24,7 @@ jobs:
- template: ../tasks/bicep-output-variables.yml
parameters:
serviceConnection: ${{ parameters.serviceConnection }}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My IDE does this too. There must be a way to prevent it creating whitespace only lines - or at least remove them on save.

Copy link
Collaborator

@leeoades leeoades left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my limited ability, it looks reasonable enough to me. I trust that it has been applied already to the other environments so I'm sure it's fine.

Base automatically changed from EES-5814-increase-psql-resources to dev January 27, 2025 17:04
@duncan-at-hiveit duncan-at-hiveit merged commit ecb42bd into dev Jan 27, 2025
5 of 8 checks passed
@duncan-at-hiveit duncan-at-hiveit deleted the EES-5814-add-premium-storage-accounts branch January 27, 2025 17:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants