When API server is initializing, it creates some global default resources if not exists like the global system config named 'default-global-system-config'. For that it looks if the resource was already initialized by fetching fq_name/uuid mapping from the cassandra 'obj_fq_name_table' table of the keyspace 'config_db_uuid'. But here, it seems you have a duplicate entry in that table for key 'global_system_config' and column start with 'default-global-system-config:'
You probably had a concurrent issue when the cluster was bootstrapped, where several API servers initialized global default resources in a mean time. Do you met that issue several times?
@Sachin: I can propose a patch to only make the DB init from the master API server (worker_id = 0) and put slave API servers in waiting state until a resource/event happen (it remains to determine what can provoke that?)
When API server is initializing, it creates some global default resources if not exists like the global system config named 'default- global- system- config' . For that it looks if the resource was already initialized by fetching fq_name/uuid mapping from the cassandra 'obj_fq_name_table' table of the keyspace 'config_db_uuid'. But here, it seems you have a duplicate entry in that table for key 'global_ system_ config' and column start with 'default- global- system- config: '
You probably had a concurrent issue when the cluster was bootstrapped, where several API servers initialized global default resources in a mean time. Do you met that issue several times?
@Sachin: I can propose a patch to only make the DB init from the master API server (worker_id = 0) and put slave API servers in waiting state until a resource/event happen (it remains to determine what can provoke that?)