carverauto/serviceradar

Fork

You've already forked serviceradar

Code Issues 190 Pull requests 16 Projects Releases 173 Packages Wiki Activity Actions

feat: 2-way integration support #726

New issue

Open

opened 2026-03-28 04:27:52 +00:00 by mfreeman451 · 0 comments

mfreeman451 commented

2026-03-28 04:27:52 +00:00

Owner

Copy link

Imported from GitHub.

Original GitHub issue: #2261
Original author: @mfreeman451
Original URL: https://github.com/carverauto/serviceradar/issues/2261
Original created: 2026-01-12T02:37:36Z

Is your feature request related to a problem?

We need to create the ability to setup 2-way integrations with things like Armis or NetBox. We've already built the 2-way integration with Armis, not sure if that code was cleaned up/removed or not, but the armis updater stuff would be a good place to start.

The 2-way integration should be configurable and an option not a requirement, through the UI under Integration Sources.

UI for setting up 2-way integration when adding Armis or NetBox integration
UI for editing exiting integration settings and adding/removing 2-way integration
Option for 2-way integration to be dependent on preconditions, such as a SweepResult event
2-way integration settings should allow user to configure the scope of devices that are going to be part of the upstream interaction, where we push data to Armis or NetBox
Need to use existing UI query builder
The scope should be using SRQL, ie the user basically defines an SRQL search and those results get pushed up to Armis
User needs to be able to select what they're sending to Armis and where it comes from out of ServiceRadar, for the first pass we are just looking at the is_available field, and then updating a custom tag in Armis
We only need to have support for updating custom tags in Armis for now
Need to call out to the serviceradar-agent to actually talk to Armis
serviceradar-agent needs to be updated to ask agent-gateway->core-elx for new config (already supported), this new config would include the instructions for the updater.
Use Ash State machine and GRPC updates received from the Agent to track progress of 2-way integration update jobs

it looks like we've got a lot of the armis_updater.go code still in the pkg/sync library (serviceradar-sync used to be standalone, has been merged into serviceradar-agent, but in the process we lost a lot of the wiring around the functionality, and a lot of it was json config driven (or could be read from KV). We're now making the agent get its config from the core via the agent-gateway, so if the updater is enabled for an integration, we need to generate a good config for that thing, so when the agent requests its config, it picks up the integration updater config/job. We might need to do some work in the serviceradar-agent because we dont really want to be running the integration updater on some interval, we want it to be event-based, which might make this a bit more difficult/convoluted. Maybe we need a new GRPC method to do some of this instead of just trying to always push configs that sort of get turned into jobs, maybe we need to push down config and jobs and be able to push down dynamic jobs. I don't want to overload the core with thousands of agents potentially all asking for jobs way too frequently either..

github.com/carverauto/serviceradar@d5d1015a64/pkg/sync/integrations/armis/armis_updater.go (L4)

Describe the solution you'd like

A clear and concise description of what you want to happen.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

Imported from GitHub. Original GitHub issue: #2261 Original author: @mfreeman451 Original URL: https://github.com/carverauto/serviceradar/issues/2261 Original created: 2026-01-12T02:37:36Z --- **Is your feature request related to a problem?** We need to create the ability to setup 2-way integrations with things like Armis or NetBox. We've already built the 2-way integration with Armis, not sure if that code was cleaned up/removed or not, but the armis updater stuff would be a good place to start. The 2-way integration should be configurable and an option not a requirement, through the UI under Integration Sources. - [ ] UI for setting up 2-way integration when adding Armis or NetBox integration - [ ] UI for editing exiting integration settings and adding/removing 2-way integration - [ ] Option for 2-way integration to be dependent on preconditions, such as a SweepResult event - [ ] 2-way integration settings should allow user to configure the scope of devices that are going to be part of the upstream interaction, where we push data to Armis or NetBox - [ ] Need to use existing UI query builder - [ ] The scope should be using SRQL, ie the user basically defines an SRQL search and those results get pushed up to Armis - [ ] User needs to be able to select what they're sending to Armis and where it comes from out of ServiceRadar, for the first pass we are just looking at the is_available field, and then updating a custom tag in Armis - [ ] We only need to have support for updating custom tags in Armis for now - [ ] Need to call out to the serviceradar-agent to actually talk to Armis - [ ] serviceradar-agent needs to be updated to ask agent-gateway->core-elx for new config (already supported), this new config would include the instructions for the updater. - [ ] Use Ash State machine and GRPC updates received from the Agent to track progress of 2-way integration update jobs it looks like we've got a lot of the armis_updater.go code still in the pkg/sync library (serviceradar-sync used to be standalone, has been merged into serviceradar-agent, but in the process we lost a lot of the wiring around the functionality, and a lot of it was json config driven (or could be read from KV). We're now making the agent get its config from the core via the agent-gateway, so if the updater is enabled for an integration, we need to generate a good config for that thing, so when the agent requests its config, it picks up the integration updater config/job. We might need to do some work in the serviceradar-agent because we dont really want to be running the integration updater on some interval, we want it to be event-based, which might make this a bit more difficult/convoluted. Maybe we need a new GRPC method to do some of this instead of just trying to always push configs that sort of get turned into jobs, maybe we need to push down config and jobs and be able to push down dynamic jobs. I don't want to overload the core with thousands of agents potentially all asking for jobs way too frequently either.. https://github.com/carverauto/serviceradar/blob/d5d1015a64fcf81a0fe6d59909f2f8c14e78f860/pkg/sync/integrations/armis/armis_updater.go#L4 **Describe the solution you'd like** A clear and concise description of what you want to happen. **Describe alternatives you've considered** A clear and concise description of any alternative solutions or features you've considered. **Additional context** Add any other context or screenshots about the feature request here.

mfreeman451 added this to the 1.1.1 milestone

2026-03-28 04:27:52 +00:00

No Branch/Tag specified

staging

2406-feat-agent-fleet-management-secure-self-update-system

bug/k8s-helm-deployments

chore/k8s-arc-update

rust-fix

2371-analytics-stats-cards-should-abbreviate-numbers

chore/perl-cleanup

2942-featweb-ng-add-logs-tab-to-device-details-page

192-feat-tftp-server

mikemiles-dev/feature/netflow_collection

testing

dependabot/cargo/hostname-0.4.1

dependabot/cargo/redis-1.0.1

dependabot/cargo/bb8-0.9.0

dependabot/cargo/rcgen-0.14.6

dependabot/cargo/hyper-1.8.1

dependabot/cargo/hyper-util-0.1.19

dependabot/cargo/clap-4.5.51

dependabot/cargo/thiserror-2.0.17

dependabot/cargo/time-tz-2.0.0

dependabot/cargo/tonic-build-0.14.2

main

dependabot/npm_and_yarn/docs/mdast-util-to-hast-13.2.1

815-feat-support-win32-for-agentpoller

gh-pages

v1.2.5

v1.2.4

v1.2.3

v1.2.2

v1.2.1

v1.2.0

v1.1.2

v1.1.0

v1.0.92

v1.0.91

v1.0.90

v1.0.89

v1.0.88

v1.0.87

v1.0.86

v1.0.85

v1.0.84

v1.0.83

v1.0.82

v1.0.81

v1.0.78

v1.0.77

v1.0.76

v1.0.70

v1.0.69

v1.0.68

v1.0.67

v1.0.66

v1.0.65

v1.0.64

v1.0.63

v1.0.62

v1.0.61

v1.0.60

v1.0.59

v1.0.58

1.0.57

v1.0.56

v1.0.55

v1.0.54-pre5

v1.0.53

v1.0.53-pre19

v1.0.53-pre18

v1.0.53-pre17

v1.0.53-pre15

1.0.53-pre10

1.0.53-pre9

1.0.53-pre8

1.0.53-pre7

1.0.53-pre6

1.0.53-pre5

1.0.53-pre4

1.0.53-pre3

1.0.53-pre2

1.0.53-pre1

1.0.52

1.0.51

1.0.50

1.0.49

1.0.49-pre5

1.0.49-pre4

1.0.49-pre3

1.0.49-pre2

1.0.48

1.0.48-rc2

1.0.48-rc1

1.0.48-pre8

1.0.48-pre7

1.0.48-pre6

1.0.48-pre5

1.0.48-pre4

1.0.48-pre3

1.0.48-pre2

1.0.48-pre1

1.0.47

1.0.47-pre8

1.0.47-pre7

1.0.47-pre6

1.0.47-pre5

1.0.47-pre4

1.0.47-pre3

1.0.47-pre2

1.0.47-pre1

1.0.46

1.0.46-pre9

1.0.46-pre8

1.0.46-pre7

1.0.46-pre6

1.0.46-pre5

1.0.46-pre4

1.0.46-pre3

1.0.46-pre2

1.0.46-pre1

1.0.45

1.0.44

1.0.44-pre12

1.0.44-pre11

1.0.44-pre10

1.0.44-pre9

1.0.44-pre8

1.0.44-pre7

1.0.44-pre6

1.0.44-pre5

1.0.44-pre4

1.0.44-pre3

1.0.44-pre2

1.0.44-pre1

1.0.43

1.0.42

1.0.41

1.0.41-pre1

1.0.40

1.0.40-pre11

1.0.40-pre10

1.0.40-pre9

1.0.40-pre8

1.0.40-pre7

1.0.40-pre6

1.0.40-pre5

1.0.40-pre4

1.0.40-pre3

1.0.40-pre2

1.0.40-pre1

1.0.39

1.0.38

1.0.37

1.0.36

1.0.36-pre5

1.0.36-pre4

1.0.36-pre3

1.0.36-pre2

1.0.35

1.0.35-pre3

1.0.35-pre2

1.0.35-pre

1.0.34-pre3

1.0.34-pre2

1.0.34-pre1

1.0.33

1.0.33-pre2

1.0.33-pre

1.0.32

1.0.31

1.0.30

1.0.29

1.0.28

1.0.27

1.0.26

1.0.25

1.0.24

1.0.23

1.0.22

1.0.21

1.0.20

1.0.19

1.0.18

1.0.17

1.0.16

1.0.15

1.0.14

1.0.13

1.0.11

1.0.10

1.0.9

1.0.8

1.0.7

1.0.6

1.0.5

1.0.4

1.0.3

1.0.2

1.0.1

1.0.0

Labels

Clear labels

1week

2weeks

Failed compliance check

IP cameras

NATS

NATS JetStream

Possible security concern

Something isn't working

build

checkers

ci-cd

continuous integration-continuous deployments

cleanup

cnpg

cloud-native postgres

Pull requests that update a dependency file

device-management

documentation

Improvements or additions to documentation

duplicate

This issue or pull request already exists

dusk

ebpf

enhancement

New feature or request

Pull requests that update GitHub Actions code

Pull requests that update Go code

good first issue

Good for newcomers

help wanted

Extra attention is needed

invalid

This doesn't seem right

javascript

Pull requests that update Javascript code

Oracle Linux related issues

otel

opentelemetry logs, traces, metrics

plug-in

proton

timeplus proton streaming database

python

question

Further information is requested

Pull requests that update rust code

sdk

security

serviceradar-agent

serviceradar-agent-gateway

This will not be worked on

zen-engine

No labels

1week

2weeks

Failed compliance check

IP cameras

NATS

Possible security concern

serviceradar-agent-gateway

Milestone

Clear milestone

No items

No milestone

1.1.1

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

carverauto/serviceradar#726

Reference in a new issue

Repository

carverauto/serviceradar

Title

Body

No description provided.

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?

Rows
Columns