├── .github └── CODEOWNERS ├── .gitignore ├── ADVOCATES.md ├── ADVOCATES.toml ├── CODE_OF_CONDUCT.md ├── Gemfile ├── README.md ├── Rakefile ├── new ├── .gitkeep ├── rfc-template.md └── rfc_closure.md ├── rfc000-rfc-process.md ├── rfc001-slack-meetings.md ├── rfc010-windows-package.md ├── rfc011-resource-guard.md ├── rfc012-openstack-network.md ├── rfc013-on-failure.md ├── rfc014-universe-endpoint.md ├── rfc015-chef-12.md ├── rfc016-homebrew-osx-package-provider.md ├── rfc017-file-specificity.md ├── rfc018-attribute-syntax.md ├── rfc019-chef-workflows.md ├── rfc020-community-guidelines.md ├── rfc021-platform-support-policy.md ├── rfc022-arbitrary-cookbook-identifiers.md ├── rfc023-chef-12-attributes-changes.md ├── rfc024-local-mode-default.md ├── rfc025-multitenant-chef-client-support.md ├── rfc026-remove-http-config-files.md ├── rfc027-file-content-verification.md ├── rfc028-mailing-list-migration.md ├── rfc029-governance-policy.md ├── rfc030-maintenance-policy.md ├── rfc031-replace-solo-with-local-mode.md ├── rfc032-dsc-resource-modules.md ├── rfc033-root-aliases.md ├── rfc034-ruby-deprecation-policy.md ├── rfc035-audit-mode.md ├── rfc036-dialects.md ├── rfc037-chef-ohai-version-metadata.md ├── rfc038-token-authentication.md ├── rfc039-event-handler-dsl.md ├── rfc040-on-demand-cookbook-libraries.md ├── rfc041-server-api-versioning.md ├── rfc042-policyfile-endpoint.md ├── rfc043-automatic-pr-assignment.md ├── rfc044-in_parallel.md ├── rfc045-node_state_separation.md ├── rfc046-ohai-cloud-network.md ├── rfc047-release-process.md ├── rfc048-github-issues-workflow.md ├── rfc049-track-rfcs.md ├── rfc050-resource-actions.md ├── rfc051-telemetry.md ├── rfc052-missing-method-missing.md ├── rfc053-ohai-config.md ├── rfc054-resource-attribute-improvements.md ├── rfc055-property-defaults.md ├── rfc056-load-and-converge.md ├── rfc057-cookbook-quality-metrics.md ├── rfc058-before.md ├── rfc059-ohai-cookbook-segment.md ├── rfc060-metadata-gem-installation.md ├── rfc061-hugs.md ├── rfc062-exit-status.md ├── rfc063-omnibus-chef-native-gems.md ├── rfc064-chefstyle.md ├── rfc065-sign-v1.3.md ├── rfc066-compound-actions.md ├── rfc067-cookbook-segment-deprecation.md ├── rfc068-postgresql-search.md ├── rfc069-cookbook-adoption.md ├── rfc070-chef-upgrade.md ├── rfc071-knife-bootstrap-client-config.md ├── rfc072-artifact-yanking.md ├── rfc073-meetbot.md ├── rfc074-community-slack.md ├── rfc075-multi-policy.md ├── rfc076-reversion-ohai.md ├── rfc077-mode-agnostic-data-collection.md ├── rfc078-supermarket-prefix.md ├── rfc079-supermarket-release-channels.md ├── rfc080-dco.md ├── rfc081-release-cadence.md ├── rfc082-deprecation-policy.md ├── rfc083-audit-phase.md ├── rfc084-test-kitchen-multi.md ├── rfc085-remove-unused-metadata.md ├── rfc086-chef-oss-project-policies.md ├── rfc087-distro-sugar-helpers.md ├── rfc088-mongodb-cookbook-transfer.md ├── rfc089-server-enforced-recipe.md ├── rfc090-server-http-head.md ├── rfc091-deprecate-kitchen-settings.md ├── rfc092-dependency-update-cadence.md ├── rfc093-server-stats-endpoint.md ├── rfc094-telemetry.md ├── rfc095-test-kitchen-telemetry.md ├── rfc096-improved-log-levels.md ├── rfc097-policyfile-includes.md ├── rfc098-deprecate-deploy-and-erlcall-resources.md ├── rfc099-authentication-config-file.md ├── rfc100-resource-lifecycle.md ├── rfc101-resource-validation-messaging.md ├── rfc102-deprecations-in-resources.md ├── rfc103-disable-passwd-and-sessions-plugins.md ├── rfc104-self-documenting-resources.md ├── rfc105-attribute-hoist.md ├── rfc106-chef_env_attribute.md ├── rfc107-resource-map-locking.md ├── rfc108-resource_metadata.md ├── rfc109-ohai-new-plugins-policy.md ├── rfc110-chef-workstation.md ├── rfc111-in-repo-draft-guides-for-chef.md ├── rfc112-target-mode.md ├── support └── rfc048-GithubIssuesWorkflow.png └── tasks ├── advocates.rb └── pages.rb /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | new/** @chef/client-maintainers 2 | * @chef/rfc-editors 3 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | Gemfile.lock 2 | gh-pages 3 | -------------------------------------------------------------------------------- /ADVOCATES.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | # Community Advocates 5 | 6 | This file lists the Community Advocates for the Chef project. Community 7 | Advocates may be assigned for each area where the community convenes online 8 | (Slack, email list, GitHub, etc.). Community Advocates are volunteers who have 9 | the best interests of our community in mind. They act in good faith to help 10 | enforce our community guidelines and respond to incidents when they occur. 11 | 12 | More information can be found in the [Chef Community Guidelines](https://github.com/chef/chef-rfc/blob/master/rfc020-community-guidelines.md). 13 | 14 | # Decider 15 | 16 | * [Adam Jacob](https://github.com/adamhjk) 17 | * Slack - holoway 18 | 19 | ## Ombudsperson 20 | 21 | * Mandi Walls 22 | * Slack - lnxchk 23 | * [mandi@chef.io](mailto:mandi@chef.io) 24 | * +1 703-582-7396 25 | 26 | ## Advocates 27 | 28 | 29 | #### Chef Community Slack 30 | * [Tim Smith](https://github.com/tas50) 31 | * Slack - tas50 32 | * [tsmith@chef.io](mailto:tsmith@chef.io) 33 | * [Seth Thomas](https://github.com/cheeseplus) 34 | * Slack - cheeseplus 35 | * [@cheeseplus](https://twitter.com/cheeseplus) 36 | * [seth.g.thomas@gmail.com](mailto:seth.g.thomas@gmail.com) 37 | * [Jerry Aldrich](https://github.com/jerryaldrichiii) 38 | * Slack - jerry 39 | * [jerry@chef.io](mailto:jerry@chef.io) 40 | * [Stuart Preston](https://github.com/stuartpreston) 41 | * Slack - stuart 42 | * [spreston@chef.io](mailto:spreston@chef.io) 43 | * [Joshua Timberman](https://github.com/jtimberman) 44 | * Slack - jtimberman 45 | * [jtimberman@chef.io](mailto:jtimberman@chef.io) 46 | * [Robb Kidd](https://github.com/robbkidd) 47 | * Slack - robbkidd 48 | * [@robbkidd](https://twitter.com/robbkidd) 49 | * [rkidd@chef.io](mailto:rkidd@chef.io) 50 | 51 | #### Chef Mailing List 52 | * [Noah Kantrowitz](https://github.com/coderanger) 53 | * [@kantrn](https://twitter.com/kantrn) 54 | * [noah@coderanger.net](mailto:noah@coderanger.net) 55 | * [Nell Shamrell](https://github.com/nshamrell) 56 | * Slack - nshamrell 57 | * [@nshamrell](https://twitter.com/nshamrell) 58 | * [nshamrell@chef.io](mailto:nshamrell@chef.io) 59 | * [Robb Kidd](https://github.com/robbkidd) 60 | * Slack - robbkidd 61 | * [@robbkidd](https://twitter.com/robbkidd) 62 | * [rkidd@chef.io](mailto:rkidd@chef.io) 63 | * [Seth Thomas](https://github.com/cheeseplus) 64 | * Slack - cheeseplus 65 | * [@cheeseplus](https://twitter.com/cheeseplus) 66 | * [seth.g.thomas@gmail.com](mailto:seth.g.thomas@gmail.com) 67 | * [Ian Henry](https://github.com/eeyun) 68 | * [@eeyun___](https://twitter.com/eeyun___) 69 | * [ian@habitat.sh](mailto:ian@habitat.sh) 70 | * [Ben Rockwood](https://github.com/benr) 71 | * [benr@chef.io](mailto:benr@chef.io) 72 | * [Josh Brand](https://github.com/joshbrand) 73 | * [jbrand@chef.io](mailto:jbrand@chef.io) 74 | * [Mark Harrison](https://github.com/mivok) 75 | * [mh@chef.io](mailto:mh@chef.io) 76 | * [Bryan McLellan](https://github.com/btm) 77 | * [btm@chef.io](mailto:btm@chef.io) 78 | * [Nathen Harvey](https://github.com/nathenharvey) 79 | * Slack - nathenharvey 80 | * [@nathenharvey](https://twitter.com/nathenharvey) 81 | * [nharvey@chef.io](mailto:nharvey@chef.io) 82 | * [Tom Duffield](https://github.com/tduffield) 83 | * [tom@chef.io](mailto:tom@chef.io) 84 | 85 | #### GitHub 86 | * [Tim Smith](https://github.com/tas50) 87 | * Slack - tas50 88 | * [tsmith@chef.io](mailto:tsmith@chef.io) 89 | 90 | #### Server Fault 91 | * Vacant - Submit a PR to become a Chef Community Advocate 92 | 93 | #### Stack Overflow 94 | * [Martin Smith](https://github.com/martinb3) 95 | * Slack - martinb3 96 | * [@martinb3](https://twitter.com/martinb3) 97 | * [martin@mbs3.org](mailto:martin@mbs3.org) 98 | * [StackOverflow](http://stackoverflow.com/users/70665/martin) 99 | 100 | #### Chef LinkedIn Group 101 | * Vacant - Submit a PR to become a Chef Community Advocate 102 | 103 | #### Chef_Opscode Reddit ([https://www.reddit.com/r/chef_opscode/](https://www.reddit.com/r/chef_opscode/)) 104 | * [Tim Smith](https://github.com/tas50) 105 | * Slack - tas50 106 | * [tsmith@chef.io](mailto:tsmith@chef.io) 107 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | Please refer to the Chef Community Code of Conduct at https://www.chef.io/code-of-conduct/ 2 | -------------------------------------------------------------------------------- /Gemfile: -------------------------------------------------------------------------------- 1 | source "https://rubygems.org" 2 | 3 | group :docgen do 4 | gem "erubis" 5 | # Require the Markdown converter gem 6 | gem "metadown", git: "https://github.com/steveklabnik/metadown.git" 7 | gem "pygments.rb" 8 | gem "rake" 9 | gem "tomlrb" 10 | end 11 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Chef RFC 2 | 3 | The repository for proposals for major changes to Chef, Chef Server, and related public projects. 4 | 5 | **<-----DEPRECATED----->** 6 | 7 | This process has been superceded by the guidelines outlined in the https://github.com/chef/chef-oss-practices and no longer applies to Chef Software projects 8 | 9 | **<-----DEPRECATED----->** 10 | 11 | ## Usage 12 | 13 | Read [RFC000](https://github.com/chef/chef-rfc/blob/master/rfc000-rfc-process.md#submitting-an-rfc) for more information on how to submit an RFC and get it reviewed. 14 | 15 | ## Generating HTML Documentation 16 | 17 | To turn the Markdown documents into HTML that can be served from a website on 18 | the gh-pages branch. Git ≥ 2.7, Ruby, and the Bundler gem are required. 19 | 20 | You'll need to have the gh-pages branch checked out locally: 21 | 22 | git fetch; git checkout -t origin/gh-pages; git checkout master 23 | 24 | Run: 25 | 26 | bundle install; bundle exec rake pages:generate 27 | 28 | After that there will be a gh-pages subdirectory that has the generated files 29 | and is on the gh-pages branch. These can be committed and pushed to deploy the 30 | website to https://chef.github.io/chef-rfc/. 31 | 32 | ## Copyright 33 | 34 | Chef RFCs are in the public domain. In jurisdictions that do not allow for this, they are available under CC0. To the extent possible under law, the person who associated CC0 with their work has waived all copyright and related or neighboring rights to their work. 35 | -------------------------------------------------------------------------------- /Rakefile: -------------------------------------------------------------------------------- 1 | require 'rubygems' 2 | require 'rubygems/package_task' 3 | require 'rdoc/task' 4 | require_relative 'tasks/advocates' 5 | require_relative 'tasks/pages' 6 | 7 | -------------------------------------------------------------------------------- /new/.gitkeep: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chef-boneyard/chef-rfc/76778b8c5b51444f973a0daecb5de471dc9ec134/new/.gitkeep -------------------------------------------------------------------------------- /new/rfc-template.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: unassigned 3 | Title: My Title 4 | Author: Alan Smithee 5 | Status: Draft 6 | Type: 7 | 8 | 9 | < - https://github.com/chef/chef/issues/X> 10 | --- 11 | 12 | # Title 13 | 14 | Description and rationale. 15 | 16 | ## Motivation 17 | 18 | As a <>, 19 | I want to <>, 20 | so that <>. 21 | 22 | ## Specification 23 | 24 | A detailed description of the planned implementation, which the RFC author agrees to execute. 25 | 26 | ## Downstream Impact 27 | 28 | Which other tools will be impacted by this work? 29 | 30 | ## Copyright 31 | 32 | This work is in the public domain. In jurisdictions that do not allow for this, 33 | this work is available under CC0. To the extent possible under law, the person 34 | who associated CC0 with this work has waived all copyright and related or 35 | neighboring rights to this work. 36 | -------------------------------------------------------------------------------- /new/rfc_closure.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: unassigned 3 | Title: Close out the RFC process 4 | Author: Tim Smithh 5 | Status: Draft 6 | Type: Process 7 | --- 8 | 9 | # Close out the RFC process 10 | 11 | This policy RFC serves to close out the Chef RFC Process as it has been superceded by the guidelines outlined in the [Chef-OSS-Practices](https://github.com/chef/chef-oss-practices) repository and the governance model outlined there. 12 | 13 | ## Motivation 14 | 15 | As a community member, 16 | I want to a single governance system for all Chef projects, 17 | so that I don't have to learn unique per project standards. 18 | 19 | As a Chef employee, 20 | I want to a simpler system to collaborate on design ideas, 21 | so that I can take feedback and concerns for even minor changes. 22 | 23 | As a contributor, 24 | I want to a system with tiered levels of commitment, 25 | so that I can take on the level of commitment right for me. 26 | 27 | As a user, 28 | I want to know the state of a repository and the response time I should expect, 29 | so that I can decide if it's appropriate to use. 30 | 31 | ## Specification 32 | 33 | This PR closes out the Chef RFC process in favor of the processes outlined in our [Chef-OSS-Practices](https://github.com/chef/chef-oss-practices) repository. Those processes apply to not only Chef, but also InSpec, Habitat, and now Automate, which gives a single governance and community contract to all projects maintained by Chef Software. 34 | 35 | Once this RFC is accepted teams will begin the process of implementing the guidelines, which occurs at the project level and also the repository level within projects. 36 | 37 | **Project level:** 38 | - Establishing which repositories are included in a project 39 | - Adding the initial list of owners, approvers, and reviewers 40 | - Creating a development channel in community Slack 41 | - Establishing office hours for triage of issues / PRs 42 | 43 | **Reposistory level:** 44 | - Adding the appropriate teams to the repos and removing existing teams 45 | - Adding repos status, project, and SLAs to the readme.md 46 | - Adding base documents such as the contributing guide and code of conduct. 47 | - Adding or updating GitHub CODEOWNERS files to use the new project teams 48 | - Adding Github issue templates for enhancements and design proposals 49 | - Migrating to standardized issue labels and adding auto label assignment to existing GitHub issue templates 50 | 51 | The final steps will be merging all relevant RFCs into the Chef developer documentation as design documents (https://github.com/chef/chef/pull/8350) and then moving this repository to the chef-boneyard, where it will remain as a historical reference. 52 | 53 | ## Downstream Impact 54 | 55 | The main impact of this change is that all Chef Software OSS repos will need to implement the processes outlined in the https://github.com/chef/chef-oss-practices and existing maintainers will need to open PRs to add themselves to one of the new roles in the new teams. 56 | 57 | ## Copyright 58 | 59 | This work is in the public domain. In jurisdictions that do not allow for this, 60 | this work is available under CC0. To the extent possible under law, the person 61 | who associated CC0 with this work has waived all copyright and related or 62 | neighboring rights to this work. 63 | -------------------------------------------------------------------------------- /rfc001-slack-meetings.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 1 3 | Title: Chef Community Slack Meetings 4 | Author: Adam Jacob 5 | Status: Accepted 6 | Type: Process 7 | --- 8 | 9 | # Chef Community Slack Meetings 10 | 11 | This RFC declares what community meetings we hold and how we hold them. 12 | 13 | # List of Meetings 14 | 15 | ## Chef Developers' Meeting 16 | 17 | Upcoming agendas, past agendas, transcripts, and minutes can be found in the 18 | [Chef Community Meetings](https://github.com/chef/chef-community-slack-meetings) 19 | repository on GitHub. 20 | 21 | ### Time 22 | 23 | Every Thursday, at 9am Pacific. 50 minutes. Each meeting's agenda will include the date and time and be announced in advance on the #community-meetings channel. 24 | 25 | ### Location 26 | 27 | The #community-meetings channel of [chef-community.slack.com](http://chef-community.slack.com) - sign-up at [http://community-slack.chef.io](http://community-slack.chef.io) 28 | 29 | ### Roles 30 | 31 | * Moderator: [Tim Smith](mailto:tsmith@chef.io) 32 | * Speakers: Anyone who wants to speak 33 | 34 | ### Standing Agenda 35 | 36 | * Agenda Review, speaker Tim Smith (tas50): 2 minutes 37 | * Updates: 15 minutes max. 38 | * Community update, speaker Tim Smith (tas50): 5 minutes 39 | * Software update, speaker - various people: 5 minutes 40 | * Review action items from last meeting, speaker Tim Smith (tas50): 5 minutes 41 | * Review PRs: 35 minutes 42 | * Review new PRs and/or PRs deferred during last meeting 43 | * Review PRs previously discussed 44 | 45 | # How 46 | 47 | ## Roles 48 | 49 | Each meeting must have the following roles assigned: 50 | 51 | 1. Moderator: this person decides who has the floor, and is in charge of moving the agenda along. 52 | 2. Speakers: the agenda may have multiple speakers assigned to a topic. 53 | 54 | If the standing Moderator is unavailable to attend, they will delegate their role to another 55 | community member. 56 | 57 | ## Agendas 58 | 59 | ### Standing Agenda 60 | 61 | Each meeting should have a standing agenda, which the meeting will default to 62 | unless otherwise stated in advance. 63 | 64 | ### Timing 65 | 66 | Meetings should be run to a schedule. Agendas should have draft time slots, and the boundaries 67 | should be held. 68 | 69 | ### Agendas are shared prior to the meeting 70 | 71 | Agendas will be sent out 24 hours prior to the meeting, via Slack in the #community-meetings 72 | channel. If no agenda is sent out in advance, the standing agenda is the meeting's agenda. 73 | 74 | ## Running a meeting 75 | 76 | ### Start 77 | 78 | 1. The meeting begins by the moderator declaring the meeting open. 79 | 2. The moderator will link to this RFC for new-comers to review what it means to be in a meeting. 80 | 3. The moderator will review the agenda, and give the floor to the first speaker. 81 | 82 | ### Timing 83 | 84 | As an agenda item nears its time limit, the moderator will give a 2 minute warning, then close the 85 | topic. 86 | 87 | ### Questions and answers 88 | 89 | It is up to the moderator and speakers to manage the back-and-forth flow of questions and answers, 90 | depending on the nature of the topic on the agenda, and the comfort of the speaker. If the speaker 91 | requests participants hold questions to the end, please be respectful. 92 | 93 | ## Meeting Conduct 94 | 95 | Please be aware of the [Community Guidelines](https://docs.chef.io/community_guidelines.html). 96 | 97 | We will follow the same [code of conduct as ChefConf and the Community summit](https://www.chef.io/blog/chefconfcodeofconduct/#long_code_of_conduct). 98 | 99 | ## Moderator can de-voice or ban 100 | 101 | The moderator has the right to de-voice, or in extreme circumstances ban completely, participants 102 | who either fail to conduct themselves appropriately, or are detrimental to the meeting. 103 | 104 | The moderator will give one warning in advance of taking action. 105 | -------------------------------------------------------------------------------- /rfc010-windows-package.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 10 3 | Author: Bryan McLellan 4 | Title: Windows Package Resource and Providers 5 | Status: Final 6 | Type: Standards Track 7 | --- 8 | 9 | # Windows Package Resource and Providers 10 | 11 | Proposal for moving windows_package LWRP from the windows cookbook into core Chef. 12 | 13 | Chef internal PBI: [OC-5114](https://tickets.corp.opscode.com/browse/OC-5114) 14 | 15 | There are a number of package installer frameworks that are common on Windows, which can specified by the user or detected. Installing packages usually means passing a flag to the installer to indicate it is an unattended installation. 16 | 17 | Support for roles features will be handled by a separate resource. 18 | 19 | ## New Core Package Resource and Provider 20 | 21 | ### Chef::Resource::WindowsPackage 22 | Shortcut Resource Name: `windows_package` 23 | 24 | This would be the default package provider on windows, so you would use the 'package' resource and wouldn't necessarily need a shortcut resource. 25 | 26 | ### Attributes 27 | 28 | * package_name - defaults to the resource name 29 | * source - the location of package to install 30 | * installer_type - for future use to manually differentiate between installers 31 | * options - flags passed to the installer 32 | * version - version of the package to install, if applicable 33 | * returns - possible exit codes that indicate success 34 | 35 | Deprecated attributes: 36 | 37 | * checksum 38 | The existing cookbook allows source to be a URL, we'd rather use remote_file to download packages unless we're passing the URL directly to the installer to avoid code duplication and maintain 'primitives.' 39 | * success_codes 40 | This will be renamed to returns to match other existing core providers 41 | 42 | ### Platform specific resources 43 | Utilizing the platform-specific resource functionality introduced in [CHEF-2698](https://tickets.opscode.com/browse/CHEF-2698), add a new package resource with windows specific attributes 44 | 45 | ``` 46 | class Chef 47 | class Resource 48 | class WindowsPackage < Chef::Resource::Package 49 | 50 | provides :package, :on_platforms => ["windows"] 51 | 52 | def initialize(name, run_context=nil) 53 | super 54 | @action = :install 55 | @allowed_actions = [ :install, :remove ] 56 | @provider = Chef::Provider::Package::Windows 57 | @resource_name = :windows_package 58 | @installer_type = nil 59 | @checksum = nil 60 | @timeout = 600 61 | @success_codes = [0, 42, 127] 62 | ``` 63 | 64 | ### Chef::Provider::Package::Windows 65 | 66 | Initial support for the Microsoft Installer (MSI) only, incrementally adding support for additional installers. 67 | 68 | All installer support in core must use a unique identifier when available (e.g. Product Code, AppID) to: 69 | * Support upgrade/removal 70 | * Idempotently verify installation state 71 | 72 | We must determine the installer type for the user to match the same experience of running the executable on windows itself. Some methods require reading the installer file, so we cannot make this determination in the resource and will do so in this provider, which will call another class specific to the determined installer 73 | 74 | [Example framework](https://gist.github.com/btm/92a40020c3eea6cb8b28) 75 | 76 | ### Chef::Provider::Package::Windows::MSI 77 | 78 | We will determine package installation status using ```MsiGetProductPropertyA``` and ```MsiGetProductInfoA``` using FFI. See the [proof of concept code](https://gist.github.com/btm/8673443#file-check_installed-rb). 79 | 80 | #### Actions 81 | * Install - Will execute the package if it is not already installed 82 | * Remove - Will remove the package by corresponding product code if installed 83 | 84 | 85 | #### Example 86 | 87 | ``` 88 | windows_package '7-Zip 9.20 (x64 edition)' do 89 | source 'http://downloads.sourceforge.net/sevenzip/7z920-x64.msi' 90 | action :install 91 | end 92 | ``` 93 | 94 | #### Future work 95 | 96 | * MSU (update) ([hotfixes + dism](http://blogs.technet.com/b/askcore/archive/2011/02/15/how-to-use-dism-to-install-a-hotfix-from-within-windows.aspx)) 97 | * MSP (patch) 98 | * MST (transform) 99 | * Idempotent upgrade based on ProductCode/ProductVersion/UpgradeCode/Revision Number Summary [Reference](http://msdn.microsoft.com/en-us/library/aa370579\(v=vs.85\).aspx) 100 | 101 | 102 | ## Existing Windows Cookbook 103 | 104 | The existing windows cookbook contains a package LWRP 105 | 106 | ### Resources 107 | * package 108 | types: msi, inno, nsis, wise, installshield, custom 109 | examples: putty-0.60-installer.exe, 7z920-x64.msi, 'Google Chrome' 110 | 111 | The type is either specified as an attribute or determined from the file extension, and is used to pass the correct arguments for a silent/automated installation to the underlying installer. The ```custom``` type requires the user to specify the correct arguments in the ```options``` attribute. 112 | 113 | ### Providers 114 | * package: handles different installers with a set of default flags for the options attribute 115 | -------------------------------------------------------------------------------- /rfc013-on-failure.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 13 3 | Author: Seth Vargo 4 | Title: On Failure 5 | Status: On Hold 6 | Type: Standards Track 7 | --- 8 | 9 | Steven, Paul, and myself were having a discussion about adding 10 | an `on_failure` handler on a per-resource basis. I wrote up an RFC proposing 11 | an API for this functionality. 12 | 13 | Defining an +on_failure+ block will rescue any exceptions, execute the given 14 | block, and then retry the resource action. 15 | 16 | ```ruby 17 | meal 'breakfast' do 18 | on_failure { notify :eat, 'food[bacon]' } 19 | end 20 | ``` 21 | 22 | The +on_failure+ block accepts an optional list of options, such as the number 23 | of times to retry before bubbling the exception up the stack. 24 | 25 | ```ruby 26 | meal 'breakfast' do 27 | on_failure(retries: 3) { notify :eat, 'food[bacon]' } 28 | end 29 | ``` 30 | 31 | You can also specify an exception or list of exceptions to run the failure 32 | block against. If the exception raised matches the given exception class (or 33 | a subclass of that exception) the block is executed. Otherwise the exception 34 | will bubble up. 35 | 36 | ```ruby 37 | meal 'breakfast' do 38 | on_failure(UncookedError) { notify :fry, 'food[bacon]' } 39 | end 40 | ``` 41 | 42 | It's possible to specify multiple exceptions to rescue in a given block. 43 | 44 | ```ruby 45 | meal 'breakfast' do 46 | on_failure(UncookedError, HungryError) { notify :fry, 'food[bacon]' } 47 | end 48 | ``` 49 | 50 | The +on_failure+ parameter is compilative, meaning declaring multiple 51 | +on_failure+ blocks is permissive. Blocks are executed in the order in 52 | which they are defined, from top-to-bottom. The pattern is useful if you 53 | need different exception handling depending on the type of exception raised. 54 | 55 | ```ruby 56 | meal 'breakfast' do 57 | on_failure(UncookedError) { notify :fry, 'food[bacon]' } 58 | on_failure(ColdError) { notify :microwave, 'food[bacon]' } 59 | end 60 | ``` 61 | 62 | For more complex failure handling, you can specify a multi-step block. The 63 | contents of the block are executed in the context of the containing recipe, 64 | in the top-level run_context (so it can notify existing resources in the 65 | top-level resource collection). 66 | 67 | ```ruby 68 | meal 'breakfast' do 69 | on_failure do 70 | alarm '7:00am' do 71 | action :buzz 72 | end 73 | end 74 | end 75 | ``` 76 | 77 | The block for +on_failure+ yields an optional reference to the parent 78 | resource (+meal[breakfast]+ in this example). This is helpful if you need 79 | information about the parent resource, such as the value of a parameter 80 | in your failure handling. 81 | 82 | ```ruby 83 | meal 'breakfast' do 84 | on_failure do |breakfast| 85 | alarm breakfast.start_time do 86 | action :buzz 87 | end 88 | end 89 | end 90 | ``` 91 | 92 | And these different methodologies can be mixed-and-matched. 93 | 94 | ```ruby 95 | meal 'breakfast' do 96 | on_failure(UncookedError) do 97 | oven 'main' do 98 | action :start 99 | end 100 | end 101 | on_failure(ThirstyError, retries: 3) do |breakfast| 102 | breakfast.minutes_until_served.each do 103 | juice 'orange' do 104 | action :drink 105 | end 106 | end 107 | end 108 | end 109 | ``` 110 | -------------------------------------------------------------------------------- /rfc014-universe-endpoint.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 14 3 | Title: Universe Endpoint for Chef Server 4 | Author: Daniel DeLeo 5 | Status: Final 6 | Type: Standards Track 7 | Tracking: 8 | - https://github.com/chef/chef-server/pulls/645 9 | --- 10 | 11 | # Universe Endpoint for Chef Server 12 | 13 | ## Use Case 14 | 15 | Users would like to host their cookbook artifacts on their chef-server 16 | and use these artifacts with an external dependency solver. There are a 17 | variety of motivations for hosting cookbooks internally: 18 | 19 | * User wants to control the availability of the service they fetch 20 | cookbooks from. 21 | * User wants to publish closed source cookbooks to a centralized 22 | artifact server for internal distribution within their organization. 23 | * User wants to vet third party cookbooks before other users in their 24 | organization access them for compliance and/or stability reasons. 25 | 26 | Users can currently publish cookbooks to a chef server using `knife` or 27 | any other tool that implements the server's HTTP API. If the user wants 28 | to find a version compatible set of cookbooks and dependencies, however, 29 | they currently must recursively query the chef server, making a request 30 | for the list of cookbook names, the list of versions of each cookbook, 31 | and the dependencies of each version. The large number of round trips 32 | involved would make this operation prohibitively time-consuming. 33 | Currently, working around this limitation requires caching the 34 | dependency information and refreshing it periodically, which implies 35 | running a separate service that periodically polls the chef server for 36 | updates to the dependency information. This workaround is suboptimal 37 | because it requires the overhead of managing a separate service and adds 38 | latency to the dissemination of cookbooks after publishing. 39 | 40 | ## Universe Endpoint 41 | 42 | This proposal addresses the described use case by adding a dependency 43 | API to the chef server. The endpoint is accessed by making an HTTP GET 44 | request to BASE_SERVER_URL/universe; in Enterprise Chef a full URL may 45 | look like 46 | 47 | https://chef-server.example.org/organizations/org_name/universe 48 | 49 | Assuming the request meets all authentication and authorization 50 | requirements, the server responds with a JSON document containing the 51 | list of all cookbooks, their available versions, and the dependencies of 52 | each. The format of this document is mostly identical to the format of 53 | the response given by the supermarket universe API, which is documented 54 | here: http://docs.opscode.com/api_cookbooks_site.html#universe The 55 | response given by the chef server differs from the supermarket API in 56 | that the `location_type` field in the response is set to "chef_server". 57 | 58 | ## Copyright 59 | 60 | This work is in the public domain. In jurisdictions that do not allow for this, 61 | this work is available under CC0. To the extent possible under law, the person 62 | who associated CC0 with this work has waived all copyright and related or 63 | neighboring rights to this work. 64 | -------------------------------------------------------------------------------- /rfc016-homebrew-osx-package-provider.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 16 3 | Author: Joshua Timberman 4 | Status: Accepted 5 | Type: Standards Track 6 | Chef-Version: 12 7 | Title: Make Homebrew OS X's Default Package Provider 8 | --- 9 | 10 | # Make Homebrew OS X's Default Package Provider 11 | 12 | [Homebrew](http://brew.sh) is a very popular source-compile based package manager for OS X. A [cookbook](https://supermarket.chef.io/cookbooks/homebrew) providing a homebrew as the OS X default provider for Chef's package resource has existed for years. Currently in Chef, the default package provider on `mac_os_x` platforms is [Macports](http://www.macports.org/). Since the cookbook makes homebrew the default in a `libraries` file, it is automatically loaded and present on any node that has the homebrew cookbook downloaded as a dependency, even if they're not using it. Many users may not even be aware that macports is the Chef default. 13 | 14 | ## Specification 15 | 16 | `Chef::Provider::Package::Macports` is the default for platforms `mac_os_x` and `mac_os_x_server` in Chef's [platform provider mapping](https://github.com/chef/chef/blob/master/lib/chef/platform/provider_mapping.rb). 17 | 18 | ```ruby 19 | :mac_os_x => { 20 | :default => { 21 | :package => Chef::Provider::Package::Macports, 22 | } 23 | }, 24 | :mac_os_x_server => { 25 | :default => { 26 | :package => Chef::Provider::Package::Macports, 27 | } 28 | } 29 | ``` 30 | 31 | This RFC proposes to change this to: 32 | 33 | ```ruby 34 | :mac_os_x => { 35 | :default => { 36 | :package => Chef::Provider::Package::Homebrew, 37 | } 38 | }, 39 | :mac_os_x_server => { 40 | :default => { 41 | :package => Chef::Provider::Package::Homebrew, 42 | } 43 | } 44 | ``` 45 | 46 | It would largely leverage the code in the homebrew cookbook's `homebrew_package.rb` [libraries](https://github.com/chef-cookbooks/homebrew/blob/master/libraries/homebrew_package.rb). We would probably need to clean some things up and modernize it to better fit with the rest of the Chef core package providers, and we would definitely need to have tests added. 47 | 48 | Macports would still remain in Chef as an alternative for those who use it, and it could be set as default similar to what the homebrew cookbook does now, in its [own cookbook](https://supermarket/chef.io/cookbooks/macports). 49 | 50 | ## Motivation 51 | 52 | The motivation for this change is to modernize the "sane defaults" that Chef provides as primitives. When Chef was created, Homebrew didn't exist - Macports was the "de facto" way to install software packages from source "ports-style." Ticket [CHEF-1250](https://tickets.opscode.com/browse/CHEF-1250) was opened four years ago proposing homebrew as the package provider, so interest in this has existed for a long time. The general developer community that uses OS X seems to have rallied around Homebrew (680+ watchers, 18,500+ stars, 9000+ forks on its GitHub repo) to provide this functionality. It is very comprehensive (over 2900 packages), and reuses the system libraries that OS X provides so users don't have to compile the entire world to install software. 53 | 54 | ## Rationale 55 | 56 | Issue #28 was opened to briefly propose this change and within a week received an overwhelming ":+1" from respondents. So far I haven't found many people that are still using Macports instead of Homebrew, and no one has mentioned anything in the issue or on the mailing list. 57 | 58 | ## Compatibility 59 | 60 | This is a backwards-incompatible change for cookbooks for users who rely on using the Macports provider. All users who have the `homebrew` cookbook already use it for the default package provider. Recipe code in cookbooks that `depends "homebrew"` won't need to be changed at all. Users will still need to have a recipe that installs Homebrew itself. This is no different than `macports` itself, which isn't installed on OS X by default either, and needs its own cookbook. 61 | 62 | ## Reference Implementation 63 | 64 | The `homebrew` cookbook maintained by CHEF is the reference implementation. It lacks tests, but those would be added as mentioned above. 65 | 66 | ## Copyright 67 | 68 | The code to implement this feature will come directly from CHEF's homebrew cookbook. It was originally written by Graeme Mathieson, and was licensed under the [Apache 2.0 Software License](https://github.com/chef-cookbooks/homebrew/blob/49936df5fd8cc6610262621b3c41c1e3bcbb9c62/metadata.rb#L3). The current copyrights listed in the cookbook are: 69 | 70 | - Copyright 2011, Graeme Mathieson 71 | - Copyright 2011-2013, Opscode, Inc. 72 | - Copyright 2014, Chef Software, Inc 73 | -------------------------------------------------------------------------------- /rfc017-file-specificity.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 17 3 | Title: File Specificity Overhaul 4 | Author: Noah Kantrowitz 5 | Status: Final 6 | Type: Standards Track 7 | Chef-Version: 12 8 | --- 9 | 10 | # File Specificity Overhaul 11 | 12 | The file specificity system allows overriding templates and cookbook files on 13 | a per-platform or per-host basis. It is used relatively infrequently, but can 14 | be invaluable when it is used. Unfortunately it adds significant mental overhead 15 | to new users that don't understand the meaning of the `default/` folder. It is 16 | also relatively inflexible, the lookup path is fixed to use the node name and 17 | platform information. This can be improved on both counts, simplifying the 18 | default case as well as improving flexibility for cases when it is needed. 19 | 20 | ## Specification 21 | 22 | The current file specificity lookup process is governed by two things, the 23 | lookup path and the source attribute. The current lookup path is: 24 | 25 | 1. `/host-$fqdn/$source` 26 | 1. `/$platform-$platform_version/$source` 27 | 1. `/$platform/$source` 28 | 1. `/default/$source` 29 | 30 | The first of these paths that exists is used, or an error is raised in none 31 | exist. 32 | 33 | The revised default lookup path would add `/` to the end: 34 | 35 | 1. `/host-$fqdn/$source` 36 | 1. `/$platform-$platform_version/$source` 37 | 1. `/$platform/$source` 38 | 1. `/default/$source` 39 | 1. `/$source` 40 | 41 | If the source attribute is given as an array, this will be used instead of the 42 | default lookup path. 43 | 44 | The default lookup path can be deprecated in the future, but this is outside 45 | the scope of this RFC. 46 | 47 | ## Motivation 48 | 49 | The motivation for this change is two-fold; to reduce the difficulty of creating 50 | a cookbook and improving flexibility for conditional file selection. The first 51 | goal is addressed by removing the need for the `default/` folder when adding 52 | templates and cookbook files. This is currently a stumbling block for new users 53 | that don't yet know about the file specificity system and don't need the 54 | features it provides. 55 | 56 | The latter goal is addressed by adding support for an explicit lookup path by 57 | giving an array for the source attribute: 58 | 59 | ```ruby 60 | template '/test' do 61 | source ["#{node.chef_environment}.erb", 'default.erb'] 62 | end 63 | ``` 64 | 65 | This allows for far more flexibility in file selection while reducing the magic 66 | of the default lookup path. 67 | 68 | The default lookup path can be emulated explicitly: 69 | 70 | ```ruby 71 | template '/test' do 72 | source %W{ 73 | host-#{node['fqdn']}/test.erb 74 | #{node['platform']}-#{node['platform_version']}/test.erb 75 | #{node['platform']}/test.erb 76 | default/test.erb 77 | } 78 | end 79 | ``` 80 | 81 | ## Compatibility 82 | 83 | This change is effectively backwards compatible. It is possible some recipe code 84 | which currently results in an error will now converge successfully, but the 85 | impact of this is likely to be infinitesimal. By keeping the default lookup path 86 | for now, full compatibility with current cookbooks is maintained. 87 | 88 | ## Copyright 89 | 90 | This work is in the public domain. In jurisdictions that do not allow for this, 91 | this work is available under CC0. To the extent possible under law, the person 92 | who associated CC0 with this work has waived all copyright and related or 93 | neighboring rights to this work. 94 | -------------------------------------------------------------------------------- /rfc021-platform-support-policy.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 21 3 | Author: Julian Dunn 4 | Title: Chef Platform Support Policy 5 | Status: Accepted 6 | Type: Informational 7 | --- 8 | 9 | # Chef Platform Policy 10 | 11 | The purpose of this RFC is to clarify which platforms the Chef community chooses to work on, and how those platforms are maintained. 12 | 13 | The [chef docs site](https://docs.chef.io/) has [details of the platforms Chef Software, Inc validates for release](https://docs.chef.io/platforms.html). 14 | 15 | # Adding a new platform 16 | 17 | Community maintenance of a platform requires that core chef resources, 18 | including `package`, `file`, and `service`, MUST have working providers 19 | for the platform. For example, on Debian the package provider supports both 20 | `dpkg` and `apt`. Ohai SHOULD also be able to gather relevant 21 | information on the platform. 22 | 23 | In addition to support in code, there SHOULD be a Lieutenant for the 24 | platform, per RFC 30. There MAY also be one or more Maintainers for the 25 | platform. The Lieutenant and any Maintainers are responsible for 26 | reviewing RFCs and code that affects the platform, and SHOULD be 27 | responsible for ensuring that new versions of the platform are 28 | supported. 29 | 30 | # Currently supported platforms 31 | 32 | If not specified, chef works with all versions of a given 33 | platform that the manufacturer supports. 34 | 35 | Platform | Versions | Architectures | Package Format 36 | ---- | --- | --- | --- 37 | AIX | 6.1, 7.1, 7.2 | ppc64 | bff 38 | CentOS | 5, 6, 7 | i386, x86_64 | rpm 39 | Cisco IOS XR | 6 | x86_64 | rpm 40 | Cisco NX-OS | 7 | x86_64 | rpm 41 | Debian | 7, 8 | i386, x86_64 | deb 42 | FreeBSD | 9, 10 | i386, amd64 | pkg_add pkg 43 | Mac OS X | 10.9, 10.10, 10.11, 10.12 | x86_64 | dmg 44 | Oracle Enterprise Linux | 5, 6, 7 | i386, x86_64 | rpm 45 | Red Hat Enterprise Linux | 5, 6, 7 | i386, x86_64 | rpm 46 | Solaris | 10u11, 11 | sparc, x86 | shar 47 | Windows | 7, 8, 8.1, 2008R2, 2012, 2012R2 | x86, x86_64 | msi 48 | Ubuntu Linux | | x86, x86_64 | deb 49 | SUSE Linux Enterprise Server | 11, 12 | x86_64 50 | Scientific Linux | 5.x, 6.x and 7.x | i386, x86_64 51 | Fedora | | x86_64 | 52 | OpenSUSE | | x86_64 | 53 | OmniOS | | x86_64 | 54 | Gentoo Linux | | x86_64 | 55 | Arch Linux | | x86_64 | 56 | 57 | ## Copyright 58 | 59 | This work is in the public domain. In jurisdictions that do not allow for this, this work is available under CC0. To the extent possible under law, the person who associated CC0 with this work has waived all copyright and related or neighboring rights to this work. 60 | -------------------------------------------------------------------------------- /rfc024-local-mode-default.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 24 3 | Title: Local Mode Default 4 | Author: John Keiser 5 | Status: Withdrawn 6 | Type: Standards Track 7 | Chef-Version: 12 8 | --- 9 | 10 | # Local Mode Default 11 | 12 | Turn on Local Mode by default in Chef 12 (do not require -z). 13 | 14 | ## Motivation 15 | 16 | As a new Chef user, 17 | I want to be able to run my first recipe without typing weird parameters, 18 | so that I can come to love Chef that much more quickly and without any conceptual obstacles. 19 | 20 | As a local developer, 21 | I want to be able to iterate quickly on recipes with less typing, 22 | so that I can avoid carpal tunnel syndrome. 23 | 24 | As a Chef book or tutorial author, 25 | I want to be able to write examples free of dashes, 26 | because they mess up formatting and make the user ask questions I don't need them asking early in the tutorial. 27 | 28 | ## Specification 29 | 30 | I propose that: 31 | 32 | 1. `Chef::Config.local_mode` default to `true` when `chef_server_url` is not set. 33 | 2. The default `Chef::Config.chef_server_url` of https://localhost:443 be removed (and have no default). 34 | 3. When `chef-client` does not find `/etc/chef/client.rb`, it search for `knife.rb` in the same manner as local mode. 35 | 4. The warning for missing config file is set to INFO. 36 | 5. When the config file is missing, the algorithm that detects the chef repository by looking for a "cookbooks/" directory also looks for "clients/" (and thus, after the first time you run chef-client, you will no longer get any warnings). 37 | 38 | ## Rationale 39 | 40 | This will make it so that when you first walk up to Chef, your experience is thus: 41 | 42 | ``` 43 | $ echo "puts 'hi'" > x.rb 44 | $ chef-client x.rb 45 | WARN: No chef repository detected at or above current directory (no cookbooks/ or clients/ subdirectories found). Assuming current directory (/Users/jkeiser/test). 46 | WARN: chef-client will create a /Users/jkeiser/test/clients and /Users/jkeiser/test/nodes, and you will not see this warning again. 47 | ... 48 | $ knife node list 49 | foo 50 | $ chef-client x.rb 51 | ... 52 | ``` 53 | 54 | Presently, when chef-client is run without configuration (or the configuration does not point at a Chef server), we assume the user wanted to point at a local Chef server (https://localhost:443). This is not a particularly common mode of operation now that chef-zero exists (which only recently supported https), and many many more users will be running local mode. Further, existing real clients will definitely *not* be pointing at localhost; they point at real servers. 55 | 56 | This change could have been implemented more simply by simply defaulting `Chef::Config.local_mode` to `true`. However, this would impact nearly all chef-clients (which would stop working until local_mode was turned off) without actually helping any more of the intended users (who generally will not have configuration). By tying this to setting the `chef_server_url`, we ensure that clients who actually want to contact a Chef server can do so, and target only people who weren't talking to a Chef server in the first place. 57 | 58 | The oddest behavior here is that users who want to run `chef-client` in local mode on a managed machine probably won't actually run in local mode. Without changing the default behavior of `chef-client`, I'm not sure there is a way around this without changing the config structure completely (which would be another RFC). Nonetheless, this at least gets us much closer to a parameter-free world, and *definitely* gets us there for new users. 59 | 60 | ## Impact 61 | 62 | - `chef-client` and `knife`, when run with no parameters and no configuration, will run in local mode without the `-z` parameter. 63 | - Existing clients that *do* have configuration but assume the Chef server is at https://localhost:443, will start running with empty runlists. 64 | - Existing clients that do not have `/etc/chef/client.rb` but just assume https://localhost:443 will load `knife.rb`. 65 | - Users who want to run `chef-client` in local mode on a managed machine with `/etc/chef/client.rb` will not end up loading `knife.rb` and probably not even run local mode. 66 | - When users accidentally run knife and chef-client outside of their repository, they will now warn the user but still give them output which they might not expect. When you run `knife node list`, for example, outside of a repository, it will not return any nodes and have empty output. We rely on the warnings to indicate to the user that something is up: 67 | 68 | ``` 69 | $ knife node list 70 | WARN: No chef repository detected at or above current directory (no cookbooks/ or clients/ subdirectories found). Assuming current directory (/Users/jkeiser/test). 71 | WARN: You may not be in the right directory. 72 | ``` 73 | 74 | Before, that would have triggered an error related to not having a private key or being able to access https://localhost:443. 75 | 76 | ## Copyright 77 | 78 | This work is in the public domain. In jurisdictions that do not allow for this, this work is available under CC0. To the extent possible under law, the person who associated CC0 with this work has waived all copyright and related or neighboring rights to this work. 79 | 80 | -------------------------------------------------------------------------------- /rfc026-remove-http-config-files.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 26 3 | Title: Remove HTTP Config Files 4 | Author: John Keiser 5 | Status: Final 6 | Type: Standards Track 7 | Chef-Version: 12 8 | --- 9 | 10 | # Remove HTTP Config Files 11 | 12 | Remove the ability to specify HTTP config files with `chef-client -c http://blah.com/client.rb`. 13 | 14 | ## Motivation 15 | 16 | As a Chef developer, 17 | I want to not have to directly find and fix the unknown number of bugs where we assume config_file is a path, 18 | so that I can write new features for Chef instead. 19 | 20 | As a Chef user, 21 | I am not using the ability to download a config file as a URL, 22 | And I am much more interested in the Chef developers writing new features instead of fixing bugs in it. 23 | 24 | ## Specification 25 | 26 | 1. Get rid of all code that lets you treat Chef::Config.config_file as an HTTP or HTTPS URL (in ConfigFetcher primarily). 27 | 2. Make it an error when you specify a config file that does not exist. 28 | 29 | ## Rationale 30 | 31 | There are already bugs in the chef-client because we assume client is a path (`config_dir` is [File.dirname(`config_file`)](https://github.com/chef/chef/blob/master/lib/chef/config.rb#L84), and some [rather crucial values](https://github.com/chef/chef/blob/master/lib/chef/config.rb#L365) are inferred from `config_dir`). While we could find and fix them all, we could also just make the code simpler by removing this capability. 32 | 33 | ## Impact and Workaround 34 | 35 | Anyone running `chef-client -c http://blah.com/client.rb` will get an error saying the config file does not exist. 36 | 37 | I suspect the number of people this will affect is somewhere between 0 and 0. No Chef-written servers export config directly and there are very real security concerns around it. If those people exist, there are real bugs in the client that those people are hitting because of it, as well (see the `config_dir` issue in Rationale). Hence this RFC, so we can discuss it. 38 | 39 | Users who *are* doing this can restore the original effect by doing the following in `/etc/chef/client.rb`: 40 | 41 | ```ruby 42 | require 'net/http' 43 | instance_eval(Net::HTTP.get('blah.com', '/client.rb')) 44 | ``` 45 | 46 | ## Copyright 47 | 48 | This work is in the public domain. In jurisdictions that do not allow for this, 49 | this work is available under CC0. To the extent possible under law, the person 50 | who associated CC0 with this work has waived all copyright and related or 51 | neighboring rights to this work. 52 | -------------------------------------------------------------------------------- /rfc027-file-content-verification.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 27 3 | Title: File Content Verification 4 | Author: Steven Danna 5 | Status: Final 6 | Type: Standards Track 7 | Chef-Version: 12 8 | --- 9 | 10 | # File Content Verification 11 | 12 | File-based resources should be able to verify a file's content via 13 | user-supplied instructions before deploying the new content. 14 | 15 | ## Specification 16 | 17 | The `verify` attribute of the `file`, `template`, `cookbook_file`, and 18 | `remote_file` resources will take a user-provided block or string. At 19 | converge time, a block will be passed the path to a temporary file 20 | holding the proposed content for the file. If the block returns `true` 21 | the provider will continue to update the file on disk as 22 | appropriate. If the block returns false, the provider will raise an 23 | error. 24 | 25 | If a string argument to verify is passed, it will then be executed as 26 | a system command. If the command's return code indicates success (0 on 27 | unix-like system) the provider will continue to update the file on 28 | disk as appropriate. If the command's return code indicates failure, 29 | the provider will raise an error. 30 | 31 | The path to the temporary file with the proposed content will be 32 | available by using Ruby's sprinf formatting: 33 | 34 | "%{path}" 35 | 36 | other variables may be made available to commands in the future. 37 | 38 | If no verification block or string is supplied by the user, the 39 | provider assumes the content is valid. 40 | 41 | Multiple verify blocks may be provided by the user. All given verify 42 | block must pass before the content is deployed. 43 | 44 | As an example: 45 | 46 | ```ruby 47 | # This should succeed 48 | template "/tmp/foo" do 49 | verify do |path| 50 | true 51 | end 52 | end 53 | 54 | # This should succeed on most systems 55 | template "/tmp/wombat" do 56 | verify "/usr/bin/true" 57 | end 58 | 59 | # This should raise an error 60 | template "/tmp/bar" do 61 | verify do |path| 62 | false 63 | end 64 | end 65 | 66 | # This should raise an error on most systems 67 | template "/tmp/turtle" do 68 | verify "/usr/bin/false" 69 | end 70 | 71 | # This should pass 72 | template "/tmp/baz" do 73 | verify { true } 74 | verify { 1 == 1 } 75 | end 76 | 77 | # This should raise an error 78 | template "/tmp/bat" do 79 | verify { true } 80 | verify { 1 == 0 } 81 | end 82 | ``` 83 | 84 | Users could use this feature to shell out to tools which check the 85 | configuration: 86 | 87 | ```ruby 88 | template "/etc/nginx.conf" do 89 | verify "nginx -t -c %{path}" 90 | end 91 | ``` 92 | 93 | Chef may ship built-in verifiers for common checks such as 94 | content-type verification. Built-in verifiers can be used by passing 95 | well-known symbols to the verify attribute: 96 | 97 | ```ruby 98 | template "/etc/config.json" do 99 | verify :json 100 | end 101 | ``` 102 | 103 | ## Motivation 104 | 105 | Typos and bugs in a template can lead Chef to render invalid 106 | configuration files on a node. In some cases, this will cause the 107 | related service to fail a notified restart, bringing down the user's 108 | application. One hopes to catch such errors in testing, but that is 109 | not always possible. 110 | 111 | Many applications provide a means to verify a configuration file, but 112 | it is currently difficult to use these tools to verify a template 113 | without an elaborate series of resources chained together with 114 | notifications. 115 | 116 | ## Related BUGS 117 | 118 | https://tickets.opscode.com/browse/CHEF-4416 119 | https://tickets.opscode.com/browse/CHEF-3634 120 | 121 | ## Compatibility 122 | 123 | This feature is backwards compatible with existing recipes. 124 | 125 | ## Copyright 126 | 127 | This work is in the public domain. In jurisdictions that do not allow 128 | for this, this work is available under CC0. To the extent possible 129 | under law, the person who associated CC0 with this work has waived all 130 | copyright and related or neighboring rights to this work. 131 | -------------------------------------------------------------------------------- /rfc028-mailing-list-migration.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 28 3 | Title: Mailing List Migration 4 | Author: Julian C. Dunn 5 | Status: Accepted 6 | Type: Informational 7 | --- 8 | 9 | # Migration Status - Complete 10 | 11 | This RFC was accepted and the work proposed herein has been completed. The mailing list was cutover from http://lists.opscode.com to https://discourse.chef.io on 13 October 2015. 12 | 13 | The details below are being maintained to provide insight on motivation for the switch and for other historical purposes. 14 | 15 | # Mailing List Migration 16 | 17 | This RFC proposes the migration of all existing Chef mailing lists 18 | (namely, `{chef,chef-dev}@lists.opscode.com`) to 19 | [Discourse](http://www.discourse.org/). Discourse is a modern web application 20 | for discussion forums that can also be used like a mailing list with 21 | subscriptions and mail-in responses and posts. 22 | 23 | ## Motivation 24 | 25 | As a user of Chef, 26 | I want the Chef mailing lists on a reliable and easy-to-use platform, 27 | So that I can easily collaborate with others in the community. 28 | 29 | As a system administrator working at Chef Software, Inc., 30 | I want to retire the old mailing list system & not manage one in-house, 31 | So that I can focus my attention on higher-priority infrastructure issues. 32 | 33 | ## Specification 34 | 35 | This RFC proposes to migrate the existing Sympa-run mailing lists at 36 | `lists.opscode.com` to [Discourse](http://www.discourse.org/). 37 | 38 | There are only two mailing lists of note: `chef` and `chef-dev`. The 39 | desired group names would be the same, but if `chef` is already taken, 40 | we propose that the new group name become `chef-users`. 41 | 42 | ### Subscriber Migration 43 | 44 | All existing subscribers on the current mailing list(s) would be 45 | migrated to their counterparts on Discourse. 46 | 47 | ### Archive Migration 48 | 49 | Chef Software, Inc. will make a reasonable attempt to migrate the 50 | archives of each of these mailing lists out of Sympa, potentially 51 | using a tool like 52 | [sympa-data-exporter](https://github.com/cdelacroix/sympa-data-extract) and into 53 | Discourse. 54 | 55 | However, we recognize that this may not be feasible. If it is not, 56 | we will simply create a static HTML site of the old Sympa archives 57 | and publish that. 58 | 59 | ## Rationale 60 | 61 | The existing mailing list system at 62 | [lists.opscode.com](http://lists.opscode.com), Sympa, is very old and fragile. 63 | Additionally, it is not a delightful experience for end-users of 64 | Chef, who must navigate a non-intuitive interface to subscribe to, 65 | unsubscribe from, and view the archives of the Chef user and developer 66 | mailing lists. 67 | 68 | There have been [previous efforts dating to 2012](http://archive.lists.chef.io/sympa/arc/chef-dev/2012-06/msg00029.html) to 69 | try and migrate off Sympa, but none have succeeded thus far. 70 | 71 | In February, 2015, we attempted a move to Google Groups. This failed because we 72 | immediately exceeded the allowable number of messages for our group. Our group 73 | is tied to our business google apps account which should have the limit 74 | increased in April of 2015 but there's no guarantee that the system will then 75 | support our group. It's best not to proceed with Google Groups. 76 | 77 | ## Copyright 78 | 79 | This work is in the public domain. In jurisdictions that do not allow for this, 80 | this work is available under CC0. To the extent possible under law, the person 81 | who associated CC0 with this work has waived all copyright and related or 82 | neighboring rights to this work. 83 | -------------------------------------------------------------------------------- /rfc029-governance-policy.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 29 3 | Title: Chef Board of Governance 4 | Author: Adam Jacob 5 | Status: Removed 6 | Type: Process 7 | --- 8 | 9 | # Chef Board of Governance 10 | 11 | Chef was designed from the outset to have a very open structure, including open design, open contribution, and consistent use of tools across the project. Given the large numbers of contributors, users, and companies with a stake in the future of the project, Chef leadership is looking to establish an advisory board, as part of its long term commitment to open governance. 12 | 13 | 14 | The Chef Board of Governance (CBGB) was officially closed on Septemeber 7, 2018 because the original concerns of the CBGB have been mostly addressed. 15 | 16 | ## Copyright 17 | 18 | This work is in the public domain. In jurisdictions that do not allow for this, 19 | this work is available under CC0. To the extent possible under law, the person 20 | who associated CC0 with this work has waived all copyright and related or 21 | neighboring rights to this work. 22 | -------------------------------------------------------------------------------- /rfc031-replace-solo-with-local-mode.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 31 3 | Title: Replace chef-solo with chef-client local mode 4 | Author: Joshua Timberman 5 | Status: Accepted 6 | Type: Standards Track 7 | --- 8 | 9 | # Replace chef-solo with chef-client local mode 10 | 11 | Replace chef-solo's core with chef-client "local-mode," to run chef without an external Chef Server 12 | 13 | ## Motivation 14 | 15 | As a Chef user, 16 | I want to run and use Chef without a server, 17 | so that I am using the same API and core features, 18 | and so that I can use any published cookbooks. 19 | 20 | Case in point, the `chef-solo-search` cookbook exists to provide search-like functionality so that users of `chef-solo` can use public cookbooks unmodified. 21 | 22 | The `knife-solo` RubyGem exists to make it easier to distribute the parts of a "chef repository" to target nodes. However, it has a completely different workflow than what users who have a Chef Server use, leading to confusion and differences in help systems such as IRC and the mailing list. 23 | 24 | Amazon Web Services "OpsWorks" uses `chef-solo` as its implementation, which leads to issues with workflow and support similar to `knife-solo`. 25 | 26 | There doesn't exist a clear and easy way for `chef-solo` users to migrate to a `chef-client`/Chef Server implementation and vice versa, due to the lack of "server" features. 27 | 28 | ## Specification 29 | 30 | This RFC proposes to replace `chef-solo` with `chef-client --local-mode`. The`chef-solo` command will continue to exist, and to the extent possible, work with existing solo-specific workflows without modification. 31 | 32 | This means that `chef-solo` using "local mode" **must** be 100% backwards-compatible with existing `chef-solo` usage. 33 | 34 | The local mode feature of `chef-client` uses `chef-zero`, an in-memory API-complete implementation of the Chef Server. This would give "solo" users the capability of performing searches, "saving" node objects, and easily saving and retrieving data bags. The `chef-zero` server can persist data to disk, allowing that to be distributed to other nodes as necessary. 35 | 36 | The application implementation of `chef-solo` would be changed to invoke `chef-client` with `Chef::Config[:local_mode]` set to `true` by default in the application class. 37 | 38 | ## Rationale 39 | 40 | Chef has always had `chef-solo`, a standalone recipe execution engine that can run recipes on nodes. However, as new `chef-client`/Chef Server features are added, they slowly trickle down to `chef-solo`, if they even get implemented at all. This makes `solo` users unable to have complete consistency when consuming cookbooks from the community. 41 | 42 | This will also simplify the codebase, as there is a great deal of duplication between `Chef::Application::Solo` and `Chef::Application::Client`. This would create a single place to go for the application config - the `Chef::Application::Client` class. 43 | 44 | ## Copyright 45 | 46 | This work is in the public domain. In jurisdictions that do not allow for this, 47 | this work is available under CC0. To the extent possible under law, the person 48 | who associated CC0 with this work has waived all copyright and related or 49 | neighboring rights to this work. 50 | -------------------------------------------------------------------------------- /rfc033-root-aliases.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 33 3 | Title: Root Aliases in Cookbooks 4 | Author: Noah Kantrowitz 5 | Status: Accepted 6 | Type: Standards Track 7 | --- 8 | 9 | # Root Aliases in Cookbooks 10 | 11 | There are several common cases when writing Chef cookbooks that result in a 12 | folder containing a single file, usually called `default.rb`. Root aliases 13 | allow using a single file instead of a folder. 14 | 15 | ## Motivation 16 | 17 | As a cookbook author, 18 | I want to less complex directory layouts, 19 | so that learning and maintenance is easier. 20 | 21 | ## Specification 22 | 23 | There are two common cases where a single-file-in-folder comes up: 24 | 25 | 1. `attributes/default.rb` 26 | 2. `recipes/default.rb` 27 | 28 | With `attributes` this is common to the point of almost complete irrelevance of 29 | other layouts given that all attribute files are always loaded. Recipes aren't 30 | exclusively singletons, but it is common enough to warrant a special case. 31 | 32 | With this in mind, aliases are available for each: 33 | 34 | 1. `attributes.rb` 35 | 2. `recipe.rb` 36 | 37 | It is an error for a cookbook to contain both an alias and its target or two 38 | aliases for the same target. 39 | 40 | No aliases are provided for other types as they are generally a more advanced 41 | use case where the worry about learning curve is reduced. 42 | 43 | Aliases are equivalent to their target file for purposes of loading either via 44 | standard cookbook loading or methods like `include_recipe`. 45 | 46 | ## Rationale 47 | 48 | This meshes well with RFC017 towards a goal of reducing the file layout 49 | complexity of simple cookbooks. There can be compatibility issues with tools 50 | that parse the cookbook manifest data and presume that all files from a given 51 | segment reside under the previously required folder, however the author knows 52 | of no such tools and given that the manifest format is mostly an internal 53 | representation this is not considered a blocker. Overall the goal of these RFCs 54 | is to remove the frequent use of single-child folders. 55 | 56 | The choice of which aliases to provide and what to name them is mostly driven 57 | by the common cases, but is not exhaustive. `attributes.rb` and `recipe.rb` are 58 | chosen to match their usage grammatically. An additional alias of `recipes.rb` 59 | could be provided to match the folder name, but this is left for a future 60 | improvement based on usage feedback. 61 | 62 | This was [previously implemented in the unmerged dialects branch](https://github.com/coderanger/chef/commit/754803597898ebd8dfc71aabde88c2f7c882aa25). 63 | 64 | ## Copyright 65 | 66 | This work is in the public domain. In jurisdictions that do not allow for this, 67 | this work is available under CC0. To the extent possible under law, the person 68 | who associated CC0 with this work has waived all copyright and related or 69 | neighboring rights to this work. 70 | -------------------------------------------------------------------------------- /rfc034-ruby-deprecation-policy.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 34 3 | Title: Ruby Version Deprecation Policy 4 | Author: Daniel DeLeo 5 | Status: Accepted 6 | Type: Standards Track 7 | --- 8 | 9 | # Ruby Version Deprecation Policy 10 | 11 | Establishes a rolling version policy for Chef and ChefDK and the 12 | associated ecosystem (berkshelf, test-kitchen, etc). 13 | 14 | ## Motivation 15 | 16 | As a Chef User, 17 | I want to avoid changes to supported Ruby VMs during a release cycle, 18 | so that I can have a stable installation process. 19 | 20 | ## Specification 21 | 22 | Minor version bumps of the ruby version shipping with Chef and ChefDK 23 | will only require a minor version bump of the Chef and ChefDK package. 24 | 25 | Raising the `required_ruby_version` floor of any associated gem by 26 | a minor version will only require a minor version bump of the gems 27 | and associated omnibus packages. 28 | 29 | Ruby versions MUST be supported until they are no longer releasing 30 | bugfixes and have entered the security maintenance phase. 31 | 32 | Ruby versions MAY be supported after they have entered the security 33 | maintenance phase. 34 | 35 | ## Rationale 36 | 37 | As ruby versions enter their security release phase, many gems in the 38 | ruby ecosystem drop support for them which creates a support burden. 39 | 40 | To reduce that support burden, Chef and ChefDK must be flexible enough 41 | to drop support for those old ruby versions without releasing a 42 | new major version. 43 | 44 | Historically, the 12.9.38 release of the chef gem dropped support for 45 | ruby 2.0.x and this was found to not cause any customer facing issues. 46 | 47 | ## Scope 48 | 49 | This RFC only covers how long a ruby version will be supported for, it 50 | does not cover which supported ruby version will be shipped in Chef 51 | and ChefDK (which is often driven by bugs and test failures that need 52 | to be addressed before those versions are considered stable enough to 53 | be shipped on all platforms). 54 | 55 | ## Copyright 56 | 57 | This work is in the public domain. In jurisdictions that do not allow for this, 58 | this work is available under CC0. To the extent possible under law, the person 59 | who associated CC0 with this work has waived all copyright and related or 60 | neighboring rights to this work. 61 | 62 | -------------------------------------------------------------------------------- /rfc037-chef-ohai-version-metadata.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 37 3 | Title: Add chef and ohai versions to Cookbook metadata 4 | Author: Jon Cowie (jcowie@chef.io) 5 | Status: Final 6 | Type: Standards Track 7 | Tracking: 8 | - https://github.com/chef/chef/pull/4081 9 | - https://github.com/chef/supermarket/pull/1211 10 | --- 11 | 12 | 13 | # Add chef_version and ohai_version fields to cookbook metadata 14 | 15 | Increasingly, as momentum on Chef development continues to grow, it is necessary to release modifications to the recipe DSL or core resources which can result in backwards incompatible cookbook code that may result in cookbooks using those features breaking under old versions of chef-client. Further, it is often necessary to make these changes in minor chef-client releases rather than waiting multiple months for the next major release cycle. There is currently no way to surface this version requirement to Chef users. 16 | 17 | This RFC proposes the addition of the "chef_version" and "ohai_version" fields to cookbook metadata to indicate the required versions of chef-client and ohai needed to run that cookbook. 18 | 19 | ## Motivation 20 | 21 | As a user of chef, I want to be able to easily determine if a specific cookbook uses any features not supported by my version of chef-client or ohai, so that I don't have to diagnose mysterious errors during a chef run. 22 | 23 | ## Specification 24 | 25 | This change would require adding two additional fields to the supported list of cookbook metadata fields. These fields will be called "chef_version" and "ohai_version" 26 | 27 | This change would potentially break backwards compatibility for older versions of chef-client which would not expect the presence of that field, but I propose that the benefit gained from easily being able to surface chef-client and ohai version requirements to cookbook users in all future versions makes this worthwhile. It may also be possible to implement the addition of these fields in a backwards compatible manner. 28 | 29 | During a chef-client run, it will check these fields in all cookbooks against the currently running version of chef-client and ohai. In the event that a version requirement is not satisfied at any level of the dependency tree, the Chef run will fail with a meaningful error, for example: 30 | 31 | ```FATAL: Cookbook 'apache' depends on chef-client version >= 12.0.4, but the running chef-client version is 12.0.3. Exiting.``` 32 | 33 | ## Copyright 34 | 35 | This work is in the public domain. In jurisdictions that do not allow for this, this work is available under CC0. To the extent possible under law, the person who associated CC0 with this work has waived all copyright and related or neighboring rights to this work. 36 | -------------------------------------------------------------------------------- /rfc039-event-handler-dsl.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 39 3 | Title: Recipe DSL method for event handler hooks 4 | Author: Ranjib Dey (ranjib@linux.com) 5 | Status: Final 6 | Type: Standards Track 7 | --- 8 | 9 | 10 | # Recipe DSL method for event handler hooks 11 | 12 | Allow cookbook authors to easily add custom logic on Chef events. 13 | 14 | 15 | ## Motivation 16 | 17 | Chef has an extensive event [dispatch mechanism](https://github.com/chef/chef/blob/master/lib/chef/event_dispatch/base.rb). 18 | But incorporating some custom logic against any of the events is an onerous process which involves 19 | subclassing the based event handler and adding it via the config. This RFC 20 | proposes a recipe DSL method to ease this. For new chef users this will reduce 21 | the entry barrier. 22 | 23 | ## Specification 24 | 25 | Currently chef client sets up couple of default handlers (doc, base) during 26 | initialization. An additional empty event handler (a subclass 27 | of the base handler without any custom logic) can be added alongside the 28 | existing handlers which will used as a placeholder for user specific hooks. 29 | 30 | A top level (::Chef) method will be introduced (`event_handler`) to wrap the 31 | main event handler DSL (`on`). Users can tap into one of the event types 32 | (as specified in base dispatcher) using this DSL to execute their custom logic. 33 | 34 | The additional top level method(`Chef.event_handler`) will allow the handler 35 | DSL usage in and outside of recipes and also ease writing backward compatible 36 | changes for the `on` method if need be. 37 | 38 | Following is an example of sending hipchat notification on chef run failure. 39 | 40 | ```ruby 41 | Chef.event_handler do 42 | on :run_failed do |exception| 43 | hipchat_notify exception.message 44 | end 45 | end 46 | ``` 47 | 48 | Following is another example of taking a distributed lock via etcd, to 49 | prevent concurrent chef runs in different nodes 50 | 51 | ```ruby 52 | lock_key = "#{node.chef_environment}/#{node.name}" 53 | 54 | Chef.event_handler do 55 | on :converge_start do |run_context| 56 | Etcd.lock_acquire(lock_key) 57 | end 58 | end 59 | 60 | Chef.event_handler do 61 | on :converge_complete do 62 | Etcd.lock_release(lock_key) 63 | end 64 | end 65 | ``` 66 | 67 | Following is another example of sending a hipchat alert on a key config change 68 | 69 | ```ruby 70 | Chef.event_handler do 71 | on :resource_updated do |resource, action| 72 | if resource.to_s == 'template[/etc/nginx/nginx.conf]' 73 | Helper.hipchat_message("#{resource} was updated by chef") 74 | end 75 | end 76 | end 77 | ``` 78 | 79 | ## Copyright 80 | 81 | This work is in the public domain. In jurisdictions that do not allow for this, this work is available under CC0. To the extent possible under law, the person who associated CC0 with this work has waived all copyright and related or neighboring rights to this work. 82 | -------------------------------------------------------------------------------- /rfc040-on-demand-cookbook-libraries.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 40 3 | Title: On-Demand Cookbook Libraries 4 | Author: John Keiser 5 | Status: Accepted 6 | Type: Standards Track 7 | --- 8 | 9 | # On-Demand Cookbook Libraries 10 | 11 | ## Motivation 12 | 13 | As a library cookbook writer, 14 | I want to have nested directories, 15 | So that I can organize my code and make it more readable. 16 | 17 | As a library cookbook writer, 18 | I want to control the load order of my library, 19 | So that I can have code in one file that refers to code in another file without constraining the filenames. 20 | 21 | As a library cookbook writer, 22 | I want to be able to `require` files in my library cookbook, 23 | So that I don't have to deal with the pitfalls of `require_relative` (particularly that it loads things multiple times). 24 | 25 | As a library cookbook user, 26 | I want to be able to `require` files in the library cookbooks I use, 27 | So that I can pick and choose what functionality I want to load. 28 | 29 | ## Specification 30 | 31 | When a user creates a cookbook, they can add the following directive to the metadata: 32 | 33 | ```ruby 34 | # metadata.rb 35 | name "mylibrary" 36 | version "0.0.1" 37 | eager_load_libraries false 38 | ``` 39 | 40 | If `eager_load_libraries` is false, Chef Client would instead append it to the ruby load path. This would occur in the phase where the `libraries` files of a cookbook otherwise be automatically required in alphabetical order. All recipes, libraries, and other Ruby code running in the Chef Client can then use `require 'filename'`` and it will load `cookbooks/mycookbook/libraries/filename` if present. 41 | 42 | If `eager_load_libraries` contains a list of files or globs, the library path is appended to the Ruby load path, and the listed files are loaded during the library load phase. 43 | 44 | If `eager_load_libraries` is `true` or not specified, Chef Client loads the top level of files in alphabetical order, as before. 45 | 46 | ## Rationale 47 | 48 | When a user wants to create a more complex library cookbook with multiple Ruby files, they have an issue right now: the library is automatically loaded in alphabetical order, making it hard to organize files. You can circumvent it somewhat using `require_relative` to load the other files out of order, but that may load a file twice, leading to other problems. This RFC circumvents that by requiring files to be loaded explicitly by the user or library writer using `require`, but allowing for an entry point (`default.rb`). 49 | 50 | There is also the fact that you don't necessarily *need* all the functionality in a library cookbook, and this RFC lets you pick and choose what to load. 51 | 52 | ## Copyright 53 | 54 | This work is in the public domain. In jurisdictions that do not allow for this, 55 | this work is available under CC0. To the extent possible under law, the person 56 | who associated CC0 with this work has waived all copyright and related or 57 | neighboring rights to this work. 58 | -------------------------------------------------------------------------------- /rfc043-automatic-pr-assignment.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 43 3 | Title: Automatically manage Pull Requests 4 | Author: Thom May 5 | Status: On Hold 6 | Type: Process 7 | --- 8 | 9 | # Automatically manage Pull Requests 10 | 11 | We would like to automatically assign pull requests to 12 | a suitable reviewer on submission. A reviewer would be chosen from the 13 | group of maintainers of the project, attempting to ensure that no 14 | reviewer becomes overloaded by Pull Requests. 15 | 16 | Especially for community developers, providing fast feedback ensures 17 | that the contributer stays engaged, rather than becoming discouraged by 18 | a submission languishing for an extended period of time. 19 | 20 | We would also like to capture metrics related to pull requests, such as 21 | life times, conversation length, and merge/reject/abandon ratios. 22 | 23 | ## Motivation 24 | 25 | As a Maintainer 26 | I want to ensure that PRs are handled in a timely manner 27 | by the most suitable developer. 28 | 29 | As a Maintainer 30 | I want to learn more about how we engage with our open source projects 31 | so that we can improve our processes 32 | 33 | ## Specification 34 | 35 | Each project should expose a machine readable MAINTAINERS file, allowing 36 | for discovery of maintainers by an automated process ("bot"). 37 | 38 | For each new Pull Request, the bot will automatically assign a reviewer 39 | based on the list retrieved from the maintainers file. It will attempt 40 | to ensure that no-one has too many PRs assigned to them at any one time. 41 | 42 | Any reviewer must be able to place themselves on vacation, which 43 | would prevent the bot assigning any PRs to them. 44 | 45 | A list of file paths will be associated with each component so that the 46 | bot can correctly choose to use either a subsystem maintainer or a core 47 | maintainer, prefering the most specific possible. 48 | 49 | If the reviewer is not able to help, they can choose to ask the bot to 50 | assign a new reviewer, or they can reassign the PR themselves. 51 | 52 | Once a Pull Request is closed, the bot will record a set of metrics 53 | related to the PR. 54 | 55 | ## References 56 | 57 | * [Rust's Infrastructure](http://huonw.github.io/blog/2015/03/rust-infrastructure-can-be-your-infrastructure/) 58 | 59 | ## Copyright 60 | 61 | This work is in the public domain. In jurisdictions that do not allow for this, 62 | this work is available under CC0. To the extent possible under law, the person 63 | who associated CC0 with this work has waived all copyright and related or 64 | neighboring rights to this work. 65 | -------------------------------------------------------------------------------- /rfc046-ohai-cloud-network.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 46 3 | Title: Enhanced Ohai Network Support 4 | Author: Matt Ray 5 | Status: Accepted 6 | Type: Standards Track 7 | --- 8 | 9 | # Enhanced Ohai Network Support 10 | 11 | The Ohai `cloud` plugin pushes information into `private_ips` and `public_ips`, but if networks have an alternate name they are overlooked. In EC2, HP and Rackspace for example, `local_ipv4` is mapped to `cloud.private_ipv4`, which is likely to be incorrect in some cases. Additional network data may be available from the metadata server (ec2, hp, openstack) but this should be confirmed and normalized within `cloud`. 12 | 13 | This was previously discussed internally at Chef at http://wiki.corp.opscode.com/display/CORP/RFC+Generalized+Network+Configuration+Specification+for+Knife+Cloud+Plugins 14 | 15 | ## OpenStack 16 | 17 | The Ohai `cloud` plugin is populated by cloud-specific code, but it generally pushes `local` attributes into `private` and anything else gets pushed into a list of additional `private_ips` (ie. `node['openstack']['local_ipv4']` becomes `['cloud']['local_ipv4']` and `['cloud']'['private_ips'][0]`). The mapping of values from the API into the existing cloud attribute namespaces should be checked for validity. 18 | 19 | ## Proposal 20 | 21 | Since `public` and `private` may not even be applicable (but are almost definitely expected by many current users, so may require longterm deprecation), the proposal is made to add an additional `networks` attribute with all of the node's networks embedded within. This allows new attributes without removing existing attributes and minimizes namespace collisions. 22 | 23 | * `node['cloud']['networks']`, the keys as NAMES_OR_IDS, likely to be `['public','private']`. Users could call `node['cloud']['networks'].keys` to get the list of the node's networks. 24 | * `node['cloud']['networks']['NAME_OR_ID']`, each key of `node['cloud']['networks']` is a hash of all relevant network data (ie. `node['cloud']['networks']['public']`) 25 | * `node['cloud']['networks']['NAME_OR_ID']['associated_ipv4']`, list of IPv4 addresses associated with the node on this network, likely to be singular (examples include floating IPs, Elastic IPs) 26 | * `node['cloud']['networks']['NAME_OR_ID']['associated_ipv6']`, list of IPv6 addresses associated with the node on this network, likely to be singular (examples include floating IPs, Elastic IPs) 27 | * `node['cloud']['networks']['NAME_OR_ID']['ipv4']`, list of IPv4 addresses on this network, likely to be singular 28 | * `node['cloud']['networks']['NAME_OR_ID']['ipv6']`, list of IPv6 addresses on this network, likely to be singular 29 | * `node['cloud']['networks']['NAME_OR_ID']['hostnames']`, list of hostnames associated with this network, likely to be singular 30 | 31 | ## Copyright 32 | 33 | This work is in the public domain. In jurisdictions that do not allow for this, 34 | this work is available under CC0. To the extent possible under law, the person 35 | who associated CC0 with this work has waived all copyright and related or 36 | neighboring rights to this work. 37 | -------------------------------------------------------------------------------- /rfc048-github-issues-workflow.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 48 3 | Title: Chef GitHub Issues Workflow 4 | Author: Serdar Sutay 5 | Author: Thom May 6 | Status: Accepted 7 | Type: Process 8 | --- 9 | 10 | # Chef GitHub Issues Workflow 11 | 12 | This RFC codifies the workflow Chef uses to track bug reports and contributions using [GitHub Issues](https://github.com/chef/chef/issues). 13 | The terms and policies used in this workflow are defined by [RFC 30](https://github.com/chef/chef-rfc/blob/master/rfc030-maintenance-policy.md). 14 | 15 | ## Terms 16 | 17 | In the context of this document below terms are used: 18 | 19 | * **Chef Users:** End users of Chef who participate in this workflow by filing **issues**. 20 | * **Contributors:** Users of Chef who would like to improve Chef. They participate in this workflow by submitting **contributions** to Chef. 21 | * **Chef Maintainers:** Developers of Chef who are responsible for one or more **subcomponents**. 22 | * **Lieutenants:** Developers of Chef who lead the maintenance of a subcomponent. 23 | * **Issue**: A filed **GitHub Issue** which can be a bug report, feature request, style change request. 24 | * **Contribution**: A filed **GitHub Pull Request** (PR). 25 | * **Subcomponents**: A sub-area of Chef project which is lead by a **Lieutenant** and a set of **maintainers**. 26 | 27 | ## Goals 28 | 29 | Everyone can: 30 | 31 | * Make contributions in a timely and efficient manner 32 | 33 | Chef Users can: 34 | 35 | * Be aware of the cause & the next steps for the issues they have filed. 36 | 37 | Contributors can: 38 | 39 | * Identify the state of their contribution. 40 | 41 | Chef Maintainers can: 42 | 43 | * See the list of contributions they need to review in a single page. 44 | * See the list of issues they need to investigate in a single page. 45 | 46 | ## Workflow 47 | 48 | ![Chef GitHub Issues Workflow](./support/rfc048-GithubIssuesWorkflow.png) 49 | 50 | 51 | ## Notes 52 | 53 | ### Common Steps for Issues & PRs 54 | 55 | The first step of Chef GitHub Issues Workflow is to identify the subcomponent for which the issue or PR belongs to. Once the subcomponent is identified, the rest of the workflow is the responsibility of the maintainers of the identified subcomponent. 56 | 57 | ### Issues Workflow 58 | 59 | The issues workflow can be broken down into these high level steps: 60 | 61 | 1. Understand the issue and determine the resolution. 62 | 1. Identify the major version the issue should be fixed in. 63 | 1. Label the issue to indicate completeness of **Triage** process. 64 | 65 | Any code or contributions associated with the issue will follow the 66 | contribution workflow documented below. 67 | 68 | #### Rules 69 | 70 | * If an issue is not commented on for more than a year, the issue is retired by closing. 71 | 72 | ### Contribution Workflow 73 | 74 | The contribution workflow can be broken down into these high level steps: 75 | 76 | 1. Maintainers check the contribution and give **:+1:** if the code is looking good, or leave a comment that clearly identifies what is needed for the contribution to move forward. 77 | 1. At their discretion, the reviewer may choose to complete a contribution by writing tests. This can be a fantastic mentoring opportunity for our community. 78 | 1. Once at least two maintainers **:+1:** a PR, the last reviewer should: 79 | * If clean up, such as a Changelog entry or a rebase, is required, mark the PR with the `Ready to Merge` label. 80 | * If no further work is required, merge the PR. 81 | 1. PRs marked with `Ready to Merge` will be merged by maintainers of the subcomponent after including the required documentation updates. 82 | 1. `Waiting for Contributor Response` label indicates that an action is needed from the contributor. 83 | 1. `Needs Maintainer Review` label indicates that an action is needed from Chef maintainers. 84 | 85 | #### Rules 86 | 87 | * PRs labeled with `Waiting for Contributor Response` and not updated for more than a month are labelled as `Incomplete Contribution`. 88 | * PRs labeled with `Incomplete Contribution` for 6 months are closed. 89 | * PRs labeled with `Needs Maintainer Review` and not reviewed for 2 weeks escalate to the Lieutenants of the subcomponent. 90 | * PRs labeled with `Ready to Merge` and not merged for 2 weeks escalate to the Lieutenants of the subcomponent. 91 | 92 | ## Queries 93 | 94 | * List of PRs that need review for a subcomponent: 95 | * Search Query: `is:open is:pr label:"Needs Maintainer Review" label: "subcomponent_name"` 96 | * **TODO** Add link to the query 97 | * List of Issues that need investigation for a subcomponent: 98 | * Search Query: `is:open is:issue label:"subcomponent_name" -label:Bug -label:Enhancement -label:"Tech Cleanup"` 99 | * **TODO** Add link to the query 100 | 101 | ## Copyright 102 | 103 | This work is in the public domain. In jurisdictions that do not allow for this, 104 | this work is available under CC0. To the extent possible under law, the person 105 | who associated CC0 with this work has waived all copyright and related or 106 | neighboring rights to this work. 107 | -------------------------------------------------------------------------------- /rfc049-track-rfcs.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 49 3 | Title: Tracking for Standards Track RFCs 4 | Author: John Keiser 5 | Status: Accepted 6 | Type: Process 7 | --- 8 | 9 | # Tracking for Standards Track RFCs 10 | 11 | Standards Track RFCs are intended for implementation. This proposal aims to 12 | make it easier to tell when an RFC is implemented or withdrawn, or what its 13 | implementation status is. 14 | 15 | ## Motivation 16 | 17 | As a Chef Contributor, 18 | I want to know whether an RFC is actually being worked on, 19 | so that I can decide whether to wait, write it myself, or write a replacement RFC. 20 | 21 | As a Chef Contributor, 22 | I want to know whether an RFC has become withdrawn, 23 | So that I can decide whether to find a new owner for the subject. 24 | 25 | ## Specification 26 | 27 | ### Tracking Metadata Field 28 | 29 | RFCs will now include a metadata field called Tracking, which will be a list of URLs to github issues on the relevant repositories where the feature is tracked. 30 | 31 | For example, metadata might look like this: 32 | 33 | ```yaml 34 | --- 35 | RFC: XXX 36 | Author: Daniel DeLeo 37 | Status: Final 38 | Type: Standards Track 39 | Chef-Version: 12.0 40 | Tracking: 41 | - https://github.com/chef/chef/issues/12345 42 | --- 43 | ``` 44 | 45 | ALL accepted Standards Track RFCs will have: 46 | 47 | - Status of Accepted or Final 48 | - Tracking URLs containing at a minimum a Github issue (unless it is an old RFC with Final status, in which case 49 | Tracking URLs are optional) 50 | - Chef-Version (if Final) 51 | 52 | ### RFC "Withdrawn" status 53 | 54 | When the author of an RFC is no longer willing to work on it and 55 | no one has stepped up to do it--the RFC is updated to reflect that fact with the 56 | Withdrawn status as documented in RFC-00. If someone else wants to step back up, they will need to 57 | re-present the RFC and have it Accepted again. 58 | 59 | ### RFC Acceptance Process Modification 60 | 61 | When a Standards Track RFC is accepted, we will do all the normal things we do, 62 | *plus* file a github issue for implementation (or link to the existing issue or PR), 63 | and mark the Tracking field with that URL. 64 | 65 | ### Finalization 66 | 67 | When the implementation issue is resolved as fixed, we mark the RFC Final (or add 68 | other issues tracking the remaining work) and mark the Chef-Version in which it 69 | was shipped. Issue URLs remain on the RFCs for historical purposes. 70 | 71 | ### Existing RFCs 72 | 73 | All existing Accepted Standards Track RFCs will either be marked Final or have 74 | Tracking attached to them. The implementer of a specific RFC is responsible for submitting a PR to mark it as final. 75 | They may optionally be marked Withdrawn if they are no longer going to be worked on. 76 | 77 | RFC editors are authorized to accept Pull Requests to change the status of an RFC from "Accepted" to "Final" without the need for explicit approval from the project lead. 78 | 79 | ## Copyright 80 | 81 | This work is in the public domain. In jurisdictions that do not allow for this, 82 | this work is available under CC0. To the extent possible under law, the person 83 | who associated CC0 with this work has waived all copyright and related or 84 | neighboring rights to this work. 85 | -------------------------------------------------------------------------------- /rfc050-resource-actions.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 50 3 | Title: Resource Actions 4 | Author: John Keiser 5 | Status: Final 6 | Type: Standards Track 7 | --- 8 | 9 | # Resource Actions 10 | 11 | In this proposal, we allow actions to be specified as recipes, directly in resources. 12 | 13 | ## Motivation 14 | 15 | As a Chef user, 16 | I want to be able to write actions in resources, 17 | so that I don't have to learn and reason about `Provider`s (less friction). 18 | 19 | As a Chef user, 20 | I want to be able to write actions in resources, 21 | so that I don't have to switch contexts to understand what resources do. 22 | 23 | As a Chef user, 24 | I want actions to be specified as recipes by default, 25 | so that I can use concepts I already know to create good test-and-set resources. 26 | 27 | ## Specification 28 | 29 | To create an action on a resource, users specify `action do ... end`. 30 | The recipe in between the do ... end block will be run when the action is 31 | performed. 32 | 33 | ```ruby 34 | class MyResource < Chef::Resource::LWRPBase 35 | attribute :path, name_attribute: true 36 | attribute :content 37 | attribute :mode 38 | 39 | action :create do 40 | ruby_block "Update content of #{path}" do 41 | only_if { content != IO.read(path) } 42 | block { IO.write(path, content) } 43 | end 44 | 45 | execute "Update mode of #{path}" do 46 | not_if { File.stat(path).mode == mode } 47 | command "chmod #{mode} #{path}" 48 | end 49 | end 50 | end 51 | ``` 52 | 53 | There is no change to providers or the way we run actions. This is just a way 54 | of defining a provider without having to type or think about the word. Providers 55 | do not go away, so much as become a secondary concept, a sort of house for the 56 | primary concept of actions. 57 | 58 | `action` will work for any resource extending from `Chef::Resource`. 59 | 60 | ### Action details 61 | 62 | #### Action recipe execution 63 | 64 | The action recipe works like a Chef run, in that it is an isolated resource 65 | collection and runs actions and notifications the same way as a top level Chef 66 | run. 67 | 68 | - The entire action recipe is compiled (just like a normal recipe) before 69 | converging. 70 | - This compile happens when the action is *run*, not when the parent resource 71 | is declared. 72 | - Delayed and immediate notifications are local to the action. 73 | 74 | This is equivalent to what `use_inline_resources` in an LWRP does, and we will 75 | keep them orthogonal as much as possible. 76 | 77 | #### Action composition and inheritance 78 | 79 | If the parent class's action is defined using `action`, you may call `super()` 80 | to call the parent class's version of the current action. 81 | 82 | ```ruby 83 | class MyFile < Chef::Resource::File 84 | action :create do 85 | puts "I am a file yo" 86 | super() 87 | end 88 | end 89 | ``` 90 | 91 | ## Changes to existing things 92 | 93 | ### Resource 94 | 95 | We add the following public API to `Resource`: 96 | 97 | - `self.action(action, class: nil, &block)`: creates a handler for the given action 98 | 99 | And modify the following: 100 | 101 | - `allowed_actions`: defaults to all actions defined by `action`, including any 102 | actions from superclasses. 103 | - `default_action`: defaults to the first defined `action` in the class or 104 | superclasses, with the exception of `:nothing`. 105 | 106 | Being defined by the `action` keyword, this is backwards compatible: neither of 107 | these definitions change anything about resources that have providers. 108 | 109 | ## Copyright 110 | 111 | This work is in the public domain. In jurisdictions that do not allow for this, 112 | this work is available under CC0. To the extent possible under law, the person 113 | who associated CC0 with this work has waived all copyright and related or 114 | neighboring rights to this work. 115 | -------------------------------------------------------------------------------- /rfc051-telemetry.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 51 3 | Title: Chef Telemetry 4 | Author: Ranjib Dey 5 | Status: On Hold 6 | Type: Standards Track 7 | --- 8 | 9 | # Chef telemetry 10 | 11 | ## Motivation 12 | 13 | As a chef user and developer 14 | I want an easy way to get chef run performance data 15 | so that I can identify areas that can be optimized 16 | 17 | As we automate more things with chef and control more system resources, 18 | chef run time increases, and the chef client process consumes more memory and cpu. 19 | As a configuration management system, it is important that a chef run 20 | does not impact the underlying host performance. Over the last few years 21 | Chef community has shared a number of optimization techniques. Aim of this 22 | RFC is to facilitate some of those common patterns by providing a robust 23 | telemetry system in core chef. If configured, the telemetry system will give users fine 24 | grained metrics about chef run that can be used to find out 25 | performance hiccups. This will also help users quantify how a chef 26 | run impacts the underlying system. 27 | 28 | ## Specification 29 | 30 | Telemetry module will provide following metrics: 31 | 32 | - Time spent on key chef run milestones: How long does the chef run take for each stage? Telemetry system 33 | will declare a subset of the current events as major milestones, these are: run_start, 34 | ohai_completed, node_load_completed, cookbook_resolution_complete, converge_start, 35 | converge_complete, run_completed/failed. Metrics will be captured during these milestones via event handlers. 36 | This can be used to estimate time spent on cookbook sync, compilation 37 | convergence phase etc. 38 | 39 | - Time spent on individual resource & recipe convergence. This information is already available 40 | using the API, telemetry system will just consolidate them, along side the other metrics. 41 | 42 | - GC related data. Ruby's internal memory usage obtained from 43 | GC.stat, captured during the chef run milestones. 44 | 45 | Telemetry system will also let users define their custom metrics that can be computed 46 | during these milestones (like total chef client process memory consumption from /proc/PID), 47 | This will be offered via Chef class DSL. This will also be the recommended way to implement platform 48 | specific metrics. Example: 49 | 50 | ```ruby 51 | require 'sys/proctable' 52 | 53 | Chef.telemetry do |telemetry| 54 | telemetry.add_metric 'vsize' do 55 | Sys::ProcTable.ps(Process.pid).vsize 56 | end 57 | end 58 | ``` 59 | 60 | In addition to capturing these metrics, telemetry system will also provide publishing 61 | API for metrics. Telemetry system will provide two publishing mechanism out of the box. 62 | They are 63 | - node attributes: metrics will be saved as node attribute itself 64 | - statsd : To publish metrics via statsd endpoints 65 | 66 | Telemetry system can be configured via the standard chef config file or using a dedicated 67 | CLI flag for chef-client and chef-solo. It will be disabled by default. 68 | Following is an example of configuring the telemetry subsystem 69 | 70 | ```ruby 71 | 72 | enable_telemetry true 73 | 74 | config_context(:telemetry) do 75 | resource true # captures per resource execution time taken 76 | recipe true # captures per recipe execution time taken 77 | gc true # captures GC stats during main chef events 78 | process true # captures process memory stats from /proc during main chef events 79 | client_run true # captures time spent on major chef run milestones 80 | publish_using( 81 | Chef::Telemetry::Publisher::Statsd.new(host: '192.168.2.11', port: 7676), # emit data to statsd 82 | Chef::Telemetry::Publisher::NodeAttribute.new('chef-metrics') # save all metrics under node['chef-metrics'] attribute 83 | ) 84 | end 85 | 86 | ``` 87 | Example of enabling telemetry using the CLI flag 88 | 89 | ```sh 90 | chef-client --enable-telemetry 91 | chef-solo --enable-telemetry 92 | ``` 93 | 94 | Telemetry publishing API will be a single method named #publish that accept a hash that 95 | represents the metrics. `publish_using` method is used to register a metrics publisher 96 | with the telemetry system. 97 | 98 | ## Copyright 99 | 100 | This work is in the public domain. In jurisdictions that do not allow for this, 101 | this work is available under CC0. To the extent possible under law, the person 102 | who associated CC0 with this work has waived all copyright and related or 103 | neighboring rights to this work. 104 | -------------------------------------------------------------------------------- /rfc055-property-defaults.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 55 3 | Title: Property Default Value Improvements 4 | Author: John Keiser 5 | Status: Final 6 | Type: Standards Track 7 | --- 8 | 9 | # Property Default Value Improvements 10 | 11 | This RFC addresses some longstanding issues with `default` values on properties (attributes), and addresses how we will move core Chef resources over to use defaults and properties. 12 | 13 | ## Motivation 14 | 15 | As a Chef developer, 16 | I want the core resources to use `property`, 17 | So that people are cribbing off good examples. 18 | 19 | As a Chef user, 20 | I want the core resources not to actually change behavior, 21 | So that I can rely on things I've built on top of them. 22 | 23 | ## Specification 24 | 25 | ### Non-Sticky Defaults 26 | 27 | Defaults are presently *sticky*, in that the first time a property is accessed, it is stored in the instance variable: 28 | 29 | ```ruby 30 | class X < Chef::Resource::LWRPBase 31 | resource_name :x 32 | attribute :foo, default: lazy { Random.rand } 33 | end 34 | 35 | x 'blah' do 36 | puts @foo #=> nil 37 | puts foo #=> 1 38 | puts foo #=> 1 39 | puts @foo #=> 1 40 | end 41 | ``` 42 | 43 | Once a default is assigned, it is not re-evaluated. 44 | 45 | #### Frozen constants 46 | 47 | Sticky defaults create a serious issue for literals (non-lazy default values): *every instance* of a resource gets the same value. 48 | 49 | ```ruby 50 | class X < Chef::Resource::LWRPBase 51 | resource_name :x 52 | attribute :foo, default: [] 53 | end 54 | x 'a' do 55 | foo << 1 56 | foo << 2 57 | end 58 | x 'b' do 59 | # ERROR we picked up the values that got added to 'a' 60 | puts foo #=> [ 1, 2 ] 61 | end 62 | ``` 63 | 64 | To fix this, we propose freezing non-lazy default values, and not assigning them to the instance. 65 | 66 | An alternative would have been to `dup` the default value before assigning it to the instance. We didn't go this direction because it's more error-prone: dup doesn't do a deep duplication; not all objects can be dup'd, and it's a little surprising to boot. 67 | 68 | #### Backcompat break: writing to constant defaults 69 | 70 | Users may rely on this behavior to *write* to `myprop`, like this: 71 | 72 | ```ruby 73 | class Foo < Chef::Resource::LWRPBase 74 | resource_name :foo 75 | attribute :myhash, default: {} 76 | attribute :mylist, default: [] 77 | end 78 | foo 'x' do 79 | mylist << 'hi' 80 | myhash[:a] = 10 81 | end 82 | ``` 83 | 84 | This would cause `mylist << 'hi'` to fail with a message "RuntimeError: can't modify frozen Array", letting the user know that *writes* will not work. To create a mutable default value, you must use a lazy value. 85 | 86 | This will fail to work in the new world, because we are freezing the constants. This is deliberate and a bugfix; the purpose is to avoid users setting values that affect all instances. 87 | 88 | ### Validating defaults 89 | 90 | We propose that defaults be validated consistently: non-lazy defaults would be validated when the resource class is declared, and lazy defaults would be validated when they are retrieved. 91 | 92 | #### Backcompat 93 | 94 | Defaults are presently validated inconsistently: they would be validated or not validated based on the order of declaration in the property information. To wit: 95 | 96 | ```ruby 97 | # This currently does not validate, even though 10 is not a string 98 | property :a, kind_of: String, default: 10 99 | # This currently validates correctly 100 | property :b, default: 10, kind_of: String 101 | ``` 102 | 103 | For backcompat purposes, if validation of a default value fails, we will emit a deprecation warning ("you must specify defaults that pass validation"). 104 | 105 | ### Move Core resources to `default` [compatbreak w/deprecation] 106 | 107 | `default` is generally a better thing for memory pressure, and is useful for detecting whether a user has set a value or not. Currently, core Resources tend to assign property default values to the proper instance variable during `initialize`, and it is possible that subclasses may rely on this behavior. 108 | 109 | Resources *should* instead be using the property getter method, and in the future the instance variable may not even always be there. For Chef 12, we will grab the default values of any lazy arrays or hashes on initialize, and we will issue a deprecation warning for subclasses that directly use the initialized instance variable. 110 | 111 | ## Copyright 112 | 113 | This work is in the public domain. In jurisdictions that do not allow for this, 114 | this work is available under CC0. To the extent possible under law, the person 115 | who associated CC0 with this work has waived all copyright and related or 116 | neighboring rights to this work. 117 | -------------------------------------------------------------------------------- /rfc057-cookbook-quality-metrics.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 57 3 | Title: Cookbook Quality Metrics 4 | Author: Nathen Harvey 5 | Status: Accepted 6 | Type: Informational 7 | --- 8 | 9 | # Cookbook Quality Metrics 10 | 11 | The question of what makes a good cookbook has been asked since the dawn of Chef. As a community we've struggled with answering this in part because each recipe is unique to the specific requirements it is trying to meet. Allowing Supermarket users to rate cookbooks is one thing that we've tried in the past. This did not work because you simply do not have enough knowledge about the quality of a cookbook when you discover and download it from the Supermarket. Similarly, download counts cannot be trusted because of [the way some older versions of the berkshelf-api server work](https://www.chef.io/blog/2015/01/21/those-pesky-supermarket-download-counts/). 12 | 13 | The Supermarket should make it easy for anyone to find quality cookbooks. In order to do so, we must agree on some qualities that indicate whether or not a cookbook is considered to have high quality. Ideally, these qualities are objective and able to be determined automatically. These qualities should be defined and agreed on by the community. 14 | 15 | ## Motivation 16 | 17 | As a cookbook author, 18 | I want to write cookbooks that can be shared with and easily used by the community 19 | so that it is easier to get going with Chef. 20 | 21 | As a Supermarket user, 22 | I want to identify the relative quality of a given cookbook, 23 | so that I can spend less time looking for a good cookbook and more time automating. 24 | 25 | ## Specification 26 | 27 | A [Cookbook Quality Metrics](https://github.com/chef-cookbooks/cookbook-quality-metrics) system will be implemented to provide indicators of certain qualities for each cookbook. These indicators will be visible on the Supermarket. 28 | 29 | * The community will be able to collaborate on the metrics. 30 | * The community has expressed a desire for an aggregate metric to make the quality ranking easy to consume without needing to fully understand what makes up the metric. 31 | * Metrics should not be visible on the Supermarket by default until the community has had time to review the data associated with the implemented metrics. 32 | * A Supermarket user should be able to easily assess a cookbook's compliance with any given metric. 33 | 34 | We will collaborate on quality metrics in the [Cookbook Quality Metrics](https://github.com/chef-cookbooks/cookbook-quality-metrics) repository. 35 | 36 | The lifecycle of a metric will be: 37 | 38 | * *Draft* - this is a proposed metric, ready for community discussion and approval. 39 | * *Accepted* - this metric has been accepted and merged into the master branch of the [Cookbook Quality Metrics repository](https://github.com/chef-cookbooks/cookbook-quality-metrics). 40 | * *In Progress* - data for this metric is being gathered and is visible by some mechanism but not displayed on the Supermarket by default. 41 | * *Implemented* - this metric has been implemented and is visible on the Supermarket. 42 | * *Closed* - this metric has not been accepted or has been removed from the system. 43 | 44 | ### Viewing Cookbook Metrics 45 | 46 | The [Supermarket](https://supermarket.chef.io) may show some sort of aggregate score for each cookbook. 47 | 48 | Each cookbook listed on the Supermarket will have a tab or other view showing how it adheres to each quality metric. 49 | 50 | ## Copyright 51 | 52 | This work is in the public domain. In jurisdictions that do not allow for this, 53 | this work is available under CC0. To the extent possible under law, the person 54 | who associated CC0 with this work has waived all copyright and related or 55 | neighboring rights to this work. 56 | -------------------------------------------------------------------------------- /rfc058-before.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 58 3 | Title: Trigger resources prior to an action occurring 4 | Author: 5 | - John Keiser 6 | - Joe Nuspl 7 | - Wade Peacock 8 | Status: Final 9 | Type: Standards Track 10 | --- 11 | 12 | # Let users trigger another resource prior to an action happening. 13 | 14 | ## Motivation 15 | 16 | As a Chef user, 17 | I want to make one resource action a precondition for another, 18 | So that when two resources depend on each other, I can make an update succeed. 19 | 20 | As a Chef user, 21 | I want this action only to happen if the other resource *does* update, 22 | So that I don't unnecessarily run my preconditions on every single Chef run. 23 | 24 | As a Chef user, 25 | I want Chef to run me an action if a resource updates, 26 | So that I don't have to implement the resource test logic in my recipe. 27 | 28 | ## Specification 29 | 30 | We add a new :before timing which causes a notification to happen 31 | *before* the resource actually updates. If the resource will not actually update, 32 | this event does not fire. 33 | 34 | The events you can specify would become: 35 | 36 | - :before - before the resource updates, but *only* if an update will occur. 37 | - :immediately - after the resource updates, but *only* if an update occurred. 38 | - :delayed - after the resource updates, at the end of the run. 39 | 40 | ```ruby 41 | package "foo" do 42 | action :upgrade 43 | # The package upgrade will fail if we try to upgrade while it runs!!! 44 | notifies :stop, "service[blah]", :before 45 | end 46 | 47 | service "blah" do 48 | end 49 | ``` 50 | 51 | This will work for both subscribes and notifies. 52 | 53 | ### Backwards Compatibility 54 | 55 | This will only affect resources which have :before on them, and will 56 | not modify any existing resources or recipes. 57 | 58 | ### Implementation 59 | 60 | There is a tricky implementation detail here, because both the test ("is my 61 | package version lower than the latest?") and the set ("call rpm and update the 62 | package") part of a resource are both part of the action. Chef only runs one 63 | action to run at a time, and it seems ill-advised to change that without a lot 64 | of extra thinking. 65 | 66 | To get around this without breaking the model, we propose that resources with an 67 | `:before` action run a why-run test of the action and trigger off of 68 | that, before running the action for real. The flow of this resource: 69 | 70 | ```ruby 71 | package "foo" do 72 | action :upgrade 73 | notifies :stop, "service[blah]", :before 74 | end 75 | ``` 76 | 77 | The execution of the package upgrade looks like this: 78 | 79 | 1. If :before events are on the resource: 80 | a. raise an error if the resource does not support why-run. 81 | b. Turn on why-run temporarily. 82 | c. Run the action. 83 | d. Send the notification if updated_by_last_action? is true. 84 | e. Turn off why-run. 85 | 2. Run the action (for real!). 86 | 3. Send :immediate or :delayed notifications if updated_by_last_action? is true. 87 | 88 | ## Copyright 89 | 90 | This work is in the public domain. In jurisdictions that do not allow for this, 91 | this work is available under CC0. To the extent possible under law, the person 92 | who associated CC0 with this work has waived all copyright and related or 93 | neighboring rights to this work. 94 | -------------------------------------------------------------------------------- /rfc059-ohai-cookbook-segment.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 59 3 | Title: Add Ohai cookbook segment 4 | Author: Lamont Granquist 5 | Status: Accepted 6 | Type: Standards Track 7 | --- 8 | 9 | # Add Ohai cookbook segment 10 | 11 | Support Ohai plugins under an `ohai` top level directory in cookbooks. Load all 12 | Ohai plugins in all synchronized cookbooks after cookbook synchronization. 13 | 14 | ## Motivation 15 | 16 | As a Chef User, 17 | I want to have my custom Ohai plugins loaded on first bootstrap, 18 | So I don't have to run chef twice. 19 | 20 | As a Chef User, 21 | I want my Ohai plugins loaded before attributes and compile/converge mode, 22 | So I can use them without worrying about cookbook execution ordering. 23 | 24 | As a Chef User, 25 | I want my Ohai plugins synchronized with my cookbooks, 26 | So that I don't incure more unavoidable round-trips to the Chef Server. 27 | 28 | As a Chef Developer, 29 | I want Ohai plugins as a first-class object, 30 | So that I don't have to compile recipes to discover templates that drop plugins. 31 | 32 | ## Specification 33 | 34 | The "segments" of a cookbook will be extended to include an "ohai" segment. In this segment there will be plugins which are intended to be copied to the Ohai `plugin_path`. All files in this segment will be copied, recursively, maintaining directory structure. 35 | 36 | In the `Chef::RunContext::CookbookCompiler#compile` method a phase will be added after `compile_libraries` and before `compile_attributes` which will copy the Ohai plugins from the cookbook segment and will load all of the discovered plugins. 37 | 38 | The plugins will be copied from `/ohai` into `/etc/chef/ohai/cookbook-plugins/` as their top level directory (recursively). The state of the entire 39 | subdirectory tree under `/etc/chef/ohai/cookbook-plugins` will be managed fully by chef-client so that any files which are not synchronized by chef-client will be removed, so 40 | that removal of a plugin from a cookbook or removal of the cookbook from `run_list` will result in the plugin being removed on the target host. 41 | 42 | The plugins directory will work similarly to libraries and other directions in that there will be no control over the inclusion of plugins below the level of the inclusion of the cookbook itself in the `run_list`. 43 | 44 | When plugins override other plugins on loading, and in particular when cookbook plugins override core plugins, they should WARN the user. This will address the case where a user has included a custom plugin and Ohai is later extended with similar functionality in the same namespace. The custom plugin should take precedence for backwards compatibility. There should be a way to silence the warning with a DSL method added to the custom plugin. 45 | 46 | ## Copyright 47 | 48 | This work is in the public domain. In jurisdictions that do not allow for this, 49 | this work is available under CC0. To the extent possible under law, the person 50 | who associated CC0 with this work has waived all copyright and related or 51 | neighboring rights to this work. 52 | -------------------------------------------------------------------------------- /rfc060-metadata-gem-installation.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 60 3 | Title: Enable gem dependencies in cookbook metadata 4 | Author: Lamont Granquist 5 | Status: Final 6 | Type: Standards Track 7 | --- 8 | 9 | # Enable gem dependencies in cookbook metadata 10 | 11 | Support a 'gem' DSL method for cookbook metadata to create a dependency on a rubygem. The 12 | gem will be installed via `chef_gem` after all the cookbooks are synchronized but before any 13 | other cookbook loading is done. 14 | 15 | ## Motivation 16 | 17 | As a Chef User, 18 | I want to be able to use additional gems in libraries, attributes and resources, 19 | to avoid complex workarounds and double-run converges. 20 | 21 | ## Specification 22 | 23 | Allow users to specify additional gem dependencies like: 24 | 25 | ```ruby 26 | gem "poise" 27 | gem "chef-sugar" 28 | gem "chef-provisioning" 29 | ``` 30 | 31 | In the `Chef::RunContext::CookbookCompiler#compile` method a phase will be added before `compile_libraries` which will install all of the gem declarations from all of the synchronized cookbooks before any other cookbook code is compiled. 32 | 33 | The implementation will use an in-memory bundler Gemfile which is constructed against all gem statements in all cookbooks which are in the `run_list`, solved 34 | at the same time. The syntax of the 'gem' statement will support the bundler gem syntax, with the qualification that since it is compiled into metadata.json 35 | that arbitrary ruby code will be expanded at cookbook upload time. 36 | 37 | The resulting gemset bundle will be installed into the LIBPATH of the running chef-client. This may either be directly into the base ruby libraries (per current `chef_gem` behavior) or into a custom location with the LIBPATH of the chef-client extended to use that location--as an open implementation question. 38 | 39 | The normal Gemfile `requires` tag may be used by users to autoload files out of gems. 40 | 41 | ## Copyright 42 | 43 | This work is in the public domain. In jurisdictions that do not allow for this, 44 | this work is available under CC0. To the extent possible under law, the person 45 | who associated CC0 with this work has waived all copyright and related or 46 | neighboring rights to this work. 47 | -------------------------------------------------------------------------------- /rfc061-hugs.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 61 3 | Title: Hugging in the Chef Community 4 | Author: Aaron Kalin and JJ Asghar 5 | Status: Accepted 6 | Type: Informational, Process 7 | --- 8 | 9 | # Hugging in the Chef Community 10 | 11 | In order to bridge the cultural gap between the US and Worldwide community the 12 | concept of hugging should be explained. 13 | 14 | ## Motivation 15 | 16 | As a Chef Community Participant, 17 | I want to express positive emotion to or for another Chef Community Participant, 18 | so that we can express our friendship physically. 19 | 20 | ## Specification 21 | 22 | Foremost, we want all community members to feel safe and welcome. This is 23 | expressed in the Chef Community Guidelines ([RFC020][rfc020]) and the Code of 24 | Conduct for our events (e.g. [ChefConf][chefconf]). When approaching another 25 | Chef Community Member that you wish to engage in a hug, you must first seek 26 | permission from the other community member by either verbally or physically 27 | indicating that you wish to hug them. 28 | 29 | An example, but not limited to, of a verbal indication for permission to hug is 30 | to ask "Can I give you a hug?" or "Can we hug?" The other party should then 31 | respond with verbal statement; for example "Yes, we can" or "Yes, you may." 32 | is a positive reaction, whereas "No, Thank you." or "No, thanks" are considered 33 | negative reactions. 34 | 35 | An example, but not limited to, of a physical indication for permission to hug 36 | is spread your arms apart from your body. The other party can indicate 37 | permission by repeating the same physical expression to provide consent. 38 | 39 | If Community member would like to express a hug, but has a limitation via 40 | a sickness or unable to use the typical hug process they may also express via 41 | other means, examples are but not limited to: 42 | - fist bumps 43 | - high fives 44 | - in the case of an illness 45 | - [elbow to elbow](https://en.wikipedia.org/wiki/Elbow_bump) 46 | - backward head nods by moving the chin upwards 47 | 48 | 49 | A Community member may signal their desire not to participate in the hug. 50 | Such signals may include, but are not limited to: 51 | - walking away 52 | - shaking ones head in a sign of "No" 53 | - verbally expressing "No, Thank you." 54 | - crossing your arms over your chest placing your right hand on your left 55 | shoulder and left hand on your right shoulder 56 | 57 | ## Copyright 58 | 59 | This work is in the public domain. In jurisdictions that do not allow for this, 60 | this work is available under CC0. To the extent possible under law, the person 61 | who associated CC0 with this work has waived all copyright and related or 62 | neighboring rights to this work. 63 | 64 | [rfc020]: https://github.com/chef/chef-rfc/blob/master/rfc020-community-guidelines.md 65 | [chefconf]: https://www.chef.io/blog/chefconfcodeofconduct/ 66 | -------------------------------------------------------------------------------- /rfc062-exit-status.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 62 3 | Title: Chef-Client Exit Codes 4 | Author: Nicholas Carpenter 5 | Status: Final 6 | Type: Standards Track 7 | --- 8 | 9 | # Chef-Client Exit Codes 10 | 11 | Signal outside tools of specific Chef-Client run status. Ability to determine results of a Chef-Client run. 12 | 13 | ## Motivation 14 | 15 | As a Chef user, 16 | I want to be able to determine when a chef-client run is rebooting the node, 17 | so that Test-Kitchen/Vagrant/any outside tool can wait for node to reboot, and continue converging. 18 | 19 | ## Specification 20 | 21 | * Chef applications (e.g. chef-client) that interpret recipes should use the specified exit codes 22 | * Chef tools (e.g. knife) should behave appropriately for the exit code, or pass it to the user 23 | 24 | ### Exit codes Reserved by Operating System 25 | 26 | * Windows- [Link](https://msdn.microsoft.com/en-us/library/windows/desktop/ms681381(v=vs.85).aspx) 27 | * Linux - [Sysexits](http://www.freebsd.org/cgi/man.cgi?query=sysexits&apropos=0&sektion=0&manpath=FreeBSD+4.3-RELEASE&format=html), [Bash Scripting](http://tldp.org/LDP/abs/html/exitcodes.html) 28 | 29 | 30 | ### Remaining Available Exit Codes 31 | 32 | All exit codes defined should be usable on all supported Chef Platforms. Also the exit codes used should be identical across platforms. That limits the total range from 1-255. Exit codes not explicitly used by Linux/Windows are listed below. There are 59 exit codes that are available on both platforms. 33 | * Any numbers below that have a strike-through are used below in the **Exit Codes in Use** section 34 | * Exit Codes Available for Chef use : 35 | * ~~35,37,40,41,42~~,43,44,45,46,47,48,49,79,81,90,91,92,93,94,95,96,97 36 | * 98,99,115,116,168,169,~172~,175,176,177,178,179,181,184,185,204,211 37 | * ~~213~~,219,227,228,235,236,237,238,239,241,242,243,244,245 38 | 39 | ### Precedence 40 | 41 | * Reboot exit codes should take precedence over Chef Execution State 42 | * Precedence within a table should be evaluated from the top down. 43 | * Example - Audit Mode Failure would only apply on a successful execution. But if the chef-run failed for any other reason, no reason to exit with audit mode. 44 | 45 | ## Exit Codes in Use 46 | 47 | #### Reboot Requirement 48 | 49 | Exit Code | Reason | Details 50 | ------------- | ------------- |----- 51 | 35 | Reboot Scheduled | Reboot has been scheduled in the run state 52 | 37 | Reboot Needed | Reboot needs to be completed 53 | 41 | Reboot Failed | Initiated Reboot failed - due to permissions or any other reason 54 | 55 | 56 | #### Chef Run State 57 | 58 | Exit Code | Reason | Details 59 | ------------- | ------------- |----- 60 | -1 | Failed execution* | Generic error during Chef execution. On Linux this will show up as 255, on Windows as -1 61 | 0 | Successful run | Any successful execution of a Chef utility should return this exit code 62 | 1 | Failed execution | Generic error during Chef execution. 63 | 2 | SIGINT received | Received an interrupt signal 64 | 3 | SIGTERM received | Received an terminate signal 65 | 42 | Audit Mode Failure | Audit mode failed, but chef converged successfully. 66 | 172 | License Acceptance | Failure accepting the Chef end user license agreement 67 | 213 | Chef upgrade | Chef has exited during a client upgrade 68 | 69 | * \*Next release should deprecate any use of this exit code. 70 | 71 | 72 | ## Extend 73 | 74 | This RFC should be able to be amended to include additional exit code functionality at a later date. Additional exit codes are assigned by pull request against this RFC as detailed in [RFC000](https://github.com/chef/chef-rfc/blob/master/rfc000-rfc-process.md#changing-an-accepted-rfc) 75 | 76 | ## Copyright 77 | 78 | This work is in the public domain. In jurisdictions that do not allow for this, 79 | this work is available under CC0. To the extent possible under law, the person 80 | who associated CC0 with this work has waived all copyright and related or 81 | neighboring rights to this work. 82 | 83 | -------------------------------------------------------------------------------- /rfc063-omnibus-chef-native-gems.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 63 3 | Title: Omnibus Chef Native Gem Additions 4 | Author: Lamont Granquist 5 | Status: Accepted 6 | Type: Standards Track 7 | Tracking: 8 | - https://github.com/chef/chef/pull/4435 9 | --- 10 | 11 | # Omnibus Chef Native Gem Additions 12 | 13 | ## Motivation 14 | 15 | As a Chef User, 16 | I want to have omnibus-chef ship with nokogiri, 17 | Because that will speed up my initial converges, and ease my pain at installing it. 18 | 19 | As a Chef User, 20 | I want to have omnibus-chef ship with popular Open Source databases, 21 | Because that will speed up my initial converges, and again ease my pain. 22 | 23 | As a Postgres Cookbook Author, 24 | I need a better way to install native gems, as the required workarounds use unstable Ruby APIs and links to the omnibus packaged OpenSSL library, which makes the cookbook very complex and brittle. 25 | 26 | 27 | ## Specification 28 | 29 | The supporting native libraries: 30 | 31 | * libxml2 32 | * libxslt 33 | * libpq 34 | * MariaDB Connector/C 35 | 36 | And the following gems: 37 | 38 | * nokogiri 39 | * pg 40 | * mysql2 41 | 42 | Will be added to the omnibus-chef distribution on all Tier #1 systems. 43 | 44 | ## Copyright 45 | 46 | This work is in the public domain. In jurisdictions that do not allow for this, 47 | this work is available under CC0. To the extent possible under law, the person 48 | who associated CC0 with this work has waived all copyright and related or 49 | neighboring rights to this work. 50 | -------------------------------------------------------------------------------- /rfc064-chefstyle.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 64 3 | Title: Chef code should have a consistent style 4 | Author: Thom May 5 | Status: Final 6 | Type: Standards Track 7 | Tracking: 8 | - https://github.com/chef/chefstyle 9 | --- 10 | 11 | # Chef code should have a consistent style 12 | 13 | There is a high cognitive load involved in switching between projects 14 | that have different or inconsistent code styles that impacts developer 15 | productivity and happiness. Chef should produce a consistent code style 16 | for its open source ruby code and apply it. 17 | 18 | ## Motivation 19 | 20 | As a developer, 21 | I want to be productive quickly in all Chef's projects, 22 | so that I can concentrate on writing code. 23 | 24 | ## Specification 25 | 26 | https://github.com/chef/chefstyle provides a rubocop configuration that 27 | is intended to be applied to chef/chef and related projects, such as 28 | chef/ohai, and chef/mixlib-\*. The community should arrive, via 29 | pull requests to `chefstyle`, at a set of style checks that can be 30 | enforced (via travis, etc) on chef community maintained ruby projects. 31 | 32 | Chefstyle, by default, disables all rubocop cops, providing a clean 33 | sheet for us to build upon. PRs to enable rules should be accompanied 34 | with a PR to chef/chef demonstrating the feasibility of enabling the 35 | rule and to allow discussion of actual changes. 36 | 37 | This style checker is not intended for use with cookbooks, which have 38 | different requirements. 39 | 40 | ## Copyright 41 | 42 | This work is in the public domain. In jurisdictions that do not allow for this, 43 | this work is available under CC0. To the extent possible under law, the person 44 | who associated CC0 with this work has waived all copyright and related or 45 | neighboring rights to this work. 46 | -------------------------------------------------------------------------------- /rfc066-compound-actions.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 66 3 | Title: Actions With Inline Resources 4 | Author: John Keiser 5 | Status: Accepted 6 | Type: Standards Track 7 | --- 8 | 9 | # Actions With Inline Resources 10 | 11 | In this proposal, we change the way in which inline resources are processed 12 | to make actions that call each other clearer. 13 | 14 | This is a backcompat break and requires a major version bump. 15 | 16 | ## Motivation 17 | 18 | As a Chef user, 19 | I want recipes defined in my actions to execute in order, 20 | So that I can predict what will happen. 21 | 22 | ## Specification 23 | 24 | At present, when inline_resources is on and one action calls another, 25 | the inner action is converged immediately: 26 | 27 | ```ruby 28 | class X < Chef::Resource 29 | resource_name :x 30 | action :outer do 31 | execute 'echo before inner' 32 | action_inner 33 | execute 'echo after inner' 34 | end 35 | action :inner do 36 | execute 'echo inner' 37 | end 38 | end 39 | 40 | x 'hi' 41 | ``` 42 | 43 | In Chef 12, the resources execute in this order: 44 | 45 | ``` 46 | Recipe: (chef-apply cookbook)::(chef-apply recipe) 47 | * x[hi] action outer 48 | * execute[echo inner] action run 49 | - execute echo inner 50 | * execute[echo before inner] action run 51 | - execute echo before inner 52 | * execute[echo after inner] action run 53 | - execute echo after inner 54 | ``` 55 | 56 | This is unintuitive any way you slice it. 57 | 58 | We suggest that the inner action simply become part of the compile phase of the outer action, and the entire resource collection is only converged once. 59 | 60 | When this RFC is implemented, the order of execution will be: 61 | 62 | ``` 63 | Recipe: (chef-apply cookbook)::(chef-apply recipe) 64 | * x[hi] action outer 65 | * execute[echo before inner] action run 66 | - execute echo before inner 67 | * execute[echo inner] action run 68 | - execute echo inner 69 | * execute[echo after inner] action run 70 | - execute echo after inner 71 | ``` 72 | 73 | ## Backwards Compatibility 74 | 75 | This will be a backwards compatibility break for all resources that call other 76 | actions and depend on the action running immediately. Thankfully, this is not 77 | super common. 78 | 79 | Here's a summary of some of the more common cases that will be affected or 80 | unaffected. None of these are *extremely* common--actions calling other actions 81 | is not endemic throughout all code--but it's common enough that many cookbooks 82 | will have the potential to be affected. 83 | 84 | ### Affected Patterns 85 | 86 | Here are some of the cases which might be adversely affected: 87 | 88 | 1. Action calls mixed with immediate checks 89 | 90 | Sometimes you depend on the effects of called action converging immediately. 91 | These cases can break: 92 | 93 | ```ruby 94 | action :recreate do 95 | action_delete 96 | if !File.exist?('/the_file') 97 | # Do something 98 | end 99 | end 100 | ``` 101 | 102 | This is generally considered an antipattern in a recipe, and it should be 103 | considered an antipattern in a resource with inline_resources as well. 104 | 105 | Note that the effect is limited to actions that declare resources; if you 106 | call an action that does its work immediately, the order of operations will 107 | not change. 108 | 109 | ### Unaffected Cases 110 | 111 | The impact is lessened because the two most common patterns for actions calling actions will not have an issue: 112 | 113 | 1. Action aliases or call chains 114 | 115 | Sometimes one action is an alias of another or sets a flag before calling 116 | another action. In these cases, the calling action does not depend at all 117 | on when the called action executes, so there's no issue: 118 | 119 | ```ruby 120 | action :purge do 121 | @purge = true 122 | action_clean 123 | end 124 | ``` 125 | 126 | Call chains--calling one action after another--will be unaffected as well. 127 | 128 | 2. Purge-then-create 129 | 130 | Some resources cannot be updated and need to be recreated. It is common to 131 | do this by calling a cleanup action before doing the rest of the job, and 132 | this will be unaffected as well: 133 | 134 | ```ruby 135 | action :recreate do 136 | action_delete 137 | file '/create_the_thing' 138 | end 139 | ``` 140 | 141 | Any method calls that do the actions *before* declaring resources or calling 142 | other recipes will be unaffected. 143 | 144 | ## Copyright 145 | 146 | This work is in the public domain. In jurisdictions that do not allow for this, 147 | this work is available under CC0. To the extent possible under law, the person 148 | who associated CC0 with this work has waived all copyright and related or 149 | neighboring rights to this work. 150 | -------------------------------------------------------------------------------- /rfc069-cookbook-adoption.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 69 3 | Title: Cookbook Adoption On Supermarket 4 | Author: Nell Shamrell-Harrington 5 | Status: Accepted 6 | Type: Process 7 | --- 8 | 9 | # Cookbook Adoption On Supermarket 10 | 11 | ## Motivation 12 | 13 | ### When a Cookbook is Up For Adoption 14 | ``` 15 | As a supermarket user, 16 | When I find a cookbook, 17 | And the cookbook is up for adoption, 18 | And the cookbook has been up for adoption for at least 6 months, 19 | Then the Supermarket team should be notified, 20 | And ownership of the cookbook should transferred to sous-chefs 21 | ``` 22 | 23 | ### When a Cookbook is NOT Up for Adoption 24 | ``` 25 | As a supermarket user, 26 | When I believe a cookbook should be transferred away from the current owner, 27 | Only in extreme cases (i.e. death of the current owner), 28 | I should open an [RFC](https://github.com/chef/chef-rfc) 29 | And request that the cookbook ownership be transferred 30 | ``` 31 | 32 | ## Specification 33 | 34 | ### When a Cookbook is Up For Adoption 35 | 36 | When a cookbook owner puts the cookbook up for adoption, that means they no 37 | longer wish to be the owner and maintainer of the cookbook. At anytime a user 38 | can click on the "Adopt Me!" button on the cookbook's page on Supermarket and 39 | the current owner of the cookbook will be notified. The owner can then transfer 40 | ownership to the user who wants it. 41 | 42 | However, sometimes cookbooks remain up for adoption for 6+ months. In this 43 | case, the cookbook ownership will be transferred the sous-chefs. This will 44 | be done manually at first but may be automated in the future. 45 | 46 | The sous-chefs will then take over responsibility for the cookbook. At their 47 | discretion, they can transfer ownership to someone else on Supermarket at any time. 48 | 49 | ### When a Cookbook is NOT Up For Adoption 50 | 51 | It is not the normal policy of Chef to transfer ownership of a cookbook to anyone 52 | else, that is left to the cookbook's current owner. See above for guidelines on 53 | when a cookbook has been placed up for adoption. 54 | 55 | We do recognize, however, that extreme circumstances do happen (i.e. death of the 56 | cookbook's current owner). In this case a community member who wishes to take 57 | ownership of the cookbook (or see ownership transferred to someone else with their 58 | consent) is welcome to file an [RFC](https://github.com/chef/chef-rfc). 59 | 60 | The RFCs will be decided on by the Chef Community on a case by case basis. 61 | 62 | ## Copyright 63 | 64 | This work is in the public domain. In jurisdictions that do not allow for this, 65 | this work is available under CC0. To the extent possible under law, the person 66 | who associated CC0 with this work has waived all copyright and related or 67 | neighboring rights to this work. 68 | -------------------------------------------------------------------------------- /rfc070-chef-upgrade.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 70 3 | Title: Chef should be able to upgrade itself 4 | Author: Thom May 5 | Status: Accepted 6 | Type: Standards Track 7 | --- 8 | 9 | # Chef should be able to upgrade itself 10 | 11 | Users should be able to automatically upgrade to the desired version of chef without having to use third party cookbooks. The upgrade should occur without affecting the normal chef client run, ensuring that a consistent state is preserved. 12 | 13 | ## Motivation 14 | 15 | ``` 16 | As an operator, I want chef versions to be consistent across my infrastructure, 17 | so that I can ensure my code works correctly 18 | ``` 19 | ``` 20 | As an operator, I want to easily and safely upgrade chef to my desired version, 21 | so that I can easily roll out new versions. 22 | ``` 23 | ``` 24 | As a developer, I want our users to get new features and bug fixes in a timely and safe manner, 25 | so that everyone's happy. 26 | ``` 27 | 28 | ## Specification 29 | 30 | At the beginning of each chef run, the client should decide whether or not to upgrade, based on configuration supplied by the administrator. 31 | 32 | If the administrator has specified a version of chef different to the one currently running, the chef client should check with an update service to ensure the specified version is available. If so, the client will download the specified version, and install it appropriately. The client run will then exit with exit code 213 to signal an upgrade has occurred as defined in RFC 62. 33 | 34 | ### Determining the desired chef version 35 | 36 | The desired chef version should be provided to the node through a new first class environment or node attribute tree, named `__chef_upgrade__`. Once RFC 45 is completed, that attribute tree will be marked as desired state, and not mutable by the node. 37 | 38 | The attribute tree will contain one mandatory attribute, `version`, and 39 | some additional attributes. Currently, we intend to support `channel` 40 | to allow the administrator to specify that they would like to consume 41 | unreleased builds. Channels are documented in [RFC 47](https://github.com/chef/chef-rfc/blob/master/rfc047-release-process.md#channels). 42 | 43 | The `version` attribute shall contain either MAJOR, MAJOR.MINOR, or 44 | MAJOR.MINOR.BUILD as documented in [RFC 47](https://github.com/chef/chef-rfc/blob/master/rfc047-release-process.md#versioning). 45 | It can also be the special string "latest", signifying that the node 46 | should always upgrade to the latest available version. 47 | 48 | ### Checking for an upgrade 49 | 50 | Currently, Chef provides an omnitruck API service that allows one to query 51 | for versions of packages. The API is [documented](https://docs.chef.io/api_omnitruck.html), 52 | and provides the ability to request various groups of versions. In 53 | future it may be desirable to provide a similar API in the Chef 54 | Server, to provide upgrades to nodes that have no external connectivity. 55 | 56 | ### Installing the upgrade 57 | 58 | The chef client will use the most appropriate mechanism to install the 59 | latest version of chef. The chef client will then exit with an appropriate 60 | error code, allowing the parent process to restart gracefully. 61 | 62 | ### Example scenario 63 | 64 | Given the environment below: 65 | ```json 66 | { 67 | "name": "production", 68 | "__chef_upgrade__": { 69 | "version": 12.5" 70 | } 71 | } 72 | ``` 73 | A chef client on an ubuntu node in the `production` environment, will make a request to omnitruck: 74 | ``` 75 | http://www.chef.io/chef/metadata?p=ubuntu&pv=14.04&m=x86_64&v=12.5 76 | ``` 77 | and receive metadata containing the latest package in the `12.5` series. 78 | Should that package be newer than the current version, chef will download 79 | the deb package, install it via `dpkg`, and end the chef run with a suitable 80 | exit code. 81 | 82 | ## Copyright 83 | 84 | This work is in the public domain. In jurisdictions that do not allow for this, 85 | this work is available under CC0. To the extent possible under law, the person 86 | who associated CC0 with this work has waived all copyright and related or 87 | neighboring rights to this work. 88 | -------------------------------------------------------------------------------- /rfc071-knife-bootstrap-client-config.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 71 3 | Title: Knife Bootstrap client Configuration 4 | Authors: Jay Mundrawala , Bryan McLellan 5 | Status: Accepted 6 | Type: Standards Track 7 | --- 8 | 9 | # Knife Bootstrap `client.rb` Configuration 10 | 11 | Knife bootstrap currently only allows a select few `client.rb` parameters 12 | to be specified during bootstrap. This RFC proposes a solution to allow users 13 | to pass bulk configuration data to `knife bootstrap` to be placed in the 14 | `client.rb` before the first chef-client run. 15 | 16 | ## Background 17 | 18 | The `knife bootstrap` command supports a small subset of possible parameters 19 | a user can configure in the `client.rb`. The chef-client cookbook provides a 20 | template that supports many more, allowing the user to configure additional 21 | options during a Chef client converge. If something you are trying to do does 22 | not fit into the template provided, you are also free to specify config files 23 | in a `client.d` folder that will automatically be loaded. However, because 24 | the chef-client cookbook is run along with the rest of the run list on the 25 | first run, your settings do not take effect until the second chef-client 26 | run. 27 | 28 | ## Motivation 29 | 30 | As a Chef user, 31 | I want to be able to configure chef-client with options that aren't supported by knife bootstrap, 32 | so that I do not have to maintain a fork of the bootstrap template, 33 | or so that I do not have to learn about bootstrap templates at all, 34 | or so that I don't have to make two chef-client runs on bootstrap to apply and use my configuration file. 35 | 36 | As a Chef developer, 37 | I want the user to have a generic way to pass custom client configuration file, 38 | so that I don't have the maintenance cost of additional bootstrap arguments for new features 39 | 40 | ## Specification 41 | 42 | ### Append Config Files From `client.d` 43 | 44 | The `chef-client` cookbook adds a block to load all `.rb` files in 45 | the `client.d` folder. The proposal here is to do the same thing. 46 | Knife bootstrap will take a `client.d` folder, by default looking 47 | the chef repo under `bootstrap`, optionally overwritable with a 48 | `knife.rb` configuration parameter `client_d_path`. The files 49 | will be loaded in alphabetical order. Knife will still sync all files 50 | under `client.d`, however only top-level files will the automatically 51 | loaded. The block to do this would look something like: 52 | 53 | ```ruby 54 | Dir.glob("/etc/chef/client.d/*.rb").sort.each do |conf| 55 | Chef::Config.from_file(conf) 56 | end 57 | ``` 58 | 59 | #### Example 60 | 61 | For this example, consider we want to configure Ohai's hostname plugin. 62 | The execution of this plugin will determine the node name that will be 63 | assigned to the node we are bootstraping, so it needs to be correct on 64 | the first run. 65 | 66 | We store the `ohai_config.rb` file in the Chef repo on our workstation: 67 | 68 | ```ruby 69 | # chef-repo/bootstrap/client.d/ohai_config.rb 70 | 71 | ohai.plugin[:hostname][:fqdn_using] = [ :hostname, :nis, :dns ] 72 | ``` 73 | 74 | ```ruby 75 | # chef-repo/bootstrap/client.d/ohai_plugins/custom_plugin.rb 76 | 77 | # My custom ohai plugin 78 | ``` 79 | 80 | Next we bootstrap the node: 81 | 82 | knife bootstrap 10.0.0.100 -x chefuser -P oneofus 83 | 84 | This generates the following `client.rb` and copies it to the box, 85 | along with all the contents in our chef repo's `client.d` directory: 86 | 87 | ```ruby 88 | # /etc/chef/client.rb 89 | 90 | log_level :info 91 | log_location STDOUT 92 | chef_server_url "https://api.chef.io/organizations/oneofus" 93 | ohai.plugin_path = "/etc/chef/client.d/ohai_plugins" 94 | 95 | Dir.glob("/etc/chef/client.d/*.rb").sort.each do |conf| 96 | Chef::Config.from_file(conf) 97 | end 98 | ``` 99 | 100 | ```ruby 101 | # /etc/chef/client.d/ohai_config.rb 102 | 103 | ohai.plugin[:hostname][:fqdn_using] = [ :hostname, :nis, :dns ] 104 | ``` 105 | 106 | ```ruby 107 | # /etc/chef/client.d/ohai_plugins/custom_plugin.rb 108 | 109 | # My custom ohai plugin 110 | ``` 111 | 112 | Now, when chef-client runs on the box, our configurations to 113 | Ohai's hostname plugin will be loaded before Ohai runs, allowing 114 | the first Chef run to get the correct hostname. 115 | 116 | Taking a look under `/etc/chef`, we should see something like: 117 | 118 | [vagrant@localhost ~]$ tree /etc/chef/ 119 | /etc/chef/ 120 | ├── client.d 121 | │   ├── ohai_config.rb 122 | │   └── ohai_plugins 123 | │   └── custom_plugin.rb 124 | ├── client.pem 125 | ├── client.rb 126 | ├── first-boot.json 127 | ├── trusted_certs 128 | │   └── localhost.crt 129 | └── validation.pem 130 | 131 | ## Copyright 132 | 133 | This work is in the public domain. In jurisdictions that do not allow for this, 134 | this work is available under CC0. To the extent possible under law, the person 135 | who associated CC0 with this work has waived all copyright and related or 136 | neighboring rights to this work. 137 | 138 | -------------------------------------------------------------------------------- /rfc072-artifact-yanking.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 72 3 | Title: Cookbook and Cookbook Version Yanking Policy 4 | Author: Nell Shamrell-Harrington 5 | Status: Accepted 6 | Type: Process 7 | --- 8 | 9 | # Cookbook and Cookbook Version Yanking Policy 10 | 11 | ## Motivation 12 | 13 | As a Supermarket User 14 | 15 | When I download an artifact from Supermarket 16 | 17 | And I depend on that artifact 18 | 19 | I do NOT want that artifact to be removed from Supermarket 20 | 21 | As a artifact author or collaborator 22 | 23 | When I upload an artifact to Supermarket 24 | 25 | And something is wrong with the artifact 26 | 27 | I want a way to hide it from the Supermarket UI 28 | 29 | And from the /universe endpoint 30 | 31 | ## Specification 32 | 33 | Currently, a Supermarket artifact author cannot remove a cookbook version from Supermarket without contacting the Supermarket admins. 34 | 35 | A cookbook author CAN remove a cookbook completely from Supermarket. 36 | 37 | The problem is when another user is depending on a cookbook version (or other future Supermarket artifact) and it is removed from Supermarket, that user's Chef setups could break. Additionally, if someone were to accidentally upload security credentials (as happens from time to time with uploads to Supermarket) and yank the cookbook or cookbook version from Supermarket, it could provide a false sense of security. Once a cookbook version has been uploaded to Supermarket, it can be downloaded or copied within seconds. It is far better to invalidate the security credentials. 38 | 39 | Here's my proposal: 40 | 41 | When a user unshares a cookbook from Supermarket (such as through $knife cookbook site unshare), Supermarket will assign the cookbook version a flag 42 | 43 | When a cookbook version has that flag, it will be hidden from both the Supermarket UI and the /universe endpoint 44 | 45 | It will not, however, be completely deleted from the Supermarket artifact store. 46 | 47 | If someone depends on the cookbook version, they will still be able to download and access it 48 | 49 | But it will be harder for a new user of the cookbook version to find the unshared version. 50 | 51 | The user who unshares the cookbook will be notified of this, along with a message that if they REALLY need it deleted to contact the Supermarket admins 52 | 53 | ## Downstream Impact 54 | 55 | Ideally this would not affect Berkshelf...but it must be tested thoroughly before deployment. 56 | 57 | ## Copyright 58 | 59 | This work is in the public domain. In jurisdictions that do not allow for this, 60 | this work is available under CC0. To the extent possible under law, the person 61 | who associated CC0 with this work has waived all copyright and related or 62 | neighboring rights to this work. 63 | -------------------------------------------------------------------------------- /rfc073-meetbot.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 73 3 | Title: Enabling meetbot for Chef IRC Community meetings. 4 | Author: JJ Asghar 5 | Status: On Hold 6 | Type: Process 7 | --- 8 | 9 | # Enabling meetbot for Chef IRC Community meetings. 10 | 11 | We will enable [meetbot][meetbot] for the Chef IRC Community Meetings. 12 | Shifting responsibility for taking meeting notes from the designated secretary 13 | to software allows the person acting as the secretary to instead participate 14 | fully in the discussion. 15 | 16 | ## Motivation 17 | 18 | As a community member of Chef, 19 | I want the meeting notes to be automated, 20 | so that the secretary can participate fully in the discussion. 21 | 22 | ## Specification 23 | 24 | The OpenStack community has constant IRC meetings. They leverage something called 25 | [meetbot][meetbot] to help take notes for them. There would be not 26 | only increased productivity and communication but a more natural flow to the 27 | conversations. There are built in commands that help track `#actions` or `#links` 28 | that output an executive summary so you can see in a quick fashion what was discussed. 29 | 30 | There will be a small learning curve to learn to use this bot, but the majority 31 | the commands can be used are: 32 | 33 | ``` 34 | Admin commands (for only Chairs): 35 | 36 | #startmeeting - Start a meeting. You are designated the owner (and have permanent chair powers). 37 | #endmeeting - End the meeting. Must be called by a chair. 38 | #topic - Set a new topic. 39 | #agreed - Document an agreement in the minutes. 40 | 41 | Commands for Everyone: 42 | 43 | #info - Add an info item to the minutes. People should liberally use this for important things they say, so that they can be logged in the minutes. 44 | #action - Document an action item in the minutes. Include any nicknames in the line, and the item will be assigned to them. (nicknames are case-sensitive) 45 | #idea - Add an idea to the minutes. 46 | #help - Add a "Call for Help" to the minutes. Use this command when you need to recruit someone to do a task. (Counter-intuitively, this doesn't provide help on the bot) 47 | #link - Add a link to the meeting minutes. The link should be the first non-command on the line, other commentary after the link is OK. Links beginning with http:// and a few other protocols are automatically detected. 48 | ``` 49 | 50 | An example of the [executive summary is here][executive_summary]. 51 | 52 | This will require Chef Inc, to host the IRC bot someplace so it can track our meetings, 53 | but there is no reason why we couldn't export the logs to GitHub after the fact 54 | and have it consistent with the previous meetings. This will allow for the least 55 | amount of friction for adoption. 56 | 57 | ## Copyright 58 | 59 | This work is in the public domain. In jurisdictions that do not allow for this, 60 | this work is available under CC0. To the extent possible under law, the person 61 | who associated CC0 with this work has waived all copyright and related or 62 | neighboring rights to this work. 63 | 64 | [meetbot]: https://wiki.debian.org/MeetBot 65 | [openstack_meetbot]: http://docs.openstack.org/infra/system-config/irc.html#meetbot 66 | [executive_summary]: http://eavesdrop.openstack.org/meetings/nova/2015/nova.2015-02-19-14.00.html 67 | -------------------------------------------------------------------------------- /rfc076-reversion-ohai.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 76 3 | Title: Change Ohai version numbers to match Chef 4 | Author: Thom May 5 | Status: Accepted 6 | Type: Process 7 | --- 8 | 9 | # Change Ohai version numbers to match Chef 10 | 11 | In general, Ohai and Chef are released together, and their functionality 12 | is interdependent. It would be much simpler to reason about how 13 | functionality added to either would affect the other if their version 14 | numbers were aligned. 15 | 16 | ## Motivation 17 | 18 | As a developer, 19 | I want to use the correct version of Ohai, 20 | so that releases of Chef and Ohai work properly. 21 | 22 | ## Specification 23 | 24 | Ohai will be renumbered to 12.x.y, where x and y are the current development 25 | minor and patch versions of Chef. Chef would then have a equality version 26 | pin to Ohai of "= 12.x.y", and Ohai would have a similar equality 27 | pin to ChefConfig. 28 | 29 | The version bot currently used to automatically change version numbers 30 | for Chef would also be used to update Ohai's version number when Chef is 31 | bumped. 32 | 33 | The change from 8 to 12 would not be considered a 34 | major version bump for API impact considerations, so no deprecated 35 | functionality would be removed. 36 | 37 | ## Downstream Impact 38 | 39 | Any library which version pins to Ohai < 9.0 would need to be updated to 40 | be < 13.0. 41 | 42 | ## Copyright 43 | 44 | This work is in the public domain. In jurisdictions that do not allow for this, 45 | this work is available under CC0. To the extent possible under law, the person 46 | who associated CC0 with this work has waived all copyright and related or 47 | neighboring rights to this work. 48 | -------------------------------------------------------------------------------- /rfc078-supermarket-prefix.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 78 3 | Title: Supermarket Prefix Reservation 4 | Author: Noah Kantrowitz 5 | Status: Accepted 6 | Type: Process 7 | --- 8 | 9 | # Supermarket Prefix Reservation 10 | 11 | While the question of explicit namespace support for Supermarket and the broader 12 | Chef ecosystem has mostly been answered, a de facto standard has emerged over 13 | the years to prefix cookbook names with the originating organization or team. 14 | In most cases these are internal, but more and more of these prefixed names are 15 | being released to the public Supermarket. 16 | 17 | This has benefits to both cookbook authors who want to make it clear a cookbook 18 | is part of their brand and thus meets their quality standards, as well as to 19 | users who can use brand-level trust to find new cookbooks to use. 20 | 21 | The downside is there is no explicit tooling built for this prefix management. 22 | Currently any user can register any unused name, possibly causing confusion as 23 | to if a cookbook is officially associated with the prefix name or not. 24 | 25 | ## Motivation 26 | 27 | As a community cookbook author, 28 | I want to maintain brand continuity, 29 | so that my cookbooks can be clearly identified. 30 | 31 | As a community cookbook consumer, 32 | I want to know when cookbooks come from trusted authors, 33 | so that I can feel confident in using new cookbooks. 34 | 35 | ## Specification 36 | 37 | A group or company will have exclusive control to prefixes registered to them. 38 | These prefixes are subject to approval by Chef Software as part of their operation 39 | of the public Supermarket application. Private deployments of Supermarket can 40 | define their own governance structure for allocating prefixes. 41 | 42 | If a prefix is registered, the user or users that are responsible for it will 43 | be the only ones allowed to register new cookbooks or tool with that prefix. 44 | The responsible user or users can authorize other users to create cookbooks in 45 | their prefix, but this requires explicit permission from the prefix holder. 46 | 47 | In the short term, prefix management can be handled ad hoc via existing cookbook 48 | rename/removal tooling in Supermarket. Established prefixes can be added to this 49 | RFC by pull request. As a reactive strategy for the time being, you will have 50 | to notify the Supermarket team of an inappropriately named cookbook by 51 | [opening a ticket](https://github.com/chef/supermarket/issues/new). 52 | 53 | In the long term, it would be good to see native functionality added to 54 | Supermarket to enable this, though care will have to be taken at that point to 55 | ensure abuse is not a problem. This could allow automatic enforcement of 56 | prefixes in the future. 57 | 58 | ## Prefixes 59 | 60 | To register a prefix, fork this repository and create a Pull Request adding 61 | your prefix and the person or organization that will be responsible for it. 62 | 63 | * `blp` - [Bloomberg](https://github.com/bloomberg) 64 | * `fb` - [Faceboook](https://github.com/facebook) 65 | * `gcp` - [googlecloudplatform](https://github.com/googlecloudplatform) 66 | * `poise` - [coderanger](https://github.com/coderanger) 67 | * `sbp` - [Schuberg Philis](https://github.com/sbp-cookbooks) 68 | * `sc` - [Sous Chefs](https://github.com/sous-chefs) 69 | * `sigsci` - [signalsciences](https://github.com/signalsciences) 70 | * `snu` - [Socrata](https://github.com/socrata-cookbooks) 71 | 72 | ## Copyright 73 | 74 | This work is in the public domain. In jurisdictions that do not allow for this, 75 | this work is available under CC0. To the extent possible under law, the person 76 | who associated CC0 with this work has waived all copyright and related or 77 | neighboring rights to this work. 78 | -------------------------------------------------------------------------------- /rfc080-dco.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 80 3 | Title: Developer Certificate of Origin (DCO) for Contributions 4 | Author: Nathen Harvey 5 | Status: Accepted 6 | Type: Process 7 | --- 8 | 9 | # Developer Certificate of Origin (DCO) for Contributions 10 | 11 | Chef's open source projects will no longer require a contributor license agreement (CLA) or corporate contributor license agreement (CCLA). A developer certificate of origin (DCO) will be required for each contribution to the projects. The DCO accomplishes the same purpose as the CLAs by indicating that developers are responsible for the code that they contribute and that they understand that the contribution is under the terms of the Apache License. This simple process is familiar to developers and more and more legal departments are willing to consider this approach as well. 12 | 13 | ## Motivation 14 | 15 | As a potential contributor to Chef's open source projects, 16 | I do not want to read, understand, and sign a contributor license agreement, 17 | so that contributing does not require unnecessary burdens. 18 | 19 | As a contributor to Chef's open source projects, 20 | I want to attest that each contribution is under the terms of the Apache License, 21 | so that it is clear that I am able to make the contribution. 22 | 23 | As a maintainer of Chef's open source projects, 24 | I want to see a developer certificate of origin in every contribution, 25 | so that it is clear that the contribution is allowed. 26 | 27 | ## Specification 28 | 29 | Effective October 1, 2016 ("the cutover date"), Chef will no longer require CLAs or CCLAs for contributions to its open source projects. Rather, Chef is adopting the developer certificate of origin ("DCO") used by several other projects and overall smart people. All commits prior to the cutover date shall fall under the CLA process and will require a signed contributor license agreement. 30 | 31 | The DCO is an attestation attached to every contribution made by every developer. In the commit message of the contribution, the developer simply adds a Signed-off-by statement and thereby agrees to the DCO, which you can find below or at [http://developercertificate.org/](http://developercertificate.org/). 32 | 33 | Developer's Certificate of Origin 1.1 34 | 35 | By making a contribution to this project, I certify that: 36 | 37 | (a) The contribution was created in whole or in part by me and I 38 | have the right to submit it under the open source license 39 | indicated in the file; or 40 | 41 | (b) The contribution is based upon previous work that, to the 42 | best of my knowledge, is covered under an appropriate open 43 | source license and I have the right under that license to 44 | submit that work with modifications, whether created in whole 45 | or in part by me, under the same open source license (unless 46 | I am permitted to submit under a different license), as 47 | Indicated in the file; or 48 | 49 | (c) The contribution was provided directly to me by some other 50 | person who certified (a), (b) or (c) and I have not modified 51 | it. 52 | 53 | (d) I understand and agree that this project and the contribution 54 | are public and that a record of the contribution (including 55 | all personal information I submit with it, including my 56 | sign-off) is maintained indefinitely and may be redistributed 57 | consistent with this project or the open source license(s) 58 | involved. 59 | 60 | ## Downstream Impact 61 | 62 | * Currybot, part of the Supermarket, will no longer be necessary. 63 | * The DCO sign-off process must be clearly documented in the contributing documents. 64 | * A small DCO bot will need to be added to each of Chef's open-source repositories. 65 | * The bot must include instructions for how to edit commits adding a `Signed-off-by` line. 66 | * A blog post and mailing list announcement will be made before the cutover. 67 | * This will have *no* impact on [the "obvious fix" rule](https://docs.chef.io/community_contributions.html#the-obvious-fix-rule). Contributions that meet these criteria will not need a DCO but should include "obvious fix" in the commit message as outlined in [the "obvious fix" policy](https://docs.chef.io/community_contributions.html#the-obvious-fix-rule). 68 | * DCO sign-off will not be required for contributions to documentation repositories (such as `chef/chef-web-docs`) or contributions that only affect documentation embedded within project repositories (such as the `docs` directory in `chef/inspec`). 69 | 70 | ## Copyright 71 | 72 | This work is in the public domain. In jurisdictions that do not allow for this, 73 | this work is available under CC0. To the extent possible under law, the person 74 | who associated CC0 with this work has waived all copyright and related or 75 | neighboring rights to this work. 76 | -------------------------------------------------------------------------------- /rfc081-release-cadence.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 81 3 | Title: Chef Release Cadence 4 | Author: Tim Smith 5 | Author: Noah Kantrowitz 6 | Status: Replaced 7 | Type: Informational 8 | Replaced-By: 86 9 | --- 10 | 11 | # Chef Release Cadence 12 | 13 | Chef follows [Semantic Versioning](https://semver.org/) for releases. Major 14 | versions (eg. 11.x -> 12.x) will include backwards-incompatible changes, minor 15 | versions (eg 12.1 -> 12.2) will include new features and bug fixes but will be 16 | backwards-compatible to the best of our ability. Patch versions are governed 17 | by [RFC 47](rfc047-release-process.md). 18 | 19 | Chef feature releases are promoted to the stable channel once per month. It is 20 | expected that this occur during the second week of the month unless 21 | circumstances intervene. Additional patch releases for a given feature release 22 | may be promoted if critical issues are found. 23 | 24 | ChefDK is released once per month. It is expected that this occur during the 25 | fourth week of the month unless circumstances intervene. 26 | 27 | Both Chef and ChefDK will prepare a release candidate before the target release 28 | date, usually in the week before but at least three business days before release. 29 | 30 | The Chef release in April of each year is a major version release, which will 31 | contain backwards-incompatible changes. A reminder notice will be sent via 32 | Discourse and Slack in March that will summarize the changes slated for the release. 33 | 34 | ## Rationale 35 | 36 | Monthly releases help ensure we get new features and minor bug fixes out to Chef 37 | users in a timely fashion while not overloading the maintainer teams. 38 | Similarly, offsetting the Chef and ChefDK releases allows the full attention of 39 | the Chef development team on each of those releases and leaves time for any 40 | potential hot fixes or follow-up. 41 | 42 | Major releases in April avoids releasing during winter holidays, summer 43 | vacations, ChefConf and Chef Summits. 44 | 45 | ## Copyright 46 | 47 | This work is in the public domain. In jurisdictions that do not allow for this, 48 | this work is available under CC0. To the extent possible under law, the person 49 | who associated CC0 with this work has waived all copyright and related or 50 | neighboring rights to this work. 51 | -------------------------------------------------------------------------------- /rfc083-audit-phase.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 83 3 | Title: Audit Segment 4 | Author: 5 | - Christoph Hartmann 6 | - Thom May 7 | Status: Accepted 8 | Type: Standards Track 9 | --- 10 | 11 | # Audit Segment 12 | 13 | Support audit and compliance checks in a technology agnostic way. 14 | 15 | ## Motivation 16 | 17 | As a cookbook author, 18 | I want to ship custom controls, 19 | so that I can ensure my nodes are compliant. 20 | 21 | As a cookbook author, 22 | I want to use the most suitable compliance library, 23 | so that I can write controls effectively. 24 | 25 | As an operator, 26 | I want to ensure that my converge happens separately from my audit, 27 | so that I have full control over my runs. 28 | 29 | 30 | ## Specification 31 | 32 | As per RFC-35, audits will be run in the `audit` phase, which occurs 33 | after the `converge` phase completes. 34 | 35 | An audit handler will be introduced to allow cookbooks to register for 36 | the audit phase. 37 | 38 | The current, Serverspec based audit mode will be migrated to a cookbook 39 | and removed from the chef-client. 40 | 41 | A cookbook may depend on other gems in the usual manner to provide 42 | functionality to audit tests. 43 | 44 | Tools will be updated to upload the `tests` directory to both 45 | supermarket and chef server. Audits can then be used both at development 46 | time with test kitchen and similar tools, and with audit mode. 47 | 48 | ## Copyright 49 | 50 | This work is in the public domain. In jurisdictions that do not allow for this, 51 | this work is available under CC0. To the extent possible under law, the person 52 | who associated CC0 with this work has waived all copyright and related or 53 | neighboring rights to this work. 54 | -------------------------------------------------------------------------------- /rfc085-remove-unused-metadata.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 85 3 | Title: Remove unused cookbook metadata 4 | Author: Thom May 5 | Status: Final 6 | Type: Standards Track 7 | --- 8 | 9 | # Remove Unused Cookbook Metadata 10 | 11 | There are a set of metadata fields that have never been really supported 12 | by Chef, and so we should remove them. 13 | 14 | ## Motivation 15 | 16 | As a community advocate, 17 | I want to ensure that cookbook maintainers focus on the things that 18 | matter, 19 | so that they can write better cookbooks. 20 | 21 | As a chef developer, 22 | I like removing code, 23 | so that there are fewer bugs. 24 | 25 | ## Specification 26 | 27 | Mark as deprecated and subsequently remove the `recommends`, `suggests`, 28 | `conflicts`, `replaces` and `grouping` metadata fields. 29 | 30 | ## Downstream Impact 31 | 32 | Chef Server should be updated to not serve this metadata, docs need to 33 | be updated. Also, generators such as `chef generate`, `berks cookbook` 34 | need to be updated to ensure they do not create metadata files with 35 | those fields. 36 | 37 | ## Copyright 38 | 39 | This work is in the public domain. In jurisdictions that do not allow for this, 40 | this work is available under CC0. To the extent possible under law, the person 41 | who associated CC0 with this work has waived all copyright and related or 42 | neighboring rights to this work. 43 | -------------------------------------------------------------------------------- /rfc088-mongodb-cookbook-transfer.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 88 3 | Title: Transfer mongodb cookbook on Supermarket to Sous Chefs org 4 | Author: Grant Ridder 5 | Status: Accepted 6 | Type: Informational 7 | --- 8 | 9 | # Transfer mongodb cookbook on Supermarket to Sous Chefs org 10 | 11 | ## Motivation 12 | 13 | As a user of the mongodb cookbook, 14 | I want to have the cookbook maintained and released to Supermarket, 15 | so that I can get cookbook updates for non-EOS versions of MongoDB. 16 | 17 | As a user of the mongodb cookbook, 18 | I want to have the cookbook up to date on Supermarket, 19 | so that I can install a version of MongoDB that is getting security updates. 20 | 21 | As a Sous Chef member, 22 | I want to be able to release to Supermarket, 23 | so that the community at large can consume the maintained fork. 24 | 25 | ## Specification 26 | 27 | Currently the [mongodb cookbook](https://github.com/edelight/chef-mongodb) 28 | on [Supermarket](https://supermarket.chef.io/cookbooks/mongodb) was last released 29 | on November 11, 2014. The last commit on the GitHub repository was the day prior, 30 | November 10, 2014. At the time of the writing of this draft, the repository has 31 | 70 open issues and 35 open PRs. The last comment on any issue or PR by any 32 | maintainer was by [jamesonjlee](https://github.com/edelight/chef-mongodb/pull/356) 33 | on December 9, 2014. 34 | 35 | The Sous Chefs have been maintaining a [fork](https://github.com/sous-chefs/mongodb) 36 | of the mongodb cookbook. The fork's master branch is currently 90 commits ahead 37 | of the source repository for the cookbook. The Sous Chefs have been active on the issues 38 | on the original repository and have worked to fix them in the maintained fork. 39 | 40 | Grant Ridder, on behalf of the Sous Chefs, has attempted on several occasions during 41 | November and December of 2016 to contact Markus Korn, the current owner on Supermarket, 42 | as well as Jameson Lee, a contributor on Supermarket and last committer on GitHub. 43 | Both individuals were each contacted with 2 different methods without response. At the 44 | time of the writing of this draft, the last evidence of activity for either user, in the 45 | context of the mongodb cookbook, is more than 2 years ago. 46 | 47 | The Sous Chefs would therefor request that the MongoDB cookbook on Supermarket be 48 | marked deprecated in favor of [sc-mongodb](https://github.com/sous-chefs/mongodb) 49 | on Supermarket under provisions layed out in the `When a Cookbook is NOT Up For Adoption` 50 | section of [RFC069](https://github.com/chef/chef-rfc/blob/master/rfc069-cookbook-adoption.md). 51 | 52 | ### Deprecation Process for this RFC 53 | 54 | 1. [@nathenharvey](https://github.com/nathenharvey) will reach out to 55 | [@thekorn](https://github.com/thekorn) weekly asking for a decision on 56 | the ownership of the cookbook. 57 | 1. The Sous Chefs will publish their MongoDB cookbook to the Supermarket. 58 | 1. On, or after, March 15, 2017 (3 months after this RFC was submitted), 59 | a Supermarket Administrator will mark the current MongoDB cookbook 60 | as deprecated and offer the Sous Chefs' cookbook as a suitable replacement. 61 | 1. A message will be posted to the mailing list notifying of this change and our reasoning behind it. 62 | 63 | Note: As the current owner of the cookbook, [@thekorn](https://github.com/thekorn) can 64 | accelerate or stop this timeline at any time. 65 | 66 | ## Downstream Impact 67 | 68 | Since the Sous Chef's fork is compatible with the existing cookbook on Supermarket, 69 | no downstream impact is expected. 70 | 71 | ## Copyright 72 | 73 | This work is in the public domain. In jurisdictions that do not allow for this, 74 | this work is available under CC0. To the extent possible under law, the person 75 | who associated CC0 with this work has waived all copyright and related or 76 | neighboring rights to this work. 77 | -------------------------------------------------------------------------------- /rfc090-server-http-head.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 90 3 | Title: Server HTTP HEAD 4 | Author: Jeremy Miller 5 | Status: Accepted 6 | Type: Standards Track 7 | --- 8 | 9 | # Server HTTP HEAD 10 | 11 | There is a greater resource cost than is necessary when querying the Server 12 | API named object endpoints for the existence of a single object. Currently, if 13 | checking for an object's existence, only HTTP `GET` requests are supported by 14 | the server. This means the entire object is fetched, consuming resources 15 | across the server, network and client. When viewed from a large scale 16 | perspective, this overhead can cause slow downs that can have compounding 17 | effects. 18 | 19 | ## Motivation 20 | 21 | As a Chef developer, 22 | 23 | I want to be able to write code that queries the 24 | Server for the existence of a single object via a light-weight API call 25 | and response, 26 | 27 | so that my applications can run as efficiently and as 28 | quickly as possible. 29 | 30 | ## Specification 31 | 32 | The HEAD method shall be identical to GET except that the server must not 33 | return a message-body in the response. 34 | 35 | The meta-information contained in the HTTP headers in response to a HEAD 36 | request should be identical to the information sent in response to a GET 37 | request. 38 | 39 | The HEAD HTTP verb will be added to oc_erchef and chef-zero named object 40 | endpoints such that a client http HEAD request for an object name will result 41 | in the following standard http response codes (no different than a `GET`): 42 | 43 | Code | Reason 44 | --- | --- 45 | 200 | object exists 46 | 401 | request signature is invalid 47 | 403 | requestor does not have READ on the object 48 | 404 | object does not exist 49 | 50 | example named endpoint: /nodes/NAME 51 | 52 | ## Downstream Impact 53 | 54 | In addition to `chef-server`, `chef-zero` will need this capability added so 55 | that it remains in lock-step. 56 | 57 | As an optimization and/or feature addition, several other downstream items 58 | could benefit including: Chef::ChefFS, Chef::Knife, knife-ec-backup. 59 | 60 | ## Copyright 61 | 62 | This work is in the public domain. In jurisdictions that do not allow for this, 63 | this work is available under CC0. To the extent possible under law, the person 64 | who associated CC0 with this work has waived all copyright and related or 65 | neighboring rights to this work. 66 | -------------------------------------------------------------------------------- /rfc092-dependency-update-cadence.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 92 3 | Title: Dependency Update Cadence 4 | Author: 5 | - Lamont Granquist 6 | - Jennifer Davis 7 | Status: Accepted 8 | Type: Process 9 | --- 10 | 11 | # Dependency Update Cadence 12 | 13 | This RFC describes the Ruby, Cookbook and Ecosystem support cadence as an addendum to the [Chef OSS project versioning and release policies.](https://chef.github.io/chef-rfc/rfc086-chef-oss-project-policies.html) and the [cookbook release process](https://github.com/chef-cookbooks/community_cookbook_documentation/blob/master/RELEASE_PROCESS.MD). 14 | 15 | ## Motivation 16 | 17 | As a person who writes and shares community cookbooks, 18 | I want to drop old support for old client versions and use new client versions, 19 | so that cookbook complexity can be reduced. 20 | 21 | As a person who writes and shares community cookbooks, 22 | I want to drop support for old versions of the Ruby language, 23 | so that I don't have to support ruby versions that are no longer supported by the ruby community. 24 | 25 | As a person who uses community cookbooks in my own recipes, 26 | I want to know the policy for cookbook support, 27 | so I can understand the impact of delaying updating underlying dependencies. 28 | 29 | ## Specification 30 | 31 | ### Cookbook and Ecosystem Tooling Support 32 | 33 | Chef-managed community cookbooks should support at least the last 6 months of [Chef Client](https://github.com/chef/chef/blob/master/CHANGELOG.md) versions. After 6 months, Chef-managed community cookbooks may 34 | elect to drop support for older Chef Client versions. This window does not reset on 35 | a major version release so that the prior major version track is supported for a 6 month window. Non-Chef-managed community cookbooks are encouraged to follow this policy. 36 | 37 | As an example, based on the [Chef OSS project versioning and release policies](https://chef.github.io/chef-rfc/rfc086-chef-oss-project-policies.html), in May if we release Chef Client 14.1.0, both 14.0 and 14.1 will be 38 | supported. The version of 13 release 6 months prior should be 13.8 and will still 39 | be supported so that 6 versions will be considered current (13.8 through 13.11 plus 40 | 14.0 and 14.1). At that point community cookbooks may choose to start using 13.8 41 | features and drop support for versions prior to 13.7. 42 | 43 | Tooling external to cookbooks (cookstyle, chefspec, stove, foodcritic, halite, 44 | poise-hoist, etc) is similarly encouraged to follow this policy. 45 | 46 | ### Ruby Cadence 47 | 48 | Since the Ruby language itself releases new minor versions over the Christmas holidays, the April major release of Chef Client should include the minor revision of Ruby which landed the prior Christmas. Combined with the 6 month sliding window for cookbook support that also implies that when the prior major release of the client falls off of community cookbook support that the prior minor release of Ruby will also fall off of community cookbook support (including the cookstyle gem and related tooling). 49 | 50 | The release of the new major version may be delayed if there are show stopping bugs 51 | in the released version of Ruby. We assume that 4 months will be enough time for 52 | major regressions in the core language to be addressed, but that is an external 53 | dependency. 54 | 55 | If the Ruby language version released over Christmas has a show-stopper bug then the 56 | next major Chef Client version may be released without it. It can then be included 57 | in a subsequent minor version bump. This RFC deliberately uses 'should' instead of 58 | 'must', and [RFC-034](https://github.com/chef/chef-rfc/blob/b7bd9c53bf96235f9334e65bb5848f7843c81fed/rfc034-ruby-193-eol.md#specification) 59 | allows for a minor version bump of Ruby with a minor version 60 | bump of Chef Client. Show stoppers in Ruby itself will not hold up major releases 61 | of Chef Client, and missing the major release window will not hold up bumping the 62 | Ruby version. 63 | 64 | ### Operating System Versions 65 | 66 | Each cookbook will define supported platforms along with version constraints through the use of the `supports` keyword in the metadata and README files within the cookbook. 67 | 68 | Chef-managed community cookbooks should drop support for platform versions that are no longer supported by the platform maintainers. 69 | 70 | ## Copyright 71 | 72 | This work is in the public domain. In jurisdictions that do not allow for this, 73 | this work is available under CC0. To the extent possible under law, the person 74 | who associated CC0 with this work has waived all copyright and related or 75 | neighboring rights to this work. 76 | -------------------------------------------------------------------------------- /rfc095-test-kitchen-telemetry.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 95 3 | Title: Use of telemetry in Test Kitchen 4 | Author: Thom May 5 | Status: Accepted 6 | Type: Standards Track 7 | --- 8 | 9 | # Use of telemetry in Test Kitchen 10 | 11 | This RFC is a description of Test Kitchen's implementation of RFC-94, as required in that RFC. 12 | 13 | ## What questions do we hope to answer? 14 | 15 | * What platforms do our users run kitchen on? 16 | * Which plugins are used by kitchen users? 17 | * Which bento boxes are used? 18 | * Which provisioners are used? 19 | * If a chef provisioner is used, which chef versions are installed? 20 | * Which commands are used? 21 | 22 | ## Implementation 23 | 24 | The bulk of this RFC is the description of the events, below. We 25 | envisage that a single client library will be built for all chef 26 | projects, and Kitchen will consume that to send events. That library 27 | would ensure events are sent in a non-blocking manner, and would deal 28 | with retries, session handling and opt-out. 29 | 30 | ## Events 31 | 32 | Let's examine a typical user interacting with kitchen in an existing cookbook, 33 | and enumerate the events and information that's sent. We'll elide the fields 34 | from the payload that are common to all chef telemetry systems. To ensure 35 | that we don't leak private information, drivers will only report provisioning 36 | targets when they are not specified explicitly by the user. 37 | 38 | The user performs a full test run on a Debian instance: 39 | 40 | `kitchen test default-debian-9` 41 | 42 | using the `kitchen-hyperv` driver on Windows 10, and the `debian-9-amd64` bento box. 43 | This results in the following events: 44 | 45 | ```json 46 | { 47 | "product": "test-kitchen", 48 | "session_id": "504ec380-5a75-458c-9f56-afa3c47b8705", 49 | "payload": { 50 | "event": "command-line", 51 | "properties": { 52 | "action": "test", 53 | "platform": "windows-10-x64" 54 | "version": "1.16" 55 | } 56 | } 57 | } 58 | ``` 59 | 60 | Running test first destroys the instance, and then creates, converges and verifies a new instance. 61 | Lastly, the instance is destroyed again. 62 | 63 | ```json 64 | { 65 | "product": "test-kitchen", 66 | "session_id": "504ec380-5a75-458c-9f56-afa3c47b8705", 67 | "payload": { 68 | "event": "destroy", 69 | "properties": { 70 | "platform": "windows-10-x64", 71 | "version": "1.16" 72 | } 73 | } 74 | } 75 | ``` 76 | 77 | ```json 78 | { 79 | "product": "test-kitchen", 80 | "session_id": "504ec380-5a75-458c-9f56-afa3c47b8705", 81 | "payload": { 82 | "event": "create", 83 | "properties": { 84 | "target": "bento/debian-9.0-amd64", 85 | "driver": "kitchen-hyperv", 86 | "driver_version": "1.2.3", 87 | "transport": "ssh", 88 | "platform": "windows-10-x64", 89 | "version": "1.16" 90 | } 91 | } 92 | } 93 | ``` 94 | 95 | when the instance is ready, the user has configured the `chef-zero` provisioner, and requested 96 | chef client `13`, using the new style configuration. They're using Policyfiles: 97 | 98 | ```json 99 | { 100 | "product": "test-kitchen", 101 | "session_id": "504ec380-5a75-458c-9f56-afa3c47b8705", 102 | "payload": { 103 | "event": "converge", 104 | "properties": { 105 | "product": "chef", 106 | "product_version": "13", 107 | "channel": "stable", 108 | "provisioner": "chef-zero", 109 | "resolver": "policyfile", 110 | "platform": "windows-10-x64", 111 | "version": "1.16" 112 | } 113 | } 114 | } 115 | ``` 116 | 117 | We now proceed to verifying the instance: 118 | 119 | ```json 120 | { 121 | "product": "test-kitchen", 122 | "session_id": "504ec380-5a75-458c-9f56-afa3c47b8705", 123 | "payload": { 124 | "event": "verify", 125 | "properties": { 126 | "verifier": "kitchen-inspec", 127 | "verifier_version": "1.2.3", 128 | "platform": "windows-10-x64", 129 | "version": "1.16" 130 | } 131 | } 132 | } 133 | ``` 134 | 135 | Before deleting it again (see above). 136 | 137 | ## Copyright 138 | 139 | This work is in the public domain. In jurisdictions that do not allow for this, 140 | this work is available under CC0. To the extent possible under law, the person 141 | who associated CC0 with this work has waived all copyright and related or 142 | neighboring rights to this work. 143 | -------------------------------------------------------------------------------- /rfc096-improved-log-levels.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 96 3 | Title: Improved Log Levels 4 | Author: Thom May 5 | Status: Final 6 | Type: Standards Track 7 | Tracking: https://github.com/chef/chef/pull/6910 8 | --- 9 | 10 | # Improved Log Levels 11 | 12 | Presently, the only way to debug a failing chef run is to enable debug 13 | logging, which is intended more for the maintainers of Chef than for a 14 | systems engineer. We would like to move to a structured metadata model 15 | that allows us to slice and dice log messages. 16 | 17 | ## Motivation 18 | 19 | As a Chef maintainer, 20 | I want to know exactly what chef is doing, 21 | so that I can maintain and develop chef. 22 | 23 | As a cookbook author, 24 | I want to ensure that my cookbook is interacting with the system as 25 | I expect, 26 | so that I can write cookbooks efficiently. 27 | 28 | As a systems engineer, 29 | I want to see the output of running commands, 30 | so that I can debug chef failures. 31 | 32 | ## Specification 33 | 34 | We propose to move the chef client, and related libraries, to a 35 | structured logging format. This would allow us to tag individual log 36 | messages with extended metadata, such as the resource/subsystem, the 37 | cookbook we're running in, the log level and so on. 38 | 39 | We would then update the logging commands to allow the user to specify a 40 | set of tags that they're interested in, allowing a user to only get log 41 | output from the resources associated with a single cookbook. 42 | 43 | ## Downstream Impact 44 | 45 | Any libraries that Chef includes (such as Ohai, mixlib-authentication 46 | and so on) would need to be updated to use structured logging. 47 | 48 | ## Copyright 49 | 50 | This work is in the public domain. In jurisdictions that do not allow for this, 51 | this work is available under CC0. To the extent possible under law, the person 52 | who associated CC0 with this work has waived all copyright and related or 53 | neighboring rights to this work. 54 | -------------------------------------------------------------------------------- /rfc098-deprecate-deploy-and-erlcall-resources.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 98 3 | Title: Deprecate deploy and erl_call 4 | Author: Noah Kantrowitz 5 | Status: Accepted 6 | Type: Standards Track 7 | --- 8 | 9 | # Deprecate `deploy` and `erl_call` 10 | 11 | Two resources in Chef core that cause a lot of user confusion and issues are 12 | the `deploy` and `erl_call` resources. 13 | 14 | With the `deploy` resource, the confusion is mostly inherent in the very large 15 | number of moving pieces in the resource. The Capistrano-style deployment logic 16 | makes sense when a deployment tool is expecting to co-exist with manual management, 17 | but this is not usually the case with Chef recipes. Most users would be better 18 | served by a simpler `git` resource for deployment. 19 | 20 | `erl_call` is more debatable, it doesn't tend to cause a lot of user confusion 21 | and the maintenance burden isn't really a problem, but if we're already doing 22 | some cleanups we kind of might as well. The use case for this resource is so 23 | vanishingly small that it doesn't make much sense to keep in Chef core. 24 | 25 | ## Motivation 26 | 27 | As a Chef user, 28 | I want Chef core resources to match my expectations, 29 | so that using Chef is easier. 30 | 31 | ## Specification 32 | 33 | The deprecation phase would start from now until Chef 14 in April 2018. The 34 | resources would emit a deprecation warning if used. 35 | 36 | Because the `deploy` resource has been around for so long, we recognize that 37 | even 6 months of deprecation warnings may not be sufficient time to port off it. 38 | As an aid to migration, we will copy the code for the `deploy` resource to a 39 | cookbook which can be included for backwards compatibility even after the release 40 | of Chef 14. This does not obligate us to continue supporting this resource or 41 | cookbook beyond basic compatibility fixes (i.e. this should not be construed as 42 | a permanent thing, nor should any improvements be counted upon beyond what 43 | already exists in Chef). 44 | 45 | With Chef 14, both resources would be removed from Chef. 46 | 47 | ## Downstream Impact 48 | 49 | Any cookbook using `deploy` would have either have to migrate to another file 50 | deployment solution (probably a simple `git` resource) or use the compatibility 51 | cookbook. Any cookbook using `erl_call` will be broken, however we are unable 52 | to find any public cookbooks at this time, and if there is community demand, 53 | someone could make a compatibility cookbook as with `deploy`. 54 | 55 | ## Copyright 56 | 57 | This work is in the public domain. In jurisdictions that do not allow for this, 58 | this work is available under CC0. To the extent possible under law, the person 59 | who associated CC0 with this work has waived all copyright and related or 60 | neighboring rights to this work. 61 | -------------------------------------------------------------------------------- /rfc099-authentication-config-file.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 99 3 | Title: Authentication Configuration 4 | Author: Thom May 5 | Status: Final 6 | Type: Standards Track 7 | Tracking: https://github.com/chef/chef/pull/6660 8 | --- 9 | 10 | # Authentication Configuration 11 | 12 | Currently, the Chef community maintains many tools to aid in the 13 | management and switching of Chef Server configuration options - for 14 | example `knife-block`. Any non-ruby tools must also implement their own 15 | configuration management, since our configuration files must be parsed 16 | as though they were ruby. 17 | 18 | It would be delightful to provide a single configuration file that was 19 | solely responsible for handling authentication options, and was in a 20 | language agnostic format, such as TOML. 21 | 22 | ## Motivation 23 | 24 | As an Operations Engineer, 25 | I want to manage nodes on many Chef Servers, 26 | so that I can interact with my whole estate. 27 | 28 | As a tool developer, 29 | I want to use the language of my choice, 30 | so that I can effectively build delightful Chef features. 31 | 32 | ## Specification 33 | 34 | A new file, `~/.chef/credentials`, will be supported by the chef client 35 | libraries, and other implementations. It is a TOML file, containing one 36 | or more sections, each associated with a profile. 37 | 38 | ``` 39 | [default] 40 | node_name = "barney" 41 | client_key = "barney_rubble.pem" 42 | chef_server_url = "https://api.chef.io/organisations/bedrock" 43 | 44 | [dev] 45 | client_name = "admin" 46 | client_key = "admin.pem" 47 | validator_key = "test-validator.pem" 48 | chef_server_url = "https://api.chef-server.dev/organizations/test" 49 | ``` 50 | 51 | File paths, such as `client_key` or `validator_key`, will be relative to 52 | `~/.chef` unless absolute. 53 | 54 | Clients can be identified with either `node_name` or `client_name`, with 55 | `client_name` being preferred. 56 | 57 | Keys can be specified inline using TOML multiline strings. 58 | 59 | The profile is selected using the `CHEF_PROFILE` environment variable, which 60 | client libraries which implement credential handling MUST support. 61 | Optionally, tools can also provide a `--profile` option, which would 62 | override the environment variable. 63 | 64 | To allow the user to specify statefully which profile they wish to 65 | use, we will introduce another new file, `~/.chef/context`, which would 66 | contain only the name of the profile to be used. 67 | 68 | It is expected that the credentials file will be parsed first, allowing 69 | the user's `knife.rb`/`config.rb` to continue to function as previously. 70 | 71 | To select the profile to use, libraries should follow the following 72 | order: 73 | 74 | 1. If an argument is passed with a command line flag, use that. 75 | 2. Otherwise, check for the `CHEF_PROFILE` environment variable, and 76 | use the value of that. 77 | 3. Otherwise, check for the context file, and read the profile name 78 | from that. 79 | 4. Otherwise, select the default profile. 80 | 81 | ## Downstream Impact 82 | 83 | Any chef API client library (such as `pychef`, `go-chef`, 84 | `rs-chef-api`), as well as `chef-config`, should be updated 85 | to support this file. 86 | 87 | Manage should be updated to produce a credentials file when generating a 88 | knife config. 89 | 90 | ## Copyright 91 | 92 | This work is in the public domain. In jurisdictions that do not allow for this, 93 | this work is available under CC0. To the extent possible under law, the person 94 | who associated CC0 with this work has waived all copyright and related or 95 | neighboring rights to this work. 96 | -------------------------------------------------------------------------------- /rfc101-resource-validation-messaging.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 101 3 | Title: Resource Validation Messaging 4 | Author: Tim Smith 5 | Status: Final 6 | Type: Standards Track 7 | Tracking: https://github.com/chef/chef/pull/6818 8 | --- 9 | 10 | # Resource Validation Messaging 11 | 12 | Custom resources provide multiple property validators allowing authors to control property input beyond just simple data types. Authors can expect strings to match predefined strings, match a regex, or return true from a callback method. This gives the author great control over the input data, but doesn't provide the consumer with much information when the validator fails. This RFC provides the author with the ability control the error text when the validator fails. 13 | 14 | ## Motivation 15 | 16 | As an author of custom resources, 17 | I want to control property inputs while providing useful error messaging on failure, 18 | so that users can easily understand why input data is not acceptable 19 | 20 | As a consumer of custom resources, 21 | I want detailed errors when I pass incorrect data to a resource, 22 | so that I quickly resolve failed chef-client runs. 23 | 24 | ## Specification 25 | 26 | This RFC will implement a new `validation_message` option for properties, which accepts a string. This message will be shown on failure in place of a generic failure message. 27 | 28 | ### Example 29 | 30 | in resources/example.rb 31 | 32 | ```ruby 33 | property :version, 34 | kind_of: String, 35 | default: '8.0.35' 36 | regex: [/^(?:(\d+)\.)?(?:(\d+)\.)?(\*|\d+)$/] 37 | validation_message: 'Version must be a X.Y.Z format String type' 38 | ``` 39 | 40 | ## Downstream Impact 41 | 42 | No anticipated downstream impact 43 | 44 | ## Copyright 45 | 46 | This work is in the public domain. In jurisdictions that do not allow for this, this work is available under CC0\. To the extent possible under law, the person who associated CC0 with this work has waived all copyright and related or neighboring rights to this work. 47 | -------------------------------------------------------------------------------- /rfc102-deprecations-in-resources.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 102 3 | Title: Deprecation Warnings Within Custom Resources 4 | Author: Tim Smith 5 | Status: Final 6 | Type: Standards Track 7 | Tracking: https://github.com/chef/chef/pull/7050 8 | --- 9 | 10 | # Deprecation Warnings Within Custom Resources 11 | 12 | In Chef 12, we introduced deprecation warnings within the chef-client. This allowed us to communicate future breaking changes to users. The warnings and integration within Test Kitchen have become a powerful tool allowing users to future proof their cookbooks and ease chef-client migration projects. 13 | 14 | This proposal extends the deprecation functionality to custom resources allowing authors to warn consumers of future breaking changes to their resources. 15 | 16 | ## Motivation 17 | 18 | As an author of custom resources, 19 | I want to warn users of my resources of future breaking changes to resources, 20 | so that they can update their wrapper cookbooks before my next release. 21 | 22 | As an author of custom resources, 23 | I want to provide immediate backwards compatibility in property names while still warning users, 24 | so that they can update their wrapper cookbooks before my next release. 25 | 26 | As an author of custom resources, 27 | I want to entirely deprecate a resource that users are consuming, 28 | so that they can update their wrapper cookbooks before my next release. 29 | 30 | As a consumer of custom resources, 31 | I want to be warned when I use deprecated functionality, 32 | so that I can update my wrapper cookbooks. 33 | 34 | ## Specification 35 | 36 | We will introduce 3 new methods in custom resources in order to implement this RFC: 37 | 38 | ### deprecated method for resources 39 | 40 | This new method will let authors communicate to consumers that a resource is going away in the future. Right now we rely on readme or changelog entries, which are not a very effective way to communicate to consumers. This method will accept a string which becomes the warning message. 41 | 42 | #### Example 43 | 44 | in resources/example.rb 45 | 46 | ```ruby 47 | deprecated 'This resource will be removed in the 3.0 release of the example cookbook in April 2018. You should use example_ng instead. See the readme for additional information.' 48 | ``` 49 | 50 | ### deprecated method for properties 51 | 52 | This new option for properties will let authors communicate to consumers that an individual property is going away in the future. Right now we rely on readme or changelog entries, which are not a very effective way to communicate to consumers. This method will accept a string which becomes the warning message. 53 | 54 | #### Example 55 | 56 | in resources/example.rb 57 | 58 | ```ruby 59 | property :destroy_everything, 60 | kind_of: [true, false], 61 | default: true, 62 | deprecated: 'Turns out destroying everything was a bad idea. This property will be removed in the 3.0 release of this cookbook in April 2018 and will throw an error if set at that time.' 63 | ``` 64 | 65 | ### deprecated_property_alias 66 | 67 | Currently if a resource author decides to change the name of a property they have two options: 68 | - Use alias_method which silently routes old properties to the new names 69 | - Define both properties in the resource and include functionality to set the new value using the old value while warning the user. 70 | 71 | `alias_method` doesn't alert cookbook consumers to the change and writing your own code to perform deprecation warnings is cumbersome and rarely done. A new deprecated_property_alias would behave similar to a `alias_method`, but throw deprecation warnings while providing backwards compatibility. It would accept and optional String value that would be used in place of a generic deprecation message. 72 | 73 | #### Example 74 | 75 | in resources/example.rb 76 | 77 | ```ruby 78 | deprecated_property_alias :set, :set_impact, 'The set property has been renamed to set_impact. Set will be removed from this cookbook in the next release in April 2018.' 79 | ``` 80 | 81 | ## Downstream Impact 82 | 83 | No anticipated downstream impact 84 | 85 | ## Copyright 86 | 87 | This work is in the public domain. In jurisdictions that do not allow for this, 88 | this work is available under CC0. To the extent possible under law, the person 89 | who associated CC0 with this work has waived all copyright and related or 90 | neighboring rights to this work. 91 | -------------------------------------------------------------------------------- /rfc103-disable-passwd-and-sessions-plugins.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 103 3 | Title: Disable Passwd and Sessions Ohai plugins 4 | Author: Thom May 5 | Status: Final 6 | Type: Informational 7 | Tracking: https://github.com/chef/ohai/pull/1136 8 | --- 9 | 10 | # Disable the Passwd and Sessions Ohai plugins 11 | 12 | We get a large number of user reports that these two plugins can cause a 13 | huge amount of unwanted storage use, especially in large enterprises 14 | with nodes hooked up to an AD tree. We should disable them by default 15 | in Chef 14, and provide appropriate notifications. 16 | 17 | ## Motivation 18 | 19 | As an Operations Engineer, 20 | I want to run my Chef Server efficiently, 21 | so that I can concentrate on providing value to my employers. 22 | 23 | ## Specification 24 | 25 | By default, make the `passwd` and `sessions` plugins disabled by 26 | default. 27 | 28 | ## Downstream Impact 29 | 30 | Any cookbooks that require these plugins will need to ensure that they 31 | document this, and operators will need to re-enable them. 32 | 33 | ## Copyright 34 | 35 | This work is in the public domain. In jurisdictions that do not allow for this, 36 | this work is available under CC0. To the extent possible under law, the person 37 | who associated CC0 with this work has waived all copyright and related or 38 | neighboring rights to this work. 39 | -------------------------------------------------------------------------------- /rfc104-self-documenting-resources.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 104 3 | Title: Self Documenting Resources 4 | Author: Tim Smith 5 | Status: Final 6 | Type: Standards Track 7 | Tracking: https://github.com/chef/chef/pull/6818 8 | --- 9 | 10 | # Self Documenting Resources 11 | 12 | Chef has allowed organizations to embrace infrastructure as code, but with codified infrastructure comes the need for accurate documentation for that codebase. This RFC aims to improve the ability to document resources within Chef code so that we can ensure documentation is accurate and automatically generated. This is applicable to both resources within chef-client and those which ship in cookbooks. 13 | 14 | ## Motivation 15 | 16 | ``` 17 | As an author of custom resources, 18 | I want to manage code and documentation in a single location 19 | so that I can have up to date documentation with minimal work 20 | 21 | As a maintainer of chef 22 | I want docs to automatically update when new chef-client releases are made 23 | so that manual release steps and mistakes can be reduced 24 | 25 | As a consumer of custom resources 26 | I want accurate and up to date documentation 27 | so that I can easily write cookbooks utilizing custom resources 28 | ``` 29 | 30 | ## Specification 31 | 32 | We will introduce 4 new methods in custom resources in order to implement this RFC: 33 | 34 | ### description (resource level) 35 | 36 | Description is a String value that allows the user to describe the resource and its functionality. This information would be similar to what you would expect to find in a readme or the Chef Docs site describing the usage of a resource. 37 | 38 | ### introduced (resource level) 39 | 40 | Introduced is a String value that documents when the resource was introduced. In a cookbook this would be a particular cookbook release. In the chef-client itself this would be a chef-client release. 41 | 42 | ### examples (resource level) 43 | 44 | Examples is a String value containing examples for how to use the resource. This allows the author to show and describe various ways the resource can be used. 45 | 46 | ### description (property level) 47 | 48 | Description is a String value that documents the usage of the individual property. Useful information here would be allowed values, validation regexes, or input coercions. 49 | 50 | ### description (action level) 51 | 52 | Description is a String that describes the functionality of the action. 53 | 54 | ## Example 55 | 56 | ```ruby 57 | description 'The apparmor_policy resource is used to add or remove policy files from a cookbook file' 58 | 59 | introduced '14.1' 60 | 61 | property :source_cookbook, 62 | String, 63 | description: 'The cookbook to source the policy file from' 64 | property :source_filename, 65 | String, 66 | description: 'The name of the source file if it differs from the apparmor.d file being created' 67 | 68 | action :add do 69 | description 'Adds an apparmor policy' 70 | 71 | cookbook_file "/etc/apparmor.d/#{new_resource.name}" do 72 | cookbook new_resource.source_cookbook if new_resource.source_cookbook 73 | source new_resource.source_filename if new_resource.source_filename 74 | owner 'root' 75 | group 'root' 76 | mode '0644' 77 | notifies :reload, 'service[apparmor]', :immediately 78 | end 79 | 80 | service 'apparmor' do 81 | supports status: true, restart: true, reload: true 82 | action [:nothing] 83 | end 84 | end 85 | ``` 86 | 87 | ## Reasons for not using YARD 88 | 89 | The goal of introducing minimal DSL changes is to extend the existing data already contained within each resource to include the necessary information to fully document resources. Documenting resources in YARD would require significant duplication of documentation, which most users probably won't do. Out of the box even without these new DSL extensions we can already document resources fairly well. These new extensions incentivize users to provide us with a small amount of addition information that would fully fill out the resource documentation. Within our own configuration management industry other projects have gone different routes to document their equivalence of resources. One project uses a hybrid comment / code method, which feels bolted on and overly complex. The other project fully documents code in comments which results in near 100% duplication of effort. Simple DSL extensions seem like they are more likely to be utilized and provide a better user experience. 90 | 91 | ## Downstream Impact 92 | 93 | The implementation of this RFC will enable the automatic generation of docs at docs.chef.io. 94 | 95 | ## Copyright 96 | 97 | This work is in the public domain. In jurisdictions that do not allow for this, this work is available under CC0\. To the extent possible under law, the person who associated CC0 with this work has waived all copyright and related or neighboring rights to this work. 98 | -------------------------------------------------------------------------------- /rfc105-attribute-hoist.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 105 3 | Title: Integrate hoisting of policy\_group attributes 4 | Author: Thom May 5 | Status: Final 6 | Type: Standards Track 7 | --- 8 | 9 | # Integrate Hoisting in core Chef 10 | 11 | Most users of Policies rely on "hoisting" to provide group specific 12 | attributes. This approach was formalised in the `poise-hoist` extension, 13 | which we'd like to move in to the Chef Client and formalise. 14 | 15 | To hoist an attribute, the user would provide a default attribute 16 | structure in their Policyfile similar to: 17 | ``` 18 | default['staging']['myapp']['title'] = "My Staging App" 19 | default['production']['myapp']['title'] = "My App" 20 | ``` 21 | and would access the node attribute in their cookbook as: 22 | ``` 23 | node['myapp']['title'] 24 | ``` 25 | The correct attribute would then be provided based on the `policy_group` 26 | of the node, so with a `policy_group` of `staging` the attribute would 27 | contain "My Staging App". 28 | 29 | 30 | ## Motivation 31 | 32 | As a cookbook author, 33 | I want to write cookbooks generically, 34 | so that they work in any operational context. 35 | 36 | As an operations engineer, 37 | I want to leverage policy groups to describe my estate, 38 | so that I can isolate environments correctly. 39 | 40 | ## Specification 41 | 42 | Hoisting will be enabled by default for all Policyfile using chef-client 43 | runs. We will not inherit the data bag hoisting that poise-hoist 44 | supports. 45 | Attributes of the form `policy_group`.`` will be made available as 46 | ``, at the level of `role_default` or `role_override`, which is where 47 | Policyfile `default` or `override` attributes are levelled currently. 48 | 49 | ## Downstream Impact 50 | 51 | Poise-hoist will not be required in chef client 14. 52 | 53 | ## Copyright 54 | 55 | This work is in the public domain. In jurisdictions that do not allow for this, 56 | this work is available under CC0. To the extent possible under law, the person 57 | who associated CC0 with this work has waived all copyright and related or 58 | neighboring rights to this work. 59 | -------------------------------------------------------------------------------- /rfc106-chef_env_attribute.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 106 3 | Title: Expose more settings as attributes 4 | Author: Thom May 5 | Status: Final 6 | Type: Standards Track 7 | Tracking: https://github.com/chef/chef/pull/6967 8 | --- 9 | 10 | # Exposing some core settings as attributes 11 | 12 | There are a number of settings, such as the node name and the environment, that we've historically not exposed as automatic attributes. 13 | The environment attribute is a bit more complicated in the world of 14 | policy groups, and this RFC clarifies that situation too 15 | 16 | ## Motivation 17 | 18 | As a system engineer, 19 | I want to make decisions based on the environment or policy group of a node, 20 | so that I get correct behaviour in my cookbooks. 21 | 22 | ## Specification 23 | 24 | We will expose the automatic attribute `name`, reflecting the name of 25 | the node. 26 | 27 | We will expose the automatic attribute `chef_environment`. In non-policy 28 | setups, the attribute will expose the environment that the node is in. 29 | 30 | In policy setups, it will expose the name of the policy group the node 31 | is in. We will also ensure that `node.chef_environment` returns the same data. We'll also expose `policy_group` and `policy_name`, to go along with `policy_revision`. 32 | 33 | ## Downstream Impact 34 | 35 | Cookbooks will have easy access to more attributes. 36 | 37 | ## Copyright 38 | 39 | This work is in the public domain. In jurisdictions that do not allow for this, 40 | this work is available under CC0. To the extent possible under law, the person 41 | who associated CC0 with this work has waived all copyright and related or 42 | neighboring rights to this work. 43 | -------------------------------------------------------------------------------- /rfc107-resource-map-locking.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 107 3 | Title: Resource Map Locking 4 | Author: Noah Kantrowitz 5 | Status: Accepted 6 | Type: Standards Track 7 | --- 8 | 9 | # Resource Map Locking 10 | 11 | To improve the migration process of resources from cookbooks to core, as well 12 | as prevent user confusion, resources in cookbooks will no longer be allowed to 13 | override resources in Chef core by default. 14 | 15 | The overall goal is enable the RFC100 resource adoption process to run more 16 | smoothly by allowing us to enforce that the version of a resource in Chef core 17 | will win priority even with an old version of the cookbook still active, but 18 | only when we want to (on Chef major version boundaries). 19 | 20 | ## Motivation 21 | 22 | As a Chef developer, 23 | I want to migrate resources to core, 24 | so that users can use them. 25 | 26 | ## Current State 27 | 28 | As of this writing, the way resource and provider mappings work is that every 29 | class providing a given name is ranked based on how "tightly" they bind to the 30 | name, and then within equal "tightness", the last class to load wins. In 31 | practical terms, this means that if both Chef core and a cookbook declare a 32 | resource with identical `provides` lines, the cookbook will win priority. 33 | 34 | ## Specification 35 | 36 | The main new concept would be introducing a "mode" to the resource and provider 37 | `NodeMap` instances, locked and unlocked. They would start in unlocked mode, 38 | allowing Chef core to register all its resources and providers as normal. It would 39 | then be switched into locked mode, where attempting to `provides` on a name 40 | that is already in use will result in a deprecation warning and the resource or 41 | provider *not* being mapped. This process is modulated in two ways, both via 42 | `provides` option flags. The first is `allow_cookbook_override: true`, which 43 | makes a resource or provider name always behave as if it is unlocked. This is 44 | used in Chef core as part of the RFC100 adoption process. The second is 45 | `__core_override__: true`, which allows intentionally remapping over a locked 46 | name in the map. This can be used by advanced users for things like pointing all 47 | `package` resources at some new code or other very edge case things. 48 | 49 | Any resource which has `allow_cookbook_override: true` set should be marked as 50 | "preview" in the documentation. This will help communicate that between 51 | the minor version where a resource is added and the following major release when 52 | it takes over from cookbooks forcibly is a trial run and we may continue to 53 | improve the resource (which should be coordinated with the cookbook). 54 | 55 | Cookbooks adding new providers to core resources is less problematic, but for 56 | consistency will work the same way so it will generally require the use of the 57 | `__core_override__` option. We may want to revisit this in the future for core 58 | resources which are most commonly extended like `package` and `service`, but 59 | this is still rare enough to be called out as a special case. 60 | 61 | In order to not disrupt the Chef 14 cycle, we can either change the behavior so 62 | that during Chef 14 when you `provides` over an existing name, it logs the 63 | deprecation warning but still adds the name, or we could add `allow_cookbook_override` 64 | to every core resource. 65 | 66 | ## Downstream Impact 67 | 68 | It is possible some users are already mapping over core resources on purpose. 69 | This proposal does preserve compatibility during Chef 14, though someone is 70 | going to complain about the deprecation warnings anyway. And come Chef 15, we 71 | would be changing the default behavior which will almost certainly get some 72 | complaints. 73 | 74 | ## Copyright 75 | 76 | This work is in the public domain. In jurisdictions that do not allow for this, 77 | this work is available under CC0. To the extent possible under law, the person 78 | who associated CC0 with this work has waived all copyright and related or 79 | neighboring rights to this work. 80 | -------------------------------------------------------------------------------- /rfc108-resource_metadata.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 108 3 | Title: Resource Metadata 4 | Author: Thom May 5 | Status: Accepted 6 | Type: Standards Track 7 | --- 8 | 9 | # Resource Metadata 10 | 11 | It's now possible to extract detailed API documentation of individual 12 | resources, but running other people's ruby code on your system to do so 13 | is unsafe. Therefore, a cookbook's metadata should contain the details of 14 | the resources contained in the cookbook. 15 | 16 | ## Motivation 17 | 18 | As a user of Supermarket, 19 | I want to view details of resources, 20 | so that I can write great cookbooks. 21 | 22 | As a cookbook author, 23 | I want code completion of any resource, 24 | so that I can write great cookbooks. 25 | 26 | ## Specification 27 | 28 | A new `resources` field will be added to the metadata json format. 29 | Resources are a set of resource descriptions generated by the 30 | `chef-resource-inspector`. Each resource has the following keys: 31 | 32 | * Description: The description of the resource 33 | * Actions: The list of actions available on the resource 34 | * Examples: Optional code examples 35 | * Introduced: The cookbook version that the resource was introduced in. 36 | * Properties: A list of properties that the resource supports. 37 | 38 | Each property has the following keys: 39 | * Name: Name of the property. 40 | * Is: The types that the property accepts. 41 | * Description: A description of the property. 42 | * Introduced: The cookbook version that added the property 43 | * Deprecated: Is the property deprecated? 44 | * Name Property: Is this property the name property for the resource 45 | 46 | Example: 47 | ```json 48 | { 49 | "resources": 50 | { 51 | "rhsm_errata": { 52 | "description": "Use the rhsm_errata resource to install packages associated with a given Red Hat Subscription Manager Errata ID. This is helpful if packages to mitigate a single vulnerability must be installed on your hosts.", 53 | "actions": [ 54 | "nothing", 55 | "install" 56 | ], 57 | "examples": null, 58 | "introduced": "14.0", 59 | "properties": [ 60 | { 61 | "name": "name", 62 | "description": null, 63 | "introduced": null, 64 | "is": "String", 65 | "deprecated": false 66 | }, 67 | { 68 | "name": "retries", 69 | "description": null, 70 | "introduced": null, 71 | "is": "Integer", 72 | "deprecated": false 73 | }, 74 | { 75 | "name": "retry_delay", 76 | "description": null, 77 | "introduced": null, 78 | "is": "Integer", 79 | "deprecated": false 80 | }, 81 | { 82 | "name": "sensitive", 83 | "description": null, 84 | "introduced": null, 85 | "is": [ 86 | "TrueClass", 87 | "FalseClass" 88 | ], 89 | "deprecated": false 90 | }, 91 | { 92 | "name": "ignore_failure", 93 | "description": null, 94 | "introduced": null, 95 | "is": [ 96 | "TrueClass", 97 | "FalseClass" 98 | ], 99 | "deprecated": false 100 | }, 101 | { 102 | "name": "errata_id", 103 | "description": "An optional property for specifying the errata ID if not using the resource's name.", 104 | "introduced": null, 105 | "is": "String", 106 | "deprecated": false 107 | } 108 | ] 109 | } 110 | } 111 | } 112 | ``` 113 | ## Downstream Impact 114 | 115 | * `stove`/`knife supermarket` will be updated to run `chef-resource-inspector` as part of the upload process. 116 | * Supermarket will add a new tab displaying resources in a cookbook. 117 | 118 | ## Copyright 119 | 120 | This work is in the public domain. In jurisdictions that do not allow for this, 121 | this work is available under CC0. To the extent possible under law, the person 122 | who associated CC0 with this work has waived all copyright and related or 123 | neighboring rights to this work. 124 | -------------------------------------------------------------------------------- /rfc109-ohai-new-plugins-policy.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 109 3 | Title: Ohai new plugins policy 4 | Author: Phil Dibowitz 5 | Status: Accepted 6 | Type: 7 | --- 8 | 9 | # Ohai new plugins policy 10 | 11 | To allow Chef to move fast while still providing stability, this lines out a 12 | policy for clarity. 13 | 14 | ## Motivation 15 | 16 | As a Chef developer, 17 | I want to be able to provide new functionality to the community 18 | so that they can use it. 19 | 20 | As a Chef user, 21 | I want to be able to leverage new functionality as quickly as possible 22 | with minimal work while not breaking existing features. 23 | 24 | As a Chef user, 25 | I also want to be able to discover available plugins. 26 | 27 | ## Specification 28 | 29 | New Ohai plugins should be able to be added in the current version, provided 30 | they do not change an existing namespace in a non-additive way (see below for 31 | examples). 32 | 33 | Further, by default we expect new plugins to *not* have `optional` set, unless 34 | there is a reason not to (for example, we expect it to be load-heavy in some 35 | environments). 36 | 37 | Ohai changes to N-1 are only added to fix bugs. 38 | 39 | Examples: 40 | 41 | * Adding new fields to an existing plugin namespace should be allowed in 42 | Example: https://github.com/chef/ohai/pull/1104/ 43 | * Adding an entirely new plugin that uses a distinct top-level namespace 44 | Example: https://github.com/chef/ohai/pull/1170 45 | * Fixing a bug should be allowed in `current` and `current-1`. 46 | Example: https://github.com/chef/ohai/pull/1084 47 | * Changing an existing namespace should *not* be allowed in `current` or 48 | `current-1` 49 | Example: Moving `node['filesystem']` to the `filesystem2` format. 50 | 51 | ## Downstream Impact 52 | 53 | None 54 | 55 | ## Copyright 56 | 57 | This work is in the public domain. In jurisdictions that do not allow for this, 58 | this work is available under CC0. To the extent possible under law, the person 59 | who associated CC0 with this work has waived all copyright and related or 60 | neighboring rights to this work. 61 | -------------------------------------------------------------------------------- /rfc111-in-repo-draft-guides-for-chef.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 111 3 | Title: In-Repo Draft Guides for Chef 4 | Author: 5 | - Noah Kantrowitz 6 | - Kimberly Garmoe 7 | Status: Accepted 8 | Type: Process 9 | --- 10 | 11 | # In-Repo Draft Guides for Chef 12 | 13 | Chef community members are skilled practitioners and valuable contributors. Chef 14 | practitioners have experience and skills, but lack a stable process for composing 15 | and sharing long-format information. 16 | 17 | The community has requested two changes: 18 | 19 | 1. A place in the `chef/chef` repository for storing community guides 20 | 2. The ability to write in Markdown 21 | 22 | ## Motivation 23 | 24 | As a Chef contributor, 25 | I want to write guides for specific procedures or problems 26 | so that we can capture changes to Chef. 27 | 28 | ## Specification 29 | 30 | To this end, we will create a `guides-drafts/` folder in the `chef/chef` repository. 31 | This folder will contain documentation files so that the maintainer team can 32 | work on and update them. No content in this folder will be considered ready for 33 | end-user use, and will not be displayed on any documentation website (docs.chef.io 34 | or whatever comes in the future in the same vein). At the discretion of the Chef 35 | documentation team, some content may be reviewed and prepared for end-user 36 | distribution, however that process is not covered here. 37 | 38 | A `README.md` file in this folder will emphasize that the documentation here is 39 | not for end-user consumption and encourage them to consult docs.chef.io. 40 | 41 | As more draft guides are added, it will be the general policy of the Chef 42 | maintainer team to only allow merges that include the relevant updates to any 43 | existing guides, or the creation of a new guide if appropriate. 44 | 45 | ## Interim Workflow 46 | 47 | [ed: this has not yet been reviewed by the Chef docs folks, this might be totally crazytalk] 48 | 49 | New content will be added by the Chef maintainer team. For purely internal, 50 | developer-facing documents, the maintainer team will own the content permanently. 51 | 52 | For content eventually destined for users, the maintainer team will nominate 53 | guides that the we feel are ready for review. The documentation team will, when 54 | they have time available, do a copy-editing pass and determine if the final 55 | destination will be `docs.chef.io` or `learn.chef.io`. The docs team will then 56 | copy the content into the destination system for end-user consumption. When a 57 | guide is updated in the future, it can be nominated for review again. 58 | 59 | ## Content Suggestions 60 | 61 | None of these are specifically required (or promised), but give an idea of the 62 | scope of the proposed structure: 63 | 64 | ### For users 65 | 66 | * How to write a helper method 67 | * How to write a DSL extension 68 | * How to write a custom resource 69 | * How to use Test Kitchen 70 | * How to use Foodcritic/Cookstyle 71 | * How to use node attributes 72 | * Berks vs. Policyfiles 73 | * How use Policyfiles in a workflow 74 | * Upgrading from roles/envs to Policyfiles 75 | * How to run subcommands (execute resources vs shell_out) 76 | * How to build CI pipelines for Chef 77 | * How to get help with Chef (community resources, etc) 78 | * Compile time vs converge time 79 | * How to move or copy files with Chef 80 | * How to edit files with Chef 81 | * How to set up Chef Server ACLs 82 | * Chef vs. Puppet+Salt+Ansible (a la hashicorp's "versus" docs) 83 | * Chef vs. Docker 84 | * Chef vs. K8s 85 | * "Getting started" guide (zero to learn-chef) 86 | * Using Chef with a corporate proxy 87 | * Using Chef on an air gap network 88 | * Using secrets with Chef 89 | * Writing wrapper cookbooks 90 | * Deploying web applications with Chef 91 | * How to set up new nodes (bootstrap, self-bootstrap) 92 | * Using community cookbooks 93 | * Publishing community cookbooks (shoutouts to souschef) 94 | * Knife vs chef 95 | 96 | ### For Chef Developers 97 | 98 | * How the Omnibus build system works 99 | * How to bump dependencies 100 | * How to release Chef 101 | * How to backport a fix 102 | * How to add a new resource to Chef 103 | * How Chef is tested (and built) 104 | * What all the mixlib gems do (also chef-config, other deps) 105 | * Chef vs Chef Server vs ChefDK vs Chef Workstation 106 | * What are Chef RFCs for and how to file one 107 | * Dev-relevant chat channels 108 | 109 | ## Downstream Impact 110 | 111 | This will eventually be made obsolete by planned overall improvements to the documentation 112 | workflow, but until this this work will have to be periodically manually integrated 113 | into user-facing documents. 114 | 115 | ## Copyright 116 | 117 | This work is in the public domain. In jurisdictions that do not allow for this, 118 | this work is available under CC0. To the extent possible under law, the person 119 | who associated CC0 with this work has waived all copyright and related or 120 | neighboring rights to this work. 121 | -------------------------------------------------------------------------------- /rfc112-target-mode.md: -------------------------------------------------------------------------------- 1 | --- 2 | RFC: 112 3 | Title: Chef Target Mode 4 | Author: Bryan McLellan 5 | Status: Accepted 6 | Type: Standards Track 7 | --- 8 | 9 | # Chef Target Mode 10 | 11 | When deploying applications or systems, we frequently need to configure 12 | applications where Chef cannot run natively. 13 | 14 | ## Motivation 15 | 16 | As a site reliability engineer, 17 | I want to configure routers, switches and load balancers, 18 | so that my application functions correctly. 19 | 20 | ## Specification 21 | 22 | A node is any machine - physical, virtual, cloud, network device, etc. - that 23 | is managed by Chef. While typically the Chef client runs on the node that it is 24 | managing, target mode would enable the client to manage a remote node. 25 | 26 | The management node is the machine that Chef client runs on and is likely to be a 27 | specific machine chosen for running the client against multiple target nodes. 28 | Ad-hoc runs against target nodes are intended to be exposed to the user through 29 | the 'chef apply' ad-hoc user experience currently associated with Chef 30 | Workstation. 31 | 32 | Having each target node be represented by a separate Chef node leverages 33 | the existing functionality in the ecosystem with only minimal modification. For 34 | example, the run list for a target node would be changed using existing 35 | patterns, `knife node run_list add TARGET_NODE RUN_LIST_ITEM`. 36 | 37 | Having each target node be managed by a separate Chef client run avoids 38 | refactoring the run\_context to account for multiple node objects at once and 39 | choosing between them. 40 | 41 | Target mode would be enabled by setting the `target` configuration setting. 42 | This could be either from a configuration file or a command line argument, e.g. 43 | `chef-client --target router.local`. When in target mode, many default local 44 | file paths would automatically change based on the target name. For example, 45 | the lock file name could change to `chef-client-TARGET_NAME.pid` and the 46 | cache path could have a sub-directory added based on the target name. This 47 | allows all other settings such as `chef_server_url` and `client_key` to be 48 | inherited from the management nodes `client.rb`. Alternatively, multiple 49 | configuration files could be maintained, one for each target node. 50 | 51 | Initially target mode would disable the use of Ohai in the client run until 52 | such time as similar support is added to Ohai. Thus target mode would require 53 | `platform` to be set on the node object (`--json-attributes`). Train's 54 | `conn.os[:family]` and `conn.os[:release]` functionality could likely be 55 | leveraged until that time. Otherwise, target mode would require `platform` to 56 | be set on the node object via `--json-attributes` or a similar fashion. An 57 | `fqdn` or `ipaddress` attribute would also have to be set in the same way. 58 | 59 | `Chef::NodeMap` would be modified such that `Chef::Provider.provides` would 60 | take a `target_mode` option. This ensures that only providers that support 61 | target\_mode are available when running in target mode. For example: 62 | 63 | ``` 64 | provides :interface, platform: "cisco", target_mode: true 65 | ``` 66 | 67 | Initially only the `execute` resource would be expected to be supported but 68 | custom resources could quickly be developed in cookbooks. Over time some core 69 | resources and providers may be updated or modified to support target mode 70 | against traditional platforms. This would facilitate `chef apply` use without 71 | having to install the chef-client on the target node and managing nodes running 72 | on esoteric architectures that we don't build binaries for. 73 | 74 | Train would be used as the transport library for connecting to target nodes. 75 | Providers could use a new mixin that would use the Train connection if we were 76 | in a target mode or otherwise shell\_out to execute a command. 77 | 78 | ### Secrets 79 | 80 | The storage of usernames, passwords, keys, and other secrets will be 81 | initially accomplished using the credentials file defined in 82 | [RFC099](https://github.com/chef/chef-rfc/blob/master/rfc099-authentication-config-file.md). 83 | We expect to later develop a secrets abstraction layer that facilitates the use 84 | of existing secrets solutions like encrypted data bags, Chef Vault, and Hashi 85 | Vault, without having to add support to all of these to target mode directly. 86 | 87 | ## Downstream Impact 88 | 89 | Chef Workstation / chef-apply would be modified to use target mode when the 90 | remote machine doesn't have a supported Chef installation. 91 | 92 | ## Copyright 93 | 94 | This work is in the public domain. In jurisdictions that do not allow for this, 95 | this work is available under CC0. To the extent possible under law, the person 96 | who associated CC0 with this work has waived all copyright and related or 97 | neighboring rights to this work. 98 | -------------------------------------------------------------------------------- /support/rfc048-GithubIssuesWorkflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chef-boneyard/chef-rfc/76778b8c5b51444f973a0daecb5de471dc9ec134/support/rfc048-GithubIssuesWorkflow.png -------------------------------------------------------------------------------- /tasks/advocates.rb: -------------------------------------------------------------------------------- 1 | # 2 | # Author:: Thom May (thom@may.lt) 3 | # Author:: Nathen Harvey (nathenharvey@google.com) 4 | # Copyright:: Copyright (c) 2015-2019, Chef Software, Inc 5 | # License:: Apache License, Version 2.0 6 | # 7 | # Licensed under the Apache License, Version 2.0 (the "License"); 8 | # you may not use this file except in compliance with the License. 9 | # You may obtain a copy of the License at 10 | # 11 | # http://www.apache.org/licenses/LICENSE-2.0 12 | # 13 | # Unless required by applicable law or agreed to in writing, software 14 | # distributed under the License is distributed on an "AS IS" BASIS, 15 | # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 16 | # See the License for the specific language governing permissions and 17 | # limitations under the License. 18 | # 19 | 20 | require 'rake' 21 | require 'tomlrb' 22 | 23 | SOURCE = File.join(File.dirname(__FILE__), "..", "ADVOCATES.toml") 24 | TARGET = File.join(File.dirname(__FILE__), "..", "ADVOCATES.md") 25 | 26 | task :default => :generate 27 | 28 | namespace :advocates do 29 | desc "Generate MarkDown version of ADVOCATES file" 30 | task :generate do 31 | advocates = Tomlrb.load_file SOURCE 32 | out = "\n" 33 | out << "\n\n" 34 | out << "# " + advocates["Preamble"]["title"] + "\n\n" 35 | out << advocates["Preamble"]["text"] + "\n" 36 | out << "# " + advocates["Org"]["Lead"]["title"] + "\n\n" 37 | out << person_data(advocates["people"].fetch(advocates["Org"]["Lead"]["person"])) + "\n\n" 38 | out << "## " + advocates["Org"]["Ombudsperson"]["title"] + "\n\n" 39 | out << person_data(advocates["people"].fetch(advocates["Org"]["Ombudsperson"]["person"])) + "\n\n" 40 | out << "## Advocates\n\n" 41 | out << components(advocates["people"], advocates["Org"]["Advocates"]) 42 | File.open(TARGET, "w") { |fn| 43 | fn.write out 44 | } 45 | end 46 | end 47 | 48 | def components(list, cmp) 49 | out = "" 50 | cmp.each do |k,v| 51 | out << "\n#### #{v['title'].gsub('#','\\#')}\n" 52 | out << advocates(list, v['advocates']) 53 | end 54 | out 55 | end 56 | 57 | def advocates(list, people) 58 | o = "" 59 | people.each do |p| 60 | o << person_data(list.fetch(p)) + "\n" 61 | end 62 | o 63 | end 64 | 65 | def person_data(person) 66 | if person.has_key?("GitHub") 67 | out = "* [#{person["Name"]}](https://github.com/#{person["GitHub"]})" 68 | else 69 | out = "* #{person["Name"]}" 70 | end 71 | out << "\n * Slack - #{person["Slack"]}" if person.has_key?("Slack") 72 | out << "\n * [@#{person["Twitter"]}](https://twitter.com/#{person["Twitter"]})" if person.has_key?("Twitter") 73 | out << "\n * [#{person["email"]}](mailto:#{person["email"]})" if person.has_key?("email") 74 | out << "\n * #{person["phone"]}" if person.has_key?("phone") 75 | out << "\n * [ServerFault](#{person["ServerFault"]})" if person.has_key?("ServerFault") 76 | out << "\n * [StackOverflow](#{person["StackOverflow"]})" if person.has_key?("StackOverflow") 77 | out 78 | end 79 | -------------------------------------------------------------------------------- /tasks/pages.rb: -------------------------------------------------------------------------------- 1 | # Generate https://chef.github.io/chef-rfc/ , using metadata from 2 | # individual RFCs to build an index. 3 | 4 | require 'metadown' 5 | require 'pygments' 6 | require 'erubis' 7 | 8 | class HTMLwithPygments < Metadown::Renderer 9 | def block_code(code, language) 10 | Pygments.highlight(code, lexer: language) 11 | rescue Exception 12 | Pygments.highlight(code, lexer: 'text') 13 | end 14 | end 15 | 16 | POSTAMBLE=<<-EOF.freeze 17 | 18 | 19 | 20 | EOF 21 | 22 | PREAMBLE=<<-EOF.freeze 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 34 | Chef RFCs 35 | 36 | 37 |
38 |
39 |
40 |

Chef RFCs

 41 |
42 |
43 | EOF 44 | 45 | INDEX=<<-EOF.freeze 46 |
47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | <% for item in metadata -%> 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | <% end -%> 66 |
NumberTitleAuthorTypeStatusTracking
"><%= item["RFC"] %>"><%= item["Title"] %><%= item["Author"] %><%= item["Type"] %><%= item["Status"] %><%= item["Tracking"] %>
67 |
68 | EOF 69 | 70 | namespace :pages do 71 | desc "Generate GitHub Pages for RFCs" 72 | task :generate do 73 | sh("git worktree add -b gh-pages gh-pages origin/gh-pages") unless File.directory?("gh-pages") 74 | metadata = [] 75 | renderer = Redcarpet::Markdown.new(HTMLwithPygments, :fenced_code_blocks => true) 76 | Dir[File.join(File.dirname(__FILE__), "..", "rfc*.md")].each do |rfc| 77 | name = File.basename(rfc, ".md") 78 | target = name + ".html" 79 | output = Metadown.render(File.read(rfc), renderer) 80 | output.metadata ||= {} 81 | output.metadata["Filename"] = target 82 | number, title = name.match(/rfc(\d*)-(.+)/)[1,2] 83 | output.metadata["Title"] ||= title.split("-").map(&:capitalize).join(" ") 84 | output.metadata["RFC"] ||= number 85 | metadata << output.metadata 86 | File.open(File.join("gh-pages", target), "w") {|fh| fh.write(PREAMBLE + output.output + POSTAMBLE) } 87 | end 88 | metadata = metadata.sort_by { |rfc| rfc["RFC"] } 89 | eruby = Erubis::EscapedEruby.new(INDEX) 90 | File.open(File.join("gh-pages", "index.html"), "w") {|fh| fh.write(PREAMBLE + eruby.result(binding()) + POSTAMBLE) } 91 | end 92 | puts "Now enter the gh-pages directory and git diff etc" 93 | puts "The site will get updated when you commit and push the gh-pages branch with your changes" 94 | end 95 | --------------------------------------------------------------------------------