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

Bug #1276985 reported by Raphaël Badin on 2014-02-06
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
High
Raphaël Badin

Bug Description

That field name is pretty confusing as it's undocumented.

Tags: ui Edit Tag help

Related branches

Raphaël Badin (rvb) wrote :
Raphaël Badin (rvb) wrote :

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.

Julian Edwards (julian-edwards) wrote :

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

Changed in maas:
importance: Medium → High
milestone: none → 14.04
Raphaël Badin (rvb) wrote :

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.

Julian Edwards (julian-edwards) wrote :

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

Raphaël Badin (rvb) 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.

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?

Raphaël Badin (rvb) wrote :

s/as done/has done/

Raphaël Badin (rvb) on 2014-02-10
Changed in maas:
assignee: nobody → Raphaël Badin (rvb)
status: Triaged → In Progress
Raphaël Badin (rvb) on 2014-02-11
Changed in maas:
status: In Progress → Fix Committed
Changed in maas:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers