SaltGUI and saltstack multimaster infrastructure

[erwindon]

Hi,
currently SaltGUI connects to a single master to execute salt commands, retrieve information (grains, pillars,..) and results.

In my case, we have 2 salt masters servers and 1 salt manager server, the manager manages the masters via salt-syndic installed on the 2 salt masters, and thus load balances the deployment requests to one or the other master.

the result is that if the manager sends the deployment to the server not "linked" to SaltGUI, I don't get the result, so basically I only get 50% of the saltstack results.

Is it possible to make SaltGUI compatible with a multimaster infrastructure?

[erwindon]

I did test SaltGUI in combination with salt-syndic like a year ago.
But I cannot remember the exact outcome; and I've lost the relevant VMs.
I'll set things up again and report back on the (im)possibilities of using SaltGUI in such context.

[erwindon]

here is a link for my convenience https://docs.saltproject.io/en/latest/topics/topology/syndic.html

[erwindon]

after some experimenting with salt-syndic...

The current version of SaltGUI does not properly support the minions behind a salt-syndic.
This is due to the fact that often the assumption is made in the software that the list of replies from regular salt-api calls matches the output from api call wheel.key.list_all. When salt-syndic is in use, the api call may return more results, and those extra results will not be shown.

The good news is that all the necessary information seems to be available.
You can already test that for some screens. Just zoom in on any minion while inspecting grains/schedules/pillars/beacons. Then change the URL to contain the minion-id of a minion that is behind a salt-syndic.

I'll try to update SaltGUI to handle this.

[erwindon]

@pju51
I have stability issues with the salt-syndic installation.
It seems that there is sometimes a mix-up of the certificates between the syndic and the master on the same machine. this is also reported by other users.
can you disclose the salt-version that you are using?

[pju51]

@erwindon
we use an old version : 3000.3 , we should update it during the year.

we do not have a certificate problem with salt-syndic on our side

[erwindon]

thx, I'll just try that one!

[erwindon]

we use an old version : 3000.3 , we should update it during the year.

note that syndic is misbehaving in later versions.

3000.3

I think that works for me.

[erwindon]

Here is an overview of the screens and their current behaviour in a syndic context:

• main screen: shows all minions, OK
• grains: shows all minions, but the click-row is broken for minions behind salt-syndic, menu item works though (a)
• schedules: same
• pillars: same
• beacons: same
• keys: shows only the minions that are not behind the salt-syndic, which is OK
• jobs: show all jobs, at least the ones that are initiated from the (main) master, OK
• highstate: only shows the minions for which the master knows the keys, thus minions behind salt-syndic are missing (b)
• templates: ok
• events: ok
• issues: some issues for minions behind salt-syndic are not reported (c)

So I now spot 3 separate issues, marked (a), (b) and (c)

Do you have any other issues that should be investigated?

[pju51]

@erwindon

no, seems clear but I don't see how it can work?

simply change proxy_pass http://saltmaster-local:3333/; to point to the salt-syndic ?

[erwindon]

in my setup the following works properly:

• have 1 master-of-masters (order_masters:True, syndic_master:not-set)
• have several secondary salt-master-s (order_masters: False, syndic_master:hostname-or-ip-of-master-of-masters)
• have 1 salt-syndic next to each secondary salt-master
• have no salt-api-s next to the secondary salt-masters
• have 1 salt-api next to the main salt-master, same config as usual. this is the only salt-api in the network, and it can host SaltGUI. there is only one SaltGUI, and it can handle all minions.

In a production situation, it is described as useful to use a backup-master next to each normal master. in fact, in each pair the second node is the backup for the first one, but also the first node is a backup for the second. but this is a high-availability scenario. so far, we were working on a load-reducing solution. So, I'll ignore that part of the setup.

When you have this setup, all salt commands that are issued against the main salt-master will get forwarded to all minions that are either directly reachable, or that are connected to the secondary salt-master-s.

When using salt-syndic(-s), the only real difference is that salt '*' ... executes its tasks on all minions, not just the minions that are reported by salt-key on the main salt-master, but also the ones that are connected to a secondary master.
In the 3 cases in which SaltGUI still misbehaves, SaltGUI was making mistakes about that fact. I'll create separate issues for them in github, so that these issues will be fixed. note that these are #461, #462 and #463. And I cannot rule out that more issues will be found.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[erwindon]

migrated issue to PR