From 40335fc4539a1b7c69c7306ac8a5455ae304133c Mon Sep 17 00:00:00 2001 From: Rob Hirschfeld Date: Fri, 18 Jan 2013 08:44:36 -0800 Subject: [PATCH] fix from BDD move, docs cleanup --- dev | 9 +- doc/barclamps.md | 0 doc/deployguide.md | 0 doc/devguide.md | 0 doc/devguide/api.md | 0 doc/devguide/api/attrib.md | 128 ------------ doc/devguide/api/barclamp.md | 44 ----- doc/devguide/api/group.md | 187 ------------------ doc/devguide/api/jig.md | 130 ------------ doc/devguide/api/node.md | 144 -------------- doc/devguide/api/proposal.md | 29 --- doc/devguide/api/status.md | 42 ---- .../{#tempate.md => template.md.reference} | 0 doc/devguide/barclamps.md | 0 doc/devguide/browser-support.md | 0 doc/devguide/building.md | 0 doc/devguide/devtool.md | 0 doc/devguide/testing.md | 0 doc/devguide/testing/bdd.md | 0 doc/devguide/testing/bdd/dsl.md | 55 ------ doc/devguide/testing/bdd/internals.md | 53 ----- doc/devguide/testing/bdd/internals/config.md | 68 ------- doc/devguide/testing/bdd/internals/json.md | 32 --- doc/devguide/testing/bdd/steps.md | 163 --------------- doc/devguide/testing/bdd/steps_rest.md | 145 -------------- doc/devguide/testing/chefspec.md | 0 doc/devguide/testing/rspec.md | 0 doc/devguide/testing/units.md | 0 doc/devguide/ui.md | 0 doc/devguide/ui/documentation.md | 101 ---------- doc/devguide/ui/localization.md | 21 -- doc/devguide/ui/navigation.md | 35 ---- doc/framework.yml | 5 + doc/gettingstarted.md | 0 doc/licenses.md | 0 doc/releasenotes.md | 0 doc/userguide.md | 0 .../master/extra/barclamp_mgmt_lib.rb | 7 + 38 files changed, 16 insertions(+), 1382 deletions(-) mode change 100755 => 100644 doc/barclamps.md mode change 100755 => 100644 doc/deployguide.md mode change 100755 => 100644 doc/devguide.md mode change 100755 => 100644 doc/devguide/api.md delete mode 100755 doc/devguide/api/attrib.md delete mode 100755 doc/devguide/api/barclamp.md delete mode 100755 doc/devguide/api/group.md delete mode 100755 doc/devguide/api/jig.md delete mode 100755 doc/devguide/api/node.md delete mode 100755 doc/devguide/api/proposal.md delete mode 100755 doc/devguide/api/status.md rename doc/devguide/api/{#tempate.md => template.md.reference} (100%) mode change 100755 => 100644 mode change 100755 => 100644 doc/devguide/barclamps.md mode change 100755 => 100644 doc/devguide/browser-support.md mode change 100755 => 100644 doc/devguide/building.md mode change 100755 => 100644 doc/devguide/devtool.md mode change 100755 => 100644 doc/devguide/testing.md mode change 100755 => 100644 doc/devguide/testing/bdd.md delete mode 100755 doc/devguide/testing/bdd/dsl.md delete mode 100755 doc/devguide/testing/bdd/internals.md delete mode 100755 doc/devguide/testing/bdd/internals/config.md delete mode 100755 doc/devguide/testing/bdd/internals/json.md delete mode 100755 doc/devguide/testing/bdd/steps.md delete mode 100755 doc/devguide/testing/bdd/steps_rest.md mode change 100755 => 100644 doc/devguide/testing/chefspec.md mode change 100755 => 100644 doc/devguide/testing/rspec.md mode change 100755 => 100644 doc/devguide/testing/units.md mode change 100755 => 100644 doc/devguide/ui.md delete mode 100755 doc/devguide/ui/documentation.md delete mode 100755 doc/devguide/ui/localization.md delete mode 100755 doc/devguide/ui/navigation.md create mode 100644 doc/framework.yml mode change 100755 => 100644 doc/gettingstarted.md mode change 100755 => 100644 doc/licenses.md mode change 100755 => 100644 doc/releasenotes.md mode change 100755 => 100644 doc/userguide.md mode change 100755 => 100644 releases/development/master/extra/barclamp_mgmt_lib.rb diff --git a/dev b/dev index 13570296c20..cf5274c93e9 100755 --- a/dev +++ b/dev @@ -3821,8 +3821,8 @@ setup_unit_tests() ( "install Crowbar, so results may differ." fi - cd "$CROWBAR_TEST_DIR/crowbar_framework/BDD" - sudo "$CROWBAR_TEST_DIR/crowbar_framework/BDD/linux_install.sh" + cd "$CROWBAR_TEST_DIR/BDD" + sudo "$CROWBAR_TEST_DIR/BDD/linux_install.sh" ./linux_compile.sh current_build >"$CROWBAR_TEST_DIR/.build" ) @@ -3848,9 +3848,8 @@ reload_unit_tests() ( done done fi - cd "$CROWBAR_TEST_DIR/crowbar_framework/BDD" + cd "$CROWBAR_TEST_DIR/BDD" ./linux_compile.sh - sed -ie 's/192.168.124.10/127.0.0.1/' "crowbar.config" ) run_unit_tests() ( @@ -3873,7 +3872,7 @@ run_unit_tests() ( # Start rails bundle exec script/rails s Puma >> log/test.out 2>> log/test.err & sleep 10 - (cd BDD; erl -s bdd test crowbar -s init stop -noshell) || final_result=fail + (cd "$CROWBAR_TEST_DIR/BDD"; erl -s bdd test devtool -s init stop -noshell) || final_result=fail kill $(ps -ef | grep Puma | grep ruby | awk '{ print $2 }') # Run chef unit tests diff --git a/doc/barclamps.md b/doc/barclamps.md old mode 100755 new mode 100644 diff --git a/doc/deployguide.md b/doc/deployguide.md old mode 100755 new mode 100644 diff --git a/doc/devguide.md b/doc/devguide.md old mode 100755 new mode 100644 diff --git a/doc/devguide/api.md b/doc/devguide/api.md old mode 100755 new mode 100644 diff --git a/doc/devguide/api/attrib.md b/doc/devguide/api/attrib.md deleted file mode 100755 index 339341f9411..00000000000 --- a/doc/devguide/api/attrib.md +++ /dev/null @@ -1,128 +0,0 @@ -### Attribute (aka Attrib) APIs - -Attribute APIs are used to manage attributes tracked by the Jig system - -> To prevent Rails name collisions, Crowbar uses 'Attrib' instead of Attribute. - -#### Attrib CRUD - -List, Create, Read, Delete actions for Attribute - -> There is no update at this time! - -##### List - -Returns list of Attrib id:names in the system - -**Input:** - - - - - - - -
Verb URL Options Returns Comments
GET /2.0/crowbar/2.0/attrib - -
- - -**Output:** - - { - 1:"ram", - 2:"cpu", - 4:"nics" - } - -Details: - -* id - Attrib id -* name - Attrib name - -##### Read - -**Input:** - - - - - - - -
Verb URL Options Returns Comments
GET /2.0/crowbar/2.0/attrib/[id] id is the Attrib ID or name. -
- - -**Output:** - - { - "id":4, - "name":"ram", - "description":null, - "order":10000, - "barclamp_id":40, - "hint":null, - "created_at":"2012-08-13T17:20:21Z", - "updated_at":"2012-08-13T17:20:21Z" - } - -Details: - -* Format - json -* id - Attrib id -* name - Attrib name -* barclamp_id - relation with barclamp (attribute only has 1) -* hint - helps the barclamp figure out how to populate the attribute. should be assigned by the attribute - -##### Attrib CRUD: Create - -Creates a new Attrib - -**Input:** - - - - - - - -
Verb URL Options Returns Comments
POST /2.0/crowbar/2.0/attrib/ json definition (see Attrib Show) must be a legal object
- -**Input:** - - { - "name":"chef", - "description":"description", - "order":10000, - } - -Details: - -* name (required) - Attrib name (must be letters - numbers and start with a letter) -* description - optional (default null) -* order - optional (default 10000) - -##### Attrib CRUD: Delete - -Deletes an Attrib - -**Input:** - - - - - - - -
Verb URL Options Returns Comments
DELETE /2.0/crowbar/2.0/attrib/[id] Database ID or name must be an existing object ID
- -No body. - -**Ouptut** - -None. - -Details: - -* id - Attrib name or database ID - - - diff --git a/doc/devguide/api/barclamp.md b/doc/devguide/api/barclamp.md deleted file mode 100755 index cd3dd7832fc..00000000000 --- a/doc/devguide/api/barclamp.md +++ /dev/null @@ -1,44 +0,0 @@ -### Barclamp APIs - -Barclamps are the core modulization for Crowbar. For that reason, the API for barclamps is more limited because changes to barclamps can cause breaking changes to the framework. - -#### Barclamp List - -**Input:** - - - - -
Verb URL Options Returns Comments
GET /2.0/crowbar/2.0/barclamp none All barclamps -
- -**Output:** - - - { - 1:"crowbar", - 2:"deployer", - 3:"impi" - } - -#### Barclamp Get - -**Input:** - - - - -
Verb URL Options Returns Comments
GET /2.0/crowbar/2.0/barclamp/[:id] none Barclamp -
- -**Output:** - - - { - "id":1, - "name":"crowbar", - "description":"this is about the barclamp" - } - - -#### Not Supported - -Barclamp API does not support create, update and delete operations. diff --git a/doc/devguide/api/group.md b/doc/devguide/api/group.md deleted file mode 100755 index aa0b70cc9c3..00000000000 --- a/doc/devguide/api/group.md +++ /dev/null @@ -1,187 +0,0 @@ -### Group APIs - -Group APIs are used to manage groups. Groups are used to organized things - -#### Group CRUD - -Create, Read, Update, Delete actions for Groups - -##### List - -Returns list of group id:names in the system - -> Note: Category is not included in this list - -**Input:** - - - - - - - -
Verb URL Options Returns Comments
GET /2.0/crowbar/2.0/group - -
- - -**Output:** - - { - 1:"not_set", - 2:"rock_n_role", - 4:"group_of_wrath" - } - -Details: - -* id - Node id -* name - Node name - -##### Read - -**Input:** - - - - - - - -
Verb URL Options Returns Comments
GET /2.0/crowbar/2.0/group/[id] id is the group ID or name. -
- - -**Output:** - - { - "id":4, - "name":"greg.example.com", - "description":null, - "order":10000, - "category":"ui", - ... - "created_at":"2012-08-13T17:20:21Z", - "updated_at":"2012-08-13T17:20:21Z" - } - -Details: - -* Format - json -* id - Node id -* name - Node name -* category - one of the allowed categories in lowercase: ui, rack -* all Node properties serialized - -##### Group CRUD: Create - -Creates a new group - -**Input:** - - - - - - - -
Verb URL Options Returns Comments
POST /2.0/crowbar/2.0/node/ json definition (see Node Show) must be a legal object
- -**Input:** - - { - "id":1 - "name":"fqdn.example.com", - "description":"description", - "category":"ui" - "order":10000, - } - -Details: - -* name - group name (must be letters - numbers and start with a letter) -* description - optional (default null) -* category - (default = ui) determines the collection of groups. Allowed categories are - * ui - * rack -* order - optional (default 10000) - -##### Group CRUD: Delete - -Deletes a group - -**Input:** - - - - - - - -
Verb URL Options Returns Comments
DELETE /2.0/crowbar/2.0/group/[id] Database ID or name must be an existing object ID
- -No body. - -**Ouptut** - -None. - -Details: - -* id - Group name or database ID - -#### Node Actions on Groups - -These actions are for showing adding, removing, or moving nodes in groups - -On success, They all return the same result as the Show method - -> _Note_: This these methods are used by the UI for drag and drop group management - -**Input:** - - - - - - - - - - - - - - - - - - - - - - - -
Verb URL Options Returns Comments
GET /2.0/crowbar/2.0/group/[group-id]/node none json list of nodes (see below) Shows nodes that below to group
POST /2.0/crowbar/2.0/group/[group-id]/node/[node-id] none json definition (see Node Show) Add node to group
PUT /2.0/crowbar/2.0/group/[group-id]/node/[node-id] none json definition (see Group Node Show) Move Node from Group 1 to Group 2
DELETE /2.0/crowbar/2.0/group/[group-id]/node/[node-id] none json definition (see Node Show) Removes a node from an existing group
- -> _Note_: Move a node from an existing group to an another group _in the same category_. This is effectively a combined delete/add action. - - -Details: - -* All data is contained in the URL (no body required) -* group-id: id of the group (can be name) -* node-id: id if the node (can be name) - -**Output:** - - { - "id": # - "nodes": {"[group_id#]":"[group_name]"}, - "name":"[group_name]", - "category":"[group_category]"} - } - -**Errors:** - -* 404 if node requested is not found -* 404 if group requested is not found - - diff --git a/doc/devguide/api/jig.md b/doc/devguide/api/jig.md deleted file mode 100755 index 6c18d09841b..00000000000 --- a/doc/devguide/api/jig.md +++ /dev/null @@ -1,130 +0,0 @@ -### Jig APIs - -Jig APIs are used to manage configuration management databases. - -> WARNING: You cannot simply add a new Jig type via the API! Jig object types must have a matching jig class override! The primary function of this API is to manage the related Jig subobjects. You can have multiple Jigs of the same type. - -#### Jig CRUD - -List, Create, Read, Delete actions for Jigs - -> There is no update at this time! - -##### List - -Returns list of Jig id:names in the system - -**Input:** - - - - - - - -
Verb URL Options Returns Comments
GET /2.0/crowbar/2.0/jig - -
- - -**Output:** - - { - 1:"chef", - 2:"puppet", - 4:"test" - } - -Details: - -* id - Jig id -* name - Jig name - -##### Read - -**Input:** - - - - - - - -
Verb URL Options Returns Comments
GET /2.0/crowbar/2.0/jig/[id] id is the jig ID or name. -
- - -**Output:** - - { - "id":4, - "name":"chef", - "description":null, - "order":10000, - "type":"JigChef", - "created_at":"2012-08-13T17:20:21Z", - "updated_at":"2012-08-13T17:20:21Z" - } - -Details: - -* Format - json -* id - Jig id -* name - Jig name -* all Node properties serialized - -##### Jig CRUD: Create - -Creates a new Jig - -**Input:** - - - - - - - -
Verb URL Options Returns Comments
POST /2.0/crowbar/2.0/jig/ json definition (see Jig Show) must be a legal object
- -**Input:** - - { - "name":"chef", - "description":"description", - "order":10000, - "type":"JigChef" - } - -Details: - -* name (required) - Jig name (must be letters - numbers and start with a letter) -* description - optional (default null) -* type (required) - name of the object that manages the Jig calls -* order - optional (default 10000) - -> The type must match an existing class in the system - -##### Jig CRUD: Delete - -Deletes a Jig - -**Input:** - - - - - - - -
Verb URL Options Returns Comments
DELETE /2.0/crowbar/2.0/jig/[id] Database ID or name must be an existing object ID
- -No body. - -**Ouptut** - -None. - -Details: - -* id - Jig name or database ID - - - diff --git a/doc/devguide/api/node.md b/doc/devguide/api/node.md deleted file mode 100755 index 43c3615bdfd..00000000000 --- a/doc/devguide/api/node.md +++ /dev/null @@ -1,144 +0,0 @@ -### Node APIs - -Node APIs are used to manage nodes (servers) within the Crowbar system - -#### Node Show (all) - -**Input:** - - - - - - -
Verb URL Options Returns Comments
GET /2.0/crowbar/2.0/node no options Specialized return
- - -**Output:** - - { - 4:"greg.example.com", - 5:"rob.example.com" - } - -Details: - -* json format is id: Node name - -#### Node Show (single) - -**Input:** - - - - - - -
Verb URL Options Returns Comments
GET /2.0/crowbar/2.0/node/[id] id is the node ID or name.
- - -**Output:** - - { - "id":4, - "fingerprint":-1224971211, - "state":null, - "name":"greg.example.com", - "description":null, - "order":10000, - ... - "created_at":"2012-08-13T17:20:21Z", - "updated_at":"2012-08-13T17:20:21Z" - } - -Details: - -* id - Node id -* name - Node name -* all Node properties serialized - -#### Node Create (API only) - -Creates a new node - -**Input:** - - - - -
Verb URL Options Returns Comments
POST /2.0/crowbar/2.0/node json definition (see Node Show) must be a legal object
- -**Input:** - - { - "name":"fqdn.example.com", - "description":"description", - "order":10000, - } - -Details: - -* name - Node name (must be FQDN) -* description - optional (default null) -* order - optional (default 10000) - -#### Node Delete (API only) - -Deletes a node - -**Input:** - - - - -
Verb URL Options Returns Comments
DELETE /2.0/crowbar/2.0/node/[id] Database ID or name must be an existing object ID
- -No body. - -**Ouptut** - -None. - -Details: - -* id - Node name or database ID (must be FQDN) - -### Node Attributes - -Node Attributes API is used to retrieve data about attributes that have been associated with a Node. - -Typically, attribute data is populated by the Jig system(s) based on the associations established using this API. - -#### Associations - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Verb URL Options Returns Comments
GET /2.0/crowbar/2.0/node/[id]/attribute none List of attribute IDs and names assigned to node
GET /2.0/crowbar/2.0/node/[id]/attribute/[id] none Last 100 readings (Event ID + Value)
POST /2.0/crowbar/2.0/node/[id]/attribute/[id] none Link Attribute to Node
PUT /2.0/crowbar/2.0/node/[id]/attribute/[id] none 405 error - Not enabled
DELETE /2.0/crowbar/2.0/node/[id]/attribute/[id] none Break association and remove data
- - - diff --git a/doc/devguide/api/proposal.md b/doc/devguide/api/proposal.md deleted file mode 100755 index f34d6a0fc9c..00000000000 --- a/doc/devguide/api/proposal.md +++ /dev/null @@ -1,29 +0,0 @@ -### Proposal APIs - -#### Proposal Status - -**Input:** - - - - - -
Verb URL Options Returns Comments
GET /2.0/crowbar/2.0/proposal/status none All proposals Used by Barclamp List
GET 2.0/crowbar/2.0/proposal/status/2.0/[id] id is the proposal ID. Used by Proposal Views
- -**Output:** - - - { - "i18n":{"unknown":"Unknown, requesting status...","ready":"Active"}, - "proposals":{"5":"ready","11":"ready" }, - "count":14, - "error":"" - } - -Details: - -* Format - json -* i18n - the localized versions of the status strings for display. Unknown is _always_ included -* proposals - the proposals (by database ID) requested in the API call with their current status -* count - the number of proposals returned, count < 0 indicates an error -* error - provides error information if the call returns an error diff --git a/doc/devguide/api/status.md b/doc/devguide/api/status.md deleted file mode 100755 index bad0eaf05be..00000000000 --- a/doc/devguide/api/status.md +++ /dev/null @@ -1,42 +0,0 @@ -### Status APIs - -Status APIs are used to provide lists of objects in optimized formats. - -The general pattern for the Status API calls is: - -> `status/2.0/object/[:id]` - -#### Node Status - -Returns JSON for node status. Includes hash of all nodes to help detect changes. - -**Input:** - - - - -
Verb URL Options Returns Comments
GET /status/2.0/node none All nodes Used by Dashboard -
GET /status/2.0/node/[id] id is the node ID or name. Used by Node details -
- -**Output:** - - { - "state":{"1":null}, - "sum":-1881043387, - "i18n":{"ready":"Ready"}, - "groups":{ - "0":{"failed":0,"ready":0,"building":0,"pending":0,"unready":1,"name":"all","unknown":0} - }, - "count":1, - "status":{"1":"unready"} - } - -Details: - -* Format - json -* i18n - the localized versions of the status strings for display. -* state - ? -* groups - ? -* status - ? -* count - ? -* sum - Hashed value of the nodes included to identify state changes for refresh diff --git a/doc/devguide/api/#tempate.md b/doc/devguide/api/template.md.reference old mode 100755 new mode 100644 similarity index 100% rename from doc/devguide/api/#tempate.md rename to doc/devguide/api/template.md.reference diff --git a/doc/devguide/barclamps.md b/doc/devguide/barclamps.md old mode 100755 new mode 100644 diff --git a/doc/devguide/browser-support.md b/doc/devguide/browser-support.md old mode 100755 new mode 100644 diff --git a/doc/devguide/building.md b/doc/devguide/building.md old mode 100755 new mode 100644 diff --git a/doc/devguide/devtool.md b/doc/devguide/devtool.md old mode 100755 new mode 100644 diff --git a/doc/devguide/testing.md b/doc/devguide/testing.md old mode 100755 new mode 100644 diff --git a/doc/devguide/testing/bdd.md b/doc/devguide/testing/bdd.md old mode 100755 new mode 100644 diff --git a/doc/devguide/testing/bdd/dsl.md b/doc/devguide/testing/bdd/dsl.md deleted file mode 100755 index e7fb6b7742b..00000000000 --- a/doc/devguide/testing/bdd/dsl.md +++ /dev/null @@ -1,55 +0,0 @@ -### BDD Domain Specific Language (DSL) - -The BDD DSL is designed to be very natural language like. There are 4 primary clauses in the DSL: - -1. General Purpose Steps - 1. **Given** ... some background thing has happened - 1. **When** ... take some action - 1. **Then** ... get some result -1. Special Purpose Steps; - 1. **Skip** ... will disable the test (please provide a reason after the skip) - 1. **Unless** environment ... will only run the test in the environments included after the Unless - 1. **Finally** ... cleanup actions (optional) - -Feature files may also include **setup** and **tear down** steps that are essential for creating input data for tests. In some cases, tests require information to be in place _before_ the Given step. - -### Writing Feature Tests - -Test files all end with the extension `.feature` and contain "plain English" scripts for testing features. This is known as the BDD DSL. While it looks like plain language, it is very specifically mapped into the testing framework and _must_ follow the DSL guidelines. - -A feature file (in the `features` directory) is broken into specific "scenarios" to be tested. Each scenario is effectively a test and has multiple steps. They all start with a known state expressed using given or when instructions. The state is then tested using then checks. The concept is to mirror actions that a user takes: when the user takes this action then they should see these results. Yes, it's that simple! - -A scenario must include a when statement but the given statement is optional. Given is used to setup a scenario before the when action is taken. This is very important for testing linking from a page. For example, _given_ that I'm on the nodes list page _when_ I click on the all link _then_ I should get a list that includes the admin node. BDD's goal is to turn those types of directives into tests. - -#### HTML Tests - -The following sentences can be used for testing HTML web pages where you can change the information in "quotes". - -* Given I am on the home page -* Given I am on the "dashboard" page -* Given there is a node "foo.example.com" -* When I go to the home page -* When I go to the "node/2.0/1" page -* When I click on the "Dashboard" menu item -* Then I should see "Full Name" -* Then there should be no translation errors -* Then I should not see "Error" -* Finally throw away node "foo.example.com" - -> Note: This is _not_ a complete list! To get a complete list of the tests use the `bdd:steps().` command. - - -#### REST/AJAX Tests - -The following sentences can be used for testing REST JSON (aka AJAX) API calls where you can change the information in - -* When REST requests the "2.0/node/status" page -* Then key "fingerprint" should be a number -* Then key "[nodes][admin][state]" should be "Ready" -* Then key "count" should be "0" -* Then key "[groups][0]" should contain "7" items -* Finally throw away node "foo.bar.com" - -> Note: This is _not_ a complete list! - -> Note: We are migrating to use "REST" instead of "AJAX" diff --git a/doc/devguide/testing/bdd/internals.md b/doc/devguide/testing/bdd/internals.md deleted file mode 100755 index 96f7a5ddcce..00000000000 --- a/doc/devguide/testing/bdd/internals.md +++ /dev/null @@ -1,53 +0,0 @@ -### BDD Internals - -This section documents the internal working of the BDD code framework. The audience for this section is for developers who are extended the BDD system and want to learn more about how it operates. - -Information about creating tests and tests should be included in other parts of the guide. - -#### Logging (bdd_utils:log) - -The BDD system has a logging utility that is managed from the Configuration file. - -The core logging call is `bdd_utils:log(Config, Level, Message, Data).` Shortcuts have been created, but are not recommended because they do not leverage ability for users the change the logging levels! The short cuts are: `log(Level, Message, Data)`, `log(Message, Data)`, and `log(Message)` where the assumed Level is `info` - -The logging system offers several levels: - -1. true - always show the message -1. puts - always shows for debugging info that should be removed and not left in the code -1. dump - the lowest level of in-code statement used to output items that take up multiple lines -1. trace - very verbose but helps trace entry of routines (do NOT dump objects using trace!) -1. debug - general information used for debugging problems and common issues -1. info - useful data about normal operations -1. warn - actions that are not normal and may require investigation -1. depricate - helps find class that have been depricated -1. custom - you can define your own levels (e.g.: using your name, mascot or martian crater) as long as you remember to include it in the configuration list. - -To set the log level from the Erlang command prompt, use the helper 'bdd_utils:log_level(debug)' or other level. The `log_level` command will include the correct items. Users can manually set the logging level by including the desired level in the configuration. Levels must be added explicitly! There is no assumption of inclusion: if you want `trace` and `warn` then you need to add both to the logging list. - - -> The legacy `debug` methods are depricated and should be avoided! - -You can use the log information in two ways - -1. modify the configuration file when running tests (applies to all tests) -1. use `bdd:debug(config, feature, scenario_id#, [log, level, list]).` to call a single scenario with custom logging. If you omit the list then it will default to `[puts, debug, info, warn]` - -> Log messages can be very verbose! Generally, running just 1 scenario is enough information for debugging. - -#### Logging for Titles - -The information shown during test runs is also generated by the logging but managed by the "titles" config. - -The log titles are - -1. Feature Titles - 1. header - BDD general information - 1. result - Results from a run - 1. feature - Feature introduction -1. Scenario Titles - 1. pass - scenario passed - 1. fail - scenario failed - 1. skip - scanario skipped - 1. step - same as pass - 1. step_pass - details about step passed (used when failed) - 1. step_fail - defails about step failed (used when failed) \ No newline at end of file diff --git a/doc/devguide/testing/bdd/internals/config.md b/doc/devguide/testing/bdd/internals/config.md deleted file mode 100755 index 06cbe52e522..00000000000 --- a/doc/devguide/testing/bdd/internals/config.md +++ /dev/null @@ -1,68 +0,0 @@ -#### BDD Config - -The BDD configuration file contains information that tells BDD how to execute. While BDD adds to this file during execution, users choose which values it starts with. - -BDD selects the `default.config` file automatically. You can choose which configuration to load by passing it into the `bdd:test(config)` or `bdd:feature(config, feature)` methods. - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ItemRequiredDefaultComment
URLYesnoneThis is the URL that BDD will use for testing
usernononeIf your site requires auth, then this is required
passwordnononeIf your site requires auth, then this is required. WARNING: Retained in clear text! Do not store production passwords here!
logno[true, puts, info, warn, error]used by bdd_utils:log printouts. Create list with none, some or all of the following: [puts, trace, debug, info, warn]
titlesno[pass, fail, skip, header, result, feature, step, step_pass, step_fail]used by bdd_utils:log printouts.
environmentnoundefinedused by Unless step prefix to skip tests
results_outno../tmp/bdd_results.outstores the detailed results of the tests. Used by bdd:failed().
- -##### Example Config - - %%-*-erlang-*- - {url, "http://192.168.124.10:3000"}. - {user, "developer"}. - {password,"Cr0wbar!"}. - {feature_path,"features/"}. - {extension, "feature"}. - {global_setup, crowbar}. - {secondary_step_files, [crowbar_rest, crowbar, bdd_webrat, bdd_restrat, bdd_catchall]}. - {translation_error, "translation_missing"}. diff --git a/doc/devguide/testing/bdd/internals/json.md b/doc/devguide/testing/bdd/internals/json.md deleted file mode 100755 index 6e42e560f1b..00000000000 --- a/doc/devguide/testing/bdd/internals/json.md +++ /dev/null @@ -1,32 +0,0 @@ -#### JSON Parser - -The BDD JSON parser is designed as a stand-alone JSON parser. It is used to support REST API calls - -The JSON parser turns JSON (`{Key1:Value1, Key2:Value2}`)into an Erlang Tuple List (`[{Key1, Value1}, {Key2, Value2}]`) where each key-value pair becomes an Erlang tuple. If the JSON is nested, then the Erlang will also nest the JSON. - -> Arrays & the JSON parser. The parser converts JSON Arrays into Hash where the key values are a numbered index. For example, `{Key:[Arr1, Arr2, Arr3]}` becomes `[{Key, [{0, Arr1}, {1, Arr2}, {2, Arr3}]}]`. - -##### Records -The JSON parser uses Erlang records to pass data between the recursive routines. - -* json is used by the top level parser -* jsonkv is used by the value subparser - -##### Keyfind & Value List -Keyfind is a helper to make DRY the lists:keyfind code. This is a very simple, 1st order search. - -Value is similar to keyfind, but performs a more exhaustive search of the JSON - -##### Parser Workers - -* parse calls the json parser functions -* json is the primary worker that identifies keys and then uses json_value to resolve matching values -* json_value uses the : as a token and resolves/recurses to retrieve the value for a key -* json_array is similar to json_value but handles the [] array values -* json_value_quoted is used to find values inside of quotes - -##### Pretty -Formats the JSON parse output into a human readable, intended format - -##### Output -Turns the erlang list from the parser back into JSON diff --git a/doc/devguide/testing/bdd/steps.md b/doc/devguide/testing/bdd/steps.md deleted file mode 100755 index d92d38e9b20..00000000000 --- a/doc/devguide/testing/bdd/steps.md +++ /dev/null @@ -1,163 +0,0 @@ -### Extending the DSL - -Each feature definition can add it's own ERL step parser. The BDD system will automatically search for a step definition based on the feature name. It will also automatically search the "crowbar" and "webrat" steps. - -The webrat steps are designed to be general purpose Web access checks. If you find yourself doing a routine HTTP or AJAX request then it likely belongs in the webrat file instead of your feature steps. - -You can add custom step files from the config page. - - -#### Steps - -All of the BDD tests decompose into the same Erlang method, known as the `step` method. The BDD test engine will search in multiple Erlang code files for steps in a specific order. - - > The steps have been defined to ensure that the last file tried (`bdd_catchall`) contains steps that have been defined to match all possible cases. If the final catchall step is reached, that step will generate a stub step that you can use to create a new step. - -A step is a standard Erlang function with 3 parameters: - -1. The BDD configuration file -1. The pass forward file that represents the accumulated output of previous steps -1. The DSL tuple populated by BDD as follows - 1. keyword (setup, teardown, given, when, or then) - 1. step number - 1. list of the DSL string tokenized by quotes - - > If you are terrified by the phrase "tokenized by quotes" then relax. That just means that BDD turns your friendly `when I click on link "foo"` into an Erlang list that is super easy to parse: ["when I click on link", Foo]. - -Let's look at an example step: - - step(Config, _Global, {step_given, {_ScenarioID, _N}, ["I went to the", Page, "page"]}) -> - bdd_utils:http_get(Config, Page); - -This step will match the DSL `Given I went to the "dashboard" page` in the scenario. It simply does an HTTP get using the BDD utilities. The `http_get` routine takes the base URL from the config file and adds the page information from the sentence. BDD will take the result of this step function and add it to the `Given` list that is passed into all following 'when' steps. - - > You can also use `{` and `}` for delimiters. Generally, these delimiters are used for special items like class types. - > Reminder: Erlang variables that start with "\_" are considered optional and don't throw a warning if they are not used. If you plan to use those variables, you can keep the "\_", however, I recommend removing it for clarity. - -There is a simple output expectation from all steps: - -* setup steps add to the Global list that is passed into Given steps -* given steps add to the Given list that is passed into When steps -* when steps add to the Results list that is passed into the Results steps -* results steps return true if the test passes or something else if it fails - -One of the most important step files is known as "webrat" as a hold over from Cucumber. The `bdd_webrat.erl` file contains most of the HTML & AJAX routines you will ever need for routine testing. It is also a great place to look for examples of step programming. - -You can extend/substitute step definitions by using the one of the predefinex prefixs. This will invoke an Erlang method when the step is tokenized so that you can create custom lookups for your steps. - -For example, using `{bdd:bdd_utils.puts.foo.bar}` will call the `Bdd_utils` method `puts/2` with the input data of `["foo","bar"]`. This approach can be used to extend steps so that they can substitue information when the step is parsed. This is NOT a test run substitution - the replacement is made before test execution. - -> Remember, prefixes are static data used during _pre-evaluation_ for steps. You cannot use prefixs to lookup information that is only available during testing such as the IDs of created steps. Use the `bdd_utils:scenario_retrieve` methods inside the steps if you need dynamic information. - -BDD step prefixes are: - -* bdd: does an apply() using the BDD Config pattern and `.` delimited information where `bdd:f.m.p1.p2.pN` becomes `apply(f, m, [Config, p1, p2, pN])` -* apply: does a raw apply() using `.` delimited information where `apply:f.m.p1.p2.pN` becomes `apply(f, m, [p1, p2, pN])` -* lookup: calls the g(type) value for the given model. Use as `lookup:node.name` to call the `node.erl g(name)` method. This is a very handy way to use the items created in the setup steps. -* atom: turns the text into an Erlang atom -* integer: turns the text into an Erlang integer -* object: same as atom but more user intuitive for REST steps - -> A handy example of this for Crowbar is using the `crowbar:i18n(Config, Key)` lookup to resolve localizations using the Utils localization string retriever. You can retrieve localizations in steps using `{bdd:crowbar.i18n.my.local.key}` where `my.local.key` maps to a key in the i18n files. - -#### Adding Pre & Post Conditions - -To add pre/post-configuration for a Feature file, you must have an Erlang step file with the same name as the feature file. For example, if you have a feature called `nodes.feature` then you must have a `nodes.erl` to create setup and tear down steps for that feature file. - -Setup Steps use the `step_setup` atom: - - step(Config, _Global, {step_setup, {_ScenarioID, _N}, _}) -> - io:format("\tNo Feature Setup Step.~n"), - Config; - -> This setup step adds results to the Config file. You should use `[{item, value} | Config]` to ensure that your values get added to the Config list and are available for the features' steps. -> _Global is always an empty list (`[]`) for setup steps. - -Teardown Steps use the `step_teardown` atom: - - step(Config, _Global, {step_teardown, {_ScenarioID, _N}, _}) -> - io:format("\tNo Feature Tear Down Step.~n"), - Config; - -To perform actions, replace or augment the code in the steps to perform the needed operations. The result from the Setup action is added to the `Global` list that is passed into all the steps called within the feature. This allows you to reference items created in setup during subsequent tests. You should remember to unwind any action from the setup in the teardown. - -For example, the Nodes feature setup and tear down look like this: - - step(Config, _Global, {step_setup, {_ScenarioID, _N}, _}) -> - Path = "node/2.0", - Node1 = "BDD1.example.com", - % just in case, cleanup first - http_delete(Config, Path, Node), - % create node(s) for tests - Node = node_json(Node1, "BDD Testing Only", 100), - Result = http_post(Config, Path, Node), - {"id", Key} = lists:keyfind("id",1,Result), - io:format("\tCreated Node ~p (id=~p) for testing.~n", [Node1, Key]), - [{node1, Key} | Config]; - - step(Config, Global, {step_teardown, {_ScenarioID, _N}, _}) -> - % find the node from setup and remove it - {"node1", Key} = lists:keyfind("node1", Global), - http_delete(Config, Path, Key), - io:format("\tRemoved Node ID ~p for Tear Down Step.~n", [Key]), - Config; - -### Passing information between Steps in a Scenario - -There are two ways to pass information between Steps in a Scenario: the the Results list and the Config Bag. - -#### The Results List - -The Results list is the primary way that information to be tested is added/checked in steps. The entire design of the BDD system is to have the When steps collect information that is checked by the Then steps. The "Result" list is the way this information is passed into the Results for checking. The same mechanism is used for passing information from the Given to When steps. - -#### The Config Bag - -The Results List is the primary mechanism to use this because the trace and step designs encourage it; however, there are times when it is necessary to collect Given information and use it in Then steps. In these cases, you can store Scenario specific information for use within the other steps using Scenario store and retrieve routines. - -To Store, use `bdd_utils:scenario_store(ScenarioID, Key, Value)` in insert a KVP into the configuration thread space. These values can be inspected from the Erlang shell using the regular `get({scenario, ID#})` approach. It is recommended to store IDs of objects that Given steps create so they are avialable during Then checks. - -> Storing the same key again will replace the old value with the new value. - -To Revieve the value later, use `bdd_utils:scenario_retrieve(ScenarioID, Key, Default).` This will recover the key value for the Scenario. - -This approach is very handy: -* if you want to store given values for a form (`Given I set "foo" to "bar"` - see `bdd_catchall`). -* if you create value (`Given REST creates {object:node} "foo.example.com"`) and need it's ID for a later step - -### Debugging - -Some handy Erlang tips: - -* `Config = bdd:getconfig("crowbar")` will load the configuration file for passing into Step routines for manual testing - -### BDD Code Files - -* bdd.erl - contains the core running logic -* bdd_utils.erl - utilities used across all modules of the bdd system -* eurl.erl - HTTP get, post, delete functions (like curl) -* json.erl - JSON parser converts to and from lists -* digest_auth.erl - Wrapps http to provide secure access -* bdd_catchall.erl - last step file executed, has fall back steps -* bdd_webrat.erl - handles most basic web & AJAX based steps -* default.erl - the fall back step file (global setup/teardown goes here) -* crowbar.erl - Crowbar specific logic -* [feature].erl - Each feature can have a specific step file - -#### In the feature specific code files, you will find the following - -#### The Global routine "g" -Provides paths for the Feature type. Using g helps to make the code DRY. - -It is common for other features to call each other's g routines to get the correct path for operations on that type. - -#### JSON creator & validator -The json method is used to create json text for POST and PUT operations against the API. -The validate method is used to make sure that GET returned json matches the expected results - -#### Inspector -The inspector inspects the system and returns a list of items that reflect it's current state. The goal of the inspector is to help detect testing artificats that should have been removed. The inpector method is called before any tests are run and again after all the tests have completed. If there is any new or missing artificat, the BDD inspector will alert you that the system was not left in a clean state. - -#### Setup and Teardown steps for the Feature. -These steps are called by BDD before and after the feature are executed. They create objects for the tests to manipulate and then restore the system to it's original state. - -REST API items that are specific to that Feature; however, some of these are common and should be moved to the Crowbar or CrowbarREST file. diff --git a/doc/devguide/testing/bdd/steps_rest.md b/doc/devguide/testing/bdd/steps_rest.md deleted file mode 100755 index eded5b97b73..00000000000 --- a/doc/devguide/testing/bdd/steps_rest.md +++ /dev/null @@ -1,145 +0,0 @@ -#### BDD testing RESTful APIs - -This section descusses the common pattern for BDD testing a RESTful API - - -##### Exports - -* step/3 -* json/3 - -* validate/1 -* inspector/1 -* g/1 - -#### g - -Put commonly used string and information here. This function is provided to help avoid duplication of strings. It makes it much easier to maintain the code if you centralize the string table. - -* path - provides the path to the REST API that is the base for this object. Commonly used from other modules. -* name & atom - are used as a string table for objects created in the steps -* type (not required) - is shown as a reference for information that you may want to keep in g - - g(Item) -> - case Item of - path -> "2.0/crowbar/2.0/jig"; - type -> "JigTest"; - name1 -> "bddjig"; - atom1 -> jig1; - _ -> crowbar:g(Item) - end. - -#### json & validate - -A Happy API has consistent JSON. - -The json routine creates a valid JSON version of the object. This is used by the routines that create and update the object via the API. You may implement multiple versions of json to capture the different required/optional components of the object. - - json(Name) -> - json:output([{"name",Name}]). - - json(Name, Description, Order) -> - json:output([{"name",Name},{"description", Description}, {"order", Order}]). - -Use the shared validator to check common properties like ID, Name, Description and edit dates. This validator should only check the items that are specific to your object. - -> The `bdd_utils:is_a` is your friend - extend it if needed. There are similar BIFs for erlang that you can also leverage. - - validate(J) -> - R =[length(J) =:= 6, - bdd_utils:is_a(J, str, description), - bdd_utils:is_a(J, integer, order), - crowbar_rest:validate(J)], - bdd_utils:assert(R). - -#### inspector - -The inspector is part of a housekeeping system for BDD that helps detect orphaned artifacts. It is optional, but recommended for root objects. - -The objective of the inspector method is to return a list of items found in the system. This list is generated before and after BDD runs. - - inspector(Config) -> - crowbar_rest:inspector(Config, jigs). % shared inspector works here, but may not always - -> It is likely that you can leverage a generic inspector routine if your API has a consistent list pattern. - -#### step - setup & teardown - -Setup and teardown are called automatically by BDD at the start of a feature run. They are optional. It is import that they are balanced - any objects created by setup should be removed in teardown. - -Setup and teardown steps are just like other steps except that they use the `step_setup` and `step_teardown` atoms. Setup is expected to return a Config file. Generally, a tumple for each object created (`{name1, 5}`) is added to the config so that teardown can delete objects by ID instead of name. - -Setup - - step(Config, _Global, {step_setup, _N, _}) -> - % create node(s) for tests - Node = json(g(name), g(description), 100), - crowbar_rest:create(Config, g(path), g(atom), g(name), Node); - -Teardown - - step(Config, _Global, {step_teardown, _N, _}) -> - % find the node from setup and remove it - crowbar_rest:destroy(Config, g(path), g(atom)). - -#### Common steps - -Common steps are easy to create because thy can leverage existing steps with minor changes. Even if the underlying step is simple, it's more maintainable to build steps based on other steps. - -Get List - - step(Config, _Given, {step_when, _N, ["REST gets the jig list"]}) -> - bdd_restrat:step(Config, _Given, {step_when, _N, ["REST requests the",eurl:path(g(path),""),"page"]}); - -Get Object - - step(Config, _Given, {step_when, _N, ["REST gets the jig",Name]}) -> - bdd_restrat:step(Config, _Given, {step_when, _N, ["REST requests the",eurl:path(g(path),Name),"page"]}); - -Validate Object - -> This routine will call back the the modules own validate! - - step(_Config, Result, {step_then, _N, ["the jig is properly formatted"]}) -> - crowbar_rest:step(_Config, Result, {step_then, _N, ["the", jig, "object is properly formatted"]}); - - -Create Object - ->Creates a new object using the require components. The routine builds the JSON for the object (see above) and then calls the shared create method. - - step(Config, _Global, {step_given, _N, ["there is a jig",Jig,"of type", Type]}) -> - JSON = json(Jig, g(description), Type, 200), - crowbar_rest:create(Config, g(path), JSON); - -Remove Object - - step(Config, _Given, {step_finally, _N, ["REST removes the jig",Jig]}) -> - crowbar_rest:destroy(Config, g(path), Jig); - -#### Reference Features - - Scenario: Jig List - Given there is a jig "my_special_jig" - When REST gets the jig list - Then there should be a value "my_special_jig" - And there should be a value "chef" - And there should be a value "bddjig" - Finally REST removes the jig "my_special_jig" - - Scenario: REST JSON check - Given there is a jig "jig_json_test" - When REST gets the jig "jig_json_test" - Then the jig is properly formatted - Finally REST removes the jig "jig_json_test" - - Scenario: REST Add - Given there is not a jig "jig_add_test" - When REST adds the jig "jig_add_test" - Then there is a jig "jig_add_test" - Finally REST removes the jig "jig_add_test" - - Scenario: REST Delete - Given there is a jig "jig_delete_test" - When REST deletes the jig "jig_delete_test" - Then there is a not jig "jig_delete_test" - diff --git a/doc/devguide/testing/chefspec.md b/doc/devguide/testing/chefspec.md old mode 100755 new mode 100644 diff --git a/doc/devguide/testing/rspec.md b/doc/devguide/testing/rspec.md old mode 100755 new mode 100644 diff --git a/doc/devguide/testing/units.md b/doc/devguide/testing/units.md old mode 100755 new mode 100644 diff --git a/doc/devguide/ui.md b/doc/devguide/ui.md old mode 100755 new mode 100644 diff --git a/doc/devguide/ui/documentation.md b/doc/devguide/ui/documentation.md deleted file mode 100755 index 14842e3a90e..00000000000 --- a/doc/devguide/ui/documentation.md +++ /dev/null @@ -1,101 +0,0 @@ -### Adding Documentation - -Crowbar uses a composite documentation system that allows each barclamp to add documentation specific to its function while still building a single comprehensive documentation set. - -> _Tip:_ Use http://www.ctrlshift.net/project/markdowneditor/ to WYSIWYG edit markdown! - -This information is available as a video! see http://youtu.be/eWHeEWiOEvo - -#### Composite Documentation - -It is vital to understand that the Crowbar documentation system is _composite documentation._ That means that the information is assembled from multiple barclamps on the fly. This is required because the Crowbar framework is really a collection of barclamps and each barclamp has it's own capabilities and features. - -The design of the documentation system allows each barclamp to contribute parts to the overall whole _and also_ allows parts to cross reference each other. - -For example, each barclamp is expected to contribute "barclamp" and "license" information. These pages only refer to the individual barclamp's data; however, they are rolled up under the barclamp and license sections of the documentation. For Crowbar suite barclamps, they are further grouped under the master Crowbar set. That means that the Deployer license information depends on the Crowbar Meta information. - -While this adds complexity for the documentation author, it greatly simplify the documentation reading experience for the user. It also allows developers to isolate documentation changes. - -#### Table of Contents - Directory Tree Layout - -By design, the table of contents generally follows the directory structure of the documentation. This is intentional because it simplifies composition. - -Each subdirectory should be paired with a matching topic document that functions as the index for the items in the subdirectory. - -For example, - - devguide.md - devguide/ - api.md - api/ - node.md - group.md - testing.md - testing/ - -In the above example, the `devguide` topic layout out general information for the developer guide. The `api` and `testing` sections would be shown as sections of the Developer Guide. Individual API topics `node` and `group` are subsections of the API topic. - -> The convention of having an the index topic name (`api.md`) match the subfolder (`api/`) makes it easier for Crowbar to assemble to table of contents without extra meta data. - -If no hints (see index below) are given, Crowbar will automatically scan the subdirectory tree and build the table of contents based on the file path naming convention. - -#### Index -There is a documentation tree index (`[barclamp].yml`) for each barclamp. The index is a yml file which builds the documentation tree by deep merging all the barclamp indexes together. - -> The index _must_ be named the same as the barclamp. So each barclamp provides "barclamp.yml" in the `doc` directory. These files are merged together during the barclamp install. - -The index has an entry for each topic page that follows the following pattern: `barclamp/topic`. The `/` is required! - -> You can comment out a page from being automatically index by prefixing it's name w/ `#` - -It is acceptable for a barclamp to reference topics in another barclamp so that the correct parent topics are used to build an integrated set. - -The index file should be nested so that topics have correct parents. - -> It is strongly encouraged (but not required) to keep the index path the same as the file path. - -##### Manual Index - -With the addition of automatic indexing, the number of pages manually indexed has dropped dramatically. Manual indexing is still required if you want to control the order of page rendering or add additional meta data. - -Each level of the index can have meta data overrides, the meta data values are: - -* order - defaults to alpha if omitted. Range is 0 to 999999, default is 9999 -* author - who edited this document last -* license - the license the document is distributed under -* date - last edit date -* copyright - copyright requirements for the document -* url - link to part of Crowbar this information relates to - -An example index file looks like this: - - # these are the default meta_data values - license: Apache 2 - copyright: 2012 by Dell, Inc - author: Dell CloudEdge Team - date: July 29, 2012 - crowbar/userguide: - order: 1000 - crowbar/ui-general: - order: 10 - - crowbar+ui-nodes - crowbar/ui-utilities: - order: 100 - url: '/utils' - crowbar/utils-export: - url: '/utils/index' - - -#### Topic Documentation - -Markdown is the current format. - -Path is `doc/default/barclamp/file.md` - -It is allowable (recommended!) to use additional subdirectories! Simply add another `/` to the same to indicate another level of depth on the file path. - -> The naming of topics will match the file paths! - -The name of the topic is expected to start with a # title flag. This title is used by the generator to create the displayed title. - -It is recommended to use # for top level (book), ## for second level (section), ### for third level (topic) and so on. diff --git a/doc/devguide/ui/localization.md b/doc/devguide/ui/localization.md deleted file mode 100755 index abb797e9bab..00000000000 --- a/doc/devguide/ui/localization.md +++ /dev/null @@ -1,21 +0,0 @@ -### Adding Localizations (i18n) - -Crowbar uses Rails I18N library. Please refer to the documentation (http://http://guides.rubyonrails.org/i18n.html) for usage hints that can help you reduce coding and add nifty features like Interpolation. - -Each barclamp is expected to add its own localization (i18n) file. Please do _not_ add your localizations into another barclamps i18n file, it’s not friendly! However, you also need to be careful not to create duplicate entries. That’s just too confusing for Crowbar and makes the bunny angry. - -Add your localization file (`en.yml` is the default) into the `crowbar_framework/config/locales/[barclamp]` directory. You know this but I’ve got to tell the n00bs: you need to replace [barclamp] with the name of your barclamp. - -If you are supporting multiple languages, replace `en` with the target language code. Like `kl.yml` if you want provide Klingon translations. - -Inside the i18n file, you’ll provide a simple YML hash for translations. - en: - # Layout - nav: - nodes: Nodes - nodes_description: Infrastructure Components - -Reminder: encode your translations in quotes if you need to use : or ‘ marks! - -#### Crowbar 1.0 note -We no longer support storing localization strings in the crowbar.yml meta data file. This was not scaling so we dropped it like a rotten tomato in the Heinz ketchup factory. diff --git a/doc/devguide/ui/navigation.md b/doc/devguide/ui/navigation.md deleted file mode 100755 index 4324993eb37..00000000000 --- a/doc/devguide/ui/navigation.md +++ /dev/null @@ -1,35 +0,0 @@ -### Adding Menu Items - -You add menu items into Crowbar using database migrations that insert into the `navs` table using the `Nav` object. - -You must add the migration to the `crowbar_framework/db/migrate` directory and follow the Rails migration naming convention of `YYYYMMDDHHMMSS_barclamp_navs.rb`. - -Inside the migration, use the `Nav.find_or_create_by_item` to populate the information for the menu item: - -* item = the id of the item -* parent_item = the id of the top level menu you want to use (`root` creates a top level menu) -* name = the i18n path to the menu text -* description = the i18n path to the menu hover information -* path = the Rails path you want to follow. Unless it starts with http, `eval` will be applied to the path. -* order = the display order of the menu item - -Remember: - -* to provide a `self.down` that removes your menu item! It’s just more sanitary that way. -* to create matching entries in your barclamps i18n files - -#### Example from the Network barclamp: - class NetworkNavs < ActiveRecord::Migration - def self.up - Nav.find_or_create_by_item :item=>'switches', :parent_item=>'network', :name=>'nav.switch', :description=>'nav.switch_description', :path=>"switch_path", :order=>500 - end - - def self.down - Nav.delete_by_item 'switches' - Nav.delete_by_item 'vlan' - end - end - -#### Crowbar 1.0 note - -We no longer support storing navigation strings in the crowbar.yml meta data file. This approach made difficult to upgrade and maintain. The new approach is also difficult to maintain but easier to upgrade. diff --git a/doc/framework.yml b/doc/framework.yml new file mode 100644 index 00000000000..db360afbe9c --- /dev/null +++ b/doc/framework.yml @@ -0,0 +1,5 @@ +# theses are the default meta_data values +license: Apache 2 +copyright: "2013 by Dell, Inc" +author: Dell CloudEdge Team +date: "January 13, 2013" diff --git a/doc/gettingstarted.md b/doc/gettingstarted.md old mode 100755 new mode 100644 diff --git a/doc/licenses.md b/doc/licenses.md old mode 100755 new mode 100644 diff --git a/doc/releasenotes.md b/doc/releasenotes.md old mode 100755 new mode 100644 diff --git a/doc/userguide.md b/doc/userguide.md old mode 100755 new mode 100644 diff --git a/releases/development/master/extra/barclamp_mgmt_lib.rb b/releases/development/master/extra/barclamp_mgmt_lib.rb old mode 100755 new mode 100644 index 15fbcdfbd39..614410326b5 --- a/releases/development/master/extra/barclamp_mgmt_lib.rb +++ b/releases/development/master/extra/barclamp_mgmt_lib.rb @@ -289,6 +289,13 @@ def bc_install_layout_2_app(bc, bc_path, yaml) debug "\tcopied over chef parts from #{bc_path} to #{@BASE_PATH}" end + # copy all the BDD files to the target + if dirs.include? 'BDD' + debug "path entries include \"BDD\"" + files += bc_cloner('BDD', bc, nil, bc_path, @BASE_PATH, false) + debug "\tcopied over BDD parts from #{bc_path} to #{@BASE_PATH}" + end + # copy over docs if dirs.include? 'doc' doc_source = File.join(bc_path,'doc')