We have SM3 installed and running but have a few problems which we posted separate threads about. We opened tickets with SUSE for each of these issues and the issue seems to be the feature wasn’t tested on salt clients (out of disk space in /boot not being reported back to SUMA when installing kernel patches for SLES11 and SUMA failures when installing a patch for a future time) or won’t be made available in SUMA for salt clients (action chains). Even though salt clients were introduced with SM3 and 5.1 from the “Getting Started” guide states “In addition to this Âtraditional framework SUSE Manager 3 includes a complete Salt solution.”, it seems the “traditional” client is better supported than the salt clients.
Interested to know whether or not people are using salt clients or “traditional” clients with SM3 and why.
‘Traditional’ has a different feature set and a slightly better UI integration compared to ‘salt minion’. Going forward, all our investment goes into ‘salt minion’ while ‘traditional’ will be in maintenance mode.
Action chains, or reusable actions, are much easier to achieve (and reuse) with Salt states.
The jabber solution has issues with fetching commands from the master in a timely fashion. Often sheduled actions only get picked up hours later. This made any sort of patch orchestration impossible. It works well with 10 clients, but if you go to 100+ it becomes flakey.
Salt IMO is a lot more elegant. It doesn’t need a daemon to call another tool. Its almost instant. Plus the main advantage to do cfg mgmt is a bonus. (We don’t use the interface for SALT in SUMA, we script everything in /srv/salt. )
The traditional client was buggy, really, really buggy. We used SUMA 2.1 with almost 1,000 clients and it was like a lottery whether or not a scheduled patch cycle would work on a client. Very often scheduled actions were not picked up or only hours later. Communication was jabber based (as in Spacewalk) and that was the main problem.
At the end of the SUMA 2.1 lifecycle jabber was somewhat stable. But then support ended. In SUMA 3.1 we only use salt minions. Salt itself is quite stable and reliable so far. But WebGUI integration is **** though: no action chain, reschedule events is not working (one of many bugs), no remote commands on system groups (not a salt problem specifically though) and so on.
But yeah, I would go with salt because the traditional client will not be supported for long anymore.
Traditional clients will be supported for a long time. However, since the ‘traditional’ stack is in maintenance mode, it will not get new features.
SUSE Manager 3.0 and 3.1 fully support traditional clients without loss of functionality. We will continue to add features to the Salt stack to make it functionality equivalent with the traditional stack.
Can traditional method and salt coexist on a managed system? I am having a hard time finding what are the real differences between both method, is one more recommended than another?
On the Uyuni docs, I found something stating
"Salt
Is an end-to-end data-center automation tool which may also be used outside the scope of Uyuni to introduce reactive, real-time orchestration, and configuration management. Managed systems can coexist using both traditional and Salt frameworks. This functionality provides a safe learning environment when switching to Salt while you continue to maintain existing deployments. "
Traditional stack was inherited from the original spacewalk solution. The client checks for ‘news’ every 1-4 hours which was not very convinient.
As a solution SUMA supports ‘push via ssh’ which actually means to ssh to client and force it to realize something is pending to be done (quite a smart approach).
Salt is another approach, quite useful in large environments and allows complex tasks to be scheduled either globally (on Organization level), group level or individually.
The Organization level is nice when a salt state is valid globally.
Group states are nice , because with activation keys, you can add a node to specific group and only then the state is taking into action.
Also, keep in mind that SALT has reactors which can allow you to take actions upon a specific event.
Also, with salt formulas - you have the alternative to ansible roles.
If I have to choose between SALT & Ansible - SALT is my favourite.
[{“insert”:"I made an RPM to update the “},{“attributes”:{“bold”:true},“insert”:“systemd”},{“insert”:” Timer for the Traditional host to check-in so it would happen more-frequently than every 4 hours. But we have <200 SLES hosts
My issue w\/SALT (or perhaps with the “SALT as integrated into SUMA”) vs. either a stand-alone SALT or Ansible is that not every device\/end-point we want to manage is registered (or registerable) to SUMA. We use Power9 hardware, and PowerVM\/HMC is not a supported Virtualization Manager in SUMA. If we want to orchestrate provisioning, I’m not seeing how we can do it via the SALT built into SUMA. But I can with a stand-alone Ansible or SALT. But having two such automation environments is not a good idea - so I might as well go with the stand-alone.
"}]