Merge staging into production, 2024 Feb 22 edition

[jacobdgm]

A list of places where code has been touched:

• ajax_melody_list function-based view (Search-by-melody page)
  • type annotations added to this view; functionality should not have changed
  • Among search results, we now display chants' sources' sigla, rather than the chants' own sigla
• Chant Detail View
  • text and volpiano parsing and alignment now handled by volpiano-display-utilities
• Chant EditSyllabificationView
  • text and volpiano parsing and alignment now handled by volpiano-display-utilities
• SequenceDetailView
  • we now display the link to edit the sequence if user has permission to edit chants/sequences in the containing source
• SequenceEditView
  • non-project-manager users can now access this page if they have been given permission to edit the sequences in a particular source.
• SourceEditChantsView
  • text and volpiano parsing and alignment now handled by volpiano-display-utilities
• SourceInventoryView
  • This view has been optimized to make fewer database requests; functionality should not have changed, but the page should load faster now.
• Network configuration
  • all valid subdomains are now specified as server_names in cantusdb.conf
  • traffic to www.cantusdatabase.org is now redirected to cantusdatabase.org
  • http traffic to alternate subdomains is now redirected directly to https://cantusdatabase.org
    • rather than http://{alternate}.cantusdatabase.org -> https://{alternate}.cantusdatabase.org -> http://cantusdatabase.org
• Under the hood
  • requirements.txt
    • volpiano-display-utilities dependency added
  • ChantInventoryView was a duplicate of what's now the SourceInventoryView; the out-of-date ChantInventoryView has been deleted

[jacobdgm]

While testing these changes, I've hit several 502 Bad Gateways on pages that shouldn't be expensive to load (e.g. https://staging.cantusdatabase.org/source/123641) - @dchiller, are you able to take a look at the logs to see whether there's something systematic going on here, and that it's not just The Alliance having a bad day or something?

[jacobdgm]

django.core.exceptions.DisallowedHost: Invalid HTTP_HOST header: '206.12.88.113'. You may need to add '206.12.88.113' to ALLOWED_HOSTS. hmm...

[jacobdgm]

I updated the dev_env file on the internal wiki to add the IP addresses to CANTUSDB_HOSTS_STAGING and _PRODUCTION. The updates I made are currently running on staging, and seem to have resolved the issue - @dchiller and @lucasmarchd01, could one of you please review the updates I made (they're in the two most recent versions within "View history") before we go to production?

[dchiller]

@dchiller, are you able to take a look at the logs to see whether there's something systematic going on here, and that it's not just The Alliance having a bad day or something?

The issue is with nginx.conf: unexpected end of file, expecting ";" or "}" in /etc/nginx/conf.d/cantusdb.conf

I'm going to get rid of the grafana logging now, because it doesn't make sense for only me to have access.

[jacobdgm]

@dchiller, are you able to take a look at the logs to see whether there's something systematic going on here, and that it's not just The Alliance having a bad day or something?

The issue is with nginx.conf: unexpected end of file, expecting ";" or "}" in /etc/nginx/conf.d/cantusdb.conf

I'm going to get rid of the grafana logging now, because it doesn't make sense for only me to have access.

I'm guessing this particular error message was a result of my attempts to debug (see my couple of messages in Slack). Things seem to be working now.

[dchiller]

I'm guessing this particular error message was a result of my attempts to debug (see my couple of messages in Slack). Things seem to be working now.

Ah, ok. Well, once containers are restarted (if not already) docker logs should be back to normal and not sent to grafana.

[dchiller]

I updated the dev_env file on the internal wiki to add the IP addresses to CANTUSDB_HOSTS_STAGING and _PRODUCTION

I think this probably shouldn't be necessary.

[dchiller]

The updates I made are currently running on staging, and seem to have resolved the issue - @dchiller and @lucasmarchd01, could one of you please review the updates I made (they're in the two most recent versions within "View history") before we go to production?

You responded to me on slack about this but responding here so we can all see... what is the issue that this solves? I understand that something is requesting something with that host, but why is it an issue...whatever is requesting it probably shouldn't be requesting it.

On the other hand, this made me realize that since we don't have a default server block in our nginx config, requests to the IP are getting through to django even though we've specified server_name's in all blocks in nginx.conf.

[jacobdgm]

You responded to me on slack about this but responding here so we can all see... what is the issue that this solves? I understand that something is requesting something with that host, but why is it an issue...whatever is requesting it probably shouldn't be requesting it.

I think I was conflating two different requests that both timed out. Thanks for probing for information/clarification on this - I'm coming to the conclusion too that these IP addresses should not be included. I'll take them out of the dev_env file on the internal wiki.

On the other hand, this made me realize that since we don't have a default server block in our nginx config, requests to the IP are getting through to django even though we've specified server_name's in all blocks in nginx.conf.

I've opened #1331 - please feel free to expand on this there.

Thank you!

[jacobdgm]

These changes are now running on Production! All tests are passing, and everything seems to be behaving as expected!