thr3ads.net - Puppet users - [Puppet Users] Autorequiring and dependency problem [Dec 2010]

If this information is useful, please help other people find it:
Share via:

Jay N.

2010-Dec-15 22:27 UTC

[Puppet Users] Autorequiring and dependency problem

Hi,

I have a dependency problem in my configuration. I have thoses 2
objects.

file { "/etc/puppet/files":
...
}

file { "/etc/puppet":
...
require => File["/etc/puppet/files"],
}

I thought I would have no problem with that but /etc/puppet is
autorequired by /etc/puppet/files, which means a dependency cycle. So
my first question is, is there a way to avoid that unwanted
autorequiring?

Let me explain my choice : I first change the owner of /etc/puppet/
files for someone else than root being able to write. Then I commit my
svn configuration into /etc/puppet/files ( I do like that because root
doesn''t have the right to checkout, only some users does ), and in the
end I update my puppet configuration ( with the /etc/puppet object )
using the checkouted files. Maybe there''s a better way to do it.

Second time : when I saw there was a problem, I tried the dirty way by
commenting the /etc/puppet/files object and creating an exec object
doing just the same.

exec { "Dirty way":
command => "chown svn /etc/puppet/files",
path => "/usr/bin:/usr/sbin",
unless => "ls -la /etc/puppet/files | head -2 | grep grpsvn",
}

Always the same dependency problem because "Dirty way" autorequires /
etc/puppet ( I changed the require in /etc/puppet too ).

The weird thing I realized is that if I change my exec to :
exec { "Dirty way":
command => "chgrp grpsvn /etc/puppet/files",
path => "/usr/bin:/usr/sbin",
unless => "cd /etc; ls -la puppet/files | head -2 | grep grpsvn",
}

then I don''t have any more the autorequire and the configuration is
working just fine. Is it normal that puppet parses the unless
parameter ( and maybe others ) to find autorequirements? Isn''t it too
much autorequirements?

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Stefan Schulte

2010-Dec-15 22:53 UTC

head link

Re: [Puppet Users] Autorequiring and dependency problem

On Wed, Dec 15, 2010 at 02:27:46PM -0800, Jay N. wrote:> Hi,
> 
> I thought I would have no problem with that but /etc/puppet is
> autorequired by /etc/puppet/files, which means a dependency cycle. So
> my first question is, is there a way to avoid that unwanted
> autorequiring?
> 
An explicit require should overwrite any autorequire and should not
cause a dependency cycle. You should see something like this when
running in debugmode

debug: /Stage[main]//Node[default]/File[/etc/puppet/files]: Skipping
automatic relationship with File[/etc/puppet]

I just tried that on my own to be sure:

  node default {
    file { ''/etc/puppet'':
      require => File[''/etc/puppet/files''],
      ensure => directory,
    }
    file { ''/etc/puppet/files'':
      ensure => directory,
    }
  }

Worked for me

-Stefan

jcbollinger

2010-Dec-16 16:15 UTC

head link

[Puppet Users] Re: Autorequiring and dependency problem

On Dec 15, 4:27 pm, "Jay N." <the.s...@gmail.com>
wrote:> Hi,
>
> I have a dependency problem in my configuration. I have thoses 2
> objects.
>
> file { "/etc/puppet/files":
> ...
>
> }
>
> file { "/etc/puppet":
> ...
> require => File["/etc/puppet/files"],
>
> }
>
> I thought I would have no problem with that but /etc/puppet is
> autorequired by /etc/puppet/files, which means a dependency cycle. So
> my first question is, is there a way to avoid that unwanted
> autorequiring?
>
> Let me explain my choice : I first change the owner of /etc/puppet/
> files for someone else than root being able to write. Then I commit my
> svn configuration into /etc/puppet/files ( I do like that because root
> doesn''t have the right to checkout, only some users does ), and in
the
> end I update my puppet configuration ( with the /etc/puppet object )
> using the checkouted files. Maybe there''s a better way to do it.
As I interpret what you wrote, you are giving Puppet conflicting
definitions for the properties of /etc/puppet/files and its contents:
one set of definitions in resource File["/etc/puppet/files"] and a
different set indirectly via recursion from File["/etc/puppet"].  This
is not the Puppet Way, and you are likely to continue to have problems
as long as you''re fighting Puppet.  Each managed resource''s
properties
should be defined exactly once.

Whenever you think "I first [...].  Then  I [...]," you are trying to
use a Puppet configuration as a script, and that will mainly get you
into trouble.  To master Puppet you must let go of the script engine
mentality.  Puppet provides resource depenencies are all about state
(just like the rest of the DSL).  For example, directory /etc/puppet/
files cannot exist unless /etc/puppet exists and is a directory,
therefore the former depends on the latter, whether you model it
explicitly or not.  The Puppet agent does use that information to
choose an acceptable order to apply resources, but if you focus on
that detail then you are missing the point.

To put it an entirely different way, never try to model transient
state in your Puppet configuration.  It goes against the tao of
Puppet.

[...]
> The weird thing I realized is that if I change my exec to :
> exec { "Dirty way":
> command => "chgrp grpsvn /etc/puppet/files",
> path => "/usr/bin:/usr/sbin",
> unless => "cd /etc; ls -la puppet/files | head -2 | grep
grpsvn",
>
> }
>
> then I don''t have any more the autorequire and the configuration
is
> working just fine.
Puppet is only a program.  If you try hard enough, you can usually
trick it.  Doing so is rarely a good idea.
> Is it normal that puppet parses the unless
> parameter ( and maybe others ) to find autorequirements?
Yes.
> Isn''t it too
> much autorequirements?
No.

You have several alternatives that should achieve the end result you
want, while being more in line with Puppet''s model:

1) Give root svn access

2) Make the files (permanently) writable by some non-root user, and
perform the svn update as that user.  The user can be a system user
such as puppet.  Do not twiddle ownership or permissions back and
forth.

3) Find or create an svn resource type to add to Puppet that will
handle the twiddling for you.

4) Move all the ownership and permission twiddling into your checkout
script (i.e. remove the two File resources with which you are
currently trying to do the twiddling).  That will make the overall
operation atomic from Puppet''s perspective, which is a good thing.

5) If you only want to manage your puppetmaster in this particular way
(which seems possible given the specific resources involved) then it
may be more reasonable to do it manually.  That will also give you the
opportunity to temporarily shut down puppetmasterd while you do so, to
avoid clients getting an inconsistent view of the files if they happen
to request them while the update is in progress.  You could schedule
that with cron if you can accommodate puppetmasterd not coming back up
in the event that the script errors out.

Good luck,

John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Jay N.

2010-Dec-18 11:16 UTC

head link

[Puppet Users] Re: Autorequiring and dependency problem

Thanks John and Stefan.

Sorry for the delay to answer. Actually, the /etc/puppet object was
too ambitious, I modified it to handle every file and subdirectory
under /etc/puppet. Like that, it''s a lot easier to handle dependencies
and ownership. Also, it''s troublesome to handle the svn under /etc/
puppet/files so I think I''ll move that somewhere else.

I didn''t think about a script handeling the checkout and the
permissions but it''s a good idea, same for the resource, I''ve
never
used it before so I''ll have to take a look.

The problem with your 5) is that I would have too many puppetmasters
to handle ( lots of separate networks ). Every modification I would
make somewhere would have to be manually downloaded everywhere which
mean loosing all the advantages of Puppet. My idea is to have a single
point where I manage everything. What we plan to do manually ( as our
configuration won''t change often ) is the puppetd -t requests, from
the level-2 puppetmasters and from the nodes, we don''t want actually
to automatize that.

But it''s also because we actually miss a development environment,
which is the next step I''ll have to work on ;-)

I''ll come back if I have any more questions, thanks again.

Jay

On 16 déc, 17:15, jcbollinger <John.Bollin...@stJude.org>
wrote:> On Dec 15, 4:27 pm, "Jay N." <the.s...@gmail.com> wrote:
>
>
>
> > Hi,
>
> > I have a dependency problem in my configuration. I have thoses 2
> > objects.
>
> > file { "/etc/puppet/files":
> > ...
>
> > }
>
> > file { "/etc/puppet":
> > ...
> > require => File["/etc/puppet/files"],
>
> > }
>
> > I thought I would have no problem with that but /etc/puppet is
> > autorequired by /etc/puppet/files, which means a dependency cycle. So
> > my first question is, is there a way to avoid that unwanted
> > autorequiring?
>
> > Let me explain my choice : I first change the owner of /etc/puppet/
> > files for someone else than root being able to write. Then I commit my
> > svn configuration into /etc/puppet/files ( I do like that because root
> > doesn''t have the right to checkout, only some users does ),
and in the
> > end I update my puppet configuration ( with the /etc/puppet object )
> > using the checkouted files. Maybe there''s a better way to do
it.
>
> As I interpret what you wrote, you are giving Puppet conflicting
> definitions for the properties of /etc/puppet/files and its contents:
> one set of definitions in resource File["/etc/puppet/files"] and
a
> different set indirectly via recursion from File["/etc/puppet"].
 This
> is not the Puppet Way, and you are likely to continue to have problems
> as long as you''re fighting Puppet.  Each managed
resource''s properties
> should be defined exactly once.
>
> Whenever you think "I first [...].  Then  I [...]," you are
trying to
> use a Puppet configuration as a script, and that will mainly get you
> into trouble.  To master Puppet you must let go of the script engine
> mentality.  Puppet provides resource depenencies are all about state
> (just like the rest of the DSL).  For example, directory /etc/puppet/
> files cannot exist unless /etc/puppet exists and is a directory,
> therefore the former depends on the latter, whether you model it
> explicitly or not.  The Puppet agent does use that information to
> choose an acceptable order to apply resources, but if you focus on
> that detail then you are missing the point.
>
> To put it an entirely different way, never try to model transient
> state in your Puppet configuration.  It goes against the tao of
> Puppet.
>
> [...]
>
> > The weird thing I realized is that if I change my exec to :
> > exec { "Dirty way":
> > command => "chgrp grpsvn /etc/puppet/files",
> > path => "/usr/bin:/usr/sbin",
> > unless => "cd /etc; ls -la puppet/files | head -2 | grep
grpsvn",
>
> > }
>
> > then I don''t have any more the autorequire and the
configuration is
> > working just fine.
>
> Puppet is only a program.  If you try hard enough, you can usually
> trick it.  Doing so is rarely a good idea.
>
> > Is it normal that puppet parses the unless
> > parameter ( and maybe others ) to find autorequirements?
>
> Yes.
>
> > Isn''t it too
> > much autorequirements?
>
> No.
>
> You have several alternatives that should achieve the end result you
> want, while being more in line with Puppet''s model:
>
> 1) Give root svn access
>
> 2) Make the files (permanently) writable by some non-root user, and
> perform the svn update as that user.  The user can be a system user
> such as puppet.  Do not twiddle ownership or permissions back and
> forth.
>
> 3) Find or create an svn resource type to add to Puppet that will
> handle the twiddling for you.
>
> 4) Move all the ownership and permission twiddling into your checkout
> script (i.e. remove the two File resources with which you are
> currently trying to do the twiddling).  That will make the overall
> operation atomic from Puppet''s perspective, which is a good thing.
>
> 5) If you only want to manage your puppetmaster in this particular way
> (which seems possible given the specific resources involved) then it
> may be more reasonable to do it manually.  That will also give you the
> opportunity to temporarily shut down puppetmasterd while you do so, to
> avoid clients getting an inconsistent view of the files if they happen
> to request them while the update is in progress.  You could schedule
> that with cron if you can accommodate puppetmasterd not coming back up
> in the event that the script errors out.
>
> Good luck,
>
> John
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Puppet users - Dec 2010 - Autorequiring and dependency problem

[Puppet Users] Autorequiring and dependency problem

Re: [Puppet Users] Autorequiring and dependency problem

[Puppet Users] Re: Autorequiring and dependency problem

[Puppet Users] Re: Autorequiring and dependency problem