Issue #16274 has been updated by Aurélien Degrémont.
Hello We are using a modified version of Puppet static compiler. * We fixed the multiple source issue simply returning the first match (in filebucket) from the list (so like `sourceselect => first`). We do have a big list of sources for each file. * We do not return checksum to be used by filebucket, but keep classic URL which could be used for fileserver. Static compiler is used to only keep the first source available on fileserver. Doing so, we avoid a lot (tons!) of requests from clients to look for invalid source files. We are really pleased to use the fileserver here, which is more flexible than a remote filebucket and more secure. So if you are concern about what client should see and what they should not (which sounds what Daniel said), please do not "*turn off fileserving entirely*" By the way, static compiler is really a good target for performance issue for us! We love it and would be very pleased to have it ready, supporting multiple sources and fileserver in mainstream! :) ---------------------------------------- Bug #16274: static compiler doesn't work when a file resource has more than one source URL https://projects.puppetlabs.com/issues/16274#change-70854 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.
