Promote/ruler api (#4132)

* unmark the ruler api as experimental

* deprecation notice for experimental prefix

* removes vendor changes, adds -ruler.enable-api (without experimental prefix) on our ruler.Config

docs/sources/configuration/_index.md

@@ -372,7 +372,6 @@ results_cache:
 
 The `ruler_config` configures the Loki ruler.
 
-<span style="background-color:#f3f973;">The Ruler API is experimental.</span>
 
 ```yaml
 # URL of alerts return path.
@@ -753,7 +752,7 @@ ring:
 [flush_period: <duration> | default = 1m]
 
 # Enable the Ruler API.
-# CLI flag: -experimental.ruler.enable-api
+# CLI flag: -ruler.enable-api
 [enable_api: <boolean> | default = false]
 ```
 

docs/sources/rules/_index.md

@@ -255,7 +255,7 @@ jobs:
 
 One option to scale the Ruler is by scaling it horizontally. However, with multiple Ruler instances running they will need to coordinate to determine which instance will evaluate which rule. Similar to the ingesters, the Rulers establish a hash ring to divide up the responsibilities of evaluating rules.
 
-The possible configurations are listed fully in the [configuration documentation](https://grafana.com/docs/loki/latest/configuration/), but in order to shard rules across multiple Rulers, the rules API must be enabled via flag (`-experimental.Ruler.enable-api`) or config file parameter. Secondly, the Ruler requires it's own ring be configured. From there the Rulers will shard and handle the division of rules automatically. Unlike ingesters, Rulers do not hand over responsibility: all rules are re-sharded randomly every time a Ruler is added to or removed from the ring.
+The possible configurations are listed fully in the [configuration documentation](https://grafana.com/docs/loki/latest/configuration/), but in order to shard rules across multiple Rulers, the rules API must be enabled via flag (`-ruler.enable-api`) or config file parameter. Secondly, the Ruler requires it's own ring be configured. From there the Rulers will shard and handle the division of rules automatically. Unlike ingesters, Rulers do not hand over responsibility: all rules are re-sharded randomly every time a Ruler is added to or removed from the ring.
 
 A full sharding-enabled Ruler example is:
 

pkg/ruler/config.go

@@ -18,6 +18,9 @@ type Config struct {
 func (c *Config) RegisterFlags(f *flag.FlagSet) {
 	c.Config.RegisterFlags(f)
 	c.RemoteWrite.RegisterFlags(f)
+
+	// TODO(owen-d, 3.0.0): remove deprecated experimental prefix in Cortex if they'll accept it.
+	f.BoolVar(&c.Config.EnableAPI, "ruler.enable-api", false, "Enable the ruler api")
 }
 
 // Validate overrides the embedded cortex variant which expects a cortex limits struct. Instead copy the relevant bits over.