Subscribe to packages in puppet
up vote
1
down vote
favorite
Consider I have a profile that installs a package. After installation, it runs some exec
commands. But these commands need to run only once when the package is first installed.
package { 'package1':
ensure => 'present'
}
exec { 'signal_package_conf':
command => 'systemctl restart package.service',
path => '/sbin:/bin:/usr/sbin:/usr/bin',
refreshonly => true,
subscribe => Package['package1'],
}
But suppose this particular package gets installed as a dependency for another package in another profile.
When puppet comes to the package1
resource, it will find that the package is already installed and will not install it again. Since puppet would not know of this implicit package dependency, will the subscription to the package still work and execute the command in the exec
resource?
dependencies puppet subscribe
add a comment |
up vote
1
down vote
favorite
Consider I have a profile that installs a package. After installation, it runs some exec
commands. But these commands need to run only once when the package is first installed.
package { 'package1':
ensure => 'present'
}
exec { 'signal_package_conf':
command => 'systemctl restart package.service',
path => '/sbin:/bin:/usr/sbin:/usr/bin',
refreshonly => true,
subscribe => Package['package1'],
}
But suppose this particular package gets installed as a dependency for another package in another profile.
When puppet comes to the package1
resource, it will find that the package is already installed and will not install it again. Since puppet would not know of this implicit package dependency, will the subscription to the package still work and execute the command in the exec
resource?
dependencies puppet subscribe
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
Consider I have a profile that installs a package. After installation, it runs some exec
commands. But these commands need to run only once when the package is first installed.
package { 'package1':
ensure => 'present'
}
exec { 'signal_package_conf':
command => 'systemctl restart package.service',
path => '/sbin:/bin:/usr/sbin:/usr/bin',
refreshonly => true,
subscribe => Package['package1'],
}
But suppose this particular package gets installed as a dependency for another package in another profile.
When puppet comes to the package1
resource, it will find that the package is already installed and will not install it again. Since puppet would not know of this implicit package dependency, will the subscription to the package still work and execute the command in the exec
resource?
dependencies puppet subscribe
Consider I have a profile that installs a package. After installation, it runs some exec
commands. But these commands need to run only once when the package is first installed.
package { 'package1':
ensure => 'present'
}
exec { 'signal_package_conf':
command => 'systemctl restart package.service',
path => '/sbin:/bin:/usr/sbin:/usr/bin',
refreshonly => true,
subscribe => Package['package1'],
}
But suppose this particular package gets installed as a dependency for another package in another profile.
When puppet comes to the package1
resource, it will find that the package is already installed and will not install it again. Since puppet would not know of this implicit package dependency, will the subscription to the package still work and execute the command in the exec
resource?
dependencies puppet subscribe
dependencies puppet subscribe
asked Nov 14 at 7:33
leoOrion
353418
353418
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
This answer is in two parts, to address two possible interpretations of your query about refresh relationships in general.
Refresh events and ordering from other classes
Let me try to rewrite what I understand your question to be in more general terms. You are asking:
Question
Suppose that Exec resource Y subscribes with refreshonly => true
to a resource X in class A. Then suppose that resource Z requires the same resource X in class B.
In other words, imagine this code:
class b () {
notify { 'Z':
require => Notify['X'],
}
}
class a () {
notify { 'X': }
exec { 'Y':
command => '/bin/echo Y',
refreshonly => true,
subscribe => Notify['X'],
}
}
include a
include b
Is it possible for the final ordering to be X, Z, Y, and if so, will the refresh event definitely reach Exec resource Y, considering that X and Y could be separated by Z in time?
Answer
Yes, and yes. Recall that Puppet builds a directed acyclic graph, and it computes the final ordering from traversing that graph. This code leads to two possible orderings in time, X, Y, Z and X, Z, Y (try it a few times using puppet apply /tmp/code.pp --ordering=random
).
But that's ok, because Puppet also tracks a queue of resources that have received a refresh event.
What if package A is installed as a dependency of package B by the package manager outside of Puppet
It's also possible that you are asking about RPM or other package-manager-level dependencies that exist outside of Puppet. If so, naturally, Puppet can't know about these.
If so, yes, the refresh event would not be sent if the package manager (or anything else outside of Puppet) satisfied the subscription.
I saw that option, but if I setreinstall_on_refresh
to true, wont it also re-install every time puppet runs?
– leoOrion
Nov 14 at 11:43
As I mentioned, only if reinstallable is also implemented, and at this time, it's only implemented forprovider => portage
. If you're on Gentoo, perhaps that's a real issue?
– Alex Harvey
Nov 14 at 11:44
In your example, classesa
andb
will be managed by puppet. What I meant was when I dopackage { 'package1': ensure => present }
in another profile that installs as a dependencypackage2
(this is done usingyum
in my case and installation ofpackage2
is not known to puppet). Now if I have anexec
that subscribes topackage2
will it still run?
– leoOrion
Nov 14 at 11:49
Yes, see the third part.
– Alex Harvey
Nov 14 at 11:49
2
re: the first point: I do not believe the asker is attempting to refresh apackage
resource, and I do not see an edit history in the question to indicate that. Another super minor point is that you can also enablerefreshable
with a method in the type that invokes something specific in the provider.
– Matt Schuchard
Nov 14 at 13:25
|
show 5 more comments
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
This answer is in two parts, to address two possible interpretations of your query about refresh relationships in general.
Refresh events and ordering from other classes
Let me try to rewrite what I understand your question to be in more general terms. You are asking:
Question
Suppose that Exec resource Y subscribes with refreshonly => true
to a resource X in class A. Then suppose that resource Z requires the same resource X in class B.
In other words, imagine this code:
class b () {
notify { 'Z':
require => Notify['X'],
}
}
class a () {
notify { 'X': }
exec { 'Y':
command => '/bin/echo Y',
refreshonly => true,
subscribe => Notify['X'],
}
}
include a
include b
Is it possible for the final ordering to be X, Z, Y, and if so, will the refresh event definitely reach Exec resource Y, considering that X and Y could be separated by Z in time?
Answer
Yes, and yes. Recall that Puppet builds a directed acyclic graph, and it computes the final ordering from traversing that graph. This code leads to two possible orderings in time, X, Y, Z and X, Z, Y (try it a few times using puppet apply /tmp/code.pp --ordering=random
).
But that's ok, because Puppet also tracks a queue of resources that have received a refresh event.
What if package A is installed as a dependency of package B by the package manager outside of Puppet
It's also possible that you are asking about RPM or other package-manager-level dependencies that exist outside of Puppet. If so, naturally, Puppet can't know about these.
If so, yes, the refresh event would not be sent if the package manager (or anything else outside of Puppet) satisfied the subscription.
I saw that option, but if I setreinstall_on_refresh
to true, wont it also re-install every time puppet runs?
– leoOrion
Nov 14 at 11:43
As I mentioned, only if reinstallable is also implemented, and at this time, it's only implemented forprovider => portage
. If you're on Gentoo, perhaps that's a real issue?
– Alex Harvey
Nov 14 at 11:44
In your example, classesa
andb
will be managed by puppet. What I meant was when I dopackage { 'package1': ensure => present }
in another profile that installs as a dependencypackage2
(this is done usingyum
in my case and installation ofpackage2
is not known to puppet). Now if I have anexec
that subscribes topackage2
will it still run?
– leoOrion
Nov 14 at 11:49
Yes, see the third part.
– Alex Harvey
Nov 14 at 11:49
2
re: the first point: I do not believe the asker is attempting to refresh apackage
resource, and I do not see an edit history in the question to indicate that. Another super minor point is that you can also enablerefreshable
with a method in the type that invokes something specific in the provider.
– Matt Schuchard
Nov 14 at 13:25
|
show 5 more comments
up vote
2
down vote
accepted
This answer is in two parts, to address two possible interpretations of your query about refresh relationships in general.
Refresh events and ordering from other classes
Let me try to rewrite what I understand your question to be in more general terms. You are asking:
Question
Suppose that Exec resource Y subscribes with refreshonly => true
to a resource X in class A. Then suppose that resource Z requires the same resource X in class B.
In other words, imagine this code:
class b () {
notify { 'Z':
require => Notify['X'],
}
}
class a () {
notify { 'X': }
exec { 'Y':
command => '/bin/echo Y',
refreshonly => true,
subscribe => Notify['X'],
}
}
include a
include b
Is it possible for the final ordering to be X, Z, Y, and if so, will the refresh event definitely reach Exec resource Y, considering that X and Y could be separated by Z in time?
Answer
Yes, and yes. Recall that Puppet builds a directed acyclic graph, and it computes the final ordering from traversing that graph. This code leads to two possible orderings in time, X, Y, Z and X, Z, Y (try it a few times using puppet apply /tmp/code.pp --ordering=random
).
But that's ok, because Puppet also tracks a queue of resources that have received a refresh event.
What if package A is installed as a dependency of package B by the package manager outside of Puppet
It's also possible that you are asking about RPM or other package-manager-level dependencies that exist outside of Puppet. If so, naturally, Puppet can't know about these.
If so, yes, the refresh event would not be sent if the package manager (or anything else outside of Puppet) satisfied the subscription.
I saw that option, but if I setreinstall_on_refresh
to true, wont it also re-install every time puppet runs?
– leoOrion
Nov 14 at 11:43
As I mentioned, only if reinstallable is also implemented, and at this time, it's only implemented forprovider => portage
. If you're on Gentoo, perhaps that's a real issue?
– Alex Harvey
Nov 14 at 11:44
In your example, classesa
andb
will be managed by puppet. What I meant was when I dopackage { 'package1': ensure => present }
in another profile that installs as a dependencypackage2
(this is done usingyum
in my case and installation ofpackage2
is not known to puppet). Now if I have anexec
that subscribes topackage2
will it still run?
– leoOrion
Nov 14 at 11:49
Yes, see the third part.
– Alex Harvey
Nov 14 at 11:49
2
re: the first point: I do not believe the asker is attempting to refresh apackage
resource, and I do not see an edit history in the question to indicate that. Another super minor point is that you can also enablerefreshable
with a method in the type that invokes something specific in the provider.
– Matt Schuchard
Nov 14 at 13:25
|
show 5 more comments
up vote
2
down vote
accepted
up vote
2
down vote
accepted
This answer is in two parts, to address two possible interpretations of your query about refresh relationships in general.
Refresh events and ordering from other classes
Let me try to rewrite what I understand your question to be in more general terms. You are asking:
Question
Suppose that Exec resource Y subscribes with refreshonly => true
to a resource X in class A. Then suppose that resource Z requires the same resource X in class B.
In other words, imagine this code:
class b () {
notify { 'Z':
require => Notify['X'],
}
}
class a () {
notify { 'X': }
exec { 'Y':
command => '/bin/echo Y',
refreshonly => true,
subscribe => Notify['X'],
}
}
include a
include b
Is it possible for the final ordering to be X, Z, Y, and if so, will the refresh event definitely reach Exec resource Y, considering that X and Y could be separated by Z in time?
Answer
Yes, and yes. Recall that Puppet builds a directed acyclic graph, and it computes the final ordering from traversing that graph. This code leads to two possible orderings in time, X, Y, Z and X, Z, Y (try it a few times using puppet apply /tmp/code.pp --ordering=random
).
But that's ok, because Puppet also tracks a queue of resources that have received a refresh event.
What if package A is installed as a dependency of package B by the package manager outside of Puppet
It's also possible that you are asking about RPM or other package-manager-level dependencies that exist outside of Puppet. If so, naturally, Puppet can't know about these.
If so, yes, the refresh event would not be sent if the package manager (or anything else outside of Puppet) satisfied the subscription.
This answer is in two parts, to address two possible interpretations of your query about refresh relationships in general.
Refresh events and ordering from other classes
Let me try to rewrite what I understand your question to be in more general terms. You are asking:
Question
Suppose that Exec resource Y subscribes with refreshonly => true
to a resource X in class A. Then suppose that resource Z requires the same resource X in class B.
In other words, imagine this code:
class b () {
notify { 'Z':
require => Notify['X'],
}
}
class a () {
notify { 'X': }
exec { 'Y':
command => '/bin/echo Y',
refreshonly => true,
subscribe => Notify['X'],
}
}
include a
include b
Is it possible for the final ordering to be X, Z, Y, and if so, will the refresh event definitely reach Exec resource Y, considering that X and Y could be separated by Z in time?
Answer
Yes, and yes. Recall that Puppet builds a directed acyclic graph, and it computes the final ordering from traversing that graph. This code leads to two possible orderings in time, X, Y, Z and X, Z, Y (try it a few times using puppet apply /tmp/code.pp --ordering=random
).
But that's ok, because Puppet also tracks a queue of resources that have received a refresh event.
What if package A is installed as a dependency of package B by the package manager outside of Puppet
It's also possible that you are asking about RPM or other package-manager-level dependencies that exist outside of Puppet. If so, naturally, Puppet can't know about these.
If so, yes, the refresh event would not be sent if the package manager (or anything else outside of Puppet) satisfied the subscription.
edited Nov 15 at 8:07
answered Nov 14 at 9:24
Alex Harvey
3,6251823
3,6251823
I saw that option, but if I setreinstall_on_refresh
to true, wont it also re-install every time puppet runs?
– leoOrion
Nov 14 at 11:43
As I mentioned, only if reinstallable is also implemented, and at this time, it's only implemented forprovider => portage
. If you're on Gentoo, perhaps that's a real issue?
– Alex Harvey
Nov 14 at 11:44
In your example, classesa
andb
will be managed by puppet. What I meant was when I dopackage { 'package1': ensure => present }
in another profile that installs as a dependencypackage2
(this is done usingyum
in my case and installation ofpackage2
is not known to puppet). Now if I have anexec
that subscribes topackage2
will it still run?
– leoOrion
Nov 14 at 11:49
Yes, see the third part.
– Alex Harvey
Nov 14 at 11:49
2
re: the first point: I do not believe the asker is attempting to refresh apackage
resource, and I do not see an edit history in the question to indicate that. Another super minor point is that you can also enablerefreshable
with a method in the type that invokes something specific in the provider.
– Matt Schuchard
Nov 14 at 13:25
|
show 5 more comments
I saw that option, but if I setreinstall_on_refresh
to true, wont it also re-install every time puppet runs?
– leoOrion
Nov 14 at 11:43
As I mentioned, only if reinstallable is also implemented, and at this time, it's only implemented forprovider => portage
. If you're on Gentoo, perhaps that's a real issue?
– Alex Harvey
Nov 14 at 11:44
In your example, classesa
andb
will be managed by puppet. What I meant was when I dopackage { 'package1': ensure => present }
in another profile that installs as a dependencypackage2
(this is done usingyum
in my case and installation ofpackage2
is not known to puppet). Now if I have anexec
that subscribes topackage2
will it still run?
– leoOrion
Nov 14 at 11:49
Yes, see the third part.
– Alex Harvey
Nov 14 at 11:49
2
re: the first point: I do not believe the asker is attempting to refresh apackage
resource, and I do not see an edit history in the question to indicate that. Another super minor point is that you can also enablerefreshable
with a method in the type that invokes something specific in the provider.
– Matt Schuchard
Nov 14 at 13:25
I saw that option, but if I set
reinstall_on_refresh
to true, wont it also re-install every time puppet runs?– leoOrion
Nov 14 at 11:43
I saw that option, but if I set
reinstall_on_refresh
to true, wont it also re-install every time puppet runs?– leoOrion
Nov 14 at 11:43
As I mentioned, only if reinstallable is also implemented, and at this time, it's only implemented for
provider => portage
. If you're on Gentoo, perhaps that's a real issue?– Alex Harvey
Nov 14 at 11:44
As I mentioned, only if reinstallable is also implemented, and at this time, it's only implemented for
provider => portage
. If you're on Gentoo, perhaps that's a real issue?– Alex Harvey
Nov 14 at 11:44
In your example, classes
a
and b
will be managed by puppet. What I meant was when I do package { 'package1': ensure => present }
in another profile that installs as a dependency package2
(this is done using yum
in my case and installation of package2
is not known to puppet). Now if I have an exec
that subscribes to package2
will it still run?– leoOrion
Nov 14 at 11:49
In your example, classes
a
and b
will be managed by puppet. What I meant was when I do package { 'package1': ensure => present }
in another profile that installs as a dependency package2
(this is done using yum
in my case and installation of package2
is not known to puppet). Now if I have an exec
that subscribes to package2
will it still run?– leoOrion
Nov 14 at 11:49
Yes, see the third part.
– Alex Harvey
Nov 14 at 11:49
Yes, see the third part.
– Alex Harvey
Nov 14 at 11:49
2
2
re: the first point: I do not believe the asker is attempting to refresh a
package
resource, and I do not see an edit history in the question to indicate that. Another super minor point is that you can also enable refreshable
with a method in the type that invokes something specific in the provider.– Matt Schuchard
Nov 14 at 13:25
re: the first point: I do not believe the asker is attempting to refresh a
package
resource, and I do not see an edit history in the question to indicate that. Another super minor point is that you can also enable refreshable
with a method in the type that invokes something specific in the provider.– Matt Schuchard
Nov 14 at 13:25
|
show 5 more comments
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53295115%2fsubscribe-to-packages-in-puppet%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown