VMware Cartographer Community Meetings, 8 Dec 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Cartographer Community Meeting - Dec. 8th, 2021

Description

00:00 Intro and welcome
01:07 The TL;DR - What's new in the project this week?
06:19 Follow up from previous meeting
09:22 Open Mic (Issue 430 Remove RBAC Informers)
21:07 Permissions and ServiceAccount discussion
31:23 Provide more informational error messages
44:51 Next version numbering

Community meetings happen each Wednesday at 8:00 AM PT/11:00ET
See the agenda here (https://bit.ly/2Z67z08), add any topic you may want to discuss and join us live!

A

Okay, hello, welcome everyone to the cartographer community meeting today is december, the 8th and uh well, let's get started. Let me share my screen with the agenda uh there. You go okay, yeah! Thank you, emily. I think I have to do the same. You know there my name under the ad in this list that will help us to keep up the conversation even after the meeting and remember all sessions are recorded and stored in the youtube vmware cloud native apps youtube channel under the characterographer community meetings. Please playlist all right um welcome everyone.

A

We don't see exactly new faces, but we are happy to see you here um again. Okay, so the pldr um is our first section where we try to summarize what's new in the project this week, what team is working on? I I try to contribute at least one item there.

A

One thing that it's definitely new and it's uh it it will be really useful for the community out there, it's having architecture and troubleshooting docs, uh it's open for feedback. I've been reading it using it and it's you know it's sent from heaven, because I I, as a user I've been longing to to have this overview and see you know visually to see all the concepts how they relate to each other.

A

So um it's going to be very useful, but again, if users out there have opportunities to improve and uh they have ideas or suggestions to the dogs, uh please please feel free to open up issues.

A

um So so we can preach and and work on it and also there's a new um troubleshooting section. Troubleshooting guide. All of these. You can check it. um You, you will be able to see it right now in the development version here, um and it has. You know it's it's very informational, because I I found this problem uh several times. You know the missing value at pat and uh not having a clear.

A

um You know not having clear guidelines on what to do next. So this is really good because it has uh you know, missing value output seems to be a kind of generic or one of the most common unknown states, and it has information what to do on different conditions. When this message can come up, so thank you for for this. Thank you to tim for working on this.

A

It will be really useful and for folks out there again, it's open for feedback.

A

That's great there you go, I think it's there so yeah. I will say that I don't know if someone else from team would like to summarize what was new and what team is working on. I will say that a good chunk of the work right now has to do with docs, but I'm sure there's more so.

A

I don't know if yeah please go ahead.

B

Were service accounts new this week, yeah they landed this week right.

A

B

B

You could be wrong. There might have been last week, but it's still very, very useful stuff that came in this week.

C

Yeah, I think we talked about reducing controller permissions last week.

A

Yeah right yeah, there you go yeah, it was last week. Yes,.

D

A

Not a problem yeah, it's a it's a big one, because it was even oh a lot of comments. It was even at the top of our readme page. So it's it's great to see it. There.

A

That's it anything else on a summary of what things working on right now.

A

E

Sorry as muted um no yeah, along with docs we're working on getting some new, uh our example has. We've always had one example and we're looking.

D

E

That into kind of a tiered example, here's like just get your thing to prod. Here's get your thing to broad with testing. Here's get your thing to prod using uh get ups flow um and then also on our um short-term horizon is uh upgrade testing. um I think we're just to the very beginning of that.

A

F

Just a question is that upgrading of card talk for itself or say upgrading a supply chain.

E

Upgrading making sure that we upgrading cartographer itself making sure that, when cartographer releases, a new version, it'll be a smooth experience again, I would say that we are at the at the opening stages of that story.

F

Yeah, it makes sense cool.

B

And there was also infrastructure testing started this week too.

A

Okay, great, thank you. um Okay um from previous meeting, we had a couple of action items, or one of it is uh already in the works. I've been talking to hector and tiffany on what will be working on the demo for the cncf that we discussed in the in the previous meeting.

A

They see it's a great idea to come up with um with a proper demo. You know meeting the requirements there that we discussed uh last week. So that's already in the works, and there was another two. It was to run a naming exercise for the blueprint classifier.

A

So I don't know if that's something we could do right now, because there there were several ideas. There.

B

We have cemented on blueprint and owner at the moment in the docs, not that I'm against it being reviewed. But it's was the idea that there was going to be an actually like a well-structured naming exercise.

E

A

E

A

Yeah he's just that, I haven't run a naming exercise before I think it's it's more on the pm skills, but um but yeah. Certainly, I saw in the dogs that blooping blueprint and honor is still there, but just to mention that there are several other ideas and we could with a little help, and you know to structure a proper naming exercise if there's a need to um change naming for those um for the class. First.

E

Yeah same for myself, I I find, I think blueprint is a great name. um I'd be voting for it. If, if we ran such an exercise, um I'm not super hot on owner, but I also haven't heard a name that I am super hot on, so I don't. I wouldn't want to take precious cycles to spin on that.

B

Maybe the recommendation here is until someone gets upset, we just settle for these because they work and and they are defined in the docs at last- which I think helps a little.

A

Okay, I agree: that's great cool um great now, for I don't know if there's any other um regarding blueprint, if not, we can move to the open mic discussion. This is from marty. I believe.

G

We talked about this in the uh office hours meeting and I had to drop a bit early, but this was the uh the outcome was. It was decided that we would remove the arbec informers because of the issue with the informers handling a lot of the same art logic that the controllers have, um and I did. I left some follow-up questions in there. um I see scott answered a few a little while ago, um but yeah.

G

I guess I just wanted to revisit this discussion, because if we remove them right, like scott, you said what about the regular back off for a failed reconciliation.

G

I like the problem with that is, unless you really fix the rolls within the first minute or two, then who knows how long you have to wait till it reconciles again and then it's essentially useless you may as well. You know if you're just gonna end up deleting and reapplying your workload, so it I think the the default back off is useless for people in that regard, right um and so like. If we say we'll reconcile every five seconds, then you're, you know once we have this permissions failure.

G

Okay, so then we're gonna just constantly have logging of constantly reconciling with the same error, or do we say: okay, fine, so we'll limit that, like this said, like long polling like sounds like there was some sort of time frame, we thought was reasonable. I was like. Is it reasonable to do every five seconds for 10 minutes like like? It seems a little bit arbitrary at that point, um so I don't feel like there's a great solution to solve this without informers.

G

Unless we want to say like okay, this is one thing we don't inform on, go for it so.

B

I I s you had to leave, which was unfortunate, but the I dived in and what I was just hoping to get to was.

B

I think it was more of a heuristic that that, having sort of like controller code yeah like in an expansive mapreduce felt messy to you, and I understood that and I feel like we could remove that complexity there. We don't need to go, adding it anywhere else until users have serious issues with or take serious issues with it. So the heuristic is.

B

Why don't we wait to see if it's a big problem for users to do something other than either use an exponential back off? I personally don't like the exponential back off, because it can make debug a little hard and noisy I'd like it to be for really truly exceptional scenarios. So that's why I was asking: could we just use a long pole and a long pole that still lets users get something resolved, maybe before they go? I'm done with this and I'll delete and reapply all right. I was thinking 10 minutes or something like that.

B

You know, but that's where my thoughts were in asking this was just to keep the code light until there was a real user concern that meant that our code needed to be heavier than it needs to be or or than it is today.

G

Background totally like, as a user myself, I've ran into this issue like when we were first doing this and we limited the controller permissions. The first thing we did was.

D

G

Apply a workload and just see which roles we absolutely need to get going like that's how we made the example and it was brutal to keep deleting reapplying and that's when we said. Okay, maybe we should have performers and, like I've, seen conversations in, I don't know how which slack they were in but like I've seen conversations where people said like. Oh, I have this error. I'm missing a permission and the answer we've been able to give is just like add this role and you'll be good.

G

Now the answer is going to be add this role: either wait a few minutes or delete and reapply your workload and, like that's only anecdotal so, like maybe you know, maybe more users won't hit that, but it feels like they're going to, and I did like I did like scott's suggestion of kind of doing kind of both like keeping the controller logic out of the informers and so like mapping a service account to a workload can happen in the workload and it can.

G

We can create an in-memory mapping, but the work of like a role to a service account has nothing to do with cartographer's inner workings, and that can stay. You know higher up, but I'm just nervous that this long pulling is a light solution that won't actually end up solving anything, and it's not worth it.

B

Then why don't we keep the code? You've got now until more misery arises.

B

Another like the code. You've got is working right. It just doesn't feel help all right because it solves the problem that you you saw it just maybe doesn't feel architecturally as sound as maybe something else.

G

Like I think, it's not just in this case right, it's also in mapping workloads to supply chains and deliverables to delivery. So we have the same problem there like now that we do best match labels. We have to do the same best match in the informers to make sure we're actually informing on the right.

G

You know we're actually reconciling the correct workloads and, like we fixed that or there's a pr to fix it. I think it was emerged like to fix in the informer. So it has the same logic that the controller has for best match matching.

B

uh To be honest, I think that the the mapreduce functions that make that make up the. I want to be informed for this, uh because this controller needs to be informed. When any of these things change. We can just wholesale pick up that logic and put it in the same name space as the reconciler for it, and then call that from the call that, from the the notif, the sorry words escaping what we call a watch, informer and former. Thank you from the informer and then we would at least have localized code.

B

That makes sense is why it exists. We can test it in isolation and still depend on it until such time as we need to do in-memory maps which I think are riskier personally, um but scott does have some suggestions that there were. There is a tool that we should in maybe investigate the. I think it's the k-native one that is designed to set up in memory mapping for informers is that right, scott.

A

H

I wouldn't necessarily use the kind of implementation, but that pattern yeah.

B

H

The general pattern is that as you're reconciling the resource, you basically know what resources you need to actually successfully reconcile a resource. So as you're going through, you can basically say this is a resource that when it changes, I want to re-reconcile the resource that I'm reconciling um or at least add it back onto the test queue.

H

So basically it's that case you're defining the mappings there so that later, when you're watching informers for those other types of resources, you can then inverse that listing and then reschedule the appropriate resources.

G

Could we dive into what I actually think I like the the risks of that exactly.

B

Yeah so, like I mean scott just said, you know, I wouldn't necessarily use that one, I'm like oh wait, so it what we create our own or we find one that we make sure is tested well and then that we now adopt a practice for testing that those mappings work and that we do also delete them so that we're not creating unnecessary or maybe we don't care, but I feel like over time, we'd start to build up the size of the cache and we might want to not when we have deletes and make sure that we do the correct like if something if a reference in there is now changed, because we do that a lot when we apply.

B

We now have logic to say: take that one out and put this one in those are my concerns. Whereas mapreduce is very straightforward in my mind, uh and I wouldn't recommend it if there wasn't a client-side, uh transparent cache which we get for free from controller runtime. That's why I recommend it because it's very straightforward to say from these map down to these results um and they're, easily tested versus uh an in-memory cache. My producers are just, I think, naturally, easier to test that those are my my thoughts.

H

And just to clarify my only criticism against the creative one is just that it is included inside of creative package, which has a bunch of other stuff and a bunch of other dependencies. um So it's kind of a big dependency to bite off.

B

So so a copy paste.

H

That's effectively what I did to pull it into reconciler one time which is that's.

B

A capex library.

H

Yeah, I think kpac is still using the canada package. If I'm correct, maybe they switched away from it. It might be, um but uh I basically did that copy paste into reconciler runtime, uh which is a library that I maintained, um but you could also copy this in something else. So like it's, it's it's one type with like a helper function. It's not that much code.

B

I still, I still think a couple of the things I mentioned remain, which is you do have to be aware that the graph is no, it can get invalidated and maybe there are side effects to that. All right. You don't necessarily.

H

Care: um okay, because what happens is that worst case is you're, just enqueuing additional resources to be reconciled so like reconcile an additional reconciler running against a resource is like a no op. If there's nothing to do so,.

B

It would be in memory a little bit of there would be in-memory growth or something like runable. It would just constantly grow. If we didn't remember to prune it. I think there.

H

Is the one the one that's implemented? uh Basically just has a time-based exploration of the keys.

H

E

Also like so, it's basically set by.

H

Default at 2x, the resync interval.

B

Oh so that it gets so, the resync causes it to be rebuilt anyway. Okay, so I was about to say, that's pretty tidy.

H

Yeah, I mean all credit to the design, goes to the canada folks and I don't know where, if they copied it from somewhere else or they came up with it. But it's not original to me.

E

I'm concerned we may have lost our host. Oh, oh, no, never mind.

A

No sorry somehow sharing was posit. I don't know um no, but I'm still here no problem yeah your.

E

Screen wasn't it wasn't.

A

E

A

Okay, great um great discussion, anything else regarding this specific issue, I think it's an ongoing conversation.

B

Oh, I think the action item is that if it's meaningful enough, there needs to be a some demonstrable code, written right.

G

Yeah, can we leave the code, that's in there now and then have a separate story to just switch out all the controller logic go ahead and write up an.

A

Issue for that, okay, great, so the action item will be to create a new issue for.

A

G

Yeah yeah refactoring the informers- I guess during okay.

A

Okay, and that will be you, marty.

G

A

Thank you, okay, great okay, for next one.

A

E

um This is just in writing the examples for users of cartographer there.

E

I wrote this sentence, it's, it is true, it's how cartographer is set up right now and it seems to cut in direct opposition to one of the goals which is developers shouldn't have to know. What's going on with the workloads and the way permissions work right now, the developer has to know exactly what the workload or the developer has to know exactly what the supply chain is going to stamp out in order to create our back rules for the controller.

E

To do that, stamping um and I just yeah- I uh didn't didn't like writing that sentence, and so I wanted to bring that up at a meeting.

G

I just put a link in the chat um you can. The supply chains can now create and reference service accounts at the supply chain level, and so, if the developer did not fill out the service account name field, it would default to what's said in the supply chain, and so it could be on the operator. If we want to write the docs in such a way that the developer doesn't care, we could put it that the onus on the operator.

E

Yeah, I think that is a better, a better default yeah we'll do.

I

Was this about just the service account name, or was it also about creating our back rules for the resources in the supply chain?.

E

uh It was whose responsibility is it to reference that surface account? Is it the developers or is it the operators.

I

We allow that to be specified in both places, so you could just do it over your side. Okay, that makes sense. There's another question of like if you're setting up our back rules, you probably don't want to set star, and so then the developer for to set our back rules for that service account they may need to. You know explicitly allow the different things in the supply chain to be created.

B

I

B

A really dumb question, but would it be valuable for like discovery that a supply chain template can specify the can at least, if well, designed, tell people what our back rules will be required? So they could be collated.

I

I I think we could distribute the templates with cluster roles and then create like an aggregated cluster role, for all the templates that the um in your name space. You could use a role binding to reference, and so then, then you wouldn't have to kind of deal with that problem.

I

But it seems like this is different than what.

D

E

It was, I didn't.

I

E

I

E

With those cluster roles, I think the when you say then you could. I guess my question is: are we saying then you as the developer, which is what I think when I hear in the name space, that it's the developer's name space, um because then it goes it I like I, I totally hear you. I think it makes total sense to have the templates to say here are the permissions I need and then to roll those up to the supply chain.

E

The supply chain says: hey included this template, and so it's uh its included roles are going to be bound to the service account that I'm using and then when, when the developer's workload comes along and says hey, I got this code. Then cartographer's, like yeah, we'll we'll stamp out your code and you shouldn't need to know what permissions some template that you may never see require.

I

I I think there are a few things as part of that somebody or if the service account is in the name space, because in both both the case where the service account is specified in the supply chain and specified in the workload the service account itself is always in the name space. In the operator case, the service account is just like a way to say the default service account name in the namespace. Is this? It's not setting an operator specified service account, and so that.

G

That's not, I don't think that's how we implemented it right, because we.

A

G

Service account ref, so you could specify the name space diploma service come from, so the operator could configure the service account.

I

But if you don't specify the namespace, then does it it just picks the one in the namespace of the workload is that right, yeah and that's. I thought that was kind of the configuration we were going to uh advertise, but maybe that's a different different topic, um because if you use a shared service account across all workloads, then it you're kind of like it's like a little bit of a privilege.

I

Escalation users can specify configuration that gets embedded into the templates and run with something that has maybe more privileges than they or has privileges across you know more than one namespace.

F

I

That's a whole other thing.

F

I did wonder what do we know what privileges we would expect developers to have, whether they do we call out? Do they need to be able to create roles? Or you know? What's the minimum set of privileges are about privileges that we think developers should have so they can't, because they won't be able to create it well potentially, to have that.

H

Definitely in a multi-tenant environment developers will be unlikely to be able to create roles and role bindings, because that itself is a privilege, escalation, yeah.

I

My mental model for this is like operator provisions namespaces for developers. Those namespaces have a role binding to a aggregated cluster role. That gives you know the service account. That's also created in the workload namespace access to create a specific set of resources, not all resources within their namespace, uh and then the developer just creates the workload of the namespace, and so it's it's tightly restricted to the namespace.

I

There's no shared you're, not sharing a service account between you know, kind of many different principles and different namespaces and developer doesn't have to create something. They probably can't create.

B

But there are two alternatives, one, which is that you could use a namespace specification to go and find it so that it's shared and that's at the supply chain level.

D

This is the current.

B

Truth right, I just I just wanted to understand. What's there and the other one is in the workload you can specify uh within the same name, space.

I

I think all three of those in service account yeah. I think, all three of those work with the current implementation. If you don't specify a namespace, a service account that's specified in the supply chain, it means use the service account in the namespace of the workload when you're, creating the resources of that workload.

I

The names allowing the name allowing you to use a shared service account for all of them. I don't think, is a bad idea.

I

I could see that being useful on some platforms right, especially if you're like a smaller cluster with less developers or whatever, but I think it is inherently a less secure configuration because it allows you to get configuration into you know something that's going to be set by a service account that has you know, potentially access to things outside of your namespace on the cluster, and so I I I don't know if I would recommend that configuration first, although I think we should document all three workflows and describe the implications. This.

B

Is where I was going with this? Actually, because we have a story up for it. I think we're going to pull it today or soon to write something similar to our architecture document, something diagrammatic, something useful, something with warnings about what's best to use, and so we might ask who wants to he wants to help us make sure that we get a good review on that. I'm going to ask you stephen what about you james? Would you like to yeah cool so yeah, whoever whoever does pick up that story?

B

I suspect it might be me, but whoever does pick up that story. It'd be great to uh to yeah include james and stephen on the review request for it, and then we can make sure that it's accurate and best in class or whatever we want to call it. You know putting the the least security model forward as much as we can at least privileged sorry.

I

Happy help sure.

A

uh The issue the issue is created, it's just.

B

When the uh when the pr is created would just like to pull in some people, david.

A

All right, okay, so that will be looping.

B

Ask for we could just yeah ask for a review from steven and james.

A

From stephen james.

I

That's definitely I'm only I'm only here two more days this year and then I'm back in the middle of january. So um if I don't respond after that point,.

F

Just not to stitch scott up as well, but yeah it might be a have quite beautiful to have another set of eyes as well, just from the happy two from that experience.

B

Yeah, I was waiting for him to to to actually volunteer.

F

A

Okay, is there anything else you'd like to discuss here, no.

F

Well, I just wish I had one very, very quick thing: sorry if it almost went, but maybe I'll, follow up and add a comment, but I noticed um on the troubleshooting, which is looking really good by the way, um I think one of the things I've felt with it's hard to know sometimes where to go. Look for the next debug message.

F

Well, I just wondered: if there's any brainstorming thoughts we could have around, how do we always kind of help users with the next command that they should run to go and look at you know investigate further issues um like it's a k-pac, always an image thing?

F

Is there a more helpful thing we can say like run this command or I don't know when.

B

They're, open source sure yeah yeah yeah. Well, sorry, not when they're open source, but when when when they.

D

B

Yeah, when they're they're, like the likely thing to find in the supply chain that you're using in the open source project, I think we're working towards that. All right I mean we can, but the thing is: is that it all?

B

I feel like it's not in the troubleshooting, it's maybe in if you happen to be using kpac as one of your templates, here's troubleshooting for that stuff and we may create categories for that, but the broader troubleshooting is, I mean correct me. If I'm wrong, you all can say that this is probably a bad approach, but the approach I took with troubleshooting is at the moment to assume that it's just the part the you created your supply chain, whatever it might be.

B

You created your deliverable whatever it might be, and you might just be using job and techton you might just be. You know what I mean.

F

Yeah well, where was pondering with that was? Could we is there a way to catch what uh you know in the era whenever we detect an error, we're about to update the message on this message status on the work note almost if we know the gbk to say, okay run, cube ctl describe uh this. This resource in this name space kind of thing to help give the user the command to run to get the. So that is in the.

C

Troubleshooting yeah, that's what we tried to do, though, right like the the message: that's there is basically everything minus to keep cuddle like we tried to have the the group and every you know the name, space and everything so that they could just that's.

B

C

B

C

B

Message right, there status message.

E

That waiting to revalue.

B

Yeah yeah, so you literally, we formatted that in the in the sense that you would do a you would do a cube, get you could just copy and paste. That was very important right.

B

That's the thing that me and emily focused on with that was like, and then we explained to do it but you're saying maybe let's lift it all the way into the message. It's just.

F

B

F

Yeah, the actual the actual command, so somebody in.

C

The issue with that is that this message isn't necessarily an error right so like telling them to go run. This cube federal command when we might just be waiting for the status to be filled in might be more misleading.

B

Well, we have to say all of that as well and the message if this takes a long time, you might want to run.

F

Yeah, I mean maybe there's something just people thought like as well things in the future, just yeah just little tips or something just to help, uh give a bit more information about people to go and find information.

B

I know, let's make sure that at the bottom of our status, if we're ever in unknown or or false, that we say see troubleshooting guide, link to the website.

B

Take you straight there we can even we could even embed links specifically to the ones that are most common like if we see a message for uh what was that one um missing.

D

B

Path- or we can take him straight to the anchor on that page for missing value apart. Do we hate.

F

I that personally I I quite like that I've done some things in the past with their with health checks and things like that. It it helps um and maybe on the docks. Then you can have. You know, there's go to the community. If this is beyond all various, it's just giving people a bit more information of how to go and find information I mean. Maybe we can rift on it a little bit more, but it's just that initial thing. Initial experience of okay something's, not quite right. Where do I go next?

F

So maybe, like you say, faq troubleshooting, that's a good initial step and we can try and get more informative in the state's messages over time.

B

As long as it stays consistent, I think it also just needs to be really easy to to make sure that we consistently apply a new uh new guidance. All right and that's.

G

We're gonna have to update the version in the link. Every time we release a new version.

B

uh I think the the head will always be safe enough. You know we could always go to development. um Actually, no there's.

D

The public version.

B

As latest yeah so slash, this works. What, if you're running an old version.

D

C

Update your information.

D

Yeah yeah, that's the first thing in all the.

G

Troubleshooting.

D

B

B

I shouldn't say tough, but you know, I think I think most of the time they shouldn't be so drastically misinformed by going to more recent troubleshooting for that for that message, unless we do breaking changes and hopefully that will start to be a thing that we do in significant version changes.

G

Speaking of which, I think we want to discuss the version number for the next release, or is this not.

E

The forum- I don't know, I think it should be fine, but I I put tree and q logs in there so stick that under let's.

D

E

And I I thought of this because of what you were asking about: james, how to help users troubleshoot even better um in some of our examples again, some places in our code base. We do like talk about uh uh cube cuddle tree and how that can help. You see the dependency graph.

E

I don't know if we want to put that into our uh into the troubleshooting guide as well. I'm not totally.

B

E

Already be in there, no.

B

There was a strong bounce back for me on that, because I was going straight there because nothing better than k-tree right, so the problem I run into is, I think, it's great to advise on it and I think there may be a section on it is the right thing, but I definitely wanted to avoid then putting that everywhere.

B

Like I don't want the troubleshooting section you get there and you start to use commands that you now have to make sure you've installed all right. I wanted it to be as and so that's my guiding rule for this, and it could be that that shouldn't be it, we should say, look minimum. You want to debug this thing get tree installed because it really.

F

B

But that was just so. You know where my head was at with the first cut of this was kind of like hey. Can I can I give people enough info to get them going as though they're not using anything special, maybe they're, running on a you know, on a business provided, laptop or and whatever the rules are wherever the person lands? Surely they've got cube cut all they might not have anything else right?

B

That was. That was the intention, so I think maybe putting.

B

I think maybe like there needs to be a section on understanding the uh the target objects, which is why the way we descend the tree in the first step on each of these bits of debug is well here's, the output that tells you where what the thing is that's being owned that we're waiting on right. You don't need to look at the tree to see what the sort of like general status of things are, but maybe there should be a section on that and there is actually a cube cuddle command.

B

That will give you a list of all of the things owned by another thing, and so again, I'd probably try and use that over using tree, and then maybe have a note as footnote. Why don't you try using tree? It might look nicer for you.

B

What do you think.

E

E

One that that approach that you were talking about makes total sense to me yeah, let's, uh let's allow them to troubleshoot with the with any tool that they have. um I personally would push a little more forcefully on hey here's, a great tool, um not just in a note but like hey, the developers of a cartographer use k-tree all the time like.

E

Maybe you should too.

B

Or maybe you could follow an issue for that, one just so that we track that yeah.

E

Happy too, um and then on a similar note, uh there's this code that was written by folks that are on the team q logs uh some members of the team use it.

E

I find it very useful, yeah, essentially a tool that will allow you to say, like here's, the workload what's going on in the logs of these objects that we've created- and it just tells you um one- is this the place to discuss like that tool and to if so, what do we think about making that tool available to others?.

B

I couldn't even get it to work, so it would have to be some effort on the behalf of our team to make sure that it's portable and usable.

H

Do you have a link to that.

E

I do it's yeah, it's it's a private repo.

H

G

You'd have to start maintaining it. If we're gonna tell people to use it right.

B

I mean maybe the person who created it could create a public personal one, and I still think if it's not well maintained, then it's probably not something we should push as part of the project, but at least then it can be just mentioned.

B

You know in chat and that sort of thing see if this tool works for you um yeah. I'm also happy to put it on my public personal, open source project. If no one wants to host it somewhere, it's like pop sites together, so those sorts of things don't care.

B

I mean if it's useful, we should share it, especially if we want someone to be able to use it, but I'm just not sure that we want to adopt.

B

Is there an alternative.

E

I haven't seen one just.

C

Run the command for each object that was created- that's I mean like which is pretty standard, so.

H

What are you looking for to log.

E

It doesn't log it it reads logs. It gives you in the in the same way that logs or yeah, in the same way that tree lets you see like hey, there's this dependency graph, like here's all the stuff. In that graph, q logs is like hey here's, the top like I just specify the top level objects, and then it's like hey here's the logs coming off of all these different child yeah.

H

The the two tools that use most commonly combat are either tail k-a-I-l or stern s-t-e-r-n, uh and both of those will allow you to specify a label selector and basically just grab a bunch of pods um or you can start getting more advanced like kale will allow you to specify the name of the deployment or the name of something else and it'll basically just go find all the appropriate children.

H

What's really nice about both of those is that it'll? It sets up an informer for the pod, so, as new pods come and go, it will basically automatically show the output from them.

E

Okay I'll check these out. Thank you.

E

Okay, I think it's I see k-a-l-e. I think it's supposed to be k-a-I-l.

E

B

Oh yeah, that's exactly what I was saying yeah I was going. I assumed k.o.k like a little oats.

H

It's kubernetes tail.

A

Yeah that one great yeah- but here you have to agree that this logo is great.

A

Okay got it. um Thank you, um okay. That will be next item. Next version number muddy.

G

Yeah, so we are still on 0.0.78, whatever we're listening, we're up to like eight now, so we have rc's out for 0.0.8.1. When do we want to bump to like 0.1 or 1.0? Even it would be nice to start following some ver for real at some point, preferably soon, um but if we don't feel like the api is stable enough, yet maybe we're not ready for 1.0.

G

I don't know I kind of feel like it is, but.

E

What do y'all think um one I mean.

E

I there was a meeting where there, where we were asked to consider the name, delivery and deliverable. um I would not. I would like to get buy-in on we're sticking with this or we're changing it before declaring 1.0, but I also don't know if it matters if we've, if we're going to have to bump our, are we keeping two versions, there's that that summer version and then there's the v1 alpha one?

E

What what are we doing with that? Are we going to v1.

C

We can save you an alpha one right, there's no reason to to bump that. Yet.

B

I mean I'll just say that most kubernetes projects- much to my, I think, it's rotten, but most of them never hit one never hit 1.0, never hit p1, it's like. So when can I start trusting in cenva, so I'd love to see it, and I think it's a great thing to bring up marty. I also just think it's. The thing that we need to say is our one of the one of our sort of like goals is to get to a one uh 1.0, but to do so mitigating risks of getting there too soon.

B

I'm a little concerned about maybe there'll be some restructuring in our open source project as well. That might mean some renaming and it'd be frustrating if we went to 1.0 before we sort of thought about that.

G

That's fair, but do we even if those restructurings happened, would we expect to make breaking changes at this point or would we have you know backwards, compatible changes.

B

I'd be wondering about the about the gbk that that's all I'd be wondering whether that was likely to change.

B

Especially the g, but also the k's, the k might change still.

F

Maybe it's best to hold on a little bit and see what comes out of the coming weeks. I guess, um having a 1.0 does suggest to outside world that people can confidently build. On top of this, I guess, um but I guess also the other thing I'd say is, I think, there's two parts to originally there's the the component of cottonwood itself. There's also the apis in there as well, so like the versioning of the of those apis.

F

But you said there are other like other projects that probably are still on alphas or betas for their for their apis. They still have. They follow a different version approach to the project itself, so I also think there's um you can find out some more there's some, I think, there's some versioning suggestions as well from from a vmware point of view, but that might help out with someone that gives some help. Some guidance on other projects in the open source, um tanzan work that their approach they're taking.

F

So maybe we can dig some of that might help.

B

Someone I mean, I don't know about you james, but would you be, or maybe david someone be able to like troll the other open source projects for opinions.

A

F

This here I've been taking action as well to kind of see if we can get some more information, if there's any guidance out there, I think there is something that's been talked about. So, let's see what I can find and share.

A

Got it anything anything else.

A

No okay. I really appreciate your time today and hope you have a good rest of the week. Thank you see you later enjoy the rest of your holiday day, david sure I'll. Try. Thank you.