-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
zfs.py: treated received properties as local and added diff mode support #502
Conversation
It might make sense to split this up into two PRs: one fixing the bug, and one to add the diff feature. I don't know the module, but I can say that the diff part looks good. If it would be only this (and a fitting changelog fragment), I'd be happy to merge it. For the bugfix I can't really say anything. |
As the bugfix was just a very tiny change I didn't considere it worth a separate PR, hence I combined the bugfix and the new features into one PR. In the meantime I created the changelog fragment for this PR and committed it to my branch froebela/community.general:patch-1. Finally I wanted to state, that the bugfix and the diff mode support was tested successfully in our environment. |
The test
|
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.
Changelog fragment and diff code look good. Cannot comment on the bugfix though.
I did my best in order to rebase my PR, resolve the conflicts and force-push it back to GitHub. I also added a new commit including some minor changes to the diff data structure. Now there are some failed checks. Unfortunately I don't really see, what they are about and how to fix them. Perhaps someone can help me. |
The Details view says:
BTW, you should still split up this into two PRs: one for diff mode (a feature), one for the bugfix. |
Because I thought about opening another bug fix PR anyway, I'll finally follow your advice and split this PR (keep the diff mode feature). Do I need to take the failed checks seriously? The one you mentioned complained about over-indentation. Yes, it’s true, but I did it for better readability and don’t really understand the problem with it. Do you know the exact rule, I'm in conflict with? |
PRs that fail sanity tests will not be merged.
|
else: | ||
zfs.create() | ||
result['diff'] = {'before': {'state': 'absent'}, 'after': {'state': state}} |
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'm not too familiar with Ansible's diff mode, but this seems a bit confusing. If the ZFS dataset already exists, then the keys of diff['before']
and diff['after']
will be the names of ZFS properties. If the ZFS dataset did not exist, then the only key will be the special string 'state'
, which is not a ZFS property.
As I mentioned, I don't use diff mode too often, so maybe this is a non-issue. It just seems slightly confusing.
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.
It would probably be nicer to include the current properties in diff['before']
, and an empty dict in diff['after']
for state=absent
, and the reverse for state=present
. But this is also fine for me. It usually depends on how much work someone wants to invest in implementing this :)
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 needed some time to do some research on this topic. Well, I couldn't find any specific guidelines for the output of the diff mode, hence I tried to use some other modules as an example. First of all I wanted to work with the information at hand and didn't want to generate new ones. Therefore I couldn't create a more detailed diff structure in case of creation or deletion. But this seems to be typical for other modules too, hence I'd like to keep it this way. In order to address the remark about mixing state and zfs property information, I added an extra dict to better differentiate that. I hope, the diff output it clearer now.
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.
Sounds reasonable to me.
Looks good to me! |
@mator any more comments from your side? |
If nobody complains, I'll merge this on Monday. |
Backport to stable-3: 💚 backport PR created✅ Backport PR branch: Backported as #3304 🤖 @patchback |
…ort (#502) * zfs.py: treated received properties as local and added diff mode support If you use "zfs set" to explicitly set ZFS properties, they are marked as from source "local". If ZFS properties are implicitly set by using "zfs send" and "zfs receive", for example as part of a template based installation, they are marked as from source "received". But as there is no technical difference between both types of them, the “received” ZFS properties should also be considered “local”. Otherwise Ansible would detect changes, which aren’t actual changes. Therefore I changed line 202/207 to reflect this. For us it’s quite important, that Ansible modules support the diff mode in order to qualify changes. Therefore I added some code lines to address this. * added changelog fragment for PR #502 * fixed typos in changelog fragment for PR #502 * minor changes in changelog fragment for PR #502 * added link to pull request in changelog fragment for PR #502 * extended the diff data structure to always include the name of the zfs filesystem * added code to also maintain the diff data structure after a change * reverted back some code lines for better code readability * added an extra dict in the diff data structure to hold the zfs properties (cherry picked from commit baa721a)
To be honest, I can't really believe, that my PR finally made it into the main branch. Thanks for your support and your patience. As you might have noticed, this was my first PR. So I've learned a lot and hope, that things run more smoothly next time. Thanks once again to all, who contributed to this PR in any way! |
…ort (#502) (#3304) * zfs.py: treated received properties as local and added diff mode support If you use "zfs set" to explicitly set ZFS properties, they are marked as from source "local". If ZFS properties are implicitly set by using "zfs send" and "zfs receive", for example as part of a template based installation, they are marked as from source "received". But as there is no technical difference between both types of them, the “received” ZFS properties should also be considered “local”. Otherwise Ansible would detect changes, which aren’t actual changes. Therefore I changed line 202/207 to reflect this. For us it’s quite important, that Ansible modules support the diff mode in order to qualify changes. Therefore I added some code lines to address this. * added changelog fragment for PR #502 * fixed typos in changelog fragment for PR #502 * minor changes in changelog fragment for PR #502 * added link to pull request in changelog fragment for PR #502 * extended the diff data structure to always include the name of the zfs filesystem * added code to also maintain the diff data structure after a change * reverted back some code lines for better code readability * added an extra dict in the diff data structure to hold the zfs properties (cherry picked from commit baa721a) Co-authored-by: froebela <[email protected]>
SUMMARY
If you use "zfs set" to explicitly set ZFS properties, they are marked as from source "local". If ZFS properties are implicitly set by using "zfs send" and "zfs receive", for example as part of a template based installation, they are marked as from source "received". But as there is no technical difference between both types of them, the “received” ZFS properties should also be considered “local”. Otherwise Ansible would detect changes, which aren’t actual changes. Therefore I changed line 202/207 to reflect this.
For us it’s quite important, that Ansible modules support the diff mode in order to qualify changes. Therefore I added some code lines to address this.
ISSUE TYPE
COMPONENT NAME
ADDITIONAL INFORMATION