David McDonald 08c4f3f4d6 Do not delete s3 letters if 'created' or 'sending'
A few weeks ago, we deleted some pdf letters that had reached their
retention period. However, these letters were in the 'created' state so
it's very arguable that we should not have deleted them because we were
expecting to resend them and were unable to. Part of the reason for this
is that we marked the letters back to `created` as the status but we did
not nullify the `sent_at` timestamp, meaning the check on
ebb43082d5/app/dao/notifications_dao.py (L346)
did not catch it.

This commit does three things

Firstly, it changes the check from looking at `sent_at` to looking at
`notification_status`. Status is a much more reliable way of determinig
if the letter should be sent or not, in case we forget to nullify the
`sent_at` field in the future.

Secondly, it changes it so letters still in `sending` will not be
deleted from s3. This is important because this protects against the
case were we hand the letter to DVLA, they accept it and it gets marked
as `sending` and then the letter is deleted before they come back to us
and say there are problems and we need to resend it to them.

Thirdly, it improves test coverage for letter deleting for a range of
letter statuses.

Note, this will change will NOT stop letters in `created` or `sending`
from still being removed from the `notifications` table and put in the
`notification_history` table. It would be nice to do this too but not as
part of this commit.

It does mean there could be a case were a letter is still in sending
when it gets moved to `notification_history` and we retain the PDF. Then
the letter is updated to `delivered`. However at this point, although
the letter has reached a final state, nothing will come along and tell
s3 to delete that PDF. However, as a backup, there is a 90 day default
deletion on letters in the `production-letters-pdf` bucket so it may be
kept slightly longer than intended but not forever. This feels like a
tolerable risk, that already existed for letters in `created` state` and
is likely a better situation than deleting the PDF too early.
2020-12-15 17:29:58 +00:00
2019-10-11 13:55:21 +01:00
2020-05-12 16:04:18 +01:00
2019-08-02 12:41:03 +01:00
2019-05-16 17:06:34 +01:00
2020-04-20 18:39:45 +01:00
2020-12-07 18:27:22 +00:00
2020-01-07 10:26:07 +00:00
2020-12-11 10:56:06 +00:00
2020-12-11 10:56:06 +00:00
2019-05-16 17:06:34 +01:00
2019-10-11 13:55:21 +01:00

GOV.UK Notify API

Contains:

  • the public-facing REST API for GOV.UK Notify, which teams can integrate with using our clients
  • an internal-only REST API built using Flask to manage services, users, templates, etc (this is what the admin app talks to)
  • asynchronous workers built using Celery to put things on queues and read them off to be processed, sent to providers, updated, etc

Setting Up

Python version

At the moment we run Python 3.6 in production. You will run into problems if you try to use Python 3.5 or older, or Python 3.7 or newer.

AWS credentials

To run the API you will need appropriate AWS credentials. You should receive these from whoever administrates your AWS account. Make sure you've got both an access key id and a secret access key.

Your aws credentials should be stored in a folder located at ~/.aws. Follow Amazon's instructions for storing them correctly.

Virtualenv

mkvirtualenv -p /usr/local/bin/python3 notifications-api

environment.sh

Creating the environment.sh file. Replace [unique-to-environment] with your something unique to the environment. Your AWS credentials should be set up for notify-tools (the development/CI AWS account).

Create a local environment.sh file containing the following:

echo "
export NOTIFY_ENVIRONMENT='development'

export MMG_API_KEY='MMG_API_KEY'
export FIRETEXT_API_KEY='FIRETEXT_ACTUAL_KEY'
export NOTIFICATION_QUEUE_PREFIX='YOUR_OWN_PREFIX'

export FLASK_APP=application.py
export FLASK_DEBUG=1
export WERKZEUG_DEBUG_PIN=off
"> environment.sh

NOTES:

  • Replace the placeholder key and prefix values as appropriate
  • The SECRET_KEY and DANGEROUS_SALT should match those in the notifications-admin app.
  • The unique prefix for the queue names prevents clashing with others' queues in shared amazon environment and enables filtering by queue name in the SQS interface.

Postgres

Install Postgres.app. You will need admin on your machine to do this.

Choose the version with Additional Releases - you want 9.6. Once you run the app, open the sidebar, remove the default v11 server and create and initialise a v9.6 server.

Redis

To switch redis on you'll need to install it locally. On a OSX we've used brew for this. To use redis caching you need to switch it on by changing the config for development:

    REDIS_ENABLED = True

To run the application

First, run scripts/bootstrap.sh to install dependencies and create the databases.

You need to run the api application and a local celery instance.

There are two run scripts for running all the necessary parts.

scripts/run_app.sh
scripts/run_celery.sh

Optionally you can also run this script to run the scheduled tasks:

scripts/run_celery_beat.sh

To test the application

First, ensure that scripts/bootstrap.sh has been run, as it creates the test database.

Then simply run

make test

That will run flake8 for code analysis and our unit test suite. If you wish to run our functional tests, instructions can be found in the notifications-functional-tests repository.

To update application dependencies

requirements.txt file is generated from the requirements-app.txt in order to pin versions of all nested dependencies. If requirements-app.txt has been changed (or we want to update the unpinned nested dependencies) requirements.txt should be regenerated with

make freeze-requirements

requirements.txt should be committed alongside requirements-app.txt changes.

To run one off tasks

Tasks are run through the flask command - run flask --help for more information. There are two sections we need to care about: flask db contains alembic migration commands, and flask command contains all of our custom commands. For example, to purge all dynamically generated functional test data, do the following:

Locally

flask command purge_functional_test_data -u <functional tests user name prefix>

On the server

cf run-task notify-api "flask command purge_functional_test_data -u <functional tests user name prefix>"

All commands and command options have a --help command if you need more information.

To create a new worker app

You need to:

  1. Create new entries for your app in manifest.yml.j2 and scripts/paas_app_wrapper.sh (example)
  2. Update the jenkins deployment job in the notifications-aws repo (example)
  3. Add the new worker's log group to the list of logs groups we get alerts about and we ship them to kibana (example)
  4. Optionally add it to the autoscaler (example)

Important:

Before pushing the deployment change on jenkins, read below about the first time deployment.

First time deployment of your new worker

Our deployment flow requires that the app is present in order to proceed with the deployment.

This means that the first deployment of your app must happen manually.

To do this:

  1. Ensure your code is backwards compatible
  2. From the root of this repo run CF_APP=<APP_NAME> make <cf-space> cf-push

Once this is done, you can push your deployment changes to jenkins to have your app deployed on every deployment.

Description
The API powering Notify.gov
Readme 96 MiB
Languages
Python 98.5%
HCL 0.6%
Jinja 0.5%
Shell 0.3%
Makefile 0.1%