FAQ
Thats pretty close to how I'd do it. Personally I'd push that cron job down
to the minions (that way if its connected to a different master or if the
minion died, it will attempt to reconnect.

As for statistics about the returns, all of the return data will be in the
job cache. If you want to store it for longer you can either have the
master use an external job cache (mysql, couchbase, etc.) or use reactors
to ship the job returns off box. Once the data is somewhere else you can
make dashboards of the returns. I know the LimeLight guys are using Kibana
and ElasticSearch to make some nice dashboards of what did what (they gave
a talk which included that @ SaltConf2015).


On Tuesday, April 21, 2015 at 4:34:07 AM UTC-7, Vince from Belgium wrote:

Hello,

we have - proudly ;-) - replaced Windows XP by GNU/Linux (Debian Jessie -
Gnome desktop) on our company desktop PC fleet of +/- 100 laptops.

As a replacement of Window GPO, we have chosen saltsatck and since one
month now, we are happy using (and learning) salt to centrally manage our
100 laptop PC

Our users can only connect to the saltmaster when their VPN is active,
which occurs ...randomly : every day for some, once in a month for others,
and probably never for some others.

When we need to deploy a new package or a change in the laptops
configurations files, we define a new state on the saltmaster, and we have
an ever running cron job on the master :

15 7-23 * * * /usr/bin/salt '*' state.highstate

that launch a salt highstate on all the minions every 15 minutes, or to be
more precise, on all the reachable minions (the minions connected to the
our VPN) at theses moments.

We don't know if it's the best practice, but it was easy to implement :-)


*But* our problem is that we don't have a global view of which minions
have successfully received the last states updates and which not.


*What would be the best practice to get an aggregated evolving list of the
cron launched "salt '*' state.highstate " results ?*
Something like a list/database with these columns/fields :

minion_name
date_hour of the last highstate *real* execution on the minion (not
taking account the failed attempt by the server to reach minions not
listening), and displaying nothing if the minion was never reached
number of failed states
number of succeed states
number of changes
prime : name of the failed state(s) and/or link to the job execution log

If someone has already done that and has a code example, it will make my
week ;-) , but you can already make my day with a good advice on how to do
that from your point of view !

Thanks,

Vince from Belgium
--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 2 | next ›
Discussion Overview
groupsalt-users @
postedApr 21, '15 at 11:34a
activeApr 22, '15 at 2:42p
posts2
users2

People

Translate

site design / logo © 2021 Grokbase