[super] CKAN Hosted

[pudo]

Many users of CKAN want to have their own instance without much effort. Setting these up in separate places is a maintenance nightmare, we should much rather have some tenant separation in core CKAN. Some ideas:

• introduce model.Site and c.site
  • site has: custom CSS, extra_template_path, title, languages list, package_form, group_form (all configured via web UI)
• Subdomain detector to activate sites.
• use site in Authorizer instead of System, have a NullSite? for global things
• allow cross-site search
• packages are in a list of sites, m:n rather than 1:n
  • list of sites is string-based, can contain sites not in site table to express harvested external material which is not editable locally.

[nils.toedtmann]

See also ​http://ckan.okfnpad.org/multisite

[thejimmyg]

Renaming to CKAN Hosted because whether we introduce a site domain object for subdomain tenants or not is an implementation detail.

As far as progress on CKAN hosted goes, we now have:

• A build tool to package ckanext-dgu, ckanext-std etc into .deb files
• The ability to apt-get install CKAN
• A script that can set up multiple non-conflicting CKAN instances on the same machine

What we need next is the ability to generate a ckanext-xxx repository for each new instance we want to host. At that point most of the underlying techniques for hosting multiple CKAN instances concurrently will be in place. Once we have that working and know what clients want, we can look at going further and speccing up a multisite solution off a single DB, rather than the multi-instance solution proposed here.

[thejimmyg]

Milestone ckan-v-future deleted