Feature #2611
resource attribute access
| Status: | Accepted | Start date: | 09/08/2009 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% | |
| Category: | language | |||
| Target version: | 3.x | |||
| Affected Puppet version: | 0.24.8 | Branch: | ||
| Keywords: | resource attribute access | |||
Description
Based on a post to the development mailing list, it may be useful to add attribute access to the language.
Use case scenario: – a resource has a certain attribute – the attribute needs to be accessed from else where (e.g. another resource, template etc.)
Sample code:
$cacert_path = Base::X509::Cert["cacert"].path
Where the Base::X509::Cert resource is a custom define instantiated e.g. as:
base::x509::cert { "cacert":
path => "/etc/ssl/$name",
source => "puppet:///profiles/cacert.pem",
}
History
#1
Updated by Luke Kanies almost 4 years ago
- Category set to language
- Status changed from Unreviewed to Accepted
- Priority changed from High to Normal
- 3 changed from Easy to Medium
“Relatively easy”, not “easy”. :) I usually reserve the ‘easy’ tickets for people who can kind of walk in off the street and figure it out, which doesn’t usually qualify for language extensions.
#2
Updated by Markus Roberts almost 4 years ago
Should the target be 0.26 (as it’s a feature, not a bug)?
#3
Updated by Jan Capek almost 3 years ago
- Target version set to 2.6.0
Would this feature be acceptable for 0.26?
#4
Updated by James Turnbull almost 3 years ago
- Target version changed from 2.6.0 to 2.7.x
At this stage it’s not going to make it into 2.6.
#5
Updated by Nigel Kersten about 2 years ago
- Target version changed from 2.7.x to 3.x
#6
Updated by Henrik Lindberg 8 months ago
Since there is no “.” operator at present, it would be far easier to implement using operator ‘[]’ – probably “just” and evaluation issue, and not a language change. the example could then be written:
$cacert_path = Base::X509::Cert['cacert']['path']
#7
Updated by Nick Lewis 8 months ago
It does require a language change either way, I think, because the example you give won’t compile at all today.
And I’d completely forgotten, but I have a prototype branch that implements this using . for access:
https://github.com/nicklewis/puppet/tree/resource-attribute-access
#8
Updated by Maru Newby 6 days ago
I’ve been looking at creating OpenStack resources (users, images, etc) via a Puppet provider, and the capability to access resource attributes would be very useful.
While it is possible to identify OpenStack resources by name, the name is not necessarily unique. Each resource has a uuid, though, typically assigned on creation. Not being able to access this uuid via a resource type means that a Puppet provider for a single OpenStack resource type has no definitive way of ensuring a given resource is associated with a target resource that has not yet been created. The only way to ensure correct association would be creating all resources that need to be associated at the same time in the provider code, which wouldn’t make for very modular or maintainable code.