Besides the resolve_tasks() function, there is also the resolve_rollback_tasks()
function, which comes into play when something has gone awry while bootstrapping.
It should be used to clean up anything that was created during the bootstrapping
process. If you created temporary files for example, you can add a task to the
rollback taskset that deletes those files, you might even already have it because
you run it after an image has been successfully bootstrapped:

In resolve_rollback_tasks() you have access to the taskset
(this time it contains tasks that will be run during rollback), the manifest, and
the tasks that have already been run before the bootstrapping aborted (completed).

The last parameter is the counter_task() function, with it you can specify that
a specific task (2nd param) has to be in the taskset (1st param) for the rollback
task (3rd param) to be added. This saves code and makes it more readable than
running through the completed tasklist and checking each completed task.

You can also specify a validate_manifest() function.
Typically it looks like this:

In the schema above we check that the example plugin has a single property
named message with a string value (setting additionalProperties to false
makes sure that users don’t misspell optional attributes).

Internal plugins are part of the bootstrap-vz package and distributed with it.
If you have developed a plugin that you think should be part of the package
because a lot of people might use it you can send a pull request to get it
included (just remember to read the guidelines first).

External plugins are packages distributed separately from bootstrap-vz.
Separate distribution makes sense when your plugin solves a narrow problem scope
specific to your use-case or when the plugin contains proprietary code that you
would not like to share.
They integrate with bootstrap-vz by exposing an entry-point through setup.py: