On Jan 19, 12:58 am, Felix Frank <felix.fr...@alumni.tu-berlin.de>
wrote:
> On 01/19/2011 12:39 AM, MJ wrote:
>
> > I'm suspect it is one of the "subtle and strange" behavoir.  I suppose
> > I should have just posted a link to the code in git hub.  I guess I
> > was expecting that this would be something that was going to jump out
> > as something obvious.  My apologies for not doing so.  Here is the
> > link:
>
> >https://github.com/therevmj/puppet-module-software/blob/master/manife...
>
> Interesting construct. Why do you need to go so meta? Usually, instead
> of building a framework for packages/services/... that you specify in
> some external scheme that you make up, you just write a classes for each
> such set in puppet DSL in the first place. Not much more work and much
> less of a hassle I'd assume.

I've written up a bit about why I'm writting this module at
https://github.com/therevmj/puppet-module-software/wiki
To ballpark it fairly quickly, having a common namespace for packages
regardless of you platform make writing other modules that are cross
platform compatible easier and more readable, and require less code
duplication.  This comes into play even more when you have to deal
with multiple providers on a single platform.  The amount of code you
end up writing starts ballooning.

Consider that you have written and apache2 module which installs the
correct package and are including it in a manifest with:
    include apache2

What happens when you want to remove this package?  You might just
rework the apache to module to remove ensure that it removes the
packages.  But if you are using it somewhere else, you can't do this.
You could create a separate class that removes apache, but that will
result in a lot of duplicated code.  Maybe this will work:

    $apache_ensure = "absent"
    include apache2

but you are stuck writing bits of code determine if you should install
or remove that package and you are duplicating that code in each of
your modules.

Ultimately, this seems to me a good way to consilidate the complexity
of dealing with cross platform compatibility issues and enabling
others to focus on the more basic bits of what software needs to be
installed rather than how to do it and what is the package name.  It's
possible I'm overthinking things, but it has made my other modules
much more straight forward.

>
> But I digress. Concerning your specific problem:
>
> First thing, I guess there's a misunderstanding on your part as to how
> defined() is supposed to check for the presence of class definitions.
> That's actually a documentation bug you'd like to file, actually.
> Observe the following snippet:
>
> class defined_class { }
>
> if defined(defined_class) {
>         notify { "Works without Class[] syntax": }
>
> }
>
> if defined(Class["defined_class"]) {
>         notify { "Works WITH Class[] syntax": }
>
> }
>
> Yields "Works without Class[] syntax" in 2.6.2.
>
> Now it would have been my guess that variables (parameter values even)
> in the argument to defined() might be a problem too, but even this:
> class defined_class_a { }
>
> define class_checker() {
>         if defined("defined_class_$name") {
>                 notify { "Class $name is defined": }
>         }
>
> }
>
> class_checker { [ "a", "b" ]: }
>
> "correctly" yields "Class a is defined".
> So you may get away with fixing your syntax.
>
> You should really file that documentation bug ;-)
>

I've file a bug report on this (and one about the fact that the
documented 'feedback' tab doesn't exist).

> Also, if you share more about what you want to achieve with this,
> somebody may be able to recommend a more...let's say "straight forward"
> solution :-)

Hopefully my description above conveys the intent of what I am trying
to achieve.  I'm always open to other ideas.  Thanks for your help!

>
> Cheers,
> Felix

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Reply via email to