Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Add awx as an embedded ansible plugin #16205
This fixes #15975
This PR builds on #16168 by adding a new EmbeddedAnsible plugin which handles running AWX.
AWX is the upstream of Ansible Tower and is distributed in a collection of containers rather than rpms.
When the role is enabled on an upstream appliance or on a development machine, we will pull the latest images, and run the containers using the same credential management system as we would in the appliance case.
The class also handles setting up the container environment required. This is mostly a ruby version of the playbook role that the AWX project uses to install the containers without all the image build and PG bits.
This allows the "fetch from the database or generate and save" behavior to be shared across different embedded ansible platforms
This will run the containers which make up AWX (https://github.com/ansible/awx) and configure our app to use that for the embedded ansible feature. This class uses the docker-api gem to communicate with the locally running docker daemon to pull and launch the containers. We use port 54321 as the host port so that this can be used seamlessly in place of ApplianceEmbeddedAnsible when ansible tower is not installed locally
When we have "localhost" in our database configuration, we have to change that to the local machine's IP on the docker NIC
This also adds stubs for all of the subclass availability in each of the specs to avoid sporadic test failures depending on the order the subclasses are evaluated for availability.
This really just assumes that a dev environment isn't multi-appliance and isn't fronted by our httpd configuration. This means that we always go to localhost, use http over https and hardcode the port and path.
This error will be raised when the containers are just started. Every API end point during the initial migration will return an html page rather than a json payload. This accounts for that specific situation by assuming if we don't get a valid json response the service is not ready to serve requests
Checked commits carbonin/manageiq@a754fa8~...b015723 with ruby 2.3.3, rubocop 0.47.1, haml-lint 0.20.0, and yamllint 1.10.0
Gaprindashvili backport details: