Closed badnetmask closed 3 years ago
I'm not sure what the future of the nios modules in community.general is. I've heard talk that they should be moved to their own collection, but that won't happen in the near future (since the deadline for that passed). @gundalow do you have more info on what will happen to the nios modules? Or who is looking after them right now?
Ah, the current state is probably summed up in this issue: https://github.com/infobloxopen/infoblox-ansible/issues/7 (Which is pretty much: no news.)
cc @NilashishC @Qalthos @brampling @danielmellado @ganeshrn @nerzhul @privateip @sganesh-infoblox @trishnaguha click here for bot help
Hello, we are very interested in the API authentication feature. It seems that PR referenced by @felixfontein is now merged ? https://github.com/infobloxopen/infoblox-ansible/pull/12
I don't understand well if it was a prerequisite to start working on feature proposal by @badnetmask ?
Do anybody have a clue if this feature may be of interest to other people in the community (@Vaishnavi-infoblox) ? I'm not able to develop it but I sure will be available for test and review.
I guess it depends on what happens with the infoblox collection. If it gets included in Ansible, we should really remove the modules here and redirect them to that collection. If not, well, I'm not sure what to do... Maybe deprecate the modules here and tell users to explicitly install and use that collection, assuming that the collection has all fixes incorporated that were added here.
I believe either @Vaishnavi-infoblox or @anagha-infoblox should have a better answer than me. I have been pushing some contributions under the collection project, but since I was told by @justjais that there would be a different direction with this module, this issue kind of slipped my mind. I'm willing to work on it though, just need to know what direction the project is taking (or if someone is already working on it and I am unaware).
In any case, I don't think we will accept new features for the modules in this collection. So if you want to work on this, you need to do that in the infoblox.nios_modules repository.
hi @badnetmask tudo bom? :brazil:
As mentioned before, it will make more sense to work on this issue in the context of the infoblox.nios_modules repository. Given that, is there any particular reason for us to keep this issue open here? TIA
Thank you very much for your interest in Ansible. This plugin/module is no longer maintained in this repository and has been migrated to https://github.com/infobloxopen/infoblox-ansible
Migrated this issue in the above repository - https://github.com/infobloxopen/infoblox-ansible/issues/64.
If you have further questions please stop by IRC or the mailing list:
SUMMARY
This is a copy/follow-up on a previously discussed issue: https://github.com/ansible/ansible/issues/51402
The current authentication implementation of the NIOS (Infoblox) modules makes use of statically defined variables for username and password, to be used in every single task. This breaks the use of dynamic authentication methods, like in environments that use time-based password (token/2FA).
The NIOS WAPI provides a cookie (ibapauth), which can be retrieved on the first authentication, and re-used on every subsequent call. Using this cookie would prevent the need to re-send the password for every task.
ISSUE TYPE
COMPONENT NAME
nios_* nios_network nios_zone nios_a_record nios_cname_record
ADDITIONAL INFORMATION
The final usage of this feature would make the NIOS-related playbooks behave like any other playbook that uses the "ovirt_*" modules. On those modules, the first task of the playbook is the authentication, which then generates an internal Ansible variable, which contains the authentication token, and is-reused for ever subsequent calls to the oVirt API. (examples can be found on: https://www.ovirt.org/develop/release-management/features/infra/ansible_modules.html)
As previously discussed with @justjais, in order to implement this feature, this module needs to be migrated to
httpapi
first, so that it no longer depends on the underlyinginfoblox-client
Python library, allowing it to properly implement cookie-based authentication.Below is an example of how a NIOS playbook would look like, if this authentication token would be implemented: