Known issues

Known Issues in Stork

The following is the list of known issues in current and previous versions of Stork. You can also see all Stork issues under this link.

Some of the dependencies have security deficiencies reported. The versions used by Stork have not been updated to their latest, patched versions. This will be addressed in the upcoming 0.19.0 release. Notable problems discovered during audit are: xmlhttprequest-ssl, y18n, url-parse, ua-parser-js, lodash, dns-packet.

The Stork Agent's --host command line option doesn't work. This command line option should configure the agent to use a specific IP address to receive the connections from the Stork Server over gRPC. The agent always uses the default 0.0.0.0 address regardless of the --host setting. See #504 (closed) for details.

Events panel presented for a machine is not refreshed when switching between machine tabs. As a result, this panel may show events referring to a different machine than currently selected. Clicking on the Machines tab (the tab listing all machines) and returning to the selected machine's tab is a known workaround to ensure that the correct list of events is displayed for the machine. See #463 (closed) for details.

When starting to monitor a machine running Kea with many subnets configured, some errors may be observed in the Stork server logs indicating database unique constraint violations. This is caused by bottlenecks in the process of machine state fetching which may sometimes lead to concurrent updates of the same information in the database. Nevertheless, this should not cause any data integrity issues in Stork database.

If upgrading from previous releases, see known issues for 0.8.0 below.
When deploying stork agent, make sure that only legitimate stork server is able to connect. A better access control is expected in future Stork versions, but for the time being please use firewall to restrict who can connect to the agent.

There are appearing problems with starting Stork demo using rake docker_up command on Ubuntu 20.04. This is due to a kernel bug and a workaround in Go runtime. GitLab #306 (closed)
When upgrading Stork Server or Stork Agent from 0.8.0 or 0.9.0 using RPM packages, the upgrade procedure will fail complaining about stork-agent or stork-server account. The workaround for this is to not do upgrade, but remove the old package first and then install new one. This problem is fixed in 0.10.0, so future upgrades to 0.11 and beyond will work. However, the underlying problem is in 0.9.0 and earlier install scripts. If you upgrade from 0.8.0 and encounter problems with missing stork-agent or stork-server accounts, the issue may be fixed using yum reinstall isc-stork-server or yum reinstall isc-stork-agent on a version 0.10 or later.

It's not possible to install both Agent and Server deb packages on the same machine. The server package contains too many files that conflict with the agent package. This issue will be resolved with updated packages in the near future.

We would appreciate feedback on usability and reports of any Stork bugs. Please contribute your experiences to the Stork users mailing list: https://lists.isc.org/mailman/listinfo/stork-dev or submit new gitlab issues.