Magnum

master docker-volume-size should be distinct from nodes

Bug #1651370 reported by Ricardo Rocha
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Magnum
Confirmed
Undecided
Ricardo Rocha

Bug Description

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.

yatin (yatinkarel)
Changed in magnum:
status: New → Confirmed
Revision history for this message
feng.shengqin@zte.com.cn (feng-shengqin) wrote :

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.

Revision history for this message
Ricardo Rocha (rocha-porto) wrote :

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.

Revision history for this message
yatin (yatinkarel) wrote :

<<< 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.

Revision history for this message
PanFengyun (pan-feng-yun) wrote :

> 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?

Revision history for this message
PanFengyun (pan-feng-yun) wrote :

In my side, I like B. ):

Ricardo Rocha (rocha-porto)
Changed in magnum:
assignee: nobody → Ricardo Rocha (rocha-porto)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.