Changing the default port for salt-api results in DeepSea stage 1 failing

This document (7022829) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Enterprise Storage 5

Situation

Changing the default salt-api port by adjusting the port number in "/etc/salt/master.d/salt-api.conf" results in DeepSea stage 1 failing with:

Stage initialization output:
salt-api                 : ["Salt API is failing to authenticate - try 'systemctl restart salt-master'"]
deepsea_minions          : valid
master_minion            : valid
ceph_version             : valid

Stage execution failed:

- salt-api failed

Resolution

The current suggested workaround is to create a custom stage 1 to bypass the salt-api validation check.

Cause

The validation check uses a curl command that specifically only checks against the default salt-api port, port 8000.

Additional Information

If it is determined that the salt-api validation is indeed failing due to a port change, to create a custom DeepSea stage 1 that bypasses the salt-api validation, the following steps are needed:

1. Copy "/srv/salt/ceph/stage/1/default.sls" to for example "/srv/salt/ceph/stage/1/custom.sls".
2. Edit "/srv/salt/ceph/stage/1/custom.sls" and remove the following section from the top if this file:

{% if salt['saltutil.runner']('validate.saltapi') == False %}

salt-api failed:
salt.state:
    - name: just.exit
    - tgt: {{ salt['pillar.get']('master_minion') }}
    - failhard: True

{% endif %}

3. Edit "/srv/pillar/ceph/stack/global.yml" and add the line:

stage_discovery: custom

4. Now re-run DeepSea stage 1.

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.