 Hey, Josh, thanks for joining. You're at the Google Next event, and Google just announced K-Native. I think it's really interesting. It seems to be some kind of a serverless framework on Kubernetes. What do you make of it? Yeah, I think it's really interesting. It attempts to provide a serverless framework based upon Kubernetes primitives, and this provides a relatively undone solution all the way from how to get your code into containers, how to then deploy them, and offer a serverless or a scale to zero approach, where traditionally in Kubernetes, you could use things like horizontal pod auto scalers to scale your resources up and down, but getting them to zero from one and then back from zero to one without dropping requests and things like that is where a lot of magic happens here, but trying to help that happen. So this is a great way to achieve it. Do you think it's also usable with things like Rails, or is it really for the pure serverless functions? I think it's an interesting question, but I think we'll need to explore a little bit further. I think in general, I don't think it should be a problem with something like Rails. I think it uses Istio for some of the management and service mapping and then some of the eventing, but I think hopefully as long as a request can come in, it can start up a container. The container can hopefully start in the reasonable amount of time. That's probably the biggest challenge with Rails, is that for GitLab, for example, it can take a minute or two to get the Rails, mine all up and running, and so that might be the biggest challenge for Rails in fact, it's just the same time. Yeah, GitLab has so many dependencies. I think we have a thousand non-unique libraries. Okay, you probably want to keep a part around, but if you have a smaller Rails app, I think, hey, Roku had this model where people said, hey, it's okay to wait 15 seconds. And even like if I have a review app that I haven't used for three months, but I want to have a look at, it's acceptable to me if I have to wait two minutes before it's spun up, it's way quicker than any alternative. Yeah, that's a really interesting angle, like the review apps and things like that, I think, to try and use this in the sense that rather than having some manual workflow that'll try and pause and restart, or restart on a text activity, if you can do it automatically just by request heading in there, and even that might take a minute or two for the environment to come up, that's a really interesting use case. They're gonna have an auto-pausing environment to kubernetes up the locations. That's something we should definitely look at. It's interesting. Do you know where they're mopping up, like you have to kind of sponge the request before you release them again if you're spinning up a container? Do you know if they're doing that in Istio or someplace else? I don't, I would imagine, I think it's this, too. I think the event control, I think it's required. So I don't think the eventing component is actually being used for that. So I imagine it's probably Istio, although I don't know that we should probably double check that. And this automatic is happening kNative server, right? Yeah, so kNative serving is the main component for the scale to zero components. There's a couple other sub-projects that we've kind of talked about here. It looks like the build side, which is a sort of a way to build containers out of your source code, as well as some other more general purpose tools you could use it for. And then the eventing side is for messages, like bosses and things like that to like interact your functions, so. Cool, there's also something they announced what is basically a sample of source to URL where you can go from the source code to like the running app. You think that's an alternative to GitLab's workflow or is this something we can embrace and put in GitLab as well? How do you see how this compares with GitLab? I think it depends upon your workflow. So if you're trying to deploy a relatively simple application going from source to URL potentially makes sense, I haven't had a chance to dig into that in depth yet. So sort of just talking generally. But I think where I'd be interested in is in sort of how you try and handle that for a service that you want to have up for a good amount of time, right? So you can potentially bake in some CI tests that might fail, but what happens if you deploy it and things start to go poorly and you're tested and catch it? Do you have some of the ability to do scenario deployers, rolling deployers and things like that with that, with that much of a simple sort of deployment option? As I think, where that would be particularly interesting for folks, even if you are doing CV, where you plan to respond to these kinds of things with minimal impact. Yeah, that makes sense. It seems that there's not a lot of visibility into the process and ability to see the different stages and get some control and visibility there. So that makes sense. One tool that was already out there, but got referenced in the documentation of Knative is Canico. Is Canico kind of a way to build Docker containers without having to use Docker in Docker or things like that? Or what is it exactly? Yeah, so Canico is a new tool that was recently released by Google to help try and solve the problem of building containers in container environments. So typically in the past, you would use something like Docker in Docker, as you noted, to accomplish this goal, but some downsides to that. Number one, and quite first and foremost, is the security concern, is that running Docker build requires a privileged environment. And so therefore, your pod needs to be privileged. And when you have privilege of running as root, this really gives global access to the node to do some really bad things. And then once the node is actually compromised and all their workloads running on the road can get compromised, and it can really punch a hole in your security model. So it's not a good solution for building containers. And so people will be looking for other solutions. And Canico is a good one in that it doesn't require you to have a push container that can still accomplish those Docker builds for you in a relatively easy way. Well, do you think it's something we should make easier to use in good lab or make use of by default in auto DevOps? Yeah, I think for sure. I think one of the challenges here with this whole space is that developers have gotten used to the ease of just using Docker build. And so that's what they're used to. And so if you present them with a Git CI YAML file, that's probably what they will go ahead and enter in there. Auto DevOps, where we control the CI YAML, we can help to drive some best practices. We should absolutely consider using Canico instead of Docker build. So you can utilize it without having to go in there. But I think also just for the general use case, we should look at ways of trying to help developers move towards other tools that don't have such a few problems. And so if there's ways that we can help, for example, like in our CI editing process, or for example, if you try and run Docker build in an unprivileged container and you get an error message, you could potentially add some logic to our log parsing that might say, hey, it looks like you failed Docker build, you're probably running this in a container that's not privileged. Rather than making it privileged, here are some things you should look at doing. And those are some potentially low-hanging fruit that we can try to accomplish to help steer users towards best practices for building containers. And then, and I think potentially a longer term, we have a whole bunch of options for fix some of these tools that might make sense for them and make Docker building first-class. And so you don't have to worry about Docker build versus Koniko versus other tools and how to script those properly for your environment. We can help you do that in a more first-class way and potentially switch from Koniko or IMG or Orca, which is some other tools that can help do this as well with some sort of slight differences in trade-offs along the way. So. Cool, that's great. We're all about making it easy for developers, but also making it secure by default. So that sounds great. I heard a customer mention yesterday that there was a thing with scopes on our registry. Can you maybe explain a bit what we're talking about there? Yeah, so we had folks trying to use Koniko for a little bit now since it was released and there's kind of two main hurdles that we're looking to solve here that sort of block its usage. One is that Koniko bridges or it attempts to mount multiple repos within a single registry and that can help you do fast copies between repos in the same registry of like a blob and so it has performance benefits. Unfortunately for us, we only support a single scope right now and so we're working on a fix to get that supported so we can more cleanly support Koniko. The other challenge is that the default Koniko build or image doesn't have a shell on it and with GitLab CI Runner, we expect to shell in certain places. There's a debug build which where our image that does include a shell, but it's like in slash busybox SSH and we don't expect it there and so we essentially can't start and that would lead you on the path of trying to make your own Koniko image but that's complex because there's like wet listing of files and how it works and so what we really need to do is just add the option to start the busybox SSH shell. We have two and I think we're getting pretty close to getting both those resolved here. And scopes, what are those scopes? Is it like, hey, this is the location of my container and then I got like a development image and I got a production image or what are these scopes? Yeah, so for example, if you wanted to pull like from a base image from a repo or an image somewhere else in your registry and you wanted to then lose as a base image and then push it to somewhere else, what can happen is that with, you can reference the same kind of base or blobs or image layers to essentially copy them over. Scopes is kind of a way to refer to the layers in the image. Yeah, and this can help you to authenticate to kind of multiple places at once. Okay, cool. Well, thanks. Thanks and enjoy. And Koniko's the first kind of tool that we've seen that kind of leverages that functionality and so we haven't bumped into it before but now that the tool is taking advantage of that feature we kind of need to add support for it. Cool. Thanks for that and enjoy Google Max. All right, thanks, Sid. Some really exciting stuff here. Can't wait to get it to working with GitLab. Awesome. See ya. Bye.