Change design of tasks

Currently, our tasks are modelled as an enum of simple tasks (e.g. LAUNCH, RESTART, HEALTH_CHECK), and do not have any parameterization, other than initial parameterization when creating a deployment. That is, tasks can return a result (status, result, traceback), but cannot be parameterized with a config. This means that we have a hard time modelling actions like configuration changes, or even tracking what the configuration changes are.

Instead, we could possibly allow tasks to be parameterized by a config, with the deployment tracking the final, most up-to-date config.

e.g.

class DeploymentTaskSerializer(serializers.ModelSerializer):

    celery_id = serializers.CharField(read_only=True)

    action = serializers.CharField() # an arbitrary app defined string

    parameters = serializers.StoredJSONField() # arbitrary parameters for executing tasks

    status = serializers.CharField(read_only=True)

    result = serializers.DictField(read_only=True)

    traceback = serializers.CharField(read_only=True)

When modelled this way, the deployment will only contain a final, cached config reflecting the latest state. Any changes to the config must be done through tasks, and each task records what its parameters are. This gives us the ability to track/audit each configuration change, from LAUNCH to DELETE. (essentially, the command pattern)

In addition, the AppPlugin interface also becomes simpler. It will only contain CRUD methods (no special purpose methods like restart, health_check etc). Performing a restart will be a new task that perform an AppPlugin.update(), parameterised by the task name/config. Appliances can freely implement the update method as they see fit.

Not a priority for now, but something we can implement in future?

@afgane @machristie Thoughts?