This is important when you have proxies in front of the service
that may have stricter timeouts, as you need at least as strict a
timeout at uwsgi to get meaningful traceback and see source of problem.
* 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>
* Bump Postgresql, Nginx and Redis versions
* pg12 --> pg13 upgrade path
* Set supported pg version as a variable to remain DRY
* Make deleting the old db data pvc after upgrade configurable
* Use labels to find the postgres pod
* backup/restore: fix postgres label selector value
We need to use the deployment_name variable for the postgres instance
name.
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
* backup/restore: add missing default supported_pg_version variable
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
* restore: update database_host fact with pg suffix
Signed-off-by: Dimitri Savineau <dsavinea@redhat.com>
Co-authored-by: Dimitri Savineau <dsavinea@redhat.com>
- Removes backup_pvc_namespace field from OLM forms
- This field has created confusion for users and there is no strong
case for needing this functionality
- Users will still be able to add it to the yaml for the CR if they
want to use it with the cluster-scoped AWX operator
- Remove unneeded advanced descriptors to avoid empty Advanced
configuration expander
fixes AAP-1176
GNU make resolves the $(wildcard ) macro when starting a block, and
caches it for the duration of the run. In order to correctly remove
namespace references from the generated helm charts, we have to split
the generation and editing into two makefile targets.
Helm should be able to set the namespace for the operator at deploy time
via the --namespace option. Use yq to remove all references to
namespaces in the helm chart prior to publishing.
Update CI process to create namespace during install.
Resolves#907
Changing bug_report from markdown to yaml
Adding config.yml for new issues
Adding Code of Conduct and support to the README (along with tags at the
top of the readme)
Adding SECURITY.md
Adding CODE_OF_CONDUCT.md
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>
* defaults in Deploying a specific version of AWX added
* Update README.md
updated the README clarified the defaults of Deploying a specific version of AWX
* added capability to set the redis container resources
* Reduce resource requests so that it can be scheduled on GitHub workflows
Co-authored-by: Cedric Morin <cedric.morin_ext@michelin.com>
Without this I was seeing:
$ make yq
tar: yq_linux_amd64: Not found in archive
tar: Exiting with failure status due to previous errors
make: *** [Makefile:240: yq] Error 2
* Load LDAP password from secret and update guideline
* Add pod_labels for custom pod labels
Signed-off-by: Loc Mai <lmai@axon.com>
* Omit tls secret if using wildcard cert
* Resolve conflicts
* Remove the ingress changes
* Remove the config changes
* Load LDAP password from secret and update guideline
* Omit tls secret if using wildcard cert
* Resolve conflicts
* Remove the ingress changes
* Remove the config changes
Co-authored-by: hungts <hungts@axon.com>
Co-authored-by: Loc Mai <lmai@axon.com>
Co-authored-by: Max Bidlingmaier <Max-Florian.Bidlingmaier@sap.com>
Co-authored-by: Max Bidlingmaier <maks@konsolan.de>
When there are e.g. multiple authenticated container registries used
we need to be able to add multiple imagePullSecrets to the k8s resource
Co-authored-by: Maximilian Meister <maximilian.meister@pm.me>
It's recommended to install the standalone version of kustomize rather
than using the version that ships with kubectl because that version is
typically very old and doesn't match the docs.
- This avoids issues with multple initContainers trying to mount the
postgres pvc at once, as is the case when there are multiple
replicas.
Signed-off-by: Christian M. Adams <chadams@redhat.com>
Otherwise, we get the too-low setting of the request, which
will be a rough experience for folks who have been using the operator
and are used to the experience of having entire underlying node capacity
Users can still set the setting via extra_settings to get the experience
of having each pod with a individualized capacity, or set a limit.
This warning originated [two years
ago](6e6cd37ce6 (diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R18)).
The API is now at `v1beta1`, so it's probably not accurate to call it
"alpha" anymore.
Since AWX and awx-operator are both OSS upstream projects, there is
implicitly no vendor support from Red Hat. The warning about support can
lead to confusion, and potentially imply that some other part of AWX is
supported, as demonstrated in a recent [twitter
thread](https://twitter.com/vwbusguy/status/1470902780311212035). When
this warning was written, the operator was self-described as an
"installation method for Ansible Tower or AWX". Since then, it appears
that the operator is focused only on upstream AWX, so that presumably
removes any need to clarify vendor support status.
I ran into a bug with this when releasing the latest version of AWX. RELATED_IMAGE_AWX always clobbers the version and does not respect `DEFAULT_AWX_VERSION`
This allows for doing stuff like this on the custom resource:
```
security_context_settings:
runAsUser: 1000
runAsGroup: 0
```
I added `snakeCaseParameters: False` because without it, variables like `runAsUser` become `run_as_user`... and that doesnt work.
* Only use them if user did not set an image, or RELATED_IMAGES_ var
is not set
Signed-off-by: Christian M. Adams <chadams@redhat.com>
(cherry picked from commit bb957be9e6)
If you `git checkout <some-released-tag>` this should just work. If you run this from the HEAD of devel, you will need to run `make docker-build docker-push` and override the appropriate image versions.
With some kubernetes clusters and settings, you might need to specify
some capabilities so the container can start. For example, the CHOWN,
SETUID and SETGID capabilties.
Setting the redis_capabilities option will add the capabilities in
the deployment.
* This increases security, the awx-operator SA has less cluster-wide
access
* This means one operator can only deploy to a single namespace
* If AWX deployments are needed in multiple namespaces, multiple
awx-operators can be deployed to accomplish this.
Signed-off-by: Christian M. Adams <chadams@redhat.com>
We hit that issue ourselves and it took us weeks until someone pointed out our error.
As it feels like this could hit other users inexperienced with kubernetes too, I propose this note.
- This prevents us from overwriting vars unintentionally at restore time
- This will make it easier to add secrets to be backed up in the future
- Add generated secret names to awx spec backup
- Fail early if secret status doesn't exist
- Skip if secret is not in spec for non-generated secrets
- Secret values must be b64 decoded before secret is created
- Cleanup temp files
This is a list of high-level changes for each release of `awx-operator`. A full list of commits can be found at `https://github.com/ansible/awx-operator/releases/tag/<version>`.
# 0.19.0 (Mar 23, 2022)
- Fix corrupted spec for the service with nodeport type (kurokobo) - dbaf64e
- Add ability to deploy with OLM & added logo (Christian Adams) - 86c31a4
- Fix backup & restore issues with special characters in the postgres password (kurokobo) - 589a375
- Use centos:stream8 container where applicable (Shane McDonald)- 12a58d7
# 0.14.0 (Oct 03, 2021)
- Starting with awx-operator 0.14.0, the project is now based on operator-sdk 1.x.
- To avoid a headache, you probably want to delete your existing operator Deployment and follow the README.
- Starting with awx-operator 0.14.0, AWX can only be deployed in the namespace that the operator exists in. See [upgrade docs](./README.md#upgrading) for necessary cleanup actions. (Christian Adams) - 58c3ebf (breaking change)
# 0.10.0 (Jun 1, 2021)
- Make tower_ingress_type to respect ClusterIP definition (Marcelo Moreira de Mello) - e37c091 (breaking_change)
- Add ability to get/create/delete secrets for the awx service account (Christian M. Adams) - 61b3cb4
- Added ability to specify annotations to ServiceAccount (Marcelo Moreira de Mello) - 446ac0b
- Do not shadow other variables (Yanis Guenane) - 223fe98
- Do not prepend variables name with tower_ (Yanis Guenane) - 75458d0 (breaking_change)
- Fully remove finalizer (Christian M. Adams) - fd92050
- Use custom pg_dump format for faster restores (Christian M. Adams) - f16d9ac
- Allow user to specify empty string for storage class on PVC (Christian M. Adams) - 818b837
- Unset ownerRefs in the installer instead of the finalizer (Christian M. Adams) - c12a1f0
- Make awx-operator compatible with Ansible 2.12 (Alan Rominger) - 5216489
- Restore: set proper kind var after deploying AWX CR (Julen Landa Alustiza) - fc4687f
- Add support for custom service labels (Jeremy Kimber) - fd42802
- Rename product specific variable names (Christian M. Adams) - 5ae3636 (breaking_change)
- Add watcher for backup CR (Christian M. Adams) - fdcc745
# 0.9.0 (May 1, 2021)
- Update playbook to allow for deploying custom image version/tag (Shane McDonald) - 77e7039
- Mounts /var/lib/awx/projects on awx-web container (Marcelo Moreira de Mello) - f21ec4d
- Extra Settings: Allow one to pass extra API configuration settings. (Yanis Guenane) - 1d14ebc
- PostgreSQL: Properly handle variable name difference when using Red Hat containers (Yanis Guenane) - 2965a90
- Deployment type: Make more fields dynamic based on that field (Yanis Guenane) - 4706aa9
- Add templated EE volume mount var to operator config (Christian M. Adams) - e55d83f
- Add NodePort to tower_ingress_type enum (TheStally) - 96b878f
- Update playbook to allow for deploying custom image version/tag (Shane McDonald) - 77e7039
- Mounts /var/lib/awx/projects on awx-web container (Marcelo Moreira de Mello) - f21ec4d
- Extra Settings: Allow one to pass extra API configuration settings. (Yanis Guenane) - 1d14ebc
- PostgreSQL: Properly handle variable name difference when using Red Hat containers (Yanis Guenane) - 2965a90
- Deployment type: Make more fields dynamic based on that field (Yanis Guenane) - 4706aa9
- Add templated EE volume mount var to operator config (Christian M. Adams) - e55d83f
- Add NodePort to tower_ingress_type enum (TheStally) - 96b878f
- Split container image and version in 2 variables (Marcelo Moreira de Mello) - bc34758 (breaking_change)
- Handles deleting and recreating statefulset and deployment when needed (Marcelo Moreira de Mello) - 597356f
- [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.
[](https://docs.ansible.com/ansible/latest/community/code_of_conduct.html)
An [Ansible AWX](https://github.com/ansible/awx) operator for Kubernetes built with [Operator SDK](https://github.com/operator-framework/operator-sdk) and Ansible.
# Table of Contents
The AWX Operator is meant to be deployed in your Kubernetes cluster(s) and can be used to install and manage the lifecycle of an AWX instance in the same namespace.
<!--ts-->
* [AWX Operator](#awx-operator)
* [Table of Contents](#table-of-contents)
* [Purpose](#purpose)
* [Usage](#usage)
* [Basic Install](#basic-install)
* [Admin user account configuration](#admin-user-account-configuration)
* [Network and TLS Configuration](#network-and-tls-configuration)
This operator is meant to provide a more Kubernetes-native installation method for AWX via an AWX Custom Resource Definition (CRD).
> :warning: The operator is not supported by Red Hat, and is in **alpha** status. For now, use it at your own risk!
## Usage
### Basic Install
This Kubernetes Operator is meant to be deployed in your Kubernetes cluster(s) and can manage one or more AWX instances in any namespace.
For testing purposes, the `awx-operator` can be deployed on a [Minikube](https://minikube.sigs.k8s.io/docs/) cluster. Due to different OS and hardware environments, please refer to the official Minikube documentation for further information.
Now you need to deploy AWX Operator into your cluster. Start by going to https://github.com/ansible/awx-operator/releases and making note of the latest release. Replace `<TAG>` in the URL `https://raw.githubusercontent.com/ansible/awx-operator/<TAG>/deploy/awx-operator.yaml` with the version you are deploying.
customresourcedefinition.apiextensions.k8s.io/awxs.awx.ansible.com created
customresourcedefinition.apiextensions.k8s.io/awxbackups.awx.ansible.com created
customresourcedefinition.apiextensions.k8s.io/awxrestores.awx.ansible.com created
clusterrole.rbac.authorization.k8s.io/awx-operator created
clusterrolebinding.rbac.authorization.k8s.io/awx-operator created
serviceaccount/awx-operator created
deployment.apps/awx-operator created
```
Wait a few minutes and you should have the `awx-operator` running.
```bash
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
awx-operator-7dbf9db9d7-z9hqx 1/1 Running 0 50s
```
Then create a file named `awx-demo.yml` with the suggested content. The `metadata.name` you provide, will be the name of the resulting AWX deployment. 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
ingress_type:none
hostname:awx-demo.example.com
```
Finally, use `kubectl` to create the awx instance in your cluster:
```bash
$ kubectl apply -f awx-demo.yml
awx.awx.ansible.com/awx-demo created
```
After a few minutes, the new AWX instance will be deployed. One can look at the operator pod logs in order to know where the installation process is at. This can be done by running the following command: `kubectl logs -f deployments/awx-operator`.
```bash
$ kubectl get pods -l "app.kubernetes.io/managed-by=awx-operator"
NAME READY STATUS RESTARTS AGE
awx-demo-77d96f88d5-pnhr8 4/4 Running 0 3m24s
awx-demo-postgres-0 1/1 Running 0 3m34s
$ kubectl get svc -l "app.kubernetes.io/managed-by=awx-operator"
Once deployed, the AWX instance will be accessible by the command `minikube service awx-demo-service --url`.
By default, the admin user is `admin` and the password is available in the `<resourcename>-admin-password` secret. To retrieve the admin password, run `kubectl get secret <resourcename>-admin-password -o jsonpath="{.data.password}" | base64 --decode`
You just completed the most basic install of an AWX instance via this operator. Congratulations!!!!
For an example using the Nginx Controller in Minukube, don't miss our [demo video](https://asciinema.org/a/416946).
| admin_email | Email of the admin user | test@example.com |
| admin_password_secret | Secret that contains the admin user password | Empty string |
> :warning: **admin_password_secret must be a Kubernetes secret and not your text clear password**.
If `admin_password_secret` is not provided, the operator will look for a secret named `<resourcename>-admin-password` for the admin password. If it is not present, the operator will generate a password and create a Secret from it named `<resourcename>-admin-password`.
To retrieve the admin password, run `kubectl get secret <resourcename>-admin-password -o jsonpath="{.data.password}" | base64 --decode`
The secret that is expected to be passed should be formatted as follow:
```yaml
---
apiVersion:v1
kind:Secret
metadata:
name:<resourcename>-admin-password
namespace:<target namespace>
stringData:
password:mysuperlongpassword
```
### Network and TLS Configuration
#### Service Type
If the `service_type` is not specified, the `ClusterIP` service will be used for your AWX Tower service.
The `service_type` supported options are: `ClusterIP`, `LoadBalancer` and `NodePort`.
The following variables are customizable for any `service_type`
| loadbalancer_protocol | Protocol to use for Loadbalancer ingress | http |
| loadbalancer_port | Port used for Loadbalancer ingress | 80 |
```yaml
---
spec:
...
service_type:LoadBalancer
loadbalancer_protocol:https
loadbalancer_port:443
loadbalancer_annotations:|
environment: testing
service_labels:|
environment: testing
```
When setting up a Load Balancer for HTTPS you will be required to set the `loadbalancer_port` to move the port away from `80`.
The HTTPS Load Balancer also uses SSL termination at the Load Balancer level and will offload traffic to AWX over HTTP.
#### Ingress Type
By default, the AWX operator is not opinionated and won't force a specific ingress type on you. So, when the `ingress_type` is not specified, it will default to `none` and nothing ingress-wise will be created.
The `ingress_type` supported options are: `none`, `ingress` and `route`. To toggle between these options, you can add the following to your AWX CRD:
* None
```yaml
---
spec:
...
ingress_type:none
```
* Generic Ingress Controller
The following variables are customizable when `ingress_type=ingress`. The `ingress` type creates an Ingress resource as [documented](https://kubernetes.io/docs/concepts/services-networking/ingress/) which can be shared with many other Ingress Controllers as [listed](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/).
| route_tls_secret | Secret that contains the TLS information | Empty string |
```yaml
---
spec:
...
ingress_type:route
route_host:awx-demo.example.com
route_tls_termination_mechanism:Passthrough
route_tls_secret:custom-route-tls-secret-name
```
### Database Configuration
#### External PostgreSQL Service
In order for the AWX instance to rely on an external database, the Custom Resource needs to know about the connection details. Those connection details should be stored as a secret and either specified as `postgres_configuration_secret` at the CR spec level, or simply be present on the namespace under the name `<resourcename>-postgres-configuration`.
The secret should be formatted as follows:
```yaml
---
apiVersion:v1
kind:Secret
metadata:
name:<resourcename>-postgres-configuration
namespace:<target namespace>
stringData:
host:<external ip or url resolvable by the cluster>
port:<external port, this usually defaults to 5432>
database:<desired database name>
username:<username to connect as>
password:<password to connect with>
sslmode:prefer
type:unmanaged
type:Opaque
```
> It is possible to set a specific username, password, port, or database, but still have the database managed by the operator. In this case, when creating the postgres-configuration secret, the `type: managed` field should be added.
**Note**: The variable `sslmode` is valid for `external` databases only. The allowed values are: `prefer`, `disable`, `allow`, `require`, `verify-ca`, `verify-full`.
#### Migrating data from an old AWX instance
For instructions on how to migrate from an older version of AWX, see [migration.md](./docs/migration.md).
#### Managed PostgreSQL Service
If you don't have access to an external PostgreSQL service, the AWX operator can deploy one for you along side the AWX instance itself.
The following variables are customizable for the managed PostgreSQL service
**Note**: The `image` and `image_version` are intended for local mirroring scenarios. Please note that using a version of AWX other than the one bundled with the `awx-operator` is **not** supported. For the default values, check the [main.yml](https://github.com/ansible/awx-operator/blob/devel/roles/installer/defaults/main.yml) file.
#### Privileged Tasks
Depending on the type of tasks that you'll be running, you may find that you need the task pod to run as `privileged`. This can open yourself up to a variety of security concerns, so you should be aware (and verify that you have the privileges) to do this if necessary. In order to toggle this feature, you can add the following to your custom resource:
```yaml
---
spec:
...
task_privileged:true
```
If you are attempting to do this on an OpenShift cluster, you will need to grant the `awx` ServiceAccount the `privileged` SCC, which can be done with:
Again, this is the most relaxed SCC that is provided by OpenShift, so be sure to familiarize yourself with the security concerns that accompany this action.
#### Containers Resource Requirements
The resource requirements for both, the task and the web containers are configurable - both the lower end (requests) and the upper end (limits).
To upgrade AWX, it is recommended to upgrade the awx-operator to the version that maps to the desired version of AWX. To find the version of AWX that will be installed by the awx-operator by default, check the version specified in the `image_version` variable in `roles/installer/defaults/main.yml` for that particular release.
Apply the awx-operator.yml for that release to upgrade the operator, and in turn also upgrade your AWX deployment.
The AWX Operator documentation is available at <https://ansible.readthedocs.io/projects/awx-operator/>
> Helm chart documentation is available at <https://ansible-community.github.io/awx-operator-helm/>
If everything works, commit the updated version, then [publish a new release](https://github.com/ansible/awx-operator/releases/new) using the same version you used in `ansible/group_vars/all`.
After creating the release, [this GitHub Workflow](https://github.com/ansible/awx-operator/blob/devel/.github/workflows/release.yaml) will run and publish the new image to quay.io.
The development environment consists of running an [`up.sh`](https://github.com/ansible/awx-operator/blob/devel/up.sh) and a [`down.sh`](https://github.com/ansible/awx-operator/blob/devel/down.sh) script, which applies or deletes yaml on the Openshift or K8s cluster you are connected to. See the [development.md](https://github.com/ansible/awx-operator/blob/devel/docs/development.md) for information on how to deploy and test changes from your branch.
## Author
This operator was originally built in 2019 by [Jeff Geerling](https://www.jeffgeerling.com) and is now maintained by the Ansible Team
## Code of Conduct
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)
## Get Involved
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).
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.