Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

adhoc jobs block other jobs from being processed in the queue #14645

Open
5 of 11 tasks
jchilcher-godaddy opened this issue Nov 9, 2023 · 5 comments
Open
5 of 11 tasks

Comments

@jchilcher-godaddy
Copy link

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.
  • I am NOT reporting a (potential) security vulnerability. (These should be emailed to [email protected] instead.)

Bug Summary

When you submit an adhoc job all other jobs (other adhoc, and job templates) are stuck in a pending state until the running adhoc job completes.

AWX version

23.4.0

Select the relevant components

  • UI
  • UI (tech preview)
  • API
  • Docs
  • Collection
  • CLI
  • Other

Installation method

kubernetes

Modifications

no

Ansible version

No response

Operating system

No response

Web browser

Firefox

Steps to reproduce

  1. submit any adhoc job (I used a shell command sleep 30; whoami)
  2. submit a job from "Templates"
  3. observe the job queue

Expected results

all jobs in the unified job queue should process according to capacity. I expect to see more than one job in a running state.

Actual results

The adhoc job is in a running state. All other jobs are stuck in pending waiting for the adhoc command to finish.

Additional information

I am using a container group to run jobs.
Capacity of the managed nodes have been visually verified to be < 25% cpu and mem usage.
I tried creating a duplicate container group for job templates, which still was stuck in pending, but now with a message waiting for adhoccommand-371 to finish

@AlanCoding
Copy link
Member

Are all jobs blocked, or only those running in the same inventory as the ad hoc command? Because if that's the case, then this is expected behavior.

def job_blocked_by(self, job):
project_block = self.get_item(self.PROJECT_UPDATES, job.project_id)
inventory_block = self.get_item(self.INVENTORY_UPDATES, job.inventory_id)

@jchilcher-godaddy
Copy link
Author

adhoc jobs appear to block only when running jobs from the same inventory, yes. I had no idea that was expected. I assumed that a job was a job and they could all be run simultaneously (excluding the inventory/project updates).

Seems like a fair workaround would be to duplicate the inventory and use one for tempates and the other for adhoc jobs, does that sound about right?

@AlanCoding
Copy link
Member

Discussion has come up before, and we would prefer to allow these rules to be fully user-customizable, @chrismeyersfsu was a particular advocate for this. There may be some existing related issues. The dependency_graph.py contains most of this type of blocking logic, which I would prefer to call "exclusion rules" to distinguish from other types of dependencies like update-on-launch dependencies. As you can see, that file isn't terribly complicated, but I don't quite know how to put that in a language where a user could customize it with a dictionary-valued setting, for example.

@fosterseth
Copy link
Member

I think we could change the way we mark adhocommands so that they aren't treated as inventory updates. Instead we can introduce a mark_adhoccommand method. We should still block on inventory updates though.

self.mark_inventory_update(job)

@imDarshanGK
Copy link

Hey, is this issue still open? I can work on this if needed..
Also saw #14645

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants