Deployment to istio ingress-gateway does not seem to work

[munjalpatel]

Describe the bug I am trying to deploy a filter directly into istio ingress-gateway but it does not seem to be working. I don't get any errors, but I also don't get updated response headers as requested in the filter.

To Reproduce

1. Create a new tinygo filter

   # select tinygo and istio options
   wasme init ./test-filter

2. Build and publish the filter

   wasme build tinygo ./test-filter-t webassemblyhub.io/company/test-filter:0.1.0
   wasme push webassemblyhub.io/company/test-filter:0.1.0

3. Deploy the filter to istio ingress gateway

   wasme deploy istio webassemblyhub.io/company/test-filter:0.1.0 --id test-filter --namespace istio-system --labels istio=ingressgateway

4. Make an HTTP request that goes through Istio ingress gateway.

Expected behavior In the response, I would expect a header with key hello and value world However, notice that the header in the response is not present.

Additional context Istio version:

client version: 1.9.1
control plane version: 1.9.1
data plane version: 1.9.1 (45 proxies)

Here is the code for the filter:

main.go

package main

import (
    "github.com/tetratelabs/proxy-wasm-go-sdk/proxywasm"
    "github.com/tetratelabs/proxy-wasm-go-sdk/proxywasm/types"
)

// Other examples can be found at https://github.com/tetratelabs/proxy-wasm-go-sdk/tree/v0.1.1/examples

func main() {
    proxywasm.SetNewRootContext(newRootContext)
}

type httpHeaders struct {
    // we must embed the default context so that you need not to reimplement all the methods by yourself
    proxywasm.DefaultHttpContext
    contextID uint32
}

type rootContext struct {
    // You'd better embed the default root context
    // so that you don't need to reimplement all the methods by yourself.
    proxywasm.DefaultRootContext
}

func newRootContext(uint32) proxywasm.RootContext { return &rootContext{} }

// Override DefaultRootContext.
func (*rootContext) NewHttpContext(contextID uint32) proxywasm.HttpContext {
    return &httpHeaders{contextID: contextID}
}

// Override DefaultHttpContext.
func (ctx *httpHeaders) OnHttpRequestHeaders(numHeaders int, endOfStream bool) types.Action {
    hs, err := proxywasm.GetHttpRequestHeaders()
    if err != nil {
        proxywasm.LogCriticalf("failed to get request headers: %v", err)
    }

    for _, h := range hs {
        proxywasm.LogInfof("request header: %s: %s", h[0], h[1])
    }
    return types.ActionContinue
}

// Override DefaultHttpContext.
func (ctx *httpHeaders) OnHttpResponseHeaders(numHeaders int, endOfStream bool) types.Action {
    if err := proxywasm.SetHttpResponseHeader("hello", "world"); err != nil {
        proxywasm.LogCriticalf("failed to set response header: %v", err)
    }
    return types.ActionContinue
}

// Override DefaultHttpContext.
func (ctx *httpHeaders) OnHttpStreamDone() {
    proxywasm.LogInfof("%d finished", ctx.contextID)
}

runtime-config.json

{
  "type": "envoy_proxy",
  "abiVersions": ["v0-4689a30309abf31aee9ae36e73d34b1bb182685f", "v0.2.1"],
  "config": {
    "rootIds": [
      "root_id"
    ]
  }
}

[kratosmat]

Hello, I have similar problem. I need to deploy a wasm filter on gateway, but I receive an error, it cannot find the file system: /var/local/lib/wasme-cache

From my understanding the sidecar is able to mount that FS thanks to these annotations: sidecar.istio.io/userVolume: '[{"hostPath":{"path":"/var/local/lib/wasme-cache"},"name":"cache-dir"}]' sidecar.istio.io/userVolumeMount: '[{"mountPath":"/var/local/lib/wasme-cache","name":"cache-dir"}]'

and it seems that the same annotations don't have the same result on the gateway.

However, by adding

volumeMounts:

• mountPath: /var/local/lib/wasme-cache name: cache-dir

and

volumes:

• hostPath: path: /var/local/lib/wasme-cache type: "" name: cache-dir

to istio ingress deployment it works.

So it seems that the annotations below doesn't add the mountpath to the pods.

I am using kube 18.3 and istio 1.7 and wasme version 0.0.33, Is it a bug?

[Sodman]

Hi @kratosmat, you are correct - the gateway needs to have the volume mounted so that it has access to the cache. Since it's not a sidecar, the istio sidecar annotations won't work here.

We'll take a look at documenting this better, as well as potential enhancements to the wasme CLI that could remove the need to add the volume mount manually.