v0.28.0 #77
antybubbs
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Kaya v0.28.0
Kaya v0.28.0 is a major reliability and platform release.
Since v0.27.4, a significant amount of work has gone into preparing Kaya for larger and more resilient deployments. This release introduces the move to PostgreSQL, strengthens High Availability and DHCP failover behaviour, expands Asset Manager, improves Remote Manager reliability, and includes a substantial amount of security, migration, deployment and operational hardening.
** Please follow the guide here for migrating from SQLite to PostgreSQL
Highlights
PostgreSQL
PostgreSQL becomes the primary database
Kaya's production Docker deployment now uses PostgreSQL rather than SQLite.
This removes a number of limitations associated with SQLite under concurrent workloads and provides a stronger foundation for larger installations, background services and High Availability environments.
The standard Compose stack now includes:
guacdSQLite to PostgreSQL upgrade path
Existing Kaya installations are not expected to start from scratch.
v0.28.0 introduces a dedicated SQLite to PostgreSQL migration process designed to preserve existing application data while moving an installation onto the new database platform.
The migration tooling includes:
A dedicated
docker-compose.upgrade.ymlworkflow is provided for the migration process.Complex foreign-key migration support
Kaya's schema contains relationships that cannot safely be migrated using simple alphabetical or table-by-table insertion.
The migration engine now builds a dependency graph from the reflected PostgreSQL schema and uses deterministic strongly connected component detection to handle cyclic relationships.
Where required, nullable foreign-key relationships are temporarily deferred during import and restored after the related records exist.
Rejected inserts now fail the migration rather than being silently retried into an uncertain database state.
High Availability
A significant amount of work in v0.28.0 has focused on making Kaya's HA behaviour safer and more deterministic.
DHCP failover fencing
Kaya now applies stronger fencing rules before allowing a node to provide DHCP service.
A node can no longer become DHCP-active simply because it briefly observes itself as the VIP owner.
Promotion repair now requires 10 seconds of continuous eligible VIP ownership before DHCP is enabled.
Kaya also persists
vip_stable_since, allowing the HA subsystem to reason about whether ownership is genuinely stable rather than treating a single heartbeat observation as authoritative.Protection against stale HA commands
Additional safeguards have been added around
DHCP_PROMOTEandDHCP_DEMOTE.A stale promotion is rejected when:
ACTIVEA stale demotion is rejected when:
If VIP ownership is lost while promotion is in progress, DHCP is disabled rather than being allowed to continue on a node that no longer owns the service address.
These changes reduce the risk of split-brain DHCP operation during transient HA transitions.
Existing HA protections retained
The new fencing work builds on, rather than replaces, Kaya's existing protections, including:
Asset Manager
Asset Manager received a substantial set of improvements in v0.28.0.
Asset photographs
Assets can now have photographs associated with them, making it considerably easier to identify physical equipment.
Support includes:
The information layout on the asset detail page has also been adjusted to accommodate the new photo area without changing Kaya's established branding or button design.
Improved asset photo layout
The image and information panels have been aligned more closely so the asset page feels like a single cohesive interface.
Photo areas no longer require an internal scroll simply to inspect their contents, and unwanted hover-border behaviour has been removed.
Automatic asset tags
Asset Manager now supports automatically generated asset tags.
Administrators can define a prefix, for example:
HALKaya can then allocate sequential identifiers such as:
HAL0001HAL0002HAL0003This provides a simple built-in asset numbering system without requiring organisations to manually assign every identifier.
Asset and IP association
Asset records can also be associated with their relevant network identity, making Asset Manager more useful for infrastructure equipment that also exists elsewhere within Kaya's network management data.
Filesystem hardening
The Asset Manager storage paths were reviewed as part of the v0.28.0 work.
Photo, thumbnail, attachment and deletion operations now resolve storage locations through validated asset records rather than constructing filesystem paths directly from request-derived identifiers.
The review covered:
Remote Manager
More reliable first connection
Remote Manager previously exhibited an issue where the first attempt to start a session could be refused, while immediately retrying with the same credentials succeeded.
The session startup sequence has been corrected so connection establishment is properly coordinated before the client attempts to use it.
This removes the common "first attempt fails, second attempt works" behaviour and makes Remote Manager feel considerably more predictable.
Deployment
Simplified Docker Compose configuration
The main Compose configuration has been cleaned up as part of the PostgreSQL transition.
The production stack is now focused on the services Kaya actually requires at runtime, while database conversion is kept in the dedicated upgrade workflow.
Temporary migration and development artefacts have also been explicitly excluded through additional
.gitignorerules.Cleaner repository structure
A wider repository clean-up accompanied the release work.
This included reviewing obsolete or temporary migration artefacts, test harness output, local database files and generated reports so they do not accidentally become part of normal source control.
Development and Release Workflow
The Docker publishing workflow has also been improved.
Development builds
Pushes to the
devbranch now publish:Development builds:
latestThis makes the distinction between development, release candidate and production images much clearer.
Release protection
RC and stable release behaviour remains separate from normal development publishing, helping prevent development builds from accidentally becoming production images.
Production Compose continues to default to the stable
latestimage unless another image is explicitly selected.Reliability and Engineering
v0.28.0 contains a broad set of regression tests and safety checks covering areas touched by the release.
Particular attention has been given to:
A number of changes were deliberately implemented as targeted fixes rather than broad rewrites so existing behaviour such as authentication, agent signing, rollback handling and established UI branding remained intact.
Security
Security-sensitive areas reviewed or hardened during this release include:
Migration and HA operations are designed to fail closed where Kaya cannot establish that continuing would be safe.
Upgrading from v0.27.4
v0.28.0 changes Kaya's primary database platform from SQLite to PostgreSQL. Existing installations should use the documented upgrade process rather than replacing their deployment configuration and starting Kaya directly against an empty PostgreSQL database.Before upgrading:
Existing SQLite databases should be retained until the PostgreSQL migration has been fully verified.
Container image
For normal production deployments:
Thank you
v0.28.0 represents a substantial amount of work below the surface of Kaya.
While there are visible additions such as Asset Manager photography and asset tagging, much of this release has been about making the platform safer to upgrade, more reliable under concurrent workloads, and better prepared for High Availability and larger self-hosted environments.
As always, issues and feedback are welcome through the Kaya GitHub repository.
This discussion was created from the release v0.28.0.
All reactions