VMware Carvel Community Meetings, 7 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Carvel Community Meeting - July 7, 2022

Description

Carvel Community Meeting - July 7, 2022
This week we announced three new releases: kapp-controller, vendir, and secretgen-controller. We also had in-depth discussion on 'Packaging API: version constraints for k8s version and kapp-controller version' and 'Examples or patterns for using imgpkg and kbld in a go CLI.' Check out the agenda here: https://hackmd.io/F7g3RT2hR3OcIh-Iznk2hw#July-7-2022-Agenda

A

Hi everyone welcome to this week's edition of the carmel community meeting. If you are watching this from home, we encourage you to come. Join us live uh we meet today, every thursday at 10, 30 am pacific time. But after this meeting we're changing some things up so keep watching and I'll. Let you know what that means.

A

um It's a great opportunity for you to come and listen in on what the maintainers are working on, uh get feedback on. What they're working on ask questions if you have any feature requests or you need help with something you can come and and just get at that live help from the maintainers and other members of the community.

A

If you do have something you wish to discuss, and then anybody that's on this call today make sure you add that down below in the discussion topic section and we will get to it towards the end of the meeting.

A

If you are unable to find us, are unable to join us in these meetings. But you still want to reach out to us. You can find us in the carnival channel within the kubernetes like workspace, you can email us. You can obviously find us in github within any of our project repos, and you can find us on twitter at carvilleunderscoredev.

A

And a reminder that at any point you are interacting with us or any members of the community. We ask that you please read and abide by our code of contact and this can be found in any of our project. Repos.

A

Today's date is july, 7th 2022, as listed here in the agenda. um If you are using any of the karbal tools, we want to know more about how you're using it. So we created a pinned issue that allows you to provide those details for us. You can input those uh the comments or add a comment. Sorry um to sorry, I'm just muting some folks, because there's some feedback, I'm getting okay.

A

uh We just asked that you provide details within a comment to this pinned issue on your use case with any of the cardboard tools and optionally, add a logo of your company, and we will get added to the adopters file here. It's a really great way for you to share what you're working on with the maintainers.

A

So they can better understand and help with the development of the tools, as well as share sharing your knowledge on how you use the tools with the community, and it helps them learn how they can also use the tools as well. So we would really appreciate it if you added that comment in there and gave us a little bit more information.

A

uh And optionally, for those that are on the call today, make sure you add your name and the company or organization you are representing here in the attendees list.

A

Moving on to announcements for content, we don't have anything for this week, but we did post two blog posts last week so be sure. To give those a look.

A

um Next week we will be publishing a blog set up cap, deploy with oidc github and gke, with gke and aws by yash sethya, so stay tuned for that when it gets published next week, and if you have anything you want to share with the community and the form of a blog post or video workshop tutorial, whatever we would love for you to participate in in this content sharing process that we've been using for the last few months, it's not limited to the maintainers, so we've created a sign up sheet here and what you do is just add your name, the topic you want to cover and how you're going to be sharing that topic, and if you want us to tag you on twitter, when we post it on twitter, you can add your twitter handle.

A

We will also share it at the community meeting and we will share on slack and do all sorts of other promotion with that and as a thank you, we will send you a t-shirt or uh an alternate swag item of your choice. If you don't like t-shirts, we have other options to choose from. So um if you have any questions, feel free to reach out to us.

A

Okay, moving on to releases, we got two releases here: cap controller and vendor. So.

B

Yeah, this is just um for cap controller, as it was reported yesterday that uh we had a little problem with trusting ca certificates when package repository gets reconciled.

B

um This was a um a recent feature when we added uh uh in 38, I think, or maybe 37. I forget anyway. The nintendo was uh both package repositories and app crs follow the same procedure and for package repositories deviated from actually executing a site car. So this uh small fix corrects that most people would not even notice since most people don't use custom proxies and ca certificates, but for the environment who do use it. This might be useful.

A

Great thanks, dimitri any questions on that.

A

All right moving on to vendor.

B

It's me again: this was some uh from a previous release. We were investigating why vendor and helm was not playing nice when it's configured through asdf package manager and turns out that asdf package manager, for whatever reason, needs to have access to the home directory as configured through the home environment variable, even though it does all kind of paths rewriting so interior should need it, but for whatever reason it needs it. um So this is an enhancement to make vendor work with uh asdf, better.

A

Cool good catch, uh any questions on that.

A

All right, thank you so much jamitri uh moving on to announcements. What I mentioned earlier in this one.

C

Sorry, sorry to jump in, but we also have one other release that is imminent. I believe uh the secret gen controller. Neil. Do you want to speak to that? One.

D

Sure yeah it'll be out uh at some point today um that release will provide support for arm 64 architectures. So you can deploy your secret gen controller on arm 64.

D

if you use an m1 mac, for example, that will uh that will be on that architecture and that release will also be publishing package cr and package metadata cr as part of the release artifacts.

D

So you no longer need to write your own to uh deploy secret chat in just like some default states.

D

The only thing you will need to create is a package install, but the package definition and the metadata will be released by our team from now on. As part of that, uh support of the release.

A

Wait thanks neil any questions on that.

A

Okay, uh once it's released I'll make sure to tweet, it out. Add it to slack. So you have all the release notes to that as well.

A

All right now, moving on to the item I mentioned earlier in the meeting, uh so we were thinking about um changing the the day and the time and whatnot for this community meeting to better accommodate our global community, our cap team, that's primarily based in india um and also just um thinking about maybe just a better time during the week in general, we had.

A

We posted this in slack to try and get feedback and um scott rosenberg one of our awesome community man, members gonna, say community managers he might as well be a manager of community. um He suggested uh wednesdays instead of thursdays, so we are now going to be moving. This community meeting two wednesdays at 9 00 a.m, pacific time, every second and fourth wednesday, and we won't be meeting next week, which would technically be the second wednesday I'm just because we're meeting today.

A

So we will reconvene on the fourth wednesday of the month now, if, if anybody has any concerns on that now, let me know- and we can try to work something else out, but um otherwise that's that's. What we're moving to any questions concerns.

A

A

Moving on to status updates project roadmap, anything updated here.

C

uh Nothing was updated here, but this is a good reminder that randy and I should probably provide some updates here. Well, we'll have that ready for the next community meeting. Unless there's anything you want to say right now, randy.

E

Yeah, I did add the package author improvements that we are doing working on so hopefully uh july end or early august is when we are hoping to get something out there.

A

Awesome thanks for you.

A

Okay, um now, as outside of the project roadmap, some stuff, that the team is working on cap controller, adding some version constraints to packaging api.

F

Sure- and you know I dropped this into the discussion like I don't know how to say this is both something that's being worked on and a discussion topic, so I'm happy to come back to it in a few minutes or discuss it now, since it's already up.

A

Let's just discuss it now.

F

Okay, hooray so basically um version stink. We should never write new software ever again, but barring that solution, uh you might want to say hey this. This will only work up to kubernetes 1.23, or this will only work starting on kubernetes, 1.24 or even worse. You might have a scenario where you're like well. If this is kubernetes 1.16 or below, I want to use. You know this feature like I know. One of the things we talked about was like pod. Was it psp's pod security? Whatever the last p?

F

Is uh you know, and then, if it's a later version of kubernetes, I want to do something else, and so I I need to have conditional logic in my templating um and anyways and you might be in that position with respect to both kubernetes and with respect to cap controller itself. So um uh hence there's this kind of like two-prong solution, so we're saying well, we can provide a minimum.

F

uh Can you scroll down nancy to the proposal? Part one thanks so here here we're saying um you know shucks, maybe you want to say my minimum. Kubernetes version is 119.

F

and maybe you want to say my maximum is. I don't know I gave this example 123., um uh and you know I think we basically said well look. If a package install like you can have a package on your system, but a package install if you make a package install uh that says the minimum kubernetes is 1.25, and here you are in 2022 running kubernetes 1.23 is we're gonna be like well, you can't install that. You know this package has a minimum kubernetes of 1.25 that doesn't exist yet so you can't install it.

F

That seems reasonable um and I maybe you know as a brief question. I would love to get any temperature in the room of like. Would you rather have two separate keys for minimum and maximum? Would you rather specify a range? Is this gonna totally miss the mark on anything that you all are dealing with today?.

G

Will these variables be made available then within like templating yeah? So that's the next. That's part.

F

Two scott you're genius: you are a community manager, um so yeah, so this this first step is about. I just don't want the install to go through and then the second step, um our very own, dennis um recently. Well, I guess, before we move on to step two, no further questions on step, one, your honor, no further questions! I.

H

Just I just wanted to ask this one to make sure y'all cover this. Is there? Is there ever a situation? We'd want to cover where there might be a very specific version within a range that we that the package would want to skip.

F

Oh, I see like whatever you do, don't install me on kubernetes 1.20.04.

H

Is is that a kind of concern here while we're talking about being able to manage and um so avoid a problem yeah, maybe.

F

That's an argument for we should use like a range, a full range constraint rather than min max right, like the the way I've presented this here is that it's a min max versus. If you go through the trouble of parsing a full range, then you can exclude some specific version.

I

I think um the the strength of the individual kubernetes api groups and sort of the promises that we provide from the ecosystem and as well as like the promises, are weaker in the ecosystem, but from the core project like we, we try not to break things that aren't broken from like an api layer like formally and so then, like my immediate question, there is somebody a pessimistic infrastructure engineer: who's like always trying to glue things together is if I install a package that is going to break because of some kubernetes versioning contract.

I

That like I want to know why right and so then my question is like what is the behavior of cap when you provided a list of objects of specific api groups that are not satisfied by the cluster right like um I don't want to see a hollow message that says you can't install this because of some number. That's arbitrary, like that's so decoupled from the contract, that's actually being broken, which is this api group is not available or you know like there can there's like a very small subset of more esoteric things like this.

I

Annotation version has a buggy implementation in this controller right, but um that should be more of like a warning or something uh so I I.

F

Think I appreciate the input lee and I I'm trying to square that the the ticket or the issue that was opened was was actually about upgrade like basically, I I don't want to upgrade my kubernetes cluster if a package won't be compatible with the new version right and that, like things that happened like I think, famously 1.24 the like, they just dropped a bunch of stuff on the floor and they were like. Oh, were you using that?

F

I'm sorry, oh so, um like I know like we had that problem and I we were far from the only ones uh there's a few things they dropped at the same time, and so the the the impetus for this is more around like coming back to decorate a maximum that then uh well than anything else.

B

Hey if to add lill here.

B

In a perfect world, everything is perfectly represented by individual apis, and I that that that, I think, is the ideal for where kubernetes community wants to be. I don't think that that's the reality. Some things are represented well enough with the api versions. Other things are entirely.

B

You know transparent to it right, especially if you get into you know different, uh uh you know, managed kubernetes service, uh kubernetes offerings and different kind of version ranges that they that they offer right. So this feature does not necessarily replace a potential future feature that talks about hey uh I'd like to make some choices around. You know what I'm deploying based on the available api versions, but I don't think that future feature is a replacement for this feature.

I

Yeah, I think um a great example of this is in the most kubernetes release. Most recent kubernetes release. We dropped support for auto, um like long-lived service, account tokens because they've been deprecated, for you know several years now, um so that automatic behavior is no longer present in a cluster.

I

After a certain version's feature, gate you know is changed by default right, but that feature gate has been there for many releases um and then it's like you have this runtime failure right like that's something that a package author can anticipate will likely happen for somebody, but it also may not happen for them based off of the version number depending.

B

I

Their api server is configured right like they may have decided to move, and then they need to install that package and they've just changed that feature gates value, um and so it's like you don't want to do anything that takes away the option of installing a package on such a flexible system underneath, for which the version number does not tell you about the state of all of the behavior um so like I am, I'm supportive of warnings and empowering users with information right like people should know and package ushers package.

I

Authors should be empowered to say, like hey. This probably is not going to work, and you might run into something in this very common case, but with any gate or like pre-flight check or warning or early exit linter type system, especially when it comes to infrastructure, which is just like all we're gluing together. These things that are so loosely coupled um like I'm very against, like anything that makes it difficult for somebody to actually do the thing that they want to do.

I

um So if we should help, people discover that packages will might have problems, but we should be really careful about, like encouraging package authors, to take some absolute stance. That says like this should not install with this version right. Somebody should always have the option to override that, and the experience should be more about warnings and reasoning than outright failure.

B

I think that aligns generally with cap controllers. um Balance of you know: what can a consumer do, even though the author provided something right so, for example, here might be ability for us to actually override a choice of uh or not a choice, but rather override a decision that the system is making by default. Right. Hey, look ignore this version constraint thing right. You just go ahead. Trust me. It may work right. I know my system better kind of thing right and so that I I don't I would.

B

I would definitely plus one into that uh type of functionality.

F

So I'm hearing that in a package install, we would then want like an override mechanism like if, if we did it this way, the the escape valve would be. Then a package installed needs to have an override.

I

Yeah this does seem like something that would probably be very well abstracted within cap itself, like you would probably want some of these things um if it's, if it's not already there in cap on, like you know it install this resource. If, if we're matching this api version or this api server version um or if this api group is present, you know install this thing.

B

I don't think it would necessarily push it to cap cap itself doesn't know much about. You know, kind of all kinds of logic that you might want to be doing right. I think ultimately, we'll you know will probably with the combination where this information is available for you at the you know, mutation of your configuration layer right.

B

uh So you know, if you're writing your templates in queue, ytt, helm, template, etc, etc. Right you can make some intelligent choices if you really want to um and then by the time it makes it to cap, you know it. It's already been. You know properly combined.

I

Yeah like um when I, when I look at how other tools solve this problem like helm, with its like monolithic design, allows like the runtime, like the applier piece to share information with the templating piece um and that's kind of hard to reconcile.

I

It's like you can have a convention where you can try to supply some standard, shape values uh to other templating tools and then get them to.

B

You know this, this actually trails in into the next section that joe has prepared here.

F

Great, let's move to the next section that joe has prepared here thanks yeah, so like.

J

Sorry to go back to this, but from the moment that the package author tells you that you shouldn't install. If you really want to install it, then you should create your own package and overwrite it.

J

I don't think I I'm not 100 sure that to be fair, I I don't think this package should even exist in a cluster that it's not sanctioned for right, like if you say that this should this package can only be installed in in this version of kubernetes, with this version of cap controller, if you're, not if you do not meet these standards by the package author, this package shouldn't even exist at all in that cluster.

J

I really, and I think that if you, if you think you know better than the package author, because that's what was talking here, you think you know better than the package author. Then you should fork that package and you should add it yourself with the restrictions that you think, but in some sense what the package author is telling you this works in this situation, I'm not.

J

Why would you want to insult in a different place right? I think that sometimes I feel like that, giving too much like freedom and too much knobs. This is gonna, even though it's gonna bite us in the future for sure, but it also it's just like it's becomes a little bit loosey here I don't know that's at least that's what I think.

K

That makes me wonder something else related, which is I'm wondering what the behavior of you know. You have cluster inversion on version one and the packages within the range it's allowed to be installed on version one of the cluster and then the cluster admin upgrades it to cluster two and now the package is no longer in in the range of that of that cluster versioning.

K

What happens to the package resources then.

I

Like again like that's, um that's like a very good point, and it's a natural consequence of using kubernetes is that the way that we upgrade things is to provide migration paths and flags to enable and disable specific behaviors, and that there are many systems that are interacting each with each other over boundaries that have various couplings right, like with the very specific failure uh mode that I'm describing. The things that broke from the last release of with service accounts tokens no longer being generated by default.

I

Right again, that's like a that's like a feature that people can opt into at various layers uh and it can be completely enabled with the old behavior, um by just changing the your cluster's configuration right so like this is not a.

I

This is an example of something that would break people's packages in a very surprising way that can only be found out at runtime. It's an example of something that a package author would likely want to help warn users and protect them from, but at the end of the day, because kubernetes is so flexible and because upgrade paths are very dependent on which components are causing breakages and you the ability to change the behavior based off of how the cluster is configured.

I

um It's if you are packaging for a specific kubernetes version, and you have the hubris to say I don't want this to install on this particular thing. um You end up with the packaging system. That's just going to get in people's way. All of the time um you know with the pace, pace of change in the core project still as it stands years in it right.

J

But it should stand in your way because if I am managing a package- and I'm telling you that you shouldn't install this in this particular version of kubernetes like I must know why right or should I just allow you to install it, break it and then come to me and tell me: oh, this is broken, and I tell you oh yeah, because we're missing this part I mean now. This doesn't work anymore.

J

If you know packages, this is causing the fact that you're giving like this ample freedom first of all, is assuming that everybody will know everything and how all the packages that they are installing work. That's yes,.

I

J

It, which is, which is not true right again as.

I

uh You know co-chair of cluster add-ons and someone who understands the ecosystem, like I think that what a lot of package authors think they know about the limitations of kubernetes is very one-dimensional um and if a package author makes a mistake about something or they say that you know this is a very particular situation, maybe they're a kubernetes expert and they understand the breakage deeply.

I

They want to prevent people from making that mistake by default, but, as somebody who's been in a platform, an infrastructure person gluing things together, like these sorts of gates, always get in my way you know, and at like I do want the power to be able to say. Yes, I really understand what I'm doing and I'm going to install this and when.

B

I

Do that there's going to be warnings from the package author all over the place? You know that say hey! This is not supposed to be. You know installed in this situation, but you've done this. You know.

F

So I do want to um move on if we can there's another section of this stock, and this was not the only thing on the agenda for this hour. uh I I think, hopefully, I've captured well and honestly, it's a hackmd. So if you think I haven't captured, feel free, you all have edit privileges, don't you?

F

uh I appreciate the discussion. um Okay, so the other thing exactly as um prophesied by scott rosenberg is we're. Gonna make this information available in templating, because you probably care about that. You probably have conditional logic and all kinds of terrible gnarly things to do depending on the version and so uh dennis recently added um we're calling it downward api. It's it's an analogy to the kubernetes downward api, so we're we're making available data. That's in like the meta like the app uh you know, metadot namespace or something we.

F

So we have our own downward api and you can be like you know. I want you to bind the value from this. My own apps metadot namespace into this name that I'm providing right and it works, and that sounds very much like the kubernetes download api. uh And so then you know same thing: we're offering um you know well, you're you're gonna get to pick your own name that we bind the data to, but somehow we're gonna make carvel.

F

Somehow we're gonna make the kubernetes version available to you and the cap controller version available to you, and uh I don't think um this. It barely matters, but I did I. I showed two different ways that we could do this right on the one we've got like left-hand side that says, um source carval.kubernetes version and on the other, the left-hand side is the name of the data. Already controller version- and you know you're just saying like the right hand, side is barely matters. What you, what you say, you're just saying: that's right, anyways!

F

I I don't know if there's opinions or if anybody sees any implications, one way or the other on that choice or if there's other concerns again about um anything. We haven't considered in how we're passing things through to the templating phase.

B

H

B

I was going to throw in something this. This might be a good, also um starting point for other similar types of features like, for example, he was mentioning earlier on around the the access to available apis right and so potentially plumbing such information into you know places like help, template ydt, template, etc, etc.

G

Yeah, I was, I was just about to say one of the things that um helm does when you do a helm apply is that it has the idea of capabilities within it, and then you can use that through the built-in capabilities.kubernetes version that does exist in helm, template by passing in flags and we're doing a helm template here. So I would wonder if, as part of this proposal, we could also add that, like helm, template for example automatically, we would pass in the kubernetes version as this value, because that never hurts the helm template.

G

But that allows many many many helm charts that would have issues today to work, because some helm charts just don't work with templating because they rely on the capabilities feature to say: am I doing something with pod secure psa, or am I doing it with psps based off the version or what version of crd am I creating a v1 beta 1 or a v1 pre or post 122 right, and so I think that it would be very helpful specifically in the helm case, also to have this plumbed into that specific case.

G

I don't know if q has that I've never used it and ytt having it as a data. Value would be the way but yeah.

B

Yeah the data value for q as well right q has no idea what kubernetes is.

B

This does raise an interesting question around uh whether um this should be under the items part of the downward api versus uh some additional section, uh which may then provide ability to you know the the the version or the potentially down the line um available. Cluster versions right may not be actually injected as a data value right. Maybe it's injected in through the inner workings of you know, helm, template, etc, etc. Right so might be some some more thinking to do in this area.

G

Yeah, and especially, I liked what you had brought up demetrium down the road, possibly adding like available api types, and things like that, like helm, has today where it can pull and say yeah, you have service, monitor crds of prometheus, so create service monitors for this application. If uh specific things exists, I'm not sure it makes sense under items necessarily. I would agree with that that, possibly having it like cluster info or something under downward api, that would be a way of separating it out from the actual downward api's strict.

G

What fields on the object am I pulling out because it seems different, even though it's all bringing in data from outside into my cluster through cap controller, the use cases can be very different if I'm pulling from the app vr from the cluster itself.

B

Just for the record, the name on that key is not the source, but rather the destination right. So it's more like.

B

Where do you show in this data right but, as you know, pointed out in helm, for example right, you might not be sending that stuff over a data value right so or or maybe maybe the the items should also you know allow you to um to not just set the keys, but do something else actually, uh the the the change that link to includes kubernetes version and uh api versions as the flags on the helm, template.

I

Yeah, I think, uh to scott's point: if those, uh if that information is not already available in a cap, controller, helm template, then it seems like something that would not break anything. If we added it.

F

Cool, so I think this has been super helpful feedback and maybe we'll take one more breath on this topic and then I know there's there really is other things on the agenda today.

G

What about I see it at the bottom, but it was a question that I was thinking. Also. Cap controller can deploy to other clusters a management cluster to a workload cluster by passing in a cube config, which cap control, which versions of what are we passing on.

F

Yeah- and I think that's part of why that's part of the argument for doing this at the package install level right- is that your you could be running some like ratty old management, cluster, deploying to a shiny new workload cluster, and I to me it seemed like the workload cluster is the important right, like this package install targeting this workload cluster, that's the important version to line up is that is that fair.

G

I think sewing cap controller version needs to be of the local version.

F

Right right, right, right.

G

Of the management cluster I'd say, but yeah kubernetes should be. I I can't think of a use case where you would need the management cluster version, but.

I

Yeah yeah I mean if this is done at the cap layer. Your api client is pointing to the cluster that you need the information about, but I agree that if you are plumbing information from the package install through the values that you want to make sure to use an api client for the target cluster.

F

Nick well appreciate, oh sorry, go ahead. Scott.

G

Nope, that was it.

F

Okay back to you, nancy thanks everybody for the input.

A

um Thanks joe thanks everyone, um I I'm gonna just skip over the ytt and image package, and if we have time when I come right back to it, I just want to make sure that we get to the top discussion um topic about examples or patterns for using image package and k, build and a go cli.

A

So dimitri, do you need to share your screen on that.

B

uh No, I I think um nothing to present. Specifically, uh I was hoping to uh just get a little bit more context on what uh what's being kind of a built, uh I think, from a slack thread. There was some discussions around uh uh kind of a having a custom cli that does some.

B

You know, building up, maybe working with image packaging k build we're also at the same time, are building kctrl package, init, slash, release, commands and actually package repo in it and release commands as well right, so we're trying to kind of up level uh what a lot of the package authors go through and also at the same time as you building your package, you probably want to iterate on the package right, so we're thinking of the kctrl dev command as well.

B

So all of that stuff is in the pr state right now we're still iterating actually just recently, I think it's a week or two ago kind of a gotten a little bit more clarity around like how we should partition the flow. uh But you kind of wanted to understand if some of this stuff is maybe overlapping in in your you know, in your efforts- uh maybe not yes, yeah.

L

uh Yeah, so that was that was my discussion item. um That sounds actually like supreme overlap.

L

So what we're getting into right now is a pretty heavy consumption of you know, bundles or packages, depending on your verbage choice and uh custom production from inside so uh for y'all, who don't know I'm at twilio and we're working with karbal and some of the tanzoo stuff and playing with that internally and we're getting to a point where custom software custom services need to go into bundles, so we can help facilitate them into clusters, and so the the custom tooling from our side is, you know we have a handful of internal clies and the idea is interacting with our infrastructure and just pretty much what you said: dimitri facilitating the ease of package creation.

L

We need a little bit of help to template out the directory structure for our devs. We need a little help, giving them tooling. To you know, k build and image package push the biggest thing that we're really interested in is you know getting some testing around that as well and so right now most of our stuff is bash scripts, because we're just at that phase, but we're starting to look at iterating on our go clies and we had one of our senior or actually principal devs.

L

Take a look and just struggled a little bit incorporating the library's image package was totally fine k build. We just actually had a little bit of issues with um and given the relationship we have and how helpful everyone always is, we said hey, why don't we just talk to the folks we know, um and so that's what we're curious about, and it sounds like.

L

Maybe what we should be looking is this this k control, um if I'm saying that right, because we haven't spent too much time focusing there, but it sounds like uh what we what we actually need- um and that's that's the point that we're at we have other needs with this unified cli tool. I've alluded to that. May work with some of our infrastructure. Some of our cluster deploys.

L

So incorporating both may make this kind of like huge mega tool for us, which would be a fun dream, but right now the the immediate issue is: how do we accelerate our developers? To put you know their custom yaml their custom, whatever inside of a package, so we can get them onto package repositories um as quick as possible, and you know accelerate that cycle and that's kind of where we're stumbling right now and everything we have works, calling binaries working out of containers, but it's just the testing and the validation is limited.

L

There is like everyone here can, probably guess um so. I'm happy to expand any more or talk into any details, but it sounds like maybe first crack taking a look at that pr you talked about would be really helpful for us and see or helping out you know. We've got anova who's very interested in working with everyone here and we'll see if we can get some time back to help with that. But yeah, that's that's kind of the question our perspective and what we're thinking about.

B

Cool cool yeah, I think um um I was thinking. Maybe we can uh share a little bit of uh uh of a demo at some point in the channel. uh I don't know if uh reno's team, I know that there were some uh demos that have been shared in the uh team's private channel. I wasn't sure if those demos are meant to be publicly shared yet uh so that would be a question uh for those folks.

B

B

You know if, if you want to uh throw in any specific questions uh where you all got stuck importing things, and you know calling out two things and whatnot, uh I think maybe this that we could take to slack just with concrete. You know problems. I know that uh some folks uh import image package. uh We actually uh did uh have some uh um some problems with import with how we're using go container registry and uh how we're using. Actually it's not even go container. Is this the kate's credential provider?

B

So there's some pending work on uh remedying that and cutting a new release. uh I do know k build, has not been as commonly imported in most folks, I think, have just delegated to the tool or just use the tool directly. uh We don't really have any objection to you know cleaning up. Some of the I don't know import. uh You know, objects to be used right.

B

So just tell us tell us what you're trying to kind of import and where are you running into a problem, and we can try to see how to make that easier. um With regards to the kctrl or k control, I guess sorry it's! uh I don't think I'll ever forget that name. So uh uh with regards to that, I think uh those pr's are fairly raw in uh uh in in shape, so most likely, if you just you, know, check it out and uh try to use it locally.

B

You'll probably run into a lot of pain. um So I wonder if there is, um if there is, you know, maybe a little bit of a read me doc or something like that- that we can prepare to again publicly share to at least share out some of the current thinking and and the plan.

B

The hope was that we were going to iterate quick enough where we don't necessarily have to produce a lot of uh material and then just you know, have folks check out the cli and use it, but since we are running a little bit uh late with that, um I think uh we can probably provide just some background information and whatnot.

L

Yeah, I think, just kind of looking at that and getting an idea on the overlap of what we're trying to accomplish and seeing, if we're, just even headed in similar directions with it might be really helpful for the team.

L

um We're pretty slim right now with a couple folks out on leave and so it'd be nice to accelerate very quickly using your tooling instead of ours, but maybe there's a great opportunity here for collaboration and helping with that and um just making sort of a more open tool that we can provide our input that may help other people outside as well.

L

But um it sounds based on the way you described it like exactly what we need um or are looking for, and it's just that component, the future state of if it interacts with clusters- and you know some of maybe the tonzo community edition stuff- could be a fun thought as well cluster provisioning relating into that. If they all map whether the idea is intentionally separate tools um totally fine, too, you know that's all personal but yeah I'll I'll, save that pr and I'll drop it in the room.

L

Thank you very much joe for linking that and uh we'll we'll just hit you up in slack. You know I'm not shy there, I'm always around to bother you guys.

B

E

One last thing on this one: I could probably ask rohit to share the recording of uh of what we have done so far with you uh separately, so that you could look at it. We will not put it in the public channel, but I think he could give it out separately. You can just look at it that way, along with the pair.

H

A

Okay, all right, thank you so much for that, dimitri and and all who contributed to the discussion um and just so we're clear. It's k, control.

A

um But as I put in the chat, I will always cuddle with my clusters: that's a given.

A

We have five minutes left, so I think we have a little bit of time to go over the updates for ytt and image package. So john, you want to take it away for what's going on with ytt.

H

Yeah my pleasure nancy um yeah, we're continuing on with our work on validations, so we're anticipating one more rule to get implemented uh before we much more proactively uh extract user validation of the ux of our validation rules. Here, we're really looking for folks to be able to uh be able to um really use use the the feature as as intended, which is that a lot of the kinds of validations that you would want to write ought to be easy short, simple and intuitive.

H

uh So we want to make sure that we understand how close we are to that mark. So this one not null is sort of the last of those we actually even did some internal usability testing or exploratory testing and found some of our own ux improvements. We folded, those in but yeah, we'll be looking for a release of ytt of version 0.42 coming up pretty soon to include these rules in an experiment, mode uh plus some additional interesting um uh contributions and bug fixes. uh So look for that coming up.

A

Awesome thanks john any questions for john.

A

Okay, image package, joel w.

J

I can do the update for image package this week. It's fine, uh so, uh okay, so I've been working in two different things. One is a continuation of what we talked last week: we're working on updating our authentication mechanism that we're using like a different library. That was a fork from the the kubernetes one, but it was causing pain to to our friend friend david.

J

So we said: okay, we're gonna, fix it and we're going to start using the the one that the the authentication mechanism that comes with go container registry library that we are already using, and thanks to that, we're going to drop a bunch of of dependencies. That kind of came with this kubernetes library that was kind of overload overloaded with stuff. So uh we're working on that not sure when we'll be ready, we're grappling with some questions around um what should we enable what should be enabled by default? Should we do allow you to obtain opt-out?

J

So there are things that we're going through there. The other topic that we're working on now is allowing people to resume the the copy to tars. That was one of the complaints that we have when you have like a very big bundle that you're trying to copy from a registry to atar.

J

Sometimes it fails and you need to copy it again and we're trying to see if there's like any nice way that you can just give an attar, we can just fill in the rest of the the blobs that you didn't copy the first time around. So that's the things that we're working on. um I think that's that. Does anybody have any questions about image package.

J

I believe jerome was very clear on what was happening so back to you, nancy.

A

Thanks joe really appreciate that update.

A

Now, uh before we say goodbye, is there anything else? The last minute we are together to bring up?

A

I guess I should say I did put a discussion topic just to say like if anybody has any objections on us skipping next wednesday speak now or forever hold your peace until the fourth wednesday of the month.

A

Please thinking got that thinking face.

H

I think leaves always thing is this is resting shaking face.

A

A

All right, so it sounds like we will skip the next two wednesdays and start fresh with 9am pacific time on the fourth wednesday of july, and until then you know where to find us we'll be in the kubernetes workspace and the carville channel on twitter at cargo underscore dev, always on our github repos and an email on our google groups. So with that, we look forward to seeing you at our next meeting and have a wonderful day.