Issue #16274 has been updated by Jeff McCune.
# Community update In an effort to clearly communicate our intentions regarding this bug, here's what we're going to do: In the 3.x series, we'll be addressing "themes" for each of the feature releases. We're almost 100% certain that 3.1 will have the theme of "clean up the settings subsystem," but we aren't yet sure what that will exactly entail. I am confident, however, that this particular bug will not be included in the 3.0.x or 3.1.x feature releases. Regarding the existing pull request, I'm going to close it but reference it here: <https://github.com/puppetlabs/puppet/pull/962>. Closing the pull request does not mean we will not fix this bug, just that the code is insufficient to fix the core design problems with the static compiler. ---------------------------------------- Bug #16274: static compiler doesn't work when a file resource has more than one source URL https://projects.puppetlabs.com/issues/16274#change-72096 Author: Daniel Pittman Status: Accepted Priority: Normal Assignee: Category: compiler Target version: 3.x Affected Puppet version: 2.6.0 Keywords: Branch: The static compiler ignores - and, so, uses non-static sourcing for - file resources with more than one source: file { "/tmp/example.txt": source => ["puppet:///foo", "puppet:///bar"] } It isn't clear to me what the most correct behaviour is: Should we replace *all* those URL references with content references? Works fine for both `sourceselect => all` and `sourceselect => first`, but may result in putting more data in the bucket than is required. Also, makes it more likely that a future change that did more to sync bucket content to agents might reveal *more* than should be shown to the machine. (eg: if we treat everything we make static as "target node can access this" we reveal both foo and bar, even if only foo should be available.) Should we try and emulate the file type behaviour? That works, I guess, but it leads to the odd situation where the static compiler and the file type have to agree on their behaviour - otherwise we end of diverging between the two. Which isn't awesome. It does mean that we do a static, compilation time evaluation of the decision point in the resource, though, which seems like a win. Do we try and defer this until we only have the static compiler (or do it preemptively), and allow types to add behaviour that supports this? (eg: the file type has the "can make myself static" feature, and takes ownership of doing all this work.) That has the advantage that any type can be able to be made static, not just file. It has the drawback that it makes more more complexity in the type being able to massage itself. Do we simply force the file type to handle this internally, without cooperation from the compiler? There is no technical reason that can't happen, but it means that any other type that wants to be static has to do the same thing. My personal feeling is that we make the type responsible for "becoming static", and adapt the static compiler to respect that. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
