-
Notifications
You must be signed in to change notification settings - Fork 23.7k
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
Fixed netapp_e_lun_mapping options for backwards compatibilitiy #44769
Conversation
ed8bdd7
to
3a84eab
Compare
@@ -89,7 +103,9 @@ def __init__(self): | |||
argument_spec.update(dict( | |||
state=dict(required=True, choices=["present", "absent"]), | |||
target=dict(required=False, default=None), | |||
volume_name=dict(required=True))) | |||
volume_name=dict(required=True, aliases=["volume"]), | |||
lun=dict(required=False), |
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.
Why has this been added?
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.
We simply found volume_name to be unnecessarily verbose and thought adding volume as an alias would help.
- volume | ||
lun: | ||
description: | ||
- This option is deprecated and will have no effect on the module's outcome |
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.
Confused, why has this been added if it's deprecated?
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.
The previous merge removed the two options, lun and target_type, that should have been deprecate instead for backwards capability. How should I correct my mistake?
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.
So if these options don't do anything that seems to break backwards compatability
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.
If there are existing customer plays that contain the two options, the module will still work as expected but we simplified the logic such that the two options are not needed. The netapp e-series restapi already had the capability to determine those options without customers explicitly stating them.
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.
Could the existing customer set these deprecated options to something other than what the restapi would automatically do, ie surprise the user?
If these options don't do anything then removing them maybe the right decision. A note:
should be added in the he modules docs and in porting_guide_2.7.rst
required: no | ||
target_type: | ||
description: | ||
- This option is deprecated and will have no effect on the module's outcome |
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.
Why has this been added if it's deprecated?
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.
@gundalow There was a patch submitted to resolve a different issue a few days ago. (#44666). This patch removed a few parameters from the module that we realized really weren't necessary. Unfortunately, removing those fields would cause existing playbooks utilizing those parameters to break (that's my fault for not remembering that). This patch is adding those back in (as deprecated fields), to maintain existing playbooks. Does that make sense?
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.
If these options don't do anything then I think it may be confusing for the end user to leave them in but not used
@ndswartz this PR contains the following merge commits: Please rebase your branch to remove these commits. |
@ndswartz You'll need to squash this back down to a single commit. |
265aee9
to
7a25960
Compare
@ndswartz this PR contains the following merge commits: Please rebase your branch to remove these commits. |
The test
|
f19fd1a
to
ae8487e
Compare
Readd lun and target_type as deprecated options. Note: lun and target_type were removed in patch ansible#44666 since they were no longer needed for the logic in the module. However, this cause will cause existing playbooks utilizing these options to break.
9ee8cf7
to
84ddc73
Compare
Could the existing customer set these deprecated options to something other than what the restapi would automatically do, ie surprise the user? If these options don't do anything then removing them maybe the right decision. A note: should be added in the he modules docs and in porting_guide_2.7.rst Is these options don't done do anything I'm not sure in the value of keeping them. |
751b22c
to
69b871a
Compare
@gundalow After some discussion resulting from your question about surprising the user, we realized that there is a possibility of ambiguity that a host target and a group target could have the same name. Furthermore it is also possible that the customer could specify a host target_type when in reality it is a group target and vice-versa. So, we have added functionality to both the target_type and the lun options. The target_type option will be optionally used to disambiguate mappable objects and lun will give the user the flexibility to specify the lun value. |
SUMMARY
Readded options lun and target_type which should have been deprecated instead of being removed.
ISSUE TYPE
COMPONENT NAME
netapp_e_lun_mapping
ANSIBLE VERSION