[UI, websockets] Show usage on 'Reserved ranges' table on VLAN summary page
Bug #1815784 reported by
Steve Rydz
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| MAAS |
Invalid
|
Medium
|
Mike Pontillo | ||
Bug Description
On the VLAN summary page there is a table for 'Reserved ranges'. In that table it would be good to show the usage in a column.
Currently the only data returned for each row is start_ip and end_ip. I believe we would need more data in order to calculate it, or a field such as the usage_string field which is used in the subnets table below.
Here is the design: https:/
| Changed in maas: | |
| status: | New → Triaged |
| importance: | Undecided → Medium |
| milestone: | none → 2.6.0 |
Revision history for this message
| Mike Pontillo (mpontillo) wrote | #1 |
| summary: |
- Show usage on 'Reserved ranges' table on VLAN summary page + [UI, websockets] Show usage on 'Reserved ranges' table on VLAN summary + page |
Revision history for this message
| Adam Collard (adam-collard) wrote | #2 |
| Changed in maas: | |
| status: | Triaged → Invalid |
To post a comment you must log in.
I spent some time today looking at this.
The relevant code that will need to be changed is likely to be maasserver/
This code is relatively complex, especially since the definition of a reserved range (whether or not the IPs are "in-use" or not) can change depending on if the subnet is managed or unmanaged.
I think the most efficient way to make this calculation would be to allow the MAASIPSet to be divided into smaller sets of addresses, based on the start and end address of the range. Then we could re-use all the code that calculates range usage by calculating it once for the subnet, and then iterating over each range and including that separately for each IP range returned by the websocket/CLI.
Note that there has also been some concern about the performance impacts of doing this on a per-range basis, which will need to be investigated as well. I don't expect the performance of the calculation itself to be particularly impactful. But the websocket may trigger recalculations based on distantly-related objects or updates to irrelevant relationships with other model objects in MAAS, so it may be a problem in aggregate.
I'll continue to investigate this tomorrow.