master docker-volume-size should be distinct from nodes

[Ricardo Rocha]

Currently the docker-volume-size passed in the magnum cluster template affects both the master and the nodes. This is not a big issue when the volumes are small, but it is when they are large.

As an example, here's a swarm cluster with 1 master, 2 nodes, docker-volume-size 500GB.

$ magnum cluster-template-show myswarm
+-----------------------+--------------------------------------+
| Property | Value |
+-----------------------+--------------------------------------+
| master_flavor_id | m2.medium |
| uuid | 34c6f972-683f-4798-9ee3-3f2b49d85047 |
| docker_volume_size | 500 |
| docker_storage_driver | devicemapper |
| name | myswarm |
| coe | swarm |
| flavor_id | m2.medium |
| ... | ... |
+-----------------------+--------------------------------------+

$ magnum cluster-create --name myswarm01 --node-count 2 --keypair-id rocha-cern --cluster-template myswarm

This results in two usable nodes, and a master with the scheduling disabled but which still has a 500GB volume attached to it, for no reason.

The same is true for kubernetes clusters.

We should either separate the docker-volume-size per master and node, or stop having docker volumes on the master and rely on the flavor having enough local storage.

[[e-mail] (feng-shengqin)]

I think the first step is to check resources. We should calculate the volume sizes of master and minion nodes and obtain the actual volume sizes. If the resource is not enough, we no longer continue to create the cluster.

[Ricardo Rocha (rocha-porto)]

That's a different thing, and i'm fine with the current behavior of the stack failing to create if not enough resources are available - the error from heat is very clear.

The point here is that we're creating a significant large volume and attaching it to a node (the master) which will never have any workload scheduled. It would be nice to avoid this.

[yatin (yatinkarel)]

<<< We should either separate the docker-volume-size per master and node, or stop having docker volumes on the master and rely on the flavor having enough local storage.

I think we should stop having docker volumes on the master as user containers would not be launched there. But we should decide the minimum flavor required for each type of cluster.
I think small flavor is enough for current clusters.

[PanFengyun (pan-feng-yun)]

> This results in two usable nodes, and a master with the scheduling disabled but which still has a 500GB volume attached to it, for no reason.

I meet this issue too.
As far as I know, when I specify docker_volume_size to 500, magnum will create two volume for cluster(1 master + 1 minion), one volume is attached to master, another volume is attached to minion.
Currently master is unscheduler, it is no need to attach volume to master.
So I need a patch to enhance 'docker_volume_size':
A: docker_volume_size just for minion, magnum just create volume for minion.
B: add master_docker_volume_size for master, add minion_docker_volume_size for minion, deprecate docker_volume_size.

A or B?

@strigazi
@flwang
any thoughts?

[PanFengyun (pan-feng-yun)]

In my side, I like B. ):