Istio User Experience Working Group, 8 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Istio User Experience WG September 8, 2020

Description

- "istioctl command type/name" enhancement
- organizing istioctl commands better to reflect persona/role

A

Their own cluster.

B

So, do you want to keep mesh config with the defaults, or do you want to create a new config for the defaults and create basically a proper crd and do what we discussed in for two years to to create a crd for the defaults and for the user configurations.

A

Yeah, so we pretty much prefer to have a crd for the defaults and the main reason is the mesh. Config is actually not configurable in our managed issue environment, where we don't allow users to change mesh config, a lot of at least most of the field in the mesh config and the main reason is you know, because if because we automatically manage like the control plane update forward use if they change mesh config, you have to think out, you know it could be overwritten.

A

First of all, second of all, how do you upgrade the mesh complex to the new version right? If you can't solve that problem, it would overwritten for them. So if we can separate the admin default out, so they could configure admin default um separately like the outlier detection time, our retry and mesh config could be, you know from really advanced user, but for normal user. Hopefully they don't have to.

B

I I'm I'm perfectly happy with this. I mean, let's discuss in environments, I mean there is a proposal that we are supposed to discuss in the next environment.

A

B

And let's make it clear that we want to have a new crd for the defaults, as the document is proposing basically and mesh config will be out of the user hands. Basically.

A

Okay, that that would be great yeah, that's something you know we have wanted to see it happening, it's still for a long time, just because.

B

Everyone- everyone wanted, I mean it's it's just. The problem was that that we had, you know, values, global and a lot of other things and mesh config was a better place than those because at least it was an api, but I agree we always wanted to have mesh config and proxy configures proper crds, and we already have proxyconfig. We went that way where it's the annotation, it's kind of a proper exposed api.

B

So I agree: let's make it a p0 to get this to solve the mesh config problem. Basically,.

A

Yeah- and we could start maybe with some of the common configuration first and gradually add more stuff as needed. So.

B

Yeah the danger is, the danger is to not transform it into global camera. I mean this new crd. We need to be very, very careful because mesh config also kind of went uh through a lot of random stuff. Getting added.

A

Yeah a grid- yes, so yeah. So let's rework uh discuss the more detail. Actually in terms of meeting on that, we need to refine that proposal a little bit more too.

B

Yeah, I think the main the main argument is that mesh config was never really user editable because you're right, I'm almost all the time I mean yes, we have ability to change it at runtime and reload it and and apply it, but next time the user is going to do an install or any change. It's going to be overwritten and lost, and we had this problem for a very long time. So it's kind of.

A

B

We need to cut it yeah.

C

Okay- okay, great, I will make sure I'm at the next meeting and talk about how we can dump out that field and explain it to users. um So the uh we've been putting this off for a while organizing the commands by personas and roles. This this document is very preliminary and I think it is kind of old, but um I didn't I first.

C

For the admins and which commands are for the users- um and I think I did this before one seven came out- so I've started trying to fix it- um tell me about the control z stuff, that users should never see any of that right.

C

Even on the um is there anything that would run in a user pod that they build a c for control, z,.

A

Well, the only time I use it is for debugging like if I need to turn on certain logs it's a convenient way, but.

B

That's operator.

D

Yeah these would be uh these would be uh control plane logs that typically users wouldn't look at. I guess.

A

That is true. Yes,.

D

So yeah, I I think I think that's what you're implying that that uh it's it's mostly an admin. uh It's it's mostly something for admins. I I think that it does belong in this in this section.

E

D

C

um So install and and upgrade if we still have upgrade apply, is gone so.

B

By admin, what do you mean by minutes? It's uh sorry. What is admins operator.

C

uh These are, these are for the essentially the cloud operator or um a person.

B

In control of the so that would be a google or ibm engineer who.

C

Is maintaining.

A

Examinations: okay, yeah.

B

A

So so I that's a good question, so I think there's really three roles, so why is the cloud operator like you were saying? You know google right operating issue for your customer? The second row is the platform team. Who is we also called mesh admin early, which is the platform owner of the service mesh platform for a particular customer?

A

Well, they define you know the service mesh strategy for the team and on-boarding services, like best practices.

F

A

Their services yeah within their customer, I think, there's two roles. One is the individual service team who run services in the match and then there's also a typical role. uh We we call it like platform owner.

F

A

The service mesh platform coordinate with multiple service owners within their organization and be able to set like best practice for adoption of service mesh best practice for configuration tuning for service measures. So it's like a central development scheme right.

B

It's it's it's familiar, for example in in hosted services you have the admin, so even if, if the yeah, the user is a user- and that mean is the ones that has been administered, you know east ud or whatever, but he's not actually operating and running the service. uh That's good! I want to make sure we have clear names and separation between them, because um again it's a big difference between mesh admin and the service owner and, for example, I don't want the measured bin to control his upgrades.

B

He may choose that he stays in a particular channel or stable or whatever, because we want to be able to push fixes whenever we need as operator.

A

Right, yeah, exactly which could be controlled by a cloud provider. So I guess an example. I would say one of google's customer auto trader kyle stoney did I pronounce his.

F

A

I would think he's the platform team right because under him, he's probably uh have like multiple service owner that he work with.

B

Yes, he's more like operators than so. He has two roles really because it's also cooperating for himself but.

A

I agree yeah, but one day, if you provide israel as a service, he would not necessarily be the operator.

B

A

Be more on the platform team, yeah, okay,.

B

And he will not be able to control the mesh version, because if there is a security fix, we'll push the security fix as long as we guarantee that it's backward compatible, we should be. I mean operators should be in control of the versions of this running.

A

C

So is this breakout I've had here separating the cloud operator from the platform team from the service operator? Do you think this is the breakout.

B

Except the mesh config settings we discussed as a default settings, not mesh config. We want to kill mesh config and leave it for uh operator, so the new default settings or new whatever you want to call it.

A

Yeah the new settings- hopefully in a crd- that's so that.

F

We can take.

A

Careful upgrade problems for the user.

B

No default idea: okay,.

B

And I really really like the idea of crd, because then we can also have per name space. We can, it can be applied by namespace and we can have proper.

B

You know you want only these names to have analysis enabled.

D

B

A

C

That makes sense so now that I've broken this out, control z is still just a cloud operator install upgrade.

C

Some of the options that we see here um like the profile stuff, I don't even know how that would apply something like turning on the demo profile thing. Do we even want to have profiles still in the future.

D

I think that that, probably for most cases, they're not gonna, be all that useful, but uh we do have some internal use cases that uh that do uh leverage it actually for for managed steel. um So.

A

I was going to say that we're still using like an empty profile to spin up a custom gateway. So that's a very, very common scenario.

D

Yeah, that's true too,.

E

Yeah, we do the same thing: we intentionally separate gateway deployment from sidecar deployment in some of our in our product, so we need an empty profile for that.

C

That makes sense, so I jumped ahead the diff command, which doesn't talk to the cloud at all. It just makes yammo, but users aren't going to have the ability to use that yaml, so hiding it from them makes sense right.

D

I I think so yeah I don't see users wanting to poke around in. uh Unless I I mean it's actually, it's a general purpose, stiffing tool. So it's it's not really specific. It just happens to be on the manifest, but you can div any ammo manifest with it that you want, and it gives you a pretty nice nice yaml diff view which is which is not easy to come by.

C

The code is ingenious and you should we should separate it off as being a non-istio thing that we contribute to the community, because it's a general gift, yeah.

D

I I think yeah yeah. I consider that that may be the way to go, because it's it's just happens to be on the that's what we initially created it for, but um I I'm not sure if that's where it belongs,.

C

Okay, so the generate users don't need to see it because they can't apply it.

D

Yes, I think so.

A

Yeah makes sense.

C

um So, let's so this promote canada master has a new name, and I forgot what it is. So I can't change it right here. It's the idea of modifying the web hook so that the istio injected true points to.

C

Different settings- and this is a user command, I believe, but maybe not what do we think.

A

I'm not seeing that.

C

A

C

Command hasn't been created yet, and it's it's scheduled for one eight. I forget what I called it in one eight, but it's something like um uh a command, a command that so you know we have.

C

We have a special annotation for these other control planes, and then we have this special legacy. Annotation and I almost don't want to discuss it because we had like a 20-minute conversation last time about, should we get rid of it or should we make it easier to point this special label at a particular control plane.

A

So this is a data plan right. I would think it's the user, then, because the user should be able to put this for each of their services.

C

That makes sense, so let me put it down here.

D

I agree, I think if we have this command and and in one thing that's there's still still some some questions about, whether we really need it um or whether it's it could be. It could be that there's some other stuff that we may put in there.

D

um Currently, I I don't think it does a whole lot or it would do a whole lot, um and you know an alternative approach to it is, is just to to just change recommendations to stop using the old uh label, um but anyway I I mean I I think if we, if we do decide that there is enough under that command that that you know we should create it, and I I do think it should be user.

C

Fair enough, so I'll ask you about these three operator commands: uh do we still need them, and I assume they're for admins only definitely.

D

um Yes, we we do need at least the second two, uh the the first one is something that it was a. It was a request. You know I I'm actually. I would like to remove it, but but um somebody asked for it- and I I don't know if we can just remove it arbitrarily, but um it just really doesn't do much other than renders the installation template for operator.

D

um So for folks that use different installation paths for for operator they they use that to to be able to inspect and apply the uh install manifest for operator so um but anyway, uh yeah. I think these three are definitely under admin or cloud operator.

C

Fair enough, um so I had jumped ahead and we talked about profile, diff uh and profile, dump and profile list.

C

I assume we want to keep, even though we're done we're getting rid of many of these profiles. We're going to keep these features around because they're so handy to keep them all compiled in.

D

Yeah, I I I think so I mean there's a there's quite a few places and docs that refer to them.

D

Yeah I mean if you have the profile command and you have profiles, then I think these these ancillary commands are are helpful.

D

So um you know, I think, they're they're tight, they're kind of a package deal with with profiles in general.

C

Fair enough, um I listed version here, I've put version on both user and admin because I think they both need. It.

C

At a previous meeting we said we want to get rid of this post install which no longer does anything and pre-check. I think, do we think this is admin only. Do we think that users want something more like what lynn was talking about in her service mesh contact to take a look at your workload and tell you if it's a good workload for istio steve current pre-check is telling you if your kubernetes cluster has the right version in memory for sdo control plane. Do we want a pre-check, a data plane, pre-check.

B

Given that version of this, you may change at any time and the clusters that are added to each you may change at any time. I don't know if it's very useful, I mean the.

C

Current picture.

B

I I mean you have a mesh, you can add clusters because multi-cluster what different versions, uh the version of study may be upgraded by the operator when they decide to pre-check will do what I mean. When do you run pre-check, because after.

F

C

B

Check the version of html change.

C

You're supposed to run pre, so let's say you wanted to add a cluster to your mesh. This pre-check should say well, your mesh is on istio 1.9, so your kubernetes is too low for that, please don't add it to your mesh. Yet that kind of thing and.

D

I think the same with upgrades you probably want to run it before upgrade or actually even incorporated, not great improvements.

B

You cannot do upgrades as a user.

D

Right so I I think it's it's an admin command, but but I think admin should run it or yeah. It should be.

B

B

Do you expect the admin to go over each individual cluster around manually commands.

D

Well, we should we should make it easier for them, but, but I think the concept is is good. um I'm not sure if this is the best implementation of it.

C

Pre-Check is pretty clunky and old and deserves more work, but it does return an error level. If your culture is not compatible, so it can be used for scripting. You could put a quad or something on it.

B

I I I don't think we are going to have too many send manual commands done, or at least for google. I suspect you will not either.

D

I think the main problem with this command right now is that, like it just got implemented, but it's it's sort of been forgotten.

C

Good point um so we'll try to improve it.

B

Or kill it I mean less is more.

A

I mean certainly pre-check is not useful for people who rarely manage the service mesh environment right, but it could be useful for people learning istio. They can just you know, run this to before they install insta, because it helps you to check for it. For instance, we don't support kubernetes, 115 and 1.7 at.

C

I think it was inspired by linker d yeah.

A

They have a similar thing.

D

Yeah, it's a great it's a great concept. I I think it's it just hasn't received attention. You know yeah.

A

Actually, I was just going to submit a pr when you run the download israel cuddle command. We currently tell people to do wrong, verify. Install it's actually would be better to run pre-check. The paycheck is actually more useful.

D

Good point it has caught it I mean I, I think it came into existence, because we were getting persistent uh installation issues that that were easily identified with this pre-check.

D

So it definitely, I think, has helped to to reduce number of issues during installation.

A

Yeah and we're supposed to update this command every release right.

D

A

Version changes yeah exactly.

A

C

um So we have a new. We want to make this, um so I I I put everything under workload users, but, as was pointed out, we have this idea that there's someone who manages the whole account and then there's individual service operators who manage a single service or namespace or test develop.

C

um So most of these commands seem to benefit both groups. Things like analyze, I think, convert ingress is gone.

C

C

So if you have any special things to say about these commands uh um regarding these add-on commands, grafana, jaeger, prometheus and zipkin, um I had something I wanted to talk to costume about with that. So currently these commands work by looking for the demo installations that we do. um I was thinking that it would be nice if these commands worked um in a different way.

C

If, um when you are the mesh admin, you install some prometheus in your own way, and then you want your user to be able to bring up grafana that this dashboard grafana, rather than looking for istio in the control plane, just there's a url that it does and I'm gonna make this thing work with a total hack, um so I'll just mention this hack to you all now. Currently, this thing looks at looks at istio system and the idea is that in the future we'll be able to specify a.

C

Arfana url and all that it will do is it will open that url so that, in a sense, that's stupid um because you could just type in something like open food bar grafana, but the reason it's not going to be stupid is that we now have uh istio cuddle settings. So if I do a steel, coil x, config list, all these settings appear. So the idea is that I'm going to make these commands uh just give you settings so that if you type this in it could just be a reminder for you.

C

How does that sound.

B

I I not a big fan of uh you, know, feature bloat and, and, and you know I would expect most people to never touches your cattle in their life. I mean normally, you do not need to use these your cutters, that's kind of a clutch, it's something that it's uh again we get to attach by two to two cent to complexity.

B

A user can put a bookmark in their browser. If you want to remember something bookmarks.

C

Exist for this purpose, you think bookmarks, you think just dump the whole the whole thing for the add-ons.

B

I mean next we're going to add the istio cattle mail comment, because maybe people want to send an email? uh It's it's not really. uh I think it's useful to keep the dashboard graphana to do. Support forwarding if you happen to have graphene installed in your cluster. Is your cutter? Could you know either search for labels or or specify a namespace and do support forwarding.

C

That's why I came to this idea casting first, I was going to remove it because you told me to and then I thought well, it's happy if you have the demo profile installed, but then I thought well, all of our documentation says type in it to cuddle dashboard grafana.

C

We could make that still work with this two or three lines of code, um but.

B

Don't open url, I mean if it's doing a port forward. I think it's useful. uh If you can add the search for graphon, I mean to get namespaces or or have a label in the namespace that is running rafana or some other way to or put the main space parameter and do the same thing, because normally I would expect people to install graphara in the namespace rafana or some other.

C

Places that they're they're using it's they're using central stod, so they their cloud provider has given them um a grafana. That's married to that essential sdod at you know, food.ibm.com.

B

uh Why I mean it's not our problem to worry about their graph, I mean google has.

C

Stuck driver, for example. Well, I know I, and I agree um this idea is: does it make our documentation and blogs easier if they can know that if you type it to a cuddle dashboard, grafana you'll get the graphic hooked up to your seo, or is that.

B

C

B

It's it's too much work and not natural, because again in in a normal company, there is a group that is going to a different group that is going to maintain grafana, for example in google, and I think, I'm pretty sure, in red hat and all other companies there is manage grafana. That is offered just like managing security. I'm not saying we should have that. I'm saying.

C

Is it handy to have a way to have this mesh admin? Tell everybody who's an operator I've. You know. Maybe we put it in a mesh config crd, that's just here's the url just so that this admin can communicate to his teams.

B

Sure that would be a different project, not easy. I mean it's not just your job to keep track of other things I mean. Maybe kubernetes will have some feature like that, or maybe there is a cube cattle described cluster which actually gives you that some some urls like that, if you, if you do describe cluster, you can see some of the things that are installed in in kubernetes with some I'm just I'm trying to.

C

Think of ways to make sdo easy and I often have gotten frustrated, not knowing where my katana was.

B

Yeah uh one one thing: rafana is that, typically, when, when it's managed graphana, you have a username and password and unfortunately it's not used integrated with single sign-on systems and people have problems. If you go to a url, I mean it's not a http url, usually an https url and at least for the ones that I tried. You need to type the username and password that is created in in grafana itself.

B

That's where the complexity leaves and what uh the tool was doing was. If it's graphene is running in cluster, you can do the port forward and kind of bypass the graph, but unfortunately that doesn't work very well. So I don't know what to say.

A

So how about this I mean for simple case people can use this. I think the link, the link. They also have a similar function for this and then for people already have a link for the cloud providers.

A

Add don't you have like a property configuration file, you added for central stud, maybe what they could do is they indicate their url in their property file, so the dashboard, the grifana or jager could open the corresponding url instead.

C

Yes, so that's what I want to do. It's like. I say it's a two or three line change to do what you just said, and it I think, simplifies things like documentation, so that.

C

Total dashboard grafana it would you hadn't, set this. It would currently it says no graffana pods. The new. The new error message will be no graphanopods. If you have a dedicated grafana, please add it to this config file, and then you type it you do that and then you type it again and it's just there. It's just a convenience method. It's not.

B

uh I mean, given that you don't.

C

Have a password.

B

Useless because if you, the real problem, is how do you? Actually? What do you type in when graphing opens? You need a username and password it's an https url and it's authenticated. Your browser is caching that for you, caching, from where I mean you need to sign up, you need to be added. It's an entire process for that and why I mean, do we have commands to open google? Do it? Do I go uh easter cat or google search opens a browser? I mean it's, not our documentation.

B

Just you know, I'm trying your graphic, not stupid. I mean it's not uh I'm.

C

I don't want to die on this on this hill, constant, I'm ready to get rid of it. um It's just easy to keep. So I wanted to make sure that, as a ux group, we decided that there's too much technical debt involved in maintaining this.

B

And and the user will do your capital help and we'll see 200 options and then say: oh wait, a minute just. Why is this you're doing rafa management.

A

Maybe before we have a good uh conclusion, we can just detect it's not ronnie. We can't do it for you know. So if people have it running, we can do poor, forwarding automatic launch for them as a convenience, store.

B

How about creating a grafana cattle and file a bag of bhagavathana forces? They create a grafana cattle command and they have you know it's their job. To maintain whatever is necessary to make rafana easier to use no towers, and we say hey: if grafana has a grafana cattle, then use grafana cattle.

B

Otherwise, that's why we move graphene out, so we don't have to maintain it and to deal with it.

A

But this is just open the dashboard I mean we already have this command and a lot of people using it.

B

But we're trying to make it easier easier, not by adding more features and functionalities that don't belong, belong to istio. If we believe that it's so such an important feature, maybe grafana should have a grafana cattle and promote yourself should have a prometheus cattle that have that opens their own dashboard. However, they see fit.

B

Why would we maintain tools for grafana.

C

Fair enough carsten, um we should stop talking about it now and unless people change their mind, we can either let this rot and deprecate it or.

B

Look at if you really want to keep it, I think the functionality to do port forward then detect it raphaelizing cluster. It's not bad yeah.

A

That's all I think we have, I mean the other service mesh project habits. That's the other thing and we already have this function.

C

I wanted to do the reason I wanted to do what what lynn said, which was just to have it open up a url, it's in a config file. If it's on a central 2d is because I thought, it'd be more work to change our documentation than to change the code.

C

B

You anyway, so if we just say hey, if gravity is in your cluster, just specify the namespace and we keep doing the portable world.

C

Okay- and I assume we feel the same way about jager, prometheus and zipkin,.

A

C

Same sync, okay- and we had this discussion before- and you were talking about this to a cuddle demo, but I think that's too much work um so cube inject.

C

um Cuban that's critical, it's critical um and the injection pod is in the user's clusters. It's um everything should work right, there's nothing! That's moved to centralize 2d.

B

uh That's an interesting issue uh right now. The way qb inject works, it's intended for asynchronous operation, for you know, cicd, driven installations, and it does have an option, a crazy option to actually go connect to kubernetes and grab a config map or two.

B

But I don't know if that's something that we want it's good or we want to preserve, because it's kind of it's the opposite of cicd. It means you have to have access to a live cluster and it's tied to a particular cluster, not a generic operation. So.

C

So is anyone using that config map reading, so you can, when you do cube inject you, you.

F

C

You pass it in yaml for your injector settings or it can.

C

I used it when I was sort of debugging, auto injection, but then, when auto injection and the command line stuff diverged, I think I think john howard has recently fixed that it got to be a real mess, so we could get. We could get rid of the config map. Reading.

C

um We could deprecate them, should we deprecate them.

B

B

It's more confusing and not very useful, because.

B

So by default and and the other problem is how do we simplify a bit? So you have a template. Okay, you have one config file. Okay, but now there are two config files. There is mesh config and values. Dot and values is the one that is crazy.

C

Yeah it got frustrating when there were three different maps you have passed into it.

B

Now there are three yeah I mean it's still three, so we need to make it two.

C

Okay, so proxy config and proxy status have had a lot of work recently, register and de-register have been deprecated um validate is completely user command. This experimental post install is being deprecated and removed already version. We want to keep.

C

The add to mesh and remove for mesh are fairly the same. The security team is redoing, uh the auth z command. As we speak. I think um we talked about this at another meeting. I can't tell you what we said: we're fixing describe.

A

Create a remote secret, same admin, command uh operator yeah, because it's creating the remote secret to be able to access the remote cluster to read the endpoints and some of the other configuration.

C

So I was, I was unsure, especially in like a hybrid cloud situation, if great, if, when you join clusters to your mesh, if that was something that uh a mesh admin did who said, you've got a mesh here. I want to add my cluster to it or, if that's something that cloud did. What do you think then.

A

And so I would think that's that's close to like multi-cluster installation, so we kind of like the operator sides of the mesh and they would need to do the create remote secrets.

B

C

And operator a usb mesh admin adds a cluster to a mesh.

C

Is this? Is this the belief you could use this for both scenarios.

B

I think so it will be hard to change otherwise, because we need secrets from the config cluster. So is that something where the mesh admin has permissions? To that's a good point.

A

Yeah, so basically it would be mesh admin and say you know, hey. I want to make this a multi-cluster mesh and then the mesh operator would make it happen right and they could be the same person in some cases.

B

I I guess we are multi-cluster by default, because one cluster is running htod and one cluster is running the config, so we are already multi-cluster. So you add more clusters.

A

That is true, except that the external sdod actually needs way more permission than create a remote secret because create a remote secret. Most of the permission was just read permission, the external issue. They need a whole lot more, so we don't actually use create remote security for external code.

B

Not for for the primary cluster but for the secondary clusters.

A

Yes, I agree: yeah.

C

Should we should we be writing a command to either produce the yaml or directly apply the permissions to let this work.

C

I want to make environments, do the work, but I I want to help with how it is used.

B

Yeah environment is trying to do as little work as possible because less work means fewer features, move.

C

C

Bootstrap um kiali do we. I I put dashboard keali down here separate. um Obviously, if we're getting rid of grafana, we should get rid of dashboards. I know um how keali would be working in a centralized situation.

C

Doesn't it need special stuff like like? Should we because keali is totally our thing? Can we do things to help the gyali team to put their stuff into our role playing.

B

I don't think it's they depend on on the operator, just a regular pods that is running in some name space. We need to make sure they are not initial system but other than that uh they're using the apis. Only.

C

So we should deprecate ours. Currently, this thing brings up a cali yeah. They.

B

Should take care of that and think.

B

And I wonder if maybe kiali team should, if you say, create a dashboard query, maybe they should also create a dashboard graph and graph dashboard, prompt use and so forth. I mean there is a business of ui dashboards.

B

Maybe they can have a link from hyali to grafana and promise you some other things they already have links actually.

A

B

Are for sure so maybe.

A

B

Yeah, so maybe that's a better solution to to just pass. uh Tell kylie hey, take care to take over dashboard and have a hyali cattle and that will take care of grafana, jagger and all the other stuff, since the absolutely need is part of their business. They know where jagger is.

C

Fair enough now, should we divide these commands that we've divided by privilege into two things, two actual binaries or do we like is to cuddle doing it all spaghetti who doesn't like spaghetti.

B

It's it's. It's a big binary. We don't want people download. I know I agree. I mean even kubernetes split cube cattle from.

C

So, do we want a seo admin that.

A

C

All these things.

A

Well, I don't know, I mean how much I mean all the download is pretty fast. For me, it would be harder to actually figure out which one is which and have two binary.

A

Unless you know it takes a long time to download- and we don't have that issue and I think we are actually separating our chats out of israel cuddle. So it's your color is going to be smaller much smaller.

B

No, but but if, if there are commands that you cannot execute because you're not an operator, what is the point of having easter cattle help show you half commands, you cannot do, cannot use.

B

And second, uh if you are an operator, you know you probably know what you're doing and probably it's not a problem to have issue admin installed. So if.

C

We wanted if we want to do something for the next release. That would be easy. What do we think about a sub command called istio cuddle, istio admin, so um we would move all of the commands underneath there that would that would clear up what you see when you type it still cuddle. I.

D

And I think I think that uh this this is actually uh not not a big uh work item to to offer uh both options. Actually um I mean we can we can decide, but uh but um in any case it's going to be based around the the cobra command framework we already have and- and uh if, if you have that, then it's a pretty trivial um effort to include it into istio cuddlic if we want or keep it as a separate binary right.

C

The code, the code is trivial, so moving all these commands to have two places for one eight and then move to their final place is easy. The question is: what, for what do the users expect right? We we don't want people to be.

C

We don't want users to be overwhelmed when they type is to cuddle, except to see to see commands like operator and profile that maybe they can't use. If we could get half of these commands out of here and hide them under istio cuddle, istio admin or istio cuddle admin that might help it would just be moving some things around in the hierarchy.

D

Right so so I think that part, I totally agree with. I, I think whether we put it under a new sub command and then you know require uh istio cuddle admin uh versus having a separate binary. um I I think that that part is pretty easy to implement.

D

um The main question is, you know like how do we decide which which way to go.

B

So why kubernetes is okay, to have cubad mean and cube cattle, and we are not. I mean, what's what's different between kubernetes and us, that make us so much more.

D

I I mean I, I don't think we would not object.

C

We would go to that in the future cost and I think this is a way to get there slowly right now, every user has been installing sto themselves, so they might, they might be befuddled by two commands. No.

B

No, we leave the commandance. It is because we cannot change backward compatibility, but we are the keyboard main command. That has only the admin commands and we deprecate and change the start stage changing the documentation and when the documentation is changed, we can start stop using. So I'm not saying now do that, but just start the issue admin make sure that all the admin commands go into histo admin.

C

So what I could do is start producing this istio admin command with all this stuff. As as martin points out, it's just a couple dozen lines of code and then we could see what it.

B

Feels like, or maybe the opposite, I mean, maybe start a command. I don't know how to call it, uh but uh that has only the user visible commands.

B

So it's a command for someone who doesn't have permissions to the to the entire thing just have permission to maybe to the main space to see how it goes. Basically, the tool that is, I think.

C

It's too late because we have three years of blog articles about using steal, cuddle to say we have a new name for our command.

A

How about another alternative issue, so we just have one command and user tell us which one they want to see. I mean so if by default they can see everything but their admin or maybe by default they can only see the user command and then they can configure to see everything or just the admin.

C

That would be easy.

B

Too, but why kubernetes I mean if we understand why kubernetes choose to go this way and I would.

A

Be happy to yeah, I mean cube, admin wasn't there, but when cubica was there, that's my understanding.

B

They could help with it, they could have created, cube cattle admins or could got to create clusterers.

A

And I think they are, they were created on different team also. um So it's not like us we're being cuddled together at the beginning.

D

So I actually think that it's it's worth finding the answer to that question because we may be assuming that they did it after you know some lengthy uh deliberation, but it could be that that they did it for some some completely different reason, um and if they went through deliberations they they probably have some some good reasons for doing that, and.

B

I I I can give you an example. I mean we have jk in kubernetes in google and that you know it's a managed kubernetes and that's the job of google to figure out how to install and keyboard main doesn't apply same thing. With this I mean we having google have traffic director and we have you know kind of other managed estiods that we can run where the user will not have to have any way to administer it.

B

So that's why I would prefer to have it separate because cuboid manually for people who manage their own issue, but everyone else will not have the impression that they have the power to do anything after because they will not. You.

D

Know I think, I think that um kubernetes and istio are are slightly at different stages of maturity in terms of being a managed offering.

D

um I think kubernetes is much further along and- and you know maybe maybe the the balance between sort of users who are both admins and users is is, uh is greater in the easter case towards towards people that are doing everything themselves. At this point, I think it's.

B

D

But you know I'm not sure where.

B

That's how it's changing I mean by by by making it clear that they're separate. So you know you can have a managed issue and you can have separate role and you have separate commands and you are not required to I mean. Even for multi-tenant. We agreed that the api is the line of demarcation and you should not assume that you are running an sdod to have a talent.

D

So so I I agree, that's that's the end goal and, and you know I I believe that that's where things will end up. I I'm just not sure how far along we are at this stage, and you know where yes, actually.

B

If we know that saying goals, then we should, you know, move into that direction and not create additional confusion for the users. That's my point.

A

Yeah, so how about we do this gradually, so it's cuddle shows the user command by default. Admin can toggle a configuration to see their the admin commands and then over longer term, when we feel admin absolutely needs their own. It's admin, it's your admonicado. We can break out if you need it.

B

Yeah, it's that's not really. My concern, I mean I don't really care about that means because, for example, in google probably not use this to admin at all. uh My concern is for users who are just using history to not be confused by having some commands that have no effect and uh or worse. Who knows what will do.

A

Right, that's what I'm saying we just make. It still kind of just show the user, but then admin could optionally enable something to see the admin commands. Hopefully there are more users.

B

So basically, hide them less work. Okay, so we hide them so from the help and our order.

C

Okay, that may work we have viper, so we can make it all be hidden by a single environment, variable or config file.

A

C

So we went over. Thank you, everybody, uh everybody who wants to please review the pr for um supporting um type, slash name instead of pod name and istio cuddle. Thank you. Everyone have a good day.

A

Thanks so much.