Puppet users - Jun 2013 - How to make a package dependant on a class for the repository.

Greetings!

tl;dr Why doesn''t require=>Class work?

I have a module I built that I creatively called "repos". This does a 
number of things for me:
* I have many systems on different networks. Depending on the network 
depends on which repository the servers get their packages from.
* I have many OS''s (RHEL, Scientific, CentOS, SuSE) and several
different
releases of those OS''s (ex: RHEL6 vs RHEL5).
* Some systems get repositories that others don''t (ex: VMware guests
get
the ESXi guest tools repo).
* We roll our own packages for some software; only systems of a certain 
type get these repos.
* ect.

This class does a wonderful job for me. I barely have to do anything in the 
node definition other than "class { ''repos'': } " and
it just figures out
which systems get what repo''s based on facter and various parameters
(like
current network IP). 

Here is the problem though.
package {["htop":ensure=>installed, }

Chances are *really* good that on first runs when the repo hasn''t yet
been
created, what will happen is:
* Error: can''t find htop.
* Installing EPEL
*Done!

Well that isn''t what I want, obviously. Thus I tried:
package
{["htop":ensure=>installed,require=>Class[''repos''],}

Still the same result as before. It never fully configures the repo before 
trying to install. Then I tried:
package
{["htop":ensure=>installed,require=>Yumrepo[''EPEL''],}

It works!! Hooray! And then I hit a failure point. This next statement 
works for Scientific Linux but fails for CentOS6 because a CentOS system 
won''t have the SL6 repo!
package
{["tuned":ensure=>installed,require=>Yumrepo[''SL6''],}

I have come up with two "solutions".
1) Change all the repos to use generic names like "Base" and
"Security".
While it is a big bandaid, it doesn''t really fix the problem as there
is
still potential for packages to conflict.

2) Find out why "require=>Class[''repos'']"
doesn''t work and fix it. This
would solve all my problems if the repos were run and configured properly 
before packages were installed. The only "problem" would then be to
make
sure I am not trying to install a package that legitimately doesn''t
exist
in the repos (like tuned on a CentOS 5 box) but that would fall squarely 
into a PEBKAC and there is only so much I can script to catch those. :-)

Can anyone help me with this please? Any ideas on how I can fix this?

Thanks!

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Does your repos class have a bunch of classes included? If so, those are 
not caught by the require and you need to use the anchor pattern:

http://projects.puppetlabs.com/projects/puppet/wiki/Anchor_Pattern

The ordering (no matter how you do it) only orders the *resources* in that 
class. Not the resources in classes that are *included* in your repos class.

On Wednesday, June 19, 2013 6:00:03 PM UTC-6, Stack Kororā
wrote:
>
> Greetings!
>
> tl;dr Why doesn''t require=>Class work?
>
> I have a module I built that I creatively called "repos". This
does a
> number of things for me:
> * I have many systems on different networks. Depending on the network 
> depends on which repository the servers get their packages from.
> * I have many OS''s (RHEL, Scientific, CentOS, SuSE) and several
different
> releases of those OS''s (ex: RHEL6 vs RHEL5).
> * Some systems get repositories that others don''t (ex: VMware
guests get
> the ESXi guest tools repo).
> * We roll our own packages for some software; only systems of a certain 
> type get these repos.
> * ect.
>
> This class does a wonderful job for me. I barely have to do anything in 
> the node definition other than "class { ''repos'': }
" and it just figures
> out which systems get what repo''s based on facter and various
parameters
> (like current network IP). 
>
> Here is the problem though.
> package {["htop":ensure=>installed, }
>
> Chances are *really* good that on first runs when the repo hasn''t
yet been
> created, what will happen is:
> * Error: can''t find htop.
> * Installing EPEL
> *Done!
>
> Well that isn''t what I want, obviously. Thus I tried:
> package
{["htop":ensure=>installed,require=>Class[''repos''],}
>
> Still the same result as before. It never fully configures the repo before 
> trying to install. Then I tried:
> package
{["htop":ensure=>installed,require=>Yumrepo[''EPEL''],}
>
> It works!! Hooray! And then I hit a failure point. This next statement 
> works for Scientific Linux but fails for CentOS6 because a CentOS system 
> won''t have the SL6 repo!
> package
{["tuned":ensure=>installed,require=>Yumrepo[''SL6''],}
>
> I have come up with two "solutions".
> 1) Change all the repos to use generic names like "Base" and
"Security".
> While it is a big bandaid, it doesn''t really fix the problem as
there is
> still potential for packages to conflict.
>
> 2) Find out why "require=>Class[''repos'']"
doesn''t work and fix it. This
> would solve all my problems if the repos were run and configured properly 
> before packages were installed. The only "problem" would then be
to make
> sure I am not trying to install a package that legitimately
doesn''t exist
> in the repos (like tuned on a CentOS 5 box) but that would fall squarely 
> into a PEBKAC and there is only so much I can script to catch those. :-)
>
> Can anyone help me with this please? Any ideas on how I can fix this?
>
> Thanks!
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Thank you very much Joe. I think this exactly the path that I need but I am 
having trouble with it.

As I said, I have multiple systems that this repo class watches over. Thus, 
for one of several instances, I have things like:

if $osfamily == ''RedHat'' {
    class {''repos::epel'': }
}

The sub-class epel.pp file configures the EPEL repository for the RHEL, 
Scientific, CentOS, Fedora, ect. However, trying to anchor that caused a 
bunch of odd errors (it is entirely possible I didn''t do it right). 

I also have the main configuration in a large case statement that manages 
the main configuration in sub-classes for all operating systems (thus only 
some sub-classes are ever called). This too is causing me some issues. 

I think it is because I don''t fully understand how the anchor is
supposed
to work and the examples listed are a bit simplistic with both a require 
and a notify. But what if I need it to require only if it matches certain 
parameters?

I poked around in a few other modules seeing if I could find more examples, 
but came up empty.

Does anyone know where I can view more examples/code for some guidance?

Thanks!

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Hi Stack,

here''s an example:
https://github.com/wolfspyre/puppet-mysqlx/blob/master/manifests/v55.pp

in this class I create a pair of bookend anchors, and then shove a yumrepo,
and a file resource between them.


Your other classes/resources can then declare a relationship to the end
anchor to establish the relationship.

some gotchas:

- Make sure to include the class declaring the anchor into the class which
has the dependency.
- Remember that you''ve just permanently established a relationship
between
these two classes. This is important to know, and can take you in a
direction that leads to complications down the road.

- It is common to have specific software classes depend on your base-type
''i set up my package repositories, and some other core things that will
happen most everywhere'' resources. The caveat here is that modules you
share with the world will NOT have that base class, and as such may have
dependency issues.

- Use the anchor pattern as sparingly as possible. Consider having to use
it like having to resort to an exec. It is occasionally the right tool for
the job, but not usually.

Hope that helps.




On Wed, Jun 26, 2013 at 7:38 PM, Stack Kororā <i.am.stack@gmail.com>
wrote:
> Thank you very much Joe. I think this exactly the path that I need but I
> am having trouble with it.
>
> As I said, I have multiple systems that this repo class watches over.
> Thus, for one of several instances, I have things like:
>
> if $osfamily == ''RedHat'' {
>     class {''repos::epel'': }
> }
>
> The sub-class epel.pp file configures the EPEL repository for the RHEL,
> Scientific, CentOS, Fedora, ect. However, trying to anchor that caused a
> bunch of odd errors (it is entirely possible I didn''t do it
right).
>
> I also have the main configuration in a large case statement that manages
> the main configuration in sub-classes for all operating systems (thus only
> some sub-classes are ever called). This too is causing me some issues.
>
> I think it is because I don''t fully understand how the anchor is
supposed
> to work and the examples listed are a bit simplistic with both a require
> and a notify. But what if I need it to require only if it matches certain
> parameters?
>
> I poked around in a few other modules seeing if I could find more
> examples, but came up empty.
>
> Does anyone know where I can view more examples/code for some guidance?
>
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscribe@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Thanks for the quick reply! And the example!  Let me review this and try it 
out. I will post back if I run into any issues.

Thanks again!

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Just wanted to say "Thanks!" again. The example helped out quite a bit
and
I was able to get it functioning the way I wanted it to (at least so far! 
:).

Thanks!


-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

A way to work around your problem may be to use stages:

class { repos: stage => first } #you may define stages before

So all repositories will be available before the first packet will be 
installed.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.