starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

'Cooldown' status for IP Addresses and prefixes #5583

New Issue
Closed
opened 2025-12-29 19:29:45 +01:00 by adam · 6 comments
adam commented 2025-12-29 19:29:45 +01:00
Owner
Copy Link

Originally created by @YWatchman on GitHub (Oct 29, 2021).

NetBox version

v3.0.8

Feature type

Change to existing functionality

Proposed functionality

Currently the Netbox IP Address and Prefix statuses are hardcoded to the four 'Container', 'Active', 'Reserved', 'Deprecated'. I would like to add another one with the value 'Cooldown'.

Use case

The status cooldown could be used for IP Addresses and Prefixes that are waiting to be released back in to the pool, for example. I allocate IPs for use in PPPoE which are statically assigned to customers and as soon as their connection get terminated, we legally have to wait for some period to release them back in the pool. Currently this is done by adding a tag 'cooldown' and filtering on these addresses, but visually it would be nicer to add them as status 'cooldown' for easily looking through the list of prefixes.

There obviously also is a color requirement: 'Purple' :-)

Database changes

None

External dependencies

None

Originally created by @YWatchman on GitHub (Oct 29, 2021). ### NetBox version v3.0.8 ### Feature type Change to existing functionality ### Proposed functionality Currently the Netbox IP Address and Prefix statuses are hardcoded to the four 'Container', 'Active', 'Reserved', 'Deprecated'. I would like to add another one with the value 'Cooldown'. ### Use case The status cooldown could be used for IP Addresses and Prefixes that are waiting to be released back in to the pool, for example. I allocate IPs for use in PPPoE which are statically assigned to customers and as soon as their connection get terminated, we legally have to wait for some period to release them back in the pool. Currently this is done by adding a tag 'cooldown' and filtering on these addresses, but visually it would be nicer to add them as status 'cooldown' for easily looking through the list of prefixes. There obviously also is a color requirement: 'Purple' :-) ### Database changes None ### External dependencies None
adam added the type: feature label 2025-12-29 19:29:45 +01:00
adam closed this issue 2025-12-29 19:29:45 +01:00
adam commented 2025-12-29 19:29:46 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 29, 2021):

This sounds redundant to the "reserved" status.

@jeremystretch commented on GitHub (Oct 29, 2021): This sounds redundant to the "reserved" status.
adam commented 2025-12-29 19:29:46 +01:00
Author
Owner
Copy Link

@YWatchman commented on GitHub (Oct 29, 2021):

Hey @jeremystretch, I agree about it sounding redundant. But I do identify them differently, customers who are assigned an IP Address in 'reserved' are about to be deployed or have for example discontinued their old service for moving houses. This way customer gets 2 IPs and the 'new' assigned which gets state 'Active' will be destroyed or 'cooled' and the 'reserved' address will be moved to the new 'tenant' which in our case is an internet subscription.

@YWatchman commented on GitHub (Oct 29, 2021): Hey @jeremystretch, I agree about it sounding redundant. But I do identify them differently, customers who are assigned an IP Address in 'reserved' are about to be deployed or have for example discontinued their old service for moving houses. This way customer gets 2 IPs and the 'new' assigned which gets state 'Active' will be destroyed or 'cooled' and the 'reserved' address will be moved to the new 'tenant' which in our case is an internet subscription.
adam commented 2025-12-29 19:29:46 +01:00
Author
Owner
Copy Link

@julianze commented on GitHub (Oct 29, 2021):

How about 'Decommissioning' as it is already implemented for cables and virtual machines?

@julianze commented on GitHub (Oct 29, 2021): How about 'Decommissioning' as it is already implemented for cables and virtual machines?
adam commented 2025-12-29 19:29:46 +01:00
Author
Owner
Copy Link

@rfdrake commented on GitHub (Nov 3, 2021):

My "solution" for this was to use permissions to make it so that users couldn't delete prefixes. Then tell everyone to mark them as deprecated. After xx time another process would run which reclaimed the addresses.

For the cleanup script you might do something like this:

curl https://netboxurl/api/ipam/prefixes/?status=deprecated

look at the JSON output and filter on last_updated > 10 days.

It might even be possible to write the script in such a way that it gets added to your local netbox housekeeping process and is run automatically.

@rfdrake commented on GitHub (Nov 3, 2021): My "solution" for this was to use permissions to make it so that users couldn't delete prefixes. Then tell everyone to mark them as deprecated. After xx time another process would run which reclaimed the addresses. For the cleanup script you might do something like this: curl https://netboxurl/api/ipam/prefixes/?status=deprecated look at the JSON output and filter on last_updated > 10 days. It might even be possible to write the script in such a way that it gets added to your local netbox housekeeping process and is run automatically.
adam commented 2025-12-29 19:29:47 +01:00
Author
Owner
Copy Link

@YWatchman commented on GitHub (Nov 4, 2021):

It's not about user permission, my FttH customers do not access Netbox. It's a routine check for IPs that should be set back to the pool, thus removing IPs which have the specified status and cool end date (in a customfield) after x months.

@YWatchman commented on GitHub (Nov 4, 2021): It's not about user permission, my FttH customers do not access Netbox. It's a routine check for IPs that should be set back to the pool, thus removing IPs which have the specified status and cool end date (in a customfield) after x months.
adam commented 2025-12-29 19:29:47 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 11, 2021):

This way customer gets 2 IPs and the 'new' assigned which gets state 'Active' will be destroyed or 'cooled' and the 'reserved' address will be moved to the new 'tenant' which in our case is an internet subscription.

I'm sorry but it sounds like you're trying to encode too much information into the status field. A reserved IP is simply one which is not available for use elsewhere, which fits the definition of your "cooldown" role. I would suggest using the reserved status and adding a tag or custom field to attach other relevant information as needed (for example, the date at which an IP will become available), since it sounds like this is needed anyway.

@jeremystretch commented on GitHub (Nov 11, 2021): > This way customer gets 2 IPs and the 'new' assigned which gets state 'Active' will be destroyed or 'cooled' and the 'reserved' address will be moved to the new 'tenant' which in our case is an internet subscription. I'm sorry but it sounds like you're trying to encode too much information into the status field. A reserved IP is simply one which is not available for use elsewhere, which fits the definition of your "cooldown" role. I would suggest using the reserved status and adding a tag or custom field to attach other relevant information as needed (for example, the date at which an IP will become available), since it sounds like this is needed anyway.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#5583
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?