Merge lp:~jameinel/maas/1.2-pxeconfig-includes-kernel-opts into lp:maas/1.2
| Status: | Merged |
|---|---|
| Approved by: | John A Meinel on 2012-11-08 |
| Approved revision: | 1288 |
| Merged at revision: | 1290 |
| Proposed branch: | lp:~jameinel/maas/1.2-pxeconfig-includes-kernel-opts |
| Merge into: | lp:maas/1.2 |
| Diff against target: |
99 lines (+43/-1) 4 files modified
src/maasserver/api.py (+9/-1) src/maasserver/tests/test_api.py (+17/-0) src/provisioningserver/kernel_opts.py (+4/-0) src/provisioningserver/tests/test_kernel_opts.py (+13/-0) |
| To merge this branch: | bzr merge lp:~jameinel/maas/1.2-pxeconfig-includes-kernel-opts |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Julian Edwards (community) | 2012-11-07 | Approve on 2012-11-08 | |
|
Review via email:
|
|||
Commit Message
Expose the new kernel options to the pxeconfig api.
Add the extra options to KernelParameters, and return them when the tftp server places its request.
Tweak the tftp server so that it adds the new parameters to the commandline.
Description of the Change
This closes the loop, so that nodes should boot with kernel_opts that are set (either in the global config, or once my other patches land in a tag.)
The main downside is that this is technically an API break as 'pxe_config' is now returning extra data in the JSON response, but old clients are strict about what data they accept. (They take the exact JSON back into a dict and pass it as **kwargs to the namedtuple constructor, which requires an exact match.)
If we really care about that, then we can bump the api version or something like that. It doesn't really make sense to add another API call just to get a little bit more data. We already have to configure the one URL in pserv.yaml, it would be silly to add a lot of other config to just make one more request.
| MAAS Lander (maas-lander) wrote : | # |
There are additional revisions which have not been approved in review. Please seek review and approval of these new revisions.


Given that I doubt anyone is upgrading in anything other than lockstep right now, I think it's fine to change this (internal) API call. However once we know people are doing bigger deployments, the API call will need to be different and we bump the version so that clusters are not forced into lockstep upgrades.