Skip to content

v1.4.0

Pre-release
Pre-release
Compare
Choose a tag to compare
@github-actions github-actions released this 26 Feb 15:43
· 13 commits to main since this release
v1.4.0
dfec22e

Release 1.4.0

What's New

  • Changes to backup/restore and standalone to HA migrations
  • Use cluster consistently for cluster operations
  • Event Doc and Consistency
  • ziti ops verify changes
    • Moved ziti ops verify-network to ziti ops verify network
    • Moved ziti ops verify traffic to ziti ops verify traffic
    • Added ziti ops verify ext-jwt-signer oidc to help users with configuring OIDC external auth
    • Added ziti ops verify ext-jwt-signer oidc to help users with configuring OIDC external auth
  • Router Controller Endpoint Changes
  • Bug fixes

Config Changes

NOTE: For HA configuration, the raft: config stanza is now named cluster:.

Example:

cluster:
  dataDir: ./data

Event Doc and Consistency

The event types are now exhaustively documented as part of the OpenZiti Reference Documentation.

During documentation, some inconsistencies were found the following changes were made.

Namespace Cleanup

Namespaces have been cleaned up, with the following changes:

  • edge.apiSessions -> apiSession
  • fabric.circuits -> circuit
  • edge.entityCount -> entityCount
  • fabric.links -> link
  • fabric.routers -> router
  • services -> service
  • edge.sessions -> session
  • fabric.terminators -> terminator
  • fabric.usage -> usage

Note that service events used services in the config file, but service.events in the event itself.
The old namespaces still work. If the old event type is used in the config file, the old namespace will be in the events as well

Timestamp field

The following event types now have a timestamp field:

  • service
  • usage

This timestamp is the time the event was generated.

Event Source ID

All event types now have a new field: event_src_id. This field is the id of the controller
which emitted the event. This may be useful in HA environments, during event processing.

Cluster Operations Naming

The CLI tools under ziti fabric raft are now found at ziti ops cluster.

The Raft APIs available in the fabric management API are now namespaced under Cluster instead.

Backup/Restore/HA Migrations

What restoring from a DB snapshot has in common with migrating from a standalone setup to
a RAFT enabled one, is that the controller is changing in a way that the router might not
notice.

Now that routers have a simplified data model, they need know if the controller database
has gone backwards. In the case of a migration to an HA setup, they need to know that
the data model index has changed, likely resetting back to close to zero.

To facilitate this, the database now has a timeline identifier. This is shared among
controllers and is sent to routers along with the data state. When the controller
restores to a snapshot of previous state, or when the the controller moves to a
raft/HA setup, the timeline identifier will change.

When the router requests data model changes, it will send along the current timeline
identifier. If the controller sees that the timeline identifier is different, it knows
to send down the full data state.

Implementation Notes

In general this is all handled behind the scenes. The current data model index and
timeline identifier can be inspected on controllers and routers using:

ziti fabric inspect router-data-model-index

Example

$ ziti fabric inspect router-data-model-index
Results: (3)
ctrl1.router-data-model-index
index: 25
timeline: MMt19ldHR

vEcsw2kJ7Q.router-data-model-index
index: 25
timeline: MMt19ldHR

ctrl2.router-data-model-index
index: 25
timeline: MMt19ldHR

Whenever we create a database snapshot now, the snapshot will contain a flag indicating
that the timeline identifier needs to be changed. When a standalone controller starts
up, if that flag is set, the controller changes the timeline identifier and resets the flag.

When an HA cluster is initialized using an existing controller database it also changes the
timeline id.

HA DB Restore

There's a new command to restore an HA cluster to an older DB snapshot.

ziti agent controller restore-from-db </path/to/database.file>

Note that when a controller is already up and running and receives a snapshot to apply, it
will move the database into place and then shutdown, expecting to be restarted. This is
because there is caching in various places and restartingi makes sure that everything is
coherent with the changes database.

Router Controller Endpoint Updates

Endpoints File Config

The config setting for controller the endpoints file location has changed.

It was:

ctrl:
  dataDir: /path/to/dir

The endpoints file would live in that directory but always be called endpoints.

This is replaced by a more flexible endpointsFile.

ctrl:
  endpointsFile: /path/to/endpoints.file

The default location is unchanged, which is a file named endpoints in the same
directory as the router config file.

Enrollment

The router enrollment will now contain the set of known controllers at the time
the router as enrollled. This also works for standalone controllers, as long as
the advertiseAddress settings is set.

Example

ctrl:
  listener: tls:0.0.0.0:6262
  options:
    advertiseAddress: tls:ctrl1.ziti.example.com

This means that the controller no longer needs to be set manually in the config
file, enrollment should handle initializing the value appropriately.

Component Updates and Bug Fixes