Skip to content

Commit

Permalink
update_ref_docs fails on an arm machine
Browse files Browse the repository at this point in the history
  • Loading branch information
Eric Van Norman committed Sep 5, 2023
1 parent 867381b commit 5970319
Show file tree
Hide file tree
Showing 23 changed files with 28,476 additions and 197 deletions.
1,569 changes: 1,569 additions & 0 deletions content/en/docs/reference/commands/install-cni/index.html

Large diffs are not rendered by default.

7,459 changes: 7,459 additions & 0 deletions content/en/docs/reference/commands/istioctl/index.html

Large diffs are not rendered by default.

1,263 changes: 1,263 additions & 0 deletions content/en/docs/reference/commands/operator/index.html

Large diffs are not rendered by default.

2,267 changes: 2,267 additions & 0 deletions content/en/docs/reference/commands/pilot-agent/index.html

Large diffs are not rendered by default.

1,485 changes: 1,485 additions & 0 deletions content/en/docs/reference/commands/pilot-discovery/index.html

Large diffs are not rendered by default.

91 changes: 69 additions & 22 deletions content/en/docs/reference/config/istio.mesh.v1alpha1/index.html
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@
layout: protoc-gen-docs
generator: protoc-gen-docs
weight: 20
number_of_entries: 64
number_of_entries: 66
---
<p>Configuration affecting the service mesh as a whole.</p>

Expand Down Expand Up @@ -67,26 +67,6 @@ <h2 id="MeshConfig">MeshConfig</h2>
<p>Connection timeout used by Envoy. (MUST BE &gt;=1ms)
Default timeout is 10s.</p>

</td>
<td>
No
</td>
</tr>
<tr id="MeshConfig-protocol_detection_timeout">
<td><code>protocolDetectionTimeout</code></td>
<td><code><a href="https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#duration">Duration</a></code></td>
<td>
<p>Automatic protocol detection uses a set of heuristics to
determine whether the connection is using TLS or not (on the
server side), as well as the application protocol being used
(e.g., http vs tcp). These heuristics rely on the client sending
the first bits of data. For server first protocols like MySQL,
MongoDB, etc. Envoy will timeout on the protocol detection after
the specified period, defaulting to non mTLS plain TCP
traffic. Set this field to tweak the period that Envoy will wait
for the client to send the first bits of data. (MUST BE &gt;=1ms or
0s to disable). Default detection timeout is 0s (no timeout).</p>

</td>
<td>
No
Expand Down Expand Up @@ -3152,6 +3132,8 @@ <h2 id="ProxyConfig">ProxyConfig</h2>
disabled: true
envoyDebugHeaders:
disabled: true
metadataExchangeHeaders:
mode: IN_MESH
</code></pre>

</td>
Expand Down Expand Up @@ -3548,6 +3530,19 @@ <h2 id="ProxyConfig-ProxyHeaders">ProxyConfig.ProxyHeaders</h2>
See the <a href="https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/router/v3/router.proto#envoy-v3-api-field-extensions-filters-http-router-v3-router-suppress-envoy-headers">Envoy documentation</a> for more details.
These headers are enabled by default if not configured.</p>

</td>
<td>
No
</td>
</tr>
<tr id="ProxyConfig-ProxyHeaders-metadata_exchange_headers">
<td><code>metadataExchangeHeaders</code></td>
<td><code><a href="#ProxyConfig-ProxyHeaders-MetadataExchangeHeaders">MetadataExchangeHeaders</a></code></td>
<td>
<p>Controls Istio metadata exchange headers <code>X-Envoy-Peer-Metadata</code> and <code>X-Envoy-Peer-Metadata-Id</code>.
By default, the behavior is unspecified.
If IN_MESH, these headers will not be appended to outbound requests from sidecars to services not in-mesh.</p>

</td>
<td>
No
Expand Down Expand Up @@ -3663,6 +3658,30 @@ <h2 id="ProxyConfig-ProxyHeaders-EnvoyDebugHeaders">ProxyConfig.ProxyHeaders.Env
</tbody>
</table>
</section>
<h2 id="ProxyConfig-ProxyHeaders-MetadataExchangeHeaders">ProxyConfig.ProxyHeaders.MetadataExchangeHeaders</h2>
<section>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
<th>Required</th>
</tr>
</thead>
<tbody>
<tr id="ProxyConfig-ProxyHeaders-MetadataExchangeHeaders-mode">
<td><code>mode</code></td>
<td><code><a href="#ProxyConfig-ProxyHeaders-MetadataExchangeMode">MetadataExchangeMode</a></code></td>
<td>
</td>
<td>
No
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="Network">Network</h2>
<section>
<p>Network provides information about the endpoints in a routable L3
Expand Down Expand Up @@ -4227,6 +4246,34 @@ <h2 id="Tracing-OpenCensusAgent-TraceContext">Tracing.OpenCensusAgent.TraceConte
<a href="https://github.com/openzipkin/b3-propagation">B3 header propagation README</a>
for details.</p>

</td>
</tr>
</tbody>
</table>
</section>
<h2 id="ProxyConfig-ProxyHeaders-MetadataExchangeMode">ProxyConfig.ProxyHeaders.MetadataExchangeMode</h2>
<section>
<table class="enum-values">
<thead>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="ProxyConfig-ProxyHeaders-MetadataExchangeMode-UNDEFINED">
<td><code>UNDEFINED</code></td>
<td>
<p>Existing Istio behavior for the metadata exchange headers is unchanged.</p>

</td>
</tr>
<tr id="ProxyConfig-ProxyHeaders-MetadataExchangeMode-IN_MESH">
<td><code>IN_MESH</code></td>
<td>
<p>Only append the istio metadata exchange headers for services considered in-mesh.
Traffic is considered in-mesh if it is secured with Istio mutual TLS. This means that <code>MESH_EXTERNAL</code> services, unmatched passthrough traffic, and requests to workloads without Istio enabled will be considered out of mesh.</p>

</td>
</tr>
</tbody>
Expand Down Expand Up @@ -4289,7 +4336,7 @@ <h2 id="ProxyConfig-InboundInterceptionMode">ProxyConfig.InboundInterceptionMode
<td><code>REDIRECT</code></td>
<td>
<p>The <code>REDIRECT</code> mode uses iptables <code>REDIRECT</code> to <code>NAT</code> and redirect to Envoy. This mode loses
source IP addresses during redirection.</p>
source IP addresses during redirection. This is the default redirection mode.</p>

</td>
</tr>
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@
generator: protoc-gen-docs
schema: istio.networking.v1alpha3.VirtualService
aliases: [/docs/reference/config/networking/v1alpha3/virtual-service]
number_of_entries: 28
number_of_entries: 29
---
<p>Configuration affecting traffic routing. Here are a few terms useful to define
in the context of traffic routing.</p>
Expand Down Expand Up @@ -729,6 +729,22 @@ <h2 id="HTTPRoute">HTTPRoute</h2>
original destination. Statistics will be generated for the mirrored
destination.</p>

</td>
<td>
No
</td>
</tr>
<tr id="HTTPRoute-mirrors">
<td><code>mirrors</code></td>
<td><code><a href="#HTTPMirrorPolicy">HTTPMirrorPolicy[]</a></code></td>
<td>
<p>Specifies the destinations to mirror HTTP traffic in addition
to the original destination. Mirrored traffic is on a
best effort basis where the sidecar/gateway will not wait for the
mirrored destinations to respond before returning the response from the
original destination. Statistics will be generated for the mirrored
destination.</p>

</td>
<td>
No
Expand Down Expand Up @@ -2495,7 +2511,8 @@ <h2 id="HTTPRetry">HTTPRetry</h2>
between retries will be determined automatically (25ms+). When request
<code>timeout</code> of the <a href="/docs/reference/config/networking/virtual-service/#HTTPRoute">HTTP route</a>
or <code>per_try_timeout</code> is configured, the actual number of retries attempted also depends on
the specified request <code>timeout</code> and <code>per_try_timeout</code> values.</p>
the specified request <code>timeout</code> and <code>per_try_timeout</code> values. MUST BE &gt;= 0. If <code>0</code>, retries will be disabled.
The maximum possible number of requests made will be 1 + <code>attempts</code>.</p>

</td>
<td>
Expand Down Expand Up @@ -2734,6 +2751,52 @@ <h2 id="HTTPFaultInjection">HTTPFaultInjection</h2>
<p>Abort Http request attempts and return error codes back to downstream
service, giving the impression that the upstream service is faulty.</p>

</td>
<td>
No
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="HTTPMirrorPolicy">HTTPMirrorPolicy</h2>
<section>
<p>HTTPMirrorPolicy can be used to specify the destinations to mirror HTTP traffic in addition
to the original destination. Mirrored traffic is on a
best effort basis where the sidecar/gateway will not wait for the
mirrored destinations to respond before returning the response from the
original destination. Statistics will be generated for the mirrored
destination.</p>

<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
<th>Required</th>
</tr>
</thead>
<tbody>
<tr id="HTTPMirrorPolicy-destination">
<td><code>destination</code></td>
<td><code><a href="#Destination">Destination</a></code></td>
<td>
<p>Destination specifies the target of the mirror operation.</p>

</td>
<td>
Yes
</td>
</tr>
<tr id="HTTPMirrorPolicy-percentage">
<td><code>percentage</code></td>
<td><code><a href="#Percent">Percent</a></code></td>
<td>
<p>Percentage of the traffic to be mirrored by the <code>destination</code> field.
If this field is absent, all the traffic (100%) will be mirrored.
Max value is 100.</p>

</td>
<td>
No
Expand Down

This file was deleted.

Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@
generator: protoc-gen-docs
schema: istio.extensions.v1alpha1.WasmPlugin
aliases: [/docs/reference/config/extensions/v1alpha1/wasm-plugin]
number_of_entries: 8
number_of_entries: 9
---
<p>WasmPlugins provides a mechanism to extend the functionality provided by
the Istio proxy through WebAssembly filters.</p>
Expand Down Expand Up @@ -342,6 +342,17 @@ <h2 id="WasmPlugin">WasmPlugin</h2>
If a traffic satisfies any of TrafficSelectors,
the traffic passes the WasmPlugin.</p>

</td>
<td>
No
</td>
</tr>
<tr id="WasmPlugin-type">
<td><code>type</code></td>
<td><code><a href="#PluginType">PluginType</a></code></td>
<td>
<p>Specifies the type of Wasm Extension to be used.</p>

</td>
<td>
No
Expand Down Expand Up @@ -478,6 +489,50 @@ <h2 id="WasmPlugin-TrafficSelector">WasmPlugin.TrafficSelector</h2>
</td>
<td>
No
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="PluginType">PluginType</h2>
<section>
<p>PluginType indicates the type of Wasm Extension to be used.
There are two types of Extensions: <code>HTTP</code> and <code>NETWORK</code>.
HTTP Extension work at &ldquo;Layer 7&rdquo;(for example as an HTTP filters in Envoy).
The detailed HTTP interface for can be found at [C++] (<a href="https://github.com/proxy-wasm/proxy-wasm-cpp-host/blob/b7e690703c7f26707438a2f1ebd7c197bc8f0296/include/proxy-wasm/context_interface.h#L199">https://github.com/proxy-wasm/proxy-wasm-cpp-host/blob/b7e690703c7f26707438a2f1ebd7c197bc8f0296/include/proxy-wasm/context_interface.h#L199</a>)
and [Rust] (<a href="https://github.com/proxy-wasm/proxy-wasm-rust-sdk/blob/6b47aec926bc29971c727471d6f4c972ec407c7f/src/traits.rs#L309)">https://github.com/proxy-wasm/proxy-wasm-rust-sdk/blob/6b47aec926bc29971c727471d6f4c972ec407c7f/src/traits.rs#L309)</a>.
NETWORK Extension work at &ldquo;Layer 4&rdquo;(for example, as a network filter in Envoy).
The detailed NETWORK interface for can be found at [C++] (<a href="https://github.com/proxy-wasm/proxy-wasm-cpp-host/blob/b7e690703c7f26707438a2f1ebd7c197bc8f0296/include/proxy-wasm/context_interface.h#L257">https://github.com/proxy-wasm/proxy-wasm-cpp-host/blob/b7e690703c7f26707438a2f1ebd7c197bc8f0296/include/proxy-wasm/context_interface.h#L257</a>)
and [Rust] (<a href="https://github.com/proxy-wasm/proxy-wasm-rust-sdk/blob/6b47aec926bc29971c727471d6f4c972ec407c7f/src/traits.rs#L257)">https://github.com/proxy-wasm/proxy-wasm-rust-sdk/blob/6b47aec926bc29971c727471d6f4c972ec407c7f/src/traits.rs#L257)</a>.
The NETWORK Extension can be applied to HTTP traffic as well.</p>

<table class="enum-values">
<thead>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="PluginType-UNSPECIFIED_PLUGIN_TYPE">
<td><code>UNSPECIFIED_PLUGIN_TYPE</code></td>
<td>
<p>Defaults to HTTP.</p>

</td>
</tr>
<tr id="PluginType-HTTP">
<td><code>HTTP</code></td>
<td>
<p>Use HTTP Wasm Extension.</p>

</td>
</tr>
<tr id="PluginType-NETWORK">
<td><code>NETWORK</code></td>
<td>
<p>Use Network Wasm Extension.</p>

</td>
</tr>
</tbody>
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -266,8 +266,10 @@ <h2 id="RequestAuthentication">RequestAuthentication</h2>
is now supported. A prefix &lsquo;@&rsquo; is used to denote a match against internal metadata instead of the headers in the request.
Currently this feature is only supported for the following metadata:</p>
<ul>
<li><code>request.auth.claims.{claim-name}[.{sub-claim}]*</code> which are extracted from validated JWT tokens. The claim name
currently does not support the <code>.</code> character. Examples: <code>request.auth.claims.sub</code> and <code>request.auth.claims.name.givenName</code>.</li>
<li><code>request.auth.claims.{claim-name}[.{nested-claim}]*</code> which are extracted from validated JWT tokens.
Use the <code>.</code> or <code>[]</code> as a separator for nested claim names.
Examples: <code>request.auth.claims.sub</code>, <code>request.auth.claims.name.givenName</code> and <code>request.auth.claims[foo.com/name]</code>.
For more information, see <a href="/docs/tasks/security/authentication/jwt-route/">JWT claim based routing</a>.</li>
</ul>
<p>The use of matches against JWT claim metadata is only supported in Gateways. The following example shows:</p>
<ul>
Expand Down
Loading

0 comments on commit 5970319

Please sign in to comment.