Puppet users - Feb 2012 - Removing the ability to serve symlinks as symlinks from the master...

G''day.

We recently found some issues with the `links => follow` setting in
recursive file copying; the designed behaviour is that it should allow
you to determine if the master serves a symlink in a module as a
symlink, or as the content of the file that the symlink points to.

The full details are here: https://projects.puppetlabs.com/issues/12418

The short version is that toggling that value doesn''t work right - it
won''t notice changes from "don''t follow" to
"follow".


Our general feeling is that putting a symlink in a module, and
expecting the same symlink to be created on the agent, is a bad
strategy.  It depends heavily on a whole lot of complex things, adds
substantial complexity to the file serving code, and won''t work on all
platforms in a sensible fashion.


That is a substantial feature to drop, though, so we wanted to gather
some more information on how people use this capability and what y''all
think about it.

If folks would take a minute and fill in a brief survey about this,
that would be great:
https://docs.google.com/a/rimspace.net/spreadsheet/viewform?formkey=dGE2R09HZ2tIdFFSdDhHQ3dQOHVGZlE6MQ

We will be using the data from that form as one of the most
significant parts of our decision, so while we welcome feedback by
email, or on the ticket, adding the raw data to the survey is pretty
valuable.

Feel free to get in touch with me if you have any further feedback on
this process, the survey, or any other "meta issue" around how we are
managing this.  This is, obviously, a new way to try and figure out
what we should do, and we want to make sure that we catch any problems
with it early.

Thanks.
-- 
Daniel Pittman
⎋ Puppet Labs Developer – http://puppetlabs.com
♲ Made with 100 percent post-consumer electrons

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Feb 13, 4:58 pm, Daniel Pittman <dan...@puppetlabs.com>
wrote:
> G''day.
>
> We recently found some issues with the `links => follow` setting in
> recursive file copying; the designed behaviour is that it should allow
> you to determine if the master serves a symlink in a module as a
> symlink, or as the content of the file that the symlink points to.
>
> The full details are here:https://projects.puppetlabs.com/issues/12418
>
> The short version is that toggling that value doesn''t work right -
it
> won''t notice changes from "don''t follow" to
"follow".
>
> Our general feeling is that putting a symlink in a module, and
> expecting the same symlink to be created on the agent, is a bad
> strategy.  It depends heavily on a whole lot of complex things, adds
> substantial complexity to the file serving code, and won''t work on
all
> platforms in a sensible fashion.

There seems to be considerable confusion, or at least imprecision, in
the description of the issue here, in the discussion in the bug
database, and in the survey.  As I understand it, the issue is not
with "putting a symlink in a module" but rather with recursively
managing a directory tree that contains symlinks.  Modules appear to
have nothing to do with it -- it''s all about the behavior of the File
resource type.

Inasmuch as I am not 100% certain that I have parsed that all out
correctly, however, I am confident that others will be confused, too.
For the discussion and survey to be meaningful, the terms and
questions need to be clear.  That will also better inform whoever ends
up picking up the resulting programming task, whatever that task ends
up being.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, Feb 14, 2012 at 06:54, jcbollinger <John.Bollinger@stjude.org>
wrote:
> On Feb 13, 4:58 pm, Daniel Pittman <dan...@puppetlabs.com> wrote:
>>
>> We recently found some issues with the `links => follow` setting in
>> recursive file copying; the designed behaviour is that it should allow
>> you to determine if the master serves a symlink in a module as a
>> symlink, or as the content of the file that the symlink points to.
>>
>> The full details are here:https://projects.puppetlabs.com/issues/12418
>>
>> The short version is that toggling that value doesn''t work
right - it
>> won''t notice changes from "don''t follow" to
"follow".
>>
>> Our general feeling is that putting a symlink in a module, and
>> expecting the same symlink to be created on the agent, is a bad
>> strategy.  It depends heavily on a whole lot of complex things, adds
>> substantial complexity to the file serving code, and won''t
work on all
>> platforms in a sensible fashion.
>
> There seems to be considerable confusion, or at least imprecision, in
> the description of the issue here, in the discussion in the bug
> database, and in the survey.  As I understand it, the issue is not
> with "putting a symlink in a module" but rather with recursively
> managing a directory tree that contains symlinks.  Modules appear to
> have nothing to do with it -- it''s all about the behavior of the
File
> resource type.
That is more or less true; modules are relatively unrelated to this,
although part of the motivation is understanding how to make things
more predictable so we have less headache getting reusable modules
built up.

It shouldn''t require recursive file copying for this to take effect, I
think, but the uncertainty is part of the motivation here.

Thanks for the feedback; we did look that content over before we
released it, but we will try and put more effort into pre-testing the
explanation before we release it to the wild in future.

-- 
Daniel Pittman
⎋ Puppet Labs Developer – http://puppetlabs.com
♲ Made with 100 percent post-consumer electrons

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Feb 15, 3:29 pm, Daniel Pittman <dan...@puppetlabs.com>
wrote:
> On Tue, Feb 14, 2012 at 06:54, jcbollinger
<John.Bollin...@stjude.org> wrote:
> > [...]  As I understand it, the issue is not
> > with "putting a symlink in a module" but rather with
recursively
> > managing a directory tree that contains symlinks.  Modules appear to
> > have nothing to do with it -- it''s all about the behavior of
the File
> > resource type.
>
> That is more or less true; modules are relatively unrelated to this,
> although part of the motivation is understanding how to make things
> more predictable so we have less headache getting reusable modules
> built up.

Fair enough.

As to the main issue, then, I recognize that the File resource''s
recursive directory management is a perpetual source of headaches, but
I''m not seeing why its documented (but failing) behavior with respect
to symlinks is inherently worse than the rest of the recursive
management stuff.   Nor do I see why recursive management of symlinks
as symlinks presents a particular issue for reusable modules.

Furthermore, if it makes sense (and it does) for the File resource to
be able to manage individual symlinks via "ensure => link",
possibly
augmented by "force => true", then why would it not make sense to
provide the same capabilities in a recursive situation?  Indeed, it
would present an internal consistency problem if Puppet were willing
to manage symlinks only for individual File resources, and not
recursively.

> It shouldn''t require recursive file copying for this to take
effect, I
> think, but the uncertainty is part of the motivation here.

If the File resource behaved as documented then there would be no
uncertainty.  With "recurse => true, links => manage, force =>
true"
the File resource would always manage a node''s corresponding directory
tree into an exact match to the master''s.  Where is the uncertainty in
that?

The uncertainty arises because of a *bug*.  Removing the buggy feature
would clear up the uncertainty, but so would fixing the bug.  Ergo,
uncertainty is not a valid argument for removing the feature.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Feb 13, 4:58 pm, Daniel Pittman <dan...@puppetlabs.com>
wrote:
> If folks would take a minute and fill in a brief survey about this,
> that would be
great:https://docs.google.com/a/rimspace.net/spreadsheet/viewform?formkey=d...
Even with the clarification, I can''t fill out the survey.  An answer
to the second question is required, but there is no option for "I have
no third-party modules on my system".  None of the available options
applies.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 02/16/2012 03:30 PM, jcbollinger wrote:
>
> If the File resource behaved as documented then there would be no
> uncertainty.  With "recurse =>  true, links =>  manage, force
=>  true"
> the File resource would always manage a node''s corresponding
directory
> tree into an exact match to the master''s.  Where is the
uncertainty in
> that?
Agree, and I would expect Puppet to behave this way.

If I wanted a symlink, I''d force create a symlink on the master and 
expect it to be created exactly the same on the agent. If I wanted that 
symlink to point to a file with some content, I''d manage the real path.

To me, a symlink is just a pointer with no content. Simple as that.

I didn''t know about the ''links => follow'' setting
and I''d argue that
feature is a bit misguided. I wouldn''t expect or maybe even want Puppet
to have this ability.

-- 
http://www.uib.no/personer/Jan.Ivar.Beddari

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.