[RFE] Using a k8s/openshift cluster as a container-runtime environment for ansible-navigator

[anshulbehl]

ISSUE TYPE

• Feature Idea

SUMMARY

One of the key features of ansible-navigator is its ability to use execution environments, which enhances the portability of automation for Ansible users who wish to migrate their workloads to AWX/AAP without dealing with dependency management challenges.

Currently, navigator offers local execution capabilities with podman and docker as the available container runtimes. However, users who want to utilize this capability with their local podman/docker container engine must have a good understanding of these tools and install them on their local machines. Sometimes, organizational policies may prevent running container engines locally, making it difficult to fully leverage the capabilities of navigator. As a result, users may resort to using the ansible-playbook CLI instead.

Given the increasing popularity and adoption of Kubernetes/OpenShift, along with the fact that a single Kubernetes cluster can serve multiple users within an organization, it becomes a compelling use case for navigator to interface with Kubernetes/OpenShift. The concept of users pointing navigator to a cluster in the settings and utilizing an Execution Environment (EE) accessible to that cluster to execute Ansible workloads provides significant benefits for playbook writers to test their Ansible content effectively.

As an AAP admin for the organization, I can provide playbook writers with instructions to configure navigator to connect to a local Kubernetes cluster. This allows them to interact with ansible-navigator in the same way they were accustomed to with the ansible-playbook CLI. This approach promotes the adoption of execution environments, eliminates the need to manage Python virtual environments in Ansible Tower, and paves the way for users to take advantage of new capabilities provided by the Ansible Automation Platform.

This is particularly beneficial for individuals using WSL 1 within the organization, as they may face limitations in migrating easily to WSL 2 and leveraging local containers. These limitations prevent them from utilizing execution environments and testing Ansible content with EE containers.

According to information from https://learn.microsoft.com/en-us/windows/wsl/tutorials/wsl-containers:

In WSL version 1, running the Docker Engine directly inside WSL was not possible due to
fundamental differences between Windows and Linux. To address this, the Docker team
developed an alternative solution using Hyper-V VMs and LinuxKit. 
However, with WSL 2 running on a Linux kernel with full system call capacity, Docker can
now run fully in WSL 2. This means that Linux containers can run natively without
emulation, resulting in better performance and improved interoperability between your
Windows and Linux tools.

[abenokraitis]

This is a great idea!

[cidrblock]

One possible approach here would be to use kubedock as a bridge between podman and k8s/os. You can find some prototype work here: https://github.com/cidrblock/dev-spaces-container

Since it's not "interactive" there going to be a bunch of the introspection work navigator does that will be broken, but basic playbook execution should work with mode set to stdout and artificat file creation disabled b/c of some EE permission issues