Changes in 0.15.x to use kolibri with external plugins

[jredrejo]

References

Testing kolibri 0.15 as base for the KDP plugin I've found some blockers that need changes in the current kolibri code.
With these changes the backend now can run, in the future there might be also needed changes for the frontend.
In summary the changes are:

• In migrations, replace settings.AUTH_USER_MODEL by the kolibriauth.FacilityUser model because when kolibri is run in a different environment the AUTH_USER_MODEL can be different and migrations will break.
• A small change to the Django initialization process to bear in mind other possible cache backends.

Reviewer guidance

• Do tests pass
• Any possible regression?

Testing checklist

• Contributor has fully tested the PR manually
• If there are any front-end changes, before/after screenshots are included
• Critical user journeys are covered by Gherkin stories
• Critical and brittle code paths are covered by unit tests

PR process

• PR has the correct target branch and milestone
• PR has 'needs review' or 'work-in-progress' label
• If PR is ready for review, a reviewer has been added. (Don't use 'Assignees')
• If this is an important user-facing change, PR or related issue has a 'changelog' label
• If this includes an internal dependency change, a link to the diff is provided

Reviewer checklist

• Automated test coverage is satisfactory
• PR is fully functional
• PR has been tested for accessibility regressions
• External dependency files were updated if necessary (yarn and pip)
• Documentation is updated
• Contributor is in AUTHORS.md

[rtibbles]

Some comments - nothing blocking. Also suggested adding a catch to the device migration that causes issues when there's a DB cache.

[rtibbles]

Oh wow, it's Django doing this - in the model specification it's explicitly targeting the FacilityUser model, but it went ahead and turned it into this reference anyway: https://github.com/learningequality/kolibri/blob/develop/kolibri/core/bookmarks/models.py#L18

[rtibbles]

I guess the other way of handling this would be to check if the process_cache is not the default cache - which in the case of Redis it is, and I assume for online instances also?

[jredrejo]

I don't understand this comment. If process_cache is in CACHES (i.e. it's not the default cache) it means we're not using redis.
The logic would be mostly the same. We can remove the attribute error checking the cache BACKEND. Is that what you have in mind? :

def _post_django_initialization():
    from kolibri.deployment.default.cache import CACHES

    if 'process_cache' in CACHES:
        backend = CACHES['process_cache']['BACKEND']
        if backend != 'django.core.cache.backends.db.DatabaseCache':
            try:
                process_cache.cull()
            except SQLite3DatabaseError:
                shutil.rmtree(process_cache.directory, ignore_errors=True)
                os.mkdir(process_cache.directory)
                process_cache._cache = FanoutCache(
                    process_cache.directory,
                    settings.CACHES["process_cache"]["SHARDS"],
                    settings.CACHES["process_cache"]["TIMEOUT"],
                    **settings.CACHES["process_cache"]["OPTIONS"]
                )

[rtibbles]

Yeah, mostly just to make it based on Django settings, rather than our OPTIONS, so in the case that it's overridden by a custom settings file, we're still checking properly.

[jredrejo]

ok, done it. I have also added a guard in kolibri/core/device/migrations/0003_contentcachekey.py to avoid the problems this migration had when running in a system using DatabaseCache.