What needs improvement with Red Hat Ansible Automation Platform?

Ansible's centric idea of servers needs to be changed. In modern infrastructure, there are more than just servers. The initial server-centric approach in Ansible is a bit strange. It should improve its functionality with cloud resources like Azure, AWS, or Google Cloud. Ansible could also improve its capabilities in managing several resources at the same time, similar to Terraform. Moreover, more integration with other tools would be beneficial.

There are challenges in using the graphical interface, particularly in open-source versions. The Subscription model presents some limitations, and there is room for improvement in making the Ansible navigator more flexible for open-source use. Installation can also be challenging, especially for graphical components.

There should be consistency. I know that it is always changing, but when we are trying to get some users to do something in basic Ansible that they are not really interested in doing but their job requires them to do it, they start finding inconsistencies. A good example of that is that we have people who are trying to automate things with Windows and Active Directory. There is a community version of the Windows collection that deals with Active Directory. You can use a lot of that code as it is described. It works with the certified Microsoft Active Directory collection if you take the same information because there are the same parameters and values, and the only thing that changes is the collection name. If you switch that out, it does not work, so having a new person run into a problem that even a seasoned person cannot understand does not work. It turns them off. You want them to have success early on. Sometimes in Ansible, you run into some inconsistencies that you do not understand and then you are concerned because it says, "We are going to deprecate this." You are like, "How long do I have to keep using this thing that is going to be deprecated before I have to move on to this other thing?" That just does not seem to work.

There should be better Windows support. We have had to develop a lot of our own roles because of the Windows platform. The Red Hat Enterprise Linux ones existed but not the Windows versions, so I have had to develop a bunch of Windows ones.

The web GUI can be a little bit better. There should be a couple of more features.

At this time, I do not have anything to improve. What we struggle with is the knowledge base, but that is more about us having to go and find it and learn the platform on our own rather than an actual Ansible issue.

The solution is slightly expensive, and its pricing could be improved.

The solution must be made easier to configure.

It would be good to make the solution more user-friendly for customers who aren't skilled in coding and don't know how to use the playbook's code. If we have many customers and the modules already exist, the user can just plug and play.

The solution should add a nice self-service portal. The standard single-node installation is easy. When you have a protection grade installed, and the customer wants DR, it creates a problem. For example, if you have the database built in, but the customer wants to use RDS, you have to tweak it. Then, you have to use the governance policies and everything accompanying them. Some customization takes place, but overall, it's easy if vendors use a straightforward method.

For my day-to-day operations, the one module that I am using is very good, and it is giving the intended results. Ansible has a lot of modules to perform your day-to-day activities. I don't think there will be room for improvement based on the current instances or use cases. The scalability of the solution has some shortcomings. Thus, the solution's scalability has some room for improvement.

I think some community projects support Ansible Playbooks, but they often break with version updates. It's a difficult problem to solve. DevOps should have a library with common components to make Ansible more productive when there are updates to Ansible and the operating system. What we need is model-driven, declarative software infrastructure management. However, things tend to break with new versions, requiring a lot of work to fix. It becomes a cost-benefit analysis of reusing old Ansible scripts versus rewriting them from scratch after updates. The problem is that it becomes quite fragile over time, and this fragility is a problem. If the IDE and auto-completion of the solution are based on Checkpt, it is important to ensure that the AI coding tools support writing in a more declarative way. While I have not yet tried coding with this assistance, Microsoft and Keylabs both offer AI coding assistants. The focus should be on improving the support for Ansible in the area of AI coding. It is crucial to see how well they work with the new versions of Ansible.

It would be helpful to have templates for common configurations. It would make it much easier and faster rather than creating a whole script. The templates would decrease the learning curve as well.

There are some options not available in the community edition of the solution.

The governance features could be improved.

The support could be better.

Additional features could be added.

There is always room for improvement in features or customer support.

We are just starting to use the solution. I can't speak to improvements, really. So far, I am more comfortable with this product than the previous one. Once we start using it heavily, maybe we will see issues.

The solution requires some Linux knowledge.

When compared to Terraform, the execution speed of Ansible is very slow due to the way it executes things. Improvements should be made in terms of execution speed, which is, I believe, the most lacking feature. Aside from that, re-triggering a failed task is another useful feature.

We would like support for the post-integration of this product before cloud frameworks because right now their approach is to avoid using on-premises activities and move everything to the cloud. This is why we choose Ansible, but we would like Ansible to stay as close as possible to recent trends coming through AWS, for instance. We have a chance to automate those processes by using Ansible, so there is interoperability of those products.

Some of the modules in Ansible could be a bit more mature. There is still a little room for further development. Some performance aspects could be improved, perhaps in the form of parallelism within Ansible. Also, some of the Ansible versioning or backward compatibility, or Python changes, could have been handled a little bit better. But all these challenges could potentially be offset by the way you use Ansible. For instance, you could have Ansible Docker-ized and that would make your Ansible environment fixed and static and fully controlled. That way you wouldn't be worried about your server or your local workstation that is used for deployment. These aren't huge issues, they are just things to keep in mind, but it all depends on how you use the product.

Ansible is great, but there are not many modules. You can do about 80% to 90% of things by using commands, but more modules should be added. We cannot do some of the things in Ansible. In Red Hat, we have the YUM package manager, and there are certain options that we can pass through YUM. To install the Docker Community Edition, I'll write the yum install docker-ce command, but because the Docker Community Edition is not compatible with RHEL 8, I will have to use the nobest option, such as yum install docker-ce --nobest. The nobest option installs the most stable version that can be installed on a particular system. In Ansible, the nobest option is not there. So, it needs some improvements in terms of options. There should be more options, keywords, and modules.

The area which I feel can be improved is the custom modules. For example, there are something like 106 official modules available in the Ansible library. A year ago, that number was somewhere around 58. While Ansible is improving day by day, this can be improved more. For instance, when you need to configure in the cloud, you need to write up a module for that.

When you set up Playbooks, I may have one version of the Playbook, but another member of the team may have a different vision, and we will not know which version is correct. We want to have one central repository for managing the different versions of Playbooks, so we can have better collaboration among team members. This is our use case for using Git version control. Collaboration across teams is a great goal to accomplish, but that would necessitate more visibility to other teams of what Ansible is capable of with the database teams and other individual applications. Because we have so many applications, I don't know if they are aware of how Ansible could be beneficial to them. That would necessitate a broader conversation within the IT infrastructure application teams. While it saves time with fewer moves, there could be still room for improvement because we do not actually manage the VMs. Instead, this is managed by the Windows team, who spins up the VM. Then, once the VM is handed off, we do the security hardening. If we received the request from the application owner to spin up the VM to hand it off, then we could take that entire process and get it streamlined. Whereas, it is handled by a different team right now. It would be great if we could leverage Ansible Tower and Red Hat Satellites more. API integration would help because right now our security team uses Splunk, and they are independent of my team, which is the Unix team. Therefore, if we could tie in Splunk with products, like Ansible, Cylance, and Rubrik for backup, then we could get all that information in a central console. We have not previously raised this suggestion because our Ansible Engine needs to be upgraded so we can get support for the Ansible product.

* Accessibility. Ansible uses a CLI by default. Those accustomed to it can find their way and adopt the YAML files easily over time. But, some users are more comfortable using UIs. * Ansible Tower's upstream project, Ansible AWX provides a web UI. But, it can be improved to make it more user-friendly. * Overall, the learning curve could benefit from an easy to use UI. * Network gear support is still not that great but evolving. We definitely would like to see a general direction towards those. Especially since there are so many vendors and managing them all from the same platform is a rare plus. * For Windows, support is getting better, too.

Error codes are not very descriptive.

For Ansible Tower, there are three tiers with ten nodes. I would like them to expand those ten nodes to 20, because ten nodes is not enough to test on. It needs better documentation when setting it up. It is not very clearly stated how exactly to set up Ansible Tower, though it is pretty self-explanatory.

Some of the module documentation could be better, but I don't know if that's Red Hat Ansible's fault. Specifically, I've done a lot of Palo, and I've done some Cisco ACI. The Cisco ACI, I don't know who actually produces those particular modules, whether it's Cisco or the community. Also, it is a little slow on the network side because every time you call a module, it's initiating an SSH or an API call to a network device, and it just slows things down. For the web server guys, all the work is done on the destination server, whereas for network devices, all the work is done on Tower. And then, as I said, it's either SSH-ing or using an API call to the device. Every time you do a module, that slows it down. I heard some rumors, I don't know if they're true, that the Ansible team is looking at improving that performance. But that's hearsay, as far as I know.

We are not using the Dashboard a lot because we have higher expectations from it. The default Dashboard from Tower doesn't give that much information. We really want to get down into more than if the job succeeded or what was the percentage of success. We want to get down to task-level success. If, in a job, there are ten tasks, we want to see this task was a success, and this one was not, and how many were not. That's the kind of granularity we are looking for, that Tower does not give right now. There could be more stuff in the workflows. I hope that if I have ten templates with different services on it, workflow could auto-populate all the template-based services.

In my opinion, one thing that needs improvement is mass updates: How I can parallelize that process a little bit better? It seems right now that I run through one set of servers, and then another set of servers, and then another set of servers but I'm not sure all those checks are needed. If I could parallelize different types of servers, like web servers and DB servers, that would make everything run a little bit more efficiently.

What I would like to see is a refined Dashboard to see, when I log in: Here are all my jobs, here are how many times they've executed; some kind graphical stitching-together of the workflows and jobs, and how they're connected. Also, those "failed hosts," what does that mean? We have a problem, a failed host can be anything. Is SSH the reason it failed? Is the job template why it failed? It doesn't really distinguish that. The job workflow needs to be worked on. It's not really clear to how you actually link things together. What they probably could do is provide an example workflow on how to stitch things together. I think that would be very helpful.

On the Dashboard, when you view a template run, it shows all the output. There is a search filter, but it would be nice to able to select one server in that run and then see all that output from just that one server, instead of having to do the search on that one server and find the results. It would be nice to just be able to view per-server. Sometimes the server has some problems that we're going to find in some places. It would be nice not to have to search for them.

We'll probably use it in conjunction with Puppet, because Puppet is more a solution where every 30 minutes it's going to check, whereas as Ansible doesn't do that. You have to push, from my understanding. That's what I thought. I could be wrong.

The way it's going to improve is with the community contributing more to the platform in terms of modules that interact with different devices. And perhaps it can contribute use cases, which is something I'm very focused on: documenting and showing them to customers; not just roles but how I use those roles, how I get started. Part of my initiative, in terms of using Ansible to build Ansible, is to demonstrate how I properly structure Ansible to deploy to a server with various roles. In my case, my role works on both Red Hat and Ubuntu Debian: How do you structure it to handle multi-OS, which is something I've learned from Jeff Geerling, whom everyone knows. The power of the community is what's going to make it better. It feels like it's growing every year. It's how the community is coming together. There's a lot of enthusiasm around that and it's contagious. People are excited about it. It has really been fun being here at AnsibleFest 2018 and seeing the passion about the product.

Ansible could use more public relations and marketing.

I have seen indications that the documentation needs improvement. They are providing a "How to Improve Your Documentation" presentation at this conference.

The user interface on the Ansible Tower product could be better, but it is functional.

Documentation could be improved. Many times, if I'm looking for something, I have to Google it in a lot of places, then figure out what the best approach will be. There are some best practices documents, but they don't give you the information. If we could have more information on how to figure out the IP address or the specific host, this type of information would help. We could get started up easily.

One problem that I'm facing right now is the mismatch between the new version of Python and Ansible. Sometimes it's Python 2, and sometimes it's Python 3. When things get a bit dicey, I wish that Ansible would solve this issue by itself. I don't want to have to specify if it is Python 3 or version 2.

There has been put a heavy focus on the network, so it is getting better. Some of the Cisco modules could be expanded, which would be great, along with not having to do so much coding in the background to make it work.

For a couple of the API integrations, there has been a lack of documentation.

In Community, there's a lot of effort towards testing, standardizing, and testing for module development to role development, which is why Molecule is now becoming real. Same thing with Zuul, which we are starting to implement. Zulu tests out modules from third-party sources, like ourselves, and verifies that the modules work before they are committed to the code. Currently, Ansible can't do this with all the modules out there.

I haven't done a lot with the dashboards yet. One of the sort of difficulties on the network side is they just recently became first class citizens on the connection, so you have to do another step. However, I think now that is clearing up, and the dashboard will come into play more. From a documentation standpoint, especially on the networking side of things, things are changing rapidly, most of time for the better. However, the communication on it is not probably where it could be. We could use some real life examples where we could point customers to them and say, "This is what you are trying to do. If you follow these steps, it would at least get you started a bit quicker."

It can use some more credential types. I've found that when I go looking for a certain credential type, such as private keys, they're not really there. I end up having to either custom-make my own credential type or trying to figure out what is already available that I can fit it into and use. I would prefer to see a lot of the more popular ones included as an out-of-the-box credential type. Because, at least for our integration with Ansible Tower, we do have to put a certificate and a key into the Tower credentials and custom-make that credential type. We're not the only product that does it. I feel like if it's such an adopted method of dealing with third-party tools, maybe we should add in that credential type and make it easier for everyone.

Right now, I am trying to understand the CLI, so the originals will be easier for me to use. Once I understand the CLI, the company will move everything to Tower. The documentation for the installation step of deployment, OpenStack, etc., and these things have to be a bit more detailed. For Dell and HPE, we are creating detailed instructions on how to deploy OpenStack Undercloud and Overcloud director step-by-step with very clear and detailed description.

* How do you democratize Ansible across more engineers that don't have a large body of scripting knowledge to leverage? * Do you bring Ansible down to that common denominator, or do you bring the engineer up to some common level of scripting capabilities? I think we need to meet in the middle. We are trying to build tools which allow engineers who don't have a lot of scripting capabilities to still leverage the power of Ansible in more standardized ways without just a choose your own adventure approach. We are trying to make Ansible simpler for more engineers to be able to use and raise the level of engineering skills. We are trying to do both. Ansible could probably help here with better documentation.

There needs to be improvement in the orchestration.

Improvement is required in the GUI. Sometimes results are different on CLI.