Objects matching the expression 'development'

• AutoloadingModules (autoload, classes, development)
• BetterDebugging (development, documentation, planned)
• CfengineVsPuppet .. contents:: Cfengine_ is currently the most widely deployed configuration management tool. In many ways, Puppet_ can be thought of as a next-generation version of cfengine, in that many of puppet's design goals are specifically derived from experience with cfengine and are meant to overcome many of cfengine's weaknesses. Puppet has significant differences from cfengine and is not just a direct descendent, but this document focuses on their direct correlations. This document summarizes the primary advances that Puppet makes over cfengine's current state. An Open Development Community ----------------------------- While Puppet's technical innovations are clearly important to its success, one of the biggest differences is non-technical: The development community around Puppet is very open and is predicated on the belief that everyone should be able to contribute ideas and code to the project. Commit access is given pretty easily, and we do everything we can to encourage contributions of various kinds. We know that we don't have all of truth, and we're more interested in a great tool than in being right. Cross-Platform Support ---------------------- Puppet was developed with a strong focus on cross-platform support, because most organizations have to deal with this problem but also because otherwise solutions cannot easily be shared among organizations. Puppet's configuration language and functional back-end are the centers of its multiple platform support. A Resource Abstraction Layer Cfengine is a great way to scale common administrative practices -- you can move from using SSH and a for loop to using Cfengine pretty smoothly. However, there is just as much complexity present in either form. You still have to handle file contents, and you still have to manage operating system differences yourself -- you have to know whether it's useradd or adduser, whether it's init or Sun's SMF, and what the format of the filesystem tab is. One of Puppet's primary innovations is a resource abstraction layer, so that you do not have to know those details. You can speak in terms of resources like users, services, or filesystems, and Puppet will translate them to the appropriate commands on each system. Puppet administrators are free to focus on the complexity of their configurations, rather than being forced to also handle that complexity plus the complexity of the differences between the operating systems. Puppet's development was heavily influenced by the many external modules that Luke Kanies wrote for cfengine, each module managing a separate resource like users, packages, or cron jobs, and one of Puppet's primary goals was to be able to make it easy to expand the number of resource types it can manage. Configuration Language Cfengine makes it surprisingly difficult to provide support for multiple architectures because of how low-level it is. All path variance (e.g., /usr/sbin/sshd vs. /usr/local/sbin/sshd) must be handled manually and often in multiple places (e.g., both starting a service and restarting it). Puppet provides a notion of a title (e.g., "sshd") and a name (which might be "sshd" or "openssh") for any resource, allowing administrators to pick a single title for all resources yet use the name as necessary for functionality. Dependency resolution can use either, making resource relationships simple. For instance, here is how one might support ssh on multiple platforms in Puppet:: class ssh { file { sshdconfig: path (cfengine, comparison, development, features)
• CodeNames Puppet code names (development, documentation, download, package, planned, puppet)
• ConfigurationVersion (development, documentation, planned)
• ConvertFromXmlrpcToRest * Use REST for all communication, instead of XMLRPC, to eliminate the encoding/escaping overhead of XMLRPC and simplify the process of integrating with other services * Retain the ability for a given network service to be used locally or remotely * Simplify creating new services and new termini for those services. Secondary Goals --------------- * Allow direct file serving by the external web servers, rather than forcing Puppet's server to handle all files (e.g., when using Mongrel behind Apache, we should be able to allow Apache to serve the files, rather than sending those requests to Mongrel) Terminology (development, documentation, inprogress, rest, xmlrpc)
• CreatingCustomTypes (If this page is a bit... abstract, try PracticalTypes:trac: for a different view of the same information) Organizational Principles ------------------------- .. image:: http://reductivelabs.com/images/ResourceTypesProviders.png 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. Deploying Code -------------- 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)
• DeveloperRepositories As Puppet moves to the Git_ distributed source code management system, it will become more important for developers to track the public repositories of other developers on the project. Patches will be pushed and pulled amongst this distributed network of source repositories. You can find some information about the development lifecycle and ticket triage on the Puppet Development Lifecycle_ wiki page. During the course of development you will likely want to run against HEAD or one of the current branches. Information can be found at the Running against Git_ wiki page. GIT Repositories ---------------- Puppet 0.24.x Stable Branch The current primary 0.24.x repository is based at Git Hub?. This is the current "stable" branch and generally works but use it in production at your own risk. :: git clone git://reductivelabs.com/puppet git pull origin Once you have cloned the repository you can also track specific branches, for example the 0.24.x development branch using the command. :: git branch --track 0.24.x origin/0.24.x This will add a new branch called 0.24.x based on the 0.24.x branch on the stable Puppet primary repository. Puppet Master Site This is the officially published master repository. This is the current "development" branch of Puppet and is not recommended for production use. :: git clone git://reductivelabs.com/puppet git pull origin Luke Kanies ' Note, this is Luke's personal development repository for collaboration with other developers. It is not the official publication listed above. If you'd like to track Luke's development work, this is the place to do it. :: git remote add luke git://github.com/lak/puppet.git Jeff Mc Cune? ' :: git remote add mccune http://northstarlabs.net/git/puppet git remote add mccune-math http://www.math.ohio-state.edu/~mccune/git/puppet.git Web Interface at: http://northstarlabs.net/cgi-bin/gitweb.cgi?p (community, development, git, reference)
• DevelopmentKeywords Tickets related to relevant milestones (development, process, query)
• DevelopmentLifecycle The Puppet Development Life Cycle (buildbot, cycle, development, git, lifecycle, puppet, repository, tickets)
• ExternalNodeClassification (development, documentation, planned, specd)
• ImprovedResourceIdentification Puppet currently uses what is known as the *namevar* to uniquely identify resources, so you don't try to manage twice the same resource in the same manifest. For example, in the case of files, the whole path of the file acts as the namevar, so if you include two file resources with the same path in a manifest puppet will abort showing an error. This is not enough, as in certain cases the namevar parameter doesn't uniquely identify a resource. For example, in Gentoo you may have two different packages with the same name under different categories (dev-java/ant and app-vim/ant or app-admin/sudo and app-vim/sudo, to name a few), so you wouldn't be able to install both those packages with puppet, as it would think they are the same one. Proposed solution (development, identification, resource)
• LanguageEvolution This page is meant as a clearinghouse for discussion of the ongoing evolution of the Puppet language. When necessary, this page will describe how these language changes will be implemented through to the client-side RAL, but generally they will focus on the parser. Accepted Changes (development, language)
• LateBindingDefinitionNames (development, documentation, planned)
• NetworkReference (development, documentation, reference)
• NetworkedClasses This is the certificate authority. The current code accepts a certificate request and returns a signed certificate, so following the REST model we'd need to serve those classes separately. The certificates also require, at least, a private key, which needs to be stored separately. You can look in lib/puppet/sslcertificates/support.rb for a good picture of what needs to be managed. This module contains code for loading, generating, and storing all of the certificate-related objects. Note that a ca cert is a normal cert but with a different path; we don't have a good way to handle this right now, so it might just be a one-off. filebucket (development, docs, documentation)
• ProviderDevelopment .. contents:: The core of Puppet's cross-platform support is via Resource Providers, which are essentially back-ends that implement support for a specific implementation of a given resource type. For instance, there are more than 20 package providers, including providers for package formats like dpkg and rpm along with high-level package managers like apt and yum. A provider's main job is to wrap client-side tools, usually by just calling out to those tools with the right information. Not all resource types have or need providers, but any resource type concerned about portability will likely need them. We will use the apt and dpkg package providers as examples throughout this document, and the examples used are current as of 0.23.0. Declaration -------------------- Providers are always associated with a single resource type, so they are created by calling the provide class method on that resource type. When declarating a provider, you can specify a parent class -- for instance, all package providers have a common parent class:: Puppet::Type.type(:package).provide :dpkg, :parent (development, documentation, providers)
• PuppetInternals (development, documentation)
• PuppetReporting The current state of reporting is clearly not what people would like. This document attempts to describe where Puppet is in terms of reporting and where we would like it to be. Definitions (development, reporting)
• PuppetVersioning Major ----- Any revision which: * adds major functionality Minor ----- Any revision which: * adds minor functionality evident to the user * adds major functionality not evident to the user Release ------- Any revision which: * adds/removes/modifies parameters * deprecates parameters or syntax, or * changes file formats Build ----- Every change committed to Git has a unique ID. Scheme B: MAJOR.MINOR.RELEASE (0.22.4) (development, puppet, version, versioning)
• PurgingResources (development, documentation, planned)
• RelationshipSyntax (development, docs, idea)
• Reports Reports (development, process, query, report)
• ResourceStateMachines (development, specification)
• RoadMap This document describes the planned road map for Puppet's development. Even having a roadmap is relatively new to Puppet, so we have not yet had time to establish how the roadmap will change over time. This document will be maintained and be as correct as possible at all times, but ping Luke or James if it seems out of date. The Purpose of This Document ---------------------------- Like most roadmaps, this document serves both the development and user community. It gives developers an idea of when they're expected to have a given set of work done, and it gives users an idea of when to expect a given set of functionality and when to expect existing functionality to change or go away. Planned Releases ---------------- * 0.24.7_: **This is the last stable release in the 0.24.x line.** * 0.25_: This release will be the first release from the master branch, and is planned for the end of the year. Its primary changes will be all of the plumbing to support REST, plus converting, at a minimum, file serving and catalog retrieval to using REST. * 0.26_: This release will convert any remaining XMLRPC network APIs to REST, and will be the last release before 1.0. It should be out in the second quarter of 2009. It will also allow multiple primary keys for resources. * 1.0_: This release stabilizes the network API: According to the plan, projects developed against its API should work going forward. Beyond those short-term releases, we've got a basic plan for forthcoming releases. At this point, the only bullet points in the later releases are related to refactoring, but we'll be adding features as we come up with plans for them. 2.0 +++ * Refactor of the transactional system. The primary goal here is to remove all of the ugly code around the transactions and RAL. 3.0 +++ * Refactor the RAL. After this release, any custom types and providers will work going forward. Any custom types and providers written before this release are considered to be against an unstable API, and while every attempt at backward compatibility will be made, it cannot be guaranteed. .. _0.24.7: http://projects.reductivelabs.com/projects/puppet/issues?fixed_version_id (development, docs, process)
• UsingMongrelDebugging Mongrel Debugging (debugging, development, mongrel)