[Rock-Ons] Docker networks cannot easily be defined in definition file

[FroggyFlox]

Since #2207 , Rockstor supports the creation and attach/detach of docker containers to a docker network (that we call rocknet). While this helps for customization of already installed Rock-Ons by the user, we currently do not offer an easy way to define these in the Rock-On definition file itself. This forces the use of complex workarounds that themselves come with limitations (see #2900, for instance).

It is thus proposed to allow the creation of new rocknets from a Rock-On definition file, as well as the attachment of select containers to them.

Needs

We need to:

• allow the creation (optional) of one or more rocknets at the Rock-On level.
• allow the attachment of a given container to one or more of these rocknets.

Approach

The easiest approach may be to follow what is currently used by docker-compose (https://docs.docker.com/compose/how-tos/networking/#specify-custom-networks) and use:

• a top-level network element (https://docs.docker.com/reference/compose-file/networks/): this would correspond to a Rock-On level element in our json file.
• a service-level network element (https://docs.docker.com/reference/compose-file/services/#networks): this would correspond to a container-level element in our json file.

This could thus be something akin to:

{
    "My Rock-On": {
        "containers": {
            "container1": {
                "networks": [
                    "rocknet01",
                    "rocknet02",
                ]
                },
            "container2": {
                "networks": [
                    "rocknet01",
                ]
                },
            "container3": {
                "networks": [
                    "rocknet02",
                ]
                }
            },
            "rocknets": {
                "rocknet01": {},
                "rocknet02": {"<dict-of-options>"},
            }
        }
}

Both new elements would be optional, to ensure backwards compatibility.

A lot of details (what options to consider, for instance?) remain to be set, but the above should help start the discussion to decide:

• should we support something like this?
• how to best implement it?