Hi,
For the Gentoo Portage “emerge” module creation i confirm what i have thinked about creating the sysctl module :
Why the python modules ; and/or the python core modules must leak the call of the main function assuming that the INCLUDE_ANSIBLE_MODULE_COMMON will insert “ansible_main()” too ?
This will not change something for python module developers based on INCLUDE_ANSIBLE_MODULE_COMMON .
And this will permit to ansible developers to add some tests for their modules (called on make tests) :
Assume for example :
#!/usr/bin/python
GPL lines
DOCUMENTATION = ‘’‘’‘’
def my_smart_function(input):
return input + ‘_expanded’
def ansible_test:
first test
res = my_smart_function(‘test’)
if res != ‘test_expanded’:
return False
end
return True
def ansible_main:
module = AnsibleModule(
[…]
)
my smart code here, for example :
args = { ‘new_state’: my_smart_function(module.params[‘input’]) }
module.exit_json(changed=True, **args)
sys.exit(0)
this is magic, see lib/ansible/module_common.py
#<<INCLUDE_ANSIBLE_MODULE_COMMON>>
Here the idea.
It will permit to call ansible_main or ansible_test in function of the needs, and permit a "one file module integration’'.
Thinking for light module synced to managed hosts, we can imagine a
Sorry for the prematured post; here the end :
Sorry for the prematured post; here the end :
----
Thinking for light module synced to managed hosts, we can imagine a wrapper
filtering the DOCUMENTATION string, and the ansible_test implementation.
Are we seeing any signs of transferring the documentation string
causing signfiicant performance implications? I can't imagine that
being a large measurable chunk.
If you can produce some benchmarks I'm open to considering it though.
This point is minor and symbolic.
Please look at the first post in the thread for the real subject.
David CHANIAL
I don't really follow what you are trying to say.
Can you rephrase that?
I don’t really follow what you are trying to say.
Can you rephrase that?
Hi,
For the Gentoo Portage “emerge” module creation i confirm what i have thinked about creating the sysctl module :
Why the python modules ; and/or the python core modules must leak the call of the main function assuming that the INCLUDE_ANSIBLE_MODULE_COMMON will insert “ansible_main()” too ?
This will not change something for python module developers based on INCLUDE_ANSIBLE_MODULE_COMMON .
And this will permit to ansible developers to add some tests for their modules (called on make tests) :
Assume for example :
#!/usr/bin/python
GPL lines
DOCUMENTATION = ‘’‘’‘’
def my_smart_function(input):
return input + ‘_expanded’
def ansible_test:
first test
res = my_smart_function(‘test’)
if res != ‘test_expanded’:
return False
end
return True
def ansible_main:
module = AnsibleModule(
[…]
)
my smart code here, for example :
args = { ‘new_state’: my_smart_function(module.params[‘input’]) }
module.exit_json(changed=True, **args)
sys.exit(0)
this is magic, see lib/ansible/module_common.py
#<<INCLUDE_ANSIBLE_MODULE_COMMON>>
Here the idea.
It will permit to call ansible_main or ansible_test in function of the needs, and permit a "one file module integration’'.
Thinking for a symbolic light module synced to managed hosts, we can imagine a wrapper filtering the DOCUMENTATION string, and the ansible_test implementation.
Here the idea.
It will permit to call ansible_main or ansible_test in function of the
needs, and permit a "one file module integration''.
Thinking for a symbolic light module synced to managed hosts, we can imagine
a wrapper filtering the DOCUMENTATION string, and the ansible_test
implementation.
What does this gain us other than a possible bandwidth savings?
forget this point please.
focus only on the test function.
Ok.
I'm still confused what you want to do with a test function.
Can you explain your use case differently?
I will come back until the end of the week with samples.