Uploaded image for project: 'OpenShift Service Mesh'
  1. OpenShift Service Mesh
  2. OSSM-992

Improve Wasm module loading into proxies

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Won't Do
    • Icon: Major Major
    • OSSM 2.2.0
    • None
    • wasm
    • None

      Currently, when pushing Wasm filter configuration to proxies, we're sending a RemoteFetch configuration, which means that Envoy will go and fetch the Wasm module itself from the URL we're providing. The RemoteFetch is problematic though, because Envoy will just NACK the configuration the first time we send it, because it first has to download the Wasm module. By default, Istio would now get stuck until the next full push, rendering the proxy unusable. To avoid this, we implemented a workaround that looks at the reason for the NACK and retries pushing the configuration if it was a transient error (ie Envoy is still downloading the module). That is not very intelligent behaviour, but it got the job done for the tech preview.

      For GA, we'll need to revisit this. We should do what upstream does and use the proxy to intercept the RemoteFetch configuration in the istio-agent, download the Wasm module themselves, and then replace it using a LocalFile configuration, just like the WasmPlugin implementation.

      Acceptance Criteria:

      • Remove the workaround
      • Use ECDS to transmit Extension Configurations, same as for WasmPlugin

            Unassigned Unassigned
            dgrimm@redhat.com Daniel Grimm
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: