Project

General

Profile

communication #59918

Salt automation: auto-deploy and monitoring

Added by mcaj 8 months ago. Updated 7 months ago.

Status:
New
Priority:
Normal
Assignee:
Category:
Configuration management (CM)
Start date:
2019-11-17
Due date:
% Done:

0%

Estimated time:
Duration:

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.

History

#1 Updated by okurz 8 months ago

https://gitlab.suse.de/openqa/salt-states-openqa/blob/master/.gitlab-ci.yml has the important pieces that we use already. I can propose something for a salt repo on gitlab.i.o.o

#2 Updated by cboltz 8 months ago

  • 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 ;-)

#3 Updated by cboltz 7 months ago

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.

Also available in: Atom PDF