Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Islandora modules un/reinstall and upgrade process #1011

Open
Natkeeran opened this issue Jan 21, 2019 · 9 comments
Open

Islandora modules un/reinstall and upgrade process #1011

Natkeeran opened this issue Jan 21, 2019 · 9 comments
Labels
Type: documentation provides documentation or asks for documentation.

Comments

@Natkeeran
Copy link
Contributor

Natkeeran commented Jan 21, 2019

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
Copy link
Member

whikloj commented Jan 21, 2019

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
Copy link

@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
Copy link
Contributor Author

@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
Copy link
Contributor

seth-shaw-unlv commented Jan 23, 2019

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
Copy link
Contributor Author

Natkeeran commented Mar 14, 2019

@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
Copy link
Contributor

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
Copy link
Contributor Author

@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
Copy link
Member

whikloj commented Apr 11, 2019

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

@seth-shaw-unlv
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: documentation provides documentation or asks for documentation.
Projects
Development

No branches or pull requests

6 participants