[Puppet Users] Terraform provisioner?
Is anyone working on a Terraform provisioner? Or have one internal that they'd like to open source (If so, am volunteering to make it all nice for the outside world and write you documentation, etc). Cheers James -- * The Art of Monitoring (https://artofmonitoring.com) * The Docker Book (https://dockerbook.com) * The LogStash Book (https://logstashbook.com) * Pro Puppet (http://tinyurl.com/ppuppet2 ) * Pro Linux System Administration (http://tinyurl.com/linuxadmin) * Hardening Linux (http://tinyurl.com/hardeninglinux) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/57FC506D.3030001%40lovedthanlost.net. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Announce: Strings 0.99.0 Released!
Hello, all! Today, we're pleased to announce the release of puppet-strings 0.99.0! Strings is a YARD-based documentation tool for Puppet extensions written in Puppet and Ruby. Given some simple in-code comments containing YARD tags, it will generate consistent HTML or JSON documentation for all of your Puppet 3x/4x API functions, Puppet language functions, Ruby classes, Ruby methods, types, and providers. This release includes a near-complete rewrite of the project, fixing many bugs from previous versions and generally improving the user experience. Note that this release is intended to be the last stop before the strings major version 1.0.0 is released, and nearly all of the functionality of the major release is included. Note also: backwards-incompatible changes have been made to the original JSON schema. *Highlights*: - Both HTML and JSON documentation has been split into sections based on type: Puppet 3x API functions, Puppet 4x API functions, Ruby classes/methods, Puppet language functions, types, and providers. - New --emit-json and --emit-json-stdout command line options for generating JSON documentation. - A brand new JSON schema organized around the new separation of types. - Support for custom functions written in the puppet language. - Support for function overloads via the create_function 4x API. - YARD has been bumped to the latest version, greatly enhancing the look and usability of the HTML output. *Other important notes*: - Markdown is now the default format for parsing in-code docstrings. - The runtime dependency of puppet has been removed in favor of a gem 'requirement' which appears on rubygems.org. This prevents conflicts when installing strings in older versions of Puppet Enterprise. We recommend you install the puppet-strings gem using puppet, as suggested in the README. Never used Strings? Check out the README linked below and give it a try! The CHANGELOG can be found here: https://github.com/puppetlabs/puppet-strings/blob/master/CHANGELOG.md The ruby gem can be found here: https://rubygems.org/gems/puppet-strings Installation and usage instructions can be found here: https://github.com/puppetlabs/puppet-strings/blob/master/README.md To track issues related to this release or report issues, see the PDOC JIRA project: - JIRA Project: https://tickets.puppetlabs.com/browse/PDOC - Fixes for 0.99.0: https://tickets.puppetlabs.com/issues/?filter=22705 - Introduced in 0.99.0: https://tickets.puppetlabs.com/issues/?filter=22706 -- William Hopper Software Engineer -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1126bd37-60e9-476c-ad8a-8d3fe0f227c9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Declare ressources from another stage
On Thursday, October 6, 2016 at 9:03:26 AM UTC-5, Prunk Dump wrote: > > > Can you help me on a more simpler and concrete example ? > > 1) My apt::client class have a defined type : > > Your apt::client class does not *have* such a defined type. Even if the type's definition appears lexically within the class's (which it ought not to do), that does not imply any meaningful ownership or scope. > define apt::client::source > > that allow to add sources to /etc/apt/sources.list.d. As an "apt-get > update" is needed after adding sources, all the resources defined in my > apt::client::source type : > => require Class['apt::client::audit'] (that check if there are not > pending install) > => notify Class['apt::client::update'] (that run apt-get update) > There as no more dependencies. And the two class ( apt::client::audit and > apt::client::update ) are contained in the apt::client class. > > 2) Now I want to build a "wine" class that install wine from "backports". > > => the wine class require that apt is ready to install packages so > naturally wine class need to be run after the apt::client class. > > => But wine also need that the backports sources are added to > sources.list. So in the the wine::install class manifest I declare a > apt::client::source(...backports sources...) that is required by the > Package['wine'] resource. > > 3) Finally I got a dependency cycle : > > apt::client::update => wine::install (because apt need to be ready) > wine::install => apt::client::source(...backports sources...) (because > the resource is declared inside the wine class and required by > Package['wine']) > apt::client::source(...backports sources...) => apt::client::update (as > the source need to be added before apt-get update) > > You can say to me that I can create a specific > apt::client::backports_source class and include it instead of declaring it. > But I have many other modules that need many other specific sources. > > You can say that I can put the apt::client::source(...backports > sources...) in the apt module. But I don't want that this sources be added > on node that don't have wine. > > I there a way to achieve what I want with puppet ? Maybe with class > parameters ? > The cycle you describe occurs because your relationships are too coarse-grained. It's not *all* of class wine::install that must be applied after apt::client::update, nor all of it that must be applied before apt::client::update. You have one part that must be applied after, one part that must be applied before, and maybe a part that can be applied either before or after. To resolve that situation you need to split the class into at least two classes, and apply the relationships with each one that are appropriate for it. John -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/59a532fb-bb93-478b-9a7a-b84b6bdf7648%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]
On Friday, October 7, 2016 at 10:39:58 AM UTC-5, re-g...@wiu.edu wrote: > > Well... The node I have been testing the duplicate declaration on uses a > puppet secondary-master server, as it is on a remote network segment. It > does not connect directly to the puppet primary-master in which The Forman > is running on. > > So I did some work to get this particular "server1" node to use the puppet > primary-master that The Foreman is running on. When I run a puppet update, > it completes without error. When I switch back to the puppet > secondary-master, I get the duplicate class error. > > They are both running puppet 3.8.7-1 on CentOS 6. > The YAML produced by both is exactly 100% the same. So I can assume the > YAML structure is not the issue. > > Would this suggest that the puppet secondary-master server is the issue, > or the client connecting to it is perhaps not always getting what it wants > from the slave? > Remember that the puppet updates will complete correctly for many hours, > then magically change to this error. And vice-versa, be in error for many > hours, and then magically change to completing correctly. Also that > sometime changing configuration in The Forman can trigger the Error to > occur AND other times trigger to Error to stop occurring. > Also note, I only have this problem with the saz-rsyslog module - NEVER > with any other puppet module. > When I remove the saz-rsyslog module, all issues disappear. > I am not prepared to believe that identical implementations of Puppet's catalog builder running on substantially identical platforms with identical inputs behave differently. Since you do see variations in behavior, therefore, I conclude that those differences can be attributed to differences in implementation, platform, or (most likely) inputs. > > I have made sure the puppet modules are 100% in sync between primary and > secondary master server. > And I have restarted the puppet processes on the secondary-master server, > but the error will continue on the nodes. > > Those are good steps. To really troubleshoot this thoroughly, however, I think you'll need to be systematic: capture the ENC output for each catalog request for a given node (or for all nodes), with timestamps and associated success / failure of catalog compilation. Compare the ENC output for successful catalog builds with that for failed builds and look for systematics. Either at the same time or separately, you should look into whether Puppet's environment cache has an impact here. Some of the behaviors you describe make me rather suspicious of this. Supposing that you are using directory environments, you should experiment both with disabling caching altogether (set the environment_timeout configuration option to 0 (its default)) and with caching indefinitely (set environment_timeout to "unlimited"). Note that Puppet recommends against using any other setting for that option. You could also try turning on the ignorecache option at the master. John -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/e6387508-1112-4bc5-bb4d-85bfe7656459%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Issue with module from forge - Duplicate declaration Class[Rsyslog]
On Thursday, October 6, 2016 at 9:04:14 AM UTC-5, re-g...@wiu.edu wrote: > > > I understand the duplicate declaration issue - I have been reading about it > for months trying to figure out this issue that keeps popping up. I am > trying to figure out how it is possible I am getting a duplicate class > declaration on a widely-used and approved module I have no control over > (that no one else has reported any similar issue as mine), when using the > forman to simply provide the values of parameters. > > I don't know how widely-tested that module is, but it absolutely does exhibit what I would consider to be some violations of best practices. As a result, it is more susceptible than most to duplicate declaration issues. Nevertheless, it appears that simple uses of that module (e.g., of its classes, only ::rsyslog is declared directly) and all uses relying exclusively on automated data binding for parameter values should be ok. > Maybe The Foreman is the cause of the ::rsyslog class to be declared more > than once? Might you suggest this possibility? > I *did* suggest that possibility, inasmuch as I suggested that it might be emitting the ENC analog of resource-like class declarations for it. That in itself would not be enough to produce the problem, but it is a likely contributor. I don't see any reason to think that it would emit multiple declarations itself, but it does not need to do, because there are several other classes in the module that explicitly or implicitly declare class ::rsyslog. If any of those is also declared then there is a potential conflict. > But then I think, how would it? And why do I have this issue for hours on > a server, and then at some magic moment the issue just disappears? Why with > two of my servers sitting 1 IP away from each other, one will have this > issue, and the other will not? > I cannot answer that in any detail, but obviously something differs over time and / or between servers. There is an enormous variety of possibilities, both inside Puppet and / or The Foreman and outside. > I consider that The Foreman is causing the problem, but then I should have > the error on all hosts at the same time. > I am by no means certain that the problem is directly related to The Foreman, and in no way am I suggesting that The Foreman is misbehaving. I am, however, suggesting that in some cases The Foreman's ENC output is interacting poorly with the module. That it is possible for that to be the case is a consequence of details of the module implementation. > The only different in the YAML between hosts is the IP addresses... every > other puppet module parameter value is exactly the same. > > That The Foreman is emitting a class declaration with parameters at all is very likely a contributing factor to the problem. Note, however, that it may not be just the parameter values that make a difference. It surely also matters which other classes are declared, and the *order* of the class declarations could also have an impact. Again, however, I see no reason to attribute any of this to a flaw in The Foreman. > The Foreman has parameterized class support. It allows us to manage the > values of the puppet module parameters. > Yes, and when you use that support, and it works exactly as intended, you open yourself up to duplicate class declaration issues. Whether any such issues will actually manifest depends on many factors. > Old Screen Shots with explaination > > http://projects.theforeman.org/projects/foreman/wiki/Parameterized_class_support > > When using the foreman, I am not writing any files, or declaring any > classes. Instead, I manage the values of the puppet module parameters in > the The Foreman WebUI, which is simply logic like 'if this host fact meets > this criteria, then this puppet module parameter is set to this value'. > Even supposing that everything works exactly as designed, you don't need to write any of your own classes to end up with duplicate declaration issues. You do need to feed class parameters to Puppet in some way (any way) other than automated data binding, and you need additional declarations of the same classes, whether implicit or explicit, in other classes you declare. You certainly have the former, and the module you're using provides easy opportunities for the latter. John -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/19e25a91-f516-4368-a15e-3ed924e14832%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: subscribe vs notify
Hi Andrew 'subscribe' is not a type - it's a metaparameter, and it still exists. See: https://docs.puppet.com/puppet/4.7/reference/lang_relationships.html On Monday, 10 October 2016 04:57:42 UTC+2, Andrew wrote: > > > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/9e513f0e-9fcd-4cdd-a363-22a975b5e16c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
