On Wed, Aug 28, 2013 at 10:42 AM, Henrik Lindberg < henrik.lindb...@cloudsmith.com> wrote:
> On 2013-28-08 19:19, Andy Parker wrote: > > What I'm thinking (in terms of a workflow a user might perform): >> >> # produce a fully validated AST serialization >> $ puppet manifest compile --manifest site.pp --modulepath >> ~/modules:/etc/puppet/modules --output my-puppet-code.ast >> # load that validated AST as a particular environment into the >> master. The master would swap in the new code for that environment only >> at the start of a new compile, any existing compiles using the old code >> loaded for the environment would continue unchanged. >> $ puppet master load --pic my-puppet-code.pic --environment staging >> This is just an example of how it could be split up into multiple >> commands. This could also be done at the beginning of the catalog >> request instead of by the user. >> >> At the moment, I'm ignoring any data that would need to go along with >> this. Taking that into account might change things as separate commands. >> >> > Basically this is a copy of the AST into another form that then has to be > loaded (which means some form of parsing and resurrection of the data). If > so, Ruby marshal of the AST will be the fastest. I think we can allow this > to be both a user level command "compile" as well as "on demand" (a check > is made at transaction start that source has not changed, if so it can be > compiled on the fly). > > Not always the case https://gist.github.com/aishfenton/480059 I think the exact way of serializing things can be discussed at another time. What I'm interested in is whether anyone things that this kind of "bulk parse and validate first, then eval" is a good move. My opinion is that it would be good for the master, but as others point out would be a problem for interactive (aka puppet apply) use. I think we can address that by creating a compiler and object model of manifests such that we can recompile only the parts needed for interactive use (I hesitate to use the term "incremental compiler" because that can get a little confusing). > I think it is safe to use Ruby marshal since the data is for a specific > runtime and it is completely managed by this runtime. > > If we instead want off-line compilation and have sharing of bundles (i.e. > 'jar-like' things), Ruby Marshal is out of the question, and I then doubt > that a serialized AST is much faster to load than parsing the language, but > it depends to a large degree on the complexity of difficult to lex/parse > constructs (gazillions of interpolation expressions). > > A jar-like approach would mean that only the timestamp of the jar needs to > be checked, then reading its manifest in order to know its content. > > Yeah, that is the win of using a jar-like approach. A single stat to know if we need to reload (or no stat at all and the reload only happens on a signal) > > - henrik > > > -- > 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+unsubscribe@**googlegroups.com<puppet-dev%2bunsubscr...@googlegroups.com> > . > To post to this group, send email to puppet-dev@googlegroups.com. > Visit this group at > http://groups.google.com/**group/puppet-dev<http://groups.google.com/group/puppet-dev> > . > For more options, visit > https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> > . > -- Andrew Parker a...@puppetlabs.com Freenode: zaphod42 Twitter: @aparker42 Software Developer *Join us at PuppetConf 2014, September 23-24 in San Francisco* -- 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 post to this group, send email to puppet-dev@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
