Merge lp:~allenap/maas/anon-power-setting into lp:maas/trunk
| Status: | Merged | ||||
|---|---|---|---|---|---|
| Approved by: | Gavin Panella on 2012-10-08 | ||||
| Approved revision: | 1174 | ||||
| Merged at revision: | 1208 | ||||
| Proposed branch: | lp:~allenap/maas/anon-power-setting | ||||
| Merge into: | lp:maas/trunk | ||||
| Diff against target: |
325 lines (+139/-33) 4 files modified
src/maasserver/api.py (+32/-1) src/maasserver/tests/test_api.py (+103/-6) src/metadataserver/api.py (+2/-24) src/metadataserver/tests/test_api.py (+2/-2) |
||||
| To merge this branch: | bzr merge lp:~allenap/maas/anon-power-setting | ||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Raphaël Badin (community) | Approve on 2012-10-05 | ||
| Julian Edwards (community) | 2012-10-04 | Approve on 2012-10-05 | |
|
Review via email:
|
|||
Commit Message
Allows power parameters to be supplied at enlistment.
| MAAS Lander (maas-lander) wrote : | # |
| MAAS Lander (maas-lander) wrote : | # |
The Jenkins job https:/
Not merging it.
- 1173. By Gavin Panella on 2012-10-05
-
Rewrite store_node_
power_parameter s; it was fairly broken, and was untested. - 1174. By Gavin Panella on 2012-10-05
-
Fix test fallout.
| Raphaël Badin (rvb) wrote : | # |
Looks good, thanks for spotting the problem and fixing this Gavin!
[0]
def store_node_
I wonder if it would not be more clear to change the signature of this method to store_node_
[1]
+ self.assertEqua
+ self.assertEqua
+ self.save.
I think it would be cleaner to test the behavior here and:
- not patch the save method
- test that reload_
Same remark in a few other places.
[2]
+ self.assertRaises(
+ MAASAPIBadRequest, store_node_
+ self.node, self.request)
+ self.save.
Again, instead of 'self.save.
[3]
+ power_types = map_enum(
+ if power_type in power_types:
+ node.power_type = power_type
+ else:
+ raise MAASAPIBadReque
51 + except ValueError:
52 + raise MAASAPIBadReque
This should probably be a ValidationError
Rarg, all of this is kinda ugly, that's exactly why we should use forms to take care of validation. Django forms are not perfect, but they are still much better than doing all of this manually. Of course, this can be refined later ( "# Hack in the power parameters here." -> that's really what it says in the tin :)).
[4]
194 + [node] = Node.objects.
I'd use "node = Node.objects.
| Andres Rodriguez (andreserl) wrote : | # |
Wouldn't it be easier leave the metadataserver api method as it is (to not break commissioning), and simply allow the power parameters to be passed on enlistment the same way it is with the rest of the parameters?
| Gavin Panella (allenap) wrote : | # |
On 5 October 2012 17:09, Andres Rodriguez <email address hidden> wrote:
> Wouldn't it be easier leave the metadataserver api method as it is (to not break commissioning), and simply allow the power parameters to be passed on enlistment the same way it is with the rest of the parameters?
That's kind of what store_node_
a better way of doing it I'm interested to know; this is not an area
where I have much expertise.
As to leaving the commissioning thing alone, I have mixed feelings. On
one hand it's broken, by validating against the wrong list of choices,
and on the other I don't want to accidentally break something that's
working.
Are there any tests for the commissioning scripts, the ones that run
on the node? They should prevent us from breaking this contract.
| Andres Rodriguez (andreserl) wrote : | # |
What do you mean by evaluating against the wrong list of choices? It evaluates against the correct power types, which is what we need t evaluate. This has been tested correctly (passing incorrect power_type).
No there are no tests for the commissioning scripts.. not an easy thing to do. IMHO much more complex than adding tests for maas-import-
| Gavin Panella (allenap) wrote : | # |
> What do you mean by evaluating against the wrong list of choices? It evaluates
> against the correct power types, which is what we need t evaluate. This has
> been tested correctly (passing incorrect power_type).
It checks that the given power type, converted to upper-case, is a
member of map_enum(
is an attribute-
given parameter matches one of the enum's attribute names, i.e. a
Python variable name. It should be checking (without changing case)
against map_enum(
> No there are no tests for the commissioning scripts.. not an easy thing to do.
> IMHO much more complex than adding tests for maas-import-
No, granted, an integration test of that would be a beast. We could
add unit tests for individual parts of those scripts though, for
example the part that sends the commissioning result, but I don't
think we'll have time for that before releasing 12.10.
| Julian Edwards (julian-edwards) wrote : | # |
On Friday 05 October 2012 21:50:27 you wrote:
> It checks that the given power type, converted to upper-case, is a
> member of map_enum(
> is an attribute-
> given parameter matches one of the enum's attribute names, i.e. a
> Python variable name. It should be checking (without changing case)
> against map_enum(
What's the practical difference? (Given what map_enum is doing)
> > No there are no tests for the commissioning scripts.. not an easy thing to
> > do. IMHO much more complex than adding tests for maas-import-
> No, granted, an integration test of that would be a beast. We could
> add unit tests for individual parts of those scripts though, for
> example the part that sends the commissioning result, but I don't
> think we'll have time for that before releasing 12.10.
Sadly no, this will go down as tech debt.
| Gavin Panella (allenap) wrote : | # |
On 8 October 2012 00:51, Julian Edwards <...> wrote:
> On Friday 05 October 2012 21:50:27 you wrote:
>> It checks that the given power type, converted to upper-case, is a
>> member of map_enum(
>> is an attribute-
>> given parameter matches one of the enum's attribute names, i.e. a
>> Python variable name. It should be checking (without changing case)
>> against map_enum(
>
> What's the practical difference? (Given what map_enum is doing)
It's looking in the keys:
>>> map_enum(
['DEFAULT', 'IPMI', 'VIRSH', 'WAKE_ON_LAN']
but it should be looking in the values:
>>> map_enum(
[u'', u'ipmi', u'virsh', u'ether_wake']
| Julian Edwards (julian-edwards) wrote : | # |
On Monday 08 October 2012 08:52:43 you wrote:
> On 8 October 2012 00:51, Julian Edwards <...> wrote:
> > On Friday 05 October 2012 21:50:27 you wrote:
> >> It checks that the given power type, converted to upper-case, is a
> >> member of map_enum(
> >> is an attribute-
> >> given parameter matches one of the enum's attribute names, i.e. a
> >> Python variable name. It should be checking (without changing case)
> >> against map_enum(
> >
> > What's the practical difference? (Given what map_enum is doing)
>
> It's looking in the keys:
>
> >>> map_enum(
> ['DEFAULT', 'IPMI', 'VIRSH', 'WAKE_ON_LAN']
>
> but it should be looking in the values:
>
> >>> map_enum(
> [u'', u'ipmi', u'virsh', u'ether_wake']
Right. As we discussed in the hangout, it's ok to just change this as
fortunately the only thing using it so far is the impi stuff where the key is
the same as the value.


The Jenkins job https:/ /jenkins. qa.ubuntu. com/job/ maas-merger- quantal/ 117/console reported an error when processing this lp:~allenap/maas/anon-power-setting branch.
Not merging it.