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

revamp data model for "services", and "service templates" #10110

New Issue
Closed
opened 2025-12-29 21:26:58 +01:00 by adam · 7 comments
adam commented 2025-12-29 21:26:58 +01:00
Owner
Copy Link

Originally created by @ghost on GitHub (Aug 16, 2024).

NetBox version

v.4.0.8

Feature type

Data model extension

Proposed functionality

I'm going to close my existing FR https://github.com/netbox-community/netbox/issues/16841 to create a new FR with more detail and a bit more expanded scope. I want to flesh out the concept here and hopefully there are enough people that see value in this. There is quite a bit of work contained within this single FR, so if devs want this broken out into smaller chunks, let me know.

The overall proposal consists of a few key items.

  1. rename "service templates" model to "service groups"
  2. rename "services" to "service assignments"
  3. create NEW model called "services"
  4. allow the ability for services to be placed into one or more service groups
  5. allow the ability to assign both services and/or service groups to dcim.devices and virtualization.virtualmachine object types
  6. move "services" and the newly renamed "Service Groups" out of "IPAM -> other" and into a new root dropdown called "Services". (applications/services don't really have much to do with IPAM so it makes sense to move them into their own category)

Here are some mockups of the changes in action
image

image

EDIT: one final note, when assigning services to objects, the object should reference the service object and not instantiate a new service per object.
For example, the service would work just like a contact. If I assign a service to an object and then edit the service (for example I change the port from 22 to 21) then that service should change for every object its assigned to.

Use case

Item 1) rename "service templates" model to "service groups"
This calls for a database change for the rename of the model. Service groups will function exactly like other existing groups (ex: site groups, tenant groups, contact groups, cluster groups, etc.) Right now, in other areas of netbox, 'templates' work a very specific way. The existing 'service templates' works more like 'groups' work for other object types. this would make the naming more consistent.

Item 2) rename "services" to "service assignments"
This is another area where it would make sense to rename the existing functionality of 'services' to 'service assignments'. Currently, when you click on services it is showing you what services are currently associated with parent objects. This functionality is what 'assignments' is for other areas of netbox. "contact assignments' is an example of this concept.

Item 3) allow the ability for services to be placed into one or more service groups
let's suppose you create a service for TCP/80 (http). You could create a new service group called "Salesforce" and place the tcp/80 (http) service into that group. You might also create another service group called "Lansweeper". Lansweeper also hosts a web frontend so you could put the existing service tcp/80 (http) into the lansweeper service group as well.
You would now have the ability to create multiple services and put them into respective groups to build what is in effect an "application" that comprises multiple ports, multiple protocols.

Item 4) create NEW model called "services"
Create a new data model that is individual services. Much like what the existing 'service templates' is. A list of all individual services available in NetBox. these services can be assigned individually to an object, but can also be associated with a service group.
To easily wrap your head around this item, think of the contacts object model.
Right now, 'services' works more like 'contact assignments' does today
Right now, 'service templates' works more like 'contact groups' does today
there is no existing method to capture individual services like there is for 'contacts'

item 5) allow the ability to assign both services and/or service groups to dcim.devices and virtualization.virtualmachine object types
Currently you can only assign services to these object types. After a data model extension these object types would need to support having either a single or multiple individual services assigned to them, but extended to be able to assign a single or multiple service groups as well.

item 6) move "service", the newly created "Service Groups", and the renamed 'Service assignments' out of IPAM -> other and into a new root dropdown called "Services"
This follows the same logic as an upcoming change to move the racks, rack roles, elevations, etc. out of "Organization" and into its own category (https://github.com/netbox-community/netbox/issues/16988). Services don't really fit into the IPAM section. Creating the model 'service groups' and giving services some revamp love like what is mentioned in this FR allows "Services" to be a front and center killer feature of NetBox that would deserve its own category.

Database changes

rename data model "service templates" to "service groups"
rename data model "services" to "service assignments"
create new data model "services" that is strictly a list of all available individual services available to be assigned to objects or service groups.
alter dcim.device and virtualization.virtualmachine to accept new service group model (multiple groups assigned)

External dependencies

none.

Originally created by @ghost on GitHub (Aug 16, 2024). ### NetBox version v.4.0.8 ### Feature type Data model extension ### Proposed functionality I'm going to close my existing FR https://github.com/netbox-community/netbox/issues/16841 to create a new FR with more detail and a bit more expanded scope. I want to flesh out the concept here and hopefully there are enough people that see value in this. There is quite a bit of work contained within this single FR, so if devs want this broken out into smaller chunks, let me know. The overall proposal consists of a few key items. 1) rename "service templates" model to "service groups" 2) rename "services" to "service assignments" 3) create NEW model called "services" 4) allow the ability for services to be placed into one or more service groups 5) allow the ability to assign both services and/or service groups to dcim.devices and virtualization.virtualmachine object types 6) move "services" and the newly renamed "Service Groups" out of "IPAM -> other" and into a new root dropdown called "Services". (applications/services don't really have much to do with IPAM so it makes sense to move them into their own category) Here are some mockups of the changes in action ![image](https://github.com/user-attachments/assets/3c0365f1-e4ce-4715-a96f-a58a2e43c9d3) ![image](https://github.com/user-attachments/assets/36f3de7d-ebbf-4f4e-8d6e-25e92ba967bb) EDIT: one final note, when assigning services to objects, the object should reference the service object and not instantiate a new service per object. For example, the service would work just like a contact. If I assign a service to an object and then edit the service (for example I change the port from 22 to 21) then that service should change for every object its assigned to. ### Use case Item 1) rename "service templates" model to "service groups" This calls for a database change for the rename of the model. Service groups will function exactly like other existing groups (ex: site groups, tenant groups, contact groups, cluster groups, etc.) Right now, in other areas of netbox, 'templates' work a very specific way. The existing 'service templates' works more like 'groups' work for other object types. this would make the naming more consistent. Item 2) rename "services" to "service assignments" This is another area where it would make sense to rename the existing functionality of 'services' to 'service assignments'. Currently, when you click on services it is showing you what services are currently associated with parent objects. This functionality is what 'assignments' is for other areas of netbox. "contact assignments' is an example of this concept. Item 3) allow the ability for services to be placed into one or more service groups let's suppose you create a service for TCP/80 (http). You could create a new service group called "Salesforce" and place the tcp/80 (http) service into that group. You might also create another service group called "Lansweeper". Lansweeper also hosts a web frontend so you could put the existing service tcp/80 (http) into the lansweeper service group as well. You would now have the ability to create multiple services and put them into respective groups to build what is in effect an "application" that comprises multiple ports, multiple protocols. Item 4) create NEW model called "services" Create a new data model that is individual services. Much like what the existing 'service templates' is. A list of all individual services available in NetBox. these services can be assigned individually to an object, but can also be associated with a service group. To easily wrap your head around this item, think of the contacts object model. Right now, 'services' works more like 'contact assignments' does today Right now, 'service templates' works more like 'contact groups' does today there is no existing method to capture individual services like there is for 'contacts' item 5) allow the ability to assign both services and/or service groups to dcim.devices and virtualization.virtualmachine object types Currently you can only assign services to these object types. After a data model extension these object types would need to support having either a single or multiple individual services assigned to them, but extended to be able to assign a single or multiple service groups as well. item 6) move "service", the newly created "Service Groups", and the renamed 'Service assignments' out of IPAM -> other and into a new root dropdown called "Services" This follows the same logic as an upcoming change to move the racks, rack roles, elevations, etc. out of "Organization" and into its own category (https://github.com/netbox-community/netbox/issues/16988). Services don't really fit into the IPAM section. Creating the model 'service groups' and giving services some revamp love like what is mentioned in this FR allows "Services" to be a front and center killer feature of NetBox that would deserve its own category. ### Database changes rename data model "service templates" to "service groups" rename data model "services" to "service assignments" create new data model "services" that is strictly a list of all available individual services available to be assigned to objects or service groups. alter dcim.device and virtualization.virtualmachine to accept new service group model (multiple groups assigned) ### External dependencies none.
adam added the type: featurenetbox labels 2025-12-29 21:26:58 +01:00
adam closed this issue 2025-12-29 21:26:58 +01:00
adam commented 2025-12-29 21:26:58 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Sep 20, 2024):

Any advice? It has been over a month and this FR hasn't been triaged. Is triage not done first in first out?

@ghost commented on GitHub (Sep 20, 2024): Any advice? It has been over a month and this FR hasn't been triaged. Is triage not done first in first out?
adam commented 2025-12-29 21:26:59 +01:00
Author
Owner
Copy Link

@jsenecal commented on GitHub (Sep 23, 2024):

I would also suggest that the term Services may as well be renamed on its own, as it currently conveys a too broad meaning. IP Services or Network Services comes to mind. Services, when used in a business term mean something else. I're resorted to "Contracted Services" in my plugins, but Services remains present in multiple views and confuses the users.

Just my 0.02$ :)

@jsenecal commented on GitHub (Sep 23, 2024): I would also suggest that the term `Services` may as well be renamed on its own, as it currently conveys a too broad meaning. `IP Services` or `Network Services` comes to mind. `Services`, when used in a business term mean something else. I're resorted to "Contracted Services" in my plugins, but `Services` remains present in multiple views and confuses the users. Just my 0.02$ :)
adam commented 2025-12-29 21:26:59 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Sep 23, 2024):

I would also suggest that the term Services may as well be renamed on its own, as it currently conveys a too broad meaning. IP Services or Network Services comes to mind. Services, when used in a business term mean something else. I're resorted to "Contracted Services" in my plugins, but Services remains present in multiple views and confuses the users.

Just my 0.02$ :)

If it were me, I'd rename the entire model to Applications. But I think Services is general enough that it can mean whatever you want it to mean.

@ghost commented on GitHub (Sep 23, 2024): > I would also suggest that the term `Services` may as well be renamed on its own, as it currently conveys a too broad meaning. `IP Services` or `Network Services` comes to mind. `Services`, when used in a business term mean something else. I're resorted to "Contracted Services" in my plugins, but `Services` remains present in multiple views and confuses the users. > > Just my 0.02$ :) If it were me, I'd rename the entire model to `Applications`. But I think `Services` is general enough that it can mean whatever you want it to mean.
adam commented 2025-12-29 21:27:00 +01:00
Author
Owner
Copy Link

@ross-cello commented on GitHub (Oct 14, 2024):

We have a huge interest in modelling network services due to one-to-many relationships with various other NB models and assurance identification requirements.

This seems very close to the modelling I envisioned.

Could you conceive of Item 5 associating with more than just Device/VM?

Our use case would be gluing services to a varying combination of Tenant+Site+Device+Circuit.
For us these services are often overlays like L3VPN, L2VPN or Internet configurables.
Generally itemised for categorisation/billing.

@ross-cello commented on GitHub (Oct 14, 2024): We have a huge interest in modelling network services due to one-to-many relationships with various other NB models and assurance identification requirements. This seems very close to the modelling I envisioned. Could you conceive of Item 5 associating with more than just Device/VM? Our use case would be gluing services to a varying combination of Tenant+Site+Device+Circuit. For us these services are often overlays like L3VPN, L2VPN or Internet configurables. Generally itemised for categorisation/billing.
adam commented 2025-12-29 21:27:00 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 10, 2025):

The overall use case for this proposal is unclear. This probably needs to be split into multiple FRs.

@jeremystretch commented on GitHub (Jan 10, 2025): The overall use case for this proposal is unclear. This probably needs to be split into multiple FRs.
adam commented 2025-12-29 21:27:00 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Apr 25, 2025):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Apr 25, 2025): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/main/CONTRIBUTING.md).
adam commented 2025-12-29 21:27:01 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 25, 2025):

Closing this out as no further discussion has taken place, and the FR in its current form is not tenable.

@jeremystretch commented on GitHub (Apr 25, 2025): Closing this out as no further discussion has taken place, and the FR in its current form is not tenable.
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 netbox 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#10110
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?