docs/proposals/210701_endpoint_discovery.md: Add initial proposal

Signed-off-by: Lili Cosic <cosiclili@gmail.com>

docs/proposals/210701_endpoint_discovery.md

@@ -0,0 +1,44 @@
+---
+title: Unified Endpoint discovery
+type: proposal
+menu: proposals
+status: XXX
+---
+
+### Related Tickets
+
+* https://github.com/thanos-io/thanos/issues/2600
+
+### Summary
+
+We want to propose a new flag called `--endpoint=<address>` that will be passed to Thanos query and replace the current `--store=<address>` and `--rule=<address>` flags, and add a discovery mechanism which will be used to determine what types of services this endpoint can serve.
+
+### Motivation
+
+Currently, in Thanos Query, the discovery of rules APIs happens via Store API's Info method, this makes it harder if we ever want to not have a coupling to the Store API (which is already planned for [scalable ruler proposal](https://github.com/thanos-io/thanos/blob/master/docs/proposals/202005_scalable-rule-storage.md)).
+
+We also require passing two different flags to the Thanos Query component `--store=<address>` and `--rule=<address>` and perform DNS discovery on often the same address multiple times, this can cause occasional DNS issues. Which is especially confusing when one works and the other doesn't.
+
+### Goals
+
+Unite discovery of endpoints, which would make code cleaner as well as provide building blocks to provide discover and support for new gRPC services, for example, the Targets API/Exemplar API/Metadata API.
+
+### Solution
+
+Add a new flag called `--endpoint` to Thanos query, and auto-discover what services that endpoint is serving based on metadata each gRPC server exposes.
+
+The plan would be for the initial discovery of gRPC services available to happen via gRPC reflection. To get further information, we would be adding an Info method to the Rules API. This would contain similar info or metadata information as we get right now from the Store Info method. Potentially in the future, we would implement this same Info method for other services in the, for example, the Targets, Examplers, etc. As mentioned the discovery would happen via reflection initially, the Info method in the Rules API would expose extra metadata about external labels for now, and we can always add more data to it in the future as needed.
+
+The upgrade path would be possible in this case, as it's strictly additive for endpoints, and therefore in theory users would need to just upgrade in the correct order, with Thanos Query component being the last to be upgraded.
+
+#### Alternatives
+
+Split Info method out of the Store API into a separate gRPC service called `info`. Each component must implement and expose this. The discovery would happen via this info gRPC service, which each component would need to explicitly state which API it supports. Besides that information, we would also need to include here various info, e.g. LabelSets, Max/Min time, etc. The drawback for this solution is harder upgrades as this would be more complex to implement as we would need to fall back to older APIs.
+
+### Work plan
+
+Start by deprecating the `--store=<address> --rule=<address>` and replace with `--endpoint=<address>` in the Thanos Query component itself and perform discovery in the Thanos Query component.
+
+### Questions to answer
+
+1. What guarantees do we give to the users, when migrating between versions? Can we just remove flags or do we need to fallback to existing ones?