On 10/07/10 17:08, Brice Figureau wrote: > Hi, > > Congrats to the whole team for making 2.6.0 happen! > > On 10/07/10 08:58, James Turnbull wrote: > [snip] >> We've include release notes below that you can also see at: >> >> http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes > [snip] >> RELEASE NOTES >> >> Language > > [snip] > >> Support for hashes in the DSL >> >> This brings a new container syntax to the Puppet DSL: hashes. >> >> Hashes are defined like Ruby Hashes: >> >> { key1 => val1, ... } >> >> The Hash keys are strings but hash values can be any possible right >> values admitted in Puppet DSL (i.e. a function call or a variable) >> >> Currently it is possible: >> >> * to assign hashes to a variable >> $myhash = { key1 => "myval", key2 => $b } >> >> * to access hash members (recursively) from a variable containing a hash >> (works for array too): >> >> $myhash = { key => { subkey => "b" }} >> notice($myhash[key][subkey]] >> >> * to use hash member access as resource title >> >> * to use hash in default definition parameter or resource parameter if >> the type supports it (known for the moment). >> >> It is not possible to string interpolate an hash access. If it proves to >> be an issue it can be added or worked around with a string concatenation >> operator easily. > > In fact, Markus made this possible. Can you remove this above sentence? > >> It is not possible to use an hash as a resource title. This might be >> possible once we support compound resource title. > > [snip] > >> New options >> >> A new option is available, ca_name, to specify the name to use for the >> Certificate Authority certificate. It defaults to the value of the >> certname option (see http://projects.reductivelabs.com/issues/1507). >> >> A new option, dbconnections, is now available that specifies a limit for >> the number of database connections made to remote databases (postgreSQL, >> MySQL). >> >> A new option, dbport, is now available that specifies the database port >> for remote database connections. > > There's also a new option/feature that lets the puppet client use HTTP > compression (--http_compression): > > Allow http compression in REST communication with the master. > This setting might improve performance for agent -> master > communications over slow WANs. > Your puppetmaster needs to support compression (usually by activating > some settings in a reverse-proxy in front of the puppetmaster, which > rules out webrick). > It is harmless to activate this settings if your master doesn't support > compression, but if it supports it, this setting might reduce > performance on high-speed LANs. > > The commit msg of the patch bringing this feature also contains what to > add to Apache or Nginx to let the master support http compression.
And I finally had time to benchmark http compression a little bit. Test setup: * one 2.6.0 puppetmaster (nginx+mongrel) * client attached to a slow link (768kbps link, which is in fact a VPN inside a DSL to DSL link). The client is a puppet-test (not a full blown client), so it doesn't download the sourced file, I measured only downloading a large catalog (about 2000 resources). The whole operation (ie client asking for its catalog, master compilation, catalog reception and deserialization) takes: * no compression: about 90s * http compression: about 67s So there's a net win, which would be even greater in normal conditions (ie client downloading source files) :-) -- Brice Figureau My Blog: http://www.masterzen.fr/ -- You received this message because you are subscribed to the Google Groups "Puppet Developers" 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-dev?hl=en.
