-
Notifications
You must be signed in to change notification settings - Fork 19
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
All file modules should have a sane default follow
parameter
#69
Comments
follow
parameter
stat might be the exception we want to keep as is, just because you are trying to identify what a path is. |
Yeah, I mentioned both stats and find, but we should check with other modules as well.
|
Talked about at this week'd Core meeting and had the following feedback: There's really several categories of file module which seem like they should have different default values for follow (names negotiable):
Action plan:
|
Sorry for not being able to join you guys during the meeting, but I wasn't near a workstation at the time. I agree with all, I'm only not sure if replacers should be Very happy about the decided changes and thanks for being fast and responsive about this (important) issue. I guess this change will be expected for 2.5? |
@kustodian I forgot to ask, could you make the updates to the proposal? We were just talking today about how to allocate manpower to work on implementing proposals as a general problem. When one of the Core devs submits a proposal it often means they are willing to work on it. When a community member submits a proposal because they want some guidance on how to implement a PR then that contributor usually is going to work on it once the proposal is approved. It's when a proposal is raised by someone who sees a problem but isn't going to work on it themselves that we have an issue. Step 1 is approving the proposal so everyone can see what the plan is. But that still leaves Step 2 of finding someone with the time to actually make the changes to the modules.... |
@abadger I will certainly update the proposal, that is not a problem. If it's approved I should be able to work on it as well, because the changes to the modules should be pretty straight forward, even though there is a lot of them. My biggest concern would be tests, not sure how much time those would take, last time I need to modify a unit test for a connection plugin wasn't a good experience. I noticed that you wrote integration tests, which means playbooks, that should be fine. Now about the update, what exactly did you mean by:
Did you mean adding more categories if not all modules fit into these ones? |
@abadger I sorted all the modules into categories, tried all of them to see how they work with following symlinks and updated the proposal. As far as I can see only 5 modules need to be updated |
Proposal: All file modules should have a sane default
follow
parameterAuthor: Strahinja Kustudic @kustodian
Date: 2017/08/31
Motivation
Currently file modules have mixed "feelings" about weather should they follow symlinks, or not. Here is a table how it is currently implemented:
N/A
meansfollow
parameter doesn't exist and I didn't check in the code how it works.It would be great if all modules used the same and sane default value, because like this it doesn't make any sense, later on for new modules that default value could be forced.
Also I would recommend to make the default value depend on how the Unix commands which these modules emulate work. In most cases this should be to follow symlinks, e.g. if I'm editing a symlink to a file (e.g.
vim linktofile
), it will actually edit a file, it won't edit a symlink. On the other handcp file1 linktofile
would actually replace a link with file1, butcp file1 linktodir
would copy the file1 into the directory the link points to.Problems
Some of the modules don't work as you would expect them to work and the work inconsistently:
blockinfile
/etc/rc.local
which actually is a symlink to/etc/rc.d/rc.local
it will actually replace the symlink with the file it generates, and basically break the/etc/rc.local
functionality.yes
, someno
, for some of them you don't even know until you try it out.Solution proposal
follow
parameter doesn't exist, hard code it, or just in case implement it).lineinfile
,replace
,blockinfile
,patch
,template
,assemble
,ini_file
) the sane default value isyes
. If for some reason you don't want to follow symlinks, you should set it manually tono
because you are doing something out of the ordinary.find
andstat
don't follow symlinks by default, so those modules shouldn't as well.This shouldn't make a big impact to the users, but it can still be announced as a breaking changed, even though most of the users shouldn't notice any issues.
UPDATE 05. Oct 2017.
After the discussion on the community meeting, here are all the modules categorized by their type, so that we know what needs to changed on each module.
Replacers
follow=no
Bulk Replacers
folloy=yes
follow=no
Modifiers
follow=yes
because most attributes on most systems can't be applied to symlinks, only to the files they point toEditors
Stat/find
follow=no
Other
Summary
This means only
fetch (flat=yes)
,file
,blockinfile
,patch
andreplace
need to be updated.The text was updated successfully, but these errors were encountered: