Known Issues in Lightbits 3.18.1

ID	Description
42309	In certain situations, if there is CM failover during the initial KEK rotation process (race condition), the new CM may not be able to become active. This means that many APIs will fail. The data path will still work as long as all nodes are healthy.
41873	Under a specific race condition, if a snapshot is created while a node is down and then deleted during the node’s startup at a very precise timing, the node could become unavailable.
41466	Creating a snapshot with a retention time that exceeds 192 years will fail, and a restart of the api-service.
41095	The `NodeRebuildNotPossible` alert is not triggered as expected.
40883	In the specific case of using VCP to upgrade a cluster, the upgrade to Lightbits version 3.17.1 or higher will fail because VCP cannot parse the new version format. To successfully upgrade the cluster, use the Lightbits core CLI or REST API directly.
40428	In extremely rare cases, the reported logical size of a volume could be incorrect after a discard operation is performed and TRIM support was enabled.
40348	ETCD alerts were not raised as required. The reference ETCD alerts configuration file for Prometheus had an error that prevented alerts from being raised as required.
38826	In-Band Authentication: When setting the trusted-host-secret command for In-Band Authentication, ensure that the specified host/target secret is in the proper format. The command could accept a secret that is not in a proper format, but this will result in a subsequent authentication failure.
38497	When creating a new server to replace another server in the cluster using the --extend-cluster=false flag (which is the default setting), and at a much later time this server and its node experience a permanent failure and fail in place is enabled (causing the servers resources to be migrated), if the server goes active again it might not participate in all proper distribution of replicas over the cluster and could cause an imbalance of resources.
37830	In a very rare case, a node could fail to recover and return to an active state if an I/O error or bad block is encountered on an underlying SSD during its startup sequence. This issue prevents a key service (gftl) from initializing correctly and could require manual intervention - such as the removal of the failed SSD from the system - to allow the node to successfully complete its recovery.
37544	In a rare scenario, the discovery-client service could stop if network connectivity to the cluster is disrupted at the same time as multiple volume changes are generating notifications. The service is designed to restart automatically after such an event, and no manual intervention is required.
37505	In a rare combination of events, the '`physicalOwnedCapacity`' volume statistic could report an incorrect value if data at a specific LBA is overwritten with content that has a different compression ratio. In this scenario, the updated length of the overwritten data is not correctly accounted for in the statistic.
33865	In certain cases when migrating volumes during dynamic rebalancing, a `VolumeInDegradedProtectionState`event could be sent out when the volume is actually fully protected.
28027	A server upgrade status will not update in the following sequence: A server is upgraded to release x.y.z. The operation fails (i.e., times out); however, binaries on the server are updated to version x.y.z. At a later time, the upgrade is attempted again to version x.y.z (this operation is skipped internally, as binaries have already been updated). The upgrade status will continue to show the failed upgrade operation, even though the last upgrade returned with no error.

Last updated on

Was this page helpful?