[Puppet Users] Re: Module team update: 2013-07-07 - 2013-07-12
I insist on the question since I've not had answers previously: Any hope the redesign of the PuppetLabs modules will consider the suggested standards discussed here: https://github.com/stdmod/puppet-modules/blob/master/Parameters_List.md ? On Saturday, July 13, 2013 12:24:46 AM UTC+2, Ashley Penney wrote: Hello! Now that we're two weeks in it's time for another update on what's been going on in the module team. We focused on puppetlabs-ntp and puppetlabs-firewall as our two primary modules, but also merged in fixes to passenger, rabbitmq, mysql, apt, and apache. As a result of this work we've released: http://forge.puppetlabs.com/puppetlabs/apache/0.7.0 http://forge.puppetlabs.com/puppetlabs/ntp/1.0.0 http://forge.puppetlabs.com/puppetlabs/firewall/0.4.0 Of these three the apache release is by far the largest. The module was basically rewritten between the older version and this and most users have been using it from git for a while. This is a huge change so I would recommend anyone on 0.6.0 to test carefully before unleashing it in production. The NTP module was also completely rewritten (but is tiny in comparison). There's some work left to do in this to unify the templates but I wanted to get a release out the door today and work on the unification for 2.0.0. The firewall changes are smaller but the regular mix of features and bugfixes. In addition to all these module releases Hunter released http://rubygems.org/gems/rspec-system-serverspec, which is a bridge between the serverspec matchers and rspec-system. I made https://github.com/puppetlabs/puppetlabs-rabbitmq/pull/71 which is an in progress refactor of the installation part of the rabbitmq module. I want to continue overhauling this module completely until it sparkles. Please take a poke in there and comment if you're a rabbitmq user. 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+unsubscr...@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.
Re: [Puppet Users] puppetlabs-ntp template discussion
I've been missing a way to set which server(s) should be preferred. We generally include all our NTP servers in the config but prefer the one that is in the same site as the node in question. So for a machine in site1 it would look like: server ntp.site1.example.com prefer server ntp.site2.example.com server ntp.site3.example.com On 10 July 2013 19:57, Ashley Penney ashley.pen...@puppetlabs.com wrote: Hi guys, As I mentioned in a previous email I've refactored ntp and released a 1.0.0 release candidate. There's one outstanding flaw remaining that's bothering me and I wanted to solicit opinions on the list. We currently maintain a template per distribution that is close to the stock distribution provided ntp configuration. This leads to massive sprawl and means adding a distribution means yet another template. Would users of the ntp module mind if we unified this all into a single template? Obviously we'd have to pick one as the best base template and move over to using it and deal with the fact that your ntp configuration would significantly change. Obviously we'd still be using your custom servers in the template so that bit wouldn't change. We could expand the restrict option to let you pass in more customized options here. What else would people like to be able to tune, change, tinker, trigger, whack, or modify in terms of parameters? If you have a really complex ntp setup then I want to hear from you! The more complex and awkward the better so that we can be sure our module meets your needs. If you've ever refused to use the ntp module as it lacks something you need, now is the time to shout out! 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+unsubscr...@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. -- Erik Dalén -- 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+unsubscr...@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.
Re: [Puppet Users] Re: Module team update: 2013-07-07 - 2013-07-12
On Sat, Jul 13, 2013 at 6:16 AM, Alessandro Franceschi a...@lab42.it wrote: I insist on the question since I've not had answers previously: Any hope the redesign of the PuppetLabs modules will consider the suggested standards discussed here: https://github.com/stdmod/puppet-modules/blob/master/Parameters_List.md ? I know you're finding the lack of answer from us frustrating and I can promise we're not trying to ignore it or trivialize the issue. From our perspective it's just the two of us and we're just trying to find our feet and handle the enormous PR backlog and get the modules into some kind of shape. I'm not against any of those parameter names and I'll accept PRs to deprecate all the existing names and replace them with alternatives but it's just a big chunk of work that we haven't been able to schedule yet. So from my personal point of view I am trying to use those parameter names as much as possible, as well as that general class outline, in the context of transforming existing modules where I can't just start over. We haven't reached the point where we're doing much from scratch so these kinds of design things haven't come up as we're trying to find ways to work within what we got! So there's a totally unofficial answer, but I think hunner is generally on the same page as me. We see the need for a standardized list of parameter names/layout that is recommended, and we're in favor of moving towards it. Alessandro, here's a proposal that might help - https://github.com/puppetlabs/puppet/pull/1718 is a PR about improving the skeleton that module generate creates. It would be awesome to see if we can get electrical and you to work together to put together a skeleton that a/ reflects the class layout in that doc (probably just install,config,service and init as a skeleton) as well as a STANDARDS.md or GUIDELINES.md document that includes all those parameters. That way the information would be right there whenever a user creates a module. It would go a huge way towards getting these adopted I think if you integrated that document directly into the module skeleton. It would make it easy for busy people like me juggling modules to constantly refer to the document as I'd have copies of it all over the place. :) -- 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+unsubscr...@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.
Re: [Puppet Users] puppetlabs-ntp template discussion
On Sat, Jul 13, 2013 at 7:15 AM, Erik Dalén erik.gustav.da...@gmail.comwrote: I've been missing a way to set which server(s) should be preferred. We generally include all our NTP servers in the config but prefer the one that is in the same site as the node in question. So for a machine in site1 it would look like: server ntp.site1.example.com prefer server ntp.site2.example.com server ntp.site3.example.com I'll take a look at this but I have a sneaky suspicion if you just pass in servers = [ 'ntp.site1.example.com prefer', 'ntp.site2.example.com' ] it should magically do the right thing. On monday I'll find that out and make it do the right thing if not. I guess what you're saying is it's a pain to modify the list per site? In that case we can always add a prefer = 'blah' and have that append to the site you pick if that works. I think what I'm saying is here is tell me the API you'd like most for that and we'll do it. :) 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+unsubscr...@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.
[Puppet Users] username/password combo for custom provider (couchbase)
Hi,
I'm trying to program custom type for managing Couchbase buckets.
Problem is that every RW operation to Couchbase cluster (creating,
deleting, resizing bucket) requires admin privileges (username/password).
Do you have any suggestion how should I pass the username/password to
provider? If I make it a param, then every resource of type
'couchbucket' will need to have 'username =' and 'password =' params,
which will (probably) be the same across the board.
Now, to circumvent that repetition, I'm thinking of maybe setting
something like:
Couchbucket {
username = $::couchbase::admin_user,
password = $::couchbase::admin_password,
}
in the '::couchbase' class. Offcourse there will be similar settings for
hostname and port of the couchnode, and probably something like purge =
true.
But still, if someone wants to use the type without including the base
class, this is obviously not a viable option, because he will have to
address the username/password in every couchbucket resource definition.
So, what I am interested in is your opinion about how to proceed with
this one.
--
Jakov Sosic
www.srce.unizg.hr
--
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+unsubscr...@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.
[Puppet Users] Re: ERB Template Newb Question
Could you show the puppet code that sets '$rabbitmq_port' and '$rabbitmq_address' ? I'd recommend dropping a line like this in your template: *NODE_PORT=%= @rabbitmq_port.inspect %* (If you see 'nil', the variable either hasn't been set or has been set to 'undef'). Eric -- 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+unsubscr...@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.
Re: [Puppet Users] The handy Grail of Modules Standards
Hey Al, sorry. I went on holiday and then had to unbury myself. I guess it's time I get my opinion out there. On Mon, Jul 1, 2013 at 2:33 AM, Alessandro Franceschi a...@lab42.it wrote: On Monday, July 1, 2013 5:21:44 AM UTC+2, Ryan Coleman wrote: Hi Al, et al. I apologize for being so late to this party but I'm loving all the conversation around this. I've read through the Google Doc and found lots of cool ideas on class parameter names. Please forgive me though, my product manager wired brain wants to pause at this point and discuss it a bit first before I offer my opinions on the doc. On Tue, Jun 18, 2013 at 11:19 AM, Alessandro Franceschi a...@lab42.itwrote: For me a module is reusable when: 1- It supports many different OS (this is somehow implicit and does not involve naming conventions) 2- It leaves to the user freedom on how to populate and customize the provided configuration files ( I think this is the main point for most reusability cases) 3- It allows the user to manage some behaviours of the module (has a service to be restarted after a file change? Do I want to manage a service status (at runtime or boot) 4- In (somehow extreme) cases it allows the user to customize names of package/services, paths of files and so on 5- It allows seamless addition of custom resources, not managed by the module but related to it 6- It allows the user to decide where to place his data (also this is out of naming convention scope) I'll admit that this is my Forge biased view of things, but I'm working towards modules that are reusable, interoperable and introspectable. It would help me contribute to the discussion if we could hammer out whether we loosely agree on the goal and definitions. I'm already pretty happy with your definition of reusable, but I'll paraphrase. Interoperable - Module A is known to do X, Y Z. - Module B also does X, Y Z and can seamlessly replace module A Agree, and to clarify this even more: If module C needs X which is provided by module A and B: - A and B should be seamless replaceable (as you said) - C should allow easy selection (for the user) of another module that provides X This second point might look redundant, given the first one, but it might be necessary since seamless replacement of modules won't be easy to achieve OR a user may want to use a module that does not support the standard namings. An approach for this second point is the usage of a dependency_class parameter (details in the Google Doc), but I'm sure the collective wisdom here may find a better solution. As in, this is the class you're expected to depend on? That's going to be a little hard to standardize on. Sometimes it's a resource you want, sometimes a fact, maybe it's multiple classes. Also this interoperability should be somehow managed at Modulefile level (and with the puppet module command), so that I can use B even if in the Modulefile is required A. This part, which involves changes in Puppet's code, has to be somehow addressed sooner or later, IMHO. I couldn't agree with you more here. We've got to allow for dependencies to be interchangeable and I think this is most elegantly solved (for the moment) at the module level, with its metadata and Forge ecosystem. That said, I think that's best left to another thread. Reusable - Supports multiple operating systems with a clear standard pattern for adding additional OSes - General capabilities of module can be switched on or off or lightly modified. Ex., don't manage services or override configuration directory. One way that we differ immediately on reusability is that you're pretty detailed on what you should be able to customize, like package and service names. I don't disagree with you but I'm trying to start from a higher level and see whether that's sufficient. I'm not sure what the balance is regarding # of class parameters in use / ease of use. The idea is that you are not forced to provide all the proposed parameters, but if some of the parameters you provide in your module have the same function of the ones proposed, you should call them in the standard way. We might classify parameters in different ways, so that some should be considered somehow recommended (for a standard module), other optional, and other extra or enhanced, because more specific and exotic (thinking about the ones related to monitoring/firewalling, for example). OK. I could get on board with that though I do think that the overall set of parameters needs to be pruned down. Which parameters could be better addressed with module/puppet changes? The dependency_class parameter mentioned above seems like a good example. Introspectable - Code follows style guide and other patterns so that contributions are more easily made and managed. - Puppet should be able to programmatically tell us about defined class parameters and their default values. (yeah, this is theoretical atm)
Re: [Puppet Users] username/password combo for custom provider (couchbase)
Crosspost to puppet-dev to get better feedback.
On Sat, Jul 13, 2013 at 7:54 AM, Jakov Sosic jso...@srce.hr wrote:
I'm trying to program custom type for managing Couchbase buckets.
Problem is that every RW operation to Couchbase cluster (creating,
deleting, resizing bucket) requires admin privileges (username/password).
Do you have any suggestion how should I pass the username/password to
provider? If I make it a param, then every resource of type
'couchbucket' will need to have 'username =' and 'password =' params,
which will (probably) be the same across the board.
There's two options, one to store the username/password on server like
mysql resource (~/my.cnf), or in catalog. I had discussions where some
users prefer the former, but I'm in the later camp.
Now, to circumvent that repetition, I'm thinking of maybe setting
something like:
Couchbucket {
username = $::couchbase::admin_user,
password = $::couchbase::admin_password,
}
in the '::couchbase' class. Offcourse there will be similar settings for
hostname and port of the couchnode, and probably something like purge =
true.
This works, just slightly cumbersome.
But still, if someone wants to use the type without including the base
class, this is obviously not a viable option, because he will have to
address the username/password in every couchbucket resource definition.
So, what I am interested in is your opinion about how to proceed with
this one.
In vmware modules, we use a transport resource to specify connectivity.
https://github.com/vmware/vmware-vcsa/blob/master/manifests/init.pp#L44-L51
Right now, transport is a resource and metaparameter, but I think there's
some value perhaps to turn it back to a regular parameter so we can specify
defaults.
Puppet::Type.newtype(:couchbucket) do
...
newparam(:transport) do
defaultto 'couch'
end
end
This should allow a one time specification of username password for all
resources:
transport { 'couch'
username = ...
password = ...,
}
couchbucket { 'a':
#transport = 'couch' implied
}
You can find examples in the vmware module how we search the catalog to
find the transport data to initialize and reuse connection.
I've intended to convert transport to a stand alone module and support the
following usage:
1. simple store for username/password (for your exact usage).
2. transport ssh.
3. transport rest.
4. transport soap.
Maybe that would be of interest? I have some other ideas about how to take
advantage of the catalog as data, instead of just resource, but that's
probably going to deviate from this topic.
Thanks,
Nan
--
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+unsubscr...@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.
Re: [Puppet Users] where do I configure 'max pool size'?
On 13 July 2013 16:18, Steve Wray stevedw...@gmail.com wrote: Getting this error; The max pool size is currently 5; consider increasing it using MySQL. Surprisingly, I haven't been able to find exactly where I make the configuration change that Puppet suggests. Any clues? Just add/change the following line in /etc/my.cnf: max_connections = x Where x is however many clients you think will be connecting simultaneously + some room for growth; then restart MySQL. Regards, Matt. -- 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+unsubscr...@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.
Re: [Puppet Users] where do I configure 'max pool size'?
On 7/13/2013 8:18 AM, Steve Wray wrote: Getting this error; The max pool size is currently 5; consider increasing it using MySQL. Surprisingly, I haven't been able to find exactly where I make the configuration change that Puppet suggests. Any clues? Where is the error coming from? Also paste the full text of the error. Not nearly enough information here to even suggest what to do next. Ramin -- 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+unsubscr...@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.
Re: [Puppet Users] Re: Module team update: 2013-07-07 - 2013-07-12
On Saturday, July 13, 2013 2:47:36 PM UTC+2, Ashley Penney wrote: On Sat, Jul 13, 2013 at 6:16 AM, Alessandro Franceschi a...@lab42.itjavascript: wrote: I insist on the question since I've not had answers previously: Any hope the redesign of the PuppetLabs modules will consider the suggested standards discussed here: https://github.com/stdmod/puppet-modules/blob/master/Parameters_List.md ? I know you're finding the lack of answer from us frustrating and I can promise we're not trying to ignore it or trivialize the issue. From our perspective it's just the two of us and we're just trying to find our feet and handle the enormous PR backlog and get the modules into some kind of shape. I'm not against any of those parameter names and I'll accept PRs to deprecate all the existing names and replace them with alternatives but it's just a big chunk of work that we haven't been able to schedule yet. So from my personal point of view I am trying to use those parameter names as much as possible, as well as that general class outline, in the context of transforming existing modules where I can't just start over. We haven't reached the point where we're doing much from scratch so these kinds of design things haven't come up as we're trying to find ways to work within what we got! So there's a totally unofficial answer, but I think hunner is generally on the same page as me. We see the need for a standardized list of parameter names/layout that is recommended, and we're in favor of moving towards it. Alessandro, here's a proposal that might help - https://github.com/puppetlabs/puppet/pull/1718 is a PR about improving the skeleton that module generate creates. It would be awesome to see if we can get electrical and you to work together to put together a skeleton that a/ reflects the class layout in that doc (probably just install,config,service and init as a skeleton) as well as a STANDARDS.md or GUIDELINES.md document that includes all those parameters. That way the information would be right there whenever a user creates a module. Wow, that's what I call a direct approach, pushing a PR directly on puppet code to set standards de facto... wonder what some persons on this list would say about that (John?). I still think that trying to find a shared agreement on naming standards is a step to do before pushing the whole default layout of puppet module generate. Anyway I'll gladly accept your invitation to prepare a STANDARDS.md and a module skeleton PR , but, really , I think some (not so many actually) naming patterns still need discussion (package or package_name?) as in some cases I've deliberately introduced them (dependency_class? options_hash? user_class? install_*? monitor_* ? firewall_*?... ) and even if they make a lot of sense for me it might not be the same for others. It would go a huge way towards getting these adopted I think if you integrated that document directly into the module skeleton. It would make it easy for busy people like me juggling modules to constantly refer to the document as I'd have copies of it all over the place. :) Any place suggested by PuppetLabs on where to define modules standards is ok for me. If the discussion can be done directly on the relevant PR, it's ok for me too. Thank you for the reply, Al -- 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+unsubscr...@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.
Re: [Puppet-dev] Re: [Puppet Users] Re: Module team update: 2013-07-07 - 2013-07-12
On Sat, Jul 13, 2013 at 11:26 AM, Alessandro Franceschi a...@lab42.it wrote: Any place suggested by PuppetLabs on where to define modules standards is ok for me. If the discussion can be done directly on the relevant PR, it's ok for me too. Hi Al, I agree that the pattern itself needs more collaboration before it starts getting applied to Puppet Labs modules. That said, you've got a more appropriate thread going for that discussion already (on Puppet-Users) and I look forward to continuing it there. -- Ryan Coleman | Modules Forge | ryanycoleman on twitter #puppet IRC -- 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+unsubscr...@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.
Re: [Puppet Users] username/password combo for custom provider (couchbase)
On 07/13/2013 06:43 PM, Nan Liu wrote:
There's two options, one to store the username/password on server like
mysql resource (~/my.cnf), or in catalog. I had discussions where some
users prefer the former, but I'm in the later camp.
First approach is OK, if the client program supports dot-conf file with
supplied password. But 'couchbase-cli' doesn't. So I'm stuck with the
former anyway.
This works, just slightly cumbersome.
Actually I've just found that I have trouble getting it to work :(
This code is generating errors:
Couchbucket {
admin_user = 'Administrator',
admin_password = 'secret',
}
couchbucket { 'testbucket':
ensure = present,
}
Error: Could not set 'present' on ensure: can't convert nil into String
at 75:/etc/puppet/modules/system/manifests/autoload/nodes/server.pp
Error: Could not set 'present' on ensure: can't convert nil into String
at 75:/etc/puppet/modules/system/manifests/autoload/nodes/server.pp
...
And this code works as expected:
couchbucket { 'testbucket':
ensure = present,
admin_user = 'Administrator',
admin_password = 'secret',
}
So I'm buffled why is that...
In vmware modules, we use a transport resource to specify connectivity.
https://github.com/vmware/vmware-vcsa/blob/master/manifests/init.pp#L44-L51
Right now, transport is a resource and metaparameter, but I think
there's some value perhaps to turn it back to a regular parameter so we
can specify defaults.
Puppet::Type.newtype(:couchbucket) do
...
newparam(:transport) do
defaultto 'couch'
end
end
This should allow a one time specification of username password for all
resources:
transport { 'couch'
username = ...
password = ...,
}
couchbucket { 'a':
#transport = 'couch' implied
}
This seems nice.
You can find examples in the vmware module how we search the catalog to
find the transport data to initialize and reuse connection.
I've intended to convert transport to a stand alone module and support
the following usage:
1. simple store for username/password (for your exact usage).
2. transport ssh.
3. transport rest.
4. transport soap.
Maybe that would be of interest? I have some other ideas about how to
take advantage of the catalog as data, instead of just resource, but
that's probably going to deviate from this topic.
This would be great! It would certainly avoid collisions... Eg. two
different modules (couchbase and vmware for example) both bringing
'transport' resource with them...
It would be a good idea to merge transport into stdlib.
--
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+unsubscr...@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.
Re: [Puppet Users] Packages on fedora19
Fedora 19 is now up on yum.puppetlabs.com. As a word of caution, this is the first distro to adopt Ruby 2.0, so there could be some bugs in a few spots. Please file if you run into them. http://projects.puppetlabs.com/projects/puppet-community-pkg-repo/issues/new stahnma -- 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+unsubscr...@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.
Re: [Puppet Users] Re: Yum.puppetlabs.com: Fedora 19
Fedora 19 is now up on yum.puppetlabs.com. As a word of caution, this is the first distro to adopt Ruby 2.0, so there could be some bugs in a few spots. Please file if you run into them. http://projects.puppetlabs.com/projects/puppet-community-pkg-repo/issues/new stahnma -- 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+unsubscr...@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.
[Puppet Users] Accessing methods of parent provider
I'm taking some time to refactor a custom provider. I'm trying to move common code into a parent provider so that it can be shared among all custom resource providers in the puppet module. While verifying I can call methods in the parent provider I get the following error: Error: Could not prefetch jboss7_deployment provider 'jboss7': undefined method `echo' for Puppet::Type::Jboss7_deployment::ProviderJboss7:Class Here are the relevant snippets of code class Puppet::Provider::Jboss7 Puppet::Provider def echo(arg) info arg end end require 'puppet/provider/jboss7' Puppet::Type.type(:jboss7_deployment).provide(:jboss7, :parent = Puppet::Provider::Jboss7) do echo hello world ... end I modeled this code after the puppetlabs F5 code on the forge. https://github.com/puppetlabs/puppetlabs-f5 I am running puppet version 3.0.0. Any thoughts on why the jboss7_deployment resource provider code cannot access the echo method of the parent provider? -- 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+unsubscr...@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.
Re: [Puppet Users] where do I configure 'max pool size'?
Jul 14 02:36:51 puppet puppet-master[9566]: could not obtain a database connection within 5 seconds. The max pool size is currently 5; consider increasing it. Jul 14 02:37:14 puppet-master[9566]: last message repeated 12 times MySQL is configured for 300 connections. I have 72 hosts managed with Puppet. I don't think the error message is about the MySQL configuration, I think theres an undocumented Puppet configuration. On Sunday, 14 July 2013 01:26:48 UTC+8, Ramin K wrote: On 7/13/2013 8:18 AM, Steve Wray wrote: Getting this error; The max pool size is currently 5; consider increasing it using MySQL. Surprisingly, I haven't been able to find exactly where I make the configuration change that Puppet suggests. Any clues? Where is the error coming from? Also paste the full text of the error. Not nearly enough information here to even suggest what to do next. Ramin -- 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+unsubscr...@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.
Re: [Puppet Users] where do I configure 'max pool size'?
What you're running into is the default value of the Mysql connection pool that is set within the gem Activerecord. You can use dbconnections = 10 to increase it. However it appears you're using the webrick Puppet master so it seems a bit strange that a single thread can use all five connections. Which version of the Activerecord gem or package do you have installed? Also which versions of Puppet and your distro? There are known problems with versions less than 2.3.5 of Activerecord. Ramin On 7/13/2013 7:53 PM, Steve Wray wrote: Jul 14 02:36:51 puppet puppet-master[9566]: could not obtain a database connection within 5 seconds. The max pool size is currently 5; consider increasing it. Jul 14 02:37:14 puppet-master[9566]: last message repeated 12 times MySQL is configured for 300 connections. I have 72 hosts managed with Puppet. I don't think the error message is about the MySQL configuration, I think theres an undocumented Puppet configuration. On Sunday, 14 July 2013 01:26:48 UTC+8, Ramin K wrote: On 7/13/2013 8:18 AM, Steve Wray wrote: Getting this error; The max pool size is currently 5; consider increasing it using MySQL. Surprisingly, I haven't been able to find exactly where I make the configuration change that Puppet suggests. Any clues? Where is the error coming from? Also paste the full text of the error. Not nearly enough information here to even suggest what to do next. Ramin -- 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+unsubscr...@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.
