...
But one thing we still need Ansible for is provisioning the ArchivesSpace server.
Software on the ArchivesSpace server
A ) The actual ArchivesSpace software.
B ) The code and files that export EADs and HTML finding aids.
Lives in a GitHub repository.
Badly needs repairs.
C ) An Apache server that serves the EADs and the HTML finding aids output by B )
The Othmer catalog links to the HTML files.
External links to the files, however, are rare. We do not need to provide redirects if we change them.
The EADs are consumed by CHSTM and UPenn. We will need to let them know about any changes.
Options
To eliminate the ArchivesSpace server (and with it much of our dependency on Ansible), we should consider one or more of the following steps:
A ) Move the ArchivesSpace software to a hosted provider. (we did this – ASpace is now living on LibraryHost.)
As part of this, we may also wish to (or have to) update the version of ArchivesSpace.
We may also decide, as part of this work, to turn on the public user interface.
If we turn on the PUI, the HTML finding aids become obsolete.
B ) Run the export scripts from a hosted environment. It may be possible to run them from a serverless environment, such as AWS lambda. This is done: see export_archivesspace_xml
C ) Replace Apache with an S3 bucket. This is done: see export_archivesspace_xml
Notes
It may also be possible to get a hosted ArchivesSpace to serve the EADs directly. If so, it may be possible to If an ArchivesSpace hosting provider, as part of their service, can take care of exporting and serving the EADs, we can avoid doing B ) and C ) altogether. We should keep this in mind as we shop.
Because the ArchivesSpace server is the only one left that we use Ansible for, each of these steps has the side-effect of cutting out big chunks of our Ansible code. For instance, C) should allow us to get rid of all our Apache-related code in Ansible.
A ), B ) and C ) above could be treated as independent projects and be done in any order.
...