Fix autorequire case sensitivity #14
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
||
| matching_resource_keys = catalog.resource_keys.collect do |rsrc_type, rsrc_id| | ||
| rsrc_id if (rsrc_type == desired_type) && (rsrc_id =~ /^#{parent_keypath.to_s}$/i) | ||
| end.compact |
There was a problem hiding this comment.
This concerns me as we're scanning all of the resource keys in the catalog for each component in the registry key path. Shouldn't we stop at the first match?
With that said, I think the whole issue could be resolved by simply downcasing the paths at munge time. We already save off the subkey (in its original case) and use that when create/open/destroying keys/values (so it will be case-preserving).
munge do |path|
Puppet::Modules::Registry::RegistryValuePath.new(path).canonical.downcase
end
|
4eff6d8 appears to be working and satisfies the test case. Still need to do a bit more clean up before this is ready to merge though. |
|
@joshcooper OK, all spec tests passing, new specs added, acceptance tests added with pretty good coverage. Ready for review. |
Without this patch the behavior of a registry_value auto requiring
parent registry_key resources does not work when the parent resources do
not share the same letter case as the value.
For example, the value fails to require the key in this scenario:
registry_key { 'HKLM\Software\Vendor\PUPPETLABS':
ensure => present,
}
registry_value { 'HKLM\Software\Vendor\puppetlabs\ValueString':
data => "Hello World!",
}
The root cause of this problem is that Puppet treats all resource
identifier keys as case sensitive and the registry types ascend their
`path` attribute looking up resources using the string provided by the
user in the path parameter.
This patch fixes the problem by aliasing every registry_key and
registry_value resource using the downcase version of the path
attribute. Other resources are expected to look up related resources in
the catalog using the downcase version of the path parameter.
This solves the problem because we now have an internally consistent,
case insensitive identifier.
We preserve case for the user by not munging the case of the path
parameter itself. Instead we simply alias the downcase version in the
catalog.
joshcooper
added a commit
that referenced
this pull request
May 16, 2012
…orequire_case_sensitivity Fix autorequire case sensitivity
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ready for review.
This change set changes the behavior of autorequire in the registry_key and
registry_value types to be case insensitive and preserving. Without these
changes we do not properly autorequire in the following manifest: