| *** jlozadad has quit IRC | 00:16 | |
| *** jlozadad has joined #ara | 00:23 | |
| *** bcoca has quit IRC | 00:27 | |
| *** dcreno has joined #ara | 00:50 | |
| *** dcreno has quit IRC | 00:54 | |
| *** jlozadad_ has joined #ara | 02:21 | |
| *** jlozadad has quit IRC | 02:22 | |
| *** dcreno has joined #ara | 05:23 | |
| *** dcreno has quit IRC | 05:27 | |
| *** dcreno has joined #ara | 05:45 | |
| *** dcreno has quit IRC | 05:48 | |
| *** dcreno has joined #ara | 06:46 | |
| *** dcreno has quit IRC | 06:50 | |
| *** sshnaidm|off is now known as sshnaidm|rover | 08:52 | |
| *** jlozadad_ has quit IRC | 12:03 | |
| *** jlozadad_ has joined #ara | 12:40 | |
| *** myoung|ruck is now known as myoung | 12:56 | |
| *** Bakey has joined #ara | 13:38 | |
| *** bcoca has joined #ara | 13:42 | |
| *** bcoca has joined #ara | 13:42 | |
| *** tbielawa has joined #ara | 14:35 | |
| *** dcreno has joined #ara | 14:51 | |
| *** dcreno has quit IRC | 14:55 | |
| hiroki | Bakey: we run local Ansible playbooks for, our baseline and on top of it for individual roles, on the destination host itself (programmatically). To get visuals, ARA runs on each host as well for post analysis purposes. Don't know if that helps you .. | 15:25 |
|---|---|---|
| *** jlozadad_ has quit IRC | 15:31 | |
| *** dcreno has joined #ara | 15:35 | |
| *** dcreno has quit IRC | 15:39 | |
| Bakey | hiroki: hmm? | 15:52 |
| Bakey | so you de-centralize the ARA reports? | 15:53 |
| *** dcreno has joined #ara | 16:05 | |
| *** jlozadad_ has joined #ara | 16:11 | |
| hiroki | Bakey: yes, no need to aggregrate them in our case. We have positive/negative feedback loops for all playbook runs across our platform, so we know instantly what's up in case of failures. ARA is really used only for post analysis to catch a quick glimpse of what tasks failed and what the playbook's run mode was. Any deeper analysis requires us to move from ARA to our ELK stack to see the actual output of the | 16:17 |
| hiroki | Playbook run. But ARA is a great starting point as it weeds out repetitive and time consuming analysis of Playbook output | 16:18 |
| *** sshnaidm|rover is now known as sshnaidm|off | 16:52 | |
| *** jlozadad has joined #ara | 17:03 | |
| *** jlozadad_ has quit IRC | 17:04 | |
| Bakey | I'd think though in a highly volatile environment that would make it harder to keep track of play results | 17:06 |
| *** dcreno has quit IRC | 17:38 | |
| hiroki | Depends on the volatility of the object. If a node doesn't exist anymore, most probably previously run Playbook results are not of interest anymore. If it would, it makes more sense storing the results of ARA in a centralized MySQL cluster or similar. It would however add a SPOF as the Playbook will not run if ARA can't write to it's database | 17:43 |
| *** tbielawa is now known as tbielawa|lunch | 17:47 | |
| *** dcreno has joined #ara | 17:53 | |
| *** dcreno has quit IRC | 17:57 | |
| *** jlozadad has quit IRC | 18:00 | |
| *** jlozadad has joined #ara | 18:00 | |
| Bakey | if you care that much about SPOF MySQL can do clustering | 18:13 |
| hiroki | A MySQL cluster improves the availability of the MySQL as an individual entity, you still have to deal with a bunch of other potential issues that could prevent the MySQL cluster to be reached from endpoints that have nothing to do with the MySQL cluster itself ;-) | 18:22 |
| Bakey | still sounds like architecture fixes could eliminate a central server as a SPOF | 18:37 |
| *** dcreno has joined #ara | 18:44 | |
| *** dcreno_ has joined #ara | 18:48 | |
| *** dcreno has quit IRC | 18:48 | |
| *** tbielawa|lunch is now known as tbielawa | 18:49 | |
| dmsimard | The reason why I don't personally recommend running a central database is mostly because of the added latency/network overhead | 18:58 |
| Bakey | dmsimard: just throw more hardware at it :P | 18:58 |
| dmsimard | Even if your MySQL server is next door and you're looking at 10ms latency per query, it's not that long but it adds up if you're running against hundreds of hosts with hundreds of tasks | 18:59 |
| *** dcreno_ has quit IRC | 19:20 | |
| *** dcreno has joined #ara | 19:20 | |
| *** dcreno has quit IRC | 19:24 | |
| *** dcreno has joined #ara | 19:25 | |
| *** dcreno has quit IRC | 19:30 | |
| *** jlozadad has quit IRC | 19:49 | |
| *** tbielawa is now known as tbielawa|mtg | 19:58 | |
| *** twouters has quit IRC | 20:08 | |
| *** twouters has joined #ara | 20:08 | |
| *** twouters has quit IRC | 20:08 | |
| *** twouters has joined #ara | 20:08 | |
| *** tbielawa|mtg is now known as tbielawa | 20:30 | |
| *** tbielawa has quit IRC | 20:39 | |
| *** dcreno has joined #ara | 20:47 | |
| *** dcreno has quit IRC | 20:48 | |
| *** dcreno has joined #ara | 20:48 | |
| hiroki | Bakey: A proper architectural design isn't a magical solution for all, it's usually more multi-facetted than just that. Whatever you think, think times 10.000. However, i'm happy to help you with examples of our ARA setup if that's what you actually need :-) | 20:59 |
| Bakey | nah I don't think fully distributed makes sense for our environment | 20:59 |
| *** jlozadad has joined #ara | 20:59 | |
| *** dcreno has quit IRC | 21:04 | |
| *** dcreno has joined #ara | 21:10 | |
| *** dcreno has quit IRC | 21:14 | |
| *** dcreno has joined #ara | 21:25 | |
| *** dcreno has quit IRC | 21:26 | |
| *** dcreno has joined #ara | 21:27 | |
| *** jlozadad_ has joined #ara | 22:40 | |
| *** jlozadad has quit IRC | 22:41 | |
| *** dcreno has quit IRC | 22:59 | |
| *** dcreno has joined #ara | 23:03 | |
| *** dcreno has quit IRC | 23:07 | |
| *** dcreno has joined #ara | 23:09 | |
| *** dcreno has quit IRC | 23:16 | |
| *** jlozadad has joined #ara | 23:24 | |
| *** jlozadad_ has quit IRC | 23:24 | |
| *** jlozadad has quit IRC | 23:29 | |
| *** dcreno has joined #ara | 23:36 | |
| *** dcreno_ has joined #ara | 23:40 | |
| *** dcreno has quit IRC | 23:40 | |
| *** myoung is now known as myoung|off | 23:46 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!