communication #59918
closed
Salt automation: auto-deploy and monitoring
Added by mcaj over 4 years ago.
Updated over 2 years ago.
Category:
Configuration management (CM)
Description
Our general Salt goals are
- all core services to be in salt
- automating our automation
- better monitoring/reporting
This time we will focus on auto-deploy and Monitoring
The following solutions were proposed :
trigger the state.apply via the CI and send the output on monitoring
The auto-deploy via the CI can be done in the similar way as we are using for openqa.
Oliver Kurz offer us help in this are.
Marin Caj and Ricardo Klein will investigate monitoring options for salt so
we store changes and status in Monitoring tool.
- Private changed from Yes to No
I can't access gitlab.suse.de, therefore I'm looking forward to your MR to gitlab.infra.o.o ;-)
A little warning: Some servers have a "salt timebomb" (aka manually edited config files which are not synced back to salt), therefore please send out a warning before actually enabling this everywhere. IIRC this affects anna/elsa, daffy* (see the open MRs for keepalived) and mirrordb* (postgresql config files). This shouldn't stop us from auto-deploying changes in salt, but obviously we need to get these servers re-salted before ;-)
Update on the "salt timebombs" mentioned in my previous comment:
As soon as MR 302 gets accepted, the known (to me) salt timebombs are gone, and we can apply a highstate everywhere again.
- Status changed from New to Closed
- % Done changed from 0 to 100
Hi there - and a Happy and Healthy 2022!
I'm currently closing old tickets which did not see much change.
If the main concern still exists and should be handled, please re-open by just replying to this Email.
Thanks in advance,
Lars
Also available in: Atom
PDF