Merge lp:~smoser/curtin/trunk.doc-interface into lp:~curtin-dev/curtin/trunk
- trunk.doc-interface
- Merge into trunk
Proposed by
Scott Moser
Status: | Merged |
---|---|
Merged at revision: | 529 |
Proposed branch: | lp:~smoser/curtin/trunk.doc-interface |
Merge into: | lp:~curtin-dev/curtin/trunk |
Diff against target: |
268 lines (+158/-47) 5 files modified
doc/index.rst (+1/-0) doc/topics/curthooks.rst (+108/-0) doc/topics/networking.rst (+2/-0) doc/topics/overview.rst (+45/-47) doc/topics/storage.rst (+2/-0) |
To merge this branch: | bzr merge lp:~smoser/curtin/trunk.doc-interface |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Chad Smith | Approve | ||
Server Team CI bot | continuous-integration | Approve | |
Review via email:
|
Commit message
doc: update documentation on curtin-hooks and non-ubuntu installation.
Add the section 'curthooks' to the documentation.
Generalize the environment variables in overview.
Description of the change
To post a comment you must log in.
Revision history for this message
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Server Team CI bot (server-team-bot) wrote : | # |
review:
Approve
(continuous-integration)
Revision history for this message
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Chad Smith (chad.smith) wrote : | # |
Minor spelling nits inline. Approved afterward. Good content (and good education/reference for me).
review:
Approve
Revision history for this message
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Scott Moser (smoser) wrote : | # |
ok. so comments in line. i took your obvious feedback and we can work on the others subsequently (mainly whether or not to document CURTIN_
Preview Diff
[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1 | === modified file 'doc/index.rst' | |||
2 | --- doc/index.rst 2016-08-18 16:17:20 +0000 | |||
3 | +++ doc/index.rst 2017-09-29 22:00:32 +0000 | |||
4 | @@ -17,6 +17,7 @@ | |||
5 | 17 | topics/apt_source | 17 | topics/apt_source |
6 | 18 | topics/networking | 18 | topics/networking |
7 | 19 | topics/storage | 19 | topics/storage |
8 | 20 | topics/curthooks | ||
9 | 20 | topics/reporting | 21 | topics/reporting |
10 | 21 | topics/development | 22 | topics/development |
11 | 22 | topics/integration-testing | 23 | topics/integration-testing |
12 | 23 | 24 | ||
13 | === added file 'doc/topics/curthooks.rst' | |||
14 | --- doc/topics/curthooks.rst 1970-01-01 00:00:00 +0000 | |||
15 | +++ doc/topics/curthooks.rst 2017-09-29 22:00:32 +0000 | |||
16 | @@ -0,0 +1,108 @@ | |||
17 | 1 | ======================================== | ||
18 | 2 | Curthooks / New OS Support | ||
19 | 3 | ======================================== | ||
20 | 4 | Curtin has built-in support for installation of Ubuntu. | ||
21 | 5 | Other operating systems are supported through a mechanism called | ||
22 | 6 | 'curthooks' or 'curtin-hooks'. | ||
23 | 7 | |||
24 | 8 | A curtin install runs through different stages. See the | ||
25 | 9 | :ref:`Stages <stages>` | ||
26 | 10 | documentation for function of each stage. | ||
27 | 11 | The stages communicate with each other via data in a working directory and | ||
28 | 12 | environment variables as described in | ||
29 | 13 | :ref:`Command Environment`. | ||
30 | 14 | |||
31 | 15 | Curtin handles partitioning, filesystem creation and target filesystem | ||
32 | 16 | population for all operating systems. Curthooks are the mechanism provided | ||
33 | 17 | so that the operating system can customize itself before reboot. This | ||
34 | 18 | customization typically would need to include: | ||
35 | 19 | |||
36 | 20 | - ensuring that appropriate device drivers are loaded on first boot | ||
37 | 21 | - consuming the network interfaces file and applying its declarations. | ||
38 | 22 | - ensuring that necessary packages are installed to utilize storage | ||
39 | 23 | configuration or networking configuration. | ||
40 | 24 | - making the system boot (running grub-install or equivalent). | ||
41 | 25 | |||
42 | 26 | Image provided curtin-hooks | ||
43 | 27 | --------------------------- | ||
44 | 28 | An image provides curtin hooks support by containing a file | ||
45 | 29 | ``/curtin/curtin-hooks``. | ||
46 | 30 | |||
47 | 31 | If an Ubuntu image image contains this path it will override the builtin | ||
48 | 32 | curtin support. | ||
49 | 33 | |||
50 | 34 | The ``curtin-hooks`` program should be executable in the filesystem and | ||
51 | 35 | will be executed without any arguments. It will be executed in the install | ||
52 | 36 | environment, *not* the target environment. A change of root to the | ||
53 | 37 | target environment can be done with ``curtin in-target``. | ||
54 | 38 | |||
55 | 39 | The hook is provided with some environment variables that can be used | ||
56 | 40 | to find more information. See the :ref:`Command Environment` doc for | ||
57 | 41 | details. Specifically interesting to this stage are:. | ||
58 | 42 | |||
59 | 43 | - ``OUTPUT_NETWORK_CONFIG``: This is a path to the file created during | ||
60 | 44 | network discovery stage. | ||
61 | 45 | - ``FSTAB``: This is a path to the file created during partitioning stage | ||
62 | 46 | - ``CONFIG``: This is a path to the curtin config file. It is provided so | ||
63 | 47 | that additional configuration could be provided through to the OS | ||
64 | 48 | customization. | ||
65 | 49 | |||
66 | 50 | **TODO**: We should add 'PYTHON' or 'CURTIN_PYTHON' to this environment | ||
67 | 51 | so that the hook can easily run a python program with the same python | ||
68 | 52 | that curtin ran with (ie, python2 or python3). | ||
69 | 53 | |||
70 | 54 | |||
71 | 55 | Networking configuration | ||
72 | 56 | ------------------------ | ||
73 | 57 | Access to the network configuration that is desired is inside the config | ||
74 | 58 | and is in the format described in :ref:`networking`. | ||
75 | 59 | |||
76 | 60 | .. TODO: We should guarantee that the presense | ||
77 | 61 | of network config v1 in the file OUTPUT_NETWORK_CONFIG. | ||
78 | 62 | |||
79 | 63 | The curtin-hooks program must read the configuration from the | ||
80 | 64 | path contained in ``OUTPUT_NETWORK_CONFIG`` and then set up | ||
81 | 65 | the installed system to use it. | ||
82 | 66 | |||
83 | 67 | If the installed system has cloud-init at version 17.1 or higher, it may | ||
84 | 68 | be possible to simply copy this section into the target in | ||
85 | 69 | ``/etc/cloud/cloud.cfg.d/`` and let cloud-init render the correct | ||
86 | 70 | networking on first boot. | ||
87 | 71 | |||
88 | 72 | Storage configuration | ||
89 | 73 | --------------------- | ||
90 | 74 | Access to the storage configuration that was set up is inside the config | ||
91 | 75 | and is in the format described in :ref:`storage`. | ||
92 | 76 | |||
93 | 77 | .. TODO: We should guarantee that the presense | ||
94 | 78 | of storage config v1 in the file OUTPUT_STORAGE_CONFIG. | ||
95 | 79 | This would mean the user would not have to pull it out | ||
96 | 80 | of CONFIG. We should guarantee its presense and format | ||
97 | 81 | even in the 'simple' path. | ||
98 | 82 | |||
99 | 83 | To apply this storage configuration, the curthooks may need to: | ||
100 | 84 | |||
101 | 85 | * update /etc/fstab to add the expected mounts entries. The environment | ||
102 | 86 | variable ``FSTAB`` contains a path to a file that may be suitable | ||
103 | 87 | for use. | ||
104 | 88 | |||
105 | 89 | * install any packages that are not already installed that are required | ||
106 | 90 | to boot with the provided storage config. For example, if the storage | ||
107 | 91 | layout includes raid you may need to install the mdadm package. | ||
108 | 92 | |||
109 | 93 | * update or create an initramfs. | ||
110 | 94 | |||
111 | 95 | |||
112 | 96 | System boot | ||
113 | 97 | ----------- | ||
114 | 98 | In Ubuntu, curtin will run 'grub-setup' and to install grub. This covers | ||
115 | 99 | putting the bootloader onto the disk(s) that are marked as | ||
116 | 100 | ``grub_device``. The provided hook will need to do the equivalent | ||
117 | 101 | operation. | ||
118 | 102 | |||
119 | 103 | finalize hook | ||
120 | 104 | ------------- | ||
121 | 105 | There is one other hook that curtin will invoke in an install, called | ||
122 | 106 | ``finalize``. This program is invoked in the same environment as | ||
123 | 107 | ``curtin-hooks`` above. It is intended to give the OS a final opportunity | ||
124 | 108 | make updates before reboot. It is called before ``late_commands``. | ||
125 | 0 | 109 | ||
126 | === modified file 'doc/topics/networking.rst' | |||
127 | --- doc/topics/networking.rst 2016-08-18 15:39:15 +0000 | |||
128 | +++ doc/topics/networking.rst 2017-09-29 22:00:32 +0000 | |||
129 | @@ -1,3 +1,5 @@ | |||
130 | 1 | .. _networking: | ||
131 | 2 | |||
132 | 1 | ========== | 3 | ========== |
133 | 2 | Networking | 4 | Networking |
134 | 3 | ========== | 5 | ========== |
135 | 4 | 6 | ||
136 | === modified file 'doc/topics/overview.rst' | |||
137 | --- doc/topics/overview.rst 2016-08-18 16:02:27 +0000 | |||
138 | +++ doc/topics/overview.rst 2017-09-29 22:00:32 +0000 | |||
139 | @@ -4,6 +4,8 @@ | |||
140 | 4 | 4 | ||
141 | 5 | Curtin is intended to be a bare bones "installer". Its goal is to take data from a source, and get it onto disk as quick as possible and then boot it. The key difference from traditional package based installers is that curtin assumes the thing its installing is intelligent and will do the right thing. | 5 | Curtin is intended to be a bare bones "installer". Its goal is to take data from a source, and get it onto disk as quick as possible and then boot it. The key difference from traditional package based installers is that curtin assumes the thing its installing is intelligent and will do the right thing. |
142 | 6 | 6 | ||
143 | 7 | .. _Stages: | ||
144 | 8 | |||
145 | 7 | Stages | 9 | Stages |
146 | 8 | ------ | 10 | ------ |
147 | 9 | A usage of curtin will go through the following stages: | 11 | A usage of curtin will go through the following stages: |
148 | @@ -22,6 +24,32 @@ | |||
149 | 22 | 24 | ||
150 | 23 | Curtin's assumption is that a fairly rich Linux (Ubuntu) environment is booted. | 25 | Curtin's assumption is that a fairly rich Linux (Ubuntu) environment is booted. |
151 | 24 | 26 | ||
152 | 27 | .. _Command Environment: | ||
153 | 28 | |||
154 | 29 | Command Environment | ||
155 | 30 | ~~~~~~~~~~~~~~~~~~~ | ||
156 | 31 | Stages and commands invoked by curtin always have the following environment | ||
157 | 32 | variables defined. | ||
158 | 33 | |||
159 | 34 | - ``WORKING_DIR``: This is for inter-command state. It will be the same | ||
160 | 35 | directory for each command run and will only be deleted at the end of the | ||
161 | 36 | install. Files referenced in other environment variables will be in | ||
162 | 37 | this directory. | ||
163 | 38 | |||
164 | 39 | - ``TARGET_MOUNT_POINT``: The path in the filesystem where the target | ||
165 | 40 | filesystem will be mounted. | ||
166 | 41 | |||
167 | 42 | - ``OUTPUT_NETWORK_CONFIG``: After the network discovery stage, this file | ||
168 | 43 | should contain networking config information that should then be written | ||
169 | 44 | to the target. | ||
170 | 45 | |||
171 | 46 | - ``OUTPUT_FSTAB``: After partitioning and filesystem creation, this file | ||
172 | 47 | will contain fstab(5) style content representing mounts. | ||
173 | 48 | |||
174 | 49 | - ``CONFIG``: This variable contains a path to a yaml formatted file with | ||
175 | 50 | the fully rendered config. | ||
176 | 51 | |||
177 | 52 | |||
178 | 25 | Early Commands | 53 | Early Commands |
179 | 26 | ~~~~~~~~~~~~~~ | 54 | ~~~~~~~~~~~~~~ |
180 | 27 | Early commands are executed on the system, and non-zero exit status will terminate the installation process. These commands are intended to be used for things like | 55 | Early commands are executed on the system, and non-zero exit status will terminate the installation process. These commands are intended to be used for things like |
181 | @@ -48,32 +76,23 @@ | |||
182 | 48 | 10_wipe_filesystems: curtin wipe --quick --all-unused-disks | 76 | 10_wipe_filesystems: curtin wipe --quick --all-unused-disks |
183 | 49 | 50_setup_raid: curtin disk-setup --all-disks raid0 / | 77 | 50_setup_raid: curtin disk-setup --all-disks raid0 / |
184 | 50 | 78 | ||
211 | 51 | **Command environment** | 79 | |
212 | 52 | 80 | Network Discovery | |
213 | 53 | Partitioning commands have the following environment variables available to them: | 81 | ~~~~~~~~~~~~~~~~~ |
214 | 54 | 82 | Networking configuration is *discovered* in the 'network' stage. | |
215 | 55 | - ``WORKING_DIR``: This is simply for some sort of inter-command state. It will be the same directory for each command run and will only be deleted at the end of all partitioning_commands. | 83 | The default command run at this stage is ``curtin net-meta auto``. After |
216 | 56 | - ``OUTPUT_FSTAB``: This is the target path for a fstab file. After all partitioning commands have been run, a file should exist, formatted per fstab(5) that describes how the filesystems should be mounted. | 84 | execution, it will write the discovered networking to the file specified |
217 | 57 | - ``TARGET_MOUNT_POINT``: | 85 | in the environment variable ``OUTPUT_NETWORK_CONFIG``. The format of this |
218 | 58 | 86 | file is as described in :ref:`networking`. | |
219 | 59 | 87 | ||
220 | 60 | Network Discovery and Setup | 88 | If curtin's config has a network section, the net-meta will simply parrot the |
221 | 61 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 89 | data to the output file. If there is no network section, then its default |
222 | 62 | Networking is done in a similar fashion to partitioning. A series of commands, specified in the config are run. At the end of these commands, a interfaces(5) style file is expected to be written to ``OUTPUT_INTERFACES``. | 90 | behavior is to copy existing config from the running environment. |
223 | 63 | 91 | ||
224 | 64 | Note, that as with fstab, this file is not copied verbatim to the target filesystem, but rather made available to the OS customization stage. That stage may just copy the file verbatim, but may also parse it, and use that as input. | 92 | Note, that as with fstab, this file is not copied verbatim to the target |
225 | 65 | 93 | filesystem, but rather made available to the OS customization stage. That | |
226 | 66 | **Config Example**:: | 94 | stage may just copy the file verbatim, but may also parse it, and apply the |
227 | 67 | 95 | settings. | |
202 | 68 | network_commands: | ||
203 | 69 | 10_netconf: curtin network copy-existing | ||
204 | 70 | |||
205 | 71 | **Command environment** | ||
206 | 72 | |||
207 | 73 | Networking commands have the following environment variables available to them: | ||
208 | 74 | |||
209 | 75 | - ``WORKING_DIR``: This is simply for some sort of inter-command state. It will be the same directory for each command run and will only be deleted at the end of all network_commands. | ||
210 | 76 | - ``OUTPUT_INTERFACES``: This is the target path for an interfaces style file. After all commands have been run, a file should exist, formatted per interfaces(5) that describes the systems network setup. | ||
228 | 77 | 96 | ||
229 | 78 | Extraction of sources | 97 | Extraction of sources |
230 | 79 | ~~~~~~~~~~~~~~~~~~~~~ | 98 | ~~~~~~~~~~~~~~~~~~~~~ |
231 | @@ -88,27 +107,6 @@ | |||
232 | 88 | 107 | ||
233 | 89 | wget $URL | tar -Sxvzf | 108 | wget $URL | tar -Sxvzf |
234 | 90 | 109 | ||
235 | 91 | Hook for installed OS to customize itself | ||
236 | 92 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
237 | 93 | After extraction of sources, the source that was extracted is then given a chance to customize itself for the system. This customization may include: | ||
238 | 94 | - ensuring that appropriate device drivers are loaded on first boot | ||
239 | 95 | - consuming the network interfaces file and applying its declarations. | ||
240 | 96 | - ensuring that necessary packages | ||
241 | 97 | |||
242 | 98 | **Config Example**:: | ||
243 | 99 | |||
244 | 100 | config_hook: {{TARGET_MP}}/opt/curtin/config-hook | ||
245 | 101 | |||
246 | 102 | **Command environment** | ||
247 | 103 | - ``INTERFACES``: This is a path to the file created during networking stage | ||
248 | 104 | - ``FSTAB``: This is a path to the file created during partitioning stage | ||
249 | 105 | - ``CONFIG``: This is a path to the curtin config file. It is provided so that additional configuration could be provided through to the OS customization. | ||
250 | 106 | |||
251 | 107 | **Helpers** | ||
252 | 108 | |||
253 | 109 | Curtin provides some helpers to make the OS customization easier. | ||
254 | 110 | - `curtin in-target`: run the command while chrooted into the target. | ||
255 | 111 | |||
256 | 112 | Final Commands | 110 | Final Commands |
257 | 113 | ~~~~~~~~~~~~~~ | 111 | ~~~~~~~~~~~~~~ |
258 | 114 | 112 | ||
259 | 115 | 113 | ||
260 | === modified file 'doc/topics/storage.rst' | |||
261 | --- doc/topics/storage.rst 2017-04-21 17:36:27 +0000 | |||
262 | +++ doc/topics/storage.rst 2017-09-29 22:00:32 +0000 | |||
263 | @@ -1,3 +1,5 @@ | |||
264 | 1 | .. _storage: | ||
265 | 2 | |||
266 | 1 | ======= | 3 | ======= |
267 | 2 | Storage | 4 | Storage |
268 | 3 | ======= | 5 | ======= |
PASSED: Continuous integration, rev:536 /jenkins. ubuntu. com/server/ job/curtin- ci/637/ /jenkins. ubuntu. com/server/ job/curtin- ci/nodes= metal-amd64/ 637 /jenkins. ubuntu. com/server/ job/curtin- ci/nodes= metal-arm64/ 637 /jenkins. ubuntu. com/server/ job/curtin- ci/nodes= metal-ppc64el/ 637 /jenkins. ubuntu. com/server/ job/curtin- ci/nodes= metal-s390x/ 637
https:/
Executed test runs:
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
Click here to trigger a rebuild: /jenkins. ubuntu. com/server/ job/curtin- ci/637/ rebuild
https:/