Make playbook into two pieces

[whikloj]

GitHub Issue: https://github.com/Islandora/documentation/issues/2166

What does this Pull Request do?

This is a bit of a naive first attempt, probably needs a way to continue the original full build steps. Or if you wanted to use this to build a remote machine you'd need to run both sides.

For discussion.

What's new?

Adds a new environment variable to check for called ISLANDORA_BUILD_BASE if it is "true" then the playbook will build a ubuntu/focal64 box with Java, Tomcat 9, Apache, MySQL/Postgres, ActiveMQ, Solr and Cantaloupe installed.

There is some configuration I didn't move, for instance Apache is configured to use the eventual Drupal folder as its DocumentRoot. But as there is nothing there you get a error page.

• Does this change require documentation to be updated? Yes it will, if adopted
• Does this change add any new dependencies? no
• Does this change require any other modifications to be made to the repository (i.e. Regeneration activity, etc.)? no
• Could this change impact execution of existing code? 🤷

How should this be tested?

1. Pull down this PR in a directory.
2. Build the base box.

    > ISLANDORA_BUILD_BASE=true vagrant up

   This should import the ubuntu/focal64 box, that will be one of the first steps it executes. Once it is complete (without errors 🤞 )

3. Package the box.

    > vagrant package --output islandora_base

   This shuts down the VM and exports it to the file islandora_base in this directory.

4. Get rid of the old box

    > vagrant destroy
         default: Are you sure you want to destroy the 'default' VM? [y/N] y
    ==> default: Forcing shutdown of VM...
    ==> default: Destroying VM and associated drives...

5. Now build a VM using the base box.

    > vagrant up

   This should show it is importing the islandora_base box.

That's it, you can now destroy and rebuild the VM using this base image as many times as you need.

Interested parties

Tag (@ mention) interested parties or, if unsure, @Islandora-Devops/committers especially @rosiel

[rosiel]

🥳 @whikloj I was scared when I saw how quickly the base box built. But this is awesome!

Base box built in 6m:28s It took a bit to export, but I didn't time it. The rest of it built in 5m:40s. I saw no errors and the front page loads

Wizardry!! 😀 What do we need to make this 🚀 ?

[whikloj]

I guess the things I'm not sure of and need clarification on is:

1. do we still want a full build option in one run? i.e. for using the playbook to setup a remote machine or is running two steps ok.
2. can you login to the box (I was not sure if I got the private key would work for everyone or just me)

As this is not the flagship distribution method for Islandora, I'm not sure how careful we need to be.

We could make this separate branch so the original dev remains pure but that tends to lead to one or the other branch being more valued.

[whikloj]

Also, we could push a copy of islandora_base up to Hashicorp (sp?) if we wanted, but I wasn't sure if we wanted to try to maintain that as well.

[rosiel]

do we still want a full build option in one run?

Two steps is fine. I imagine running them could be done "at once" by chaining the commands, like this?

ISLANDORA_BUILD_BASE=true vagrant up; ISLANDORA_BUILD_BASE=false vagrant provision;

can you login to the box?

vagrant ssh worked just fine. is there anything else I need to test?

As this is not the flagship distribution method for Islandora, I'm not sure how careful we need to be.

Agreed.

We could make this separate branch so the original dev remains pure but that tends to lead to one or the other branch being more valued.

We have already created a 1.0.0 release, so I think that binds us to some degree of semantic version-y responsibility. Therefore I think this should be 2.0.0 or something. I know it's not even managed by Composer, but cutting a release where the non-back-compatible changes happen would let anyone who's running this and encounters problems know where they can go up to without altering how they interface with the playbook.

But branches? the playbook is so minimally maintained, and I can't imagine us maintaining two branches, let's do this all on the dev branch.

we could push a copy of islandora_base up to Hashicorp (sp?) if we wanted

I think we can wait, maybe come back to it in a few months. The base box is really fast to build, and i don't think we have the people/tools to maintain another external snapshot thing right now.

[whikloj]

I am fine with your answers. I hadn't thought about just provisioning over top. I am fine with just adding a new tagged version, we might want to add a last 1.x.x tag to include the last bits (not sure anyone is using the tags) and then add a 2.0.0 tag to the commit that adds this change.

[rosiel]

Can you add islandora_base to .gitignore? (if not no worries i can make another PR)

[rosiel]

😢 I just ran into a problem that i think was caused by this split (but I'm not sure). After building the site on top of the base box, going to http://localhost:8000/admin/config/search/search-api/server/default_solr_server showed me a big red drupal warning banner error: "You are using an incompatible solr schema. Please follow the instructions in the README.md file for setting up Solr."

I don't know what to look for/at. The indexing worked fine: I went to http://localhost:8983/solr/#/, and did a query, and the results showed i had indexed two nodes and all their values.

But my View (I was using the default that came with the starter site, solr_search_content) returns 0 values, always.

[whikloj]

Argh, okay. Let me look there is some futzing we do with the Solr stuff but I thought it was working.

[rosiel]

That did it. Awesome stuff!