| *** ysandeep|out is now known as ysandeep | 03:58 | |
| *** ysandeep is now known as ysandeep|afk | 06:23 | |
| *** ysandeep|afk is now known as ysandeep | 07:39 | |
| *** ysandeep is now known as ysandeep|lunch | 09:52 | |
| *** ysandeep|lunch is now known as ysandeep | 11:15 | |
| *** dviroel|out is now known as dviroel | 11:24 | |
| tomas_mensik | Hi! Could anyone please help me with strange issue with openstack.cloud.config issues? Despite my openstack client works fine with this clouds.yaml config, ansible config modules keeps failing. Other modules such as openstack.cloud.auth works! https://pastebin.com/9kfCihzs | 12:13 |
|---|---|---|
| *** dviroel is now known as dviroel|biab | 12:29 | |
| *** dviroel|biab is now known as dviroel | 13:31 | |
| *** dviroel_ is now known as dviroel | 14:10 | |
| tomas_mensik | For the question above, here is opestack config example which should have all it needs - works for either openstack cli or cloud.auth: https://pastebin.com/0SPhSU7j | 14:31 |
| *** ysandeep is now known as ysandeep|out | 14:35 | |
| *** dviroel is now known as dviroel|lunch | 15:03 | |
| tomas_mensik | eureka! I have finally got openstack.cloud.config working! While I am still not sure it was the only issue, I certainly needed to unset either OS_CLOUD and OS_PASSWORD. Which is unfortunate because OS_PASSWORD environment variable was the only way how to securely provide password without leaving it in plaintext at secure.yaml. | 15:15 |
| gtema | plaintext env vs plaintext secure.yaml | 15:16 |
| jrosser_ | i think that these modules are very sensitive to which env vars are / are not set and having the wrong combination leads to wierd error messages | 15:18 |
| gtema | while working with cloud modules you should anyway avoid setting env vars and instead either rely on config file or pass whole conn structure which you read from some sort of vault if concerned | 15:19 |
| gtema | and the second one is definitely preferred | 15:20 |
| tomas_mensik | yes, but switching to different cloud/profile using env vars is quite painful - and openstack solved that by moving to clouds.yaml config. At least that password should be possible to pass using ENV. | 15:22 |
| gtema | that is a misuse of concepts. Passing creds is "native" for ansible modules. For running things locally clouds.yaml should be used | 15:23 |
| gtema | cause depending on whether you use "localhost" or "some_remote_host" you either have clouds.yaml or not. And this makes whole playbook pretty not portable | 15:24 |
| tomas_mensik | and plaintext ENV variable - sure does not sound like much difference, but its more difficult to steal secret from a running process (unless it gives it away itself) than from a file on disk. | 15:24 |
| tomas_mensik | for that playbook portability - sure that is why openstack.cloud.config does exist, isn't it? I admit I always expected to have authentication on computer the playbook was run on - is it expected to read ENV vars from remote host of ansible inventory? | 15:35 |
| gtema | every module takes "cloud" param. This can be either "name" from clouds.yaml or whole structure same way as in clouds.yaml. So if you read it from inventory/vault/whatever_is_secure_for_you - all is done without concerns | 15:37 |
| gtema | and this is exactly how AWX/Ansible was always designed - you have secrets in the tool that is executing playbook and they are passed securely to the module without writing to the FS | 15:38 |
| tomas_mensik | well I was just expecting from ansible modules to have similar flexibility as openstack client/sdk has. Unfortunately it is not mentioned in documentation. And if you don't rely only on the ansible then it makes sense to keep as much of configuration on only one places - which is clouds.yaml for me. | 15:52 |
| gtema | personally disagree with that (from experience) - for every use case you should use the most suitable approach, and for ansible this is multi-fold. If you try to invoke you playbooks through AWX or similar thing (i.e. even inside Zuul jobs it is used this way) - you pass whole structure instead of writing clouds.yaml on a remote host | 15:54 |
| *** dviroel|lunch is now known as dviroel| | 16:21 | |
| *** dviroel| is now known as dviroel | 16:21 | |
| frickler | I also would consider it more of a bug than a feature for OSC to take data from both OS_CLOUD and OS_PASSWORD. like what happens when the cloud entry is using app creds instead of user+pass? | 16:38 |
| gtema | sdk need to support so many different ways of configuring that it is no surprise things like that happen. Especially that OSC here may merge things on it's side rather | 16:39 |
| gtema | than delegating it all to sdk. Think it doesn't happen, but OSC is also doing few things around | 16:40 |
| opendevreview | Rafael Castillo proposed openstack/ansible-collections-openstack master: Refactor server_volume to be compatible with openstacksdk>=0.99.0 https://review.opendev.org/c/openstack/ansible-collections-openstack/+/858834 | 17:19 |
| opendevreview | Rafael Castillo proposed openstack/ansible-collections-openstack master: Updates volume for 2.0.0 https://review.opendev.org/c/openstack/ansible-collections-openstack/+/853749 | 18:05 |
| *** dviroel_ is now known as dviroel | 18:28 | |
| *** dviroel is now known as dviroel|biab | 19:51 | |
| *** rcastillo_ is now known as rcastillo | 23:30 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!