Stork 0.1.0, November 06th 2019, Release Notes

Welcome to the Stork 0.1.0 release. This is the very first development of the Stork project, which aims at providing a modern, responsive and scalable dashboard solution with well defined REST API interface. The long term goal of the project is to provide a monitoring and management solution for BIND, Kea DHCP and more.

The goal of this initial release is to provide some fundamental building blocks, such as building procedures, server framework, server-agent connectivity and a basic user interface. There are no end-user usable features yet. The first basic user features are coming up in 0.2.

Features introduced in this version:

1. Stork server with REST API. We now have a functional Stork server. Every network is expected to deploy a single central server in their core. The server provides a handful of REST API calls that govern user authentication, checking server version, connecting to agent and more. We do have a responsive web interface based on modern tooling (Angular 8). #22 (closed)

2. Stork agent. The agent is a small tool that's expected to be deployed on every machine that runs either BIND or Kea DHCP server to be monitored. #26 (closed)

3. Checking Machine status. The agent is able to retrieve machine status, including OS name, hostname, OS version, virtualization type, IP address, number of CPU cores, CPU load, available memory, memory utilization, uptime and more. The server is able to connect to a Stork agent using gRPC over http/2 and retrieve that information remotely. #23 (closed)

4. Database connection and upgrades. The Stork server is able to connect to PostgreSQL database and retrieve various pieces of information from it. Right now the schema is rather simple, but it is expected to grow in complexity significantly in the near future. A migrations (upgrade/downgrade) mechanism has been implemented. #20 (closed)

5. User authentication. The Stork UI has a simple login form that retrieves data from the server and manages user login process. Both the UI (browser side) and the server are able to store session information, so returning users will not have to log in repeatedly. #22 (closed)

6. Stork ARM. We have a Stork Administrator Reference Manual. It's simple. It will get better in the future. #27 (closed)

7. Build framework. Stork comes with a build system that simplifies the compilation procedure. To build stork 0.1, you need to have rake, jre and docker installed. Every other dependency will be retrieved and installed locally (no root credentials needed). Stork can be built with one command: rake docker_up. #19 (closed)

8. Development environment. We came up with many tools, scripts and processes the end users don't really see. We have a CI environment that lets us build the software automatically and flag issues to developers, we have unit-tests that are ran after every commit, we have coding guidelines, the team agreed on many processes that put a shape around our intentions to develop the software. #28 (closed), #30 (closed), #34 (closed)

Release Model

Stork is expected to have monthly development releases on the first Wednesday of each month (with some exceptions around holidays). We're planning to have a first major release 0.8 some time in the spring of 2020.

We encourage users to test the development releases and report back their findings on the stork-dev mailing list, available at https://lists.isc.org/mailman/listinfo/stork-dev.

This text references issue numbers. For more details, visit the Stork GitLab page at https://gitlab.isc.org/isc-projects/stork/issues.

License

This version of Stork is released under the Mozilla Public License, version 2.0.

https://www.mozilla.org/en-US/MPL/2.0

Download

The Stork source and PGP signature for this release may be downloaded from:

https://ftp.isc.org/isc/stork

The signature was generated with the ISC code signing key which is available at:

https://www.isc.org/pgpkeys

ISC provides documentation in the Stork Administrator Reference Manual. It is currently available only in the source form in docs/ directory. To build it, you need the Sphinx tool. This is expected to change in a future release.

We ask users of this software to please let us know how it worked for you and what operating system you tested on. Feel free to share your feedback on the Stork-Dev mailing list (https://lists.isc.org/mailman/listinfo/stork-dev). Also we would like to hear whether the documentation is adequate and accurate. Please open tickets in the Stork GitLab project for bugs, documentation omissions and errors, and enhancement requests. We want to hear from you even if everything worked.

Support

Professional support for Stork will become available once it reaches 1.0 milestone. Existing ISC customers that consider themselves very early adopters may get involved in the development process, including roadmap, features planning and early testing, but the software maturity level does not constitute a typical professional service before 1.0 milestone.

Free best-effort support is provided by our user community via a mailing list. Information on all public email lists is available at https://www.isc.org/community/mailing-list. If you have any comments or questions about working with Stork, please share them to the Stork-dev List (https://lists.isc.org/mailman/listinfo/stork-dev). Bugs and feature requests may be submitted via GitLab at https://gitlab.isc.org/isc-projects/stork/issues.

Changes

The following summarizes changes and important upgrade notes since beginning of the project.

• 8 [func] marcin

  Enabled sign-in/sign-out mechanism with HTTP sessions based on cookies. The default admin account has been created with default credentials. (Gitlab #22 (closed))

• 7 [func] godfryd

  Added initial implementation of the page which allows for adding new machines and listing them. The missing part of this implementation is the actual storage of the machines in the database. In addition, the agent has been extended to return a state of the machine. (Gitlab #23 (closed))

• 6 [func] godfryd

  Added initial implementation of Stork Agent. Implemented basic communication between Stork Agent and Stork Server using gRPC (Server initiates connection to Agent). (Gitlab #26 (closed))

• 5 [func] marcin

  Added stork-db-migrate tool to be used for migrating the database schema between versions and returning the current schema version number. Also, added basic schema with SQL tables holding system users and session information. (Gitlab #20 (closed))

• 4 [doc] tomek

  Added several text files: AUTHORS (lists project authors and contributors), ChangeLog.md (contains all new user visible changes) and CONTRIBUTING.md (Contributor's guide, explains how to get your patches accepted in Stork project in a seamless and easy way. (Gitlab #17 (closed))

• 3 [func] godfryd

  Added Swagger-based API for defining ReST API to Stork server. Added initial Web UI based on Angular and PrimeNG. Added Rakefile for building whole solution. Removed gin-gonic dependency. (Gitlab #19 (closed))

• 2 [build] godfryd

  Added initial framework for backend, using go and gin-gonic. (Gitlab #missing)

• 1 [func] franek

  Added initial proposal for Grafana dashboard. (Gitlab #6 (closed))

Thank you again to everyone who assisted us in making this release possible.

We look forward to receiving your feedback.