View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 989 | RackTables | default | public | 2013-08-02 08:05 | 2013-08-07 10:09 |
| Reporter | combr | Assigned To | |||
| Priority | normal | Severity | tweak | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 0.20.5 | ||||
| Summary | 989: cannot expand network range - cannot delete allocation becaise of liveptr | ||||
| Description | I set a new network range /29, and use it (add servers to it by hand, and try LivePTR that found a matches). Then I got an extended network range /28 - same 8 addresses + neighbor 8 addresses and want to extend it in racktables. I not found nor simple, nor complex way to do it :) 1. Simple way - edit network mask and done (no way, can't find how i change it via interface, properties tab do not show anything similar). 2. Complex way - delete all membership of range, delete range, create new extended range. Or create new range without deletion and re-accociate members. No way - after delete members i can't delete range because LivePTR found a match and I can't cancel it. With LivePTR member i can't delete range. Suggestions: 1. Add an interface option to edit network mask. 2. Add an interface option to edit (delete) LivePTR imports. | ||||
| Tags | No tags attached. | ||||
|
If i try to add new extended range, delete IP+interface from server and try to add it, it automatically binds with old, smaller network range! Maybe if ip address matches two or more overlapped ranges - before bind it give to user its list and user select it by hand? |
|
| Please see this: http://www.freelists.org/post/racktables-users/IPv4-Question,1 | |
|
thanks, with "IPV4_JAYWALK = yes" I, at least, was able to delete range. But it very far from obvious and does not change that suggestions above :) |
|
| Would you like to open a pull request on GitHub? https://github.com/RackTables/racktables | |
|
pull from what? If decribed behaviour are inconvenient, it must be here anyway (waiting for assign and include to roadmap to fix by the current or new developers), regardless of needed changes complexity. If it considered convenient by the developers or other users, it may be closed, desirable with described reason. I am not a php developer in any way, therefore I don't have something to suggest to pull. |
|
| OK, closing for now. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-08-02 08:05 | combr | New Issue | |
| 2013-08-02 08:11 | combr | Note Added: 0001687 | |
| 2013-08-05 16:58 | infrastation | Note Added: 0001699 | |
| 2013-08-06 07:15 | combr | Note Added: 0001703 | |
| 2013-08-06 11:46 | infrastation | Note Added: 0001705 | |
| 2013-08-07 07:21 | combr | Note Added: 0001707 | |
| 2013-08-07 10:09 | infrastation | Note Added: 0001709 | |
| 2013-08-07 10:09 | infrastation | Status | new => closed |
| 2013-08-07 10:09 | infrastation | Resolution | open => no change required |