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.