netbox-community / netbox

The premier source of truth powering network automation. Open source under Apache 2. Public demo: https://demo.netbox.dev
http://netboxlabs.com/oss/netbox/
Apache License 2.0
15.68k stars 2.53k forks source link

Additional Features for Staged Changes #11138

Open minitriga opened 1 year ago

minitriga commented 1 year ago

NetBox version

v3.4

Feature type

Change to existing functionality

Proposed functionality

Below are some proposed changes to the Staged Changes functionality in Netbox 3.4 beta. Referencing #10851

Use case

This would assist plugin developers when making synchronisation plugins.

Database changes

Status Column on Branch Model

External dependencies

No response

jeremystretch commented 1 year ago

When a branch changed has been merged the staged changed are deleted, I would like to be able to see that they are now applied_changes

We could retain the StagedChange instances, but would need some way to flag that each has been applied and prevent it from being re-applied.

I would like to propose the idea of a Branch status.

This seems to conflict with the first item. If we allow a branch to retain both applied and non-applied changes, the branch itself cannot have an atomic status. Or is the intent to only permit one type of change or the other? (If so, this would preclude a branch from being reused for successive merges.)

I would like the ability to not show a model has been updated if only the last_updated column has been altered.

Can you give an example of a change that causes this? Is it specifically related to staged changes, or just change logging in general?

minitriga commented 1 year ago

My issue is not with change logging but a StagedChange being created when only "last_updated" field has been updated. If the data is the same before and after only the "last_updated" field is changed causing a branch to show a change that is only updating that field causing false positives to show in the branch. Here is an example change that is trying to update an existing record:

If you run this within NB shell and then merge the branch you will have one new device. However if you run it again you will have a staged change with no changed fields except "last_updated".

from django.utils.text import slugify
from dcim.choices import DeviceStatusChoices
from extras.models import Branch
from netbox.staging import checkout
from datetime import datetime

device = {'configReg': None,
          'devType': 'fw',
          'domain': None,
          'family': 'asa',
          'fqdn': None,
          'hostname': 'L68ASAV5',
          'hostnameOriginal': None,
          'hostnameProcessed': None,
          'icon': None,
          'id': '36699432',
          'image': 'boot:/asa992-32-smp-k8.bin',
          'loginIp': '10.68.200.5',
          'loginType': 'ssh',
          'mac': '0200.6300.0524',
          'memoryTotalBytes': 2147483648,
          'memoryUsedBytes': 2147483648,
          'memoryUtilization': 100,
          'model': 'ASAv10',
          'objectId': None,
          'platform': 'asav',
          'processor': 'Pentium II 3333 MHz',
          'rd': None,
          'reload': None,
          'siteName': '68 Pardubice Distribution',
          'sn': '9AKRD59RU24',
          'snHw': '9AKRD59RU24',
          'stpDomain': None,
          'taskKey': '8cc1fd95-d3ed-4936-83b1-8b63d43c3dd9',
          'uptime': 8308800,
          'vendor': 'cisco',
          'version': '9.9(2)32'
          }

current_time = str(datetime.now())
branch = Branch.objects.create(name=f'{current_time}')
with checkout(branch):
    device_role, _ = DeviceRole.objects.get_or_create(
        name="Network Device", slug=slugify("Network Device"))
    site = Site.objects.filter(name=device['siteName'])[0]
    device_type = DeviceType.objects.filter(model=device['model'])[0]
    defaults = {
        "name": device['hostname'],
        "status": DeviceStatusChoices.STATUS_ACTIVE,
        'serial': device['sn'],
        'site': site,
        'device_type': device_type,
        'device_role': device_role
    }
    device_object, _ = Device.objects.update_or_create(serial=device['sn'], defaults=defaults)

In regards to the other points. I like the idea of keeping the StagedChange instances to see what has been applied maybe a status on that model (Boolean or Status Field). I have been using a Branch Instance for each set of changes. Once I have merged a branch I do not intend to go back and reuse the same branch for future staged changes but I guess the branch could be reused.

jeremystretch commented 1 year ago

There's probably more to discuss here, and we'll likely break out some of the work to separate issues, but I've tagged this as needs milestone to ensure it remains a focus for future releases.

bkampsnl commented 1 year ago

I see this feature has the following use case :

This would assist plugin developers when making synchronisation plugins.

I am wondering : will it also be an idea to integrate this into the rest api / ui so that users can create branches in the web ui ?

So a user can make changes in netbox without directly saving them in the database but keeping the changes in a branch ? When the user is done he can verify if the changes can be committed to the database and then commit the changes.

I though I read in another issue that my desccribed use case is the final goal but the feature is broken down into smaller iterations. If so, I am wondering when will the rest api / web-ui part be developed ? Are there already ideas on how to implement this ?

I am really pleased with netbox, I think it's a great full feature application ! Respect to the very active developers ! I want to introduce it into my organisation and the branching / staging feature within the web-ui would make netbox even more great :)

I am a developer myself so if there are ideas on how to implement this in rest-api / web-ui maybe I can give a hand.

jadyndev commented 5 months ago

I see this feature has the following use case :

This would assist plugin developers when making synchronisation plugins.

I am wondering : will it also be an idea to integrate this into the rest api / ui so that users can create branches in the web ui ?

So a user can make changes in netbox without directly saving them in the database but keeping the changes in a branch ? When the user is done he can verify if the changes can be committed to the database and then commit the changes.

I though I read in another issue that my desccribed use case is the final goal but the feature is broken down into smaller iterations. If so, I am wondering when will the rest api / web-ui part be developed ? Are there already ideas on how to implement this ?

I am really pleased with netbox, I think it's a great full feature application ! Respect to the very active developers ! I want to introduce it into my organisation and the branching / staging feature within the web-ui would make netbox even more great :)

I am a developer myself so if there are ideas on how to implement this in rest-api / web-ui maybe I can give a hand.

From an OPs perspective it would be awesome to allow (external) workers to make changes within a branch (which could be auto-created for convenience) and let them submit their changes to an Admin/Reviewer for approval.

I'd suggest these changes to the permissions:

Maybe add a dropdown menu to switch between branches similar to GitHub?

JoeIzzard commented 2 months ago

It would also be beneficial for our use case to be able to restrict who can see change branches. We have a lot of technicians that access Netbox to only see the current version and aren't interested in future projects.

A dropdown to change branches could then be hidden from users that don't have permission to view change branches. I do like the idea of a dropdown, maybe at the top of the sidebar under the Logo so it's easy to see your in a change context?

Mockup for context: netbox-change-branch-dropdown