-
Notifications
You must be signed in to change notification settings - Fork 47
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
API update #128
API update #128
Conversation
…alue at the same time Signed-off-by: Tomas Herfert <herfik>
Signed-off-by: Tomas Herfert <herfik>
Signed-off-by: Tomas Herfert <herfik>
Signed-off-by: Tomas Herfert <herfik>
Codecov Report
@@ Coverage Diff @@
## main #128 +/- ##
==========================================
- Coverage 87.56% 87.34% -0.23%
==========================================
Files 28 28
Lines 3499 3516 +17
Branches 619 626 +7
==========================================
+ Hits 3064 3071 +7
- Misses 308 313 +5
- Partials 127 132 +5
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Docs Build 📝Thank you for contribution!✨ This PR has been merged and your docs changes will be incorporated when they are next published. |
Hi @felixfontein! Could you please re-run the checks? (the sanity failed because of some network issues again). Thanks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see how default
and can_disable
can be used together. If there is a default and the value is not returned by the API, the modules treat the value of that field as the default value. If the field can be disabled and is not returned by the API, it is treated as disabled. If a field both has a default and is specified as 'can_disable', how should the module now handle the case that the value is not returned by the API?
See the However the field can be explicitly disabled and then field isn't returned by the API. See the following:
Here you can see how api_modify works (with the proposed change):Module parameters:
First run
Second run (module is idempotent):
disabling keepalive - new parameters:
First run
second run (module is idempotent)
if I remove the "keepalive:" from the data now, it would again set the default as on the first run. current behaviour (without the proposed change)1st option:
|
Co-authored-by: Felix Fontein <[email protected]>
Ok, I understand now why it is necessary. I want to to through the other code in more depth though to make sure we're not forgetting to change a place which would be affected by this as well. |
Thanks! |
Signed-off-by: Tomas Herfert <herfik>
I added |
I think you need the following change as well if such paths should ever be used in the tests: diff --git a/tests/unit/plugins/modules/fake_api.py b/tests/unit/plugins/modules/fake_api.py
index b17c088..f50c996 100644
--- a/tests/unit/plugins/modules/fake_api.py
+++ b/tests/unit/plugins/modules/fake_api.py
@@ -120,7 +120,7 @@ class Or(object):
def _normalize_entry(entry, path_info):
for key, data in path_info.fields.items():
- if key not in entry and data.default is not None:
+ if key not in entry and data.default is not None and not data.can_disable:
entry[key] = data.default
if data.can_disable:
if key in entry and entry[key] in (None, data.remove_value): Besides that, it looks good to me! |
Signed-off-by: Tomas Herfert <herfik>
@felixfontein done. btw. I also thought about the tests, but I had never done that and didn't really know where to start. (I'm not a developer :D ) |
Thanks again for yet another contribution :) |
SUMMARY
interface gre
ISSUE TYPE
COMPONENT NAME
ADDITIONAL INFORMATION
data
andhandle_entries_content
isn'tignore
. It also covers a situation when the field is currently disabled in ROS.interface gre
fieldkeepalive
as an example where this is required.