-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Meta] User survey: Are you using ARA ? What is your use case ? #103
Comments
Hi! I'm using ARA 1.x, for the advanced logging, tracing and debugging capabilities (even when compared to Jenkins, AWX/Tower or Rundeck) - especially when working with multiple playbooks and systems. Simply put: ansible logs are so much more readable thanks to Ara! Wish list? Perhaps better integration with AWX/Tower or Jenkins, though you can already to that. Maybe improved authentication and authorization for enterprise space? That's something Tower excels at, so perhaps a tower integration would solve that. Also, documenting how to use ARA with molecule - using raw_env_vars ANSIBLE_CALLBACK_PLUGINS. There are a few magical tools (ara, molecule, ansbile-lint) that make life so much easier. I think the biggest item on my wish list would be awareness. Perhaps even inclusion in the documentation and official Red Hat material, such as DO447 - Ansible Best Practices :-). Thanks for developing Ara, and Happy New Year! |
+1 we are already an AWX shop. Having defined and documented way of running ARA alongside AWX would be a big help and get those people who might dread having to support them as totally different/side-by-side. |
I use ARA a lot at customers sites, when they don't want the complexity of Tower or AWX, but must be able to have some playbook insights. But with the newer versions of ARA ( |
|
This comment has been minimized.
This comment has been minimized.
I am trying to use ARA 1.x to talk to multiple Ansible server. |
|
ARA 0.x Using it to show detailed results of tasks in bigger plays mostly during development of modules, plugins, playbooks, etc... Its really nice to use the web UI rather than scrolling through a terminal mess especially on larger plays with many hosts. I'd switch to 1.x, but there isn't the detail task results. There was a WIP change on opendev I believe, but I can't find it now. I'd help code it, but just don't have enough time to learn react/patternfly |
This comment has been minimized.
This comment has been minimized.
Hi David, being relatively new to ansible, I just ran into ARA few days ago and this is really a very very nice tool. I'm currently doing an evaluation as we plan to use it in several customer automation projects where ansible playbooks will be kicked from ansible tower using the tower API to launch the jobs from a high level workflow...and the whole platform runs on OpenShift4.x. So here is my wish list (some may already be available from u or others as I've not yet completely finalised my eval. and if not we'll come-up with our own implementation of the missing parts)
I'm actually listing here the features I think I can already get, just in case I've been too optimistic or wrong in my eval:
Finally, I'm not sure yet if we can get the following points out of the box (but there are not absolutely mandatory for us to decide/start) using ARA but would be nice to have:
Thx again for writing such great tools and sorry for the length of this post. |
This comment has been minimized.
This comment has been minimized.
David, thx for you comprehensive answer, I've been quite overwhelmed these days and will put back focus on this in the coming weeks. |
@dmsimard I'm not sure if it will be recorded, I'm in the Ansible room, which is not one of the main rooms. But my sheets will be online, next week (after CfgMgmtCamp) at https;//speakerdeck.com/tonk NTW: On RHEL8/CentOS8 it works out of the box. Checked this last week. |
We are using 0.x in production and just switched over to 1.x in nonprod. Our main use is to surface detailed results of failed playbook runs by linking to the ARA UI from our automated failure notifications. Secondarily it's useful any time we want to look at historical playbook results or timing, e.g. to see the detailed return from a particular module without rerunning the playbook with more verbosity. I can't think of any features that we're missing; it slots nicely into our tooling and (apart from needing to pin django and tzlocal to older versions) 1.x was fairly painless to install on Amazon Linux 2. |
Using 1.4 now in dev and production stages. Only using the API server and its built-in user interface since the 'ara-web' had fallen behind in feature parity when I was using 1.3. The ansible runs as part of our initialization of ec2 workloads, including AMI builds. The use-case is to have easier/faster debugging of failed tasks as part of that startup sequence. Feature Wishlist
|
ARA 1.4.3.dev27 I use it to analyse my ansible run results. I debug output from my ansible playbook and use ARA API http://<>/api/v1/playbooks/ and get my required debug messages from here. Issue in 1.5.x |
I have setup ara 1.x here because ansible is starting to gain traction and being used by other teams. Communication being a complex thing, it allows us to access logs from every run to catch recurring errors that operators encounter but don't tell us about as well as provide support when they do speak with us. It also allows our team to see whether operators adopt new features, what's used, what isn't. Having logs from scheduled runs is the cherry on top. One thing that would be nice is RBAC so we could open access to other teams which would allow them to communicate about ansible runs inside their own team. |
Hi !
In an effort to better understand what users are doing with ARA, I would be very grateful if you could answer the following questions:
The answers will be useful in determining the direction for future development.
Thank you !
The text was updated successfully, but these errors were encountered: