Merge lp:~gz/maas/1.2_add_db_kernel_params into lp:maas/1.2
| Status: | Merged |
|---|---|
| Approved by: | Martin Packman on 2012-11-07 |
| Approved revision: | 1287 |
| Merged at revision: | 1285 |
| Proposed branch: | lp:~gz/maas/1.2_add_db_kernel_params |
| Merge into: | lp:maas/1.2 |
| Prerequisite: | lp:~gz/maas/1.2_fix_duplicated_039_migration |
| Diff against target: |
271 lines (+220/-3) 4 files modified
src/maasserver/migrations/0043_add_tag_kernel_opts.py (+203/-0) src/maasserver/models/tag.py (+3/-0) src/maasserver/testing/factory.py (+4/-3) src/maasserver/tests/test_tag.py (+10/-0) |
| To merge this branch: | bzr merge lp:~gz/maas/1.2_add_db_kernel_params |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| John A Meinel | 2012-11-06 | Approve on 2012-11-06 | |
|
Review via email:
|
|||
Commit Message
Add kernel_opts field to Tag to allow for customisation of kernel command line
Description of the Change
Adds a field to Tag for holding custom kernel parameters, which is a step towards resolving bug 1044503.
The plan is to store the global options as a specially named field in Config, which will not require a migration. The values there are json, but it's fine to just use a string instead of an object. The per-tag customisation could also be done there by packing the tag name into the key, but having a string field on tag is simple enough.
The added field allows null in the hope that we may be able to distinguish "use global" from "use no params" simply.
- 1286. By Martin Packman on 2012-11-06
-
Document and test kernel_params a little
| Martin Packman (gz) wrote : | # |
Have added to the class docstring, and integrated a little with the testing environment. Real testing can wait for when there's some actual logic I think.
- 1287. By Martin Packman on 2012-11-07
-
Rename added field to kernel_opts from kernel_params
| Martin Packman (gz) wrote : | # |
As suggested by John on call, have renamed kernel_params field to kernel_opts which is closer to the existing usage in provisioningserver.


The actual change seems good. But I'm thinking there should be a docstring somewhere that needs updating as well. And maybe some sort of test about setting & getting the value?