Objects matching the expression 'types'

• #1180 nagios types should be able to generate /template definitions/ in nagios (naginator, nagios, types)
• CompleteResourceExample This document walks through the definition of a very simple resource type and one provider. We'll build the resource up slowly, and the provider along with it. See CreatingCustomTypes Creating Custom Types:trac: and ProviderDevelopment Provider Development:trac: for more information on the individual classes. Resource Creation ----------------- Any reasonable resource needs to be able to be created and destroyed, and resources have to have names, so we'll start with those two features. Puppet's property support has a helper method called ensurable that handles modeling creation and destruction; it creates an ensure property and adds absent and present values for it, which in turn require three methods on the provider, create, destroy, and exists?. Here's the first start to the resource:: Puppet::Type.newtype(:file) do @doc (documentation, example, providers, types)
• CreatingCustomTypes (If this page is a bit... abstract, try PracticalTypes:trac: for a different view of the same information) Organizational Principles ------------------------- When creating a new Puppet type, you will be focusing on two types of classes: The resource type itself, which we normally just call a 'type', and the provider(s) for that type. The resource types provide the model for what you can do: They set the valid parameters, they handle input validation, and they determine what features a provider can or should provide. The providers implement support for that type by translating calls in the resource type to operations on the system. Once you have your code, you have to figure out how to deploy it where necessary. Both your clients and servers will need the code; the clients obviously need it in order to actually use them, but the server needs it in order to validate resource parameters. You can, in theory, put your types in a puppet/type subdirectory of any directory in Ruby's load path, however the best place is Puppet's libdir. The libdir is special because you can use the pluginsync system to copy all of your plugins from the fileserver to all of your clients (and your Puppetmaster, if it's a Puppet-managed machine too). To enable pluginsync, set pluginsync (development, documentation, types)
• PluginsInModules This page describes the deployment of custom facts and types via modules. It is supported in 0.24 onwards and modifies the pluginsync model supported in releases prior to 0.24. It is NOT supported in earlier releases of Puppet but may be present as a patch in some older Debian Puppet packages. Usage ----- Instead of using the existing pluginsync mechanism custom types and facts are now stored in modules. These custom types and facts are then gathered together and distributed via a file mount on your Puppet master called plugins. To enable module distribution you need to make changes on both the Puppet master and the clients. On the Puppet master, if you have an existing plugins section in your fileserver.conf, get rid of the path parameter (if you leave the path parameter in place, then the mount will behave like any other fileserver mount). Move your existing plugins from the directory specified in that path into the modules for which they are relevant. If you do not have any modules defined or the types and facts are not relevant to any particular module you can create a generic module to hold all custom facts and types. It is recommended that you name this module custom. Ruby libraries in your plugins directories behave like Ruby libraries in any other Ruby lib directory, and their paths need to match whatever Ruby would normally look for. For example, Ruby expects Puppet resource types to be in $libdir/puppet/type/$type.rb, so for modules you would put them here:: <MODULEPATH>/<module>/plugins/puppet/type For providers you place them in:: <MODULEPATH>/<module>/plugins/puppet/provider Similarly, Facter facts belong in the facter subdirectory of the library directory:: <MODULEPATH>/<module>/plugins/facter So, if we are using our custom module and our modulepath is /etc/puppet/modules then types and facts would be stored in the following directories:: /etc/puppet/modules/custom/plugins/puppet/type /etc/puppet/modules/custom/plugins/puppet/provider /etc/puppet/modules/custom/plugins/facter For now, continue using factsync to distribute facts. Distributing them works fine with pluginsync, but Facter is not yet smart enough to load them. This will be fixed in the next Facter release. Turn on pluginsync and specify factpath, so that the facts dropped by pluginsync are loaded by Puppet:: [main] pluginsync (custom, facts, modules, plugins, types)
• PracticalTypes So you want to create a custom type. Good for you. There should be more of them in the world. However, it can be really daunting to create a type, as the existing types are mostly very complex, with talk of providers, munging, and all the rest of it. Funnily enough, most of the types we might want to create are a hell of a lot simpler than the pre-existing ones, and don't need the majority of the complexity that Puppet's type model provides. This document is a lighter introduction to writing types than the more official docs. It simplifies the model down to the bare minimum needed to implement a wide range of simple (but still useful) types. Hopefully you can get up to speed with writing simple types, and then move on to more difficult concepts later once you need them. Building a mental model ----------------------- It's important to know roughly how Puppet does what it does with types before writing one, so we'll start with a bit of explanation about how Puppet works with types. There's two important things that Puppet asks each resource during a Puppet run: "Are you up to date?" and "Please modify the system to bring yourself up to date". The work that gets done by your type can be many and varied, but it all must fit into this question / action model. For an example of this, consider the simple task of appending a line to a file if it doesn't already exist. The question "are you up to date?" is handled by just looking through the file to see if the line exists. Modifying the system just involves appending the line to the file. If you can describe what you want to do with your type in these terms, you're a long way towards being able to write your type. Simple Beginnings: Defining the type ------------------------------------ There's a bunch of stuff you have to do to define any type in the Puppet system -- scaffolding, if you like. A simple template looks like this:: module Puppet newtype(:append_if_no_such_line) do end end Here we're defining a type named append_if_no_such_line, which isn't going to do anything. We'll fill in the blanks later. Where should you be putting this code? It's important that the file be named after your type: a type named append_if_no_such_line must be put in a file named append_if_no_such_line.rb. If you put it in any other file, Puppet won't recognise it and your type won't get used (probably resulting in errors in your manifest). What about the directory to put the file into? Puppet will look for types in a puppet/type directory anywhere in the Ruby load path and in the libdir you've defined. (If you don't know where your libdir setting points to, you can run puppetd --genconfig to get all your config variables and see what it's set to). Since you don't want to be copying a type definition file to every machine under Puppet control, you can use pluginsync to get the copying done automatically. Setting that up is beyond the scope of this article; see Creating Custom Types for info on the pluginsync mechanism. Variables: how to know what to do --------------------------------- It would be a very rare type indeed that didn't need to be configured in some way. Puppet's way of defining variables that can be set in the manifest is with "parameters". You define these in your type, and then you can specify values for them in your manifests. Continuing with our append_if_no_such_line example, we have two parameters of interest -- the file we want to mangle, and the line we want to append. So let's define those now:: module Puppet newtype(:append_if_no_such_line) do newparam(:file) newparam(:line) end end Defining parameters is pretty easy, huh? We've missed one thing in our type above, a parameter that every type needs but which we don't think about very often. Any thoughts? It's the parameter which defines the "title" of each individual resource, often called the "name". In theory, you can call this anything you like, but there's complications if you call it anything other than "name", so we'll just call it that and move on:: module Puppet newtype(:append_if_no_such_line) do newparam(:name) newparam(:file) newparam(:line) end end Documentation is Critical ------------------------- I'm going to take a little pause here and talk about documenting your type. It's important to document your type so others can use it. Unfortunately, Puppet uses it's own slightly weird structure for documentation, by setting variables in various places, rather than just using rdoc comments. Oh well. To document the type itself, you need to set the @doc variable at the type level with a documentation string:: module Puppet newtype(:append_if_no_such_line) do @doc (type, types)