Bug #2020
Realizing a resource should create a dependency on that resource
| Status: | Accepted | Start date: | 02/23/2009 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | language | |||
| Target version: | 3.X | |||
| Affected Puppet version: | 0.25.4 | Branch: | ||
| Keywords: | ||||
| Votes: | 1 |
Description
puppet 0.24.6
Typically I have modules laid out like this:
apache::install, apache::config, apache::service
inside apache::config resources will require Class[“apache::install”] making sure all the installation tasks gets done first.
Using simple package{..} resources in the apache::install class all works as you’d hope, but on moving to virtual packages I am seeing configuration files get created before the packages gets installed, below simple manifest demonstrates the problem:
class virt {
@file{"/tmp/file1":
content => "file 1\n"
}
@file{"/tmp/file2":
require => File["/tmp/file1"],
content => "file 2\n"
}
}
class prereq {
realize(File["/tmp/file1"])
realize(File["/tmp/file2"])
}
include virt
include prereq
file{"/tmp/file3":
content => "file 3\n",
require => Class["prereq"]
}
When I run this I’d expect all the resources in Class[“prereq”] to be realized, files created etc, before /tmp/file3, on running it though I get:
notice: //File[/tmp/file3]/content: created file with contents {md5}9c38e8324dbf031557c89d53a39f0b26
notice: //virt/File[/tmp/file1]/content: created file with contents {md5}e243bb39c844b3543a7726576c869caf
notice: //virt/File[/tmp/file2]/content: created file with contents {md5}4349cfeff8e2eb74dffc369bb5fd084e
Related issues
History
Updated by James Turnbull about 3 years ago
- Category set to transactions
- Status changed from Unreviewed to Accepted
- Assignee set to Luke Kanies
Luke?
Updated by Luke Kanies about 3 years ago
- Category changed from transactions to language
- Assignee changed from Luke Kanies to Puppet Community
I see what’s happening here. You’re expecting that ‘realize’ creates a relationship between the realized resource and the realizing class.
I’d say that this is expected behaviour at this point, but I can see how you’d want these relationships to be created.
Is it reasonable to have ‘realize’ also create a dependency on that resource?
Updated by R.I. Pienaar about 3 years ago
Luke, I’ve sent mail to the list as requested (via IRC) and no1 seemed to care either way, so perhaps you should just do what you think is best ? :P
Updated by Luke Kanies about 3 years ago
- Subject changed from Virtual resources and classes not respecting requires to Realizing a resource should create a dependency on that resource
Okay. Fixing the description to be more appropriate.
Updated by James Turnbull almost 3 years ago
- Assignee deleted (
Puppet Community)
Updated by R.I. Pienaar over 2 years ago
Is there any chance at all we can get this change into the next release? It’s community owned, not sure if there’s any hope.
Last ditch effort before backing out my virtual packages and moving back to standard resources :(
Updated by James Turnbull over 2 years ago
- Target version set to 2.6.0
- Affected Puppet version changed from 0.24.6 to 0.25.1
Updated by James Turnbull over 2 years ago
- Target version changed from 2.6.0 to 2.7.x
Updated by Tim Stoop about 2 years ago
- Affected Puppet version changed from 0.25.1 to 0.25.4
Not too bothered by this, since subsequent runs will fix it eventually. But it makes it fairly impossible to setup a machine from scratch in one puppet run, which bothers me from an aesthetic point of view. Voting for it, though.
Updated by Nigel Kersten over 1 year ago
Not too bothered by this, since subsequent runs will fix it eventually
No, this is bad. It’s totally counter-intuitive, and if you’re needing to do multiple runs to achieve something, either your config or Puppet is broken imho.
Is there a corresponding issue with implicit tags as well? I’ll try to do a test there.
Updated by Nigel Kersten about 1 year ago
- Target version changed from 2.7.x to 3.X
Updated by Mikael Fridh 5 months ago
ouch, I think i got bit by this today.
True, it will get fixed on subsequent runs but in my case, packages are installed before certain virtual users are realized before the package installation, thus users are created with wrong UIDs etc, causing blocking UIDs one some runs, and of course, subsequently I’m left with permissions problems (albeit small).
I’ve tried to change my dependencies from require => Class[“user::account”] to require => User[“username”] instead for now but I’d prefer the real fix. Thanks for looking into it.