Drupal 8 multi-site capability?

174 views
Skip to first unread message

Bryan Brown

unread,
Feb 13, 2019, 9:57:14 AM2/13/19
to islandora-dev
Hi all,

I remember hearing someone (can't remember who though) saying that Drupal 8's multi-site capability ends up being more trouble than its worth, and that it ends up being better in practice to just run separate Drupal 8 instances for individual sites. I believe the reasoning on this had to do with SSL certs for different domains (which seems to be equally problematic in Drupal 7) and another point having to do with the difficulty of upgrading modules and components in a multi-site instance. I didn't understand this argument when it was made, but I think it had to do with different components that could require different versions of dependencies and it all combining to form a big mess that requires manual intervention. I've tried to find more info about this on the web but have been so far unsuccessful.

Since, IMHO, the multi-site capability of Drupal is a major ingredient in the secret sauce that makes Islandora 7.x so popular with consortia and universities wanting separately branded/themed front doors to their collections, I want to explore this further to determine if this is truly an issue, and if so, how we can work as a community to rally around best practices to mitigate any issues that come from it. Having to stand up separate Islandora 8.x instances, even if they connect to the same Fedora, would be a major sticking point for adopters coming from Islandora 7.x multi-site instances. Alternatively, if this IS NOT actually an issue, I'd like to have a thread to point to that puts the debate to bed.

So, Drupal 8 gurus... what are your opinions on this matter?

- Bryan

Mark Jordan

unread,
Feb 13, 2019, 10:30:17 AM2/13/19
to islandora-dev


Hi Bryan, thanks for bringing this up. I know nothing about multisite in 7 or 8 so can offer no useful input but will point out that https://github.com/Islandora-CLAW/CLAW/issues/396 covers a lot of this ground already. Multi-tenancy is #2 with a bullet on the proposed technical roadmap document as well.


Mark


From: island...@googlegroups.com <island...@googlegroups.com> on behalf of Bryan Brown <bryj...@gmail.com>
Sent: Wednesday, February 13, 2019 6:57 AM
To: islandora-dev
Subject: [islandora-dev] Drupal 8 multi-site capability?
 
--
You received this message because you are subscribed to the Google Groups "islandora-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to islandora-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/islandora-dev/f1012c5a-2056-42e6-8fd6-ebf19d1b0c61%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

dp...@metro.org

unread,
Feb 13, 2019, 11:05:28 AM2/13/19
to islandora-dev
Hi,

You heard that from me probably. The use of multisites in 7.x had some community benefits because it really allowed to have access to all Objects (single backed) and Search Engine but filter/theme via namespaces what you wanted to show or not. Key word there is "filter". In a CLAW architecture or a vanilla D8 one, each multi site will have access only to its own entities because (out of the box, there are some WIP solutions like the domain module which sadly does not play well with a lot of other modules) and could eventually share the same Solr core (that is D8 built in, but disabling for now Multi lingual, documented issue). But, there is more. Because of Symfony and the way Drupal 8 is build around a single composer.json file, basically you have a hierarchical skeleton project (/vendor libraries) that start from the top (before the /web folder) and control all the internal developments. So deploying a module affects that composer.json (top) and basically makes separating in a single deployment different needs a bit different and redundant. Again, if all your multisites share the same code (single security update!) the great. But what happens if you have conflicting modules?  Now, if you add Fedora 5 to the mix. Each Multi site will manage its own configs, its own queues, its own flysystem targets but will try to publish all those sources to the same Fedora? Will middleware be aware of what comes from where? Tripple store? How do we know what to query there?

Question would be (if you need Multisites, because there are uses like sharing a single Docker container and a single Could machine to lower costs, but those differ to what we as repo users are used to), how you separate entities coming from site 1 to those from site 2 inside Fedora? How do you deal with the fact that users (real users, not XACML) could end being different entities (different Ids, different UUIDS) and how do you backup/restore this?

What i say is, the extra effort needed to make CLAW middleware machinery to be able to talk to different heads could require extra code. Also tiny things like your vocabularies, your "minted" entities, etc, would have to be duplicated in each Multisite. Keyword here is "duplication". There are ways around of course.

Conclusion: multi sites are still an option, we just need to make sure we are clear on what the benefits for us are  (individual, institutional and community wise) and assume that what we got out of the box in 7.x for the same concept will differ totally from what you get in this new environment.

I posted to that same thread Mark points to my concerns. Here it is https://github.com/Islandora-CLAW/CLAW/issues/396#issuecomment-416260098, this was almost 3 years ago!

I would love to hear the use cases and concerns people have. Also, with all these programmed deprecation cycles, concern/effort should be put in D9 

because multisite approach could change once we are there

Best

Diego Pino
Metro.org

Brandon Weigel

unread,
Feb 14, 2019, 9:35:59 AM2/14/19
to islandora-dev
I would love to hear the use cases and concerns people have.

The multisite architecture is the key reason Arca works as well as it does.
  1. While each child site has its own window on the content, the critical feature is the parent site, which provides *all* the content from one place, giving each site's content greater exposure, discoverability, etc.
  2. This also makes it a lot easier to provide centralized support. If one of our sites is having trouble displaying theirsite.arcabc.ca/islandora/object/my:object, I can look at it, and compare it to arcabc.ca/islandora/object/my:object and see at a glance whether the problem is their configuration or something more universal.
  3. The shared repository means that I, as the central coordinator, can make adjustments to everyone's objects at once. For example, we recently went through a major project to standardize our Genre terms on two controlled vocabularies. To do this, I exported 26,800 MODS.xml files from objects across all our 23 repository sites together, edited them locally on a text editor to harmonize the terms, and then re-imported them together. Doing this for 23 child sites individually would have taken 23 times as long.
  4. The shared codebase means that all of our sites have the same basic architecture, access to the same modules, the same paths to various places, and the same customizable theme - and they can all be tweaked and updated at once. Want to update Islandora Badges? Go to sites/all/modules/islandora_badges and "git pull". I'd rather do this one time than 23 times.
There are more benefits; these are just the ones off the top of my head. Honestly, multi-tenancy is critical to the consortial model we use. If we couldn't use a similar approach in Islandora 8, I'm not sure how sustainable we'd be.

And the number of multi-tenant implementations like ours is growing, although they aren't all participating in the community communications. I've communicated with several and even helped a couple get started. This is a major consideration and important to the longevity of the Islandora platform.

So... I don't have any answers to how multisite (or something that looks and feels like multisite) would work in Islandora 8, but I can tell you that quite a lot of Islandora users depend on it.

Cheers,

Brandon Weigel

Mark Jordan

unread,
Feb 14, 2019, 10:31:45 AM2/14/19
to islandora-dev

Brandon,


Thanks for providing some rough use cases to help us focus on what multisite functionality means. I think it's fair to say that no one in the Islandora community has any substantial experience with Drupal 8's multisite capabilities. As with end-of-life timelines, we need to learn to live within the constraints Drupal forces on Islandora. I propose that a group of us focuses some effort on testing Drupal 8's multisite capabilities, at least on something like the CLAW playbook, in the very short term so we can better understand what the roadblocks will be at the time of the launch of Islandora 8. We should also acknowledge, as Diego points out, that Drupal 8's multisite capabilities are probably still not fully baked. But at least if we keep on top of how they mature, we will be better able to plan for 7->8 migrations and for greenfield 8 installations.


I will also suggest that we focus on Drupal first, understand the challenges there, then look at how Fedora 5 relates to our goals here. Maybe we can rely strictly on Drupal for the kinds of benefits you outline in your use cases and not worry about Fedora, keeping in mind that in Islandora 8, Drupal and Fedora have a different relationship than they do in Islandora 7. Also, Islandora 8's heavy reliance on Contexts may be worth looking at (see my comment at https://github.com/Islandora-CLAW/CLAW/issues/396#issuecomment-449586318 for a start at an implementation that uses a "namespace" in Islandora 8 nodes).


Given the importance of multisite capabilities, and the number of Islandora7 instances that rely heavily on it, I even wonder if it's worth forming a short-lived Multisite Interest Group to take this work on. Just a thought. I also wonder if we should move this discussion from the islandora-dev list to the general islandora list, since this is an issue that we need the broadest possible input on.


Mark



From: island...@googlegroups.com <island...@googlegroups.com> on behalf of Brandon Weigel <jeanpau...@gmail.com>
Sent: Thursday, February 14, 2019 6:35 AM
To: islandora-dev
Subject: Re: [islandora-dev] Drupal 8 multi-site capability?
 

Daniel Lamb

unread,
Feb 14, 2019, 11:43:03 AM2/14/19
to island...@googlegroups.com

Despite their flaws, D8 multisites are the most supported/least invasive way point multiple domains at a single Drupal server.  If you're attempting shared hosting, that's still a good deal.  They hit a sweet spot for maximizing what you can get out of a single Drupal server on the cheap.  Do you _need_ them?  Absolutely not.  I think there's multiple ways to interpret multi-tenancy in Islandora, and if you want to go with a Drupal -- and even a Fedora -- per tenant, that's a solid approach, too.  I wouldn't want Islandora 8 to knowingly exclude either, as there's certain to be different benefits for different situations.  And lets face it, lots of people use multisites.

But yes, with the state of the software currently, if we want to wire up multiple Drupal frontends to a single Fedora backend, there's some legwork to do.  Its something we've waited to do because it depends on Fedora 5's WebAC capabilities.  A lot of it will be figuring out how to lay down very basic restrictions using WebAC policies to sandbox groups of users to subtrees.  Drupal users/roles/perms will need to get translated roughly into WebAC.  We'll never get the full granularity of Drupal permissions in Fedora, but we certainly can partition a Fedora good enough to keep tenants restricted to their own space.

In my opinion, a single kitchen sink install with a Drupal multisite should be a viable entry into small scale shared hosting. It certainly would be a good exercise to go through.  But I don't think that's the one or only way to do it, and getting a better understanding of what everyone is expecting will certainly inform what work we eventually end up doing.


For more options, visit https://groups.google.com/d/optout.
--
~Danny Lamb
Tech Lead
Islandora Foundation
http://islandora.ca

Mark Jordan

unread,
Feb 14, 2019, 12:30:33 PM2/14/19
to island...@googlegroups.com

Danny, thanks for pointing out there are several ways that multi-tenancy/multisite can be approached.


Mark



From: island...@googlegroups.com <island...@googlegroups.com> on behalf of Daniel Lamb <dl...@islandora.ca>
Sent: Thursday, February 14, 2019 8:42 AM
To: island...@googlegroups.com
Subject: Re: [islandora-dev] Drupal 8 multi-site capability?
 
Reply all
Reply to author
Forward
0 new messages