In the Amsterdam release, DCAE components were deployed on VMs or as Docker containers running on (non-Kubernetes) Docker hosts.   DCAE components used Consul as a service discovery mechanism to locate each other.   In the Beijing release, DCAE moved to a Kubernetes-based deployment.  In Kubernetes, the Consul-based service discovery is not needed–simple lookups in the Kubernetes DNS are sufficient.  In order to minimize the changes needed to move to Kubernetes, however, DCAE continued to support Consul-based service lookup by setting up service registrations in Consul for key DCAE components, such as the config binding service.    Components that were written for the Docker environment could continue to use lookups in Consul.

After 4 releases, it is time to move away from Consul service discovery.  In the El Alto release, the Python and Java client libraries were modified to use Kubernetes DNS lookups instead of Consul lookups to locate the config binding services.  Components that use these libraries can update to the latest versions.  Components that directly call Consul will need to be modified.  The DCAE bootstrap process will no longer launch a Consul agent and will no longer create service registrations for DCAE components.

Note that this change affects Consul service discovery only.  It does not change how DCAE uses the Consul key-value store for component configurations.