Skip to content

Commit 1647749

Browse files
authored
Update for v2.0.0 release (#121)
* Rename public-cloud/aws/base to public-cloud/aws/datalake and update docs to point at cldr-runner documentation * Update FAQ to migrate some entries to cldr-runner and add entry for migration * Add migration document * Update image and pull policies, remove ANSIBLE_COLLECTIONS_PATHS from ansible-navigator.yml * Rename public-cloud/aws/tf to public-cloud/aws/datalake-tf * Add contributing document * Remove profile.yml and legacy readme.adoc * Update README to reflect v2 changes Signed-off-by: Webster Mudge <wmudge@cloudera.com>
1 parent 22bc22e commit 1647749

34 files changed

+538
-768
lines changed

CONTRIBUTING.md

Lines changed: 82 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,82 @@
1+
# Contributing to cloudera-deploy
2+
3+
Thank you for considering contributions to the `cloudera-deploy` project!
4+
5+
# Submitting a pull request
6+
7+
You can start work on issues that are not yet part of a [Milestone](https://github.com/cloudera-labs/cloudera-deploy/milestones) -- anything in our issue tracker that isn't assigned to a Milestone is considered the [backlog](https://github.com/cloudera-labs/cloudera-deploy/issues?q=is%3Aopen+is%3Aissue+no%3Amilestone).
8+
9+
Before you start working, please announce that you want to do so by commenting on the issue. _([Create an issue](https://github.com/cloudera-labs/cloudera-deploy/issues/new?labels=enhancement) if there isn't one yet, and you can also check out our [Discussions](https://github.com/cloudera-labs/cloudera-deploy/discussions) for ideas.)_ We try to ensure that all active work is assigned to a Milestone in order to keep our backlog accurate.
10+
11+
**When your work is ready for review, create a branch in your own forked repository from the `devel` branch and submit a pull request against `devel`, referencing your the issue.**
12+
13+
As a _best practice_, you can prefix your branches with:
14+
15+
|prefix|Description|Example|
16+
|------|-----------|-------|
17+
|`feature/`|A new feature or changes existing to existing code or documentation|`feature/update-some-params`|
18+
|`fix/`|A non-urgent bug fix|`fix/refactor-some-params`|
19+
|`hotfix/`|An urgent bug fix|`hotfix/patch-insecure-params`|
20+
21+
> [!NOTE]
22+
> :fire_extinguisher: A **hotfix** should branch from `main`. It will then be committed to both the `main` and `devel` branches.
23+
24+
# Signing your commits
25+
26+
Note that we require signed commits inline with [Developer Certificate of Origin](https://developercertificate.org/) best-practices for open source collaboration.
27+
28+
A signed commit is a simple one-liner at the end of your commit message that states that you wrote the patch or otherwise have the right to pass the change into open source. Signing your commits means you agree to:
29+
30+
```
31+
Developer Certificate of Origin
32+
Version 1.1
33+
34+
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
35+
660 York Street, Suite 102,
36+
San Francisco, CA 94110 USA
37+
38+
Everyone is permitted to copy and distribute verbatim copies of this
39+
license document, but changing it is not allowed.
40+
41+
42+
Developer's Certificate of Origin 1.1
43+
44+
By making a contribution to this project, I certify that:
45+
46+
(a) The contribution was created in whole or in part by me and I
47+
have the right to submit it under the open source license
48+
indicated in the file; or
49+
50+
(b) The contribution is based upon previous work that, to the best
51+
of my knowledge, is covered under an appropriate open source
52+
license and I have the right under that license to submit that
53+
work with modifications, whether created in whole or in part
54+
by me, under the same open source license (unless I am
55+
permitted to submit under a different license), as indicated
56+
in the file; or
57+
58+
(c) The contribution was provided directly to me by some other
59+
person who certified (a), (b) or (c) and I have not modified
60+
it.
61+
62+
(d) I understand and agree that this project and the contribution
63+
are public and that a record of the contribution (including all
64+
personal information I submit with it, including my sign-off) is
65+
maintained indefinitely and may be redistributed consistent with
66+
this project or the open source license(s) involved.
67+
```
68+
69+
(See [developercertificate.org](https://developercertificate.org/))
70+
71+
To agree, make sure to add line at the end of every git commit message, like this:
72+
73+
```
74+
Signed-off-by: John Doe <jdoe@example.com>
75+
```
76+
77+
> [!NOTE]
78+
> :rocket: TIP! Add the sign-off automatically when creating the commit via the `-s` flag, e.g. `git commit -s`.
79+
80+
# Have questions? Opinions? Comments?
81+
82+
Come find us on our [Discussions](https://github.com/cloudera-labs/cloudera-deploy/discussions)!

FAQ.md

Lines changed: 8 additions & 54 deletions
Original file line numberDiff line numberDiff line change
@@ -1,48 +1,29 @@
11
# Frequently Asked Questions
22

3+
Be sure to check out the [Discussions > Help](https://github.com/cloudera-labs/cloudera-deploy/discussions/categories/help) category for the latest answers.
4+
35
## Where did everything go?
46

57
The project undertook some serious remodeling, but rest assured, your definitions will still work as they did in the previous version of `cloudera-deploy`.
68

79
Okay, but where did everything go? Well...
810

9-
1. The `quickstart.sh` migrated to `ansible-navigator`. Both of these applications use a container based on `ansible-runner`, i.e. [`cldr-runner`](https://github.com/cloudera-labs/cldr-runner), to execute the playbooks, yet `ansible-navigator` is configuration-driven and better aligned with how AWX runs Ansible in containers. Also, `ansible-navigator` brings a nifty UI and the ease of use to handle different execution modes.
11+
1. The `quickstart.sh` migrated to `ansible-navigator`. Both of these applications use a container based on `ansible-runner`, i.e. [`cldr-runner`](https://github.com/cloudera-labs/cldr-runner), to execute the playbooks, yet `ansible-navigator` is configuration-driven and better aligned with how AWX runs Ansible in containers. Also, `ansible-navigator` brings a nifty text-based UI (TUI) and the ease of use to handle different execution modes.
1012

1113
We also migrated `cldr-runner` to use `ansible-builder`, but you can read more about that effort at the [`cldr-runner`](https://github.com/cloudera-labs/cldr-runner) project.
1214

1315
1. The original `cloudera-deploy` playbooks moved into `cloudera.exe`. Starting with Ansible `2.11`, [collections can contain playbooks](https://docs.ansible.com/ansible/latest/collections_guide/collections_using_playbooks.html#using-a-playbook-from-a-collection). We call the playbooks using `import_playbook` like roles.
1416

15-
PLEASE NOTE, if you are developing your own project playbooks, you must first set up your `cloudera-deploy` variables _before_ calling the playbooks by running the `cloudera.exe.init_deployment` role on `localhost`.
17+
> [!IMPORTANT]
18+
> If you are developing your own project playbooks, you must first set up your `cloudera-deploy` variables _before_ calling the playbooks by running the `cloudera.exe.init_deployment` role.
1619
17-
1. The _run-levels_ still remain; you can still use `-t infra` for example. However, the playbooks themselves are more granular and overall set up and tear down processes are now separate playbooks.
20+
1. The _runlevels_ still remain; you can still use `-t infra` for example. However, the playbooks themselves are more granular and overall set up and tear down processes are now separate playbooks.
1821

1922
This change promotes composibility and reusability, and we are going to continue to break apart the functions and operations within `cloudera-deploy` and -- 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.
2023

21-
## How to I add _extra variables_ and tags to `ansible-navigator`?
22-
23-
If you want to run a playbook with a given tag, e.g. `-t infra`, then simply add it as a parameter to the `ansible-navigator` commandline. For example, `ansible-navigator run playbook.yml -t infra`.
24-
25-
Like tags, so you can pass _extra variables_ to `ansible-navigator` and the underlying Ansible command. For example, `ansible-navigator run playbook.yml -e @some_config.yml -e some_var=yes`.
26-
27-
## How do I tell `ansible-navigator` where to find collections and roles?
28-
29-
By default, `cloudera-deploy` expects to use the collections, roles, and libraries within the _execution environment_ container, that is `cldr-runner`. Make sure you do _not_ have `ANSIBLE_COLLECTIONS_PATH` or `ANSIBLE_ROLES_PATH` set or `ansible-navigator` will pick up these environment variables and pass them to the running container. The underlying `ansible` application, like `ansible-playbook` will then pick up these environment variables and attempt to use them if set! This behavior is great if you want to use host-based collections, e.g. local development, but you need to ensure that you update the `ansible-navigator.yml` configuration file to mount the host collection and/or role directories into the execution environment container.
30-
31-
## `ansible-navigator` hangs when I run my playbook. What is going on?
32-
33-
`ansible-navigator` does not handle user prompts when running in the `curses` UI, so actions in your playbook like:
24+
## How do I run my `cloudera-deploy` V1 playbooks in `ansible-navigator`?
3425

35-
* Vault passwords
36-
* SSH passphrases
37-
* Debugger statements
38-
39-
will not work out-of-the-box. You can enable `ansible-navigator` to run with prompts, but doing so will also disable the UI and instead run its operations using `stdout`. Try adding:
40-
41-
```bash
42-
ansible-navigator run --enable-prompts ...
43-
```
44-
45-
to your execution.
26+
See the [Migration V1](MIGRATION_V1.md) document for details.
4627

4728
## How can I view a previous `ansible-navigator` run to debug an issue?
4829

@@ -54,14 +35,6 @@ ansible-navigator replay runs/<playbook name>-<timestamp>.json
5435

5536
Then you can use the UI to review the plays, tasks, and inventory for the previous run!
5637

57-
## How can I enable the playbook debugger?
58-
59-
The [playbook debugger](https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_debugger.html) is enabled in `ansible-navigator` by setting the debugger and then enabling prompts. For example,
60-
61-
```bash
62-
ANSIBLE_ENABLE_TASK_DEBUGGER=True ansible-navigator run --enable-prompts main.yml
63-
```
64-
6538
## How can I select just a single subnet using `subnet_filter`, say for a CDE definition?
6639

6740
The various `filters`, like `subnet_filter`, `loadbalancer_subnets_filter`, etc., use [JMESPath](https://jmespath.org/) expressions against a list of subnet objects. Using expression like:
@@ -114,22 +87,3 @@ You can [test sample filters](https://play.jmespath.org/?u=45e4d839-15f9-4569-94
11487
}
11588
]
11689
```
117-
118-
## How to I configure SSH to avoid a "Failed to connect to new control master" error?
119-
120-
When running connecting to a host via SSH while running `ansible-navigator`, in particular when you are working with Terraform inventory managed by the `cloud.terraform` inventory plugin, you might encounter the following error:
121-
122-
```
123-
Failed to connect to the host via ssh: Control socket connect(/runner/.ansible/cp/b44b170fff): Connection refused
124-
Failed to connect to new control master
125-
```
126-
127-
To resolve, be sure to add the following variable to your `ansible-navigator.yml` configuration file:
128-
129-
```yaml
130-
ansible-navigator:
131-
execution-environment:
132-
environment-variables:
133-
set:
134-
ANSIBLE_SSH_CONTROL_PATH: "/dev/shm/cp%%h-%%p-%%r"
135-
```

MIGRATION_V1.md

Lines changed: 187 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,187 @@
1+
# Migrating from V1 to V2 of `cloudera-deploy`
2+
3+
## In Summary
4+
5+
1. Don't change your `definition.yml` or `cluster.yml` files.
6+
2. Create a playbook within your project to run your setup. You can start by referencing the following:
7+
* [Public Cloud](public-cloud/aws/datalake/main.yml)
8+
* Private Cloud (coming soon!)
9+
3. Create an `ansible-navigator.yml` configuration in your project. You can start by referencing the following:
10+
* [Public Cloud](public-cloud/aws/datalake/ansible-navigator.yml)
11+
* Private Cloud (coming soon!)
12+
4. Run your playbook by using `ansible-navigator` vs. `ansible-playbook`.
13+
* All other arguments apply, so continue to use `-e` and `-t` as needed, e.g. `ansible-navigator run your_playbook.yml -e key=value -t infra,plat,another_tag`
14+
15+
## In Detail
16+
17+
So, you may ask yourself, "How do I run my `cloudera-deploy` V1 playbooks in `ansible-navigator`?" <cue [The Talking Heads](https://youtu.be/5IsSpAOD6K8?si=K4vEs-b3kvZimM5X&t=49)>
18+
19+
Previously, you would execute the `quickstart.sh` script to bootstrap the `cldr-runner` image into a shell and then run your scripts _from the container shell_, e.g. `ansible-playbook /opt/cloudera-deploy/main.yml -e "definition_path=examples/sandbox" -t run,default_cluster -vvv`. While this mode is still certainly possible, the introduction of `ansible-navigator` simplifies these action.
20+
21+
**The most significant change**: the legacy definitions only contain configuration files -- the `definition.yml`, `cluster.yml`, `application.yml`, and `inventory_*` files -- and the legacy `cloudera-deploy` has local playbooks that orchestrated the whole run by calling a "sequence" role in `cloudera.exe`... No longer!
22+
23+
So, what to do? First off...
24+
25+
**Your existing platform configurations -- `definition.yml` and `cluster.yml`, specifically -- remain as they are. No changes are needed.**
26+
27+
What does need to change?
28+
29+
**You need to provide an entrypoint playbook.**
30+
31+
Your project now needs a playbook, ala `main.yml`, to coordinate execution. This change allows for considerable flexibility as to how and when infrastructure and platform runlevels execute - frankly, how and when _any_ tasks, runlevel or otherwise, are run.
32+
33+
In short, we have moved the responsiblity of managing key sections of the "runlevel" from the `cloudera_deploy` _application_ to the project _itself_. This allows you, on a per-project basis, to define _exactly_ what you want, when you need it. Yet, you still can call on the common, shared order-of-operations for installing Cloudera Manager or spinning up a CDP Public Cloud Datalake that the legacy `cloudera-deploy` once had, rather forced you to have. A simple `ansible.builtin.import_playbook` pragma will include these _collection playbooks_ from the updated `cloudera.exe` collection.
34+
35+
Here is an example. The previous `main.yml` file eventually calls the `cloudera.exe.sequence` role, which in turn calls the _runlevel_ roles.
36+
37+
```yaml
38+
# cloudera.exe.sequence/tasks/main.yml
39+
40+
- name: Validate Infrastructure Configuration
41+
ansible.builtin.include_role:
42+
name: cloudera.exe.infrastructure
43+
tasks_from: validate
44+
# Truncated for clarity
45+
46+
- name: Validate Platform Configuration
47+
ansible.builtin.include_role:
48+
name: cloudera.exe.platform
49+
tasks_from: validate
50+
# Truncated for clarity
51+
52+
- name: Validate Runtime Configuration
53+
ansible.builtin.include_role:
54+
name: cloudera.exe.runtime
55+
tasks_from: validate
56+
# Truncated for clarity
57+
```
58+
59+
([See this file in its entirety.](https://github.com/cloudera-labs/cloudera.exe/blob/v1.7.5/roles/sequence/tasks/main.yml))
60+
61+
The _v2.x_ of `cloudera.exe` (and via proxy, `cloudera-deploy`) moves this code from the role _into_ a playbook within `cloudera.exe`.
62+
63+
Here is a _v2.x_ entrypoint playbook. It assumes that you want to handle infrastructure - say, for a sandbox install - as well as the CDP Public Cloud setup. (There is an explicit playbook to teardown.)
64+
65+
```yaml
66+
# cloudera-deploy/public-cloud/aws/datalake/main.yml
67+
68+
- name: Set up the cloudera-deploy variables
69+
hosts: localhost
70+
connection: local
71+
gather_facts: yes
72+
tasks:
73+
- name: Read definition variables
74+
ansible.builtin.include_role:
75+
name: cloudera.exe.init_deployment
76+
public: yes
77+
when: init__completed is undefined
78+
tags:
79+
- always
80+
81+
- name: Set up CDP Public Cloud infrastructure (Ansible-based)
82+
ansible.builtin.import_playbook: cloudera.exe.pbc_infra_setup.yml
83+
84+
- name: Set up CDP Public Cloud (Env and DL example)
85+
ansible.builtin.import_playbook: cloudera.exe.pbc_setup.yml
86+
```
87+
88+
And the new `cloudera.exe` playbooks?
89+
90+
```yaml
91+
# cloudera.exe/playbooks/pbc_infra_setup.yml
92+
93+
- name: Set up CDP Public Cloud infrastructure (Ansible-based)
94+
hosts: "{{ target | default('localhost') }}"
95+
environment: "{{ globals.env_vars }}"
96+
gather_facts: yes
97+
tasks:
98+
- name: Validate CDP Public Cloud infrastructure configuration
99+
ansible.builtin.import_role:
100+
name: cloudera.exe.infrastructure
101+
tasks_from: validate
102+
tags:
103+
- validate
104+
- initialize
105+
- infra
106+
107+
- name: Initialize CDP Public Cloud infrastructure setup
108+
ansible.builtin.import_role:
109+
name: cloudera.exe.infrastructure
110+
tasks_from: initialize_setup
111+
tags:
112+
- initialize
113+
- infra
114+
115+
- name: Set up CDP Public Cloud infrastructure
116+
ansible.builtin.import_role:
117+
name: cloudera.exe.infrastructure
118+
tasks_from: setup
119+
tags:
120+
- infra
121+
```
122+
123+
```yaml
124+
# cloudera.exe/playbooks/pbc_setup.yml
125+
126+
- name: Set up CDP Public Cloud
127+
hosts: "{{ target | default('localhost') }}"
128+
environment: "{{ globals.env_vars }}"
129+
gather_facts: yes
130+
tasks:
131+
- name: Validate Platform configuration
132+
ansible.builtin.import_role:
133+
name: cloudera.exe.platform
134+
tasks_from: validate
135+
tags:
136+
- validate
137+
- initialize
138+
- plat
139+
- run
140+
141+
- name: Validate Data Services configuration
142+
ansible.builtin.import_role:
143+
name: cloudera.exe.runtime
144+
tasks_from: validate
145+
tags:
146+
- validate
147+
- initialize
148+
- run
149+
150+
- name: Initialize Platform setup
151+
ansible.builtin.import_role:
152+
name: cloudera.exe.platform
153+
tasks_from: initialize_setup
154+
tags:
155+
- initialize
156+
- plat
157+
- run
158+
159+
- name: Set up Platform
160+
ansible.builtin.import_role:
161+
name: cloudera.exe.platform
162+
tasks_from: setup
163+
tags:
164+
- plat
165+
- run
166+
167+
- name: Initialize Data Services setup
168+
ansible.builtin.import_role:
169+
name: cloudera.exe.runtime
170+
tasks_from: initialize_setup
171+
tags:
172+
- initialize
173+
- run
174+
175+
- name: Set up Data Services
176+
ansible.builtin.import_role:
177+
name: cloudera.exe.runtime
178+
tasks_from: setup
179+
tags:
180+
- run
181+
```
182+
183+
You can see that instead of calling the role and passing Ansible tags, you call the playbook, which now has _the very same code_ but without the need for some of the tags or the intermediate role, `cloudera.exe.sequence`. In fact, the playbooks in `cloudera.exe` have become the `cloudera.exe.sequence` role.
184+
185+
You don't want to use the infrastructure playbook because you have your own process for establishing infrastructure? Great! Remove the `import_playbook` and call whatever is necessary! So long as you have run `cloudera.exe.init_deployment` in your project's playbook(s) _prior_ to importing any of the _collection playbooks_, you can use the collection playbooks anytime in your project playbooks.
186+
187+
Need to discuss this further? Stop by the [Discussions > Help](https://github.com/cloudera-labs/cloudera.exe/discussions/categories/help)!

0 commit comments

Comments
 (0)