rosiel commented 7 years ago

Here are some use cases (please help revise!) that may help us figure out deployment strategies that can meet our needs.

USE CASE 1 - Evaluator

Title (Goal)	A Happy Evaluator Experience
Primary Actor	Collections Manager, Librarian, Library Director
Scope	Evaluation, Documentation
Story	As someone not sure if or how Islandora does X, I want to be able to see how it works. I want to see something set up "like a repository" with demo content that communicates to me, a librarian/library director/someone unfamiliar with islandora, what Islandora does and can do so that I can make a decision about whether to use Islandora.

USE CASE 2 - Dabbler/Documentor

Title (Goal)	Run, test, and maintain a local Islandora sandbox with a little more management control.
Primary Actor	Interest Group member, community member, developer
Scope	Testing, Documentation, Drupal Maintenance
Story 1	As someone nominally familiar with Islandora, I want to get my hands a little dirtier. Maybe I want to see how Islandora works with a contrib module that sounds useful, so that we can figure out how to do a feature that we need. I don't have access to a devoted sandbox from my institution, so I want something I can install and play with locally.
Story 2	Someone has a pull request on a drupal module they would like me to test, to see if it meets my needs. i therefore need to fetch a drupal module by referring to a branch on a non-islandora repo, and be able to update it as changes are added.
Story 3	I am documenting a feature of Islandora. I want it to be set up "out of the box" so that I can test the same thing that others will see. It should have the "latest released" code (since we release by semver, this should be frequent). I need to know how to update my box so that I can get new point releases, and I need to know if/what things will not be updated when I "do updates" (that is, to drupal via composer). (namely, stuff in features)

Use Case 3 - Dev

Title (Goal)	Run, test, and maintain a full local development Islandora.
Primary Actor	Developer
Scope	DevOps, testing, documentation
Story	I am working on or testing code in Drupal, Fedora, Syn, Alpaca, Crayfish, or Crayfish Commons. OR, I am responsible for making Islandora run "out of the box" on a newer database system, version of PHP, or underlying OS. I need to have all my code running the latest commit (not latest release).

Use Case 4 - Staging (as sysadmin)

Title (Goal)	Deploy Islandora so others can play with it (not production).
Primary Actor	Sysadmin, DevOps
Scope	Deployment
Story	I need to create a 'staging' server so my metadata people can create content types, my themers can create a theme, programmers can test their custom modules, etc. This will be non-local so needs to be secure enough to not get hacked. Drupal security updates will be obligatory. Eventually I will "move" this to production. (how do i do that)
Story 2	I need to manage the config, themes, and modules so that they can be version tracked, recovered and/or cloned to sandbox or production.

Use Case 5 - Staging (as manager)

Title (Goal)	Out of the Box, An Empty Repo
Primary Actor	Metadata admin, Drupal Manager, Librarian, Archivist
Scope	Content Modelling, Site Building
Story	I need to start building my site on the server that was created in Use Case 4. I want to configure my metadata profile(s) and content types, and start adding my content. I do NOT want there to be demo content, and any views/features present out of the box should not break because I change the metadata fields around. I need to know that my changes to content types, configs, etc won't be overridden by some update.

Use Case 6 - Production

Title (Goal)	Super Clean Production Machine
Primary Actor	Sysadmin
Scope	Deployment
Story	I need to run a production site. It must be secure. It should not have extraneous 'dev' features enabled. All security updates must be applied. I should be able to update all components of the server and of Islandora as needed. What are the configs and workflows that can make this happen?

Original Ticket (for reference)

I think this was the idea all along, (and maybe this is redundant because there's an other issue?) but to have a set of "stuff" (modules? features? Maybe a Drupal installation profile?) that can let CLAW function out of the box, possibly including:

commonly used content types (images, audio, video, book, pdf...)
common RDF-mapped metadata fields ("forms" including the basic metadata fields that have been present in existing forms)
a set of derivatives that let us build a web-friendly display and navigation (thumbnails and display proxies)
viewers for those display proxies
a nice theme for presenting objects and their metadata, and navigation (collection?)
a default setup of solr so that search is snazzy

Whereas the "functionality" to have these is going to be built into CLAW core, there was always an intention to keep core lean. Would these types of 'defaults' be better in a set of 'starter modules' or features, rather than having the defaults (which are totally editable if you don't want to use them) baked into core?

Please discuss!

Natkeeran commented 7 years ago

I was exploring setting up Apache Solr search and facets. I've complied some notes here: https://github.com/Natkeeran/Notes/blob/master/Configuring%20Apache%20Solr%20Search%20and%20Facets%20in%20CLAW.md

DiegoPino commented 7 years ago

@Natkeeran++ just looking that at that, thanks. Any problems/missing things?

Natkeeran commented 7 years ago

@DiegoPino

The current default Apache core (CLAW) does not seem to have the needed configurations. I've copied the configurations provided in the Solr Search module. (I created new core because I was not sure how the default core was configured.)

Both of the modules are not covered by drupal security advisory policy. Not sure how big of an issue that would be! We are in the early stages of prototyping, thus have not explored the indexing and facets in detail. Overall, seems to be a workable solution.

kstapelfeldt commented 2 years ago

The original issues in the ticket are somewhat completed, and there remain new issues related to default builds for Islandora. Every method has different ways of achieving similar things. Coming up with a standard default remains an issue. We need to rewrite this as a use case.

rosiel commented 2 years ago

I did a brain dump, and above are the use cases I've encountered.

Anyone want to discuss these? Use cases are crap unless they come from collaboration.