The "Edit cluster interface" page shows an undocumented "Foreign dhcp ip" field.

This field is used to store the IP address of another DHCP server on the network. It's displayed on the cluster interface listing page to warn users about the presence of another DHCP server. My take on this is that the user shouldn't be able to edit it.

Not sure why that field is there, it should not be. Feel free to remove it.

The periodic_probe_dhcp task uses the API to change this field. It does so by updating the interface and the form to update the interface is shared between the API and the UI. That's the reason why it's present in the UI.

I see two possible course of actions:
- Remove the field from the form. Add a new API call dedicated to upgrading this field. This has the advantage of not including this field in the normal update API call.
- Have two forms: one for the API with the field, one for the UI without the field.

If we have a separate API call will it solve the problem with the signals? I suspect not, but asking anyway :)

> If we have a separate API call will it solve the problem with the signals? I suspect not, but asking anyway :)

Actually, funny that you should mention this because Jeroen and I have been having the exact same thought:
If we save the object using obj.save() then the signals will be fired… but if we use update() then we're good because update() doesn't call the signals.

https://docs.djangoproject.com/en/dev/topics/db/queries/#updating-multiple-objects-at-once
"""
Be aware that the update() method is converted directly to an SQL statement. It is a bulk operation for direct updates. It doesn’t run any save() methods on your models, or emit the pre_save or post_save signals (which are a consequence of calling save()), or honor the auto_now field option.
"""

On Friday 07 Feb 2014 10:59:36 you wrote:
> > If we have a separate API call will it solve the problem with the
>
> signals? I suspect not, but asking anyway :)
>
> Actually, funny that you should mention this because Jeroen and I have been
> having the exact same thought: If we save the object using obj.save() then
> the signals will be fired… but if we use update() then we're good because
> update() doesn't call the signals.

Interesting. It sounds dangerous and useful at the same time :)

Are you thinking of using it?

> Are you thinking of using it?

Yes, that's precisely what Jeroen as done in https://code.launchpad.net/~jtv/maas/report-foreign-dhcp/+merge/205430 and https://code.launchpad.net/~jtv/maas/validate-foreign-dhcp/+merge/205551.

s/as done/has done/