Merge lp:~jtv/maas/bug-1025582-task into lp:maas/trunk
| Status: | Merged | ||||
|---|---|---|---|---|---|
| Approved by: | Jeroen T. Vermeulen on 2012-09-14 | ||||
| Approved revision: | 1003 | ||||
| Merged at revision: | 999 | ||||
| Proposed branch: | lp:~jtv/maas/bug-1025582-task | ||||
| Merge into: | lp:maas/trunk | ||||
| Prerequisite: | lp:~jtv/maas/bug-1025582-api | ||||
| Diff against target: |
661 lines (+467/-16) 10 files modified
etc/celeryconfig.py (+7/-0) src/apiclient/testing/credentials.py (+26/-0) src/maasserver/tests/test_api.py (+16/-0) src/provisioningserver/boot_images.py (+68/-0) src/provisioningserver/pxe/tests/test_tftppath.py (+134/-0) src/provisioningserver/pxe/tftppath.py (+84/-0) src/provisioningserver/tasks.py (+12/-0) src/provisioningserver/tests/test_auth.py (+3/-11) src/provisioningserver/tests/test_boot_images.py (+80/-0) src/provisioningserver/tests/test_tasks.py (+37/-5) |
||||
| To merge this branch: | bzr merge lp:~jtv/maas/bug-1025582-task | ||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Julian Edwards (community) | 2012-09-12 | Approve on 2012-09-14 | |
|
Review via email:
|
|||
Commit Message
Have the master worker report its available boot images.
This creates a new task for the master worker, and runs it on a 5-minute schedule. The task scans the TFTP filesystem tree (which is on the same system as the master worker) for boot images, and reports what it finds to the API. In a subsequent branch, the UI will report missing images as a persistent error.
Description of the Change
See commit message. Pre-implementation call with Julian.
There's a lot of testing going on, especially for the helpers that drill down into multiple directories at once. It seems a bit weird in places but it was an effective way of getting a flat listing of all boot images' parameters. Any suggestions for tests that I could sensibly drop are welcome.
This branch is to be backported to 1.1.
Jeroen
- 999. By Jeroen T. Vermeulen on 2012-09-13
-
Merge review changes from pre-predecessor branch.
| Gavin Panella (allenap) wrote : | # |
| Julian Edwards (julian-edwards) wrote : | # |
On Thursday 13 September 2012 08:05:30 you wrote:
> > The task scans the TFTP filesystem tree (which is on the same system
> > as the master worker) for boot images, ...
>
> It /may/ be on the same filesystem, but there's no guarantee. The TFTP
> filesystem tree needs to be mirrored to each cluster controller. I
> guess where there's a worker there's a cluster controller, because
> they're bundled as one?
That is our implementation of the cluster controller, yes. So we can make
this guarantee.
> This doesn't take into account future cluster controllers. The region
> asks the cluster for a machine matching $constraints and then to put
> $release on it; the cluster could decide to use an different,
> hardware-tuned, image, instead of the one from cloud images. Though I
> don't think this is a requirement right now, we need to bear a very
> much more intelligence-
It's the direction in which we're heading, yes. The only thing that can know
about this is the cluster (pserv) which is why it's reporting it via the API.
Everything else is an implementation detail.
| Julian Edwards (julian-edwards) wrote : | # |
FWIW I don't like the commit message, it seems like a lot of it should be in the description. It should really just state the change happening (and why). Also... conflicts :(
- 1000. By Jeroen T. Vermeulen on 2012-09-14
-
Merge trunk and conflict resolution from predecessor branch, resolve another conflict.
- 1001. By Jeroen T. Vermeulen on 2012-09-14
-
Revert some debugging changes.
| Julian Edwards (julian-edwards) wrote : | # |
Nice testing!
54 >>>>>>> MERGE-SOURCE
Stray merge marker.
277 + [arch, subarch, release, purpose] = path
You don't need the [ and ] here.
Is it always guaranteed to have four elements? Otherwise the unpacking will blow up.
278 + return {
279 + 'architecture': arch,
280 + 'subarchitecture': subarch,
281 + 'release': release,
282 + 'purpose': purpose,
283 + }
How about:
return dict(
I also wonder if a named tuple might be better so you could do something like ``path.
310 === modified file 'src/provisioni
[lots of imports]
I really think we should keep tasks.py very lean, and import functions from elsewhere that do the actual work. It'll keep things more structured, and then tasks.py becomes an inclusion point, a bit like models/__init__.py.
373 + task_logger.
377 + task_logger.
I think these would be better as debugging logs.
- 1002. By Jeroen T. Vermeulen on 2012-09-14
-
Some review changes.
- 1003. By Jeroen T. Vermeulen on 2012-09-14
-
Review changes: move task out into its own module (occasioning creation of apiclient.testing), log missing info from server at debug level.
| Jeroen T. Vermeulen (jtv) wrote : | # |
> Nice testing!
>
> 54 >>>>>>> MERGE-SOURCE
>
> Stray merge marker.
I so hope those were separate comments and not sarcasm. :) The marker was just a bit of diff artifact inherited from a conflict in the parent branch.
> 277 + [arch, subarch, release, purpose] = path
>
> You don't need the [ and ] here.
Fixed.
> Is it always guaranteed to have four elements? Otherwise the unpacking will
> blow up.
Yes, it is — but I could have documented it. Now I have.
> 278 + return {
> 279 + 'architecture': arch,
> 280 + 'subarchitecture': subarch,
> 281 + 'release': release,
> 282 + 'purpose': purpose,
> 283 + }
>
> How about:
>
> return dict(
> architecture=arch, subarchitecture
> purpose=purpose)
Done.
> I also wonder if a named tuple might be better so you could do something like
> ``path.
It's certainly tempting. In this particular case though I'm translating from a list to a dict — I don't think a named tuple would have made that much better.
> 310 === modified file 'src/provisioni
>
> [lots of imports]
>
> I really think we should keep tasks.py very lean, and import functions from
> elsewhere that do the actual work. It'll keep things more structured, and
> then tasks.py becomes an inclusion point, a bit like models/__init__.py.
You're right. I was just too lazy to create a separate module for this — and it didn't quite fit in any that we had.
I've now given this its own module, and reduced the task test to a single integration test. Unfortunately one helper in test_tasks was now needed in too many places; I put it in a brand-new maasclient.testing.
> 373 + task_logger.
> yet.")
> 377 + task_logger.
> yet.")
>
> I think these would be better as debugging logs.
Fair enough. Done.
Jeroen
| Jeroen T. Vermeulen (jtv) wrote : | # |
I've moved some text from the commit message to the description. Still experimenting with this new distribution of responsibilities between the two.


> The task scans the TFTP filesystem tree (which is on the same system
> as the master worker) for boot images, ...
It /may/ be on the same filesystem, but there's no guarantee. The TFTP
filesystem tree needs to be mirrored to each cluster controller. I
guess where there's a worker there's a cluster controller, because
they're bundled as one?
This doesn't take into account future cluster controllers. The region at-the- edge approach in mind, imo.
asks the cluster for a machine matching $constraints and then to put
$release on it; the cluster could decide to use an different,
hardware-tuned, image, instead of the one from cloud images. Though I
don't think this is a requirement right now, we need to bear a very
much more intelligence-