Jira (PUP-8549) Reduce regular expression garbage in puppet
Title: Message Title Justin Stoller commented on PUP-8549 Re: Reduce regular _expression_ garbage in puppet It was also interesting to see that the only encodings were of ASCII and UTF8 when running the benchmarks, even after setting the default external encoding to Latin-1. I don't know whether that's because the modules/manifests are explicitly UTF8 and/or the parser converts them to either UTF8 or ASCII, or something else? I also don't know if facts can be non-UTF8. It might be that server side inputs will only ever be UTF8 or ASCII, but that command line parameters like the resource application test discussed above might be non-UTF8. If that were the case we could coerce the regex to UTF8 only when running in master mode, though that feels wrong... (if it were the case that command line processing was the only place that non-UTF8 compatible encodings could creep into the system then having command parsing force them to be UTF8 seems like a better solution). Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8549) Reduce regular expression garbage in puppet
Title: Message Title Justin Stoller commented on PUP-8549 Re: Reduce regular _expression_ garbage in puppet Without my patch, running the full catalog benchmark I see tagging.rb allocating 2.67Mb in 38,348 objects which makes it the 9th memory intensive file ran. There are 37.262 Mb in 738,582 Strings allocated in general. With my patch in the full catalog benchmark there are 3Mb of memory in 46,553 objects being allocated in tagging.rb (381Kb in 8,205 objects more than without my patch). 1.8Mb in 16,552 objects coming from line 111 (in the added helper, the line not only creates the additional strings but also the match data that would have been created elsewhere). Overall there are 37.578 Mb in 746,567 Strings allocated (361Kb in 7,985 objects more than without the patch). tagging.rb is the 8th biggest consumer of memory (up one) and the validation helper being the 7th biggest call site. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8556) environment.conf modulepath should accept globs
Title: Message Title Sean Millichamp commented on PUP-8556 Re: environment.conf modulepath should accept globs The scenario we have is a set of modules that are organized on the filesystem like so: groups//modules In our scenario, "" happens to be customer, but I could see something similar using other groupings depending on organizational need. Today we solve this problem by jamming symlink creation into the end of our Puppetfile that collects all the module names (using Dir.glob) and puts symlinks to them from a single, otherwise empty, directory (which is specified in environment.conf). We've been doing this for 5+ years but there are a couple of problems with it: Every time users create a new module in this area in their "live" testing environments, they have to remember to manually create the symlinks (something which is otherwise done automatically for them when the testing environment is spun up). Since they don't do it all the time, it is frequently a source of confusion. The symlinks to/through directories do not work with the Code Manager / Static Catalogs combination. Access to file resources (e.g. with source => 'puppet:///modules/modulename') in these modules is not possible with static catalogs enabled - so despite our efforts to enable them we have been unable to use them so far. There are some organizational reasons why the above directory structure has some considerable advantages for us, and why having to know and list all the possible group/customer directories in environment.conf is a non-starter - unless we started generating environment.conf as part of our Puppetfile instead of generating symlinks, but then we still have the user awareness issue when creating new customer module areas. Though I can't see it, I'm told that PE-20305 contains information about the symlink / code manager / static catalogs bug and support cases #25081 and #28894 contain maybe a bit more detail about our particular use case. Add Comment
Jira (PUP-8556) environment.conf modulepath should accept globs
Title: Message Title Henrik Lindberg commented on PUP-8556 Re: environment.conf modulepath should accept globs I can see that this saves having to spell out a long modulepath if modules are in multiple locations in the env. Are there any other advantages that you see? Technically, I wonder if we should perhaps redesign so that the resolution of modulepath resolves directly to the actual modules. I.e. with this change there is a glob to find the moduledirs, and later a search to find the modules. We always need to find the modules on the module path, we could just as well do the globbing there. (Bigger change though). Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
