Charm statuses

A deployed charm follows standard Juju applications statuses. Here you can find the expected reactions on many typical Charmed Apache Kafka statuses:

Juju Status	Message	Expectations	Actions
Active		Normal charm operations	No actions required
Active	manual partition reassignment may be needed to utilise new storage volumes	Existing data is not automatically rebalanced when new storage is attached. New storage will be used for newly created topics and/or partitions	Inspect the storage utilisation and based on the need, and rebalance data across multiple storages/brokers
Active	potential data loss due to storage removal without replication	Some partition/topics are not replicated on multiple storages, therefore potentially leading to data loss	Add new storage, increase replication of topics/partitions and/or rebalance data across multiple storages/brokers
Active	machine system settings are not optimal - see logs for info	The broker is running on a machine that has sub-optimal OS settings. Although this may not preclude Apache Kafka to work, it may result in sub-optimal performances	Check the juju debug-log for insights on which settings are sub-optimal and may be changed
Active	sysctl parameters cannot be set. Is the machine running on a container?	Some of the sysctl settings required by Apache Kafka could not be set, therefore affecting Apache Kafka performance and correct settings. This can also be due to the charm being deployed on the wrong substrate	Remove the deployment and make sure that the selected charm is correct given the Juju cloud substrate
Blocked	unable to install charmed-kafka snap	There are issues with the network connection and/or the snap Store	Check your internet connection and Snapcraft.io status. Remove the application and when everything is OK, deploy the charm again
Blocked	service not running	The charm failed to start the Apache Kafka snap daemon processes	Check the Apache Kafka logs for insights on the issue
Blocked	Cruise Control not running	The charm failed to start the Cruise Control snap daemon process	Check the Cruise Control logs for insights on the issue
Blocked	unit not connected to the controller	The Apache Kafka broker unit is unable to authenticate to the KRaft controllers	May self-resolve after 5-15m. Otherwise, check the Apache Kafka logs for insights on the issue
Blocked	application needs to be related with a KRaft controller	The Apache Kafka brokers do not information on where KRaft controller to connect to is	Ensure that there is an active relation between the broker and KRaft controllers, or that the broker application has configuration roles=broker,controller
Blocked	can’t setup mTLS client without a TLS relation first	The units do not have the necessary client keystore and truststore to trust provided mTLS certificates	Ensure that there is an active certificates relation with a tls-certificates relation interface provider application
Blocked	mTLS client’s certificate is not a valid leaf certificate	The certificate provided in a kafka_client relation across the mtls-cert relation data field is not a valid certificate	Ensure that the client application is sending a valid certificate, and not a CA
Waiting	internal broker credentials not yet added	Intrabroker credentials being created to enable communication and syncing among brokers belonging to the Apache Kafka clusters.
Waiting	unit waiting for signed certificates	Unit has requested a CSR request via the certificates relation and it is waiting to receive the signed certificate
Blocked	missing broker data	The KRaft controller or Cruise Control rebalancer does not have sufficient Apache Kafka broker data to make a valid connection	Ensure that KRaft controller and/or Cruise Control rebalancer applications are related to a Apache Kafka broker application
Waiting	waiting for 3 online brokers	The Cruise Control rebalancer application is not provided with the minimum number of brokers’ data - 3	Ensure that the Apache Kafka broker application has at least 3 units. Less than 3 units will result in Cruise Control not functioning
Waiting	awaiting completion of rebalance task	The Cruise Control rebalancer application is currently running a rebalance task, and is busy
Maintenance		Charm is performing the internal maintenance (e.g. cluster re-configuration, upgrade, …)	No actions required
Error	any	An unhandled internal error happened	Read the message hint. Execute juju resolve <error_unit/0> after addressing the root of the error state
Terminated	any	The unit is gone and will be cleaned by Juju soon	No actions possible
Unknown	any	Juju doesn’t know the charm app/unit status. Possible reason: K8s charm termination in progress.	Manual investigation required if status is permanent