Re: [Puppet-dev] Puppet 4: defined resource types and epp template

2016-02-04 Thread Martin Alfke 

On 01 Feb 2016, at 19:15, Henrik Lindberg  
wrote:

> 
> That is exactly what you should do. An external (file based epp) when called, 
> does not get to see variables in the scope from which it was called/used. 
> This design is deliberate. Think of the template as a function you are 
> calling, and you have to give it its arguments.

In this case the documentation on the website is wrong:
https://docs.puppetlabs.com/puppet/latest/reference/lang_template_epp.html#example-template

The example just switches from template() to epp() function.
According to your writing you must pass all parameters to the epp() function.

> 
> Contrast this with the inline_epp, which you can think of as a 
> lambda/code-block. Here the code block gets to see the variables in scope, 
> since it is itself in that scope (part of the same piece of code).
> 
Got it.
To be honest: this is ugly.
I always thought of epp() being a full replacement for template() without the 
scope issue.
This especially feels bad, when we will have performance improvement for epp in 
the future.

I need to rethink whether inline_epp() is the proper replacement for template() 
function.


> This design makes the code more maintainable and templates more reusable. It 
> is also easier to test the templates (there is a command line utility (puppet 
> epp IIRC) that allows you to feed values into a templates and render the 
> result).
> 
> Hope that helps
> - henrik
> 
>> 
>> Best,
>> Martin
>> 
> 
> 
> -- 
> 
> Visit my Blog "Puppet on the Edge"
> http://puppet-on-the-edge.blogspot.se/
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-dev/n8o7b5%24k5j%241%40ger.gmane.org.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/E26F3ED6-17F6-47FA-A215-2463253858ED%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] Announce: puppet-agent 1.3.5 available

2016-02-04 Thread Morgan Rhodes 
Puppet Agent 1.3.5 is now available! This is a security release that
updates OpenSSL to 1.0.2f.

See the release notes for the puppet agent package here:
http://docs.puppetlabs.com/puppet/latest/reference/release_notes_agent.html

To install or upgrade puppet-agent, follow the getting started directions:
http://docs.puppetlabs.com/puppet/latest/reference/index.html
-- 
Morgan Rhodes
mor...@puppetlabs.com
Release Engineer

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CA%2BFnDv173AW9Hj675P2S8XPgjwed1kPE5pcmON_Z_g8_bLtD6A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: ruby-1.9.3 in yum.puppetlabs.com

2016-02-04 Thread Michael Stahnke 
On Fri, Jan 29, 2016 at 8:16 AM, Alex Harvey  wrote:

> Yep, it's solved in Puppet 4 - the all-in-one package is fantastic, as is
> so much in Puppet 4.  However PE hasn't release Puppet 4 yet; my assessment
> of the Puppet Forge is that not many modules out there are ready; and I am
> not super confident that other tools in the ecosystem like Beaker,
> Librarian etc are ready; so I am not personally willing to recommend Puppet
> 4 to customers at this stage.  In any case, loads and loads of people will
> be using Puppet 3 for a long, long time yet.
>

Chris already covered this, but this incorrect. PE has had Puppet 4 since
July of 2015.

>
> And then I get back to - why not just put the RPMs in the yum repository?
> They're already in PE aren't they?  I get it that it's not really Puppet's
> problem that EL is crap, but on the other hand, it actually is.  Puppet
> made the choice to build a DSL on Ruby.  So, when I discovered earlier
> today that there's still no supported Ruby for the latest Puppet 3 for
> CentOS Linux, I couldn't believe it.  This is RUBY on EL6/7.  This is not a
> wacky feature request.  Without Ruby, the amazingly complex, feature rich
> ecosystem we know and love as Puppet is a castle built on sand.
>

Why would I ship a ruby when Red Hat does? The packages we ship for Puppet
3 are designed to ship with System Ruby. System ruby is 1.8.7. I realize
that is old, but that is what is there on EL6. That ruby is supported by
Red Hat until 2023. If you want to run on a non-system ruby, gems are
provided or you are welcome to package your own thing.

>
> It shouldn't be so hard to stand Puppet up in 2016.  I love Puppet, and I
> love Ruby, and I hate hearing super smart developers telling me that Salt
> or Ansible are superior, when their main reason for saying so is that Ruby
> and Puppet together are just way too many yaks to shave.  And I hear this,
> all, the, time.
>

What's difficult about install a puppetlabs-release package and yum install
puppet?

I think your complaint is that a non-standard use-case doesn't work. I
don't understand why you have that use-case, and we can solve everybody's
individual case. We provide a system-ruby enabled package. We also provide
puppet 4 with everything you need.


>
> On Saturday, January 30, 2016 at 12:39:15 AM UTC+11, Erik Dalén wrote:
>>
>> Isn't this already solved with the Puppet 4.x packaging (puppet-agent)?
>> So why insist on installing an old Puppet version instead of a modern one?
>>
>> Personally I prefer that PuppetLabs is developing new features in Puppet
>> 4.x instead of spending time improving packaging and stuff for Puppet 3.x.
>>
>> On Fri, 29 Jan 2016 at 14:31 Alex Harvey  wrote:
>>
>>> Thanks for the heads up.  Anything less than Puppet Labs providing a
>>> working Ruby at yum.puppetlabs.com, or CentOS providing one, feels to
>>> me like a bit of a hack.  I've seriously got a customer wanting to ditch
>>> Puppet and go to Ansible because because they just want it to be easy to
>>> install open source Puppet 3.  We were burnt by Puppet Omnibus.  It just
>>> feels a bit like Puppet's giving us the finger, when all it would take is
>>> someone to stick an RPM on a server.  This problem could have been solved
>>> years ago, as the original poster in this thread suggested.
>>>
>>> On Friday, January 29, 2016 at 10:38:29 PM UTC+11, Rob Nelson wrote:
>>>
 Ruby 1.9.3 is available in the Software Collections (SCL) repository.
 Instructions at
 https://digitalchild.info/centos-6-5-and-ruby1-9-3-via-software-collections/
 .

 There may be some side effects for any system utilities that expect
 1.8.7 but that's a risk you'll have to accept if you're still on EL6, just
 like every other ancient version of software it includes. It does "work" in
 most senses, though.

 On Friday, January 29, 2016, Alex Harvey  wrote:

> https://bugs.centos.org/view.php?id=10268
>
> On Friday, January 29, 2016 at 4:15:16 PM UTC+11, Alex Harvey wrote:
>>
>> I thought I'd just put it out there that it's the Year of Our Lord
>> 2016* and CentOS is still installing Ruby 1.8.7, and
>> yum.puppetlabs.com is still not providing a modern Ruby either.
>>
>> Yes, PE provides a Ruby.
>> Yes, Puppet 4 provides a Ruby.
>> Yes, Puppet-omnibus can build a Ruby.
>> Yes, RVM is kinda cool.
>> Yes, compiling Ruby is kinda fun sometimes.
>>
>> But, as a user, I want to type "yum install ruby" and, OMFG, ruby
>> installs.
>>
>> *With apologies to adherents of other religious faiths and proponents
>> of Lunar and non-Gregorian calendars.
>>
>> :)
>>
>> On Friday, July 26, 2013 at 1:13:24 AM UTC+10, Christian Flamm wrote:
>>>
>>> Hi,
>>> I'm (using CentOS 6.4 and I'm) suffering from an AFAIU
>>> performance/design bug (http://projects.puppetlabs.com/issues/20865)

[Puppet-dev] Announce: Puppet 3.8.6 available

2016-02-04 Thread Morgan Rhodes 
Puppet 3.8.6 is now available. This is a security release that updates
OpenSSL to 1.0.2f for the Windows MSIs. There are no changes for
non-Windows platforms. See the full release notes here:

http://docs.puppetlabs.com/puppet/3.8/reference/release_notes.html

For installation and upgrade instructions, see this doc:

http://docs.puppetlabs.com/puppet/3.8/reference/pre_install.html
-- 
Morgan Rhodes
mor...@puppetlabs.com
Release Engineer

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CA%2BFnDv2rJW0bv9D4PSL6XhgtRr2-zi0E%2BJF-udrqvsWo8FDrbA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] metaparam question

2016-02-04 Thread Kylo Ginsberg 
On Wed, Feb 3, 2016 at 7:47 AM, R.I.Pienaar  wrote:

> hello,
>
> I would like to add a metaparameter - which I think is easy now via
> Type.newmetaparam.
>

We haven't been thinking of metaparameters as a general purpose extension
point. This came up once before that I know of, about a year ago, and
there's a little discussion of this in
https://tickets.puppetlabs.com/browse/PUP-4281. The conclusion we reached
at the time was, more or less, to explore whether the desired change could
be accomplished with a puppet function and/or a change to core puppet.


>
> The thing that I can't seem to find any example of though is how to
> make this metaparameter do something on the nodes for all providers
> or all types.


> Imagine there's a metaparam that might describe how to test a resource
> works, something like:
>
>service{"httpd": validate => "check_http --port 80 -H localhost"}
>
> I'd then want to have some code that would be run on the agent nodes
> for any resource that has this param set.
>

I don't think something like this exists per se, but 'validate' might be
one such example of something worth adding to core puppet. Fwiw, one
resource-specific example added not too long ago is the file type's
validate_cmd:

https://docs.puppetlabs.com/puppet/latest/reference/type.html#file-attribute-validate_cmd
.

Also, I'm guessing you're aware but another tool in the toolbox *might*
include the postrun_command setting (which is *not* per-provider as you
were thinking):

https://docs.puppetlabs.com/puppet/latest/reference/configuration.html#postruncommand

More broadly, there has been some discussion on a few threads and tickets
about making the agent lifecycle provide some more useful hooks, so I'd
love to hear more ideas about how to improve this.

Thanks!
Kylo


> Does anyone have any hints or know of an example of this?
>
> thanks
>
> ---
> R.I.Pienaar
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/70254077.345165.1454514435921.JavaMail.zimbra%40devco.net
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Kylo Ginsberg | k...@puppetlabs.com | irc: kylo | twitter: @kylog

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CALsUZFHniTYyYU0ThP-Jk37f6QXroJ0P0-K0PkbRPXMsdB6v0Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Puppet 4: defined resource types and epp template

2016-02-04 Thread Martin Alfke 

On 04 Feb 2016, at 14:30, Henrik Lindberg  
wrote:

> On 2016-04-02 11:46, Martin Alfke wrote:
>> 
>> On 01 Feb 2016, at 19:15, Henrik Lindberg  
>> wrote:
>> 
>>> 
>>> That is exactly what you should do. An external (file based epp) when 
>>> called, does not get to see variables in the scope from which it was 
>>> called/used. This design is deliberate. Think of the template as a function 
>>> you are calling, and you have to give it its arguments.
>> 
>> In this case the documentation on the website is wrong:
>> https://docs.puppetlabs.com/puppet/latest/reference/lang_template_epp.html#example-template
>> 
> The long example is wrong in that it does not show that arguments must be 
> given in a hash.
> 
> The documetation for epp has unfortunately been boiled down to just the bare 
> minimum and the important distinction that variables must be given has been 
> lost in the series of rewrites that were made.
> 
> The implementation clearly restricts epp() to only see global scope.
> 
> The specification is also clear about scoping: 
> https://github.com/puppetlabs/puppet-specifications/blob/master/language/templates.md#visibility-of-scoped-variables

Yes. the written description is clear about that.

> 
> I filed a documentation ticket.
> 
>> The example just switches from template() to epp() function.
>> According to your writing you must pass all parameters to the epp() function.
>> 
> 
> yes, epp() requires that arguments are given in the call. epp() templates 
> only have access to global variables (i.e. $::osfamily and such).
> 
> 
>>> 
>>> Contrast this with the inline_epp, which you can think of as a 
>>> lambda/code-block. Here the code block gets to see the variables in scope, 
>>> since it is itself in that scope (part of the same piece of code).
>>> 
>> Got it.
>> To be honest: this is ugly.
>> I always thought of epp() being a full replacement for template() without 
>> the scope issue.
> 
> The ERB based template() function is for templates in files. The epp() 
> function is also for files. The big difference between them is that all 
> variables used by the template processed by epp() must be given to the 
> function.
> 
> The inline_epp() may in the special case, when it does not declare parameters 
> have access to all variables in scope. This was deemed to be harmless as all 
> of the logic is in one place, and there is never a question of reuse. It is 
> also seen as an easy way to transition to inline_epp() from inline_template().
> 
> With that, I am not sure I understand your comments. What is it that you 
> think is ugly?
> 
>> This especially feels bad, when we will have performance improvement for epp 
>> in the future.
>> 
> 
> I have not seen tickets with reports of performance problems. How bad is it?

You mentioned it somewhere at PuppetConf that in the future the epp() function 
will have a performance benefit over template() function due to template() 
needing the ruby stack whereas epp() is running in the java based parser (as 
far as I have understood this).

> 
> Best
> - henrik
> 
> -- 
> 
> Visit my Blog "Puppet on the Edge"
> http://puppet-on-the-edge.blogspot.se/
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-dev/n8vjpn%244u0%241%40ger.gmane.org.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/F7162FAD-4521-4CAF-AEA3-B39F87AA4EAD%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] Re: Puppet 4: defined resource types and epp template

2016-02-04 Thread Henrik Lindberg 

On 2016-04-02 11:46, Martin Alfke wrote:


On 01 Feb 2016, at 19:15, Henrik Lindberg  
wrote:



That is exactly what you should do. An external (file based epp) when called, 
does not get to see variables in the scope from which it was called/used. This 
design is deliberate. Think of the template as a function you are calling, and 
you have to give it its arguments.


In this case the documentation on the website is wrong:
https://docs.puppetlabs.com/puppet/latest/reference/lang_template_epp.html#example-template

The long example is wrong in that it does not show that arguments must 
be given in a hash.


The documetation for epp has unfortunately been boiled down to just the 
bare minimum and the important distinction that variables must be given 
has been lost in the series of rewrites that were made.


The implementation clearly restricts epp() to only see global scope.

The specification is also clear about scoping: 
https://github.com/puppetlabs/puppet-specifications/blob/master/language/templates.md#visibility-of-scoped-variables


I filed a documentation ticket.


The example just switches from template() to epp() function.
According to your writing you must pass all parameters to the epp() function.



yes, epp() requires that arguments are given in the call. epp() 
templates only have access to global variables (i.e. $::osfamily and such).





Contrast this with the inline_epp, which you can think of as a 
lambda/code-block. Here the code block gets to see the variables in scope, 
since it is itself in that scope (part of the same piece of code).


Got it.
To be honest: this is ugly.
I always thought of epp() being a full replacement for template() without the 
scope issue.


The ERB based template() function is for templates in files. The epp() 
function is also for files. The big difference between them is that all 
variables used by the template processed by epp() must be given to the 
function.


The inline_epp() may in the special case, when it does not declare 
parameters have access to all variables in scope. This was deemed to be 
harmless as all of the logic is in one place, and there is never a 
question of reuse. It is also seen as an easy way to transition to 
inline_epp() from inline_template().


With that, I am not sure I understand your comments. What is it that you 
think is ugly?



This especially feels bad, when we will have performance improvement for epp in 
the future.



I have not seen tickets with reports of performance problems. How bad is it?

Best
- henrik

--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

--
You received this message because you are subscribed to the Google Groups "Puppet 
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/n8vjpn%244u0%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] Re: Puppet 4: defined resource types and epp template

2016-02-04 Thread Henrik Lindberg 

On 2016-02-02 21:15, John Bollinger wrote:


On Monday, February 1, 2016 at 12:15:12 PM UTC-6, henrik lindberg wrote:

Contrast this with the inline_epp, which you can think of as a
lambda/code-block. Here the code block gets to see the variables in
scope, since it is itself in that scope (part of the same piece of
code).



Hmmm. The docs


The docs are wrong. I have filed a ticket.

The behavior is specified here 
https://github.com/puppetlabs/puppet-specifications/blob/master/language/templates.md#visibility-of-scoped-variables


The implementation works as specified.

Best
- henrik



cast that behavior of inline_epp() as a special exception, and claim
it's applicable only when the template declares no parameters and you
don't pass any (and only with inline_epp()).  Are the docs wrong?  If
they are correct, then surely it is best to view that exception *as* an
exception, not as some sort of natural consequence of the scope in which
the template or the inline_epp() call appears.

In fact, inasmuch as the template might be presented in the form of a
variable defined in a different scope, drawing its actual value from
who-knows-where, I really think it's confusing to assert that such an
exception is a natural extension of Puppet's scoping rules.  Call it
what it is: an ease-of-use aid applicable only to cases where the
stricter ordinary scoping rules of EPP templates are of little advantage.


John

--
You received this message because you are subscribed to the Google
Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to puppet-dev+unsubscr...@googlegroups.com
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/02150181-1b5d-47a6-b2a4-4ebb3f8a6f98%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.



--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

--
You received this message because you are subscribed to the Google Groups "Puppet 
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/n8vjvv%248b0%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] metaparam question

2016-02-04 Thread Luke Kanies 
> On Feb 4, 2016, at 3:35 PM, Kylo Ginsberg  wrote:
> 
>> On Wed, Feb 3, 2016 at 7:47 AM, R.I.Pienaar  wrote:
>> hello,
>> 
>> I would like to add a metaparameter - which I think is easy now via
>> Type.newmetaparam.
> 
> We haven't been thinking of metaparameters as a general purpose extension 
> point. This came up once before that I know of, about a year ago, and there's 
> a little discussion of this in 
> https://tickets.puppetlabs.com/browse/PUP-4281. The conclusion we reached at 
> the time was, more or less, to explore whether the desired change could be 
> accomplished with a puppet function and/or a change to core puppet.

I don't remember my original logic for metaparams not being an extension point. 
Given the system's support for easily loading this kind of plugin, it should be 
easy to add.

The discussion on the ticket is pretty limited. We've got multiple use cases 
here, and I have seen use cases in the past brought up, but they were mostly on 
lists or in person, so I don't think they made it into the ticketing system.

RI - you up for a pull request to add the autoloading? Have you thought much 
about how this might go wrong?

>> The thing that I can't seem to find any example of though is how to
>> make this metaparameter do something on the nodes for all providers
>> or all types.
>> 
>> Imagine there's a metaparam that might describe how to test a resource
>> works, something like:
>> 
>>service{"httpd": validate => "check_http --port 80 -H localhost"}
>> 
>> I'd then want to have some code that would be run on the agent nodes
>> for any resource that has this param set.
> 
> I don't think something like this exists per se, but 'validate' might be one 
> such example of something worth adding to core puppet. Fwiw, one 
> resource-specific example added not too long ago is the file type's 
> validate_cmd: 
> 
> https://docs.puppetlabs.com/puppet/latest/reference/type.html#file-attribute-validate_cmd.
> 
> Also, I'm guessing you're aware but another tool in the toolbox *might* 
> include the postrun_command setting (which is *not* per-provider as you were 
> thinking):
> 
> https://docs.puppetlabs.com/puppet/latest/reference/configuration.html#postruncommand

Ryan and others on his team have discussed ways of using the new 
consume/produce system for doing service validation. I don't think the whole 
system is quite in place, but there are some good ideas getting close.

That doesn't settle the generalized plugin capability issue, though.

> More broadly, there has been some discussion on a few threads and tickets 
> about making the agent lifecycle provide some more useful hooks, so I'd love 
> to hear more ideas about how to improve this.

> 
> Thanks!
> Kylo
> 
>> 
>> Does anyone have any hints or know of an example of this?
>> 
>> thanks
>> 
>> ---
>> R.I.Pienaar
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to puppet-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-dev/70254077.345165.1454514435921.JavaMail.zimbra%40devco.net.
>> For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> -- 
> Kylo Ginsberg | k...@puppetlabs.com | irc: kylo | twitter: @kylog
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-dev/CALsUZFHniTYyYU0ThP-Jk37f6QXroJ0P0-K0PkbRPXMsdB6v0Q%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/FB2D2883-CE00-4D61-ACC2-0B59F807A4D5%40puppetlabs.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] Re: Puppet 4: defined resource types and epp template

2016-02-04 Thread Henrik Lindberg 

On 2016-04-02 14:40, Martin Alfke wrote:

On 04 Feb 2016, at 14:30, Henrik Lindberg  
wrote:

On 2016-04-02 11:46, Martin Alfke wrote:

This especially feels bad, when we will have performance improvement for epp in 
the future.


I have not seen tickets with reports of performance problems. How bad is it?


You mentioned it somewhere at PuppetConf that in the future the epp() function 
will have a performance benefit over template() function due to template() 
needing the ruby stack whereas epp() is running in the java based parser (as 
far as I have understood this).



It has a performance benefit already! What I was referring to is that in 
order to construct the ERB context we need to iterate over all variables 
in all visible scopes and create a temporary class/context where each of 
those variables are added as instance variables. This may mean hundreds 
or possible thousands of variables that must be copied over. This is 
repeated for each an every call to template() and inline_template().


The epp() and inline_epp() does not have to do this. It simply uses the 
scope (global or local depending on epp/inline_epp), then variable 
access goes directly against the scope.


I noticed a performance improvement when manually playing around with 
epp. But this was for small templates, and I did not write any 
benchmarks for epp. However, .pp logic is slower than ruby in general, 
so it depends on what you are doing.


We have ideas for further improvements.

A big improvement will come in the future when we have a native 
compiler. The EPP based templates will then run much faster, and most 
likely faster than ERB since ERB means calling Ruby in an external 
process and serializing the 100-1000 variables for each and every 
invocation.


So, unless you are using very large templates or have complex logic, 
iterate over massive data structures, or having the need to use external 
ruby code, I would absolutely recommend using EPP as soon as possible.


If anyone have real performance problems with EPP I would like to hear 
about it so we can optimize.


Best,
- henrik

--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

--
You received this message because you are subscribed to the Google Groups "Puppet 
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/n902kb%24d6b%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.