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 so that users can intentially set it to an empty string if they want to use the default storage class
* conversely, now users can manually create a pvc that does not utilize the default storage class
- renamed some more variables to be consistent with the pulp-operator
- removed unneeded vars from backup & restore crds
- added a way to parse spec at restore time by including vars to
get around the issue of triply nested quotes when using to_json
- set migrate data status even if custom name for old postgres config is not used
- Allow users to change pg name, pw & db name for a managed postgres
- set default value for postgres-configuration type as unmanaged if secret is created
- Make pg port configurable for managed deployments
For more advanced usage, a user can do the
extra_volumes/extra_volume_mounts dance. But for simple need adding this
parameter make it easy to just specify an extra parameter.
Currently the file is inacurrate and yaml parsing would fail on line 166
with
> syntax error: expected <block end>, but found '<block mapping start>'
(syntax)
This is the full implementation of the OpenAPI schema that maps to the
currently existing roles defaults variable.
Prior to this commit, all variables specified at the spec level that
didn't have an entry in the OpenAPI schema at the CRD level were simply
ignored, unless --validate=false was specified.
This commit fixes that and provide a mapping between the CRD level
OpenAPI schema and the variables availabe in <roles>/defaults/main.yml.
This commit is simply about ensuring one can provide all the available
variables. A follow up commit will come to add logic in the OpenAPI
schema definition as it can be shown here[1]
[1]
https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema
If a user provide its own secret by using the
`tower_postgres_configuration_secret` use this variable, else try to use
`<instance>-postgres-configuration` secret. Else create one and use a
local database.
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
- 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
Hi there! We're excited to have you as a contributor.
Have questions about this document or anything not covered here? Please file a new at [https://github.com/ansible/awx-operator/issues](https://github.com/ansible/awx-operator/issues).
- [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
- All code submissions are done through pull requests against the `devel` branch.
- All PRs must have a single commit. Make sure to `squash` any changes into a single commit.
- Take care to make sure no merge commits are in the submission, and use `git rebase` vs `git merge` for this reason.
- If collaborating with someone else on the same branch, consider using `--force-with-lease` instead of `--force`. This will prevent you from accidentally overwriting commits pushed by someone else. For more information, see https://git-scm.com/docs/git-push#git-push---force-with-leaseltrefnamegt
- 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)
## Submmiting your work
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 everything looks correct, commit your changes.
```sh
#> git add <FILES>
#> git commit -m "My message here"
```
5. Create your [pull request](https://github.com/ansible/awx-operator/pulls)
**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://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
#> 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 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 kind
```
#### Testing in Minikube
```sh
#> minikube start --memory 8g --cpus 4
#> minikube addons enable ingress
#> molecule test -s test-minikube
```
[Minikube](https://kubernetes.io/docs/tasks/tools/install-minikube/) is a more full-featured test environment running inside a full VM on your computer, with an assigned IP address. This makes it easier to test things like NodePort services and Ingress from outside the Kubernetes cluster (e.g. in a browser on your computer).
Once the operator is deployed, you can visit the AWX UI in your browser by following these steps:
1. Make sure you have an entry like `IP_ADDRESS example-awx.test` in your `/etc/hosts` file. (Get the IP address with `minikube ip`.)
2. Visit `http://example-awx.test/` in your browser. (Default admin login is `test`/`changeme`.)
Alternatively, you can also update the service `awx-service` in your namespace to use the type `NodePort` and use following command to get the URL to access your AWX instance:
```sh
#> minikube service <serviceName> -n <namespaceName> --url
```
## Generating a bundle
> :warning: operator-sdk version 0.19.4 is needed to run the following commands
If one has the Operator Lifecycle Manager (OLM) installed, the following steps is the process to generate the bundle that would nicely display in the OLM interface.
Applying this template will do it. Once the CatalogSource is in a READY state, the bundle should be available on the OperatorHub tab (as part of the custom CatalogSource that just got added)
5. Enjoy
## Reporting Issues
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.
## Purpose
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.
This operator is meant to provide a more Kubernetes-native installation method for AWX via an AWX Custom Resource Definition (CRD).
## Documentation
Note that the operator is not supported by Red Hat, and is in alpha status. For now, use it at your own risk!
The AWX Operator documentation is available at <https://ansible.readthedocs.io/projects/awx-operator/>
## Usage
> Helm chart documentation is available at <https://ansible-community.github.io/awx-operator-helm/>
This Kubernetes Operator is meant to be deployed in your Kubernetes cluster(s) and can manage one or more AWX instances in any namespace.
## Contributing
First you need to deploy AWX Operator into your cluster:
For docs changes, create PRs on the appropriate files in the `/docs` folder.
Then you can create instances of AWX, for example:
1. Make sure the namespace you're deploying into already exists (e.g. `kubectl create namespace ansible-awx`).
2. Create a file named `my-awx.yml` with the following contents:
```
---
apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
name: awx
namespace: ansible-awx
spec:
tower_admin_user: test
tower_admin_email: test@example.com
tower_admin_password: changeme
tower_broadcast_websocket_secret: changeme
```
3. Use `kubectl` to create the awx instance in your cluster:
```
kubectl apply -f my-awx.yml
```
After a few minutes, your new AWX instance will be accessible at `http://awx.mycompany.com/` (assuming your cluster has an Ingress controller configured). Log in using the `tower_admin_` credentials configured in the `spec`.
### Deploying a specific version of AWX
To achieve this, please add the following variable under spec within your CR (Custom Resource) file:
```yaml
tower_image: ansible/awx:15.0.0 # replace this with desired image
```
You may also override any default variables from `roles/awx/defaults/main.yml` using the same process, i.e. by adding those variables within your CR spec.
### Ingress Types
Depending on the cluster that you're running on, you may wish to use an `Ingress` to access AWX, or you may wish to use a `Route` to access your AWX. To toggle between these two options, you can add the following to your AWX CR:
---
spec:
...
tower_ingress_type: Route
OR
---
spec:
...
tower_ingress_type: Ingress
tower_hostname: awx.mycompany.com
By default, no ingress/route is deployed as the default is set to `none`.
### 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:
---
spec:
...
tower_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:
oc adm policy add-scc-to-user privileged -z awx
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.
### Connecting to an external Postgres Service
When the Operator installs the AWX services and generates a Postgres deployment it will lay down a config file to enable AWX to connect to that service. To use an external database you just need to create a `Secret` that the AWX deployment will use instead and then set a property in the CR:
---
spec:
...
external_database: true
The secret should have the name: *crname*-postgres-configuration and
should look like:
apiVersion: v1
kind: Secret
metadata:
name: <crname>-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>
type: Opaque
### Persistent storage for Postgres
If you need to use a specific storage class for Postgres' storage, specify `tower_postgres_storage_class` in your AWX spec:
---
spec:
...
tower_postgres_storage_class: fast-ssd
If it's not specified, Postgres will store it's data on a volume using the default storage class for your cluster.
## Development
### 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).
You need to make sure you have Molecule installed before running the following commands. You can install Molecule with:
pip install 'molecule[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 (standalone)
molecule test -s test-local
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
minikube start --memory 8g --cpus 4
minikube addons enable ingress
molecule test -s test-minikube
[Minikube](https://kubernetes.io/docs/tasks/tools/install-minikube/) is a more full-featured test environment running inside a full VM on your computer, with an assigned IP address. This makes it easier to test things like NodePort services and Ingress from outside the Kubernetes cluster (e.g. in a browser on your computer).
Once the operator is deployed, you can visit the AWX UI in your browser by following these steps:
1. Make sure you have an entry like `IP_ADDRESS example-awx.test` in your `/etc/hosts` file. (Get the IP address with `minikube ip`.)
2. Visit `http://example-awx.test/` in your browser. (Default admin login is `test`/`changeme`.)
Alternatively, you can also update the service `awx-service` in your namespace to use the type `NodePort` and use following command to get the URL to access your AWX instance:
```sh
minikube service <serviceName> -n <namespaceName> --url
```
### Release Process
There are a few moving parts to this project:
1. The Docker image which powers AWX Operator.
2. The `awx-operator.yaml` Kubernetes manifest file which initially deploys the Operator into a cluster.
Each of these must be appropriately built in preparation for a new tag:
#### Build a new release of the Operator for Docker Hub
#### Build a new version of the `awx-operator.yaml` file
Update the awx-operator version:
- `ansible/group_vars/all`
Once the version has been updated, run from the root of the repo:
ansible-playbook ansible/chain-operator-files.yml
After it is built, test it on a local cluster:
minikube start --memory 6g --cpus 4
minikube addons enable ingress
kubectl apply -f deploy/awx-operator.yaml
kubectl create namespace example-awx
kubectl apply -f deploy/crds/awx_v1beta1_cr.yaml
<testeverything>
minikube delete
If everything works, commit the updated version, then tag a new repository release with the same tag as the Docker image pushed earlier.
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).
If true you must supply a secret containing the location and credentials for
connecting to the external database by a user who has permission to create
and apply a schema.
The secret should have the name: <custom resource name>-postgres-configuration and
should look like:
apiVersion: v1
kind: Secret
metadata:
name: <crname>-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>
type: Opaque
type:boolean
type:object
type:object
version:v1beta1
versions:
- name:v1beta1
served:true
storage:true
status:
acceptedNames:
kind:""
plural:""
conditions:null
storedVersions:null
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.