# Uninstall a plugin

## Experiment setup

* Setup a sandbox with pulpcore and multiple plugins installed, with and without pulp-2to3-migration
* the majority of plugins only have FKs/relations with pulpcore objects
* some plugins (e.g. pulp-2to3-migration) can have FKs to other plugins as well, not just pulpcore

## Uninstall `pulp_file`

Confirmed works (only without pulp-2to3-migration):
* `sudo -i`
* `systemctl stop pulp*`
* `pulpcore-manager migrate --plan file zero`
look for `Raw Python operation -> IRREVERSIBLE`
* `pulpcore-manager migrate file zero`
* `/usr/local/lib/pulp/bin/pip uninstall pulp_file`
* `systemctl start --all pulp*`

## Confirmed uninstallable plugins:

* `pulp_file` (only if pulp-2to3-plugin is not installed)
* `pulp_python`
* `pulp-certguard`

Uninstalled them.

## Non-reverseable migrations:

* `pulp_ansible`
* `pulp_container`
* `pulp_rpm`

## Reinstall plugins

Ran `vagrant provision ...` to check if plugins are reinstallable.

## Notes/Caveats/Problems:

- Down migrations must be performed, while the plugin code is still installed.
- Removal of detail models will leave the master table in a bad state.
- This seems to be a general problem with django (tried with `2.2.*` and `3.*`)
- https://code.djangoproject.com/ticket/32724
- Removal without using ORM is painful and not feasible because of all the relations needed to be cleaned up in muliple tables which are handled by ORM and not easy or skipped if you perform directly in the db.
- uninstallable plugins can fail if other plugin refers to any objects of the plugin, watch for `django.db.utils.IntegrityError: update or delete on table "XXX" violates foreign key constraint`.
- Non-atomic migrations can be half unapplied and be stuck at this state, can't be applied back, e.g. pulp_file 0009.
- Order in which content is being removed matters
- Artifacts are not cleaned up, orphan cleanup should be used
- Need to deal with auth_permission, django_content_types, core_accesspolicy
- FileRemote has access/relations to some RPM details, smells like some django magic and master-detail models but it causes problems at plugin removal time. Try dir() on any FileRemote instance in django shell.

## Ideas
* ask QE for a box with a large data set to see if it's user friendly to ask for a downtime
* asked, in progress
* if a noticeable downtime is needed to remove a plugin (more than 30 sec? 1 min?):
* find a way to disable a plugin in way that will allow command to use ORM but plugin won't be accessible for using after restart of services
* do explicit pre-delete (remove all data which takes long), then demand the downtime and run removal again to cleanup everything
* potentially can cause problems if users work with data we are deleting and will cause the whole app to fail
* in a fully containerized env, spin up containers where plugin is not installed, shutdown those where it is installed, spin up one where plugin is disable but ORM is acceesible, run remove-plugin command in this container
* testing is needed
* probably for every plugin
* for uninstallable plugins use fake migrations to avoid using raw SQL
* docs
* we need a guidance for plugin writers
* about atomic/non-atomic migrations
* to encourage to make migrations reversible
* entities we create in core should be easily identifiable in terms of which plugin they belong to, e.g. core_accesspolicy concern

## Current working approach
* require pulp services to be down
* remove all plugin data
* remove all data via plugin models (django.apps.all_models[app_label])
* remove other data which is indirectly related to plugin (auth_permission, django_content_types, core_accesspolicy)
* raw SQL only it seems
* maybe auth_permisssion can be removed via ORM, need to try
* unapply migrations
* try in a clean way
* otherwise fake it until you make it (fake unapply + drop table with raw SQL)
* done
* after that user needs to uninstall plugin and it depends how it was initially installed, pip or yum/dnf way.