Islandora modules un/reinstall and upgrade process

[Natkeeran]

Currently, there are three drupal modules for CLAW: islandora, islandora_demo, and Islandora modules and controlled_access_terms that impact fields or have inter dependencies. That means, if we need to uninstall and reinstall these modules as part of an upgrade progress, things get complicated.

For instance, a recent change to controlled_access_terms required that module to be uninstalled and re installed. This mean, islandora_demo need to be uninstalled and reinstalled as well. Uninstalling and reinstalling means that any information in fields managed by these modules get deleted. Though this is not a major issue while in development, will become a major issue if we have to upgrade modules in production.

We need to get a clear understanding about when islandora modules need to be updated via uninstall/reinstall method and how to go about doing it. That process need to be documented well. We may need additional tooling to support this. We may have to consider tooling make the necessary database changes without uninstall/reinstall.

Many users do extend the metadata fields they use. Adding metadata fields should not require migration. However, modifing existing fields will require field or data migration. These processes need to be documented as well.

Also need direction with respect to how to use composer and ansible to manage these upgrades in production environments.

[whikloj]

Updating a module where the actual configuration is changed as in the controlled_access_terms where the entire "type" was altered is going to be destructive. One of the reasons I would avoid adding too much to any non-Drupal standard field at this time is this variability.

But I would also note that islandora does not have a dependency on controlled_access_terms, so you didn't need to re-install it and probably a process of export/import of your content to get the controlled access fields changed would be possible.

Alternatively if you are not using the controlled_access_terms fields, then removing them from the content type is probably appropriate.

[MarcusBarnes]

@whikloj This is also @Natkeeran's point - detailed documentation of when re-installation is required or not, etc. and in fine detail, so that new to the platform will know how to proceed with confidence, especially during upgrades.

[Natkeeran]

@whikloj

Yes, you are right. uninstalling controlled_access_terms only required islandora_demo to be uninstalled, not islandora. Nor an issue at all while testing.

[seth-shaw-unlv]

I think, once we have an initial release, the uninstall/install, migration pattern shouldn't be used at all. Proper upgrade hooks should be used instead. So, really, the PR that prompted this should have had an upgrade hook and would result in a new version being sliced.

Generally speaking, I think most upgrades will simply require applying the PR and doing a feature import. This one is more involved because of a field-type change.

[Natkeeran]

@dannylamb

@seth-shaw-unlv and I had some discussion on this topic. To have the option to cleanly update islandora and islandora_demo, we can possibly do the following. The basic idea is to recommend not to customize islandora and islandora_demo at all.

• Use https://www.drupal.org/project/entity_type_clone to create custom metadata profile or content type
• You will need to have an additional context similar to http://localhost:8000/admin/structure/context/repository_content
• This will require changes to OpenSeaDragon and PDF EVA views to make them applicable to any content type. Currently, they are targeting Repository Item only. Or the user may have to manually edit those EVA views to include the custom content type.
• The custom content type and context can be packaged into a module or configuration package and deployed to an Islandora 8 instance.

[dannylamb]

Good stuff @Natkeeran and @seth-shaw-unlv. I think the google doc you linked me could pretty easily go straight into the docs. By the end of it, we'll have a good "how to set up your repository" body of knowledge in the docs after folks start actively using this process. I take it this comes from experience at UTSC and UNLV?

[Natkeeran]

@dannylamb

One of the pain points of CLAW has been updates. Anything we do now to ease that process will help manyfolds down the line. I believe @seth-shaw-unlv has a similar setup. We are on an earlier prototype with various custom content types.

[whikloj]

@Natkeeran @seth-shaw-unlv Did this knowledge make it into the documentation during the last sprint?

[seth-shaw-unlv]

@whikloj, I don't think so. No one signed up for the relevant slots on the sprint spreadsheet.