What's New in Tower 3: Search

October 28, 2016 by John Mitchell

Ansible-Tower-3-blog-series.png

In July, we released Ansible Tower 3. In this blog series, we will take a deeper dive into Tower changes designed to make our product simpler and easier to scale Ansible automation across your environments. In our last post, our Principal Software Engineer Matt Jones highlighted what’s new for Tower 3 notifications.

If you’d like to learn more about the release, our Director of Product Bill Nottingham wrote a complete overview of the Tower 3 updates.

Simplifying Search

Tower gives you the ability to manage the use of Ansible for an entire enterprise, allowing you to potentially manage hundreds of Playbooks and thousands of hosts in a single place. Tower also gives you the ability to audit all types of usage through its integrated activity stream, which can be verbose. One of the goals of Tower 3 was to provide a consistent and full-featured user interface for dealing with these large collections of data.

In Tower 2, searching these collections was pretty limited. You could only make a single query for a particular collection. In Tower 3, we developed and implemented a tag-based searching system throughout the app, allowing you to chain multiple queries together so that you can quickly drill down to the items you are looking for. For example, you can now look for hosts that include “web_server” in the name and have jobs that have run against them that have failed. Each tag is individually removable, so queries can be updated on the fly.

“search-tag.png"

Adding and removing search tags


Adding Labels to Job Templates

We've also added the ability to add labels to job templates. Labels act as searchable tags that provide organization to job templates. Labels added to a job template by one user are visible to other users. Labels are displayed for each job template in the job templates list and are filterable through the standard search interface.

This means you can chain queries for multiple labels together as well as chain non-label-based queries into your search (e.g., job templates whose names include “web” and have the label “production”). Labels are copied from job template to “job” at job creation time, allowing you to filter by labels on the jobs list as well.

“search.png

Filtering the job templates list by “engineering” and “process” labels


Stream Searching

One of the things I was most excited about was streamlining activity stream searching. In Tower 2, you were presented with three separate search boxes. One would allow you to filter based on if the activity was initiated by a user or was an automated system event in Tower. The other two acted as “object_one” and “object_two” filters based on how our API categorizes the data. If we look at the example activity “associated user john_doe to organization engineering,” it’s unclear if the user John Doe is “object_one” or “object_two.”

“filter.png"

Activity stream searching in Tower 2: Is user object_one or object_two?

Tower 3 makes things much simpler, giving you a high-level filter for the type of resource (“Credentials,” “Hosts,” etc.), as well as a single search box that queries both “object_one” and “object_two” with your specified terms. This search box utilizes the tag-based system mentioned previously, so chaining queries together is not a problem.

“stream.png"

Simplified activity stream searching in Tower 3


Looking Forward

We have more improvements for search slated for our next release of Tower:

  • Queries will persist in the URL bar, allowing you to share a URL with a coworker that, when clicked, will load a pre-filtered view of a collection in Tower.

  • We’re introducing set operators that make chaining complex queries more powerful. For example, instead of only being able to search the intersection of two queries, you’ll be able to search for a job template that has the labels “web” or “production.”

  • We’re working on a new input method that utilizes a colon-separated pattern that allows you to input multiple queries at once, as opposed to having to select from a dropdown of query types, then inputting each query individually.

  • We’re revamping our standard out view in job results to include the ability to show only tasks that have a specific status (“skipped,” “failed”), as well as a text-based filter for this data.

Our hope is the improvements we’ve made in Tower 3, as well as those slated for the next release, will help users quickly and easily find the things that they need to interact with in Tower.

Try the New Ansible Tower

Ansible Tower 3 is available now for anyone to try via local install, Vagrant image, or AMI. Try the latest version today.

Share:

Topics:
Ansible Tower, Tower 3


 

John Mitchell

Front End Developer, Ansible, Red Hat


rss-icon  RSS Feed

Ansible Tower by Red Hat
Ansible Fest Austin 2018
Learn About Ansible Tower