Autorequiring parent directories to the home directory in user resources

[Raphaël Pinson]

Hello,

As per Kylo's comment in PR for PUP-4036, I'd like to discuss the possibility and implications of autorequiring parent directories of the home directory for user resources.

As stated in the PR, the idea came from stumbling upon a code like this one:

file { '/srv/home': ensure => directory }
file { '/home': ensure => link, target => '/srv/home' } -> User <| |>

where it made a lot of sense that all users should just autorequire the nearest parent directory to their home directory.

What are your thoughts on this feature?

Cheers,

Raphaël

[Trevor Vaughan]

I think I filed a bug about this a while back.

+1 for autorequiring targets

Trevor

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/9c55b0bf-eae3-41f9-8103-e69870f1297d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

[John Bollinger]

On Wednesday, February 25, 2015 at 6:06:33 PM UTC-6, Trevor Vaughan wrote:

I think I filed a bug about this a while back.

+1 for autorequiring targets

I'm inclined to disagree.  Autorequiring should be reserved for cases where the requirement is inherent in the resource's nature.  Files' dependencies on their parent directories are a good example (except when ensuring 'absent'): when a file and its directory are both under management, you cannot be confident of managing the file properly if you do not first manage its directory.

Symbolic links do not have the same kind of relationship with their targets.  A link can be managed entirely independently of its target, therefore Puppet should not automatically demand a particular order.  As a general rule, it is important for resource types to model their corresponding physical resources as cleanly as possible, lest unintended consequences arise.  In this particular case, autorequiring link targets can create dependency cycles in cases that would otherwise be perfectly good.

I observe, too, that in the example presented, the convenience afforded by the proposed autorequirement is a function of the *use* of the resource, not inherent in the resource itself.  Puppet cannot know that, or be expected to account for it.  It is the manifest author who should be expected to take responsibility for modeling such site-specific requirements.


John

[David Schmitt]

On 2015-02-26 20:31, John Bollinger wrote:
> On Wednesday, February 25, 2015 at 6:06:33 PM UTC-6, Trevor Vaughan
> wrote:
>
>> I think I filed a bug about this a while back.
>>
>> +1 for autorequiring targets

+1 from me too. Slightly conditional on the discussion below.

> I'm inclined to disagree. Autorequiring should be reserved for cases
> where the requirement is inherent in the resource's nature. Files'
> dependencies on their parent directories are a good example (except
> when ensuring 'absent'): when a file and its directory are both under
> management, you cannot be confident of managing the file properly if
> you do not first manage its directory.
>

> Symbolic links do _not_ have the same kind of relationship with their

> targets. A link can be managed entirely independently of its target,
> therefore Puppet should not automatically demand a particular order.
> As a general rule, it is important for resource types to model their
> corresponding physical resources as cleanly as possible, lest
> unintended consequences arise. In this particular case, autorequiring
> link targets can create dependency cycles in cases that would
> otherwise be perfectly good.

Examples please? Everything I can currently think of right now (and
it's night time here, so please be gentle) would create invalid
filesystem layouts if the symlink points to one of it's own
subdirectories. Or, maybe a scenario where /srv/app is owned by
app_user, whose home directory is below /srv/app/something. But that
would be a cycle /srv/app -> owner -> home -> /srv/app without any
symlink.

> I observe, too, that in the example presented, the convenience
> afforded by the proposed autorequirement is a function of the *use*
> of
> the resource, not inherent in the resource itself. Puppet cannot know
> that, or be expected to account for it. It is the manifest author who
> should be expected to take responsibility for modeling such
> site-specific requirements.

I would argue, that the primary *use* of a symlink is to point to
something. Even in the obscure case of pointing to something that is
managed as ensure=>absent, I would posit that the intended state of the
symlink is only reached after its target's managed state is reached too.


Regards, David
>
> John

>
> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it,

> send an email to puppet-dev+...@googlegroups.com [1].

> To view this discussion on the web visit
>

> https://groups.google.com/d/msgid/puppet-dev/1aecc279-4620-4a36-bfb4-8f38c9ea3479%40googlegroups.com
> [2].
> For more options, visit https://groups.google.com/d/optout [3].
>
>
> Links:
> ------
> [1] mailto:puppet-dev+...@googlegroups.com
> [2]
>
> https://groups.google.com/d/msgid/puppet-dev/1aecc279-4620-4a36-bfb4-8f38c9ea3479%40googlegroups.com?utm_medium=email&utm_source=footer
> [3] https://groups.google.com/d/optout

[Felix Frank]

Hi,

thanks for building this.

I must admit, I find the prospect a little frightening. The logic that
picks the autorequire target makes sense, but I see quite some potential
for surprising the user with weird dependency cycles.

What I'd like to see instead would be for the user type to actually
spawn a file resource that manages the home directory when managehome =>
true is in use.

There would be some perks to such an approach:
1. This would be backwards compatible (manifests that contain the home
directory will keep the resource from being generated again)
2. You get the autorequire for free (from the very file resource)
3. If issues arise, the user is presented with a very clear message
about just what resource just blew up in their face.

The key would be the additional resources generator. I did something
similar to the naginator types a while ago.

Cheers,
Felix

On 02/26/2015 12:41 AM, Raphaël Pinson wrote:
> Hello,
>
>
> As per Kylo's comment in PR for PUP-4036

> <https://github.com/puppetlabs/puppet/pull/3645#issuecomment-76032829>,

[Trevor Vaughan]

I still can't come up with a scenario where this would ever be an issue.

Auto-creating a resource (especially a directory) is a greater level of spooky action at a distance since it's actually *doing* something to your system and I'm very against that when possible. (It also bloats your catalog, but that's not as much of an issue).

Cases:

1Q) file { '/home': ensure => link, target => '/srv/home' }

1A) Broken symlink may be created, who cares

2Q)

file { '/home': ensure => link, target => '/srv/home' }

file { '/srv/home': ensure => directory }

2A) /srv/home gets created before /home, good stuff

3Q)

file { '/home': ensure => link, target => '/srv/home' }

file { '/srv/home': ensure => link, target => '/opt/home' }

3A) /home -> /srv/home -> <broken>. This is accurate

What other scenarios are there that I'm missing?

Trevor

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/54F0A279.20006%40alumni.tu-berlin.de.

For more options, visit https://groups.google.com/d/optout.

[John Bollinger]

On Thursday, February 26, 2015 at 2:28:22 PM UTC-6, David Schmitt wrote:

On 2015-02-26 20:31, John Bollinger wrote:

 

> Symbolic links do _not_ have the same kind of relationship with their
> targets. A link can be managed entirely independently of its target,
> therefore Puppet should not automatically demand a particular order.
> As a general rule, it is important for resource types to model their
> corresponding physical resources as cleanly as possible, lest
> unintended consequences arise. In this particular case, autorequiring
> link targets can create dependency cycles in cases that would
> otherwise be perfectly good.

Examples please? Everything I can currently think of right now (and
it's night time here, so please be gentle) would create invalid
filesystem layouts if the symlink points to one of it's own
subdirectories.

I don't think File autorequires would do it all by themselves, but they don't exist in a vacuum.  Any time you establish a constraint on the model space that does not reflect a genuine constraint on the target space, you make a portion of the target space impossible to model.  "Constraint" and "impossible" are a bit too strong here, of course, because you can override autorequires, but any circumstance in which you need to do so highlights a flawed autorequirement.

Here's a contrived example:

file { '/path/link':
  ensure => 'link,
  target => '/other/path'
  before => Exec['create-target-as-fifo']
}

exec { 'create-target-as-fifo':
  before => File['/other/path']
}

file { '/other/path':
  owner => 'fifo_own',
  mode => '0600'
}

The script 'create-target-as-fifo' is imagined to read the symlink dynamically to determine where a FIFO is supposed to live (i.e. the symlink's target), and create that FIFO if it does not already exist.  Afterward, Puppet manages the ownership and mode of the FIFO via an ordinary File resource.  This requires the symlink to be managed before its target, as is reflected in the declared relationships, and if Puppet adds a requirement of the type proposed then it closes a cycle.

I don't particularly expect that specific pattern to crop up in the wild, but I do expect all sorts of other weird stuff to crop up, and it would be unreasonable to assume that it will all be safe with respect to the proposed autorequirement.  If the use case served by the proposal were bigger or harder to serve by mechanisms already available in Puppet, then perhaps I would be more open to sacrificing correctness for convenience, but such is not the case.

 

> I observe, too, that in the example presented, the convenience
> afforded by the proposed autorequirement is a function of the *use*
> of
> the resource, not inherent in the resource itself. Puppet cannot know
> that, or be expected to account for it. It is the manifest author who
> should be expected to take responsibility for modeling such
> site-specific requirements.

I would argue, that the primary *use* of a symlink is to point to
something. Even in the obscure case of pointing to something that is
managed as ensure=>absent, I would posit that the intended state of the
symlink is only reached after its target's managed state is reached too.

To be sure, the intended state of the system is reached only after the link target's managed state is reached, but the state of the symlink itself does not depend on or incorporate the state of its target.  My example above serves as a plausible -- albeit unlikely -- counterexample.


John

[Trevor Vaughan]

Ok, you certainly have a working counter example, but I feel that it *should* actually fail and that this is a bug.

The expected state of the system is:

1) Make a FIFO file at /other/path
2) Set permissions on /other/path

3) Link /path/link to /other/path

I would like to propose that symlinks should naturally (i.e. autorequire*) come *after* all components of relevant file resources because otherwise they are systemically invalid.

A dangling symlink is a bad thing in every scenario that I can think which is probably why they're bright red in most shell syntax highlighting.

So, I still think that the autorequires on the target, in the case of a symlink, is the correct thing to do from both an expectation and semantic point of view.

Thinking about this further, should Puppet even be able to create invalid symlinks? I don't feel like it should as they can cause all sorts of havoc on a system with a code (expectation)-based infrastructure. Additionally, having Puppet complain on making a link to something that hasn't yet been mounted could be a very good thing since you would be aware that your underlying external system requirements have not been correctly met.

It *should* leave invalid symlinks alone unless told to remove them, of course.

Thanks,

Trevor

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/6b2d70cc-0293-4d66-8b32-08cd56ba130f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Felix Frank]

On 02/27/2015 06:22 PM, Trevor Vaughan wrote:
> I still can't come up with a scenario where this would ever be an issue.
>
> Auto-creating a resource (especially a directory) is a greater level
> of spooky action at a distance since it's actually *doing* something
> to your system and I'm very against that when possible. (It also
> bloats your catalog, but that's not as much of an issue).

I don't agree. You are not changing the system, you are changing
Puppet's behavior (towards being more consistent, I believe).

Another contrived example of an issue that could arise:

user { 'apprunner':
home => '/opt/vendor/main-app',
}

file { '/opt': owner => 'sysadmin' }

user { 'sysadmin': require => User['apprunner'] }

Yes, unlikely that such a require would be used. It might emerge from
class interdependencies, though, as part of a larger cycle.

Cheers,
Felix

[John Bollinger]

On Friday, February 27, 2015 at 2:51:03 PM UTC-6, Trevor Vaughan wrote:

Ok, you certainly have a working counter example, but I feel that it *should* actually fail and that this is a bug.

[...]

 

I would like to propose that symlinks should naturally (i.e. autorequire*) come *after* all components of relevant file resources because otherwise they are systemically invalid.

I have just demonstrated that dangling symlinks are NOT systematically invalid.  They have inherent significance, however limited.

In any event, don't lose sight of the fact that resource relationships are strictly about order of application, not about semantic associations between resources.  The validity of a symlink in light of other elements of the state of the system is a resource-relationship concern only to the extent that it affects whether the symlink or other resources can be applied.  Whether a dangling link is acceptable or wanted is an entirely separate issue.

It is, moreover, a good general idea to minimize the number of resource relationships by avoiding unneeded ones.  Although a relationship is needed (to ensure a viable order of application) in the case described in PUP-4036, that's unusual and case-specific.  It should also be readily visible to the manifest author, and easily fixable without changes to Puppet.

 

Thinking about this further, should Puppet even be able to create invalid symlinks?

Of course it should be able to do.  Puppet is my tool, not my nanny.  If the target system allows dangling symlinks then Puppet has no good reason to go out of its way to make it difficult to create them.  It doesn't know and shouldn't be expected to guess whether it's intentional, acceptable, or wrong for any particular link to dangle at any given time.

I'd be ok with warnings about dangling links, though, which potentially Puppet could emit even when the link is already in sync.

 

I don't feel like it should as they can cause all sorts of havoc on a system with a code (expectation)-based infrastructure. Additionally, having Puppet complain on making a link to something that hasn't yet been mounted could be a very good thing since you would be aware that your underlying external system requirements have not been correctly met.

It *should* leave invalid symlinks alone unless told to remove them, of course.

Can we at least have consistency?  If Puppet accepts dangling symlinks as a valid, in-sync target state for existing resources, then it should not refuse to manage resources into such a state.  On the other hand, if Puppet is unwilling to manage a symlink into a dangling state, then it should not accept an existing dangling symlink as being in sync.


John

[Trevor Vaughan]

Hmm....Ok, how about this:

1) Dangling symlinks are allowed

2) Warnings on dangling symlinks are the default (because you *probably* don't want them)

3) Setting :force => true, disables the warning message (in theory, you would only do this after seeing the message)

3a) For a less destructive method, something like 'dangle => true' could be allowed I suppose

4) Autorequires happen so that you don't get spurious warning messages

Would that work?

Thanks,

Trevor

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/5e3447ea-8ebe-4cfa-85df-56decb5506d4%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Reid Vandewiele]

On Monday, March 2, 2015 at 7:21:55 AM UTC-8, Trevor Vaughan wrote:

Hmm....Ok, how about this:

1) Dangling symlinks are allowed

2) Warnings on dangling symlinks are the default (because you *probably* don't want them)

3) Setting :force => true, disables the warning message (in theory, you would only do this after seeing the message)

3a) For a less destructive method, something like 'dangle => true' could be allowed I suppose

4) Autorequires happen so that you don't get spurious warning messages

Would that work?

It still seems presumptuous to me even to emit warnings by default if Puppet creates a symlink which is dangling at the time of creation. The assumption is that potential benefit of the alert would outweigh the cost of the potential noise and extra parameters required to silence it when dangling symlinks are desired.

Besides the crazy things symlinks get used for on occasion, such as Samba's use of dangling symlinks to represent DFS file shares, Puppet may legitimately be asked to create a link prior to installing a package or performing another action which will result in the target being created, and users shouldn't need to set :force or :dangle for their first run to log cleanly.

The potential benefit of the noise does not merit the extra complexity to silence it. This is an instance where Puppet cannot reasonably determine whether or not a dangling symlink is a problem and should not presume to do so.

[Trevor Vaughan]

Well, there's my concrete example of where dangling symlinks are used in the wild....

Ok, back to autorequires. I'm still not convinced that it's beneficial to not have it in place.

I suppose that I could do some hack-fu like I did with 'group' so that people that want it could patch it into place but that seems a bit unfortunate.

Are auto* items things that should be allowed to be disabled on a resource-by-resource basis using a Metaparameter? That way you can do the 'usual' thing but, should it cause an issue, just turn it off for that resource and declare things explicitly.

I'd much rather be able to shim in my own auto* items from the DSL (I mean, it's an Array), but this goes back to the 'if defined considered harmful' argument which, in turn, spawns John's "Puppet's not my Nanny" argument.

Good conversation and idea flow throughout!

Thanks,

Trevor

--

You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/1f9719c7-3729-4311-b93f-c386408f1e6d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[John Bollinger]

On Monday, March 2, 2015 at 1:50:08 PM UTC-6, Trevor Vaughan wrote:

Well, there's my concrete example of where dangling symlinks are used in the wild....

Ok, back to autorequires. I'm still not convinced that it's beneficial to not have it in place.

I am unlikely to persuade you if I have not done so already, but here is a summary of the pros and cons as I see them:

Advantages to symlinks autorequiring their targets:

1. In the event that a symlink and its target are both managed as File resources, AND some other resource under management requires the target to exist before it can be applied, AND this other resource declares a relationship on the symlink instead of on its target (possibly via an autorequire), BUT no relationship between link and target is explicitly declared, THEN Puppet will pick up the slack to ensure that the missing requirement does not prevent the catalog from being successfully applied the first time.
2. There is no (2).
   

Disadvantages to symlinks autorequiring their targets:

1. Many unneeded resource relationships are generated.
2. Under some circumstances, Puppet will needlessly create relationship cycles.
3. Although the autorequirement could be overridden, it would be impossible to model the usual true state of affairs, that the relative order of applying link and target does not matter.
   

 
Note there that

• the conditions for the autorequirement even having the possibility of a useful effect are pretty specific; and
  
• even when the conditions are met, it's by no means certain that the catalog fails without the autorequirement; and
  
• if the catalog does fail on account of the link's target not being managed soon enough, then it will be applied successfully the next time (barring other errors); and
  
• any failure arising from a missing target -> link relationship will be easy to characterize and to fix; yet
  
• dependency cycles are notoriously hard to understand and troubleshoot, especially when they involve automatic relationships; and
• (this one's for you, Trevor) to fix a dependency cycle closed via an autorequirement such as we are discussing would require explicitly and artificially declaring the target to depend on the link, a relationship some find counterintuitive.
  

I suppose that I could do some hack-fu like I did with 'group' so that people that want it could patch it into place but that seems a bit unfortunate.

What's so bad about manually declaring a link to depend on its target when that's actually needed?  If the situation in PUP-4036 is representative of such situations, then I don't see why a manifest author should even be taken by surprise by such a need.

 

Are auto* items things that should be allowed to be disabled on a resource-by-resource basis using a Metaparameter? That way you can do the 'usual' thing but, should it cause an issue, just turn it off for that resource and declare things explicitly.

I don't see why it should be inappropriate for a parameter to modulate which autorequirements are in effect.  Alternatively, if you want to cast link validity as an aspect of the File resource state then a new 'ensure' value could be created to model that.  Perhaps something like "link-valid".  When that 'should' value was in effect, the resource could reasonably autorequire its target, and would be expected to fail if the target did not exist when the link was being applied.

 

I'd much rather be able to shim in my own auto* items from the DSL (I mean, it's an Array),

I don't follow you there.  Do you mean you want some kind of global flag to enable the proposed autorequirements being generated?  I don't see how that fits directly into the DSL, but you could address it within your own code by using a wrapper definition around the File type.  Or if you mean on a case-by-case basis then what does "auto" have to do with it?  Just declare the relationship you want.

John

[Trevor Vaughan]

Honestly, it seems like the majority is to not have this, so I'm happy to drop it if that's the consensus. I just keep running into the usual situation where I don't want dangling links.

For the other items:

if the catalog does fail on account of the link's target not being managed soon enough, then it will be applied successfully the next time (barring other errors); and

I agree, and I do understand that 'eventual consistency' is what is advertised. That said, I prefer one run to two as much as possible.
 

What's so bad about manually declaring a link to depend on its target when that's actually needed?  If the situation in PUP-4036 is representative of such situations, then I don't see why a manifest author should even be taken by surprise by such a need.

The main issue here is working around cross-module dependencies. I don't particularly want to create another module/class just for managing a symlink target that might be managed by multiple files. Also, it's just something else that needs to be explicitly declared when it seems to be the usual use case to me.

In other words I think that, in most cases, I don't want dangling symlinks and I do want to make sure that the item that I'm targeting is present on the system already, regardless of its location in the module space.

I don't see why it should be inappropriate for a parameter to modulate which autorequirements are in effect.  Alternatively, if you want to cast link validity as an aspect of the File resource state then a new 'ensure' value could be created to model that.  Perhaps something like "link-valid".  When that 'should' value was in effect, the resource could reasonably autorequire its target, and would be expected to fail if the target did not exist when the link was being applied.

This I like, very much!

I'd be happy with something like 'link-valid' being added to the File resource and autorequirements being spawned from that. I do feel, though, that this would be the generally expected use case. I.e. don't you always expect your links to be valid in general?

So, can I vote for adding 'validate_link => :boolean' as a parameter to File to effect the state above? (Is anyone else happy with this?)

I'd much rather be able to shim in my own auto* items from the DSL (I mean, it's an Array),

I don't follow you there.  Do you mean you want some kind of global flag to enable the proposed autorequirements being generated?  I don't see how that fits directly into the DSL, but you could address it within your own code by using a wrapper definition around the File type.  Or if you mean on a case-by-case basis then what does "auto" have to do with it?  Just declare the relationship you want.

Apologies on this non-sequitur. This is sort of spawning the old 'if defined' argument and that way madness lies, so I'm going to stop this before it starts.

Thanks,

Trevor

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/b26f9b97-c98d-4ed5-b0c7-a09b9e8079fa%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Felix Frank]

On 03/02/2015 10:55 PM, Trevor Vaughan wrote:
> So, can I vote for adding '/validate_link => :boolean/' as a parameter
> to File to effect the state above? (/Is anyone else happy with this?/)

Yes, this does appeal to me. I could even be persuaded that this could
benignly default to true.

[Trevor Vaughan]

Created with links and details as https://tickets.puppetlabs.com/browse/PUP-4071.

Made the :autorequires portion dependent on a risk assessment. The warnings would point out what need to be fixed but may make for a lot of code cruft.

Thanks,

Trevor

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/54F5851B.10804%40alumni.tu-berlin.de.

For more options, visit https://groups.google.com/d/optout.

[John Bollinger]

I prefer doing this with a new ensure value, instead of by adding a parameter that is only relevant to a small subset of File resources.  Nevertheless, I could accept a validate_link parameter, provided that it defaults to false (i.e., the only behavior currently available).


John

[Stefan Schulte]

Hello

On 02.03.2015 22:21, John Bollinger wrote:

Disadvantages to symlinks autorequiring their targets:

1. Many unneeded resource relationships are generated.
2. Under some circumstances, Puppet will needlessly create relationship cycles.
3. Although the autorequirement could be overridden, it would be impossible to model the usual true state of affairs, that the relative order of applying link and target does not matter.
   

maybe I am missing something here but

a) a resource relationship that is autorequired can be overwritten with explicit requires (at least last time I checked). So while dependency cycles can occur, you are likely to resolve them with some explicit requires)

b) a file resource (symlink) already autorequires its target since puppet 2.7.10 (https://projects.puppetlabs.com/issues/5421)

- Stefan

[John Bollinger]

On Tuesday, March 3, 2015 at 1:35:28 PM UTC-6, Stefan Schulte wrote:

Hello

On 02.03.2015 22:21, John Bollinger wrote:

Disadvantages to symlinks autorequiring their targets:

1. Many unneeded resource relationships are generated.
2. Under some circumstances, Puppet will needlessly create relationship cycles.
3. Although the autorequirement could be overridden, it would be impossible to model the usual true state of affairs, that the relative order of applying link and target does not matter.
   

maybe I am missing something here but

a) a resource relationship that is autorequired can be overwritten with explicit requires (at least last time I checked). So while dependency cycles can occur, you are likely to resolve them with some explicit requires)

Known, acknowledged, and covered in the discussion (even in the quoted text).  Yes you can override an autorequirement, but if you ever should need to do so -- indeed, if it is ever valid to do so -- then the autorequirement is in error.  It shouldn't be automatic if there's any reasonable chance that it's wrong or even just unneeded.

 

b) a file resource (symlink) already autorequires its target since puppet 2.7.10 (https://projects.puppetlabs.com/issues/5421)

What a shame.


John

[John Bollinger]

My sincere apologies for my part in what I now recognize as taking this thread off on a tangent.  The lively discussion we had, however, did allow me to frame my general position on autorequirements, which is that they should be implemented only when they are directly indicated by the nature of the resource.  If User resources can be applied without first applying the File resources representing their home directories, then there should be no autorequirement.


John

[Trevor Vaughan]

Indeed, I too apologize for the complete tangent!

And, as would be expected, I'm for the autorequires since it does what I would expect it to do.

Which, again, is counter to what John wants ;-). But, that's my answer to the original question.

Thanks,

Trevor

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/b8d5e560-9357-4d8f-8234-3b593d9be246%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Stefan Schulte]

On 03.03.2015 21:31, John Bollinger wrote:

On Tuesday, March 3, 2015 at 1:35:28 PM UTC-6, Stefan Schulte wrote:

[..]

maybe I am missing something here but

a) a resource relationship that is autorequired can be overwritten with explicit requires (at least last time I checked). So while dependency cycles can occur, you are likely to resolve them with some explicit requires)

Known, acknowledged, and covered in the discussion (even in the quoted text).

I am sorry, I must have missed that.

Yes you can override an autorequirement, but if you ever should need to do so -- indeed, if it is ever valid to do so -- then the autorequirement is in error.  It shouldn't be automatic if there's any reasonable chance that it's wrong or even just unneeded.

 

b) a file resource (symlink) already autorequires its target since puppet 2.7.10 (https://projects.puppetlabs.com/issues/5421)

What a shame.

I am not saying that the current behaviour is correct/better or that your argument is invalid (you have a good point IMHO). I just wanted to point out that it is implemented for quite a while now and personally I am not aware that this caused any problems. I can only guess that most people either expect the current behaviour or they are using explicit requires anyway (which either overwrite the autorequire or making it redundant). But changing the current behaviour *might* break manifests.

- Stefan

[John Bollinger]

On Tuesday, March 3, 2015 at 4:34:43 PM UTC-6, Stefan Schulte wrote:

 

I am not saying that the current behaviour is correct/better or that your argument is invalid (you have a good point IMHO). I just wanted to point out that it is implemented for quite a while now and personally I am not aware that this caused any problems.

Understood.  My rather terse commentary was intended to communicate that although I think that autorequirement is inappropriate, I am not interested in mounting a likely-futile campaign to get it removed again, and I do not intend to engage in an angry diatribe about what a terrible thing it is for Puppet to have such an obvious and horrendous flaw -- and how dare you personally have anything to do with implementing it?  ( :-) )

If it were of surpassing importance to me that all my tools were designed and behaved exactly exactly as I liked, then I would have no choice but to write them myself.  Although I can be impassioned, in the end, I'm a lot more pragmatic than that.

John

[Trevor Vaughan]

If it were of surpassing importance to me that all my tools were designed and behaved exactly exactly as I liked, then I would have no choice but to write them myself.  Although I can be impassioned, in the end, I'm a lot more pragmatic than that.

This should be engraved in stone somewhere.....

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/83c8406c-fd1c-40bc-abb5-2ed0831dc038%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Eric Sorenson]

I haven't followed this discussion super closely, so I can't weigh in on the merits. But I wanted to compliment and thank everyone involved (especially John) for keeping such a temperate and constructive tone throughout. 

--eric0

On Mar 4, 2015, at 1:25 PM, Trevor Vaughan <tvau...@onyxpoint.com> wrote:

If it were of surpassing importance to me that all my tools were designed and behaved exactly exactly as I liked, then I would have no choice but to write them myself.  Although I can be impassioned, in the end, I'm a lot more pragmatic than that.

This should be engraved in stone somewhere.....

Eric Sorenson - eric.s...@puppetlabs.com - freenode #puppet: eric0
puppet platform // coffee // techno // bicycles

[Felix Frank]

Since we're winding down :)

As nobody seems to love generated resources as passionately as I do
(it's OK, we still have each other), I would still ask for a compromise:
Autorequire does make sense, but can we tone it down?

As I understand it, the following resource

user { 'foo': home => '/var/lib/vendor/toolset/vendor-tool' }

will autorequire either
File['/var/lib/vendor/toolset']
File['/var/lib/vendor']
File['/var/lib']
or
File['/var']

which is a bit much for my taste. Autorequiring the immediate parent
only would make more sense to me.

Thanks,
Felix

On 03/03/2015 10:38 PM, Trevor Vaughan wrote:
> Indeed, I too apologize for the complete tangent!
>
> And, as would be expected, I'm for the autorequires since it does what I
> would expect it to do.
>
> Which, again, is counter to what John wants ;-). But, that's my answer
> to the original question.
>
> Thanks,
>
> Trevor
>
> On Tue, Mar 3, 2015 at 3:37 PM, John Bollinger
> <john.bo...@stjude.org <mailto:john.bo...@stjude.org>> wrote:
>
>
>
> On Wednesday, February 25, 2015 at 5:41:19 PM UTC-6, Raphaël Pinson
> wrote:
>
> Hello,
>
>
> As per Kylo's comment in PR for PUP-4036

> <https://github.com/puppetlabs/puppet/pull/3645#issuecomment-76032829>,

> I'd like to discuss the possibility and implications of
> autorequiring parent directories of the home directory for user
> resources.
>
> As stated in the PR, the idea came from stumbling upon a code
> like this one:
>
> file { '/srv/home': ensure => directory }
> file { '/home': ensure => link, target => '/srv/home' } -> User <| |>
>
>
> where it made a lot of sense that all users should just
> autorequire the nearest parent directory to their home directory.
>
> What are your thoughts on this feature?
>
>
>
> My sincere apologies for my part in what I now recognize as taking
> this thread off on a tangent. The lively discussion we had,
> however, did allow me to frame my general position on
> autorequirements, which is that they should be implemented only when
> they are directly indicated by the nature of the resource. If User

> resources /can/ be applied without first applying the File resources

> representing their home directories, then there should be no
> autorequirement.
>
>
> John
>
> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to puppet-dev+...@googlegroups.com

> <mailto:puppet-dev+...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/b8d5e560-9357-4d8f-8234-3b593d9be246%40googlegroups.com

> <https://groups.google.com/d/msgid/puppet-dev/b8d5e560-9357-4d8f-8234-3b593d9be246%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Trevor Vaughan]

Interestingly, I ran into just this issue yesterday.

The scenario was using autofs.

Autofs home directories get installed in /export/home/$USER.

Autofs takes care of $USER.

However, puppet takes care of /export and /home.

So, if all resources are managed by Puppet, then User['foo'] should autorequire at least /export/home which, in turn, will autorequire /export. However, the actual /export/home/$USER directory is completely irrelevant (and should not show up in Puppet anyway).

If, for some reason, /export/home was *not* controlled by Puppet, then I would want User['foo'[ to autorequire /export as well as /export/home.

In this case, I would want the user's target directory +1 to be autorequired and I would like to vote for that.

I couldn't come up with any scenarios that would push me past target +1.

Trevor

To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/54F98667.5040505%40alumni.tu-berlin.de.

For more options, visit https://groups.google.com/d/optout.

[Felix Frank]

On 03/06/2015 12:20 PM, Trevor Vaughan wrote:
>
> If, for some reason, /export/home was *not* controlled by Puppet, then I
> would want User['foo'[ to autorequire /export as well as /export/home.

Hi Trevor,

I see your example, but don't really see the value in requiring /export.

If /export/home appears through a mount, then the user should make the
User require the mount resource explicitly, not its mount point. If
there is no mount resource (autofs), then requiring the mount point adds
comparatively little safety, at the cost of complexity and potential
surprises.

Cheers,
Felix

[Trevor Vaughan]

Oh, no, we would be requiring /export/home, not /export.

user { 'foo':

  home => '/export/home/foo

}

/export/home/foo => Autofs controlled

/export/home => Something Puppet creates

If it doesn't create it, then nothing happens, no added complexity.

I'm not sure what kind of surprise you could have with autorequiring /export/home. I'm also not sure what complexity arises.

file { '/export': ensure => 'directory' }

file { '/export/home': ensure => 'directory' }

user { 'foo': home => '/export/home/foo' } # This probably needs to come after /export/home, otherwise the user will get a nasty surprise when they first login

Sure, I *can* create the user without having the directory in place. But what good does that do anyone?

Trevor

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/54F9A1D6.8060107%40alumni.tu-berlin.de.

For more options, visit https://groups.google.com/d/optout.

[Felix Frank]

On 03/06/2015 02:45 PM, Trevor Vaughan wrote:
> file { '/export': ensure => 'directory' }
> file { '/export/home': ensure => 'directory' }
> user { 'foo': home => '/export/home/foo' } # This probably needs to come
> after /export/home, otherwise the user will get a nasty surprise when
> they first login
>
> Sure, I *can* create the user without having the directory in place. But
> what good does that do anyone?

Ah, a misunderstanding. It had actually not occured to me that users
might manage the $HOME dir as a file resource as well, and that we
should autorequire that. I'm all caught up in autorequiring the parent.

And yes, both these things do make sense. I see no issues with adding
the relationship to either homedir or parent. (It's parent+1 that makes
no sense, but we agree on that as well).

Thanks,
Felix

[Trevor Vaughan]

Sorry for the confusion. That's what I get for typing prior to the morning caffeine.

Trevor

Felix

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/54F9B3CA.7030700%40alumni.tu-berlin.de.

For more options, visit https://groups.google.com/d/optout.

[Erik Dalén]

Won't the $HOME file resource autorequire the user resource already? At least if $HOME is owned by $USER, which it usually is. So then you would get a dependency loop.

[Trevor Vaughan]

That's a really good point and an unfortunate situation, kind of like the group/user dependency chain for removals.

So, there goes that thread :-)

--

You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAAAzDLfcUqwhAAg-k_KF%2BGU%2B1txbSfg6%2Bbgh6Y1OXjojfK5e5w%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.