Full setup from clean machine fails because of unexpected order of operations

[mbukatov]

When I have yum, service sections to install and start gluster server, then peer to create trusted storage pool and finally backend-setup section in gdeploy config file, gdeploy fails during execution, because it will try Create Physical Volume first (when the gluster is not yet installed) and fail.

Version

gdeploy-2.0.2-7.noarch (from sac-gdeploy copr)

Steps to reproduce

1. Prepapre set of clean CentOS 7 machines (with base system and CentOS repositories only)
2. Install centos-release-gluster310 package on all machines
3. Create new gdeploy config file (list all machines created in the previous step):

[hosts]
mbukatov-usm1-gl1.example.com
mbukatov-usm1-gl2.example.com
mbukatov-usm1-gl3.example.com
mbukatov-usm1-gl4.example.com

[yum]
action=install
gpgcheck=yes
packages=glusterfs-server

[service1]
action=enable
service=glusterd

[service2]
action=start
service=glusterd

[peer]
action=probe
ignore_peer_errors=no

[backend-setup]
devices=vdb,vdc
vgs=vg_gluster_1,vg_gluster_2
pools=pool_gluster_1,pool_gluster_2
lvs=lv_gluster_1,lv_gluster_2
mountpoints=/mnt/glusterbrick_1,/mnt/glusterbrick_2

3. Run gdeploy:

$ gdeploy -c reproducer.conf

Actual Result

Gdeploy immediately fail during Create Physical Volume task:

$ gdeploy -c sample.conf

PLAY [gluster_servers] ******************************************************************************************************************************

TASK [Clean up filesystem signature] ****************************************************************************************************************
Friday 11 August 2017  12:12:11 -0400 (0:00:00.135)       0:00:00.135 *********
skipping: [mbukatov-usm1-gl1.example.com] => (item=/dev/vdc)
skipping: [mbukatov-usm1-gl1.example.com] => (item=/dev/vdb)
skipping: [mbukatov-usm1-gl2.example.com] => (item=/dev/vdc)
skipping: [mbukatov-usm1-gl2.example.com] => (item=/dev/vdb)
skipping: [mbukatov-usm1-gl3.example.com] => (item=/dev/vdc)
skipping: [mbukatov-usm1-gl3.example.com] => (item=/dev/vdb)
skipping: [mbukatov-usm1-gl4.example.com] => (item=/dev/vdc)
skipping: [mbukatov-usm1-gl4.example.com] => (item=/dev/vdb)

TASK [Create Physical Volume] ***********************************************************************************************************************
Friday 11 August 2017  12:12:12 -0400 (0:00:00.198)       0:00:00.334 *********
fatal: [mbukatov-usm1-gl4.example.com]: FAILED! => {"failed": true, "msg": "The conditional check 'result.rc != 0 and 'Physical Volu
me Exists' not in result.msg' failed. The error was: error while evaluating conditional (result.rc != 0 and 'Physical Volume Exists' not in result.ms
g): 'dict object' has no attribute 'rc'"}
fatal: [mbukatov-usm1-gl1.example.com]: FAILED! => {"failed": true, "msg": "The conditional check 'result.rc != 0 and 'Physical Volu
me Exists' not in result.msg' failed. The error was: error while evaluating conditional (result.rc != 0 and 'Physical Volume Exists' not in result.ms
g): 'dict object' has no attribute 'rc'"}
fatal: [mbukatov-usm1-gl3.example.com]: FAILED! => {"failed": true, "msg": "The conditional check 'result.rc != 0 and 'Physical Volu
me Exists' not in result.msg' failed. The error was: error while evaluating conditional (result.rc != 0 and 'Physical Volume Exists' not in result.ms
g): 'dict object' has no attribute 'rc'"}
fatal: [mbukatov-usm1-gl2.example.com]: FAILED! => {"failed": true, "msg": "The conditional check 'result.rc != 0 and 'Physical Volu
me Exists' not in result.msg' failed. The error was: error while evaluating conditional (result.rc != 0 and 'Physical Volume Exists' not in result.ms
g): 'dict object' has no attribute 'rc'"}

Note that Create Physical Volume is part of backend-setup tasks and that this section is listed last in the gdeploy config file.

Expected Result

Gdeploy will follow the order of sections listed in the config file, so that the operation will succeed.

[mbukatov]

It seems that the workaround could be to separate operations into multiple gdeploy config files, but for that, I would like to keep the list of gluster servers in separate file.

[mbukatov]

Does this bug report make sense wrt gdeploy design?

[sac]

Martin it does. The initial design once upon a time was to do backend-setup first, irrespective of whereever it was listed in the config file. However it does not make sense anymore now after the development of yum and other sections. We have to change gdeploy to follow the order listed in the config file.

[mbukatov]

When I think about it, trying to adhere to the ordering specified in gdeploy config file could be problematic for these reasons:

• all current gdeploy config files are written with gdeploy ignoring the order in mind, so that changing that could break lot of gdeploy scripts
• gdeploy config file is a ini file, and module from python standard library doesn't care about order of the items in ini file either

So maybe we could just change the order so that package installation would be performed first.