Be sure to check out the Discussions > Help category for the latest answers.
The project undertook some serious remodeling, but rest assured, your definitions will still work as they did in the previous version of cloudera-deploy.
Okay, but where did everything go? Well...
-
The
quickstart.shmigrated toansible-navigator. Both of these applications use a container based onansible-runner, i.e.cldr-runner, to execute the playbooks, yetansible-navigatoris configuration-driven and better aligned with how AWX runs Ansible in containers. Also,ansible-navigatorbrings a nifty text-based UI (TUI) and the ease of use to handle different execution modes.We also migrated
cldr-runnerto useansible-builder, but you can read more about that effort at thecldr-runnerproject. -
The original
cloudera-deployplaybooks moved intocloudera.exe. Starting with Ansible2.11, collections can contain playbooks. We call the playbooks usingimport_playbooklike roles.[!IMPORTANT] If you are developing your own project playbooks, you must first set up your
cloudera-deployvariables before calling the playbooks by running thecloudera.exe.init_deploymentrole. -
The runlevels still remain; you can still use
-t infrafor example. However, the playbooks themselves are more granular and overall set up and tear down processes are now separate playbooks.This change promotes composibility and reusability, and we are going to continue to break apart the functions and operations within
cloudera-deployand -- most importantly -- the collections that drive this application. We fully expect that you will want to adapt and create your own "deploy" application, one that caters to your needs and operating parameters. Switching to a more granular, more modular approach is key to this objective.
See the Migration V1 document for details.
Each example is configured to save execution runs in the project's runs directory. You can reload a run by using the replay command:
ansible-navigator replay runs/<playbook name>-<timestamp>.jsonThen you can use the UI to review the plays, tasks, and inventory for the previous run!
The various filters, like subnet_filter, loadbalancer_subnets_filter, etc., use JMESPath expressions against a list of subnet objects. Using expression like:
[?contains(subnetName,`pvt`)] | [:1]
will limit the list of subnet objects to those with the term pvt and then select the first element of that reduced list.
You can test sample filters using this example on the JMESPath Playground (link goes to a preloaded playground):
[
{
"availabilityZone": "us-east-2c",
"cidr": "10.10.64.0/19",
"subnetId": "subnet-0123",
"subnetName": "sbnt-pub-2"
},
{
"availabilityZone": "us-east-2a",
"cidr": "10.10.0.0/19",
"subnetId": "subnet-1234",
"subnetName": "sbnt-pub-0"
},
{
"availabilityZone": "us-east-2c",
"cidr": "10.10.160.0/19",
"subnetId": "subnet-2345",
"subnetName": "sbnt-pvt-2"
},
{
"availabilityZone": "us-east-2b",
"cidr": "10.10.128.0/19",
"subnetId": "subnet-3456",
"subnetName": "sbnt-pvt-1"
},
{
"availabilityZone": "us-east-2b",
"cidr": "10.10.32.0/19",
"subnetId": "subnet-4567",
"subnetName": "sbnt-pub-1"
},
{
"availabilityZone": "us-east-2a",
"cidr": "10.10.96.0/19",
"subnetId": "subnet-5678",
"subnetName": "sbnt-pvt-0"
}
]