Merge lp:~jtv/maas/bug-1025582-model into lp:maas/trunk
| Status: | Merged | ||||
|---|---|---|---|---|---|
| Approved by: | Jeroen T. Vermeulen on 2012-09-13 | ||||
| Approved revision: | 988 | ||||
| Merged at revision: | 990 | ||||
| Proposed branch: | lp:~jtv/maas/bug-1025582-model | ||||
| Merge into: | lp:maas/trunk | ||||
| Diff against target: |
398 lines (+339/-1) 5 files modified
src/maasserver/migrations/0025_add_bootimage_model.py (+182/-0) src/maasserver/models/__init__.py (+4/-1) src/maasserver/models/bootimage.py (+89/-0) src/maasserver/testing/factory.py (+17/-0) src/maasserver/tests/test_bootimage.py (+47/-0) |
||||
| To merge this branch: | bzr merge lp:~jtv/maas/bug-1025582-model | ||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Julian Edwards (community) | Approve on 2012-09-13 | ||
| Raphaël Badin (community) | 2012-09-11 | Needs Information on 2012-09-12 | |
|
Review via email:
|
|||
Commit Message
New model: BootImage. Represents an available boot image, so that the server can detect use of missing images.
This new model represents what types of node we can boot which releases on, for which purpose. Since the inventory only changes when we have a new image, complete and ready to install, there is no provision for disappearing images.
Description of the Change
The master worker (which runs on the same machine as the TFTP server) will report available images regularly through the MAAS API. The download script can't do this directly because it has no API credentials.
Nobody was available to pre-imp this part of the work with, so read critically.
Jeroen
- 985. By Jeroen T. Vermeulen on 2012-09-11
-
Merge trunk workaround for Django fix that broke our tests.
- 986. By Jeroen T. Vermeulen on 2012-09-13
-
Review change: renumber DB migration as newer branches overtake this one in review.
| Jeroen T. Vermeulen (jtv) wrote : | # |
> Looks generally good, but I really wonder about [1], so "needs information".
>
> [0]
>
> src/maasserver/
>
> Would you mind renaming this 0025_add_
> landed migrations 21 and 22 and I've got branches in review for migrations 23
> and 24.
Done.
> [1]
>
> 297 + architecture = CharField(
> 298 + subarchitecture = CharField(
> 299 + release = CharField(
> 300 + purpose = CharField(
>
> Why didn't you use CharField with choices here (same as, for instance,
> node.architecture)?
Because I thought that Django might possibly enforce it, which would not be what I wanted: registering available images shouldn't break just because you've got an architecture that the server isn't aware of yet.
But as it turns out the choices option isn't model-related. It's purely for the UI, which this model doesn't have — so probably not worth holding up these reviews for! I added it and made the fields non-editable.
- 987. By Jeroen T. Vermeulen on 2012-09-13
-
Review change: set choices for architecture field.
| Julian Edwards (julian-edwards) wrote : | # |
On Thursday 13 September 2012 03:25:22 you wrote:
> > [1]
> >
> > 297 + architecture = CharField(
> > 298 + subarchitecture = CharField(
> > 299 + release = CharField(
> > 300 + purpose = CharField(
> >
> > Why didn't you use CharField with choices here (same as, for instance,
> > node.architecture)?
>
> Because I thought that Django might possibly enforce it, which would not be
> what I wanted: registering available images shouldn't break just because
> you've got an architecture that the server isn't aware of yet.
>
> But as it turns out the choices option isn't model-related. It's purely for
> the UI, which this model doesn't have — so probably not worth holding up
> these reviews for! I added it and made the fields non-editable.
We want to rid the code of all enums for architecture because having one makes
it impossible to install arbitrary new architectures. That is something we
need to support in the near-ish future.
| Julian Edwards (julian-edwards) wrote : | # |
Approved as it was, let's remove the choices.
- 988. By Jeroen T. Vermeulen on 2012-09-13
-
Julian's suggestions.
| Jeroen T. Vermeulen (jtv) wrote : | # |
Thanks. Choices removed, fields documented, propagating changes to successor branches.
| Raphaël Badin (rvb) wrote : | # |
>> [0]
>>
>> src/maasserver/
>>
>> Would you mind renaming this 0025_add_
>> landed migrations 21 and 22 and I've got branches in review for migrations 23
>> and 24.
>Done.
rarg, that was a bad suggestion from me :/. I forgot that each migration not only has information about the delta (what field needs to be added/removed etc.) but also about all of the models. I also spotted a weird (South-related?) problem with the recently uuid field so I'll see about fixing that…


Looks generally good, but I really wonder about [1], so "needs information".
[0]
src/maasserver/ migrations/ 0021_add_ bootimage_ model.py
Would you mind renaming this 0025_add_ bootimage_ model.py? I've recently landed migrations 21 and 22 and I've got branches in review for migrations 23 and 24.
[1]
297 + architecture = CharField( max_length= 255, blank=False) max_length= 255, blank=False) max_length= 255, blank=False) max_length= 255, blank=False)
298 + subarchitecture = CharField(
299 + release = CharField(
300 + purpose = CharField(
Why didn't you use CharField with choices here (same as, for instance, node.architecture)?