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

Move logging from BaseScript into JobRunner #10144

New Issue
Closed
opened 2025-12-29 21:27:28 +01:00 by adam · 9 comments
adam commented 2025-12-29 21:27:28 +01:00
Owner
Copy Link

Originally created by @alehaa on GitHub (Aug 27, 2024).

NetBox version

v4.1-beta1

Feature type

Change to existing functionality

Proposed functionality

  • Move the logging methods (i.e. self.log_info()) from extras.scripts.BaseScript into netbox.jobs.JobRunner.
  • Move job log views from script to general job details.

Use case

With the JobRunner framework, plugins have the ability to define jobs in a standard way. However, communication to the user is still limited to free-form data and exception logging. Adding logging to general jobs would allow plugins to provide additional information about what's been done during job execution.

Database changes

None

External dependencies

None.

If accepted, this could make #15983 obsolete. As all jobs would have logs, no dedicated link to script logs is required anymore.

Originally created by @alehaa on GitHub (Aug 27, 2024). ### NetBox version v4.1-beta1 ### Feature type Change to existing functionality ### Proposed functionality * Move the logging methods (i.e. `self.log_info()`) from `extras.scripts.BaseScript` into `netbox.jobs.JobRunner`. * Move job log views from script to general job details. ### Use case With the `JobRunner` framework, plugins have the ability to define jobs in a standard way. However, communication to the user is still limited to free-form data and exception logging. Adding logging to general jobs would allow plugins to provide additional information about what's been done during job execution. ### Database changes None ### External dependencies None. If accepted, this could make #15983 obsolete. As all jobs would have logs, no dedicated link to script logs is required anymore.
adam closed this issue 2025-12-29 21:27:28 +01:00
adam commented 2025-12-29 21:27:29 +01:00
Author
Owner
Copy Link

@alehaa commented on GitHub (Sep 25, 2024):

I volunteer to work on this myself.

@alehaa commented on GitHub (Sep 25, 2024): I volunteer to work on this myself.
adam commented 2025-12-29 21:27:29 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 25, 2024):

I'm not sure I understand the intent here. Logging methods like log_info() are intended to be called by the script itself within its run() method to log output from its operations. @alehaa could you elaborate a bit on the specific change(s) being proposed?

@jeremystretch commented on GitHub (Sep 25, 2024): I'm not sure I understand the intent here. Logging methods like `log_info()` are intended to be called by the script itself within its `run()` method to log output from its operations. @alehaa could you elaborate a bit on the specific change(s) being proposed?
adam commented 2025-12-29 21:27:30 +01:00
Author
Owner
Copy Link

@alehaa commented on GitHub (Sep 25, 2024):

My intention when introducing the JobRunner framework was to provide a standard way to handle jobs. Previously there were some different implementations in NetBox and also some plugins. With NetBox v4.1 it is now possible to access this standard interface and e.g. show which background jobs are running along with other jobs like scripts or data source syncs.

With this FR I'd like to introduce the next evolution of the framework and give it the ability to communicate information to users and administrators in a standard way. Currently, scripts, the blueprint of the JobRunner framework, have a standardized way to communicate messages using logging methods. Now I'd like to make logging available to the JobRunner class as well. This would allow background jobs and housekeeping tasks to document what they've done, e.g. which VMs were synchronized or skipped, just like scripts do.

To avoid reinventing the wheel, I suggest moving the existing methods from the BaseScript class to JobRunner or a common base class (to be introduced). The JobRunner class has been designed to keep extensions like this in mind, so one would call log_info() from run() like in scripts. The UI log views also need to be moved from scripts to jobs.

@alehaa commented on GitHub (Sep 25, 2024): My intention when introducing the `JobRunner` framework was to provide a standard way to handle jobs. Previously there were some different implementations in NetBox and also some plugins. With NetBox v4.1 it is now possible to access this standard interface and e.g. show which background jobs are running along with other jobs like scripts or data source syncs. With this FR I'd like to introduce the next evolution of the framework and give it the ability to communicate information to users and administrators in a standard way. Currently, scripts, the blueprint of the `JobRunner` framework, have a standardized way to communicate messages using logging methods. Now I'd like to make logging available to the `JobRunner` class as well. This would allow background jobs and housekeeping tasks to document what they've done, e.g. which VMs were synchronized or skipped, just like scripts do. To avoid reinventing the wheel, I suggest moving the existing methods from the `BaseScript` class to `JobRunner` or a common base class (to be introduced). The `JobRunner` class has been designed to keep extensions like this in mind, so one would call `log_info()` from `run()` like in scripts. The UI log views also need to be moved from scripts to jobs.
adam commented 2025-12-29 21:27:30 +01:00
Author
Owner
Copy Link

@alehaa commented on GitHub (Oct 8, 2024):

@jeremystretch do you need some additional information? It's unclear to me whether this issue is in the state needs owner or revisions needed.

@alehaa commented on GitHub (Oct 8, 2024): @jeremystretch do you need some additional information? It's unclear to me whether this issue is in the state `needs owner` or `revisions needed`.
adam commented 2025-12-29 21:27:30 +01:00
Author
Owner
Copy Link

@alehaa commented on GitHub (Nov 22, 2024):

I am still happy to work on this feature. Since there won't be any model changes, there shouldn't be any significant changes to the existing functionality, just making it available to other NetBox internal and external code.

@alehaa commented on GitHub (Nov 22, 2024): I am still happy to work on this feature. Since there won't be any model changes, there shouldn't be any significant changes to the existing functionality, just making it available to other NetBox internal and external code.
adam commented 2025-12-29 21:27:31 +01:00
Author
Owner
Copy Link

@fdietzsch commented on GitHub (Jan 8, 2025):

I'd love to see this feature. I am currently using a @system_job, a feature of the recent NetBox 4.2 release. Currently I don't know how to communicate details about the job execution to the user. For example I'd like to see on which device objects the current execution operates.

Any current workaround is highligh appreciated.

This is my current system_job

@system_job(interval=JobIntervalChoices.INTERVAL_MINUTELY)
class EnsureMaintenanceStatusJob(JobRunner):
    class Meta:
        name = "Check device status"
        description = "Set 'Maintenance' status for Devices if current time is within the maintenance window."


    def run(self, *args, **kwargs):
        now = timezone.now()

        # obtained via Django field lookups, e.g. https://docs.djangoproject.com/en/3.2/ref/models/querysets/#gte
        active_mw = DeviceMaintenance.objects.filter(start_time__lte=now, end_time__gte=now)
        devices_in_maintenance = active_mw.values_list('device_id', flat=True)


        # !!! This is the highly appreciated part, e.g.
        # self.log_info("Number of devices in maintenance: ", len(active_mw))
        # !!! 

        # filter for all devices that have a maintenance window and set their status accordingly
        Device.objects.filter(pk__in=devices_in_maintenance).update(status='maintenance')

        # search all devices that have maintenance status but are no longer within a maintenance window
        revert_qs = Device.objects.filter(status='maintenance').exclude(pk__in=devices_in_maintenance)
        revert_qs.update(status='staged')
@fdietzsch commented on GitHub (Jan 8, 2025): I'd love to see this feature. I am currently using a `@system_job`, a feature of the recent NetBox 4.2 release. Currently I don't know how to communicate details about the job execution to the user. For example I'd like to see on which device objects the current execution operates. Any current workaround is highligh appreciated. This is my current `system_job` ```python @system_job(interval=JobIntervalChoices.INTERVAL_MINUTELY) class EnsureMaintenanceStatusJob(JobRunner): class Meta: name = "Check device status" description = "Set 'Maintenance' status for Devices if current time is within the maintenance window." def run(self, *args, **kwargs): now = timezone.now() # obtained via Django field lookups, e.g. https://docs.djangoproject.com/en/3.2/ref/models/querysets/#gte active_mw = DeviceMaintenance.objects.filter(start_time__lte=now, end_time__gte=now) devices_in_maintenance = active_mw.values_list('device_id', flat=True) # !!! This is the highly appreciated part, e.g. # self.log_info("Number of devices in maintenance: ", len(active_mw)) # !!! # filter for all devices that have a maintenance window and set their status accordingly Device.objects.filter(pk__in=devices_in_maintenance).update(status='maintenance') # search all devices that have maintenance status but are no longer within a maintenance window revert_qs = Device.objects.filter(status='maintenance').exclude(pk__in=devices_in_maintenance) revert_qs.update(status='staged') ```
adam commented 2025-12-29 21:27:31 +01:00
Author
Owner
Copy Link

@alehaa commented on GitHub (Feb 26, 2025):

@jeremystretch I think this issue is stuck. Can you give any advice on how to proceed? I'm happy to provide a PR for this on the feature branch for the upcoming 4.3 release.

@alehaa commented on GitHub (Feb 26, 2025): @jeremystretch I think this issue is stuck. Can you give any advice on how to proceed? I'm happy to provide a PR for this on the `feature` branch for the upcoming 4.3 release.
adam commented 2025-12-29 21:27:31 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (May 28, 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 (May 28, 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:32 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jun 27, 2025):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Jun 27, 2025): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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 complexity: low netbox pending closure status: needs owner 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#10144
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?