Skip to main content
Version: 4.12.x.x LTS

Recommendations and Limitations

To benefit from Nevis Support, your installation must observe the recommendations and limitations in this section. See also [System Requirements].General

  • Meet the system requirements for the Nevis software versions and target platforms that can be managed by nevisAdmin 4. For more information, see System Requirements.
  • Various nevisAuth, nevisIDM and nevisMeta related usecases are not yet supported by the high-level standard patterns. In the GUI, add Generic patterns to configure such use cases on a component level.

Classic Deployment

When deploying from nevisAdmin 4 to VMs, observe these limitations:

  • SuSE Linux is not supported.
  • nevisAdmin 4 cannot manage plain Docker containers, that is containers started with Docker Compose.
  • nevisFIDO instance clustering is not supported that is deploying a nevisFIDO instance to a group of hosts.

Kubernetes Deployment

When deploying from nevisAdmin 4 to Kubernetes, observe these limitations:

nevisProxy:

  • Client certificate authentication does not work as the TLS termination is done by the ingress.
  • Multiple virtual hosts per nevisProxy instance (Kubernetes service) is supported through SNI. Custom bind addresses are not supported.

nevisAuth:

  • Only SQL-based out of context data store is supported.

nevisIDM:

nevisDetect:

  • Experimental support.

Zero Downtime Deployment​

  • Users of the nevisAdmin Administration GUI will lose their sessions after redeployment.
  • If using automatic key management, during redeployment, automatic certificate renewal occurs. As a result, some users may experience errors until all pods are updated to the newest certificate configuration.
  • If you deploy changes that are not backward compatible, some users may experience errors because during zero downtime deployment, old and new instances (pods) communicate freely.
  • To make sure ongoing connections are not interrupted, the old instances are kept alive until all connections are closed, which results in higher resource usage during the redeployment process. The time during which the components are kept alive will be shortened in the future.
  • Automatic nevisIDM DB schema upgrades are only supported for MariaDB, not for Oracle. Zero downtime deployment is supported in combination with manual Oracle database schema upgrades as described in the nevisIDM technical documentation, section General Upgrade Instructions.

Side-by-Side Deployment​

  • Do not change the namespace after the first deployment. This is because the primary and secondary deployments must be in the same namespace.
  • Do not use the same namespace for multiple inventories. This is because the promotion and rollback of the secondary deployment affects the whole namespace.
  • Avoid deleting the related inventory. This is because the deployment history is based on the inventory, and the side-by-side deployment depends on the deployment history. If the inventory is deleted, the history information will be lost.
  • Only Import as Existing inventoryis supported. This is because the deployment history is based on the existing inventory, and not saved in the exported inventory.