Kubernetes Usability Special Interest Group, 2 Aug 2022

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: 20220802 SIG Usability

Description

Brian Grant demos kpt

A

Okay, uh hey everybody! uh This is the sig usability meeting on tuesday august 2nd um and I am filling in for tasha today. She said that she had a meeting that she uh unfortunately could not move but still wanted to give brian a chance to do a demo of the kbt project.

A

So that is the first topic on the agenda today. um So brian, if you want to take it away with your topic,.

B

Okay, um let me see if I can share.

B

My screen just a minute.

C

B

Okay, I think you should be able to see that now. um So in terms of a little bit of background, this is uh an approach. That's um I've been calling configuration is data and uh what the ui can do with the help of our back end, which we call the package orchestrator is. It can actually modify uh configure reading right in storage.

B

So, instead of like the kubernetes dashboard, which interacts directly with live cluster states, uh this ui can interact with the configuration in git and then a get ops tool can apply that state automatically to the cluster, so that the idea is to enable capabilities that today kind of bring together the capabilities of get up style tools or infrastructures, code style tools and traditional tools where we can apply. You know traditional ux techniques to mitigate domain complexity, to provide step-by-step guidance, and things like that.

B

So we started with the simplest possible kubernetes scenario, which is configuring, namespaces or provisioning namespaces.

B

um But what we're looking at now is how to apply this, to the thing that most companies use about, which is uh but kind of uh something. That's happened in the kubernetes ecosystem. Is that you know most um there's a kind of an assumption that most people are deploying their applications with a configuration tool like helm or customize, or something like that, so the user experience developed in most uh kubernetes dashboards, portals consoles, uis etc, are somewhat incomplete. So, for example, I can show the the kubernetes dashboard. Let me see if I can.

B

Refresh my credentials here.

B

So if I go to the deployments.

B

uh Default namespace all namespaces.

B

Okay, if I look at deployments- and I want to deploy something- create a new resource in the kubernetes dashboard, for example, uh the form view is uh somewhat incomplete, so I can actually you know.

C

B

Kind of a standard nginx example.

B

And show advanced options, but advanced options is actually still a tiny subset of the options that are actually in the pod spec.

B

You know it's a somewhat incomplete experience. The this uh cades ymo tool uh actually has a somewhat more complete experience, but it's kind of flat. It just presents sort of all the options um together. So I think you know an interesting question is what kind of step-by-step guidance would be more helpful in constructing.

B

The kubernetes resource description for um for real-world use cases, and you know I think, we're just starting down that path, but you know just to show the namespace example so in this example, their namespaces and the associated policy resources like resource um or our back role binding, for example, uh have a lot fewer options. So you know first represents uh a flat form, but you can imagine if there are more options, you need to structure it more with progressive disclosure and step-by-step guidance and smart defaults, and things like that.

B

But what we can do here is actually create uh a blueprint.

B

I'll just call this a a base, namespace blueprints and the blueprints uh is, you can think of as kind of like a template except there's, no actual templating in it, it's more of an archetype or an example of the set of resources and a set of instructions for how to create variants of that when you're actually utilizing the blueprint to create specific deployments from it.

B

So you can think of that as like a macro in some sense.

B

But if I say okay, what this is using under the hood is a project called kept, which is a simple packaging tool that supports git and we're working on container image or oci support for storing the configuration as well, and it will execute a set of functions to transform uh the configuration so instead of intermingling template, syntax or some configuration language like jsonnet or qlang, or starlark or dahl, or something or a general purpose, language like typescript or whether or not actually in the configuration.

B

The configuration is just represented as data as kubernetes yaml and then the code. The functions manipulate the data so much more like a traditional uh ui tool or cli tool or automation, tool that interacts directly with the live state and read, modifies and writes, say we manage configuration in a similar way.

B

So what we can do is, we can say uh edit the blueprint since we want to create a namespace print. um We can add a namespace resource to blueprint and you know say we want to use istio so we'll enable istio.

B

Injection and we could provide, if that's a common thing people do. We could provide a first-class feature for that.

B

You know, but then we can save that and that's name spaces. Don't have a lot of attributes. So that's pretty easy. So we will.

B

Just leave it at that and then you know we need to add a role mining uh to name spaces, and we will um assume that there's a cluster role called app admin. So um we will add a reference to the cluster role, app admin, and we will bind that to a group and say that that group has a form decided by the platform team.

B

We could also bind it to a service account and add a service account.

B

But uh we'll just say it's example.admin, whatever our company is, uh is what the platform team is.

B

uh So then you know so that's kind of the simplest possible uh blueprint like I said you can think of it as a template or a prototype, but it's just an example.

B

uh So then you know we need to provide the rest, the variance for that when they're provisioned, uh so that's done with functions um so one function function we need is to set the namespace name to some unique value when we create namespaces from this blueprint, we also need to change the group in that role binding, so we'll actually use a transformation that we repackaged from customize to um to modify the role binding. That's the trickiest bit common transformation. We could actually write a dedicated function for that, but you know apply replacements.

B

You can give it as a fancy kind of patch the. But my general observation from looking at a lot of kubernetes configuration packages is that the same kinds of patterns are templatized in all the packages or helm charts whatever that contain the same resource.

B

So we're doing here is taking that logic out of the packages and out of the templates and putting in functions that we can reuse the crop tree packages that contain those resource types.

B

So in this case we are going to use the name of the package uh which we put in into this config map here automatically. For now um we're going to use the name of the package to set the name of the namespace, which is kind of a nice simple convention that creates a unique identity for every deployable instance, and we want to modify the role binding and we want to change that group string and- and that's we only need to change that first part of the group string.

B

So um this one provides values, so we can see what we're actually changing uh yeah. We want to replace this example.

B

And then we can go to the kep file and add our functions, so we need a function um to set the name of the namespace. So we have a function, set namespace function for that and we're using the name of the package.

B

And then we need to add a function for that apply replacements um configuration that we specified uh we we can we're look planning to create a way to do this automatically to automatically map these input types to functions, so people don't need to manually, add the functions, um but for now I can just do that and use autocomplete effectively to identify that. So that's basically it.

B

We need a way to be able to test this to make sure it does what we but right now we'll go ahead and save this and hope that it works, and what we've done is we've created this.

B

uh You know prototype as it were, for maybe my credentials expired.

B

Nope, it's just a little bit slow for some reason. uh So once we have done the edits that we think we need, we can propose a change and then someone else on the team could review and approve the change. And what we've done here is created an experience where it can be reviewed uh directly in the ui. Now here we're starting from scratch. So there's nothing really to compare with um you know they can just take a look and you can make that view as uh as nice or as structured as you want. Like.

B

I said, these resources are pretty simple, so we just kept it simple.

B

Go ahead and approve that and then this blueprint becomes available for deployment, so we can deploy right from here or we have uh the the model we're using is we're fully rendering all of the configuration to deploy in advance. So, instead of having a template that renders and and doesn't apply on the fly, we're doing in advance, so you can completely see what you're deploying you can present it in a structured way. You can validate it. uh However, you like, and do automated checks, uh review and approval whatever you want here.

B

We just use the same workflow for simplicity, because it's kind of a proof of concept, but we deploy these things into this other repository. We call namespace instances now these things uh actually are reposing github. So what I just did is I created this. You know the base namespace blueprint.

B

uh Which now here is in my repo- and I never really had to look at yaml. I never really had to do all those good commands um and we can see you know the contents that I put in there is in there, so we're gonna do a similar thing with the actual namespaces that I want to create.

B

So now that I created that blueprint it's in in the list of available blueprints, uh because we have that repository specified the repository to go, look for blueprints and you know I can just create a backend say for this and say yeah go ahead and create the deployment now, in this case, all of the changes all the edits are completely automated. So here we see that the namespace is changed.

B

The name of the package backend one, the namespace value and the role binding- was also changed back in one, and that group was replaced with back-end one as we expected. So that's actually all the changes we expect.

B

If we wanted to do further customizations to this, we could we could edit, just as if the blueprint- and you can think of that as adding patches on top of the base blueprints, except that you don't have to construct a patch manually, effective it automatically uh diffs with the blueprint when you do an update, so instead of always patching uh the base as we're doing customize, the diff is computed when we do an update from the upstream.

B

uh So, like I said it's the same workflow, so you could do a propose. This change. uh I can show the diff from the upstream, I think, or maybe not.

B

That doesn't seem to be working.

B

Yeah that doesn't seem to be working for some reason, but um you know we could show the diff from upstream. The diff is not super interesting, because these are the changes that we expected to take, but you know once we go ahead and prove that approve this. This will get merged into that other repository, and um we can should see that here, here's back in one so yeah, that's stored and now, like I said, the get ops uh process in the background can actually um sync those resources.

B

To the cluster, so I can show that.

B

And here's the back end one resource uh namespace,.

B

Already in the cluster, so by making these changes in and get effectively directly changing the state in the cluster, and this linkage between the two um you know there we're using uh config sync in this case, because I'm most familiar with that, but you could easily use flux or argo cd to do the same thing.

B

I have annotations here that actually map this resource back to the source of truth. So this says it came from back in one namespace.yaml, uh so you know. If we had integration with uh the configuration ui, we actually put a link there and go back and forth uh between the two.

B

So um you know if someone we could make it so that someone could couldn't make the mistake of just doing it edit directly through the live statement, would be redirected back to the configuration ui to make a change, but making a change should be just as easy to make it through the configuration, as it would be to make that change through the live state.

B

So I think this is an interesting model um like I said, because we can apply uh all the users techniques that we would apply to a livestream ui um or to a git provider's ui. We could apply um to the use economism, so that would that you know things that people think you know don't use a ui to manage a production environment or today uh this actually enables game equation, and it actually would enable people to make changes through ui and still have repeal. I can go create.

B

You know as many name spaces as I want from the same blueprint and you get you know: pre-deployment validation and change, control, review and approval uh also versioning on view. So I've only created one version, but we have a list of revisions here and you know kind of like in google docs.

B

You can just select a previous revision and say re. You know revert to this previous revision right so undo for kubernetes generally uh effectively so yeah. I was interested to see what people think about, and uh you know whether there's interest in in trying to apply.

B

You know standard sort of uh ux uh strategies to the the blueprints creation process effectively right so today, if you want to create a home chart, for example, you basically have to start from scratch, author the resources and then you know out template every attribute is a typical thing uh that people do like every possible conceivable attribute that someone would want to change um and uh there's not really much help for that authoring experience actually, especially for the for this case, because you know helm, helm, create you know, cr creates a minimal blueprints and service, and maybe ingress- I don't remember, but uh you know it doesn't do that namespaces uh here we can actually provide uh a base blueprint and then create blueprints from other blueprints.

B

Just like I created these deployments from so you could potentially create classes of blueprints for different scenarios for namespaces for applications for other things you needed to do in kubernetes, but even for creating those base blueprints some of the resources, like anything with a pod spec, for example, is pretty complex, so being able to provide more guidance and more structure around. That, I think, is an interesting prospect that hasn't really been much explored. I've looked at a bunch of dashboards. I've looked at you know.

B

This is the kubernetes dashboard also looked at lens and octant, and you know this k cml dot com uh from octopus.

B

This is probably the most complete example: I've I've seen uh for generating configuration, but here there's no way to deploy. You know it's just like after you base the optimal, whereas in the backstage and you can deploy.

B

C

B

About um all right show for the demo, because you know mostly, I wanted to get people's impressions and see what people uh how people felt about the approach, whether it's useful, um not.

B

A

I think it's interesting silence, so I I watched uh I watched the your similar demo.

A

I think a couple from a couple of months ago, when I was preparing for this, for this uh meeting um and and one of the things that struck me is like you could have the ability to do like, like I know when I used to I used to work on a platform team and um one of the challenges that we had was when we tasked our app engineers um with defining their own services and then deploying them onto the clusters that we managed um we, I called it the control c control v problem, so we managed it all through get right, but they would just go.

A

Take somebody else's service wholesale copy. It paste it change the two things that they needed and then commit it and then never look at it again. um So from that perspective, like the blueprint idea, I think would be very helpful right because you could enable platform teams to say like no just like don't copy and paste just use the blueprint.

A

um A couple of the other thoughts that I had with with regards to like usability is like um I'm thinking of another piece of software that I use for like 3d, printing right on and plating, and it's got like a an easy, a medium and like an expert mode, and it seems like this could really lend itself to that.

A

I noticed, as you were doing the demo like there were some deep internals that could show up as part of like a blueprint that maybe a a novice user wouldn't really know or care about or could easily blow their foot off. But you could you could abstract that away through the ui um and really, you know, make it easier for for newer users to to be able to use the thing and then make it easy.

A

For you know, experts to also be able to go and like dial each knob that you would want to expose like, like you said through, like a home chart or something.

B

Right right, yeah, I think what I've seen as a common pattern for for teams with the scenario you mentioned, is that they create kind of a universal home chart um that parameterizes any attribute that anybody wants to use and then the values.yaml ends up being about as large as the entire template.

B

uh So people are copy, not copy pasting. The whole chart, but they're copy pasting, the values.yaml and doing the same thing. So you know structurally, it's a little bit simpler to merge in an automated fashion, but otherwise you know is is pretty much as complex if all the default values are in there and whatnot and to some degree that's you know what they're giving up when they do. That is it's no longer api, so no standard tools, work with it, there's no standard documentation that goes along with it about what the values mean.

B

um There's you know no standard ui for presenting those values uh you know other than as just a kind of a generic form, or you know, even as just about the ammo itself, uh so you know understanding what values are available and what changing those values does almost always requires. Looking at the charts- or you know, asking someone who's familiar with the chart, um so you know that I think the general my general sense is that we can have a lot more leverage.

B

If we build on the standard types and both for kubernetes and the extensions around kubernetes like uh istio and k, native and argo cd and and whatever then you know, you know, somebody can write that logic, one time whether it's in a function or a ui uh and everybody else can can leverage that and can use it.

B

So so we're still in the early stages but um yeah the thing we're looking at next is kubernetes applications, so deployments and services and ingress and stateful sets and whatnot.

B

uh And that's where you know we'll have to evaluate how important each set of knobs is for the typical user uh in order to figure out how to structure the ui in a way. That's less overwhelming.

C

Yeah, I think- um and this is I guess, coming as a question from like a novice, this idea of like optimizing usability, but for building the blueprint itself. um It would be interesting to get like y'alls thoughts about how you balance, like suggestions on how to like manage this, like config workflow and maybe like breaking down these like steps granularly uh against just this idea of like having to click a lot of buttons and like not being able to see everything at once or like what's the trade off there.

C

And how do you all manage that? I guess when building a ui like this.

B

I mean in terms of seeing everything all at once.

B

Are you thinking about just seeing all the resources all at the same time or.

C

Yeah, exactly or like you know this, this workflow like it was like a lot of okay. I did this part uh like let's move on to the next part. I did this part in terms of uh yeah managing that type of uh like process.

B

Yeah I liked elliot's idea of the having different modes for people with different levels of familiarity. um You know people who need more step-by-step guidance. May people who uh are more familiar may skip around more. um The analogy I like to use is turbo tax, which you know the tax taxes are super complicated.

B

It hasn't has a sort of a wizard that walks you through it, but it's not an abstraction in the sense that uh it's not preventing you from changing any particular field of any particular form. You can actually um go through this step-by-step, where it asks you a bunch of questions and populates information or you can choose I'll, do I'll choose what I want to actually go fill out and you can just hop around and select flip between deductions and income.

B

If you want and things like that, and then there's the form view, which is really the raw view, and if you change a value in the form view it does not get overridden by the wizard uh at least I've never had it happen to me. So you know it's not it's. It's providing you know, stan it's using standard. Ux approaches to mitigate the domain complexity and that's even more complex than kubernetes for sure.

B

But letting you choose the sort of the level of simplification that is appropriate for you right. So, like the first time I used turbotax, I went through the step-by-step guidance and then, after that I was familiar with how it was laid out. I hopped around said you know. I know these parts are not relevant to me. I'll just skip those, um so that's sort of the mental model for how I'm imagining it and another example of that that I've seen that has done well is my asus.

B

Wi-Fi router had a mode like that, where you know there's a simple mode where you know almost everything is automatic and I I just have to enter minimal information like what you know. Actually even you know, generating passwords and stuff can be on. I'm not gonna just have to know what it is, um but you know there's also an advanced mode where I can go and change lots of networking knobs that only a networking expert would know, um and if I change those they don't get stomped by the device.

B

So that's only two two modes, um auto everything in advance, but I think it's some shows the concepts uh you know in this different domain can also work where it's not abstracting the underlying details. It is simplifying how to manage those underlying details um and something I've seen since the beginning of kubernetes is that abstraction is hard like people from the beginning. Even when kubernetes had vastly fewer knobs and vastly fewer resource types, people tried to abstract the resources with you know, jsonnet or some other configuration tool and is very difficult.

B

Like I'm not aware of a lot of successes there um for people trying to do something, that's very general purpose like an off-the-shelf application or a blueprint that works for all the applications in an organization or something like that uh it can be very, very challenging there also, I, I think, a lot of times people get caught up on uh reducing boilerplate or you know, applying minor simplifications, and that ends up not having a lot of value. It just gets in the way. More than anything else.

B

um You know there is something to be said for not needing to know exactly how the kubernetes ammo is formatted and things like that, um but we should have tools that can help with that. Ids can put that, for example, a ui could help with that or cli.

B

You know so. Keep control has. If you know the right combination of flags you can use, keep control creates to create the ammo. For you keep control creates, you know, client equals dry run or whatever it is now dash or yaml, and it will spit out the ammo for you, so I actually have been using that and it's not bad. You know if we made that more obvious uh or a first class. You know new command like cube control generates, or something like that.

B

I think that could be a pretty nice experience, uh but this general idea that I'm going to generate and transform the configuration with the assistance of tools and then apply it to the cluster as a distinct step, I think, would be a good model to adopt.

B

I mean kubernetes users, for the most part have adopted that model already, whether they're using get ops tools or you know, they're doing control, apply or they're using helm on the command line or whatnot, um but so just getting into that mindset that you know the kubernetes api is natively declarative.

B

So if we have a declarative representation of that uh serialized and stored, then we can get. You know pretty much all the benefits that people want from uh from get ops style workflows. There are a few tricky bits, so you know one thing I didn't show is upgrade so upgrade.

B

If not, if not for upgrade everything I showed you could basically just do with um macros right, like you could take a take, a blueprint, run, a macro spit out a variant, uh and that's that's nothing new! Really. uh The tricky bit is actually okay. If now, how do you, if someone changes the blueprint? How do you update all the deployments that were generated from that blueprint?

B

So that's where this you know patching diffing and patching.

B

Mechanism is actually needed and we're still working on. You know exactly the right semantics, but my mental model is uh kind of similar to a customized base where the blueprint is providing defaults and if the consumer hasn't overrided those defaults and those you know new defaults get. Arguably you shouldn't change defaults in the blueprint, because changing defaults is sort of a breaking behavior, but.

B

You know just as an example, if you make a mistake in a blueprint and then some deployments get created from it and you want to fix all of them all those you want to put the fix in the in the blueprint and then roll out that fix in all the direct instances right. So just as I you know, the example I showed was pretty simple, but even then you know I run this demo lots of times and half the time.

B

I forget to do something right, like I forget to add the reply apply replacements function which should be automated, but still you know, if I forget to add uh the istio injection label to the namespace, for example.

B

You know I would want to add that to the blueprint and then go update, all the deployments to get that change right. So I think that is the sort of the interesting bit uh or one of the interesting bits. There's there are some other challenging things. We're working on application. Configuration is one that we're looking at right now.

B

Application configuration is in a wide range of different formats, so we have we've been looking at a number of off the shelf, helm charts and you know the the can apple config is in formats like ini and tomml and xml, and some are some are in json and yaml.

B

Prop application properties is another one for java applications, properties files.

B

So there's like on the order of half a dozen formats that are not uh kubernetes resource formats, so you know if someone changes an attribute, how do you do this diff and merge uh correctly?

B

um So so that's you know something we're working on uh right now as well. um Do you also have that same problem with uh versioning and upgrade of the mutators as well yeah? So that's another thing we're thinking about you know the platform team probably wants to manage the versions of those functions right now, the tags for the so that we're using containerized functions and the tags are in the kep file, uh and that probably is going to be.

B

You know it's good for predictability, but it's probably going to be a maintenance issue. So one thing we're thinking about so our back end has made all the configuration accessible through apis through kubernetes api is actually using an aggregated api server, so uh that enables us to run all kinds of automation on the configuration content in storage. So in theory we should be able to discover all the set of packages in a repository.

B

Check what function versions, they're running, for example, change those and propose that change and do whatever automated validation or testing. We want to do and then merge those changes in a progressive fashion, so that conceptually should all work. We need to actually go build a prototype of that and improve that we did build a prototype of bulk upgrades, so update a blueprint and then you know discover all the packages that were drive from that blueprint and propose up upgrades to those, uh and that worked great.

B

uh The workflow is a little bit tedious, so we probably would adjust the workflow, so they can be bulk, approved uh bulk reviewed and approved, and we can actually run automated checks already. So I showed mutator functions. We can also run validator functions, so we could run automated validation checks. You can think of them conceptually like github statuses or some or things like that um or mission control in kubernetes.

B

It's effectively admission control for git, um so we can prevent uh merging changes that fail the checks or we could automatically merge things that pass the checks um but uh yeah and the workflow can base basically be whatever people want it to be and we have the base uh after any mutation that's made. We run all the functions again, so they need to be item potent, um but that's the image control aspect of it.

B

uh That mechanism is, is pretty flexible.

B

So you know a lot of different workflows could be built onto the primitives uh that we built, um but yeah and definitely bulk upgrades of functions is, is something that uh we've already run into because we've iterated several times on the set namespace function, trying to figure out what behavior we want from it, because some packages deal with resources from multiple namespaces, for instance,.

B

So it's it's yeah. It's definitely clear that it's gonna be something that platform teams need to do, and I I I think, the other. The other thought you know kind of riffing on the you know, making it easy for some and having more advanced uh for others is uh possibly having better descriptions in terms of what the mutators do, such that it's more obvious to people. You know which mutator to pick et cetera, yeah. Absolutely I'm also been thinking for the application use case.

B

We will want the ui to understand certain mutators that you know we expect to be commonly used much like customize has you know some built-in transforms that are that are commonly used, um so we have a kind of a general purpose, discovery mechanism where we can register uh repo and discover what functions are in there and then in theory. We could attach metadata to those functions and uh you know filter them in various ways. So currently we have filtering based on whether a function is a meditator or a validator.

B

So if you are adding a validator, it only shows you the validator functions and then in the repo. uh Definitely one thing I've noticed is where the input type is well structured like in the apply replacements case. We could automatically know what functions get run in that case and the user wouldn't have to deal with it, but also for the resources in the blueprint like namespace rolebinding.

B

Usually there are functions that apply to specific resource types like set set namespace, for example, and that applies to most resources, because most resources are namespaced, but we have some specific functions that apply to specific resource types. So we can suggest functions based on what resource types are in the package, um which is a more generalized version of no. You know invoking a specific function for specific input.

B

So we're looking at things like that, but yeah in terms of modifying the lots of the pod spec, um we're trying to figure out the balance between supporting those edits directly in the ui and creating functions that can modify parts of the pod spec, because there are some of the attributes. We want to be common across all the applications in an organization, for example.

B

So for those we would like to have a function that we can just say make it so like make no make sure none of the pods are privileged or none of them auto mount the service accounts. Things like things like that, uh so those things will probably you know those best practices as platform teams develop. Then they would probably want to create functions for those and then automatically apply those functions to all the packages. So we're also looking at attaching functions at the repo level.

B

So again, with this admission control concept, so the platform teams can ensure that you know all of the deployments. You know obey what whatever specific rules they have with respect to security or networking or whatnot.

A

Cool well, thank you for watching.

A

I found it really interesting. I I hadn't uh hadn't actually heard of the project until I saw the your previous demo, so I was excited to to get to your chat about a stick.

B

You know kept has been around for a little while, but a lot of this functionality is new since may yeah, so like the dui plug-in and the package orchestrator back-end in particular, and we also just recently open sourced config sync as well. So now it's kind of a more comprehensive package for automating.

B

um I changed the tagline of the project to automate kubernetes configuration editing because I feel like that is really the unique uh aspect to what we're doing is. You know in you know all the other 100 tools for managing kubernetes.

B

You have to write the configuration by hand at the end of the day, you're in a text editor an ide writing it by hand and with this approach you know id is sort of the proof of concept, but I think, as we get into security remediation and tools that you know try to instill best practices and things like that, there'll be more automation that uh that we'll be able to apply to constructing the configuration machine. Learning is another thing we're looking at.

B

You know. Most people set this this way you should probably set it that way.

A

Good pilot for your manifest.

B

A

Cool um does anybody else have any other questions say about the demo or or any other audibles? They want to call for the topics we have about. 10 minutes left.

A

B

I have a question, um which is how much does sig usability interact with the other cigs like sig, ui and 6li, like cli in particular. I think.

B

I haven't seen a lot of examples of.

B

Ux really trying to inform how the cli is designed, I mean keep control itself at this point is hard to change, because it has so many users and documentation and things like that. But um for things for things that are additive, and we could look at how to streamline the experience more for what people actually do uh anyway.

B

Just as one example, I don't know how active you know. uh Dashboard effort is at this point in terms of making changes versus just keeping up with kubernetes evolution, but uh could be interesting or useful.

A

Yeah, I I I don't have an. I don't have a good answer um for that, but um I feel like tasha probably would be the person to would be the person to know um so I can. I can definitely ping her with a with a follow-up uh for you on that.

B

A

Cool uh anything else before we wrap up today.

A

Okay, awesome: well thanks everybody for coming out thanks again brian for the demo, um and you all have a great rest of your week.

A