Merge lp:~allenap/maas/fix-makefile-write-dhcp-stuff into lp:~maas-committers/maas/trunk
Status: | Merged |
---|---|
Approved by: | Gavin Panella |
Approved revision: | no longer in the source branch. |
Merged at revision: | 624 |
Proposed branch: | lp:~allenap/maas/fix-makefile-write-dhcp-stuff |
Merge into: | lp:~maas-committers/maas/trunk |
Diff against target: |
173 lines (+15/-66) 4 files modified
Makefile (+1/-6) buildout.cfg (+1/-7) src/provisioningserver/dhcp/tests/test_writer.py (+7/-40) src/provisioningserver/dhcp/writer.py (+6/-13) |
To merge this branch: | bzr merge lp:~allenap/maas/fix-makefile-write-dhcp-stuff |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Raphaël Badin (community) | Approve | ||
Review via email: mp+109324@code.launchpad.net |
Commit message
Tweak the way the DHCPConfigWriter is plumbed in.
Description of the change
This changes a few bits about the new DHCPConfigWriter.
- Renames write_dhcp_
provisionings
it's about configuration.
- Removes the write_dhcp_config script entirely. It's not necessary -
use bin/py -m provisioningser
misleading because packages cannot use it anyway as it is generated
by buildout.
- Remove all references to write_dhcp_config from Makefile.
- Remove the test for the write_dhcp_config script.
- Use stdout.write() to emit the config instead of print(); the latter
adds an extra newline.
- Encodes the config as ASCII for the paranoid.
- Drive-by: restricts the scripts that the [database] part in
buildout.cfg creates to just the bin/database script. Previously it
was also generating a bin/postgresfixture script.
Looks good. +15/-66 without loosing functionality, that's nice.
Maybe we can wait for Julian to clarify things about [0] but I'll leave it up to you because, in my opinion, this is all good.
[0]
> Removes the write_dhcp_config script entirely. It's not necessary - ver/dhcp/ writer instead - and is
> use bin/py -m provisioningser
> misleading because packages cannot use it anyway as it is generated
> by buildout.
I agree with you. Since Julian is away I can only speculate here but this script can only be a development convenience and if it's the case then using the command as you suggest is, I think, good enough.
So far, when we had the need to expose a command, the usual way to do that has been to create a Django command. Now, unless I'm mistaken, this is part of the provisioning server because it will be run by the workers. We haven't talked about this but the workers will probably need to install a specific maas package (something like 'maas-worker') rather that the server 'maas' package and this worker package will only contain the worker code (i.e. the module 'provisioningse rver'). This implies that if we want to ship scripts in this worker package we will have to come up with a new strategy because the Django MAAS application (and thus CLI) won't be installed there.