Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

regenerated metadata after pushing to cookbook site

  • Loading branch information...
commit cd56af93fe28ce2195ff9ac45b99cda8ceaf3254 1 parent 56e47c2
@jtimberman jtimberman authored
Showing with 4 additions and 4 deletions.
  1. +2 −2 application/metadata.json
  2. +2 −2 radiant/metadata.json
View
4 application/metadata.json
@@ -1,7 +1,7 @@
{
"name": "application",
"description": "Deploys and configures a variety of applications defined from databag 'apps'",
- "long_description": "Application cookbook\n====================\n\nThis cookbook is initially designed to be able to describe and deploy web applications. Currently supported:\n\n* Rails\n\nOther application stacks (PHP, DJango, JBoss, etc) will be supported as new recipes at a later date.\n\nThis cookbook aims to provide primitives to install/deploy any kind of application driven entirely by data defined in an abstract way through a data bag.\n\n---\nRequirements\n============\n\nChef 0.8 or higher required.\n\nThe following Opscode cookbooks are dependencies:\n\n* runit\n* unicorn\n* apache2\n\nThe following are also dependencies, though the recipes are considered deprecated, may be useful for future development.\n\n* `ruby_enterprise`\n* `passenger_enterprise`\n\n---\nRecipes\n=======\n\nThe application cookbook contains the following recipes.\n\ndefault\n-------\n\nSearches the `apps` data bag and checks that a server role in the app exists on this node, adds the app to the run state and uses the role for the app to locate the recipes that need to be used. The recipes listed in the \"type\" part of the data bag are included by this recipe, so only the \"application\" recipe needs to be in the node or role `run_list`.\n\nSee below regarding the application data bag structure.\n\npassenger_apache2\n-----------------\n\nRequires `apache2` and `passenger_apache2` cookbooks. The `recipe[apache2]` entry should come before `recipe[application]` in the run list.\n\n \"run_list\": [\n \"recipe[apache2]\",\n \"recipe[application]\"\n ],\n\nSets up a passenger vhost template for the application using the `apache2` cookbook's `web_app` definition. Use this with the `rails` recipe, in the list of recipes for a specific application type. See data bag example below.\n\nrails\n-----\n\nUsing the node's `run_state` that contains the current application in the search, this recipe will install required packages and gems, set up the deployment scaffolding, creates database and memcached configurations if required and then performs a revision-based deploy.\n\nThis recipe can be used on nodes that are going to run the application, or on nodes that need to have the application code checkout available such as supporting utility nodes or a configured load balancer that needs static assets stored in the application repository.\n\nFor Gem Bundler: include `bundler` or `bundler08` in the gems list. `bundle install` or `gem bundle` will be run before migrations.\nFor config.gem in environment: `rake gems:install RAILS_ENV=<node environment>` will be run when a Gem Bundler command is not.\n\nunicorn\n-------\n\nRequires `unicorn` cookbook.\n\nUnicorn is installed, default attributes are set for the node and an app specific unicorn config and runit service are created.\n\n---\nDeprecated Recipes\n==================\n\nThe following recipes are deprecated in favor of rails+unicorn, as that is performant enough for many Rails applications, and takes less time to provision new instances. Using these recipes may require additional work to the rest of the stack that wouldn't be required with rails+unicorn because they were early-phase development of this cookbook.\n\npassenger-nginx\n---------------\n\nBuilds passenger as an nginx module, drops off the configuration file and sets up the site to run the application under nginx with passenger. Does not deploy the code automatically.\n\nrails_nginx_ree_passenger\n-------------------------\n\nSets up the application stack with Ruby Enterprise Edition, Nginx and Passenger.\n\nThe recipe searches the apps data bag and then installs packages and gems, creates the nginx vhost config and enables the site, sets up the deployment scaffolding, and uses a revision-based deploy for the code. Database and memcached yaml files are written out as well, if required.\n\n---\nApplication Data Bag\n====================\n\nThe applications data bag expects certain values in order to configure parts of the recipe. Below is a paste of the JSON, where the value is a description of the key. Use your own values, as required. Note that this data bag is also used by the `database` cookbook, so it will contain database information as well. Items that may be ambiguous have an example.\n\nThe application used in examples is named `my_app` and the environment is `production`. Most top-level keys are Arrays, and each top-level key has an entry that describes what it is for, followed by the example entries. Entries that are hashes themselves will have the description in the value.\n\nNote about \"type\": the recipes listed in the \"type\" will be included in the run list via `include_recipe` in the application default recipe based on the type matching one of the `server_roles` values.\n\nNote about `databases`, the data specified will be rendered as the `database.yml` file. In the `database` cookbook, this information is also used to set up privileges for the application user, and create the databases.\n\nNote about gems and packages, the version is optional. If specified, the version will be passed as a parameter to the resource. Otherwise it will use the latest available version per the default `:install` action for the package provider.\n\n {\n \"id\": \"my_app\",\n \"server_roles\": [\n \"application specific role(s), typically the name of the app, e.g., my_app\",\n \"my_app\"\n ],\n \"type\": {\n \"my_app\": [\n \"recipes in this application cookbook to run for this role\",\n \"rails\",\n \"unicorn\"\n ]\n },\n \"memcached_role\": [\n \"name of the role used for the app-specific memcached server\",\n \"my_app_memcached\"\n ],\n \"database_slave_role\": [\n \"name of the role used by database slaves, typically named after the app, 'my_app_database_slave'\",\n \"my_app_database_slave\"\n ],\n \"database_master_role\": [\n \"name of the role used by database master, typically named after the app 'my_app_database_master'\",\n \"my_app_database_master\"\n ],\n \"repository\": \"git@github.com:company/my_app.git\",\n \"revision\": {\n \"production\": \"commit hash, branch or tag to deploy\"\n },\n \"force\": {\n \"production\": \"true or false w/o quotes to force deployment, see the rails.rb recipe\"\n },\n \"migrate\": {\n \"production\": \"true or false boolean to force migration, see rails.rb recipe\"\n },\n \"databases\": {\n \"production\": {\n \"reconnect\": \"true\",\n \"encoding\": \"utf8\",\n \"username\": \"db_user\",\n \"adapter\": \"mysql\",\n \"password\": \"awesome_password\",\n \"database\": \"db_name_production\"\n }\n },\n \"mysql_root_password\": {\n \"production\": \"password for the root user in mysql\"\n },\n \"mysql_debian_password\": {\n \"production\": \"password for the debian-sys-maint user on ubuntu/debian\"\n },\n \"mysql_repl_password\": {\n \"production\": \"password for the 'repl' user for replication.\"\n },\n \"snapshots_to_keep\": {\n \"production\": \"if using EBS, integer of the number of snapshots we're going to keep for this environment.\"\n },\n \"deploy_key\": \"SSH private key used to deploy from a private git repository\",\n \"deploy_to\": \"path to deploy, e.g. /srv/my_app\",\n \"owner\": \"owner for the application files when deployed\",\n \"group\": \"group for the application files when deployed\",\n \"packages\": {\n \"package_name\": \"specific packages required for installation at the OS level to run the app like libraries and specific version, e.g.\",\n \"curl\": \"7.19.5-1ubuntu2\"\n },\n \"gems\": {\n \"gem_name\": \"specific gems required for installation to run the application, and if a specific version is required, e.g.\",\n \"rails\": \"2.3.5\"\n },\n \"memcached\": {\n \"production\": {\n \"namespace\": \"specify the memcache namespace, ie my_app_environment\"\n }\n }\n }\n\n---\nUsage\n=====\n\nTo use the application cookbook, we recommend creating a role named after the application, e.g. `my_app`. This role should match one of the `server_roles` entries, that will correspond to a `type` entry, in the databag. Create a Ruby DSL role in your chef-repo, or create the role directly with knife.\n\n % knife role show my_app\n {\n \"name\": \"my_app\",\n \"chef_type\": \"role\",\n \"json_class\": \"Chef::Role\",\n \"default_attributes\": {\n },\n \"description\": \"\",\n \"run_list\": [\n \"recipe[application]\"\n ],\n \"override_attributes\": {\n }\n }\n\nAlso recommended is a site-cookbook named after the application, e.g. `my_app`, for additional application specific setup such as other config files for queues, search engines and other components of your application. The `my_app` recipe can be used in the run list of the role, if it includes the `application` recipe.\n\nYou should also have a role for the environment(s) you wish to use this cookbook. Similar to the role above, create the Ruby DSL file in chef-repo, or create with knife directly.\n\n % knife role show production\n {\n \"name\": \"production\",\n \"chef_type\": \"role\",\n \"json_class\": \"Chef::Role\",\n \"default_attributes\": {\n \"app_environment\": \"production\"\n },\n \"description\": \"production environment role\",\n \"run_list\": [\n\n ],\n \"override_attributes\": {\n }\n }\n\nThis role uses a default attribute so nodes can be moved into other environments on the fly simply by modifying their node object directly on the Chef Server.\n\n---\nLicense and Author\n==================\n\nAuthor:: Adam Jacob (<adam@opscode.com>)\nAuthor:: Joshua Timberman (<joshua@opscode.com>)\n\nCopyright 2009-2010, Opscode, Inc.\n\nLicensed under the Apache License, Version 2.0 (the \"License\");\nyou may not use this file except in compliance with the License.\nYou may obtain a copy of the License at\n\n http://www.apache.org/licenses/LICENSE-2.0\n\nUnless required by applicable law or agreed to in writing, software\ndistributed under the License is distributed on an \"AS IS\" BASIS,\nWITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\nSee the License for the specific language governing permissions and\nlimitations under the License.\n",
+ "long_description": "Application cookbook\n====================\n\nThis cookbook is initially designed to be able to describe and deploy web applications. Currently supported:\n\n* Rails\n\nOther application stacks (PHP, DJango, JBoss, etc) will be supported as new recipes at a later date.\n\nThis cookbook aims to provide primitives to install/deploy any kind of application driven entirely by data defined in an abstract way through a data bag.\n\n---\nRequirements\n============\n\nChef 0.8 or higher required.\n\nThe following Opscode cookbooks are dependencies:\n\n* runit\n* unicorn\n* apache2\n\nThe following are also dependencies, though the recipes are considered deprecated, may be useful for future development.\n\n* `ruby_enterprise`\n* `passenger_enterprise`\n\n---\nRecipes\n=======\n\nThe application cookbook contains the following recipes.\n\ndefault\n-------\n\nSearches the `apps` data bag and checks that a server role in the app exists on this node, adds the app to the run state and uses the role for the app to locate the recipes that need to be used. The recipes listed in the \"type\" part of the data bag are included by this recipe, so only the \"application\" recipe needs to be in the node or role `run_list`.\n\nSee below regarding the application data bag structure.\n\n`passenger_apache2`\n-------------------\n\nRequires `apache2` and `passenger_apache2` cookbooks. The `recipe[apache2]` entry should come before `recipe[application]` in the run list.\n\n \"run_list\": [\n \"recipe[apache2]\",\n \"recipe[application]\"\n ],\n\nSets up a passenger vhost template for the application using the `apache2` cookbook's `web_app` definition. Use this with the `rails` recipe, in the list of recipes for a specific application type. See data bag example below.\n\nrails\n-----\n\nUsing the node's `run_state` that contains the current application in the search, this recipe will install required packages and gems, set up the deployment scaffolding, creates database and memcached configurations if required and then performs a revision-based deploy.\n\nThis recipe can be used on nodes that are going to run the application, or on nodes that need to have the application code checkout available such as supporting utility nodes or a configured load balancer that needs static assets stored in the application repository.\n\nFor Gem Bundler: include `bundler` or `bundler08` in the gems list. `bundle install` or `gem bundle` will be run before migrations.\n\nFor config.gem in environment: `rake gems:install RAILS_ENV=<node environment>` will be run when a Gem Bundler command is not.\n\nIn order to manage running database migrations (rake db:migrate), you can use a role that sets the `run_migrations` attribute for the application (`my_app`, below) in the correct environment (production, below). Note the data bag item needs to have migrate set to true. See the data bag example below.\n\n {\n \"name\": \"my_app_run_migrations\",\n \"description\": \"Run db:migrate on demand for my_app\",\n \"json_class\": \"Chef::Role\",\n \"default_attributes\": {\n },\n \"override_attributes\": {\n \"apps\": {\n \"my_app\": {\n \"production\": {\n \"run_migrations\": true\n }\n }\n }\n },\n \"chef_type\": \"role\",\n \"run_list\": [\n ]\n }\n\nSimply apply this role to the node's run list when it is time to run migrations, and the recipe will remove the role when done.\n\nunicorn\n-------\n\nRequires `unicorn` cookbook.\n\nUnicorn is installed, default attributes are set for the node and an app specific unicorn config and runit service are created.\n\n---\nDeprecated Recipes\n==================\n\nThe following recipes are deprecated in favor of rails+unicorn, as that is performant enough for many Rails applications, and takes less time to provision new instances. Using these recipes may require additional work to the rest of the stack that wouldn't be required with rails+unicorn because they were early-phase development of this cookbook.\n\npassenger-nginx\n---------------\n\nBuilds passenger as an nginx module, drops off the configuration file and sets up the site to run the application under nginx with passenger. Does not deploy the code automatically.\n\n`rails_nginx_ree_passenger`\n---------------------------\n\nSets up the application stack with Ruby Enterprise Edition, Nginx and Passenger.\n\nThe recipe searches the apps data bag and then installs packages and gems, creates the nginx vhost config and enables the site, sets up the deployment scaffolding, and uses a revision-based deploy for the code. Database and memcached yaml files are written out as well, if required.\n\n---\nApplication Data Bag\n====================\n\nThe applications data bag expects certain values in order to configure parts of the recipe. Below is a paste of the JSON, where the value is a description of the key. Use your own values, as required. Note that this data bag is also used by the `database` cookbook, so it will contain database information as well. Items that may be ambiguous have an example.\n\nThe application used in examples is named `my_app` and the environment is `production`. Most top-level keys are Arrays, and each top-level key has an entry that describes what it is for, followed by the example entries. Entries that are hashes themselves will have the description in the value.\n\nNote about \"type\": the recipes listed in the \"type\" will be included in the run list via `include_recipe` in the application default recipe based on the type matching one of the `server_roles` values.\n\nNote about `databases`, the data specified will be rendered as the `database.yml` file. In the `database` cookbook, this information is also used to set up privileges for the application user, and create the databases.\n\nNote about gems and packages, the version is optional. If specified, the version will be passed as a parameter to the resource. Otherwise it will use the latest available version per the default `:install` action for the package provider.\n\n {\n \"id\": \"my_app\",\n \"server_roles\": [\n \"application specific role(s), typically the name of the app, e.g., my_app\",\n \"my_app\"\n ],\n \"type\": {\n \"my_app\": [\n \"recipes in this application cookbook to run for this role\",\n \"rails\",\n \"unicorn\"\n ]\n },\n \"memcached_role\": [\n \"name of the role used for the app-specific memcached server\",\n \"my_app_memcached\"\n ],\n \"database_slave_role\": [\n \"name of the role used by database slaves, typically named after the app, 'my_app_database_slave'\",\n \"my_app_database_slave\"\n ],\n \"database_master_role\": [\n \"name of the role used by database master, typically named after the app 'my_app_database_master'\",\n \"my_app_database_master\"\n ],\n \"repository\": \"git@github.com:company/my_app.git\",\n \"revision\": {\n \"production\": \"commit hash, branch or tag to deploy\"\n },\n \"force\": {\n \"production\": \"true or false w/o quotes to force deployment, see the rails.rb recipe\"\n },\n \"migrate\": {\n \"production\": \"true or false boolean to force migration, see rails.rb recipe\"\n },\n \"databases\": {\n \"production\": {\n \"reconnect\": \"true\",\n \"encoding\": \"utf8\",\n \"username\": \"db_user\",\n \"adapter\": \"mysql\",\n \"password\": \"awesome_password\",\n \"database\": \"db_name_production\"\n }\n },\n \"mysql_root_password\": {\n \"production\": \"password for the root user in mysql\"\n },\n \"mysql_debian_password\": {\n \"production\": \"password for the debian-sys-maint user on ubuntu/debian\"\n },\n \"mysql_repl_password\": {\n \"production\": \"password for the 'repl' user for replication.\"\n },\n \"snapshots_to_keep\": {\n \"production\": \"if using EBS, integer of the number of snapshots we're going to keep for this environment.\"\n },\n \"deploy_key\": \"SSH private key used to deploy from a private git repository\",\n \"deploy_to\": \"path to deploy, e.g. /srv/my_app\",\n \"owner\": \"owner for the application files when deployed\",\n \"group\": \"group for the application files when deployed\",\n \"packages\": {\n \"package_name\": \"specific packages required for installation at the OS level to run the app like libraries and specific version, e.g.\",\n \"curl\": \"7.19.5-1ubuntu2\"\n },\n \"gems\": {\n \"gem_name\": \"specific gems required for installation to run the application, and if a specific version is required, e.g.\",\n \"rails\": \"2.3.5\"\n },\n \"memcached\": {\n \"production\": {\n \"namespace\": \"specify the memcache namespace, ie my_app_environment\"\n }\n }\n }\n\n---\nUsage\n=====\n\nTo use the application cookbook, we recommend creating a role named after the application, e.g. `my_app`. This role should match one of the `server_roles` entries, that will correspond to a `type` entry, in the databag. Create a Ruby DSL role in your chef-repo, or create the role directly with knife.\n\n % knife role show my_app\n {\n \"name\": \"my_app\",\n \"chef_type\": \"role\",\n \"json_class\": \"Chef::Role\",\n \"default_attributes\": {\n },\n \"description\": \"\",\n \"run_list\": [\n \"recipe[application]\"\n ],\n \"override_attributes\": {\n }\n }\n\nAlso recommended is a cookbook named after the application, e.g. `my_app`, for additional application specific setup such as other config files for queues, search engines and other components of your application. The `my_app` recipe can be used in the run list of the role, if it includes the `application` recipe.\n\nYou should also have a role for the environment(s) you wish to use this cookbook. Similar to the role above, create the Ruby DSL file in chef-repo, or create with knife directly.\n\n % knife role show production\n {\n \"name\": \"production\",\n \"chef_type\": \"role\",\n \"json_class\": \"Chef::Role\",\n \"default_attributes\": {\n \"app_environment\": \"production\"\n },\n \"description\": \"production environment role\",\n \"run_list\": [\n\n ],\n \"override_attributes\": {\n }\n }\n\nThis role uses a default attribute so nodes can be moved into other environments on the fly simply by modifying their node object directly on the Chef Server.\n\n---\nLicense and Author\n==================\n\nAuthor:: Adam Jacob (<adam@opscode.com>)\nAuthor:: Joshua Timberman (<joshua@opscode.com>)\n\nCopyright 2009-2010, Opscode, Inc.\n\nLicensed under the Apache License, Version 2.0 (the \"License\");\nyou may not use this file except in compliance with the License.\nYou may obtain a copy of the License at\n\n http://www.apache.org/licenses/LICENSE-2.0\n\nUnless required by applicable law or agreed to in writing, software\ndistributed under the License is distributed on an \"AS IS\" BASIS,\nWITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\nSee the License for the specific language governing permissions and\nlimitations under the License.\n",
"maintainer": "Opscode, Inc.",
"maintainer_email": "cookbooks@opscode.com",
"license": "Apache 2.0",
@@ -49,5 +49,5 @@
"application::rails_nginx_ree_passenger": "Deprecated recipe that deployed a rails application under Ruby Enterprise Edition, Passenger and Nginx",
"application::unicorn": "Sets up the deployed Rails application with Unicorn as the web server"
},
- "version": "0.6.3"
+ "version": "0.7.0"
}
View
4 radiant/metadata.json
@@ -1,7 +1,7 @@
{
"name": "radiant",
"description": "Installs radiant from Git repository",
- "long_description": "= DESCRIPTION:\n\nInstalls RadiantCMS, a Ruby on Rails content management system.\n\n= REQUIREMENTS:\n\n== Platform:\n\nThe db_bootstrap recipe requires using the Opscode application cookbook.\n\nTested on Ubuntu 9.04, uses the Opscode Apache2 cookbook which is Ubuntu/Debian specific.\n\nRequires Chef 0.7.12 for Deploy resource when installing from Radiant's git repo.\n\n== Cookbooks:\n\nOpscode cookbooks (http://github.com/opscode/cookbooks/tree/master)\n\n* git\n* sqlite\n* rails\n* apache2\n\n= ATTRIBUTES:\n\n* radiant[:edge] - Do a deploy from github repo if true, use gems if false, default false.\n* radiant[:branch] - Branch to deploy from, default HEAD.\n* radiant[:migrate] - Whether to do a database migration, default false.\n* radiant[:migrate_command] - Command to do a database migration, default 'rake db:migrate'.\n* radiant[:environment] - Rails environment to use, default is production.\n* radiant[:revision] - Revision to deploy, default HEAD.\n* radiant[:action] - Whether to deploy, rollback or nothing, default nothing.\n* radiant[:db_bootstrap] - rake task to bootstrap a fresh database, use once and with care, it will delete the database contents.\n\n= USAGE:\n\nThis recipe uses SQLite3 for the database by default. To set up the default database to get Radiant rolling, run a db:bootstrap by changing the radiant[:migrate] command to the following in the webui:\n\n yes | rake production db:bootstrap \\\n ADMIN_NAME=Administrator \\\n ADMIN_USERNAME=admin \\\n ADMIN_PASSWORD=radiant \\\n DATABASE_TEMPLATE=empty.yml\n\nChange as required for your environment. If the target system doesn't have /usr/bin/yes, use echo 'yes' instead.\n\nRadiant supports other database backends. We don't yet have automation ready to set up a database user and grant privileges, or creating the database itself.\n\n== Database Bootstrap\n\nThis recipe is DESTRUCTIVE.\n\nNormally when running the db:bootstrap rake task in Radiant, it prompts the user:\n\nThis task will destroy any data in the database. Are you sure you want to continue? [yn] y\n\nThis recipe wraps the rake db:bootstrap from above. Only use this recipe if you know what you are doing. Otherwise, run the db:bootstrap manually.\n\nThis recipe is designed to be used with the Opscode application cookbook, and only one time.\n\n= LICENSE and AUTHOR:\n\n\nAuthor:: Joshua Timberman (<joshua@opscode.com>)\nCopyright:: 2009, Opscode, Inc.\n\nLicensed under the Apache License, Version 2.0 (the \"License\");\nyou may not use this file except in compliance with the License.\nYou may obtain a copy of the License at\n\n http://www.apache.org/licenses/LICENSE-2.0\n\nUnless required by applicable law or agreed to in writing, software\ndistributed under the License is distributed on an \"AS IS\" BASIS,\nWITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\nSee the License for the specific language governing permissions and\nlimitations under the License.\n\n\n",
+ "long_description": "= DESCRIPTION:\n\nInstalls RadiantCMS, a Ruby on Rails content management system.\n\n= REQUIREMENTS:\n\n== Platform:\n\nThe db_bootstrap recipe requires using the Opscode application cookbook.\n\nTested on Ubuntu 9.04, uses the Opscode Apache2 cookbook which is Ubuntu/Debian specific.\n\nRequires Chef 0.7.12 for Deploy resource when installing from Radiant's git repo.\n\nThe `db_bootstrap` recipe requires Chef 0.9.10+ for the notifies resource syntax.\n\n== Cookbooks:\n\nOpscode cookbooks (http://github.com/opscode/cookbooks/tree/master)\n\n* git\n* sqlite\n* rails\n* apache2\n\n= ATTRIBUTES:\n\n* radiant[:edge] - Do a deploy from github repo if true, use gems if false, default false.\n* radiant[:branch] - Branch to deploy from, default HEAD.\n* radiant[:migrate] - Whether to do a database migration, default false.\n* radiant[:migrate_command] - Command to do a database migration, default 'rake db:migrate'.\n* radiant[:environment] - Rails environment to use, default is production.\n* radiant[:revision] - Revision to deploy, default HEAD.\n* radiant[:action] - Whether to deploy, rollback or nothing, default nothing.\n* radiant[:db_bootstrap] - rake task to bootstrap a fresh database, use once and with care, it will delete the database contents.\n\n= USAGE:\n\nThis recipe uses SQLite3 for the database by default. To set up the default database to get Radiant rolling, run a db:bootstrap by changing the radiant[:migrate] command to the following in the webui:\n\n yes | rake production db:bootstrap \\\n ADMIN_NAME=Administrator \\\n ADMIN_USERNAME=admin \\\n ADMIN_PASSWORD=radiant \\\n DATABASE_TEMPLATE=empty.yml\n\nChange as required for your environment. If the target system doesn't have /usr/bin/yes, use echo 'yes' instead.\n\nRadiant supports other database backends. We don't yet have automation ready to set up a database user and grant privileges, or creating the database itself.\n\n== Database Bootstrap\n\nThis recipe is DESTRUCTIVE.\n\nNormally when running the db:bootstrap rake task in Radiant, it prompts the user:\n\nThis task will destroy any data in the database. Are you sure you want to continue? [yn] y\n\nThis recipe wraps the rake db:bootstrap from above. Only use this recipe if you know what you are doing. Otherwise, run the db:bootstrap manually.\n\nThis recipe is designed to be used with the Opscode application cookbook, and only one time. It removes itself with a Ruby block resource when the rake resource executes successfully.\n\n= LICENSE and AUTHOR:\n\n\nAuthor:: Joshua Timberman (<joshua@opscode.com>)\nCopyright:: 2009, Opscode, Inc.\n\nLicensed under the Apache License, Version 2.0 (the \"License\");\nyou may not use this file except in compliance with the License.\nYou may obtain a copy of the License at\n\n http://www.apache.org/licenses/LICENSE-2.0\n\nUnless required by applicable law or agreed to in writing, software\ndistributed under the License is distributed on an \"AS IS\" BASIS,\nWITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\nSee the License for the specific language governing permissions and\nlimitations under the License.\n\n\n",
"maintainer": "Opscode, Inc.",
"maintainer_email": "cookbooks@opscode.com",
"license": "Apache 2.0",
@@ -135,5 +135,5 @@
"radiant": "Installs Radiant CMS",
"radiant::db_bootstrap": "Bootstrap the Radiant database, used with application cookbook (destructive)"
},
- "version": "0.11.2"
+ "version": "0.11.3"
}
Please sign in to comment.
Something went wrong with that request. Please try again.