[Puppet Users] Re: if( defined( Class["software::mongodb"] ) ) throws an error
Hey Trevor, Thanks for the reply. This thread is way off topic from the original problem which has been resolved. Just to clarify for anyone running into the same problem, the issue was simply the syntax I was using. I was checking if a class was defined like this: defined( Class["class::subclass"] ) The correct syntax is: defined( "class::subclass" ) The documentation is not clear on the proper way to do this. I've filed a bug report with so this should be getting clarified in the documentation. The specific ticket can be viewed here: https://projects.puppetlabs.com/issues/5944 On Jan 20, 7:04 pm, Trevor Vaughan wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > This is probably the case that you don't have this class present in your > autoloader path. > > For some reason, Puppet needs the class to be in the autoloader even if > you don't use it or you run into this exact situation. > > I think there's a bug filed in the Puppet Redmine about it. If there's > not there should be ;-). > > Try just declaring the class somewhere that the autoloader will pick it > up and just not using it. > > Unfortunately, I don't currently know of a way around this. > > Trevor > > On 01/18/2011 05:29 AM, MJ wrote: > > > I'm trying to detect if a class has been defined as is indicated at > >http://docs.puppetlabs.com/references/stable/function.html#defined > > > However, this check always results in the following error: > > err: Could not retrieve catalog from remote server: Error 400 on > > SERVER: Could not find class software::mongodb at /etc/puppet/modules/ > > software/manifests/init.pp:36 on node X..com > > > Line 36 is the "if defined" line which doesn't make any sense as this > > line is supposed to trap that exact condition. Has anyone else run > > into this and / or figured out a way around it? Thanks. > > - -- > Trevor Vaughan > Vice President, Onyx Point, Inc. > email: tvaug...@onyxpoint.com > phone: 410-541-ONYX (6699) > pgp: 0x6C701E94 > > - -- This account not approved for unencrypted sensitive information -- > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > > iQEcBAEBAgAGBQJNOPe1AAoJECNCGV1OLcypvAIH+wQFZ6wWHyLV4QD3TBVxKCwI > GAMbyDASDTz0XW2Br6rl271LGLzoOJAqRxu5oTUWjTKtaSX7xxkjtUcRbGmBU4X8 > 0yePO4fnw0yqwYxjNQ/UPDJxDDeNI9Pg2dtyR7XVxuM/SVKltfgKVbM1qJcSthcK > eku9oI9b4uDE0o6T9hC5mcTHAH7+XKhB8d+lmP8Xn4ZG0bTapV+IOZUTcCuOr3jL > NJ9cKXS/lc2Iy2Z3ToZRiNFHUsXNUbZr98LHmk54xJth/x2QbrmmySf2cv42Wxm6 > hEi4LzOpjLKIQdOn+/S5hQnxD43zNfXJJA6e3kZc0t0BqDc8Dhl0CvjS31UBmqg= > =Mv45 > -END PGP SIGNATURE- > > tvaughan.vcf > < 1KViewDownload -- 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.
[Puppet Users] Re: if( defined( Class["software::mongodb"] ) ) throws an error
> Hum, I get the feeling there is more than just this removal scenario
> that's bugging you. However, there are rather elegant solutions in the
> DSL for that, so I'll elaborate on this and maybe inspire you to some
> other approaches that may help with other problems as well.
You are correct, the removal senario is not the only issue.
Ultimately I would like to roll in service and configuration awareness
so that as long as you know what package you want to install, you can
easily make sure any associated service is running and that you have
put config files is the right place. I'm a long way from that, but
this is just the first step in the journey and I think even by itself
it will prove to be beneficial to the puppet community as a whole.
> First off, don't rely on dynamic scoping (i.e. variables being available
> in included classes) if it's at all possible.
I agree whole heartedly on this. Technically, I'm not relying on
dynamic scoping. If the variables are not available in the included
class, things still work as intended. I'm treating them more as
hints. I actually spent a fair amount of time trying to figure out a
"config file" format that represented the data I am currently pulling
from the included classes, but I've not been able to come up with
anything that represents the complexity and flexability I need without
requiring a minimal programing language and it seems silly to make
someone learn yet another language to do what seems to work quite well
using the puppet DSL. That's not to say there isn't a better way, I
just haven't come up with something better.
>
> What I'd do to make apache2 selectively removable is a subclass:
>
> class apache2 {
> package { "apache2": ... }
>
> class disable inherits apache2 {
> Package["apache2"] { ensure => absent }
> }
>
> }
>
> Nodes then make sure to not have apache installed by including
> apache2::disable.
>
> As for cross-platform, I try to rely on facter to flesh out the minimum
> of required discrepancies. E.g., I have a class for the at daemon that
> runs on SUSE and Debian systems. Here's how I work around a problem with
> the SUSE init script:
>
> package { "at": ensure => installed; }
> if $operatingsystem != "Debian" { #SUSE
> Service { hasstatus => true }
> }
> service { "atd":
> enable => true,
> ensure => running,
> require=> Package["at"],
> }
>
> In more complex scenarios, it may even make sense to specify further
> subclasses for specific platforms, but I try and avoid that. The point
> is that the module emits a platform-independent interface for installing
> and running atd, so platform-specific subclasses actually hurt. The
> facter-based constructs can become quite entangled in places, but
> they're meant to be "internal magic" so that's usually acceptable.
What you point out his is completely true. I will grant that without
a large number of "package config" class, there is not a lot of value
to my 'software' resource. However, as I continue to use it and
create configs that work on multiple platforms, the number of them
will increase and the amount of work others will have to do to write a
module that is "platform agnostic" will reduce. I think the git.pp,
git-core.pp, and git-daemon.pp classes and the way they work together
is a really good example of how this becomes beneficial. When you
start running situations where it takes multiple packages to provide
the same functionality as a single package on another system, things
get hairy. So far it looks like I've been able to move all the
wackiness into the core 'software' resource with minimal work int the
"package config" classes.
Now that I have the 'defined' syntax correct for classes, my
"software" resource will fall back to behaving just like the package
resource. And because it still does use the package resource on the
back end, it can easily play nicely with existing manifests without
requiring any modifications unless the maintainer decides to convert
everything to the 'software' resource.
One of the things I've found frustrating with puppet is that it
doesn't come packaged with any modules. I suspect that's due to the
fact that truly generic yet useful manifests are difficult to come
by. It's my opinion that if we can reduce the complexity of writing
platform agnostic modules without losing flexibility, we will start to
see modules that are reasonable to include with a base puppet install.
There are a few under the hood enhancements I'm going to add to the
current module and the I will start putting together some decent
documentation and will try to include a good "why would I want to use
this" section. I don't know that I've yet been able to properly
explain the benefits I see in this, but hopefully as I put together
the documentation I'll be able to articulate it more clearly.
Your input (and everybody else's) is greatly appreciated.
>
[Puppet Users] Re: if( defined( Class["software::mongodb"] ) ) throws an error
On Jan 19, 12:58 am, Felix Frank
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.
[Puppet Users] Re: if( defined( Class["software::mongodb"] ) ) throws an error
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/manifests/init.pp
I'm absolutely doing some "not so normal" things in this module to
obtain the desired effect. While I liked that idea of loading this
data by including a class, it probably makes more sense to extract all
of the data in my [package_name].pp files into csv files or yaml and
slurp that data in using 'extlookup'. Initially there was more logic
in
[package_name].pp files, but now that they are basically just case
statements setting variables, they don't really need to be classes
anymore. Using 'inline_template' to effectively let me do an
'eval( $software::$name::ensure )' wasn't my first inclination, but at
the time it was what made the most sense.
Thanks for taking the time to respond to my not-so-complete inquiry.
It is much appreciated.
On Jan 18, 11:46 am, Daniel Pittman wrote:
> On Tue, Jan 18, 2011 at 02:29, MJ wrote:
> > I'm trying to detect if a class has been defined as is indicated at
> >http://docs.puppetlabs.com/references/stable/function.html#defined
>
> > However, this check always results in the following error:
> > err: Could not retrieve catalog from remote server: Error 400 on
> > SERVER: Could not find class software::mongodb at /etc/puppet/modules/
> > software/manifests/init.pp:36 on node X..com
>
> > Line 36 is the "if defined" line which doesn't make any sense as this
> > line is supposed to trap that exact condition. Has anyone else run
> > into this and / or figured out a way around it?
>
> It would have been easier to check this if you gave us the fragment of
> code that had the problem, and the puppet version you are using. It
> works for me with 2.6.4-363-g27abd84 and 2.6.4 plain, using this
> manifest:
>
> if defined( Class["software::mongodb"] ) {
> notice("defined")
> } else {
> notice("not defined")
> }
>
> Specifically, I see "not defined" announced as expected. However, be
> aware that the 'defined' function is subtle and strange – it depends
> heavily on the order that your files and classes are parsed in, and
> can behave very unpredictably.
>
> Using it is often a sign that something not-quite-right has happened
> in your code, so it would be interesting to see how you have written
> it; there might be a better way to achieve the same result without the
> problems.
>
> Regards,
> Daniel
> --
> ⎋ Puppet Labs Developer –http://puppetlabs.com
> ✉ Daniel Pittman
> ✆ Contact me via gtalk, email, or phone: +1 (503) 893-2285
> ♲ Made with 100 percent post-consumer electrons
--
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.
[Puppet Users] if( defined( Class["software::mongodb"] ) ) throws an error
I'm trying to detect if a class has been defined as is indicated at http://docs.puppetlabs.com/references/stable/function.html#defined However, this check always results in the following error: err: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find class software::mongodb at /etc/puppet/modules/ software/manifests/init.pp:36 on node X..com Line 36 is the "if defined" line which doesn't make any sense as this line is supposed to trap that exact condition. Has anyone else run into this and / or figured out a way around it? Thanks. -- 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.
