chore: add config service and update others to latest

[aaron-steinfeld]

Description

This adds the config service to hypertrace-service's collection of services, and updates other services to latest. This service is needed to support hypertrace/hypertrace#142 , and will power other config-driven features in the future.

Testing

Built this image locally and verified it in a local docker-compose deployment.

Checklist:

• [x] My changes generate no new warnings
• [ ] I have added tests that prove my fix is effective or that my feature works
• [x] Any dependent changes have been merged and published in downstream module

[kotharironak]

@JBAhire / @aaron-steinfeld I think, this change will also need the change in the architecture diagram - https://docs.hypertrace.org/arch/?

@JBAhire Do you think, we need any documentation for usage of this service in the context of HT at - https://github.com/hypertrace/config-service?

• what are the usage and kind of config users can configure?

[JBAhire]

@JBAhire / @aaron-steinfeld I think, this change will also need the change in the architecture diagram - https://docs.hypertrace.org/arch/?

@JBAhire Do you think, we need any documentation for usage of this service in the context of HT at - https://github.com/hypertrace/config-service?

* what are the usage and kind of config users can configure?

definitely, @kotharironak !

Hey @aaron-steinfeld , would you mind sending me a rough diagram for where this fits in our architecture and also RATIONALE or an issue telling why and how we are using it?

We can utilize that information to modify our architecture docs.

[kotharironak]

@JBAhire / @aaron-steinfeld I think, this change will also need the change in the architecture diagram - https://docs.hypertrace.org/arch/? @JBAhire Do you think, we need any documentation for usage of this service in the context of HT at - https://github.com/hypertrace/config-service?

* what are the usage and kind of config users can configure?

definitely, @kotharironak !

Hey @aaron-steinfeld , would you mind sending me a rough diagram for where this fits in our architecture and also RATIONALE or an issue telling why and how we are using it?

We can utilize that information to modify our architecture docs.

@JBAhire https://github.com/hypertrace/hypertrace/issues/142

[JBAhire]

@JBAhire hypertrace/hypertrace#142

Yup. that I saw. I am talking specific to why we moved config service here and how it helps Hypertrace-service as a federated service moving ahead. as we have plans to convert this to macro repo as well, that will be a good input in deciding the split for repos and versioning accordingly. Basically, some info around why this is right place for config service and how it can benefit us in future while consolidation.

Not a blocker but nice to have information in maybe same issue.

[aaron-steinfeld]

The config service addition is actually different than #142 (this is just the first usage of it). Here's a marked up arch diagram with changes (both related to this change and just missing links):

Rationale on the config service: It's a place to store configuration data such as user preferences, saved query filters, ingestion config, etc. Many of these use cases have not yet been built out. In general, this service is meant for user-managed configuration that needs to be persisted, and contains support for version history, auditing etc. In the past, we've addressed such things by spinning up individual services (such as attribute service). As new features get built out, we want to avoid that (and eventually to merge older services back into this).

This config service is designed to be a single macroservice, contained in one repo with separate modules defining different GRPC services that expose feature-specific APIs. Long term, I see our architecture having three separate logical groups - query, config and ingestion.

[JBAhire]

Thanks, @aaron-steinfeld ! This is very helpful. I will make changes in docs accordingly.