When configuring the content delivery micro-services (for example, the Content service) you have to specify a ConfigRepository element which provides information for locating and authenticating with the discovery service of the relevant environment.

I can see why the topology manager needs to find the discovery service and log in to it: otherwise publishing wouldn't be possible.

Obviously, discovery registration needs this information, but it is my understanding that discovery registration is a separate activity from actually running the services.

So why does (for example) the content service need to find the discovery service, and what problems would we see if this does not happen correctly?


The Discovery Service also acts a a centralized configuration repository for some of the other microservices (hence the term ConfigRepository in the configuration). As such, the Discovery service acts as the hub between Topology Manager and all the CD microservices.

In particular, the Content Service gets Publication URL mapping information out of the Discovery Service (to do URL resolving) instead of getting it from config files (cd_dynamic_conf.xml and cd_link_conf.xml).

So: the ConfigRepository element is actually very important for the Content Service.

One might wonder (I do :-) why the Discovery Service needs a reference to itself, but I guess that's for the registration tool.

  • Thanks Rick. Is it only the content service, or do other services also need this? And if you ran the discovery registration from a different service, would that mean that the discovery service wouldn't need ConfigRepository? – Dominic Cronin Apr 20 '16 at 9:08
  • I think that currently only the (Session-enabled) Content Service uses the Discovery Service as config repository. And I think that the registration tool must be run using the Discovery Service's cd_storage_conf.xml, because the Capabilities are defined there; I think the Discovery Service itself doesn't use it, indeed. – Rick Pannekoek Apr 22 '16 at 8:59
  • Hi Rick. Thanks for the really useful answer. If we are using legacy publishing (rather than Topology Manager configuration), can we configure the Discovery Service and/or the Content Service to get the Publication URL mapping information from the cd_dynamic_conf.xml and (or?) the cd_link_conf.xml files, so that we don't have to do anything with Topology Manager (i.e. So we don't have to configure Content Delivery Environments or Web Sites or Web Applications)? – Jonathan Williams Mar 8 '17 at 21:57
  • Yes, I think you can (although legacy publishing is typically combined with legacy, in-process CD APIs). cd_link_conf.xml is configured to ignore Discovery Service OOTB (so you get relative link URLs). AFAIK, the Content Service falls back to cd_dynamic_conf.xml if the ConfigRepository is not specified. – Rick Pannekoek Mar 9 '17 at 7:26

The ConfigReposotory only needs to be defined in the cd_storage_conf.xml file of the Discovery Service.

In the other microservices, it doesn't need to be defined. And the Content Service, as you said, doesn't need to know where the discovery service must be, because is the discovery service that has to know where all the microservices are, to manage the connections between applications and microservices.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.