Potential gotchas

[cakrit]

The idea here is to "prepare a wsl2 image with the required changes, use the WSL2 export/import functionalities and setup the msi file using wix to install everything"

There are a couple of potential pitfalls here, worth considering ahead of time:

• How will the image be kept up to date? Netdata has nightly and stable releases. It also comes by default with an auto-updater running every night via a cron job.
• If an image is created after Netdata has run even once, the file /var/lib/netdata/registry/netdata.public.unique.id will have been created. All netdata processes must be stopped and that file removed before a snapshot is taken. When netdata runs again, it will enter in that file a unique id. We want each server to have a different unique id, but we also want that id to be persisted/maintained in its lifetime (i.e. it should survive upgrades).

There's also the optional connection to netdata cloud. A user should be able to run the installer without any arguments. But if a user wants to, they could provide the following three parameters. We will provide users with the complete command including these parameters from within netdata.cloud:

• TOKEN: A unique identifier that will connect their agent to netdata cloud.
• URL: The URL to Netdata cloud (always https://app.netdata.cloud today).
• ROOMS: a comma-separated list of identifiers. This one is optional.

If the image already has an installed and running netdata, then the msi should probably run the following and return its output to the console, if the parameters are passed:

/usr/sbin/netdata-claim.sh -token=TOKEN -rooms=ROOMS -url=URL

A potential solution is to not even check what arguments are passed and blindly execute /usr/sbin/netdata-claim.sh with whatever the user passes as a parameter to the msi.

Finally, the kickstart script itself has a lot of parameters/options for configuration. If the image is generated after kickstart has been executed, I'm not sure if and how we'll be able to support those options.

[dfpr]

I will take into consideration these points for the prototype, I can think of some ways to integrate such updates, I'll work on them after the initial installation and setup has been developed.

[Ferroin]

Regarding updates, I’m strongly inclined to suggest we just do MSI builds for stable releases (most likely users on Windows are businesses, who in turn are far more likely to be using stable releases and not nightlies), and then let users manage updates themselves (just like we do with other container setups).

Regarding the kickstart options, 99% of those are either build-time things or options which control the operation of the script itself. Of the actual options there, the only ones that we are likely to need special handling for are:

• --disable-telemetry: This just needs to touch /etc/netdata/.opt-out-from-anonymous-statistics in the WSL environment.
• --disable-cloud: This just needs to create a file called /var/lib/netdata/cloud.d/cloud.conf containing:

  [global]
  enabled = no

Other than that, and possibly the automatic updates options, everything else is either irrelevant for this style of install (mostly because it’s pre-built), or is something that would be inherently handled by the MSI itself (like uninstalling or reinstalling).

On a side note, it’s an absolute requirement that this can be installed with any options specified on the command line, ideally with the ability to run it entirely non-interactively. The expected primary users are devops and netops people, who will want to install via remote PowerShell or whatever orchestration tooling they happen to use.

---

As far as actually building things, I think the sanest approach is probably going to be producing the WSL image file in our regular CI (probably alongside the static builds) and then saving it somewhere that the MSI build process can fetch it from. That would help ensure that the build process for the agent itself stays in sync properly, and should in theory greatly simplify implementing CI for the MSI itself.

If that’s the way we want to go, I can probably have something working to produce that some time tomorrow.

[cakrit]

If that’s the way we want to go, I can probably have something working to produce that some time tomorrow.

Perhaps we wait for @dfpr to do the prototype first and we take it from there.

[cakrit]

FYI @dfpr the overall project for Netdata on Windows is tracked on https://github.com/netdata/netdata/issues/13727 Mentioning it in case you run into something unexpected, you'll see there some known limitations and expected improvements.

[dfpr]

FYI @dfpr the overall project for Netdata on Windows is tracked on netdata/netdata#13727 Mentioning it in case you run into something unexpected, you'll see there some known limitations and expected improvements.

Got it, good to know, specially the systemd thing, I'll keep in mind trying it to work for the daemon.

[cakrit]

I added a couple of lines to the README for the installation options mentioned in https://github.com/netdata/msi-installer/issues/1#issuecomment-1281407719 Closing.

[dfpr]

I've added MSI arguments for the Telemetry, Rooms and the cloud URL, also updated the README with that and the agent restarting command, removed the cloud info as the source Docker image contains it regardless of claiming afaict.