Jira (PUP-10665) Add weak dependencies to puppet resources

Issue Type:	New Feature
Assignee:	Unassigned
Components:	Language
Created:	2020/09/12 5:22 PM
Priority:	Normal
Reporter:	Trevor Vaughan

After a long discussion in Slack, I was asked to create a ticket around adding 'weak dependencies' to puppet resources.

Weak dependencies work like the wants keyword in systemd in that resources will be ordered after other resources that they want but failures in earlier resources will not cause cascading errors into resources that want them.

This would be useful in cases like the yumrepo resource which may cascade down to packages that do not actually reside in that repository.

Per the Slack discussion, it looks like implementing this in the compiler is going to be the best case for backwards compatibility and could constitute a non-breaking feature enhancement.

This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)

Trevor Vaughan (Jira)

unread,

Sep 14, 2020, 8:10:04 AM9/14/20

to puppe...@googlegroups.com

Trevor Vaughan updated an issue

Puppet /

Change By:	Trevor Vaughan

After [a long discussion in Slack|https://puppetcommunity.slack.com/archives/C0W1X7ZAL/p1599682853112600], I was asked to create a ticket around adding 'weak dependencies' to puppet resources.

Weak dependencies work like the {{wants}} keyword in {{systemd}} in that resources will be ordered after other resources that they {{want}} but failures in earlier resources will not cause cascading errors into resources that {{want}} them.

This would be useful in cases like the {{yumrepo}} resource which may cascade down to packages that do not actually reside in that repository.

Per the Slack discussion, it looks like implementing this in the compiler is going to be the best case for backwards compatibility and could constitute a non-breaking feature enhancement.

An example of what this might look like is:

{code}
file { '/tmp/foo':
  owner => 'root',
  mode => '0640',
  requires => [ File['/tmp'], Exec['foo'] ]
  wants => [ File['/etc/bar'], Exec['baz'] ]
}
{code}

In this case, {{requires}} would work as usual and {{wants}} would use the resource if present, ignore it if not, and not cascade resource failures.

If something exists in both {{requires}} and {{wants}} then the stronger dependency ({{requires}}) should win.

Henrik Lindberg (Jira)

unread,

Sep 14, 2020, 10:38:03 AM9/14/20

to puppe...@googlegroups.com

Henrik Lindberg commented on

Is the case "resource must be there, but don't propagate errors" valid? Seems like optionally_requires and do_not_propagate are separate things.
Maybe these concepts are:

optionally_before, optionaly_after (since optionally_require is a bit of an oxymoron) - this is a soft dependency, no error if missing
isolated_before, isolated_after - this does not propagate errors (isolated == isolated from errors) and implies optionality unless resource is also listed as required.

Just a thought.

Trevor Vaughan (Jira)

unread,

Sep 15, 2020, 8:13:04 AM9/15/20

to puppe...@googlegroups.com

Trevor Vaughan commented on

I like the idea above from Henrik Lindberg. It is true that optionally_requires is not the same as isolated_before. (I warned people that I was bad at naming things).

Technically, optionally_before is what I expected the regular before to be when I started using the language but I think that ship has sailed.

Even though it's a bit more wordy, I think that this is probably better than my original idea.

The optionally_ stuff is actually easy to implement because it's identical to the auto (autorequires, etc...) portions of custom types that already exist.

I think may be borrowing from systemd and using wants and wanted_by would be a bit easier to wrap our heads around than the isolated_* naming scheme.

I'll update the description with these ideas.

Trevor Vaughan (Jira)

unread,

Sep 15, 2020, 8:18:03 AM9/15/20

to puppe...@googlegroups.com

Trevor Vaughan updated an issue

Puppet /

Change By:	Trevor Vaughan

After [a long discussion in Slack|https://puppetcommunity.slack.com/archives/C0W1X7ZAL/p1599682853112600], I was asked to create a ticket around adding 'weak dependencies' to puppet resources.

Weak dependencies work like the {{wants}} keyword in {{systemd}} in that resources will be ordered after other resources that they {{want}} but failures in earlier resources will not cause cascading errors into resources that {{want}} them.

This would be useful in cases like the {{yumrepo}} resource which may cascade down to packages that do not actually reside in that repository.

Per the Slack discussion, it looks like implementing this in the compiler is going to be the best case for backwards compatibility and could constitute a non-breaking feature enhancement.

An example of what this might look like is: (updated from comments below)

{code}
exec { 'ping host':
command => 'ping 1.2.3.4'
}

exec { 'ping other host':
command => 'ping 2.3.4.5'
}

file { '/tmp/foo':
owner => 'root',
mode => '0640',

  requires => [ File['/tmp'], Exec[' foo ping host '] ] ,
  wants   # Add these items to the autorequires list
  optionally_requires => [ File['/ etc dev / bar shm '] ] ,
  # Do not fail if these resources fail
  wants => [ Exec[' baz ping other host '] ]
}
{code}

The pairings would be:

* {{optionally_requires}} => {{optionally_notifies}}
* {{wants}} => {{wanted_by}}

Potential symbols:

* {{optionally_requires}} => {{*>}}
** Denotes the 'match anything' regex marker
* {{wants}} => {{+>}}
** Denotes a broken line == broken dependency

In this case, {{requires}} would work as usual and {{wants}} would use the resource if present, ignore it if not, and not cascade resource failures.

If something exists in both {{requires}} and {{wants}} then the stronger dependency ({{requires}}) should win.

Trevor Vaughan (Jira)

unread,

Sep 15, 2020, 11:39:04 AM9/15/20

to puppe...@googlegroups.com

Trevor Vaughan updated an issue

Puppet /

Change By:	Trevor Vaughan

After [a long discussion in Slack|https://puppetcommunity.slack.com/archives/C0W1X7ZAL/p1599682853112600], I was asked to create a ticket around adding 'weak dependencies' to puppet resources.

Weak dependencies work like the {{wants}} keyword in {{systemd}} in that resources will be ordered after other resources that they {{want}} but failures in earlier resources will not cause cascading errors into resources that {{want}} them.

This would be useful in cases like the {{yumrepo}} resource which may cascade down to packages that do not actually reside in that repository.

Per the Slack discussion, it looks like implementing this in the compiler is going to be the best case for backwards compatibility and could constitute a non-breaking feature enhancement.

An example of what this might look like is: (updated from comments below)

{code}

exec { 'ping host':
  command => 'ping 1.2.3.4'
}

exec { 'ping other host':
  command => 'ping 2.3.4.5'
}

file { '/tmp/foo':
  owner => 'root',
  mode => '0640',

requires => [ File['/tmp'], Exec['ping host'] ],

# Add these items to the autorequires list

optionally_requires optional_requires => [File['/dev/shm']],

# Do not fail if these resources fail

wants => [ Exec['ping other host'] ]
}
{code}

The pairings would be:

* {{ optionally_requires optional_requires }} => {{ optionally_notifies optional_notifies }}
* {{wants}} => {{wanted_by}}

Potential symbols (Stretch Goal) :

* {{ optionally_requires optional_requires }} => {{*>}}

** Denotes the 'match anything' regex marker
* {{wants}} => {{+>}}
** Denotes a broken line == broken dependency
In this case, {{requires}} would work as usual and {{wants}} would use the resource if present, ignore it if not, and not cascade resource failures.

If something exists in both {{requires}} and {{wants}} then the stronger dependency ({{requires}}) should win.

Trevor Vaughan (Jira)

unread,

Sep 15, 2020, 11:40:04 AM9/15/20

to puppe...@googlegroups.com

Trevor Vaughan commented on

Changed optionally to optional because it's easier to type

Reid Vandewiele (Jira)

unread,

Sep 23, 2021, 4:52:02 PM9/23/21

to puppe...@googlegroups.com

Reid Vandewiele commented on

Language check: to match existing grammar (require, subscribe, before, notify), the suggested weak dependency keywords should be singular, not plural. That is,

optional_require
optional_notify
want
wanted_by

This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97)

Reid Vandewiele (Jira)

unread,

Sep 24, 2021, 5:24:02 PM9/24/21

to puppe...@googlegroups.com

Reid Vandewiele commented on

It's really too bad we can't use before and after for weak ordering. isolated_* isn't exactly intuitive. Maybe instead we could for those ones do

order_before
order_after

It's true we can never remove the original before, but it might be a good idea to introduce a new alias for that functionality which we can recommend new code use instead. We have require, which is good; we could pair require with the new before alias:

required_by