Possibility to link instance group with container group

[RummsMurmel]

Please confirm the following

• I agree to follow this project's code of conduct.
• I have checked the current issues for duplicates.
• I understand that AWX is open source software provided for free and that I might not receive a timely response.

Feature type

Enhancement to Existing Feature

Feature Summary

I have the following scenario:

Earlier:
We had run AWX 17 via docker-compose on a CentOS VM.
For a few individual playbooks we had to access a CIFS share. We simply mounted these in the task container via docker-compose.

Today:
We have an AWX instance in Kubernetes (awx-operator version 2.7.2).
Now I would like to avoid from mounting CIFS via FlexVolume (https://github.com/fstab/cifs) because of the necessary intervention on the Kubernetes nodes.

Now I had the plan:

1. install an external execution node with the name "debian11-test" (Instance Group -> Add Instance Group) on a Debian11. check - the installation went well, the runner is shown as Ready and I was able to start a simple debug Pkaybook.

2. mount the CIFS shares directly on the Debian11 execution node via /etc/fstab. check

3. set up a new container group on the AWX with the name: "with-cifs-share" ("Instance Group -> Add Container Group) with the following pod specification:

apiVersion: v1
kind: Pod
metadata:
  namespace: awx
spec:
  serviceAccountName: default
  automountServiceAccountToken: false
  volumes:
    - name: cifs-share
      hostPath:
        path: /mnt/cifs-share
        type: Directory
  containers:
    - image: my-docker-reg/ansible/ee-ansible
      name: worker
      args:
        - ansible-runner
        - worker
        - '--private-data-dir=/runner'
      resources:
        requests:
          cpu: 250m
          memory: 100Mi
      volumeMounts:
         - name: cifs-share
           mountPath: /mnt/cifs-share

The aim is to mount the CIFS share 1:1 in the container, in other words on the identical path as in the host system. This would allow the playbooks to access these resources. And I can now run the jobs that require access to the CIFS share via this instance group and container group.

The problem is that I cannot say in the AWX template:
Please use the execution instance "debian11-test" for this template and please use the container group "with-cifs-share" for this.

In the template, container groups and instance groups are treated in the same way. You can select several, but these are only to be considered as a sequence. If instance group "debian11-test" is not available, then use instance group "with-cifs-share".

So it either runs on my debian11-test node - but without the pod information that a local directory should be mounted
Or it runs in the Kubernetes cluster, but does not find the directory "/mnt/cifs-share".

In my opinion, these are two fundamentally different definitions:

1. where should the job template run (instance-group).
2. how the job template should run (container group).

Is there a way to wire this up after all?

Select the relevant components

• UI
• API
• Docs
• Collection
• CLI
• Other

Steps to reproduce

Create an Instance-Group with an external execution-node and a Container-Group with a customized pod specification. Now try to run a job on the new external execution node with the customized pod specifications.

Current results

Instance-Group and Container-Group are treated in the same way in a Job-Template.
I can't find a way to tell AWX: Please let the Job run on the following Instance-Group with the following pod-spec's, defined in aa Container-Group.

Sugested feature result

Possibility to link instance group with container group

Additional information

No response

[fosterseth]

Hi! thanks for giving feedback and a detailed description of your setup.

when a job is ran on an execution node, a podman container is spun up to run the ansible-playbook. No k8s / pod spec will be used for this job run.

when a job is ran on a container group, it is running as a pod in that k8s cluster.

These are mutually exclusive concepts as of now.

Is the idea to have your execution node be able to launch a job pod on a remote k8s cluster?