Skip to content
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

Open
dmsimard opened this issue Dec 31, 2019 · 17 comments
Open

[Meta] User survey: Are you using ARA ? What is your use case ? #103

dmsimard opened this issue Dec 31, 2019 · 17 comments
Labels

Comments

@dmsimard
Copy link
Contributor

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:

  • Are you using ARA 0.x or 1.x ?
  • What is your use case ? How are you using it ?
  • Anything on your wish list ? What improvements would you like to see ?

The answers will be useful in determining the direction for future development.

Thank you !

@dmsimard dmsimard pinned this issue Dec 31, 2019
@dmsimard dmsimard added the meta label Dec 31, 2019
@crivetimihai
Copy link

crivetimihai commented Jan 1, 2020

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!

@nixfu
Copy link

nixfu commented Jan 1, 2020

+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.

@tonk
Copy link

tonk commented Jan 2, 2020

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 (nodejs, Python3 and so) installation on CentOS7 is tedious.
You need a couple of hoops to jump through. That's why I'll do a presentation at CfgMgmtCamp next February about this setup. It's called ARA on RHEL7 – Welcome to hell :-)

@TristanCacqueray
Copy link
Contributor

  • I'm using ARA 0.x with zuul to record job execution and access the result with the middleware.

  • The use-case is to investigate job behavior, in particular, look at the task complete result and see the playbook/role/task content.

  • I'd like to use ARA 1.x with zuul to centralize job execution logs and be able to query what job used what playbook or roles. Ideally, using a cli (or browser extension), i'd like to query the ARA 1.x api to get builds associated with a yaml file (e.g. a playbook or role tasks).

@dmsimard

This comment has been minimized.

@alwaysharsha
Copy link

I am trying to use ARA 1.x to talk to multiple Ansible server.
Installation doesn't seems to be straight forward i.e., (Install ARA on Ansible server and access the url outside the server needs lot of configuration)
Documentation regarding this could be improved better.

@berendt
Copy link
Contributor

berendt commented Jan 6, 2020

  • We are using ARA 1.x
  • We provide Docker images for ARA server + ARA web, this allows our customers to analyze the results of their Ansible runs in daily business (we offer packaged ceph-ansible and kolla-ansible)
  • Thanks to ARA we have a central location where all Ansible Logs are available, we also like to use it as a review of the past, we and our customers are satisfied with it as it is and it is sufficient for our needs
  • The future of ARA web is currently not clear to us, it seems not to be developed, we would appreciate a clear announcement

@nahun
Copy link

nahun commented Jan 8, 2020

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

@dmsimard

This comment has been minimized.

@fckbo
Copy link

fckbo commented Jan 14, 2020

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.
The web UI would be used by admins and developers performing playbook debugging, and using the ARA API, results might also be embedded in the mgt ui of our application for day 2 staff. We would also use it in our devops tool chain as part of integration test.

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)

  • [packaging]Package ARA server/API in docker image
  • [deployment]Have an Helm chart or/and an operator to deploy it with postgresql on Openshift
  • [packaging]Package the ARA http client in a separate package (I actually just quickly did an alpha version of the http client to run it on python 2.7 with my very limited python skills.) but need it for python 3.x.

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:

  • ARA Can work with playbooks launched using ansible-playbook command line & Ansible Tower
  • ARA can be setup to use a postgresql or mysql DBs
  • ARA API can be used to retrieve playbook results and display status information down to the task level in our own application for use case where the provided web client would not be used or/and when using it in our automatic integration tests.
  • ARA API could rely on external LDAP for authentication as it relies on Django which itself can be setup to use an external LDAP.

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:

  • Possibility to filter playbook executions from various "sources" either playbooks ran on different platforms all pointing to the same ARA server or playbooks ran in different organisations in ansible tower or both

  • Possibility to scale and make ARA more resilient with several API servers and a load balancer in the front and a DB cluster in the back-end.

  • Possibility to have RBAC on the results to provide access to only a subset of playbooks execution results depending on which groups the user belongs to or role he may have.

Thx again for writing such great tools and sorry for the length of this post.

@dmsimard

This comment has been minimized.

@fckbo
Copy link

fckbo commented Jan 27, 2020

David, thx for you comprehensive answer, I've been quite overwhelmed these days and will put back focus on this in the coming weeks.

@tonk
Copy link

tonk commented Jan 27, 2020

@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.

@flowerysong
Copy link
Contributor

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.

@zswanson
Copy link

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

  • oauth2, saml, etc so that I can integrate with and require my SSO identity provider
  • built-in scheduled cleanups (either by max age or max size of the data records) of old data rather than requiring something external such as a cron job

@kalyanbhonagiri16
Copy link

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
Once i upgraded to 1.5.x my automation failed as the API output json has been changed. I would appreciate if the changes to API are trivial

@bendem
Copy link
Contributor

bendem commented Sep 28, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests