* Add use_db_compression option for backup database dumps
Enable optional pg_dump compression (-Z 9) via use_db_compression
boolean flag. Restore auto-detects compressed (.db.gz) or
uncompressed (.db) backups for backward compatibility.
Authored By: Christian M. Adams <chadams@redhat.com>
Assisted By: Claude
* Add CRD field, CSV descriptor, and restore auto-detection for use_db_compression
Authored By: Christian M. Adams <chadams@redhat.com>
Assisted By: Claude
Quote {{ now }} in firstTimestamp and lastTimestamp to prevent
YAML parser from converting the value to a datetime object.
Assisted-by: Claude
Signed-off-by: Lucas Benedito <lbenedit@redhat.com>
Use backup_pvc for custom backup PVC name in templates
When backup_pvc is specified with create_backup_pvc: true, the PVC
template and ownerReference removal used the hardcoded default name
(deployment_name-backup-claim) instead of the user-specified name.
This caused the management pod to reference a PVC that didn't exist.
Replace backup_claim variable with backup_pvc throughout the backup
role so the resolved PVC name is used consistently in all templates.
Authored By: Adam Knochowski <aknochow@redhat.com>
Assisted By: Claude
The testing kustomization overlay still referenced the deleted
manager_auth_proxy_patch.yaml. Update to use manager_metrics_patch.yaml
and add metrics_service.yaml resource.
Ref: AAP-65254
Authored By: Christian M. Adams <chadams@redhat.com>
Assisted By: Claude
Bump operator-sdk, ansible-operator, and OPM binaries to align with
the OCP 4.20 / AAP 2.7 target. Replace the deprecated kube-rbac-proxy
sidecar (removed in operator-sdk v1.38.0) with controller-runtime's
built-in WithAuthenticationAndAuthorization for metrics endpoint
protection.
Changes:
- Makefile: operator-sdk v1.36.1 → v1.40.0, OPM v1.26.0 → v1.55.0
- Dockerfile: ansible-operator base image v1.36.1 → v1.40.0
- Remove kube-rbac-proxy sidecar and auth_proxy_* RBAC manifests
- Add metrics_auth_role, metrics_reader, and metrics_service resources
- Add --metrics-secure, --metrics-require-rbac, --metrics-bind-address
flags via JSON patch to serve metrics directly from the manager on
port 8443 with TLS and RBAC authentication
Ref: AAP-65254
Authored By: Christian M. Adams <chadams@redhat.com>
Assisted By: Claude
- Move force_drop_db from vars/main.yml to defaults/main.yml so CR spec
values are not overridden by Ansible variable precedence
- Grant CREATEDB priv to database user before DROP/CREATE and revoke
it after restore, following the containerized-installer pattern
- Omit --clean --if-exists from pg_restore when force_drop_db is true
since the database is freshly created and empty, avoiding partition
index dependency errors
Signed-off-by: Lucas Benedito <lbenedit@redhat.com>
When users specify a custom backup_pvc name, the operator now
automatically creates the PVC instead of failing with
"does not exist, please create this pvc first."
Changes:
- Add create_backup_pvc variable (default: true) to backup defaults
- Update error condition to check create_backup_pvc before failing
- Update PVC creation condition to include create_backup_pvc
- Add create_backup_pvc field to AWXBackup CRD
Users who want the previous behavior can set create_backup_pvc: false.
Add map directives for X-Trusted-Proxy and X-DAB-JW-TOKEN headers to
log the presence of these headers as trusted_proxy_present and
dab_jwt_present fields in the nginx access log.
These markers enable the detection tool (aap-detect-direct-component-access)
to identify direct API access that bypasses AAP Gateway.
Also add explicit error_log /dev/stderr warn; instead of relying on
container base image symlinks.
Part of ANSTRAT-1840: Remove direct API access to platform components.
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
AWX Operator is no longer published to OperatorHub. Remove the
publish-operator-hub GHA workflow, the hack/publish-to-operator-hub.sh
script, the OperatorHub section from the release process docs, and the
OperatorHub-specific resource list from the debugging guide.
Author: Christian M. Adams
Assisted By: Claude
The Docker daemon on ubuntu-latest runners now requires minimum API
version 1.44, causing molecule kind tests to fail during cluster
teardown.
Author: Christian M. Adams
Assisted By: Claude
The application container image is now using python3.12 so we need
to update the associated volume mount for the redirect page.
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
add the functionality to accept an annotation in the awx-cr to be able to override the default client_request_timeout value.
rh-pre-commit.version: 2.3.2
rh-pre-commit.check-secrets: ENABLED
This avoids running in to the following error when pg_restore is run as
the application db user from the db-management pod:
pg_restore: error: could not execute query: ERROR: must be member of role postgres
Command was: ALTER SCHEMA public OWNER TO postgres;
* fix: Correct the image_version conditional
When image is set and image_version is unset, the conditional is failing
due to the unset variable causes and error.
Implemented the correct conditional and added an assert to validate that
both variables are set properly when image is set.
Signed-off-by: Lucas Benedito <lbenedit@redhat.com>
* Add hacking/ directory to .gitignore as it is commonly used for dev scripts
* Add postgres_extra_settings
* Add postgres_configuration_secret checksum to DB statefulset
* Docs for postgres_extra_settings, CI coverage, and examples
---------
Co-authored-by: Christian M. Adams <chadams@redhat.com>
- Applies a pull-secret yaml file if it exists at hacking/awx-cr.yml
- The operator will look for a pull secret called
redhat-operators-pull-secret
- This makes it possible to use a private operator image on your quay.io
registry out of the box with the up.sh
- Add PULL_SECRET_FILE environment variable with default hacking/pull-secret.yml
* updating task descriptions in backup and restore roles
* Revert "Run import_auth_config_to_gateway when public_url is defined (#2064)"
This reverts commit 54293a0efb.
Set password_encryption to scram-sha-256 and re-encrypt db user passwords for FIPS compliance
(cherry picked from commit 0e76404357a77a5f773aee6e2b3a5b85d1f514b7)
Co-authored-by: Christian M. Adams <chadams@redhat.com>
feat: set api timeout to match proxy timeout
Timeout before the openshift route times out
not timing out before undercuts usefulness of our log-traceback-middleware in
django-ansible-base that logs a traceback from requests that get timed
out -- because uwsgi or gunicorn has to send the timeout signal to the
worker handling the request. Also leads to issues where requests that
envoy has already timed out are filling up queues of the workers of the
components.
Also, configure nginx to return a 503 if WSGI server doesn't respond.
Co-authored-by: Elijah DeLee <kdelee@redhat.com>
Other installer uses 3.7.1 and the file on disk is also using 3.7.1
from the rest framework directory.
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
* Add deployment type shortname for legacy API url
* Add trailing slash to legacy API url
Co-authored-by: Christian Adams <rooftopcellist@gmail.com>
---------
Co-authored-by: Christian Adams <rooftopcellist@gmail.com>
Enables users to customize client_max_body_size in Nginx conf to allow
for larger file uploads. This is useful in cases when users need to upload
large subscription manifest files.
---------
Co-authored-by: Seth Foster <fosterseth@users.noreply.github.com>
* awx.awx collection on galaxy is ooooold at this point. Releases are
paused, so point at awx collection in devel to get that new bleeding
edge hotness.
* Compare gating version against existing deployment versions and set upgradeFrom status
* Add quotes to default version
Co-authored-by: Dimitri Savineau <savineau.dimitri@gmail.com>
* docs: simplify README.md and make index.md to refer to it
* docs: change order for pages in navigation and add missing pages
* docs: fix headings to improve navigation, transform notes to admonition, fix indentation, linting issues and minor issues
* docs: merge docs for using images from private registries
* docs: add example to integrate LDAP configuration via extra_settings_files
* Apply suggestions from code review
docs: apply suggested changes
Co-authored-by: Don Naro <dnaro@redhat.com>
* docs: update the doc site url as same as the url in https://www.ansible.com/ecosystem/
* docs: minor fixes for hpa page
* docs: expand note block
* docs: apply #1904 to README.md
---------
Co-authored-by: Don Naro <dnaro@redhat.com>
When enabling debug web requests, the /var/log/tower directory needs
to exist.
Rather than just creating that directory in the container image then
create an emptyDir volume.
Closes: #1485
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
- Update role name for README.md
- Avoid the this_awx['resources'][0] is undefined in database_configuration.yml
- Add update_status variable to include or not the update_status.yml
- metrics_utility_enabled exists in CRD but not as variable
Co-authored-by: Christian Adams <chadams@redhat.com>
Sometimes a job is launched through the web api
before the instance is in a ready state. This throws
a 500 internal server error, causing CI to fail.
Adds a task to query the instances endpoint
and check that at least one control node is
in a ready state.
Signed-off-by: Seth Foster <fosterbseth@gmail.com>
* Fix bundle_ca_crt for task/web/migration
- added a new init container init-bundle-ca-trust
- added volume ca-trust-extracted to the migration job
- added volume ca-trust-extracted to the init container init-database
- removed volume bundle-ca from all follow-up containers
Update secrets.yml
We need to specify a container in environments that use sidecar injection, like in the case of istio service mesh. If the container is not specified, and a side car is injected so there are multiple containers running in the pod, this task will fail because a container was not specified in a pod with multiple containers.
Enable fallback to global settings for db-migration job scheduling (#1804)
Modified the db-migration job template to use `task_*` settings with a fallback to global AWX configurations if not specified.
The new UI depends on the locales available via ingress/locales which
is being served as static file and not via Django.
A change in the nginx.conf was already done for the dev environment
in commit ec4f10d86881389af12371f90cb75af03417d109 (AWX), but not
here.
Signed-off-by: Tom Siewert <tom.siewert@hetzner.com>
With ansible 2.9.27 (operator-sdk v1.27.0) then the rejectattr filter
returns a generator so we need to cast it to list.
The behavior doesn't exist when using a more recent operator-sdk
version like v1.34.0 (ansible-core 2.15.8) but using the list
filter on that version works too (even if not needed)
"<generator object select_or_reject at 0x7fbbf0443728>"
This is a similar issue as 80a9e8c.
TASK [Get the new resource pod information after updating resource.]
********************************
FAILED! => {"msg": "The conditional check '_new_pod['resources'] | rejectattr('metadata.deletionTimestamp', 'defined') | length' failed.
The error was: Unexpected templating type error occurred on ({% if _new_pod['resources'] | rejectattr('metadata.deletionTimestamp', 'defined') | length %} True {% else %} False {% endif %}): object of type 'generator' has no len()
This also removes the unneeded quotes on the when conditions.
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
The default paramater from the jinja map filter has been added in the
2.11.0 release.
However, the downstream ansible operator is still using ansible 2.9
with jinja 2.10.x so using the default parameter leads to the
following error:
TASK [Dump ingress tls secret names from awx spec and data into file]
********************************
The error was: jinja2.exceptions.FilterArgumentError: Unexpected
keyword argument 'default'
fatal: [localhost]: FAILED! => {
"msg": "Unexpected failure during module execution.",
"stdout": ""
}
Rather than using the default parameter with the map filter then add the
selectattr filter to get only the items with tls_secret defined and then
get the tls_secret attribute with the map filter.
This also gets rid of the when statement since we always get an empty
list when no tls_secret are present in ingress_hosts so the loop statement
will be skipped on the empty list.
Finally this changes the default value from the ingress_hosts field because
it's a list rather than a string.
https://jinja.palletsprojects.com/en/latest/templates/#jinja-filters.map
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
Ensures the list is properly rendered in readthedocs website.
Improves the documentation to build and serve the docs locally.
Co-authored-by: Florian Sey <florian.sey@neofacto.com>
- output all relevant k8s resource to file on failure
- output awx job list and job details to file on failure
- output all pod logs to file on failure
- added STORE_DEBUG_OUTPUT to enable debug output gathering
- added DEBUG_OUTPUT_DIR to control where the debug output files will be stored
- when molecule test fail in CI trigger artifact gathering
adding new variables for redhat hybrid cloud console shipping
simplifying configmap and secret setup
making pvc creation conditional on ship_target type being directory
Add postgres init container if
postgres_data_volume_init is true
This is aimed to solve the issue where users may
need to chmod or chown the postgres
data volume for user 26, which is the user
that is running postgres in the sclorg image.
For example, one can now set the follow on the AWX spec:
spec:
postgres_init_container_commands: |
chown 26:0 /var/lib/pgsql/data
chmod 700 /var/lib/pgsql/data
Deprecate postgres_init_container_resource_requirements param in favor
of postgres_resource_requirements param.
Signed-off-by: Seth Foster <fosterbseth@gmail.com>
Co-authored-by: craph <14820052+craph@users.noreply.github.com>
Co-authored-by: kurokobo <kuro664@gmail.com>
Co-authored-by: Christian M. Adams <chadams@redhat.com>
* in the sclorg Postgresql 15 image, the PGDATA directory is hardcoded
* if users were to modify this directory, they would only change the
directory the pvc is mounted to, not the directory PostgreSQL uses.
This would result in loss of data.
* switch from /var/lib/pgsql/data/pgdata to /var/lib/pgsql/data/userdata
With ansible 2.9.27 (operator-sdk v1.27.0) then the reverse filter
returns an iterator so we need to cast it to list.
The behavior doesn't exist when using a more recent operator-sdk
version like v1.34.0 (ansible-core 2.15.8) but using the list
filter on that version works too (even if not needed)
"sorted_old_postgres_pods": "<list_reverseiterator object at 0x7f539eaa5610>"
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
The metrics utility fields were configured under the statusDescriptors
section rather than specDescriptors so displaying those fields in the
UI wasn't done correctly (not under the Advanced section nor using the
correct field type).
This also changes the `metrics_utility_configmap` descriptor from
`urn:alm:descriptor:com.tectonic.ui:selector:core:v1:ConfigMap` to
`urn:alm:descriptor:io.kubernetes:ConfigMap` because the first value
doesn't work.
Finally, all metrics utility fields are only displayed (in the Advanced
section) when `metrics_utility_enabled` is enabled (not default).
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
* Change default value for postgres_data_path
/var/lib/postgresql/data/pgdata
to
/var/lib/pgsql/data/pgdata
postgres 15 uses a different location for
postgres data directory.
Fixes issue were database was not being written
to the mounted in volume, and if the postgres
container restarted, data would be lost.
Signed-off-by: Seth Foster <fosterbseth@gmail.com>
---------
Signed-off-by: Seth Foster <fosterbseth@gmail.com>
Co-authored-by: Hao Liu <44379968+TheRealHaoLiu@users.noreply.github.com>
Leave old postgres-13 volume alone in case of unforseen upgrade failure for restore purposes
User can manually delete old PVC after verifying upgrade is completed
- We cast the settings value to a string so that it would display
properly in the Openshift UI. Unfortunately, the k8s validator will no
longer allow arrays for settings values.
- This will avoid the operator changing the host value of the original
deployments postgres_configuration_secret. As it was, restores broke
the original deployment if it was still around before this change.
Signed-off-by: Christian M. Adams <chadams@redhat.com>
* Fix awx_kube_devel
* Sanitize version name for kube_dev
When in development mode, awx version may look
like 23.9.1.dev18+gee9eac15dc.d20240311
k8s job to the migration can only have
a name with alphanumeric, and '.', '-'
so we can just drop off the +
Signed-off-by: Seth Foster <fosterbseth@gmail.com>
---------
Signed-off-by: Seth Foster <fosterbseth@gmail.com>
Co-authored-by: Seth Foster <fosterbseth@gmail.com>
* bind ee_images, control_plane_ee_image and init_container_image with DEFAULT_AWX_VERSION instead of "latest"
* fix when condition on init_container_image_version check
* Use DEFAULT_AWX_VERSION for AWXMeshIngress
* Add back AWX EE latest for backward compatibility
---------
Co-authored-by: Hao Liu <44379968+TheRealHaoLiu@users.noreply.github.com>
* Upgrading to postgres:15
* Changing image from postgres to sclorg
* Handle scenario where upgrade status is not defined & correct pg tag
* Rework the upgrade logic to be more resiliant for multiple upgrades
---------
Co-authored-by: john-westcott-iv <john-westcott-iv@users.noreply.github.com>
Co-authored-by: Christian M. Adams <chadams@redhat.com>
* add descriptions and examples for awxmeshingress
* convert list to table
* add note for image
* correct minor wording issues
* apply suggested changes from code review for docs/user-guide/advanced-configuration/mesh-ingress.md
Co-authored-by: Seth Foster <fosterseth@users.noreply.github.com>
* Previously, the nginx location would match on /foo/websocket... or
/foo/api/websocket... Now, we require these two paths to start at the
root i.e. <host>/websocket/... /api/websocket/...
* Note: We now also require an ending / and do NOT support
<host>/websocket_foobar but DO support <host>/websocket/foobar. This
was always the intended behavior. We want to keep
<host>/api/websocket/... "open" and routing to daphne in case we want
to add more websocket urls in the future.
* fix: correct port number for internal receptor address
* feat: add support for ingress for awxmeshingress cr
* feat: add support for ingressroutetcp (for traefik) for awxmeshingress cr
When pod loses connection with k8s api server,
a statefulset can take a while (5 minutes) before
it is rescheduled. Deployments quicker turnaround
in this situation, which should help mesh
stability.
Signed-off-by: Seth Foster <fosterbseth@gmail.com>
The mesh role now calls
1. awx-manage provision instance to register the hop
node to the database
2. awx-manage add_receptor_address to register the
internal address
3. awx-manage add_receptor_address to register the
external address (to be used by remote nodes)
CRD expanded to include external_ipaddress and
external_hostname
external_ipaddress is added as ipaddress in the
hop node certificate
external_hostname is added as dnsname in the
hop node certificate
the mesh role now checks for is_openshift and
only creates a Route if true. Otherwise it
will use external_hostname set in the spec
file in place of Route name.
Signed-off-by: Seth Foster <fosterbseth@gmail.com>
sample are used in CI for validation test
in current implementation we only support openshift route this will not work on kind clusters correctly and having the sample is causing CI failure
* Add multi-arch image builds to makefile
* A default set of platforms is specified and will build those if var `PLATFORMS` is not specified on the CLI
* Builds containers and stores @ghcr with tag that is git commit.
* Pushes the image to quay.io/ansible with tag devel.
* Update Promote to use single build point and the multi-arch manifest
- Pulls the complete manifest containing all architectures that matches the version from ghcr
- Tag manifest with the specified version and publish to quay.io
- Tag manifest as 'latest' and publish to quay.io
Author: jon-nfc
Co-authored-by: Christian M. Adams <chadams@redhat.com>
Co-authored-by: TheRealHaoLiu
* Replace api version for deployment kind to apps/v1
* Add new multiple ingress spec and deprecate hostname and ingress_tls_secret
* Manage new ingress_hosts.tls_secret backup separately
* Fix ci molecule lint warnings and error
* Fix documentation
* Fix ingress_hosts tls_secret key being optional
* Remove fieldDependency:ingress_type:Ingress for Ingress Hosts
* Fix scenario when neither hostname or ingress_hosts is defined
---------
Co-authored-by: Guillaume Lefevre <guillaume.lefevre@agoda.com>
Co-authored-by: Seth Foster <fosterseth@users.noreply.github.com>
Co-authored-by: Christian Adams <chadams@redhat.com>
- Previously, if the flag was set to true, the bash conditional failed
because the boolean was not correctly interpreted.
- Use pg_restore return code to determine if the task should be marked as failed
Signed-off-by: Christian M. Adams <chadams@redhat.com>
- Describe checking out the tag to deploy in basic install instructions
- Also, the repo already contains a awx-demo.yml file but the doc reference awx-demo.yaml with en extra a. I remove this road block for newcomers by using same 'yml' extension everywhere.
We discovered some weird behavior observed on later Kubernetes version (OCP 4.12+)
For some reason why we apply the templates postgres resource with
```
postgres_storage_requirements:
limit: {}
requests:
storage: <x>Gi
```
the `Create Database if no database is specified` task that does the k8s apply will always think the resource is "changed" and proceed to cycle the task and web pod
This resulted in AWX pods being continuously restarted
Update postgres.yaml.j2
Rename TAG_NAME to VERSION so it's no longer ambiguous when running hack/publish-to-operator-hub.sh
Checkout awx-operator at VERSION with fetch-depth=0 so that `make print-PREV_VERSION` will be able to actually find previous tag
* Automate awx-operator publishing on operatorhub
* Use scripts from workflow branch
Previously it will use scripts from the release tag to do the release
If we have to fix up the scripts for any reason we would have to retag
This will allow us to modify the publishing script without having to retag the release.
NOTE: the commit in this PR was accidentally pushed to `devel` directly... merging this PR just for the record.
Previously it will use scripts from the release tag to do the release
If we have to fix up the scripts for any reason we would have to retag
This will allow us to modify the publishing script without having to retag the release.
- Fix indentation on one of the newer molecule files.
- Update to actions/checkout@v3 and actions/setup-python@v4 and helm/kind-action@v1.8.0.
Signed-off-by: Rick Elrod <rick@elrod.me>
* Update awx.ansible.com_awxs.yaml with rsyslog resource containers
* Update awx-operator.clusterserviceversion.yaml with x-descriptors
* Add default values in main.yml
* Template resource_requirements in web.yaml.j2 and task.yaml.j2
* feat: add HostAliases to web/task containers (fixes#646)
* feat: add HostAliases to web/task containers
* Make host_aliases display in the Operator UI
* Add default value for host_aliases and add to web deployment template
Co-authored-by: zhangpeng.zong <zhangpeng.zong@funplus.com>
Co-authored-by: Dimitri Savineau <savineau.dimitri@gmail.com>
- In some use cases, limits must be set for every container in a
cluster. To address this, we will use the task and web resource
requirements for the initContainers where applicable.
This was fixed in 6cae8df but the task/web split rebase didn't apply this
to the web deployment.
This prevents to deploy the operator when FIPS is enabled.
{"msg": "An unhandled exception occurred while running the lookup plugin
'template'. Error was a <class 'ValueError'>, original message:
[digital envelope routines: EVP_DigestInit_ex] disabled for FIPS"}
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
- rename awx_pod to awx_web_pod to better reflect intention
- update `awx_version` block to also validate awx_task_pod
- add get awx_task_pod in additional label check block (fix CI in awx repo which does not run the validate awx_version block)
- add assertion for awx_task_pod extra label
move chmod chgrp for projects_persistence to different init
default init container is the awx-ee because and unable to run command chgrp
moving it into a different init container
note this is not needed for openshift so this is conditional on is_k8s
SUPERVISOR_WEB_CONFIG_PATH is used in the old deployment for task container to reach into the web container and restart services
this is no longer possible/needed after splitting the deployment
renaming SUPERVISOR_WEB_CONFIG_PATH to SUPERVISOR_CONFIG_PATH
and setting it to the supervisor file for the container
this can still be useful to help run `supervisorctl -c $SUPERVISOR_CONFIG_PATH`
- rename scale_down vars to the new deployments since the old one no longer exists
- rename postgres.yml scale down vars as it references the old ones as well
Added the following volume mounts to the web container:
- receptor-work-signing
- receptor-ca
- work-public-key.pem
Also added these corresponding volumes to the web deployments:
- receptor-ca
- receptor-work-signing
update logic for determining if install.yml task should be run
to respect the auto_upgrade field in awx resource
conditions and expected behavior
```
auto_upgrade awx awx-web awx-task run install.yml
-------------- ----- --------- ---------- -----------------
T - - - T
F T - - F
F - T T F
F - T F T
F - F T T
F - F F T
```
* first pass, still WIP, need tolerations etc
* add tolerations that don't work bc idk
* bug hunting
* local push, still a WIP
* affinity still needs testfor to_nice_yaml, tolerations logic is working
* fixed task deployment and affinity for both
The choice for backup_source are:
- Backup CR
- PVC
This current prevents to create an AWXRestore CR with the Backup CR value
from the OLM UI.
Error "Unsupported value: "Backup CR": supported values: "CR", "PVC"" for
field "spec.backup_source".
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
The deployment_name from the AWXRestore CR doesn't requires to set a
value for this parameter.
That parameter is already required for the AWXBackup CR so it should be
the same for AWXRestore.
Creating an AWXRestore CR without deployment_name set results in a failure
during the Secrets restoration.
"reason":"FieldValueInvalid","message":"Invalid value: \\"-receptor-ca\\":
a lowercase RFC 1123 subdomain must consist of lower case alphanumeric
characters, \'-\' or \'.\', and must start and end with an alphanumeric
character (e.g. \'example.com\', regex used for validation is
\'[a-z0-9]([-a-z0-9]*[a-z0-9])?(\\\\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*\')"
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
We could let the web container terminate as usual, as there are no
reasons to keep it running as it doesn't participate in
job control. Additionally, it stops receiving traffic with the beginning
of termination
> At the same time as the kubelet is starting graceful shutdown, the
> control plane removes that shutting-down Pod from EndpointSlice (and
> Endpoints) objects where these represent a Service with a configured
> selector
@ https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination
- previously, there was no way to auto-assign a port by default
which led to conflicts with other deployments at times
- nodeport_port param can still be used to specify a port if desired
With the previous approach, not all associated (mounted) CM/Secrets
changes caused the Deployment to be rolled out, but also the Deployment
could have been rolled out unnecessary during e.g. Ingress or Service
changes (which do not require Pod restarts).
Previously existing Pod removal (state: absent) was not complete as
other pods continued to exist, but also is not needed with this commit
change due to added Pods annotations.
The added Deployment Pod annotations now cause the new ReplicaSet
version to be rolled out, effectively causing replacement of the
previously existing Pods in accordance with the deployment `strategy`
(https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#deploymentstrategy-v1-apps,
`RollingUpdate`) whenever there is a change in the associated CMs or
Secrets referenced in annotations. This implementation is quite standard
and widely used for Helm workflows -
https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments
Do not consider Pods marked for deletion when calculating tower_pod to
address replicas scale down case - where normally Pods spawned recently
are being taken for removal. As well as the case when operator kicked
off but some old replicas are still terminating.
Respect `creationTimestamp` so to make sure that the newest Pod is taken
after Deployment application, in which case multiple RS Pods (from old
RS and new RS) could be running simultaneously while the rollout is
happening.
Proper waiting is already performed earlier during Deplyment{apply: yes, wait: yes} -
e6ac874098/plugins/module_utils/k8s/waiter.py (L27).
And also not every Deployment change produces new RS/Pods. For example,
changing Deployment labels won't cause new rollout, but will cause
`until` loop to be invoked unnecessarily (when replicas=1).
There are cases when having a new Deployment may be taking above the
default timeout of 120s.
For instance, when a Deployment has multiple replicas, and each replica
starts on a separate node, and the Deployment specifies new images, then
just pulling these new images for each replica may be taking above the
default timeout of 120s.
Having the default time multiplied by the number of replicas should
provide generally enough time for all replicas to start
* Move label templates into `common` role
So that there is single source of labels management, and labels are
unified across the other roles
* Introduce `additional_labels`
* Fix paths for labels templates
* Return `additional_labels_items` as list
* Add molecule tests
- Reconfigure index file generation
- checkout gh-pages branch in promote.yaml
- fix helm-index make target
- add gh-pages folder in .gitignore
Signed-off-by: Miles Wilson <wilson.mil@icloud.com>
Co-authored-by: Hao Liu <haoli@redhat.com>
Co-authored-by: Christian Adams <rooftopcellist@gmail.com>
In order to get information during CI debugging then turning off the
no_log statement will help with non hidden output.
FAILED! => {"censored": "the output has been hidden due to the fact that
'no_log: true' was specified for this result"}
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
I had hard times to identify how to declare to include statement for a custom certifcate bundle within the Kustomize file.
The tricky part for me was to spot the option "disableNameSuffixHash: true" in order to avoid renaming the secret name with an has suffix
* Add an option to specify affinity rules for the awx pod
In some cases, you may want to use affinity rules instead of a
node selector so you can have more flexbility. For example if you want
to have "soft" rules i.e. run my pod on this node if possible otherwise
run it anywhere
* Rename `node_affinity` to `affinity`
* Maintain defaults and CSV
* Add fields validation
Co-authored-by: Olivier <oliverf1ca@yahoo.com>
`base64 --decode` prints no new line after its output, resulting in the next shell prompt starting immediately after the password. This makes copying the password difficult. Adding an `echo` at the end of the command fixes this.
Since e966e92 we're using the `no_log` variable to control the no_log
statement value.
This job will check if the no_log statements are correctly set.
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
Set the no_log default value in the CRDs and switch from hidden to
boolean in the CSV file so this can be display properly in the UI.
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
e966e92 adds the configurable no_log parameter to all CRDs (install, backup
and restore) but only once in the CSV file (for installer).
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
Support external execution nodes
- Allow receptor.conf to be editable at runtime
- Create CA cert and key as a k8s secret
- Create work signing RSA keypair as a k8s secret
- Setup volume mounts for containers to have access to the needed
Receptor keys / certs to facilitate generating the install bundle
for a new execution node
- added firewall rule, work signing and tls cert configuration to default receptor.conf
The volume mount changes in this PR fulfill the following:
- `receptor.conf` need to be shared between task container and ee container
- **task** container writes the `receptor.conf`
- **ee** consume the `receptor.conf`
- receptor ca cert/key need to be mounted by both ee container and web container
- **ee** container need the ca cert
- **web** container will need the ca key to sign client cert for remote execution node
- **web** container will need the ca cert to generate install bundle for remote execution node
- receptor work private/public key need to be mounted by both ee container and web container
- **ee** container need to private key to sign the work
- **web** container need the public key to generate install bundle for remote execution node
- **task** container need the private key to sign the work
Signed-off-by: Hao Liu <haoli@redhat.com>
Co-Authored-By: Seth Foster <fosterbseth@gmail.com>
Co-Authored-By: Shane McDonald <me@shanemcd.com>
Signed-off-by: Hao Liu <haoli@redhat.com>
Co-authored-by: Shane McDonald <me@shanemcd.com>
Co-authored-by: Seth Foster <fosterbseth@gmail.com>
When the task_resource_requirements variable has no "limits" key (which
is the default value) then the config template generation fails
----------------------------------
looking for "config.yaml.j2" at "/opt/ansible/roles/installer/templates/config.yaml.j2"
File lookup using /opt/ansible/roles/installer/templates/config.yaml.j2 as file
fatal: [localhost]: FAILED! => {
"msg": "The task includes an option with an undefined variable. The error was: the inline if-expression on line 36 evaluated to false and no else section was defined.
The error appears to be in /opt/ansible/roles/installer/tasks/resources_configuration.yml: line 30, column 3, but may
be elsewhere in the file depending on the exact syntax problem.
The offending line appears to be:
- name: Apply Resources
^ here
----------------------------------
The current condition doesn't have a else statement so the template fails
when the "limits" key isn't present.
This rewrite the current if/else statement in jinja template.
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
2022-05-24 09:29:36 -04:00
276 changed files with 12637 additions and 3825 deletions
This chart installs the AWX Operator resources configured in [this](https://github.com/ansible/awx-operator) repository.
## Getting Started
To configure your AWX resource using this chart, create your own `yaml` values file. The name is up to personal preference since it will explicitly be passed into the helm chart. Helm will merge whatever values you specify in your file with the default `values.yaml`, overriding any settings you've changed while allowing you to fall back on defaults. Because of this functionality, `values.yaml` should not be edited directly.
In your values config, enable `AWX.enable` and add `AWX.spec` values based on the awx operator's [documentation](https://github.com/ansible/awx-operator/blob/devel/README.md). Consult the docs below for additional functionality.
### Installing
The operator's [helm install](https://github.com/ansible/awx-operator/blob/devel/README.md#helm-install-on-existing-cluster) guide provides key installation instructions.
* This value is accessed by `{{ $.Release.Namespace }}` in the templates
* Acts as the default namespace for all unspecified resources
*`--create-namespace` specifies that helm should create the namespace before installing
To update an existing installation, use `helm upgrade` instead of `install`. The rest of the syntax remains the same.
## Configuration
The goal of adding helm configurations is to abstract out and simplify the creation of multi-resource configs. The `AWX.spec` field maps directly to the spec configs of the `AWX` resource that the operator provides, which are detailed in the [main README](https://github.com/ansible/awx-operator/blob/devel/README.md). Other sub-config can be added with the goal of simplifying more involved setups that require additional resources to be specified.
These sub-headers aim to be a more intuitive entrypoint into customizing your deployment, and are easier to manage in the long-term. By design, the helm templates will defer to the manually defined specs to avoid configuration conflicts. For example, if `AWX.spec.postgres_configuration_secret` is being used, the `AWX.postgres` settings will not be applied, even if enabled.
### External Postgres
The `AWX.postgres` section simplifies the creation of the external postgres secret. If enabled, the configs provided will automatically be placed in a `postgres-config` secret and linked to the `AWX` resource. For proper secret management, the `AWX.postgres.password` value, and any other sensitive values, can be passed in at the command line rather than specified in code. Use the `--set` argument with `helm install`.
| `AWX.name` | The name of the AWX resource and default prefix for other resources | `"awx"` |
| `AWX.spec` | specs to directly configure the AWX resource | `{}` |
| `AWX.postgres` | configurations for the external postgres secret | - |
# Contributing
## Adding abstracted sections
Where possible, defer to `AWX.spec` configs before applying the abstracted configs to avoid collision. This can be facilitated by the `(hasKey .spec what_i_will_abstract)` check.
## Building and Testing
This chart is built using the Makefile in the [awx-operator repo](https://github.com/ansible/awx-operator). Clone the repo and run `make helm-chart`. This will create the awx-operator chart in the `charts/awx-operator` directory. In this process, the contents of the `.helm/starter` directory will be added to the chart.
## Future Goals
All values under the `AWX` header are focused on configurations that use the operator. Configurations that relate to the Operator itself could be placed under an `Operator` heading, but that may add a layer of complication over current development.
- [Things to know prior to submitting code](#things-to-know-prior-to-submitting-code)
- [Submmiting your work](#submmiting-your-work)
- [Development](#development)
- [Testing](#testing)
- [Testing in Kind](#testing-in-kind)
- [Testing in Minikube](#testing-in-minikube)
- [Generating a bundle](#generating-a-bundle)
- [Reporting Issues](#reporting-issues)
## Things to know prior to submitting code
@@ -25,13 +28,13 @@ Have questions about this document or anything not covered here? Please file a n
## Submmiting your work
1. From your fork `devel` branch, create a new brach to stage your changes.
1. From your fork `devel` branch, create a new branch to stage your changes.
```sh
#> git checkout -b <branch-name>
```
2. Make your changes.
3. Test your changes according described on the Testing section.
4. If everylooks looks correct, commit your changes.
4. If everything looks correct, commit your changes.
```sh
#> git add <FILES>
#> git commit -m "My message here"
@@ -40,30 +43,34 @@ Have questions about this document or anything not covered here? Please file a n
**Note**: If you have multiple commits, make sure to `squash` your commits into a single commit which will facilitate our release process.
## Development
The development environment consists of running an [`up.sh`](./up.sh) and a [`down.sh`](./down.sh) script, which applies or deletes yaml on the Openshift or K8s cluster you are connected to. See the [development.md](docs/development.md) for information on how to deploy and test changes from your branch.
## Testing
This Operator includes a [Molecule](https://molecule.readthedocs.io/en/stable/)-based test environment, which can be executed standalone in Docker (e.g. in CI or in a single Docker container anywhere), or inside any kind of Kubernetes cluster (e.g. Minikube).
This Operator includes a [Molecule](https://ansible.readthedocs.io/projects/molecule/)-based test environment, which can be executed standalone in Docker (e.g. in CI or in a single Docker container anywhere), or inside any kind of Kubernetes cluster (e.g. Minikube).
You need to make sure you have Molecule installed before running the following commands. You can install Molecule with:
```sh
#> pip install 'molecule[docker]'
#> python -m pip install molecule-plugins[docker]
```
Running `molecule test` sets up a clean environment, builds the operator, runs all configured tests on an example operator instance, then tears down the environment (at least in the case of Docker).
If you want to actively develop the operator, use `molecule converge`, which does everything but tear down the environment at the end.
#### Testing in Docker
#### Testing in Kind
Testing with a kind cluster is the recommended way to test the awx-operator locally. First, you need to install kind if you haven't already. Please see these docs for setting that up:
* https://kind.sigs.k8s.io/docs/user/quick-start/
To run the tests, from the root of your checkout, run the following command:
```sh
#> molecule test -s test-local
#> molecule test -s kind
```
This environment is meant for headless testing (e.g. in a CI environment, or when making smaller changes which don't need to be verified through a web interface). It is difficult to test things like AWX's web UI or to connect other applications on your local machine to the services running inside the cluster, since it is inside a Docker container with no static IP address.
#### Testing in Minikube
```sh
@@ -137,4 +144,4 @@ Applying this template will do it. Once the CatalogSource is in a READY state, t
## Reporting Issues
We welcome your feedback, and encourage you to file an issue when you run into a problem.
We welcome your feedback, and encourage you to file an issue when you run into a problem.
We ask all of our community members and contributors to adhere to the [Ansible code of conduct](http://docs.ansible.com/ansible/latest/community/code_of_conduct.html). If you have questions or need assistance, please reach out to our community team at [codeofconduct@ansible.com](mailto:codeofconduct@ansible.com)
We welcome your feedback, questions and ideas. Here's how to reach the community.
## Forum
Join the [Ansible Forum](https://forum.ansible.com) as a single starting point and our default communication platform for questions and help, development discussions, events, and much more. [Register](https://forum.ansible.com/signup?) to join the community. Search by categories and tags to find interesting topics or start a new one; subscribe only to topics you need!
* [Get Help](https://forum.ansible.com/c/help/6): get help or help others. Please add appropriate tags if you start new discussions, for example `awx-operator` and `documentation`.
* [Posts tagged with 'awx-operator'](https://forum.ansible.com/tag/awx-operator): subscribe to participate in project-related conversations.
* [Bullhorn newsletter](https://docs.ansible.com/ansible/devel/community/communication.html#the-bullhorn) used to announce releases and important changes.
* [Social Spaces](https://forum.ansible.com/c/chat/4): gather and interact with fellow enthusiasts.
* [News & Announcements](https://forum.ansible.com/c/news/5): track project-wide announcements including social events.
For more information on the forum navigation, see [Navigating the Ansible forum](https://forum.ansible.com/t/navigating-the-ansible-forum-tags-categories-and-concepts/39) post.
## Matrix
For real-time interactions, conversations in the community happen over the Matrix protocol in the following channels:
* [#awx:ansible.com](https://matrix.to/#/#awx:ansible.com): AWX and AWX-Operator project-related discussions.
* [#docs:ansible.im](https://matrix.to/#/#docs:ansible.im): Ansible, AWX and AWX-Operator documentation-related discussions.
For more information, see the community-hosted [Matrix FAQ](https://hackmd.io/@ansible-community/community-matrix-faq).
The first step is to create a draft release. Typically this will happen in the [Stage Release](https://github.com/ansible/awx/blob/devel/.github/workflows/stage.yml) workflow for AWX and you don't need to do it as a separate step.
If you need to do an independent release of the operator, you can run the [Stage Release](https://github.com/ansible/awx-operator/blob/devel/.github/workflows/stage.yml) in the awx-operator repo. Both of these workflows will run smoke tests, so there is no need to do this manually.
After the draft release is created, publish it and the [Promote AWX Operator image](https://github.com/ansible/awx-operator/blob/devel/.github/workflows/promote.yaml) will run, which will:
There are development scripts and yaml examples in the [`dev/`](../dev) directory that, along with the up.sh and down.sh scripts in the root of the repo, can be used to build, deploy and test changes made to the awx-operator.
## Prerequisites
You will need to have the following tools installed:
* [oc](https://docs.openshift.com/container-platform/4.11/cli_reference/openshift_cli/getting-started-cli.html) (if using Openshift)
You will also need to have a container registry account. This guide uses quay.io, but any container registry will work. You will need to create a robot account and login at the CLI with `podman login` or `docker login`.
## Quay.io Setup for Development
Before using the development scripts, you'll need to set up a Quay.io repository and pull secret:
### 1. Create a Private Quay.io Repository
- Go to [quay.io](https://quay.io) and create a private repository named `awx-operator` under your username
- The repository URL should be `quay.io/username/awx-operator`
### 2. Create a Bot Account
- In your Quay.io repository, go to Settings → Robot Accounts
- Create a new robot account with write permissions to your repository
- Click on the robot account name to view its credentials
### 3. Generate Kubernetes Pull Secret
- In the robot account details, click "Kubernetes Secret"
- Copy the generated YAML content from the pop-up
### 4. Create Local Pull Secret File
- Create a file at `hacking/pull-secret.yml` in your awx-operator checkout
- Paste the Kubernetes secret YAML content into this file
- **Important**: Change the `name` field in the secret from the default to `redhat-operators-pull-secret`
- The `hacking/` directory is in `.gitignore`, so this file won't be committed to git
Example `hacking/pull-secret.yml`:
```yaml
apiVersion:v1
kind:Secret
metadata:
name:redhat-operators-pull-secret # Change this name
namespace:awx
type:kubernetes.io/dockerconfigjson
data:
.dockerconfigjson:<base64-encoded-credentials>
```
## Build and Deploy
If you clone the repo, and make sure you are logged in at the CLI with oc and your cluster, you can run:
```
export QUAY_USER=username
export NAMESPACE=awx
export TAG=test
./up.sh
```
You can add those variables to your .bashrc file so that you can just run `./up.sh` in the future.
> Note: the first time you run this, it will create quay.io repos on your fork. If you followed the Quay.io setup steps above and created the `hacking/pull-secret.yml` file, the script will automatically handle the pull secret. Otherwise, you will need to either make those repos public, or create a global pull secret on your cluster.
To get the URL, if on **Openshift**, run:
```
$ oc get route
```
On **k8s with ingress**, run:
```
$ kubectl get ing
```
On **k8s with nodeport**, run:
```
$ kubectl get svc
```
The URL is then `http://<Node-IP>:<NodePort>`
> Note: NodePort will only work if you expose that port on your underlying k8s node, or are accessing it from localhost.
By default, the usename and password will be admin and password if using the `up.sh` script because it pre-creates a custom admin password k8s secret and specifies it on the AWX custom resource spec. Without that, a password would have been generated and stored in a k8s secret named <deployment-name>-admin-password.
## Clean up
Same thing for cleanup, just run ./down.sh and it will clean up your namespace on that cluster
After cloning this repository, you must choose the tag to run:
```sh
git clone git@github.com:ansible/awx-operator.git
cd awx-operator
git tag
git checkout tags/<tag>
# For instance:
git checkout tags/2.7.2
```
If you work from a fork and made modifications since the tag was issued, you must provide the VERSION number to deploy. Otherwise the operator will get stuck in "ImagePullBackOff" state:
```sh
exportVERSION=<tag>
# For instance:
exportVERSION=2.7.2
```
Once you have a running Kubernetes cluster, you can deploy AWX Operator into your cluster using [Kustomize](https://kubectl.docs.kubernetes.io/guides/introduction/kustomize/). Since kubectl version 1.14 kustomize functionality is built-in (otherwise, follow the instructions here to install the latest version of Kustomize: <https://kubectl.docs.kubernetes.io/installation/kustomize/>)
!!! tip
If you don't have a Kubernetes cluster, you can use [Minikube](https://minikube.sigs.k8s.io/docs/) for testing purposes. See the [Minikube install docs](./creating-a-minikube-cluster-for-testing.md) for more details.
!!! note
Some things may need to be configured slightly differently for different Kubernetes flavors for the networking aspects. When installing on Kind, see the [kind install docs](./kind-install.md) for more details.
There is a make target you can run:
```sh
make deploy
```
If you have a custom operator image you have built, you can specify it with:
```sh
IMG=quay.io/$YOURNAMESPACE/awx-operator:$YOURTAG make deploy
```
Otherwise, you can manually create a file called `kustomization.yaml` with the following content:
```yaml
apiVersion:kustomize.config.k8s.io/v1beta1
kind:Kustomization
resources:
# Find the latest tag here: https://github.com/ansible/awx-operator/releases
# Set the image tags to match the git version from above
images:
- name:quay.io/ansible/awx-operator
newTag:<tag>
# Specify a custom namespace in which to install AWX
namespace:awx
```
!!! tip
If you need to change any of the default settings for the operator (such as resources.limits), you can add [patches](https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/patches/) at the bottom of your kustomization.yaml file.
Install the manifests by running this:
```sh
$ kubectl apply -k .
namespace/awx created
customresourcedefinition.apiextensions.k8s.io/awxbackups.awx.ansible.com created
customresourcedefinition.apiextensions.k8s.io/awxrestores.awx.ansible.com created
customresourcedefinition.apiextensions.k8s.io/awxs.awx.ansible.com created
serviceaccount/awx-operator-controller-manager created
role.rbac.authorization.k8s.io/awx-operator-awx-manager-role created
role.rbac.authorization.k8s.io/awx-operator-leader-election-role created
clusterrole.rbac.authorization.k8s.io/awx-operator-metrics-reader created
clusterrole.rbac.authorization.k8s.io/awx-operator-proxy-role created
rolebinding.rbac.authorization.k8s.io/awx-operator-awx-manager-rolebinding created
rolebinding.rbac.authorization.k8s.io/awx-operator-leader-election-rolebinding created
clusterrolebinding.rbac.authorization.k8s.io/awx-operator-proxy-rolebinding created
configmap/awx-operator-awx-manager-config created
service/awx-operator-controller-manager-metrics-service created
deployment.apps/awx-operator-controller-manager created
```
Wait a bit and you should have the `awx-operator` running:
Next, create a file named `awx-demo.yml` in the same folder with the suggested content below. The `metadata.name` you provide will be the name of the resulting AWX deployment.
!!! note
If you deploy more than one AWX instance to the same namespace, be sure to use unique names.
```yaml
---
apiVersion:awx.ansible.com/v1beta1
kind:AWX
metadata:
name:awx-demo
spec:
service_type:nodeport
```
!!! tip
It may make sense to create and specify your own secret key for your deployment so that if the k8s secret gets deleted, it can be re-created if needed. If it is not provided, one will be auto-generated, but cannot be recovered if lost. Read more [here](../user-guide/admin-user-account-configuration.md#secret-key-configuration).
If you are on Openshift, you can take advantage of Routes by specifying the following your spec. This will automatically create a Route for you with a custom hostname. This can be found on the Route section of the Openshift Console.
```yaml
---
apiVersion:awx.ansible.com/v1beta1
kind:AWX
metadata:
name:awx-demo
spec:
service_type:clusterip
ingress_type:Route
```
Make sure to add this new file to the list of `resources` in your `kustomization.yaml` file:
After a few minutes, the new AWX instance will be deployed. You can look at the operator pod logs in order to know where the installation process is at:
Once deployed, your AWX instance should now be reachable at `http://localhost:<assigned-nodeport>/` (in this case, `http://localhost:31006/`).
By default, the admin user is `admin` and the password is available in the `<resourcename>-admin-password` secret. To retrieve the admin password, run:
```sh
$ kubectl get secret awx-demo-admin-password -o jsonpath="{.data.password}"| base64 --decode ;echo
yDL2Cx5Za94g9MvBP6B73nzVLlmfgPjR
```
You just completed the most basic install of an AWX instance via this operator. Congratulations!!!
If you do not have an existing cluster, the `awx-operator` can be deployed on a [Minikube](https://minikube.sigs.k8s.io/docs/) cluster for testing purposes. Due to different OS and hardware environments, please refer to the official Minikube documentation for further information.
It is not required for `kubectl` to be separately installed since it comes already wrapped inside minikube. As demonstrated above, simply prefix `minikube kubectl --` before kubectl command, i.e. `kubectl get nodes` would become `minikube kubectl -- get nodes`
Let's create an alias for easier usage:
```sh
aliaskubectl="minikube kubectl --"
```
Now, you can proceed with the installation of the AWX Operator and AWX. Please refer to the [Basic Install](basic-install.md) for further instructions.
!!! tip
Once your AWX has been deployed, the AWX instance will be accessible by running:
```sh
minikube service -n awx awx-demo-service --url
```
For an example using the Nginx Ingress Controller in Minikube, don't miss our [demo video](https://asciinema.org/a/416946).
Install Kind by running the following. Refer to the [official Kind documentation](https://kind.sigs.k8s.io/docs/user/quick-start/) for more information.
**Note**: `<resourcename>` must match the `name` of the AWX object you are creating. In our example below, it is `awx`.
!!! note
`<resourcename>` must match the `name` of the AWX object you are creating. In our example below, it is `awx`.
### Old Database Credentials
@@ -34,23 +35,21 @@ metadata:
namespace: <targetnamespace>
stringData:
host: <externaliporurlresolvablebythecluster>
port: <externalport,thisusuallydefaultsto5432>
port: "<externalport,thisusuallydefaultsto5432>" # quotes are required
database: <desireddatabasename>
username: <usernametoconnectas>
password: <passwordtoconnectwith>
type: Opaque
```
> For `host`, a URL resolvable by the cluster could look something like `postgresql.<namespace>.svc.cluster.local`, where `<namespace>` is filled in with the namespace of the AWX deployment you are migrating data from.
!!! note
For `host`, a URL resolvable by the cluster could look something like `postgresql.<namespace>.svc.<cluster domain>`, where `<namespace>` is filled in with the namespace of the AWX deployment you are migrating data from, and `<cluster domain>` is filled in with the internal kubernetes cluster domain (In most cases it's `cluster.local`).
If your AWX deployment is already using an external database server or its database is otherwise not managed
by the AWX deployment, you can instead create the same secret as above but omit the `-old-` from the `name`.
In the next section pass it in through `postgres_configuration_secret` instead, omitting the `_old_`
from the key and ensuring the value matches the name of the secret. This will make AWX pick up on the existing
database and apply any pending migrations. It is strongly recommended to backup your database beforehand.
If your AWX deployment is already using an external database server or its database is otherwise not managed by the AWX deployment, you can instead create the same secret as above but omit the `-old-` from the `name`.
In the next section pass it in through `postgres_configuration_secret` instead, omitting the `_old_` from the key and ensuring the value matches the name of the secret. This will make AWX pick up on the existing database and apply any pending migrations.
It is strongly recommended to backup your database beforehand.
The postgresql pod for the old deployment is used when streaming data to the new postgresql pod. If your postgresql pod has a custom label,
you can pass that via the `postgres_label_selector` variable to make sure the postgresql pod can be found.
The postgresql pod for the old deployment is used when streaming data to the new postgresql pod. If your postgresql pod has a custom label, you can pass that via the `postgres_label_selector` variable to make sure the postgresql pod can be found.
## Deploy AWX
@@ -66,7 +65,16 @@ spec:
secret_key_secret: <resourcename>-secret-key
...
```
### Exclude postgreSQL tables during migration (optional)
Use the `pg_dump_suffix` parameter under `AWX.spec` to customize the pg_dump command that will execute during migration. This variable will append your provided pg_dump parameters to the end of the 'standard' command. For example, to exclude the data from 'main_jobevent' and 'main_job' to decrease the size of the backup use:
When the operator is deploying AWX, it is running the `installer` role inside the operator container. If the AWX CR's status is `Failed`, it is often useful to look at the awx-operator container logs, which shows the output of the installer role. To see these logs, run:
Create a playbook that invokes the installer role (the operator uses ansible-runner's role execution feature):
```yaml
# run.yml
---
- hosts:localhost
roles:
- installer
```
Create a vars file:
```yaml
# vars.yml
---
ansible_operator_meta:
name:awx
namespace:awx
set_self_labels:false
update_status:false
service_type:nodeport
```
The vars file will replace the awx resource so any value that you wish to over ride using the awx resource, put in the vars file. For example, if you wish to use your own image, version and pull policy, you can specify it like below:
To uninstall an AWX deployment instance, you basically need to remove the AWX kind related to that instance. For example, to delete an AWX instance named awx-demo, you would do:
```sh
$ kubectl delete awx awx-demo
awx.awx.ansible.com "awx-demo" deleted
```
Deleting an AWX instance will remove all related deployments and statefulsets, however, persistent volumes and secrets will remain. To enforce secrets also getting removed, you can use `garbage_collect_secrets: true`.
!!! note
If you ever intend to recover an AWX from an existing database you will need a copy of the secrets in order to perform a successful recovery.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.