[Deepsea-users] stage 1 errors on Azure
Eric Jackson
ejackson at suse.com
Wed Sep 19 14:39:28 MDT 2018
The rpm would be installed after Salt is configured. I understand some installations
install both Salt and DeepSea via YaST. We did try to make accommodations for that
scenario.
So, your salt-api is still down. We ran into drastically different reasons why the salt-api
can fail. We did not have the bandwidth to address each type of failure. The check we do
is a curl command to verify that the salt-api is answering.
curl -si localhost:8000/login -H "Accept: application/json"
-d username=admin -d sharedsecret=xxx -d eauth=sharedsecret
The sharedsecret is in /etc/salt/master/sharedsecret.conf. It's possible to have the Salt
master remember the previous contents of that file and the Salt api to use the current
contents if an admin does things just right :) . That's why we give the error message
about restarting the Salt master.
However, if the above curl command fails because the Salt-api is down or maybe
localhost is not defined in /etc/hosts (ran into that once). The curl command may shed
more light on the failure.
***
As far as how would you have found that curl command. Take a look at the contents of /
srv/modules/runners/validate.py. About line 626, you will see the python code is literally
calling the curl command. In other words, do not be intimidated about the python code.
Much of it is calling some of the same command line tools that you would use. We are
just using Salt to do much of this in parallel.
It's also possible to run this directly without invoking Stage 1.
# salt-run validate.saltapi
Although the validations can be frustrating, not having them is worse. The situations
where we did not check for Salt api lead to incredibly painful debug sessions.
Eric
On Wednesday, September 19, 2018 3:56:17 PM EDT Kevin Ayres wrote:
> Thanks Eric, Yes, I understand this but worded it poorly. I don't see any
> issues with NTP or DNS. Something else is amiss.
Should deepsea be
> installed after salt as outlined in the deployment doc, or before?
> salt:~ # salt-run state.orch ceph.stage.discovery
> salt-api : ["Salt API is failing to authenticate - try
> 'systemctl restart salt-master': list index out of range"]
deepsea_minions
> : valid
> master_minion : valid
> ceph_version : valid
> [ERROR ] No highstate or sls specified, no execution made
> salt_master:
> ----------
> ID: salt-api failed
> Function: salt.state
> Name: just.exit
> Result: False
> Comment: No highstate or sls specified, no execution made
> Started: 19:38:41.962044
> Duration: 0.734 ms
> Changes:
>
> Summary for salt_master
> ------------
> Succeeded: 0
> Failed: 1
> ------------
> Total states run: 1
> Total run time: 0.734 ms
>
>
> salt:~ # tail -f /var/log/salt/master
> 2018-09-19 18:44:36,555 [salt.loaded.ext.runners.minions][WARNING ][15319]
> All minions are ready
2018-09-19 19:38:41,955 [salt.transport.ipc][ERROR
> ][1626] Exception occurred while handling stream: [Errno 0] Success
> 2018-09-19 19:38:41,962 [salt.state ][ERROR ][40826] No highstate
> or sls specified, no execution made
> salt:~ # ls /srv/pillar/ceph/proposals
> ls: cannot access '/srv/pillar/ceph/proposals': No such file or directory
>
> salt:~ # ls /srv/pillar/ceph/
> benchmarks deepsea_minions.sls deepsea_minions.sls.rpmsave
> init.sls master_minion.sls master_minion.sls.rpmsave stack
>
> ~ Kevin
>
> On 9/19/18, 12:37 PM, "deepsea-users-bounces at lists.suse.com on behalf of
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.suse.com/pipermail/deepsea-users/attachments/20180919/09b42750/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.suse.com/pipermail/deepsea-users/attachments/20180919/09b42750/attachment.sig>
More information about the Deepsea-users
mailing list