Don't raise dependency errors for dynamic credential fields

[wenottingham]

Example: setting ssh_key_unlock by hand when the key comes from a vault.

[softwarefactory-project-zuul]

Build succeeded.

• awx-api-lint : SUCCESS in 3m 30s
• awx-ui-lint : SUCCESS in 2m 54s
• awx-ui-next-lint : SUCCESS in 3m 40s
• awx-api : SUCCESS in 10m 20s
• awx-ui : SUCCESS in 4m 15s
• awx-ui-next : SUCCESS in 7m 30s
• awx-swagger : SUCCESS in 10m 32s
• awx-detect-schema-change : FAILURE in 9m 16s (non-voting)
• awx-ansible-modules : FAILURE in 2m 33s (non-voting)

[wenottingham]

For #4791

[omgjlk]

Well this lets me save the dialog, AND execute a command on a host using that credential prompts for the passphrase. However when trying to use it now the job fails immediately, the same way as if it didn't get prompted for the passphrase.

[omgjlk]

So I guess technically this pull request DOES solve a bug, and should be merged. But it uncovers a deeper underlying bug too.

[wenottingham]

Anything in the logs that looks like a traceback or gives more info as to how it failed?

[omgjlk]

Actually you know what, I forgot to make this code change on the task container. I'll work that out and get back to you with any additional logging.

[jakemcdermott]

For new credentials, these dynamic input relationships don't exist yet, and the dependency validation error will still occur:

To get the expected validation behavior, we'll need to come up with a way of knowing the intended dynamic inputs before they've been created.

For regular / static fields that are encrypted, we've dealt with similar issues in the past by (ab)using the special $encrypted value as a placeholder. We may need to do something similar here.

I'd need to take a deeper look at this before proposing anything specific.

[jakemcdermott]

@omgjlk Once the prompted fields are saved, I suspect that an updated task container might be all that's needed to resolve #4798 (comment) but it would be good to confirm - thanks for taking a look.

[omgjlk]

@omgjlk Once the prompted fields are saved, I suspect that an updated task container might be all that's needed to resolve #4798 (comment) but it would be good to confirm - thanks for taking a look.

I restarted the task container, which seems to have already had the edited code in it (I'm guessing with the docker-compose style of deployment there is a shared venv).

Unfortunately the task still fails, and there aren't really any good logs to show WHY it failed.

	awx_task     | 2019-09-23 13:08:06,773 DEBUG    awx.main.dispatch delivered 640de1d5-99ce-425b-8bd9-1eb04e3a7639 to worker[196] qsize 0
awx_task     | 2019-09-23 13:08:06,777 DEBUG    awx.main.dispatch task 640de1d5-99ce-425b-8bd9-1eb04e3a7639 starting awx.main.scheduler.tasks.run_task_manager(*[])
awx_task     | 2019-09-23 13:08:06,781 DEBUG    awx.main.scheduler Running Tower task manager.
awx_task     | 2019-09-23 13:08:06,792 DEBUG    awx.main.scheduler Starting Scheduler
awx_task     | 2019-09-23 13:08:06,849 DEBUG    awx.main.scheduler Starting ad_hoc_command 11794 (pending) in group tower instance awx (remaining_capacity=76)
awx_task     | 2019-09-23 13:08:06,857 DEBUG    awx.main.scheduler Submitting ad_hoc_command 11794 (waiting) to <instance group, instance> <1,awx>.
awx_task     | 2019-09-23 13:08:06,882 DEBUG    awx.main.scheduler ad_hoc_command 11794 (waiting) consumed 6 capacity units from tower with prior total of 0
awx_task     | 2019-09-23 13:08:06,938 DEBUG    awx.main.dispatch publish awx.main.tasks.RunAdHocCommand(3c1d9572-1486-45b4-95e9-2012c5076d86, queue=awx)
awx_task     | 2019-09-23 13:08:06,953 DEBUG    awx.main.dispatch delivered 3c1d9572-1486-45b4-95e9-2012c5076d86 to worker[198] qsize 0
awx_task     | 2019-09-23 13:08:06,956 DEBUG    awx.main.dispatch task 3c1d9572-1486-45b4-95e9-2012c5076d86 starting awx.main.tasks.RunAdHocCommand(*[11794])
awx_task     | 2019-09-23 13:08:06,954 DEBUG    awx.main.dispatch task 640de1d5-99ce-425b-8bd9-1eb04e3a7639 is finished
awx_task     | 2019-09-23 13:08:09,421 INFO     awx.main.commands.run_callback_receiver Event processing is finished for Job 11794, sending notifications
awx_task     | 2019-09-23 13:08:09,421 INFO     awx.main.commands.run_callback_receiver Event processing is finished for Job 11794, sending notifications
awx_task     | 2019-09-23 13:08:09,514 DEBUG    awx.main.tasks ad_hoc_command 11794 (running) finished running, producing 1 events.
awx_task     | 2019-09-23 13:08:09,577 WARNING  awx.main.dispatch ad_hoc_command 11794 (failed) encountered an error (rc=1), please see task stdout for details.
awx_task     | 2019-09-23 13:08:09,579 DEBUG    awx.main.dispatch task 3c1d9572-1486-45b4-95e9-2012c5076d86 starting awx.main.tasks.handle_work_error(*['3c1d9572-1486-45b4-95e9-2012c5076d86'])
awx_task     | 2019-09-23 13:08:09,580 DEBUG    awx.main.tasks Executing error task id 3c1d9572-1486-45b4-95e9-2012c5076d86, subtasks: [{'type': 'ad_hoc_command', 'id': 11794}]
awx_task     | 2019-09-23 13:08:09,584 DEBUG    awx.main.dispatch publish awx.main.scheduler.tasks.run_task_manager(3ef1968c-b49e-456c-a681-14ccadf061c9, queue=awx_private_queue)

The web UI shows this for output

Enter passphrase for /tmp/awx_11794_yh899vb9/artifacts/11794/ssh_key_data

I'm totally wiling to drop a rpdb.set_trace() somewhere in here to catch this interaction in a debugging session, if there are values and such you'd like me to dump at some points in this.

[ryanpetrello]

@wenottingham @jakemcdermott @omgjlk I'm not certain this is going to work, and the more I think about it, I think supporting this new dynamic input model means we're going to have to lose this level of validation, because the order of operations just doesn't work.

[ryanpetrello]

@wenottingham we might end up going with this instead:

#4807