Release Notes¶

2.10.0¶

Note

The internal version of the PostgreSQL database has been upgraded from version 13 to 17. Currently existing data will be automatically translated to the new database version upon first boot after a PixStor upgrade. Logs for this process can be retrieved from the ngeneahub-dbmigration systemd service.

What you need to know¶

Ngenea Hub now backs up database data and configuration on startup
It is now possible to include job history in database backups. Note that including job history will increase the size of the backup file and will take longer to complete. Details for this are in the backup configuration settings.
New Job Alerting functionality can send email alerts if Jobs error or are not yet finished after an expected time period
Ngenea Hub is now prepared for failover by allowing multiple Ngenea Hub instances with shared high-availability (HA) services such as PostgreSQL, Redis and RabbitMQ. See the Ngenea Hub configuration guide for further information.
All share types can now be configured per-Site on each Space

Changes that may affect tools¶

The /health endpoint now reports on infrastructure component health The previous Sites health response is now available at /health/sites
Docker service names change to a new format, E.G. ngeneahub_backend_1, is now ngeneahub-backend-1
The output format of ngeneahubctl status now only reports service status and uptime The “command” and “port” columns have been removed. Use docker ps to retrieve detailed service information.
Ngenea Hub provides an updated Docker version. The updated Docker version is incompatible with DJANGO_SECRETS containing a $ or # character. Hub automatically converts the Django secrets where such characters are present. Upon conversion existing JWT tokens are invalidated. Hub native API keys are not affected.

What’s Fixed¶

Consult the changelog for individual fixes

2.9.4¶

What you need to know¶

Resolves an indentified vulnerability in Ngenea Hub versions 2.7.0 through 2.9.3 inclusive that could allow a low-privileged user to elevate their privileges by changing their group membership or performing user management via remote API requests.

What’s Fixed¶

Consult the changelog for individual fixes

2.9.3¶

What you need to know¶

Adds a default workflow for manual Iris notification. Import of a custom workflow is no longer required.
Introduces various quality of life improvements to the Hub UI. Refer to the changelog for individual improvements.
Ngenea HSM 1.33 support
Cloud provider-specific tasks will be deprecated in a future release. The following tasks are affected:
- delete_from_s3
- remove_from_s3_bucket
- copy_between_s3_buckets
- remove_from_gcs_bucket
- copy_between_gcs_buckets

What’s Fixed¶

Consult the changelog for individual fixes

2.9.2¶

What you need to know¶

Adds support for triggering Iris file notification manually. This requires the import of a custom workflow. Contact support for more details.

What’s Fixed¶

This release includes no bug fixes.

2.9.1¶

What you need to know¶

Resolves an issue whereby upgrades from versions prior to 2.8.0 causes pre-upgrade schedules running workflows with snapdiff, such as sync, to reprocess all data. New schedules post-upgrade are unaffected.

What’s Fixed¶

Consult the changelog for individual fixes

2.9.0¶

Whats new¶

Iris enablement of spaces
Iris Single Sign On (SSO)
External service support for Postgres, RabbitMQ and Redis
Ngenea HSM 1.32 support

What you need to know¶

The configuration value LDAP_MIRROR_GROUPS is no longer json loaded, please consult the LDAP documentation for more details.
The configuration value “celery_broker” will be automatically replaced with BROKER_PROVIDER and RESULTS_PROVIDER on first hub startup.
Any configuration file older than version 2.9.0 will be backed up with this upgrade
SSO and LDAP cannot be enabled simultaneously, please consult the LDAP and Single Sign-On documentation for more details.
SSO is not enabled by default and must be configured and enabled, details for this process are in the Single Sign-On documentation.

What’s Fixed¶

Consult the changelog for individual fixes

2.8.3¶

What you need to know¶

Resolves an indentified vulnerability in Ngenea Hub versions 2.7.0 through 2.9.3 inclusive that could allow a low-privileged user to elevate their privileges by changing their group membership or performing user management via remote API requests.

What’s Fixed¶

Consult the changelog for individual fixes

2.8.2¶

What you need to know¶

Resolves an issue whereby upgrades from versions prior to 2.8.0 causes pre-upgrade schedules running workflows with snapdiff, such as sync, to reprocess all data. New schedules post-upgrade are unaffected.
Support all ngenea configuration paramaters for HSM External Targets

2.8.1¶

What you need to know¶

Ngenea targets are no longer renamed on update, the new format is only applied to new targets
Ngenea HSM 1.32 support has been added to targets

What’s Fixed¶

Consult the Changelog for individual fixes

2.8.0¶

What’s new¶

Iris beta (feature flagged)
Initial release of Programming Guide, with improved, user-friendly REST API documentation

What you need to know¶

API only workflows can now be selected when editing the Space Schedules and Schedule settings
Hub containers now auto-restart when encountering an issue which causes container shutdown

What’s Fixed¶

Consult the Changelog for individual fixes

2.7.1¶

What you need to know¶

Ngenea targets are no longer renamed on update, the new format is only applied to new targets

What’s Fixed¶

Consult the Changelog for individual fixes

2.7.0¶

What’s new¶

Spaces can now be viewed in table layout
Schedules are now specified relative to the site timezones rather than UTC+0
Site workflow batch size options to control workflow task processing performance
Policies support more file systems than mmfs1
Global settings now provides Timeout controls for Hub behaviours
API performance can be scaled with the new GUNICORN_THREADS setting

What you need to know¶

Where NAS user(s) and group(s) exist prior to additional sites being joined, automatic creation of existing NAS users and groups as part of setup on the new Site may fail if the Site is still undergoing joining. Should this occur, re-submit the failed ‘Creating NAS group’ and/or ‘Creating NAS user’ job after a few minutes.

What’s Fixed¶

Consult the Changelog for individual fixes