feat: agent missing edge onboarding support #875

New issue

Closed

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

mfreeman451 commented

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

Owner

Imported from GitHub.

Original GitHub issue: #2533
Original author: @mfreeman451
Original URL: https://github.com/carverauto/serviceradar/issues/2533
Original created: 2026-01-27T06:33:59Z

Is your feature request related to a problem?

serviceradar-agent seems to be missing the support to do edge onboarding:

[mfreeman@localhost serviceradar]$ /usr/local/bin/serviceradar-agent --help
Usage of /usr/local/bin/serviceradar-agent:
  -config string
    	Path to agent config file (default "/etc/serviceradar/agent.json")
[mfreeman@localhost serviceradar]$

It should accept -enroll -token

This aligns it to accept edge onboarding packages created by web-ng, where users can go into the UI and
generate the onboarding package, all the user should have to do is take the token and pass it to the agent on the CLI, the agent base64 decodes the string, which should contain the address of the serviceradar-agent-gateway and so on. I think historically we had the edge onboarding process generating a config and pushing that down as well, not sure if that is really necessary/still implemented in the elixir rewrite of serviceradar-core.

{
  "checkers_dir": "/etc/serviceradar/checkers",
  "agent_id": "default-agent",
  "agent_name": "127.0.0.1",
  "host_ip": "PLACEHOLDER_HOST_IP",
  "partition": "default",
  "gateway_addr": "agent-gateway:50052",
  "push_interval": "30s",
  "status_debounce_interval": "30s",
  "status_heartbeat_interval": "5m",
  "gateway_security": {
    "mode": "mtls",
    "cert_dir": "/etc/serviceradar/certs",
    "server_name": "agent-gateway",
    "role": "client",
    "tls": {
      "cert_file": "agent.pem",
      "key_file": "agent-key.pem",
      "ca_file": "root.pem"
    }
  },
  "logging": {
    "level": "info",
    "debug": false,
    "output": "stdout",
    "time_format": "",
    "otel": {
      "enabled": true,
      "endpoint": "127.0.0.1:4317",
      "service_name": "serviceradar-agent",
      "batch_timeout": "5s",
      "insecure": false,
      "tls": {
        "cert_file": "/etc/serviceradar/certs/agent.pem",
        "key_file": "/etc/serviceradar/certs/agent-key.pem",
        "ca_file": "/etc/serviceradar/certs/root.pem"
      }
    }
  }
}

So really the core needs to be returning the external IP address of the agent-gateway in the onboarding package, the agent receives it, and updates its config on the filesystem. Need to also make sure the serviecradar-agent-gateway is reachable to edge agents.

update serviceradar-agent to update agent.json with agent-gateway address
have agent or cli update "host_ip": "PLACEHOLDER_HOST_IP" in agent.json
agent-id should also be derived / configured from UI during edge onboarding process in UI and part of the onboarding token
partition should also be configured during the UI edge onboarding process and part of the enrollment package
review edge onboarding UI, there seems to be multiple places to configure / create this stuff (https://192.168.2.235/admin/edge-packages and https://192.168.2.235/settings/agents/deploy)
https://192.168.2.235/admin/edge-packages is broken
make sure agent-gateway is exposed / reachable via public internet in docker compose stack
expose agent-gateway via loadbalancer/service in k8s (helm/manifest)

Another option is to ship serviceradar-cli with the agent and let the cli handle updating the config.

https://192.168.2.235/admin/edge-packages also appears to be broken:

06:34:34.528 [info] CONNECTED TO Phoenix.LiveView.Socket in 39�s
  Transport: :websocket
  Serializer: Phoenix.Socket.V2.JSONSerializer
  Parameters: %{"_csrf_token" => "QQkJABhnDURGJxVDRBk9IQAmYhlYEgJ-lLxca4Itqwb9iPrvjh64khj7", "_live_referer" => "undefined", "_mount_attempts" => "0", "_mounts" => "0", "_track_static" => %{"0" => "https://192.168.2.235/assets/css/app-3d3cbc8ec20ad9a2e5fda777bb06c5a6.css?vsn=d", "1" => "https://192.168.2.235/assets/js/app-3b3a31883956d121ce95946e82415dd0.css?vsn=d", "2" => "https://192.168.2.235/assets/js/app-5d1fa133666facee3fe4671fa9efc71c.js?vsn=d"}, "vsn" => "2.0.0"}
06:34:34.569 [info] GRPC.Client.Connection stopping as requested
06:34:37.080 [error] GenServer #PID<0.35789.0> terminating
** (RuntimeError) Cannot access AshPhoenix.Form.

You're trying to access a form field but the form is not a Phoenix.HTML.Form struct.

If you are using Phoenix, you are likely missing to_form/2 call on the form.

Instead of:
    AshPhoenix.Form.for_create(MyApp.Blog.Post, :create)

Use:
    AshPhoenix.Form.for_create(MyApp.Blog.Post, :create) |> to_form()

    (ash_phoenix 2.3.18) lib/ash_phoenix/form/form.ex:484: AshPhoenix.Form.fetch/2
    (elixir 1.19.4) lib/access.ex:326: Access.get/3
    (serviceradar_web_ng 0.1.0) lib/serviceradar_web_ng_web/live/admin/edge_package_live/index.ex:446: anonymous fn/3 in ServiceRadarWebNGWeb.Admin.EdgePackageLive.Index.create_modal/1
    (phoenix_live_view 1.1.19) lib/phoenix_live_view/diff.ex:420: Phoenix.LiveView.Diff.traverse/6
    (phoenix_live_view 1.1.19) lib/phoenix_live_view/diff.ex:609: anonymous fn/3 in Phoenix.LiveView.Diff.traverse_dynamic/6
    (elixir 1.19.4) lib/enum.ex:2520: Enum."-reduce/3-lists^foldl/2-0-"/3
    (phoenix_live_view 1.1.19) lib/phoenix_live_view/diff.ex:419: Phoenix.LiveView.Diff.traverse/6
    (phoenix_live_view 1.1.19) lib/phoenix_live_view/diff.ex:609: anonymous fn/3 in Phoenix.LiveView.Diff.traverse_dynamic/6
Process Label: {Phoenix.LiveView, ServiceRadarWebNGWeb.Admin.EdgePackageLive.Index, "lv:phx-GI6C8NBHoDO-WSzB"}
Last message: %Phoenix.Socket.Message{topic: "lv:phx-GI6C8NBHoDO-WSzB", event: "event", payload: %{"event" => "open_create_modal", "type" => "click", "value" => %{"value" => ""}}, ref: "12", join_ref: "4"}
06:34:38.124 [info] GRPC.Client.Connection stopping as requested

Also I'm not really sure how the agent-gateway would be aware of its external IP address if it were running in docker or k8s. We might have to add some UI into web-ng settings pages where we can just hardcode that in, it would be a task the user does after installation or if they needed to deploy edge packages, this is a pre-requisite?

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: #2533 Original author: @mfreeman451 Original URL: https://github.com/carverauto/serviceradar/issues/2533 Original created: 2026-01-27T06:33:59Z --- **Is your feature request related to a problem?** `serviceradar-agent` seems to be missing the support to do edge onboarding: ``` [mfreeman@localhost serviceradar]$ /usr/local/bin/serviceradar-agent --help Usage of /usr/local/bin/serviceradar-agent: -config string Path to agent config file (default "/etc/serviceradar/agent.json") [mfreeman@localhost serviceradar]$ ``` It should accept -enroll -token <token> This aligns it to accept edge onboarding packages created by `web-ng`, where users can go into the UI and generate the onboarding package, all the user should have to do is take the token and pass it to the agent on the CLI, the agent base64 decodes the string, which should contain the address of the `serviceradar-agent-gateway` and so on. I think historically we had the edge onboarding process generating a config and pushing that down as well, not sure if that is really necessary/still implemented in the elixir rewrite of `serviceradar-core`. ```json { "checkers_dir": "/etc/serviceradar/checkers", "agent_id": "default-agent", "agent_name": "127.0.0.1", "host_ip": "PLACEHOLDER_HOST_IP", "partition": "default", "gateway_addr": "agent-gateway:50052", "push_interval": "30s", "status_debounce_interval": "30s", "status_heartbeat_interval": "5m", "gateway_security": { "mode": "mtls", "cert_dir": "/etc/serviceradar/certs", "server_name": "agent-gateway", "role": "client", "tls": { "cert_file": "agent.pem", "key_file": "agent-key.pem", "ca_file": "root.pem" } }, "logging": { "level": "info", "debug": false, "output": "stdout", "time_format": "", "otel": { "enabled": true, "endpoint": "127.0.0.1:4317", "service_name": "serviceradar-agent", "batch_timeout": "5s", "insecure": false, "tls": { "cert_file": "/etc/serviceradar/certs/agent.pem", "key_file": "/etc/serviceradar/certs/agent-key.pem", "ca_file": "/etc/serviceradar/certs/root.pem" } } } } ``` So really the core needs to be returning the external IP address of the agent-gateway in the onboarding package, the agent receives it, and updates its config on the filesystem. Need to also make sure the `serviecradar-agent-gateway` is reachable to edge agents. - [x] update serviceradar-agent to update agent.json with agent-gateway address - [x] have agent or cli update "host_ip": "PLACEHOLDER_HOST_IP" in agent.json - [x] agent-id should also be derived / configured from UI during edge onboarding process in UI and part of the onboarding token - [x] partition should also be configured during the UI edge onboarding process and part of the enrollment package - [x] review edge onboarding UI, there seems to be multiple places to configure / create this stuff (https://192.168.2.235/admin/edge-packages and https://192.168.2.235/settings/agents/deploy) - [x] https://192.168.2.235/admin/edge-packages is broken - [ ] make sure agent-gateway is exposed / reachable via public internet in docker compose stack - [ ] expose agent-gateway via loadbalancer/service in k8s (helm/manifest) Another option is to ship serviceradar-cli with the agent and let the cli handle updating the config. https://192.168.2.235/admin/edge-packages also appears to be broken: ``` 06:34:34.528 [info] CONNECTED TO Phoenix.LiveView.Socket in 39�s Transport: :websocket Serializer: Phoenix.Socket.V2.JSONSerializer Parameters: %{"_csrf_token" => "QQkJABhnDURGJxVDRBk9IQAmYhlYEgJ-lLxca4Itqwb9iPrvjh64khj7", "_live_referer" => "undefined", "_mount_attempts" => "0", "_mounts" => "0", "_track_static" => %{"0" => "https://192.168.2.235/assets/css/app-3d3cbc8ec20ad9a2e5fda777bb06c5a6.css?vsn=d", "1" => "https://192.168.2.235/assets/js/app-3b3a31883956d121ce95946e82415dd0.css?vsn=d", "2" => "https://192.168.2.235/assets/js/app-5d1fa133666facee3fe4671fa9efc71c.js?vsn=d"}, "vsn" => "2.0.0"} 06:34:34.569 [info] GRPC.Client.Connection stopping as requested 06:34:37.080 [error] GenServer #PID<0.35789.0> terminating ** (RuntimeError) Cannot access AshPhoenix.Form. You're trying to access a form field but the form is not a Phoenix.HTML.Form struct. If you are using Phoenix, you are likely missing to_form/2 call on the form. Instead of: AshPhoenix.Form.for_create(MyApp.Blog.Post, :create) Use: AshPhoenix.Form.for_create(MyApp.Blog.Post, :create) |> to_form() (ash_phoenix 2.3.18) lib/ash_phoenix/form/form.ex:484: AshPhoenix.Form.fetch/2 (elixir 1.19.4) lib/access.ex:326: Access.get/3 (serviceradar_web_ng 0.1.0) lib/serviceradar_web_ng_web/live/admin/edge_package_live/index.ex:446: anonymous fn/3 in ServiceRadarWebNGWeb.Admin.EdgePackageLive.Index.create_modal/1 (phoenix_live_view 1.1.19) lib/phoenix_live_view/diff.ex:420: Phoenix.LiveView.Diff.traverse/6 (phoenix_live_view 1.1.19) lib/phoenix_live_view/diff.ex:609: anonymous fn/3 in Phoenix.LiveView.Diff.traverse_dynamic/6 (elixir 1.19.4) lib/enum.ex:2520: Enum."-reduce/3-lists^foldl/2-0-"/3 (phoenix_live_view 1.1.19) lib/phoenix_live_view/diff.ex:419: Phoenix.LiveView.Diff.traverse/6 (phoenix_live_view 1.1.19) lib/phoenix_live_view/diff.ex:609: anonymous fn/3 in Phoenix.LiveView.Diff.traverse_dynamic/6 Process Label: {Phoenix.LiveView, ServiceRadarWebNGWeb.Admin.EdgePackageLive.Index, "lv:phx-GI6C8NBHoDO-WSzB"} Last message: %Phoenix.Socket.Message{topic: "lv:phx-GI6C8NBHoDO-WSzB", event: "event", payload: %{"event" => "open_create_modal", "type" => "click", "value" => %{"value" => ""}}, ref: "12", join_ref: "4"} 06:34:38.124 [info] GRPC.Client.Connection stopping as requested ``` Also I'm not really sure how the agent-gateway would be aware of its external IP address if it were running in docker or k8s. We might have to add some UI into web-ng settings pages where we can just hardcode that in, it would be a task the user does after installation or if they needed to deploy edge packages, this is a pre-requisite? **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.