ansible / eda-server-operator

Ansible

Ansible is a radically simple IT automation system. It handles configuration management, application deployment, cloud provisioning, ad-hoc task execution, network automation, and multi-node orchestration. Ansible makes complex changes like zero-downtime rolling updates with load balancers easy. More information on the Ansible website.

Design Principles

• Have an extremely simple setup process with a minimal learning curve.
• Manage machines quickly and in parallel.
• Avoid custom-agents and additional open ports, be agentless by leveraging the existing SSH daemon.
• Describe infrastructure in a language that is both machine and human friendly.
• Focus on security and easy auditability/review/rewriting of content.
• Manage new remote machines instantly, without bootstrapping any software.
• Allow module development in any dynamic language, not just Python.
• Be usable as non-root.
• Be the easiest IT automation system to use, ever.

Use Ansible

You can install a released version of Ansible with pip or a package manager. See our installation guide for details on installing Ansible on a variety of platforms.

Power users and developers can run the devel branch, which has the latest features and fixes, directly. Although it is reasonably stable, you are more likely to encounter breaking changes when running the devel branch. We recommend getting involved in the Ansible community if you want to run the devel branch.

Get Involved

• Read Community Information for all kinds of ways to contribute to and interact with the project, including mailing list information and how to submit bug reports and code to Ansible.
• Join a Working Group, an organized community devoted to a specific technology domain or platform.
• Submit a proposed code update through a pull request to the devel branch.
• Talk to us before making larger changes to avoid duplicate efforts. This not only helps everyone know what is going on, but it also helps save time and effort if we decide some changes are needed.
• For a list of email lists, IRC channels and Working Groups, see the Communication page

Coding Guidelines

We document our Coding Guidelines in the Developer Guide. We particularly suggest you review:

• Contributing your module to Ansible
• Conventions, tips, and pitfalls

Branch Info

• The devel branch corresponds to the release actively under development.
• The stable-2.X branches correspond to stable releases.
• Create a branch based on devel and set up a dev environment if you want to open a PR.
• See the Ansible release and maintenance page for information about active branches.

Roadmap

Based on team and community feedback, an initial roadmap will be published for a major or minor version (ex: 2.7, 2.8). The Ansible Roadmap page details what is planned and how to influence the roadmap.

Authors

Ansible was created by Michael DeHaan and has contributions from over 5000 users (and growing). Thanks everyone!

Ansible is sponsored by Red Hat, Inc.

License

GNU General Public License v3.0 or later

See COPYING to see the full text.

eda-server-operator's Issues

Enable single command install without clone

There's currently no single command apply for any of the 3 operators that doesn't require cloning the repo. This is how other operators do it, which makes it easier for people to get up and running faster. Example: Installing the standard kubernetes metrics:

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

We can add it to a release GHA, then have it be a .yaml release artifact. That's how they do it for the metrics-server:

• make command to generate the manifests
• step in Release GHA to publish the artifacts - https://github.com/kubernetes-sigs/metrics-server/blob/796fc0f832c1ac444c44f88a952be87524456e07/.github/workflows/release.yaml#L24

On fresh deployments, sometimes the first reconciliation loop fails on the task "Check for API Pod"

Description

On fresh deployments for EDA CR, sometimes the first reconciliation loop fails on the task "Check for API Pod".

If we do nothing and wait for the next reconciliation loop, this task will succeed and the deployment will complete.

The first reconciliation:

...
--------------------------- Ansible Task StdOut -------------------------------
 TASK [Check for API Pod] ******************************** 
fatal: [localhost]: FAILED! => {"api_found": true, "attempts": 3, "changed": false, "resources": []}
...
[eda : Check for API Pod] *************************************************\r\n
task path: /opt/ansible/roles/eda/tasks/deploy_eda.yml:31\n
FAILED - RETRYING: Check for API Pod (3 retries left).\n
FAILED - RETRYING: Check for API Pod (2 retries left).\n
FAILED - RETRYING: Check for API Pod (1 retries left).\n
fatal: [localhost]: FAILED! => {\"api_found\": true, \"attempts\": 3, \"changed\": false, \"resources\": []}\n\r\n
PLAY RECAP *********************************************************************\r\n
localhost                  : ok=53   changed=7    unreachable=0    failed=1    skipped=12   rescued=0    ignored=0   \r\n\n

Just wait for the second reconciliation with doing nothing:

...
TASK [eda : Check for API Pod] *************************************************
task path: /opt/ansible/roles/eda/tasks/deploy_eda.yml:31

-------------------------------------------------------------------------------
{"level":"info","ts":1702472703.452893,"logger":"proxy","msg":"cache miss: /v1, Kind=PodList err-Index with name field:status.phase does not exist"}
{"level":"info","ts":1702472703.856233,"logger":"logging_event_handler","msg":"[playbook task start]","name":"eda","namespace":"eda","gvk":"eda.ansible.com/v1alpha1, Kind=EDA","event_type":"playbook_on_task_start","job":"4939066471100038729","EventData.Name":"eda : Create admin user"}

--------------------------- Ansible Task StdOut -------------------------------

TASK [eda : Create admin user] *************************************************
task path: /opt/ansible/roles/eda/tasks/main.yml:36

Additional information

This is due to the until without delay or retries.
It wait only for 15 seconds since the default value for delay is 5 and retries is 3.

When pulling image from registry is performed in addition to API initialization for api pod, it often takes tens of seconds or more for the api pod to become ready, making this task very prone to failure.

eda-server-operator/roles/eda/tasks/deploy_eda.yml

Lines 31 to 46 in 6df1529

	- name: Check for API Pod
	k8s_info:
	kind: Pod
	api_version: v1
	namespace: "{{ ansible_operator_meta.namespace }}"
	label_selectors:
	- "app.kubernetes.io/name={{ ansible_operator_meta.name }}"
	- "app.kubernetes.io/managed-by={{ deployment_type }}-operator"
	- "app.kubernetes.io/component={{ deployment_type }}-api"
	field_selectors:
	- status.phase=Running
	register: eda_api_pod
	until:
	- "eda_api_pod['resources'] | length"
	- "eda_api_pod['resources'][0]['status']['phase'] == 'Running'"
	- "eda_api_pod['resources'][0]['status']['containerStatuses'][0]['ready'] == true"

We should explicitly specify delay and retries with enough value (5 and 24, 2 minutes in total, for example), or use wait, wait_condition, wait_sleep, and wait_timeout for k8s_info module instead of until: https://docs.ansible.com/ansible/latest/collections/kubernetes/core/k8s_info_module.html

UI can't be started up due to changes for ansible-ui

Directory structure and nginx.conf for eda-ui image has been updated on ansible-ui via ansible/ansible-ui#766

This causes CrashLoopBackOff for eda-ui pod since health check fails with 404:

$ kubectl -n eda logs eda-ui-7cc5f59787-5wpww
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
20-envsubst-on-templates.sh: Running envsubst on /etc/nginx/templates/default.conf.template to /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
10.42.0.1 - - [16/Aug/2023:02:27:13 +0000] "GET / HTTP/1.1" 404 146 "-" "kube-probe/1.27"
10.42.0.1 - - [16/Aug/2023:02:27:14 +0000] "GET / HTTP/1.1" 404 146 "-" "kube-probe/1.27"
10.42.0.1 - - [16/Aug/2023:02:27:18 +0000] "GET / HTTP/1.1" 404 146 "-" "kube-probe/1.27"
10.42.0.1 - - [16/Aug/2023:02:27:18 +0000] "GET / HTTP/1.1" 404 146 "-" "kube-probe/1.27"
10.42.0.1 - - [16/Aug/2023:02:27:18 +0000] "GET / HTTP/1.1" 404 146 "-" "kube-probe/1.27"

Workaround:

Specify old image using image_web and image_web_version

...
spec:
  ...
  image_web: quay.io/ansible/eda-ui
  image_web_version: "2.4.306"
  ...

postgres_storage_class does not work

postgres_storage_class is ignored due to invalid if statement.

eda-server-operator/roles/postgres/templates/postgres.statefulset.yaml.j2

Lines 103 to 105 in b24ca21

	{% if postgres_storage_class is defined %}
	storageClassName: '{{ combined_database.postgres_storage_class }}'
	{% endif %}

Should be {% if combined_database.postgres_storage_class is defined %}.

Pin API and UI image refs in released operator images

There are no gaurantees that newer api and ui images will be compatible with a given released eda-server-operator image. We should pin the latest api and ui image at time of release inside the operator image as env vars.

Here is how it was done in AWX Operator:

• https://github.com/ansible/awx-operator/pull/612/files

We will need to coordinate with the eda-server and eda-ui image maintainers to standardize tags as needed. We will also want to write a release script or GHA that accepts a version or image tags as inputs.

Bump kustomize version

Using newer (5.x) of kustomize causes deprecated message: Warning: 'patchesStrategicMerge' is deprecated

The make deploy will no longer be used since single installable YAML file will be provided with next release, but anyway deprecated syntax should not be used.

$ which kustomize
~/bin/kustomize

$ kustomize version
v5.3.0

$ NAMESPACE=eda VERSION=latest make deploy
cd config/manager && /home/kuro/bin/kustomize edit set image controller=quay.io/ansible/eda-server-operator:latest
cd config/default && /home/kuro/bin/kustomize edit set namespace eda
/home/kuro/bin/kustomize build config/default | kubectl apply -f -
# Warning: 'patchesStrategicMerge' is deprecated. Please use 'patches' instead. Run 'kustomize edit fix' to update your Kustomization automatically.
namespace/eda created
customresourcedefinition.apiextensions.k8s.io/edabackups.eda.ansible.com created
customresourcedefinition.apiextensions.k8s.io/edarestores.eda.ansible.com created
customresourcedefinition.apiextensions.k8s.io/edas.eda.ansible.com created
serviceaccount/eda-server-operator-controller-manager created
role.rbac.authorization.k8s.io/eda-server-operator-eda-manager-role created
role.rbac.authorization.k8s.io/eda-server-operator-leader-election-role created
clusterrole.rbac.authorization.k8s.io/eda-server-operator-metrics-reader created
clusterrole.rbac.authorization.k8s.io/eda-server-operator-proxy-role created
rolebinding.rbac.authorization.k8s.io/eda-server-operator-eda-manager-rolebinding created
rolebinding.rbac.authorization.k8s.io/eda-server-operator-leader-election-rolebinding created
clusterrolebinding.rbac.authorization.k8s.io/eda-server-operator-proxy-rolebinding created
service/eda-server-operator-controller-manager-metrics-service created
deployment.apps/eda-server-operator-controller-manager created

The same changes with this PR in AWX Operator should be applied: ansible/awx-operator#1357

Auto-build and push operator images for the main branch

Currently, new release isn't needed to run the latest, you can build images and push to your own quay.io.

But it would be better for all to have set something up that will push the latest image to main tag or something like that so that people have the option of running:

A) a released version or
B) the latest code in the main branch without having to build images.

Installation issue

Im fairly new to K8s and I tried to follow the install guide and have managed to get the eda-server-operator-controller-manager installed on my k3s server ( along with a working AWX install and operator ) but when I run the eda.yml and check the logs this is the following output.

--------------------------- Ansible Task StdOut -------------------------------

 TASK [Fail if automation_host_connection_secrets is not (only one should be set)] ********************************
fatal: [localhost]: FAILED! => {
    "assertion": "automation_host_connection_secrets is defined",
    "changed": false,
    "evaluated_to": false,
    "msg": "Please set a single automation server connection secret to be used via the automation_host_connection_secrets parameter."
`}

I can't see any instructions on where this needs to be defined and what it is?

DEFAULT_*_VERSION and OPERATOR_VERSION are empty in Operator 1.0.0

make docker-buildx does not use BUILD_ARGS, so even if we specify BUILD_ARGS in CI, it will be ignored:

  BUILD_ARGS="--build-arg DEFAULT_EDA_VERSION=sha-26e62bd \
      --build-arg DEFAULT_EDA_UI_VERSION=2.4.884 \
      --build-arg OPERATOR_VERSION=1.0.0" \
  IMG=ghcr.io/ansible/eda-server-operator:1.0.0 \
  make docker-buildx

https://github.com/ansible/eda-server-operator/actions/runs/7507310771/job/20440601824#step:6:2

Indeed the images for 1.0.0 has empty ENVs:

$ docker run --rm -it --entrypoint bash quay.io/ansible/eda-server-operator:1.0.0 -c env | sort | grep VERSION
DEFAULT_EDA_UI_VERSION=
DEFAULT_EDA_VERSION=
OPERATOR_VERSION=
TINI_VERSION=v0.19.0

$ docker run --rm -it --entrypoint bash ghcr.io/ansible/eda-server-operator:1.0.0 -c env | sort | grep VERSION
DEFAULT_EDA_UI_VERSION=
DEFAULT_EDA_VERSION=
OPERATOR_VERSION=
TINI_VERSION=v0.19.0

@rooftopcellist @jon-nfc
F.Y.I.😞

Build a Release workflow

We should add a GHA for releasing eda-server and eda-server-operator in tandem, and also have the ability to release eda-server-operator separately if desired.

The AWX pattern for mapping them is to have the awx-operator and awx release handled by the same GHA, which sets an env var for the awx version to use in the awx-operator image. Then the operator uses that env var as the default awx image version to use.

We should add a step to make a commit to a docs/version-matrix.md file.

Once this workflow is in place, we should cut the first v1.0.0 eda-server-operator release to denote that this is now a stable operator.

EDA UI is blank with latest eda-ui image

With the latest eda-ui image, the UI shows as blank. This is because the default url path has changed and the operator's nginx.conf must be updated to reflect this.

PR here:

• #152

Admin User creation task fails on deployment

From inside the container:

bash-5.1$ echo 'from django.contrib.auth import get_user_model;
User = get_user_model(); 
nsu = User.objects.filter(is_superuser=True, username=\"{{ admin_user }}\").count();' | aap-eda-manage shell
Traceback (most recent call last):
  File "/app/venv/bin/aap-eda-manage", line 6, in <module>
    sys.exit(main())
  File "/app/src/src/aap_eda/manage.py", line 18, in main
    execute_from_command_line(sys.argv)
  File "/app/venv/lib64/python3.9/site-packages/django/core/management/__init__.py", line 419, in execute_from_command_line
    utility.execute()
  File "/app/venv/lib64/python3.9/site-packages/django/core/management/__init__.py", line 413, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/app/venv/lib64/python3.9/site-packages/django/core/management/base.py", line 354, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/app/venv/lib64/python3.9/site-packages/django/core/management/base.py", line 398, in execute
    output = self.handle(*args, **options)
  File "/app/venv/lib64/python3.9/site-packages/django/core/management/commands/shell.py", line 93, in handle
    exec(sys.stdin.read(), globals())
  File "<string>", line 3
    nsu = User.objects.filter(is_superuser=True, username=\"{{ admin_user }}\").count();
                                                           ^
SyntaxError: unexpected character after line continuation character

Operator Logs:

 TASK [Check if there are any super users defined.] ******************************** 
fatal: [localhost]: FAILED! => {"msg": "The conditional check 'users_result.return_code > 0' failed. The error was: error while evaluating conditional (users_result.return_code > 0): 'dict object' has no attribute 'return_code'"}
...ignoring

-------------------------------------------------------------------------------
{"level":"error","ts":1680389646.1523108,"logger":"logging_event_handler","msg":"","name":"eda-demo","namespace":"eda","gvk":"eda.ansible.com/v1alpha1, Kind=EDA","event_type":"runner_on_failed","job":"1030711653854159178","EventData.Task":"Check if there are any super users defined.","EventData.TaskArgs":"","EventData.FailedTaskPath":"/opt/ansible/roles/eda/tasks/create_admin_user.yml:2","error":"[playbook task failed]","stacktrace":"github.com/operator-framework/operator-sdk/internal/ansible/events.loggingEventHandler.Handle\n\t/workspace/internal/ansible/events/log_events.go:111"}

--------------------------- Ansible Task StdOut -------------------------------

TASK [eda : Create super user via Django if it doesn't exist.] *****************
task path: /opt/ansible/roles/eda/tasks/create_admin_user.yml:17

-------------------------------------------------------------------------------
{"level":"info","ts":1680389646.1761863,"logger":"logging_event_handler","msg":"[playbook task start]","name":"eda-demo","namespace":"eda","gvk":"eda.ansible.com/v1alpha1, Kind=EDA","event_type":"playbook_on_task_start","job":"1030711653854159178","EventData.Name":"eda : Create super user via Django if it doesn't exist."}

--------------------------- Ansible Task StdOut -------------------------------

 TASK [Create super user via Django if it doesn't exist.] ******************************** 
fatal: [localhost]: FAILED! => {"msg": "The conditional check 'users_result.return_code > 0' failed. The error was: error while evaluating conditional (users_result.return_code > 0): 'dict object' has no attribute 'return_code'\n\nThe error appears to be in '/opt/ansible/roles/eda/tasks/create_admin_user.yml': line 17, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Create super user via Django if it doesn't exist.\n  ^ here\n"}

Accessing / over HTTPS redirects to eda/ over HTTP

Description

On 0.0.11 with the latest eda-ui, accessing https://eda.example.com redirects to http://eda.example.com/eda/.

Steps to reproduce

• Deploy EDA with Ingress with TLS cert

  ingress_type: ingress
  ingress_tls_secret: eda-secret-tls
  hostname: eda.example.com

• Access https://eda.example.com

Additional information

With above configuration, TLS is terminated on Ingress resource, so on the nginx side, $scheme is determined as plain HTTP instead of HTTPS.

Installation with route ingress type fails

I have an eda instance that requires a route with tls and it is failing during installation because the playbook cannot find the route_tls_key variable.

lines 63 and 65 of the ingress template reference the variable, but I could not find where to set it in the eda cr and I don't see any other references to the variable in the role.

eda-server-operator/roles/eda/templates/eda-ui.ingress.yaml.j2

Lines 53 to 76 in 0e00851

	{% if route_host != '' %}
	host: {{ route_host }}
	{% endif %}
	port:
	targetPort: '{{ (route_tls_termination_mechanism | lower == "passthrough") | ternary("https", "http") }}'
	tls:
	insecureEdgeTerminationPolicy: Redirect
	termination: {{ route_tls_termination_mechanism | lower }}
	{% if route_tls_termination_mechanism | lower == 'edge' and route_tls_secret != '' %}
	key: |-
	{{ route_tls_key | indent(width=6, first=True) }}
	certificate: |-
	{{ route_tls_crt | indent(width=6, first=True) }}
	{% if route_ca_crt is defined %}
	caCertificate: |-
	{{ route_ca_crt | indent(width=6, first=True) }}
	{% endif %}
	{% endif %}
	to:
	kind: Service
	name: {{ ansible_operator_meta.name }}-ui
	weight: 100
	wildcardPolicy: None
	{% endif %}

Is there somewhere that this variable can be set, or is this a bug?

Add Contributing.md

We should add a contributing.md doc that describes how to build the images to test locally.

extra_settings does not work due to invalid structure in configmap

In the current implementation, environment variables that should be loaded through configmap are stored under settings key as multiline strings:

eda-server-operator/roles/eda/templates/eda.configmap.yaml.j2

Lines 10 to 26 in b24ca21

	data:
	settings: |
	# Operator specific settings
	DEPLOYMENT_TYPE=k8s
	# AWX Server
	EDA_CONTROLLER_SSL_VERIFY=no
	# EDA Server
	EDA_WEBSOCKET_BASE_URL=ws://eda-api:8000
	EDA_WEBSOCKET_SSL_VERIFY=no
	# Custom user variables
	{% for item in extra_settings | default([]) %}
	{{ item.setting | upper }}={{ item.value }}
	{% endfor %}

and this configmap is loaded by envFrom.

eda-server-operator/roles/eda/templates/eda-worker.deployment.yaml.j2

Lines 65 to 67 in b24ca21

	envFrom:
	- configMapRef:
	name: '{{ ansible_operator_meta.name }}-{{ deployment_type }}-configmap'

This causes no variables under settings are loaded correctly. configMapRef loads keys just under root of configmap, so as a result, the pods have settings and nginx_conf as envs that include multiline strings.

# Get shell of the pod
$ kubectl -n eda exec -it eda-worker-8446d9dd44-9dz7k -- bash

# Getting specific environment variables show multiline strings
[eda@eda-worker-8446d9dd44-9dz7k src]$ echo "$settings"
# Operator specific settings
DEPLOYMENT_TYPE=k8s
...

[eda@eda-worker-8446d9dd44-9dz7k src]$ echo "$nginx_conf"
events {
    worker_connections 1024;
}
http {
    ...

Therefore, extra_settings has no effect in the current implementation.

Support Helm Deployment method

Instead of having Releases based on Kustomize, Helm should be used instead.

Helm is also used on AWX-Operator Repo.

I think it makes sense that EDA Operator follows that same release approach, instead of making people use 2 technologies basically, since most cases if you are deploying EDA, you also Deploy AWX.

The ports and scheme for UI has been changed to 80/443 and HTTPS

We have to follow this changes: ansible/ansible-ui#927. This changes cause CrashLoopBackOff for eda-ui.

• EDA UI is now listening on 80 (HTTP) and 443 (HTTPS) instead of 8080, so livenessProbe and redinessProbe in Deployment have to be updated
• EDA UI is now redirecting HTTP request on port 80 to HTTPS on 443 with status 301. If the bundled nginx.conf in EDA UI should be used as it is, our implementation for Service/Ingress/Route resources have to be updated. Alternatively, we can choose to revert to passing nginx.conf through configmap (made by #124)

Unable to launch managed postgres db in cluster

Hello @rooftopcellist! I am having some issues with deploying EDA into our EKS cluster:

eda-manager.log

it is stuck on

TASK [postgres : Wait for Database to initialize if managed DB]:

{"level":"info","ts":1697747113.740688,"logger":"proxy","msg":"cache miss: /v1, Kind=PodList err-Index with name field:status.phase does not exist"}

I deployed via recommended operator with ArgoCD/Customize

Are we not able to yet use an external db similar to what we do with AWX? thanks for your help!

IPv6 is always enabled by default for eda-ui

From the logs during startup of eda-ui:

# kubectl logs -n awx pod/eda-ui-5f99478dc4-sjnpl  -f

docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: ipv6 not available
/docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
20-envsubst-on-templates.sh: Running envsubst on /etc/nginx/templates/default.conf.template to /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2023/10/13 21:06:31 [emerg] 1#1: socket() [::]:80 failed (97: Address family not supported by protocol)
nginx: [emerg] socket() [::]:80 failed (97: Address family not supported by protocol)

Copying /etc/nginx/templates/default.conf.template contains the following snippet

server {
    listen 80;
    listen [::]:80;
    server_name _
    server_tokens off;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name _;
    server_tokens off;

This negates the running of the script in 10-listen-on-ipv6-by-default.sh, and enables IPv6 on systems, where IPv6 is not enabled.

Built-in scheduler in workers can be disabled

Since dedicated RQ scheduler has been introduced in #104, built-in scheduler in workers (--with-scheduler args wor rqworker) can be disabled.

The same changes had been made in ansible/eda-server#321 in eda-server repository.

[docs] EDA Server Operator or EDA Controller Operator

The docs on ansible/eda-server shows EDA Controller as its name, as same as official docs for EDA Controller.

I don't know the internal naming policy, but the product names in the docs on this repository should be considered to rename from EDA Server Operator to EDA Controller Operator.

Incorrect args for worker pods

With the latest quay.io/ansible/eda-server:main, worker pod failed to start with following error:

$ kubectl -n eda logs eda-worker-694fc4d474-4f85b
Traceback (most recent call last):
  File "/app/venv/bin/aap-eda-manage", line 6, in <module>
    sys.exit(main())
  File "/app/src/src/aap_eda/manage.py", line 18, in main
    execute_from_command_line(sys.argv)
  File "/app/venv/lib64/python3.9/site-packages/django/core/management/__init__.py", line 419, in execute_from_command_line
    utility.execute()
  File "/app/venv/lib64/python3.9/site-packages/django/core/management/__init__.py", line 413, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/app/venv/lib64/python3.9/site-packages/django/core/management/base.py", line 354, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/app/venv/lib64/python3.9/site-packages/django/core/management/base.py", line 398, in execute
    output = self.handle(*args, **options)
  File "/app/venv/lib64/python3.9/site-packages/django_rq/management/commands/rqworker.py", line 120, in handle
    w = get_worker(*args, **worker_kwargs)
  File "/app/venv/lib64/python3.9/site-packages/django_rq/workers.py", line 50, in get_worker
    worker_class = get_worker_class(kwargs.pop('worker_class', None))
  File "/app/venv/lib64/python3.9/site-packages/django_rq/workers.py", line 36, in get_worker_class
    worker_class = import_attribute(worker_class)
  File "/app/venv/lib64/python3.9/site-packages/rq/utils.py", line 220, in import_attribute
    attribute_owner = getattr(module, attribute_owner_name)
AttributeError: module 'aap_eda.core.tasking' has no attribute ''

There is no longer aap_eda.core.tasking.Worker class (via ansible/eda-server#318)

eda-server-operator/roles/eda/templates/eda-worker.deployment.yaml.j2

Line 64 in b24ca21

- aap-eda-manage rqworker --with-scheduler --worker-class aap_eda.core.tasking.Worker

Not tested well on my side but it seems to be aap_eda.core.tasking.DefaultWorker.

Sorry for the messy note 😥