Thanks for that!

Private front-ends are on our roadmap. We can't provide an ETA at this time

This is in the works. I don't have any details on timing, but we will share on this channel as soon as we have a good idea

Please note that OSM has been archived by it's maintainers. openservicemesh.io/blog/osm-project-update We suggest following this guidance to move to the Istio add-on. learn.microsoft.com/en-us/azure/aks/open-service-mesh-istio-migration-guidance We would love to know if there are any obstacles or missing features that would prevent you from moving forward.

@@theakscommunity thanks a lot means osm is legacy now and istio is new solution do you know in AKS which one I should go

@@amitverma7545 We recommend the Istio Add-on for AKS. It's a managed offering, so we take care of the Istio control plane for you.

You have to go through Azure Policy to create your own policies that sync to Gatekeeper on the cluster. learn.microsoft.com/en-us/azure/aks/use-azure-policy#create-and-assign-a-custom-policy-definition

It's not supported in Gov Cloud today,, but it is in our plans. No ETA at this time, but we will be sure to share when we know more

Thanks for the question. AGC has been completely redesigned from the ground up to improve the performance of both the data plane and control plane. The video demonstrates the performance improvements for the control plane. A quick performance test against the frontend will yield improved results for the data plane as well. Please let us know how us that performing for you.

Sounds good. Please let us know how it goes.

The cluster management behavior shown in this video is GA yes. The dataplane part to place workload on member clusters via the hub's apiserver will GA shortly.

Hey @GK-rl5du, thanks for comment & great questions. I'll do my best to answer and let Yosh correct me if I'm off base. 1. Your understanding matches mine. I've been thinking about WASI as an API. And that API defines the interactions between WebAssembly modules and the host system. Much like syscalls do for the container runetimes like ContainerD. An interesting next step would be to dive into the component model. 2. Capabilities are indeed how the wasm module gets access to the host resources and without those it cannot reach the host. From what I've read and heard it’s supposed to be "sandboxed" but idk what's meant by that. I don't yet understand how the isolation is achieved and if the capability creates an isolated instance of the network interface, for example, or if it's shared. Or if even with an isolated instance if it'd be possible to tap other network interfaces. I'll dig into this and ask ppl smarter on the subject than myself and report back. :)

So, I just spoke with Yosh and here's what I learned. The implementation largely depends on the runtime and how it provides the "API" for the capability. But, all things considered it's isolated by the memory on the host machine that the wasm process is running. And all the data sent and received is locked into that address space. In theory, that shouldn't allow any cross contamination for a lack of a better work. However, that's where hyperlight comes in as a runtime and provides vm level isolation at the process level to ensure isolation.

@@joshduffney7954 thanks for all your efforts Josh 🙂 it's beginning to make sense to me. So, without capabilities based security from runtime and additional help from tech like Hyperlight, a wasm module is similar to an OS process (in terms of isolation/security)? My reasoning is, a vanilla OS process is also memory isolated from other OS processes due to the virtue of Virtual Memory. I'll do my own homework too to understand this better. But this is an interesting tech for sure 😊

Hey @joebuydem, thanks watching and subscribing. Glad to hear you found value in the conversation. More Wasm content is in the near future! :)

Thank you. We will build up the live audience over time, but we're just getting started!