[WIP] [POC] Awesome runner

[kbrock]

depends upon:

• pass task context into container_runners #177 First Commit

Overview

• Current runners link to an external process that manages the runners.
• Current runners are asynchronous

So that begs to ask the question on how to implement a runner that manages its own subprocesses.

Implementation

I came up with a synchronous and an asynchronous implementation. They get converted across with a commit.

I feel the synchronous implementation may be the best one, otherwise it has a bunch of threads hanging around.

commits:

• dependency
• Synchronous implementation
• asynchronous implementation

Issues

This doesn't work perfectly since AwesomeSpawn escapes $VAR and that makes this pretty useless.

But the goal was more focused on the Threads and stuff rather than the actual awesome spawn part.

[kbrock]

updates:

• fixed wait code to run for multiple schemes
• many cops

[kbrock]

update:

• fix comments around multi threading

[kbrock]

would have preferred not using a thread per process and not using an AwesomeSpan centric model.

[kbrock]

update:

• rebase

update:

• fixed spec (due to rebase)

[miq-bot]

Checked commits kbrock/floe@e25d67e~...514bed0 with ruby 2.7.8, rubocop 1.56.3, haml-lint 0.51.0, and yamllint
5 files checked, 0 offenses detected
Everything looks fine. 🍰

[miq-bot]

This pull request has been automatically marked as stale because it has not been updated for at least 3 months.

If these changes are still valid, please remove the stale label, make any changes requested by reviewers (if any), and ensure that this issue is being looked at by the assigned/reviewer(s).

[miq-bot]

This pull request is not mergeable. Please rebase and repush.

[miq-bot]

This pull request has been automatically marked as stale because it has not been updated for at least 3 months.

If these changes are still valid, please remove the stale label, make any changes requested by reviewers (if any), and ensure that this issue is being looked at by the assigned/reviewer(s).

[miq-bot]

This pull request has been automatically marked as stale because it has not been updated for at least 3 months.

If these changes are still valid, please remove the stale label, make any changes requested by reviewers (if any), and ensure that this issue is being looked at by the assigned/reviewer(s).

[kbrock]

update:

• rebased

still WIP

[Fryguy]

naming-wise I don't like the awesome part - externally awesome:// means nothing. If this is basically just shell execution, let's call it shell:// or if it's bash specific then bash://

[Fryguy]

I'm thinking we should adhere to the AwesomeSpawn style of params handling, so something roughtly like:

Suggested change

	"Resource": "awesome://ls -l Gemfile",
	"Comment": "awesome://ls -l $FILENAME",
	"Next": "c",
	"Parameters": {
	"FILENAME" : "Gemfile"
	}
	"Resource": "awesome://ls",
	"Comment": "awesome://ls -l $FILENAME",
	"Next": "c",
	"Parameters": {
	"-l": null,
	"Gemfile": null
	}

Though, I'm not sure how we would handle duplicate parameters.

[kbrock]

aah. I think $FILENAME did not work and that is why I put that comment in there.
Couldn't get shell env var expansion working. (There was a legit use case in there)

[Fryguy]

FWIW, I would not want this in ManageIQ, but it could be useful outside of ManageIQ. The reason is because we run user-created workflows, and this would give access to the underlying OS/filesystem, which would open up potential security issues. However, if I wanted to automate, say, my own personal stuff on my computer, this would be very useful.

[kbrock]

I was thinking for tests. But yea