[2.0b5] ValueError: The IPRange could not be created because the data didn't validate.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MAAS |
Invalid
|
Medium
|
Unassigned |
Bug Description
While trying to re-configure DHCP in the UI:
2016-04-13 23:06:52 [-] Error on request (27) vlan.configure_
Traceback (most recent call last):
File "/usr/lib/
self.
File "/usr/lib/
return target()
File "/usr/lib/
task()
File "/usr/lib/
task()
--- <exception caught here> ---
File "/usr/lib/
result = inContext.theWork()
File "/usr/lib/
inContext.
File "/usr/lib/
return self.currentCon
File "/usr/lib/
return func(*args,**kw)
File "/usr/lib/
return func(*args, **kwargs)
File "/usr/lib/
return func_outside_
File "/usr/lib/
return func(*args, **kwargs)
File "/usr/lib/
return func(*args, **kwds)
File "/usr/lib/
self.
File "/usr/lib/
iprange_
File "/usr/lib/
construct=
File "/usr/lib/
" validate." % (opts.object_name, fail_message))
builtins.
summary: |
- Sdf + ValueError: The IPRange could not be created because the data didn't + validate. |
description: | updated |
Changed in maas: | |
importance: | Undecided → Critical |
milestone: | none → 2.0.0 |
Changed in maas: | |
status: | Incomplete → New |
summary: |
- ValueError: The IPRange could not be created because the data didn't - validate. + [2.0b5] ValueError: The IPRange could not be created because the data + didn't validate. |
Changed in maas: | |
assignee: | nobody → Mike Pontillo (mpontillo) |
Changed in maas: | |
milestone: | 2.0.0 → 2.3.x |
When we talked earlier, I think you said that after you refreshed the UI the option to change the range went away.
I think the root cause of this issue is most likely that the subnet cached in the UI did not get updated after the initial range was defined. (most likely an issue with the trigger the websocket is listening for)
It's also possible that the behavior will change with the latest code, since showing those fields is based on whether or not a suggestion for a possible dynamic range is seen in the incoming JSON from the server. So it would be good to try to reproduce with the latest code, now that the fix for bug #1569984 has landed.
Meanwhile, I'll manually test and try to reproduce this bug.