很多私有化部署场景中，访问不到 higress 公开的仓库，oci 协议的使用门槛也相比文件服务器要高一些
How could it be?轻量级的场景中，higress-console 充当一个文件服务器，提供插件下载，wasmplugin 中以 http://higress-console.higress-system.svc/plugins/ai-proxy/1.0.0/plugin.wasm 的方式下载插件会方便很多
欢迎围绕这一 issue 交流，该提议是否欠妥。
这个方案不太好。console 作为治理平台，本身的可用性要求并不是很高的。即便 console 故障，gateway 本身应该是要能够正常工作的。让一个核心组件依赖一个非核心组件不是特别合理。
我的一个想法是把所有的 wasm 插件和 nginx 打到一个镜像里，用 nginx 作为静态资源服务器对外提供插件下载功能。这个镜像我们每次发布新版本的时候可以更新。用户也可以使用我们提供的 Dockerfile 来自行构建。
这里有一个问题需要验证，就是在使用 http 协议下载插件的情况下，imagePullPolicy: Always 是否仍旧可以正常工作，会不会有缓存问题。
nginx 更纯粹一点，也是很好的提议。放到 console 里面主要是因为便利性，console（springboot tomcat） 的稳定性和 nginx 的稳定性对比来看的话，感觉没有太大的差异。
wasmplugin 目前没有版本管理，如果 wasm 插件有新版本后，流水线构建除了推送公开的阿里云镜像仓库外，最好也自动将静态文件上传到一个阿里云公开可访问的 oss 中，版本 release 的时候触发镜像构建，从这个 oss 中拉取最新的文件来构建 higress-console or nginx 镜像。
nginx 更纯粹一点，也是很好的提议。放到 console 里面主要是因为便利性，console（springboot tomcat） 的稳定性和 nginx 的稳定性对比来看的话，感觉没有太大的差异。
这个对于一个 Deployment 的 HA 要求是不一样的。Console 本身是可以失效的，不影响请求。但如果 Console 承载了插件下载的功能，那就必须要保证高可用。这个是需要运维人员明确感知的，而且与一般的运维规则存在一定冲突。如果单独放一个插件服务，那么这个服务本身就可以被标记为是核心组件，要求保证 HA 的。而且 nginx 的资源占用也要比 console 小很多。
好，那就定 nginx 吧，可以下个版本作为一个可选组件供用户安装，单独一个仓库放到 higress-group 下 注意事项：
该镜像关联 wasm 静态文件的版本更新，需要跟现有流水线做一定的集成，避免镜像仓库中的插件版本不一致 （可选）wasm 插件相关 pr 合并后，是否有通知机制或者自动触发流水线构建最新 wasm 插件，目前有一定人工操作 全局配置为文件服务器加载 wasm 插件时，镜像策略优先设置为 IfNotPresent，待调研 Always 是否能正常工作 添加 SLA 说明：启用文件服务器加载 wasm 后，会改变 wasm 插件下载策略，需保证 SLA