Today, the contrail-analytics services get the user configuration from contrail-api through REST interface. This spec provides details about the new scheme, where the analytics services would read the user configuration directly from the config database (cassandra).
Today, the contrail-analytics services periodically poll the user configuration from the contrail-api through REST interface. This scheme has the following limitations.
- Analytics services do not react immediately to the user configuration changes and the delay depends on the poll duration.
- The analytics service reads all the user configuration it is interested in during every poll interval and compares with its local data store to identify the CREATE, UPDATE and DELETE operations. This could be an expensive operation depending on the number of config objects.
- Periodic polling of user configuration may increase the load on the contrail-api service.
Upon start, the analytics service would read the configuration from config database (cassandra) and listen for configuration notifications (CREATE, UPDATE, DELETE) from Rabbitmq message bus.
None
None
None
None
None
Analytics python services will reuse the following classes/modules in cfgm_common package.
- class VncAmqpHandle defined in vnc_amqp.py to connect to RabbitMq server and receive/handle config notifications.
- class VncObjectDBClient defined in vnc_object_db.py to connect to Cassandra.
- class DBBase defined in vnc_db.py - Base class for all config objects.
Analytics C++ services will reuse most the existing implementation for control-node.
Please refer to Control node config from cassandra - Implementation
The new scheme (push) will have better performance and scale over the existing scheme (pull) for handling the config changes in the Analytics daemons.
None
Deprecate [API_SERVER] section in the config section for the following Analytics services.
- contrail-collector
- contrail-alarm-gen
- contrail-snmp-collector
- contrail-topology
None
TBD
None