Merge lp:~noise/tanuki-agent/just-the-facts into lp:tanuki-agent
- just-the-facts
- Merge into trunk
Proposed by
Bret Barker
Status: | Merged |
---|---|
Approved by: | Bret Barker |
Approved revision: | 164 |
Merged at revision: | 164 |
Proposed branch: | lp:~noise/tanuki-agent/just-the-facts |
Merge into: | lp:tanuki-agent |
Diff against target: |
256 lines (+29/-119) 1 file modified
docs/api-reference.md (+29/-119) |
To merge this branch: | bzr merge lp:~noise/tanuki-agent/just-the-facts |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Guillermo Gonzalez | Approve | ||
Review via email: mp+276710@code.launchpad.net |
Commit message
remove extras from api ref; clean SPI refs
Description of the change
To post a comment you must log in.
Preview Diff
[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1 | === modified file 'docs/api-reference.md' | |||
2 | --- docs/api-reference.md 2015-11-04 14:37:58 +0000 | |||
3 | +++ docs/api-reference.md 2015-11-04 21:52:03 +0000 | |||
4 | @@ -1,59 +1,14 @@ | |||
7 | 1 | Title: Snappy Product Integration API Guide | 1 | Title: Ubuntu Core Product Integration API Guide |
8 | 2 | Version: 20151030 | 2 | Version: 20151105 |
9 | 3 | 3 | ||
10 | 4 | [TOC] | 4 | [TOC] |
11 | 5 | 5 | ||
59 | 6 | System Overview | 6 | |
60 | 7 | =============== | 7 | Definitions |
61 | 8 | 8 | ============ | |
15 | 9 | Snappy Product Integration(SPI) is system for | ||
16 | 10 | coordinating integration testing of Snappy-based products | ||
17 | 11 | across a matrix of supported platforms. | ||
18 | 12 | |||
19 | 13 | |||
20 | 14 | |||
21 | 15 | It is important to note that SPI is not a build tool, image | ||
22 | 16 | composer, or unit test runner. | ||
23 | 17 | |||
24 | 18 | |||
25 | 19 | |||
26 | 20 | There are four main actors in SPI: | ||
27 | 21 | |||
28 | 22 | - Product Owners managing product definitions | ||
29 | 23 | - Developers providing Snaps or Images for test | ||
30 | 24 | |||
31 | 25 | <!-- --> | ||
32 | 26 | |||
33 | 27 | - Lab owners managing hardware installations that will consume | ||
34 | 28 | tests | ||
35 | 29 | - Quality Assurance engineers that will manage tests and | ||
36 | 30 | evaluate test results | ||
37 | 31 | |||
38 | 32 | |||
39 | 33 | |||
40 | 34 | This separation of concerns is enforced by the design of the SPI | ||
41 | 35 | System and the APIs it provides. Below is a diagram of the | ||
42 | 36 | overall architecture and data flow. The blue boxes form the SPI software | ||
43 | 37 | provided by Canonical. The green boxes represent your organization’s | ||
44 | 38 | different responsibilities. They also represent the middle layer you | ||
45 | 39 | provide for the SPI system to talk to your hardware known as the | ||
46 | 40 | Provisioning Kit. | ||
47 | 41 | |||
48 | 42 | ![](images/image02.png) | ||
49 | 43 | |||
50 | 44 | SPI Definitions | ||
51 | 45 | --------------- | ||
52 | 46 | |||
53 | 47 | |||
54 | 48 | |||
55 | 49 | SPI models product integration testing using the following core | ||
56 | 50 | abstractions: | ||
57 | 51 | |||
58 | 52 | |||
62 | 53 | 9 | ||
63 | 54 | - **Manifest**: used to define a Product | 10 | - **Manifest**: used to define a Product |
66 | 55 | that is based on Snaps. This is optional for image-based workflows | 11 | that is based on Snaps. This is optional for image-based workflows. |
65 | 56 | as detailed below under [Workflows](#workflows). | ||
67 | 57 | - **Image Reference**: information passed | 12 | - **Image Reference**: information passed |
68 | 58 | to the Provisioning Kit to use in setting up a device for testing | 13 | to the Provisioning Kit to use in setting up a device for testing |
69 | 59 | the Product. It is free-form with data of your choosing (e.g. a | 14 | the Product. It is free-form with data of your choosing (e.g. a |
70 | @@ -62,61 +17,13 @@ | |||
71 | 62 | - **Test Spec**: defines Tests to be run on | 17 | - **Test Spec**: defines Tests to be run on |
72 | 63 | matching images | 18 | matching images |
73 | 64 | - **Test Opportunity**: an instance of a | 19 | - **Test Opportunity**: an instance of a |
124 | 65 | test for a given image that will be delivered to an Agent. | 20 | test for a given image and/or set of snaps that will be delivered to an Agent. |
125 | 66 | - **Agent**: SPI client installed in a | 21 | - **Agent**: Client software installed on a host computer to run |
126 | 67 | "lab" to coordinate running tests. | 22 | tests against a target device. |
127 | 68 | - **Test Result**: metadata | 23 | - **Test Result**: metadata about output of a test run. |
78 | 69 | about output of a test run. | ||
79 | 70 | |||
80 | 71 | |||
81 | 72 | |||
82 | 73 | |||
83 | 74 | |||
84 | 75 | Workflows | ||
85 | 76 | --------- | ||
86 | 77 | |||
87 | 78 | |||
88 | 79 | |||
89 | 80 | There are two primary workflows supported by SPI: | ||
90 | 81 | |||
91 | 82 | |||
92 | 83 | |||
93 | 84 | 1. Snappy Based Image | ||
94 | 85 | 2. Custom Image | ||
95 | 86 | |||
96 | 87 | |||
97 | 88 | |||
98 | 89 | In the Snappy scenario, the product owner will first create a | ||
99 | 90 | Product (Manifest) and Test Specs in SPI. The product will point to a | ||
100 | 91 | base image that defines the "released" product and specify the names of | ||
101 | 92 | Snaps that comprise the product. Changes to the named Snaps, represented | ||
102 | 93 | as new uploads to the Snappy Store, will be automatically advertised to | ||
103 | 94 | the SPI system to trigger tests of the base image with updated Snaps. | ||
104 | 95 | |||
105 | 96 | |||
106 | 97 | |||
107 | 98 | |||
108 | 99 | As an example, Canonical’s Snappy Core team uses this workflow to | ||
109 | 100 | perform integration, upgrade, and downgrade testing as each new revision | ||
110 | 101 | of the WebDM Snap is uploaded to the Store. | ||
111 | 102 | |||
112 | 103 | |||
113 | 104 | |||
114 | 105 | The Custom Image workflow is simpler and designed to | ||
115 | 106 | help you transition from legacy product image testing to a | ||
116 | 107 | Snappy-generated product while running the same tests in the same manner | ||
117 | 108 | throughout this period. In this scenario, the product owner | ||
118 | 109 | (or developer) can create Test Specs (no Manifest required) and then | ||
119 | 110 | submit Images that match the Test Spec based on image\_name to trigger | ||
120 | 111 | test runs. | ||
121 | 112 | |||
122 | 113 | API Reference | ||
123 | 114 | ============= | ||
128 | 115 | 24 | ||
129 | 116 | Authentication | 25 | Authentication |
133 | 117 | -------------- | 26 | ============ |
131 | 118 | |||
132 | 119 | |||
134 | 120 | 27 | ||
135 | 121 | All API endpoints are authenticated, which ensures private access | 28 | All API endpoints are authenticated, which ensures private access |
136 | 122 | to your Organization's information. | 29 | to your Organization's information. |
137 | @@ -129,7 +36,7 @@ | |||
138 | 129 | <!-- LINK TO CORRECT PLACE IN TUTORIAL? --> | 36 | <!-- LINK TO CORRECT PLACE IN TUTORIAL? --> |
139 | 130 | 37 | ||
140 | 131 | With those credentials, you can use an oauth library in your | 38 | With those credentials, you can use an oauth library in your |
142 | 132 | language of choice to sign HTTP requests to the SPI API endpoints. | 39 | language of choice to sign HTTP requests to the API endpoints. |
143 | 133 | 40 | ||
144 | 134 | 41 | ||
145 | 135 | We'll walk through an example of that in Python using <span | 42 | We'll walk through an example of that in Python using <span |
146 | @@ -203,10 +110,10 @@ | |||
147 | 203 | login process) into a file called conf.ini. Note, this script is meant only as an example and not | 110 | login process) into a file called conf.ini. Note, this script is meant only as an example and not |
148 | 204 | intended for production use. | 111 | intended for production use. |
149 | 205 | 112 | ||
152 | 206 | API Errors | 113 | Errors |
153 | 207 | ---------- | 114 | ============ |
154 | 208 | 115 | ||
156 | 209 | The SPI APIs use standard HTTP response codes. Most errors will | 116 | The APIs use standard HTTP response codes. Most errors will |
157 | 210 | contain a human-readable "message" field in the JSON response body. Here | 117 | contain a human-readable "message" field in the JSON response body. Here |
158 | 211 | are the most common error codes and guidelines for handling them. | 118 | are the most common error codes and guidelines for handling them. |
159 | 212 | 119 | ||
160 | @@ -230,14 +137,17 @@ | |||
161 | 230 | <p>There was an temporary error on the server. The request may be retried after a short wait. If the problem persists please contact support. Scripts should use an exponential backoff to avoid hammering the servers with retries. | 137 | <p>There was an temporary error on the server. The request may be retried after a short wait. If the problem persists please contact support. Scripts should use an exponential backoff to avoid hammering the servers with retries. |
162 | 231 | </table> | 138 | </table> |
163 | 232 | 139 | ||
164 | 140 | API Reference | ||
165 | 141 | ============= | ||
166 | 142 | |||
167 | 233 | Product Management | 143 | Product Management |
168 | 234 | ------------------ | 144 | ------------------ |
169 | 235 | 145 | ||
170 | 236 | Note: Product Manifests support products built from | 146 | Note: Product Manifests support products built from |
172 | 237 | Snaps. If you are instead bootstrapping SPI with a pre-existing binary | 147 | Snaps. If you are instead bootstrapping Product Integration with a pre-existing binary |
173 | 238 | image, please skip ahead to the next section - Test Management. | 148 | image, please skip ahead to the next section - Test Management. |
174 | 239 | 149 | ||
176 | 240 | In SPI, a Product is defined by a Manifest that has an image\_name | 150 | A Product is defined by a Manifest that has an image\_name |
177 | 241 | and either a list of snaps that comprise the image (e.g. as specified in | 151 | and either a list of snaps that comprise the image (e.g. as specified in |
178 | 242 | a Gadget Snap) or a base\_image\_reference. | 152 | a Gadget Snap) or a base\_image\_reference. |
179 | 243 | 153 | ||
180 | @@ -266,7 +176,7 @@ | |||
181 | 266 | - ```release``` snappy release series, e.g. | 176 | - ```release``` snappy release series, e.g. |
182 | 267 | “15.04”. Maximum length is 200 characters. | 177 | “15.04”. Maximum length is 200 characters. |
183 | 268 | - ```base_image_reference``` is opaque to | 178 | - ```base_image_reference``` is opaque to |
185 | 269 | the SPI system; it is for your Provisioning Kit in your lab to | 179 | the system; it is for your Provisioning Kit in your lab to |
186 | 270 | interpret and use. It can be any JSON | 180 | interpret and use. It can be any JSON |
187 | 271 | value. This allows for URLs to actual image binaries, | 181 | value. This allows for URLs to actual image binaries, |
188 | 272 | data for on-the-fly image composition, etc. Maximum length is 1000 | 182 | data for on-the-fly image composition, etc. Maximum length is 1000 |
189 | @@ -478,7 +388,7 @@ | |||
190 | 478 | Test Management | 388 | Test Management |
191 | 479 | --------------- | 389 | --------------- |
192 | 480 | 390 | ||
194 | 481 | Tests in SPI are defined with Test Specs. There may be multiple | 391 | Tests are defined with Test Specs. There may be multiple |
195 | 482 | Test Specs per product and they are related via the image\_name field. | 392 | Test Specs per product and they are related via the image\_name field. |
196 | 483 | TestSpecs are required for both Image and Snappy based workflows as they | 393 | TestSpecs are required for both Image and Snappy based workflows as they |
197 | 484 | form the basis for TestOpportunity creation. | 394 | form the basis for TestOpportunity creation. |
198 | @@ -658,7 +568,7 @@ | |||
199 | 658 | ### Image Submission | 568 | ### Image Submission |
200 | 659 | 569 | ||
201 | 660 | Test opportunities are triggered by a new image reference being | 570 | Test opportunities are triggered by a new image reference being |
203 | 661 | advertised by the user to the SPI system. An Image Reference | 571 | advertised by the user to the system. An Image Reference |
204 | 662 | has the following required fields: | 572 | has the following required fields: |
205 | 663 | 573 | ||
206 | 664 | 574 | ||
207 | @@ -670,13 +580,13 @@ | |||
208 | 670 | matching image_name, then two test opportunities will be created. | 580 | matching image_name, then two test opportunities will be created. |
209 | 671 | Maximum length is 200 characters. | 581 | Maximum length is 200 characters. |
210 | 672 | - ```image_reference```: is opaque to the | 582 | - ```image_reference```: is opaque to the |
212 | 673 | SPI system; it is for your Provisioning Kit in your lab | 583 | system; it is for your Provisioning Kit in your lab |
213 | 674 | to interpret and use. It can be any JSON | 584 | to interpret and use. It can be any JSON |
214 | 675 | value. This allows for URLs to actual image binaries, | 585 | value. This allows for URLs to actual image binaries, |
215 | 676 | data for on-the-fly image composition, etc. Maximum length is 1000 | 586 | data for on-the-fly image composition, etc. Maximum length is 1000 |
216 | 677 | characters. | 587 | characters. |
217 | 678 | - ```image_unique_id```: also opaque to the | 588 | - ```image_unique_id```: also opaque to the |
219 | 679 | SPI system. It is recommended that this uniquely | 589 | system. It is recommended that this uniquely |
220 | 680 | identifies the advertised version of the image so that the | 590 | identifies the advertised version of the image so that the |
221 | 681 | provisioning script can verify the image\_reference and results can | 591 | provisioning script can verify the image\_reference and results can |
222 | 682 | be queried by image\_unique\_id. For example it could | 592 | be queried by image\_unique\_id. For example it could |
223 | @@ -737,10 +647,10 @@ | |||
224 | 737 | ### Snap Revisions | 647 | ### Snap Revisions |
225 | 738 | 648 | ||
226 | 739 | Test opportunities may be triggered by snap revisions being | 649 | Test opportunities may be triggered by snap revisions being |
228 | 740 | advertised to the SPI system. | 650 | advertised to the system. |
229 | 741 | 651 | ||
230 | 742 | New snap revisions uploaded to the Store will be automatically | 652 | New snap revisions uploaded to the Store will be automatically |
232 | 743 | advertised to SPI, however they can be re-advertised manually | 653 | advertised to the system, however they can be re-advertised manually |
233 | 744 | afterwards, re-triggering tests with their original context. | 654 | afterwards, re-triggering tests with their original context. |
234 | 745 | 655 | ||
235 | 746 | The new revision advertised will be matched with all **Manifests** within the context **Organization** | 656 | The new revision advertised will be matched with all **Manifests** within the context **Organization** |
236 | @@ -782,7 +692,7 @@ | |||
237 | 782 | 692 | ||
238 | 783 | 693 | ||
239 | 784 | 694 | ||
241 | 785 | SPI will return a list of test opportunity IDs and image unique IDs that can be used to [query for results](#querying-test-results) later. | 695 | Snap revision advertisement will return a list of test opportunity IDs and image unique IDs that can be used to [query for results](#querying-test-results) later. |
242 | 786 | 696 | ||
243 | 787 | <table class="table"> | 697 | <table class="table"> |
244 | 788 | <tr> | 698 | <tr> |
245 | @@ -877,7 +787,7 @@ | |||
246 | 877 | <p>Using with_event=EVENT_TYPE will return only logs that contain that event type. | 787 | <p>Using with_event=EVENT_TYPE will return only logs that contain that event type. |
247 | 878 | For example with_event=RESULT_POSTED returns only logs for tests for which a result has been posted back. Using without_event=EVENT_TYPE will return only logs that do not contain that event type. with_event and without_event cannot be used in the same query. | 788 | For example with_event=RESULT_POSTED returns only logs for tests for which a result has been posted back. Using without_event=EVENT_TYPE will return only logs that do not contain that event type. with_event and without_event cannot be used in the same query. |
248 | 879 | 789 | ||
250 | 880 | <p>For example, a large number of results that match without_event=PICKED_BY_AGENT could indicate either an under-resourced lab (all agents are busy) or that the agents have lost communication with the SPI servers. The combination of with_event=PICKED_BY_AGENT and without_event=RESULT_POSTED can be used to track down slow or stuck test runs, and the agent_id fields of the PICKED_BY_AGENT event can be used to identify the problem agent in the lab. | 790 | <p>For example, a large number of results that match without_event=PICKED_BY_AGENT could indicate either an under-resourced lab (all agents are busy) or that the agents have lost communication with Canonical's servers. The combination of with_event=PICKED_BY_AGENT and without_event=RESULT_POSTED can be used to track down slow or stuck test runs, and the agent_id fields of the PICKED_BY_AGENT event can be used to identify the problem agent in the lab. |
251 | 881 | <tr> | 791 | <tr> |
252 | 882 | <td>Response <td><code>200 OK</code> with JSON list of matching progress event log documents | 792 | <td>Response <td><code>200 OK</code> with JSON list of matching progress event log documents |
253 | 883 | <tr> | 793 | <tr> |
254 | 884 | 794 | ||
255 | === removed file 'docs/images/image02.png' | |||
256 | 885 | Binary files docs/images/image02.png 2015-11-02 16:58:53 +0000 and docs/images/image02.png 1970-01-01 00:00:00 +0000 differ | 795 | Binary files docs/images/image02.png 2015-11-02 16:58:53 +0000 and docs/images/image02.png 1970-01-01 00:00:00 +0000 differ |
lots of red, that's usually good. +1