Jira (PUP-3647) Puppet stores files forever in state.yaml

Henrik Lindberg (JIRA) Wed, 14 Mar 2018 03:20:18 -0700

Title: Message Title

I started to read code to figure out what is going on - beginning with why the state file is loaded twice. The two loads (in the order they occur) come from:

configurer.rb in a call to client.init_storage
catalog.rb in its apply method does this Puppet::Util::Storage.load if host_config?

That raises the question - why is catalog doing this only if "host_config?" and why is it doing that? Is it a valid reload because it should start from the original stored state? Can someone explain what "host_config?" is?

A bit further down in catalog.rb we can read this:

      # Don't try to store state unless we're a host config

      # too recursive.

      Puppet::Util::Storage.store if host_config?

So, clearly the cache is never written by an apply unless it is a "host_config?"

The load caused by the configurer seems to be because it uses the cache, and attempt to rescue a bad situation:

  # Initialize and load storage

  def init_storage

      Puppet::Util::Storage.load

      @compile_time ||= Puppet::Util::Storage.cache(:configuration)[:compile_time]

  rescue => detail

    Puppet.log_exception(detail, _("Removing corrupt state file %{file}: %{detail}") % { file: Puppet[:statefile], detail: detail })

    begin

      Puppet::FileSystem.unlink(Puppet[:statefile])

      retry

    rescue => detail

      raise Puppet::Error.new(_("Cannot remove %{file}: %{detail}") % { file: Puppet[:statefile], detail: detail }, detail)

end

end

The line that sets @compile_time seems to be why it needs to read it from loaded state. Anyone know what this is about?

The code seems to be from 2007 written by Luke.

I think the two loads comes from first applying the settings catalog, and then applying the real catalog. I base this on seeing catalog.apply being called three times, and the first time host_config? is false, the second time it is true, third time it is false. It is a guess though. I also wonder what the third apply is for?

The handling of errors from the load that is done in configurer looks wrong - there is similar handling in Catalog that seems to do a better job - renaming the file with a "bad" so it can be examined, and also handling the issue of not being able to remove (say on windows).

Interestingly - if I brute force just return in configurer init_storage to this:

  # Initialize and load storage

  def init_storage

    return  ### SUPERHACK - WHAT HAPPENS

end

It still passes all tests in the puppet repo. (Which makes me sad...)

Add Comment

This message was sent by Atlassian JIRA

--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

Jira (PUP-3647) Puppet stores files forever in state.yaml

Reply via email to