Python3

Status

This code is as ready as I can get it. Here's what still needs to be done:

• Figure out issue with lvalert-overseer.
• Check for possible issues on uploading hardware injections (see here. I haven't been able to test it, but it uses StringIO which is definitely a cause for concern in terms of Python 2/3 compatibility.
• Tag a new version of lvalert-overseer, push it to PyPI, and update the requirements.txt file in this repository to use the new tag.

Suggested strategy for rolling it out

• Test the deployment with the new puppet configuration on gracedb-dev2 or dev1 (more below)
• Deploy on playground and see what happens
• Test this image on gracedb-test
• Tag it
• Deploy on production

To test on UWM VMs

• Delete /home/gracedb/djangoenv
• As root, run puppet and immediately turn it off so it doesn't revert to the default configuration:

  puppet agent -t --environment=gracedb_python3; systemctl stop puppet

• Make sure the repository in /home/gracedb/bin is up-to-date.
• Do some testing
• If everything looks good, proceed

Final deployment on UWM VMs

• Stop/disable puppet on gracedb-playground

  systemctl stop puppet
  systemctl disable puppet

• Someone at UWM should rebase and merge this MR.
• Setup the dev machines to use this branch and the new configuration.
  • As the gracedb user:

    cd /home/gracedb/gracedb_project
    rm -rf ../djangoenv
    git checkout --track origin/python3

  • As root:

    puppet agent -t
    systemctl restart gunicorn
    systemctl restart lvalert_overseer

• If all seems good, do the same for playground
• Iterate on any changes needed to the server code
• Once it seems stable on playground, test it on gracedb-test
• If that seems good, merge the code into master and tag it

NOTE: gracedb-dev2 is currently set up for Python 3 both in terms of its Puppet configuration and its code base. Puppet is currently turned off so that it doesn't revert to the "default" Puppet configuration with Python 2. Once you're ready to "officially" deploy with Python 3, and the Puppet configuration is merged, just do puppet agent -t as root on this server to restart Puppet.

Final deployment in AWS

Should be easy - it's all in a Docker image!

Potential issues

The parts of the code that I expect the most issues to occur are:

• VOEvent building (gracedb/annotations/voevent_utils.py) since it was completely rewritten
• VOEvent ingestion for external events (gracedb/events/translator.py) since it was completely rewritten
• General string parsing and encoding/decoding

docker/entrypoint

 #!/bin/bash
 
-export LVALERT_OVERSEER_RESOURCE=${LVALERT_USER}_overseer_$(python  -c 'import uuid; print(uuid.uuid4().hex)')
+export LVALERT_OVERSEER_RESOURCE=${LVALERT_USER}_overseer_$(python3  -c 'import uuid; print(uuid.uuid4().hex)')
+
+# Change the file permissions and ownership on /app/db_data:
+chown gracedb:www-data /app/db_data
+chmod 755 /app/db_data
+
+## PGA: 2019-10-15: use certs from secrets for Shibboleth SP
+SHIB_SP_CERT=/run/secrets/saml_certificate
+SHIB_SP_KEY=/run/secrets/saml_private_key
+if [[ -f $SHIB_SP_CERT && -f $SHIB_SP_KEY ]]
+then
+        echo "Using Shibboleth Cert from docker secrets over the image one"
+        cp -f $SHIB_SP_CERT /etc/shibboleth/sp-cert.pem
+        cp -f $SHIB_SP_KEY /etc/shibboleth/sp-key.pem
+        chown _shibd:_shibd /etc/shibboleth/sp-{cert,key}.pem
+        chmod 0600 /etc/shibboleth/sp-key.pem
+fi
+
+## PGA 2019-10-16: use secrets for sensitive environment variables
+LIST="aws_ses_access_key_id
+  aws_ses_secret_access_key
+  django_db_password
+  django_secret_key
+  django_twilio_account_sid
+  django_twilio_auth_token
+  lvalert_password"
+
+for SECRET in $LIST
+do
+        VARNAME=$( tr [:lower:] [:upper:] <<<$SECRET)
+        [  -f /run/secrets/$SECRET ] && export $VARNAME="$(< /run/secrets/$SECRET)"
+done
+
 exec "$@"
+