Zarf Community Meeting - 09/01/2026  🔗 **Source:** [Zarf Community Meeting - 09/01/2026](https://www.youtube.com/watch?v=juA2Zqlnhdc) Hello again. >> Hello. >> Hola. >> All right, we'll kick this off in just a minute. I'm going to grab a meeting notes link. If anybody has any topics they want to add, please add them to the agenda. I did modify the format for this one a little bit cuz I wanted to try and see if I could make this use the standard Google meeting notes format so that we can just auto auto format things and it did all right. Looks a little different, but I don't think anybody's going to complain. All right. Um we'll get this We'll get this started and let other people join if they choose to join us today. Um we do need to remind everyone that this meeting is being recorded. Uh it will be posted to LFEX shortly thereafter. Um if you need to find access to that, uh we should be able Everyone should have access in their own openprofile.dev LFEX account. Uh but we can get you the meeting recordings uh if you so need and don't have access to them. Your participation in these meetings is an agreement to abide by the OpenSSF Code of Conduct. Um you can find that in the meeting notes link that I posted. Um please feel free to add yourself to the list of attendees. Um if you're new and you'd like to introduce introduce yourself, please feel free to raise your hand or come off mute and do so now. >> We have another late joiner. >> Welcome, welcome. Um going through I think I can share my screen here just to walk through our standard criteria. If you do have anything that you want to add or share in the agenda, um the link has been posted to the chat. Um oh yeah, let's do let's do some sharing here. Should want this friend. There we go. Um so yeah, welcome everyone. Um these meetings precede the release um that we have bi-weekly by just a few days. So, if you want to see what's coming up in the next release, I've included that link here. Um that'll take you over to our release please PR that has all of the changes staged um for kicking off the release pipeline. Um there are breaking changes with regards to um the SDK and how we handle um basically uh migrating a lot of the underlying uh SDK processes over to um new interfaces uh and structures. Um in particular, what this the PR uh associated with that helps is that we can now publish um the V1 beta1 component configs. If you don't know what those are, um, that's totally valid. Um, here in the coming future, um, we will be officially promoting the V1 beta1 schema uh, for packages to, um, being available for consumption. That is not the case yet today. Um, but um, in doing so, you will basically be able to start to use the new package format, um, the which is versioned as V1 beta1. The package manifest that most people are used to is the V1 alpha1. Um, and so just trying to help people with understanding the delineation there. Um, basically V1 beta1 is a culmination of a lot of changes with regards to the manifest and the schema. Um, a lot of it is just migrating things or, uh, removing things that were previously deprecated for removal. Um, but it in doing so, we've also modified the SDK to make it more robust and kind of handle, uh, a lot of the, you know, culmination of what does this look like and how do we do it in the future? Um, so this is this was handling a lot of the published behaviors. There are more V1 beta1, um, changes to come. Um, so standby for, uh, when we release the V1 beta1 schema for general consumption. Um, number of features coming out in the next release, uh, from the OCI source, uh, auto prefixing was something that was merged from community member, um, recently. Uh, for those who have done a package operation, whether it's inspect or publish or, you know, create with an output to an OCI source, you've always had to use that OCI schema out front, OCI colon slash slash. Um, this is changing that model to just kind of start to infer is this a registry endpoint and if so um we can figure out whether to use an OCI source or not. Um you can still use OCI colon slash slash so it should not be breaking in any way. Um but this kind of just helps people, "Hey, I commonly forget to use that scheme on the front of the packages that I want to produce or consume." This makes it a little bit easier for the UX. I think that's great. Um Helm, we implemented a process for um allowable retries on Helm chart installs. Uh if you go back through the history of Zar at one point in time any any error from a Helm chart installation uh immediately attempted retries thereafter. And at the time we thought, "Hey, this is it's pretty deterministic of whether things are going to pass or fail with regards to a Helm chart installation uh based upon kind of the current state of your cluster and the things um that impact the the installation of that chart." And so we removed the retries. Um and then we started to look at other edge cases for that behavior. And so instead of um just re-implementing any error constitutes a retry, uh we've implemented kind of a very fine-grained um allowable retry um option for things that should be retried when we know that it could change on a subsequent install slash upgrade. Um in this case the the model and I'm going to butcher this off the um the the case here, but it was a Helm chart that's installing a webhook for mutation or admission control. And essentially the endpoint not being available for someone to then automatically try to apply a custom resource for that admission or mutation endpoint. Um that would try to hit the webhook, the webhook wouldn't be available, and so you would get an error. Um we can now at least try to do a subsequent retry of that so that you can put all of that logic, both the installation of the controller uh and webhook configuration and the additional custom resources that you want to install all at a, you know, in a single component and have an option for a, you know, kind of eventual consistency. How's What's have a a retry mechanism in that regard when we can detect that, "Hey, the problem was a webhook failure." In theory, it could become healthy uh and we could potentially retry and and have a successful Helm install. So, um that has been that's been implemented. If there are other cases we want to implement, we may uh add those as additional supported or allowable errors. Um we've already discussed publishing the one beta one component configs uh for the I kind of brought glossed over it, but a component config is kind of meant to be the replacement for um skeleton packages uh in regards to at least the ability to publish and isolate individual components from uh each other, which then could be consolidated into a Zarf package as Zarf package creation time. Um moving on. Um Additional warnings for image push failures. Uh ZOCI, we implemented um additional uh transport options with the new remote with options um function and then some bug fixes. Um for those who are running Zarf tools update creds agent um to update your um your agent webhook search in particular is a a lot of the primary usage. Uh we found a bug uh in that with the help of some people running this in live environments where the uh the upgrade that was performed was not using the latest Helm chart release when it was performing the upgrade and so it was actually using an old one. Uh and there happened to be enough change between the old um agent chart and the newest one to where it actually started incurring um R back errors for R back changes that were introduced later. Um really interesting. Uh something you just don't see until you're running in an environment that has has been consistently upgraded over time and using this logic. Um so we implemented a fix for that that will go into this release. Hopefully we don't see errors like that again. Um passing remote options for OCI net packages. So if you're doing a Zarf net um to an OCI net package um there was previously some missing remote options there to prevent some plain HTTP in uh installs uh or at least pulling from um plain HTTP registries and then supporting platform flags for crane copy just to kind of follow the upstream. Um and yeah, then some additional um changes to state which hopefully shouldn't impact anyone. Um but changing kind of the the agent information into a substruct. Following standard conventions. Uh yeah. I have not been watching the chat. Does anybody have any questions on what's going into the next release? Um also want to say that there will probably be more things going into the release as we get them merged. So, stay tuned um and watch your favorite Zarf Slack channel for more updates. So, that covers the next release that should happen on Thursday um barring any uh problems that we could incur with our uh CICD infrastructure. Um usually tends to be the only hold up, but otherwise expect that on Thursday. Um ZEP reviews uh we are closing in on approving two ZEPs in the very near future. Uh I am ready to throw my stamp on there here shortly, but at least wanted to call these out in a public meeting um that I would expect these to begin moving forward uh here shortly at least after approval. For those who aren't aware, the Zarf enhancement proposal um that is the process for implementing kind of a larger scope change to Zarf, breaking changes or otherwise. Um and we wanted to put more design and analysis into how we implement that. Um that those live within the proposals um repository. So, Zarf dev proposals, you can go see those there. You can see the history of the ones that have been um worked, reworked, changed, modified, updated, and maybe even you know, deprecated in some regard. Um so, please go check them out. If you heavily rely upon Zarf, uh, I would definitely recommend at least subscribing in some way to updates here, um, because they could very well, um, propose changes that impact you in some way, um, significant or otherwise. Um, this is a great way to get ahead of future changes that are coming for the project. Um, so expect those ones to be approved and moving forward shortly. Does anybody have questions about open Zarf enhancement proposals? All right. None heard. Um, at this time, I think we move it over to kind of ad hoc. If anybody has questions, topics, things you want to talk about, I'm going to try to recall if I have anything, any fun facts off the top of my head. All right. Um, none heard. Uh, the Zarf team is intending to be at KubeCon. Uh, so if you are attending or you are thinking about attending, um, here's just a early update to say, come find us. Otherwise, yeah. Thanks for the time, everyone. I won't hold you up. Uh, I'll stick around in case anybody has anything they want to talk about, otherwise, I'll see you all next time. >> Hey., Zarf Community Meeting - 09/01/2026, OpenSSF, 01m1m95tmyha9rpr94f661xz1b.