Deploy to GitHub pages

docs/blocks-storage/index.xml

@@ -3329,15 +3329,6 @@ During the migration, this flag needs to be set to 0, to make queriers always co
 As chunks ingesters shut down, they flush chunks to the storage. They are then replaced with new ingesters configured
 to use blocks. Queriers cannot fetch recent chunks from ingesters directly (as blocks ingester don’t reload chunks),
 and need to use storage instead.</p>
-<h3 id="query-frontend">Query-frontend</h3>
-<p>Query-frontend needs to be reconfigured as follow:</p>
-<ul>
-<li><code>-querier.parallelise-shardable-queries=false</code></li>
-</ul>
-<h4 id="-querierparallelise-shardable-queriesfalse"><code>-querier.parallelise-shardable-queries=false</code></h4>
-<p>Query frontend has an option <code>-querier.parallelise-shardable-queries</code> to split some incoming queries into multiple queries based on sharding factor used in v11 schema of chunk storage.
-As the description implies, it only works when using chunks storage.
-During and after the migration to blocks (and also after possible rollback), this option needs to be disabled otherwise query-frontend will generate queries that cannot be satisfied by blocks storage.</p>
 <h3 id="compactor-and-store-gateway">Compactor and Store-gateway</h3>
 <p><a href="/docs/blocks-storage/compactor/">Compactor</a> and <a href="/docs/blocks-storage/store-gateway/">store-gateway</a> services should be deployed and successfully up and running before migrating ingesters.</p>
 <h3 id="ingester--blocks">Ingester – blocks</h3>

docs/configuration/index.xml

@@ -5204,50 +5204,15 @@ See note on <code>-querier.max-concurrent</code></p>
 </li>
 </ul>
 <h2 id="querier-and-ruler">Querier and Ruler</h2>
-<p>The ingester query API was improved over time, but defaults to the old behaviour for backwards-compatibility. For best results both of these next two flags should be set to <code>true</code>:</p>
 <ul>
 <li>
-<p><code>-querier.batch-iterators</code></p>
-<p>This uses iterators to execute query, as opposed to fully materialising the series in memory, and fetches multiple results per loop.</p>
-</li>
-<li>
-<p><code>-querier.ingester-streaming</code></p>
-<p>Use streaming RPCs to query ingester, to reduce memory pressure in the ingester.</p>
-</li>
-<li>
-<p><code>-querier.iterators</code></p>
-<p>This is similar to <code>-querier.batch-iterators</code> but less efficient.
-If both <code>iterators</code> and <code>batch-iterators</code> are <code>true</code>, <code>batch-iterators</code> will take precedence.</p>
-</li>
-<li>
 <p><code>-promql.lookback-delta</code></p>
 <p>Time since the last sample after which a time series is considered stale and ignored by expression evaluations.</p>
 </li>
 </ul>
 <h2 id="query-frontend">Query Frontend</h2>
 <ul>
 <li>
-<p><code>-querier.parallelise-shardable-queries</code></p>
-<p>If set to true, will cause the query frontend to mutate incoming queries when possible by turning <code>sum</code> operations into sharded <code>sum</code> operations. This requires a shard-compatible schema (v10+). An abridged example:
-<code>sum by (foo) (rate(bar{baz=”blip”}[1m]))</code> -></p>
-<pre tabindex="0"><code>sum by (foo) (
-sum by (foo) (rate(bar{baz=”blip”,__cortex_shard__=”0of16”}[1m])) or
-sum by (foo) (rate(bar{baz=”blip”,__cortex_shard__=”1of16”}[1m])) or
-...
-sum by (foo) (rate(bar{baz=”blip”,__cortex_shard__=”15of16”}[1m]))
-)
-</code></pre><p>When enabled, the query-frontend requires a schema config to determine how/when to shard queries, either from a file or from flags (i.e. by the <code>-schema-config-file</code> CLI flag). This is the same schema config the queriers consume.
-It’s also advised to increase downstream concurrency controls as well to account for more queries of smaller sizes:</p>
-<ul>
-<li><code>querier.max-outstanding-requests-per-tenant</code></li>
-<li><code>querier.max-query-parallelism</code></li>
-<li><code>querier.max-concurrent</code></li>
-<li><code>server.grpc-max-concurrent-streams</code> (for both query-frontends and queriers)</li>
-</ul>
-<p>Furthermore, both querier and query-frontend components require the <code>querier.query-ingesters-within</code> parameter to know when to start sharding requests (ingester queries are not sharded).</p>
-<p>Instrumentation (traces) also scale with the number of sharded queries and it’s suggested to account for increased throughput there as well (for instance via <code>JAEGER_REPORTER_MAX_QUEUE_SIZE</code>).</p>
-</li>
-<li>
 <p><code>-querier.align-querier-with-step</code></p>
 <p>If set to true, will cause the query frontend to mutate incoming queries and align their start and end parameters to the step parameter of the query. This improves the cacheability of the query results.</p>
 </li>
@@ -5749,7 +5714,6 @@ the benefits of query parallelisation and caching.</p>
 </ul>
 </li>
 <li>Memcached client DNS-based service discovery.</li>
-<li>Delete series APIs.</li>
 <li>In-memory (FIFO) and Redis cache.</li>
 <li>gRPC Store.</li>
 <li>TLS configuration in gRPC and HTTP clients.</li>
@@ -5772,12 +5736,6 @@ the benefits of query parallelisation and caching.</p>
 <li>Querier: tenant federation</li>
 <li>The thanosconvert tool for converting Thanos block metadata to Cortex</li>
 <li>HA Tracker: cleanup of old replicas from KV Store.</li>
-<li>Flags for configuring whether blocks-ingester streams samples or chunks are temporary, and will be removed on next release:
-<ul>
-<li><code>-ingester.stream-chunks-when-using-blocks</code> CLI flag</li>
-<li><code>-ingester_stream_chunks_when_using_blocks</code> (boolean) field in runtime config file</li>
-</ul>
-</li>
 <li>Instance limits in ingester and distributor</li>
 <li>Exemplar storage, currently in-memory only within the Ingester based on Prometheus exemplar storage (<code>-blocks-storage.tsdb.max-exemplars</code>)</li>
 <li>Querier limits: