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

RFC: allow for environment driven env settings #541

Open
wants to merge 1 commit into
base: devel
Choose a base branch
from

Conversation

mattp-
Copy link
Contributor

@mattp- mattp- commented Oct 7, 2020

expose ANSIBLE_RUNNER_{PASSWORDS,SETTINGS,ENVVARS,SSH_KEY} as an alternative means of driving ansible runner inputs vs serializing to file. I'm submitting this for feedback on the idea, if this feature is something that would be accepted I will polish/document/add tests. This could be useful in scenarios where you don't want to be serializing at least passwords to disk, where environ is ephemeral to the lifetime of the process.

expose ANSIBLE_RUNNER_{PASSWORDS,SETTINGS,ENVVARS,SSH_KEY} as an
alternative means of driving ansible runner inputs vs serializing to
file.
@@ -352,7 +361,10 @@ def prepare_env(self):

try:
if self.ssh_key_data is None:
self.ssh_key_data = self.loader.load_file('env/ssh_key', string_types)
if 'ANSIBLE_RUNNER_SSH_KEY' in os.environ:
self.ssh_key_data = self.loader.load_env('ANSIBLE_RUNNER_SSH_KEY', Mapping)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it be preferable to cut right to the Ansible settings?

https://github.com/ansible/ansible/blob/devel/lib/ansible/config/base.yml

You could pass ANSIBLE_PRIVATE_KEY_FILE, and ansible-runner should pass that to the subprocess, and then Ansible should respect it for the same function as this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm I didn't know that existed actually, yes for ssh key it would indeed make sense. we could either duplicate it for parity with other ANSIBLE_RUNNER_* or just remove it in lieu of using ANSIBLE_PRIVATE_KEY_FILE. my main motivation is really avoiding the passwords file actually :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually looking a bit closer, ANSIBLE_PRIVATE_KEY_FILE is a path to a key, not the privkey contents itself, so a bit different.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AlanCoding any further thoughts on this functionality?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @mattp-. Alan is out for a couple more weeks after his wife gave birth. Hang tight and he'll get to this eventually.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah had no idea. congratulations :) and no rush, thanks.

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

Successfully merging this pull request may close these issues.

None yet

3 participants