VMware Cartographer Community Meetings, 19 Jan 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Cartographer Community Meeting - Jan. 19th, 2022

Description

00:00 Intro
02:15 The TL;DR
06:53 What the team is working on now?
14:41 RFC009 Best practices for multiple supply chains
40:03 Follow up from previous meeting (record a demo)
43:51 Open Mic discussion

A

A

Okay, welcome everyone to the cryptographer weekly community meeting um today is january still 19, um and I will start sharing my screen right now and there you go, I'm not the kind of host who will ask you if you're watching the screen, because I know you're seeing my screen there you go so welcome.

A

um Remember we have an open agenda and the goal so far for this space has been to to provide updates from the project to the community out there of users and adopters, and um you know it's also an open space to bring questions here, um feel free to add yourself to the attendees list and um welcome if we have new faces here, uh not much but welcome cora, milan and all the maintainers team.

A

It's great to have you here. So um if we go to the pldr, uh the goal of this short section again is to have a grasp on what is what's new in the project. This week, um there's been documentation, work been done by rashid and some other team members. Documentation is proving to be really hard and it's a never-ending task. So um I don't know if you all wanted to comment on the news here: are the docs.

B

They haven't landed yet I'm waiting for a pr on it, but um we now have explain working the way it ought to.

A

Assume you can hear me right.

B

uh Yes, can you hear me.

C

I can hear you both.

B

Okay, um yeah, uh that's a very zoom moment: um yeah, there's, uh there's now there's now one source of truth for documentation um in the in, in the definition of how I see that see how these are structured and respect for them um that that one source of truth comes with some yeah hikora yeah, uh but it comes. It comes with some annoying caveats hurts the perfectionist in me such as uh explain just slams all new lines together.

B

So uh just it's a thing that it does and in fact, even uh even like pod explain, explain. Pod suffers from the same problem, so even the kubernetes teams suffer from that kind of thing, and then we have sort of like a similar issue and then trying to present that, as uh as the crd spec, um if you actually jump straight to that preview, that you're looking at right now just browse the preview, uh it's sort of where the sunglasses smiley faces on your screen. There.

A

uh Yeah, sorry, I lost audio for a couple of seconds, so that's.

B

All right, if you click on that, see the.

A

Preview, maybe right.

B

Yep and then documentation and then development version. And then when you go to the cr reference.

A

B

Great we've got.

A

B

Like under maybe workload.

A

B

Yeah, so this is now generated from documentation.

B

uh I just noticed a problem other than the fact that it just slams the copyright up there, even though that's something we don't really want to have um in the docs uh the uh this is all now con built from uh what we document. So it's imperfect because sometimes you want to put annotations, but you'll just have to put those afterwards, but this is all automatically generated now from the same documentation that creates explain. So that's the work that that presents.

A

Do it make it you know more? I don't know if this is the word, but more scalable to maintain for future releases that.

B

Are more likely to maintain, be maintained consistently? Yeah? Okay, because we're human and we're going to miss something.

D

B

Yeah, and also it's much more obvious where you need to drop your docs as you're modifying the cr spec right. It's just it's more obvious that, in your actual cr cr definitions of the objects in go that you're supposed to add some new comments when something changes in line rather than go, searching the docs for where you should be putting it.

A

Great, thank you. That's awesome. Let me put the link here in the notes: real, quick um yeah, but that's that's great. um Okay,.

A

Anything else to summarize, what's in the project this week,.

E

um Garbage collecting of stamped objects still continues just uh putting in some guard rails there to make sure users don't get themselves into some uh unfortunate situations. I think we've got out the feature and just had a little on a bit of reflection, realized that they could specify only keeping zero um successful or failed runnable objects around, which would mean that we'd garbage collect everything and we'd lose output, which wouldn't be good, but I think um that should come in, and uh this should be should be uh closing out this week.

A

Okay, cool! That's great!

A

uh Let me put it here.

A

Okay, there you go that's great thanks uh and well now what theme is working on again guys collecting stamped objects and um yeah work around rfcs a couple of rfcs any comment around this.

F

Yes, we're doing a lot of uh design right now, um so we continue on um updating, uh rfc 18 for uh tracking artifacts in the workload uh workload status. We hit a bit of a snag on this one um in I don't know if rashuma you want to get into the details of that um or I can briefly touch on whatever you want.

C

Yeah I'll just say that there are some crds that report the latest successful artifact um examples would be kpac and our own runable, um and it's not neither those artifacts none of those status messages.

C

Let you know what was the: what was the spec generation? What was the shape of the spec that led to this latest successful uh output and because of that, we can't associate this input led to that output.

C

C

It the way forward is either one uh get the authors of those crds to provide more information. So that is something that we can track or two, at least in those two examples that we have.

C

The crd is generating other objects on the cluster. That would have more information, so, for example, kpac creates, builds, and each of those builds has information about what generation etc had had caused that build. So uh yeah, there's just some exploration to be done there to figure out. What's the best way forward,.

G

Does kpac not support, observed generation properly in the image crt? Is that that's something they could be uh asked to do.

C

I would argue that they are using observed generation properly because what they like, uh you submit a new uh definition of the object to the cluster, but you submit that object. That object is submitted to the cluster like they they reconcile on it and they say, like hey, I'm processing, something and that's the observed generation right, but they're still outputting some information about well. The most recent good image is: is this one and observed generation?

C

uh I don't think is meant to say like what's the what is the most recent good thing, it's meant to say: uh I'm looking at the status. Does this status represent uh the most recent thing? You know about the spec that is generation x, and I would argue that, yes, that is, that is what they are telling us that uh you submitted generation x and I've reconciled on generation x, and I'm telling you the most up-to-date information that I know about generation x,.

G

Wouldn't they update a condition in the status to say something is incomplete before uh bumping observed generation or the bumping observed generation and then leaving the status at ready with. uh You know.

G

C

The status goes to unknown because they're processing, something but that's somewhat orthogonal to the latest image. The the conditions I would say are in sync with ladies.

B

C

The uh observed generation, which is yeah, which is also in in sync, with the spec, its latest image, that's out of sync and by design its latest image, is not necessarily meant to be uh here's the output of this spec. It's just like it's the most recent good thing that we've seen.

G

If you wait for, I I'm not saying I don't believe you, I just want to understand. If you wait for observed generation to change and the condition to say you know ready true, uh and then you pull latest image, what's the what's the situation where that doesn't reflect the latest image.

C

That would be fine, but you would risk locking up your cluster um in two ways. One: uh let's say that you had some bad source code come down the line that can't build um until a new update comes through everything.

C

Everything past that point in kpac in your supply chain would go blank because kpac wouldn't be outputting an artifact anymore, because status is not true.

C

The other thing is, if you have commits coming in. Let's say it takes an hour to build. You've got a really large project and you're working on inner loop, so you're, you know you've got changes coming on the scale of minutes. That's your in a similar way. uh K-Pac would just always be building and it would stay in an unknown state for status, uh and you would never be able to read latest image, and so the rest of your supply chain would be broken.

G

um If we're just using it for provenance, just using it to create that artifact graph right and not not for promoting things, does that does that change anything.

C

C

I mean it means that your supply chain is no longer broken, but you would like those two, those two.

C

What you would end up with is uh in those two scenarios rather than you have a supply chain. That's broken. You would end up with. In those two scenarios, you can't determine provenance.

G

So a key problem here is two updates in a row right to the spec or like an update to the spec. While it's processing leaves it in the processing state between generations of the image, so you never get to status ready in the conditions. Okay, I think.

B

It's it's edge. That's edge, triggered you're describing moving to edge triggering now if the artifact is picked up by the next resource is level triggered, but we prove provenance for that object by level triggering where we're still stuck.

G

Yep, that makes sense. I just wanted to understand that the sequence.

A

Okay, that's great okay, and uh also regarding best practices for multiple supply chains.

F

Yeah, so this is the other thing. We're diving into um rfc. 9 is one such example of how we could how we've been thinking about um approaching multiple supply chains? uh There's lots of interesting bits in there. uh This is also.

C

Yeah um so yeah right now, uh your platforms have to deal with workloads that have lots of different lots of different shapes and needs, and we can right now we enable those platforms by saying you can have an unbound number of supply chains and you can use selectors to determine which supply chain should apply to a given workload based on the labels on that workload, um rfc9.

C

Looks for ways forward that would reduce the number of supply chains necessary by, for example, saying rather than selecting on whole supply chains or not not, instead of but along with being able to select for a whole supply chain. You could also come to an individual step or an individual resource in a supply chain and say there are three different templates here and based on some criteria.

C

You'll decide to deploy one of these templates, rather than the other templates the we could simply stick with. uh We could simply stick with uh selectors label selectors uh or we could say, let's, let's make it a little bit richer. Let's uh any information, that's in the templating context at that point could be used for uh making such a conditional decision.

C

um uh Yeah I'll say, I'm I'm a fan of the second, uh the rc uh touches on the on some options uh on either one. So, for example, even if we were to to stick with just using labels, we could have mutating web hooks that would inspect the workload and apply labels automatically so that we could reduce the burden on app devs to decorate with all the labels. I would say, what's on the screen. Right now is, as you can see, this conversation from um it's actually even from before september 7th.

C

This is all uh stuff that was ported over when we moved to the to this cartographer repo. um I've already there's been a rewrite to rfc nine um so that they in part based on all the feedback here, um yeah. So.

C

uh So yeah we I'd, say ultimately, uh if we think- and I I my gut- is that there's that there would be a consensus on the need to reduce the number of supply chains that are necessary to be maintained which would require um uh resource level selection. um Then the question becomes okay. Do we do that uh using just labels, or do we do that using something a little richer?

C

I think that's the that's. The big decision point that we should gather feedback on.

A

Yeah sorry using labels and selectors and what is the another? What will be another approach?

A

C

Along with so using any information available in the templating context, so what does that mean? That means one anything in the template. Spec could be used. um I've heard some people refer to that as field selectors, but so that also available in the template, spec is uh the artifacts that have come off of earlier resources in the supply chain.

C

I I suspect that uh there will be some uh steps in a supply chain that could produce an output that would then change what later objects in a supply chain would want to do.

C

The most concrete example I could give is let's say that you have some source code, you put it into the supply chain and the convention service decorates your deployment with some information, and then that makes it possible or impossible for k-native to deploy that code.

C

That's not something that could be known by just examining the fields on the workload when the workload is submitted. uh You would have to wait until the convention service did that decoration.

C

If we and because of that label selectors, wouldn't be sufficient, because label selectors would be applied at the time that the workload is submitted.

C

Instead, we would want to have that whole templating context available for the conditional to be able to examine.

C

What's all the information about, what's happened so far in the supply chain to decide which template are we going to use this k native one or a different one?.

G

In that case, would you be switching on the like it, because the supply chain is usually used to generate configuration not like deploy a candidate of service immediately right?

G

Would it really make sense to switch on the resource that gets generated versus having you know kind of what we do now, where it's it's inside of a template where the thing that gets generated is determined.

C

uh Do you mean using ytt.

D

C

Yeah, so I guess the uh a goal that I have that wasn't exposed in that combo is uh to remove all conditional ytt from uh from templates, I think of that as a code smell and as a complication. That makes it more difficult for um one. I think.

C

I've seen users come in and say like: oh well, there are these examples in the open source um cartographer. But when I look at the uh at the.

C

Supply chains that have actually been handed to me by the platform that I'm on they're full of ytt right, and that would be one reason that I think it's really valuable: to uh remove that ytt, to simplify those templates and to put the conditional logic uh in a place. That's a little clearer.

G

It makes a lot of sense um if you put the conditional, if you make the conditional dynamic and based on the resources that are flowing through that kind of changes, the infrastructure that gets generated over time right so like at one point the supply chain is this set of persistent resources and then later it's this other set and then maybe it switches back. Is that or maybe you generate both all the time and you're just promoting between the two? Have you thought about what that?

G

How that graph changes or what like the implications of like, would you always generate all of them? Would you just generate them the first, I guess the first branch through or something but then keep the old ones around. um You know. Does that make sense.

C

Yeah, um I hadn't thought about what happens to the objects that like, if you change from, uh if it's step the step n, if you change from template a to template b, presumably the object, the most recent object for template a would still be in the supply chain or that's still in the cluster.

C

um I'd expect that you could garbage collect it at that point, but I have I haven't thought about like what would be the dangers of the corner cases there. It's a good one. Oh.

B

That I mean my first obvious one there. This is why I was going to put my hand up for the same reason, stephen that that I I understand where you're coming from with that idea with schumer. But my concern is like you leave a k-pack down and it builds another image. It builds another image, it's still producing output, but it's no longer selected for in the supply chain. That's been dynamically created.

B

You know it's. That kind of uh um uh I mean k pack yeah with the builders, I'm yeah. um I I think, there's I think if we can assert that for a particular workload, you have a particular shape, which means not being based on the template context, but only on the on the the workload.

B

That's a much safer saner, but not necessarily flexible enough solution, but we should start with the safe and sane and worry about those edge cases see if we can worry about them. Some other way that keeps everything more easy to reason about.

C

uh I don't in into that. I I don't have start simple, makes total sense to me. I I think that the uh I'm curious.

C

I think that the danger that you're, pointing out, which you know the the problems that you're pointing out, uh makes sense, uh but I think that they are inherent in that use case that I was putting forward um that you know it may be that at some point, steps in the supply chain start to invalidate later steps conditionally.

C

If that makes sense, um so uh so yeah and- and it's just a question of like do we live in that world or not do do we have users that will have that that need or not um until we know that we do like. Let's do something safe and simple, uh is a totally reasonable approach.

C

Yeah you're sure.

F

C

F

um Yeah, I I mean a lot of my ideas- have already been addressed by others, but yeah. I just want to point out that these are two very different. Like questions we're raising right, it's like one. Do we want this dynamic nature in the templating at all, and then uh like do? We want to be able to switch templates based on something static like the label or some property in the workload, and then the other one is like do we want this to be dynamic based on other artifacts in the supply chain?

F

And I just I just want to call it that we should reason about those separately.

C

uh Marty marty.

H

I also just wanted to point out: do we not right now have the problem of the garbage collection already like if a different supply chain gets selected, because a new one comes in that matches better anything that was stamped out by the original one is going to stick around forever.

C

I think that is correct.

B

Yeah, I think, that's correct, but I think it's much easier if it's not a dynamic supply chain to make a decision to remove the old one, because a new one got selected right.

H

Yeah, I agree, but I think I'm just pointing out that these are problems that we have to solve to some degree either way. You know, and I'm not saying that I didn't necessarily want to do the dynamic selection, but like yeah. The problems are not ones that we don't have to address anyway.

B

I mean, I don't think it's garbage collection that has me concerned so much as um uh the simplicity of read, like it's already a complex system, we're trying to find ways to make it easier to understand easier to modify.

B

I think I put that above those those criteria personally,.

H

Yeah definitely hear.

B

That just trying to call it out just before you go stephen. I just want to mention I've put in an item for the fact that we're doing a hack day on friday, um where we would like very much to just slam some ideas and present them on on. You know better or basically a way to try to move away from if this than that, wherever we can, including all of these things that worship has brought up.

G

Yeah, that sounds really interesting for sure.

G

um Actually, I had a question about the the label so putting the dynamic generation aside for a second and thinking about the you know, if you're just like just going to use labels to determine which resources get generated statically when the workload's created is that going to make connecting the inputs and outputs together like kind of hard to see, because if you connected something that was mislabeled you'd be pointing to an input that didn't exist in some instantiation of it.

F

I think, like in our artifact graph right, they're, always tied back to the resource that created them under the hood.

F

And so, as as things are flowing through the pipeline through the supply chain right, you would, you would always still be able to trace back that graph because you may like, even though there may be, like certain other items in the supply chain that didn't get stamped out like the artifact still has to come from an individual object.

G

I'm saying maybe I'm misinterpreting rfc9, but in the rfc it seems like in the template refs like, depending on the state of the workload or depending on the labels in the workload different um or okay. Are you saying that they have to be in the same shape and always have the same outputs if different labels get selected.

G

F

Not necessary, I don't want the supply chain that has to be in the same shape, but I do think that uh your upstream, like yes, your upstream uh your upstream artifacts, still need to fulfill downstream contracts right. So if I'm a downstream template that relies on an upstream say image that that image still needs to exist.

G

And if, if you depend on an upstream image, but a different version, a different labeled version right doesn't depend on it. Then you could end up with a upstream thing. That's happening for no reason right, because it's not actually fed into what the graph ends up. Looking like for your workload, I'm not, I think, I'm not complaining about like a problem, a user interface thing if that makes sense, yeah like we, should think about what we should make sure.

G

This is easy for a supply chain, author, to reason about, what's going to get the infrastructure, that's going to get generated to match the workload, but I think I like the idea, because it keeps it very simple, I'm just trying to think through all the different edge cases or it's more simple than you know, making things conditional on the parameters or you know, especially, I think dynamically would get really uh hard to think about, but the I want to make sure that it's not it's not hard for a supply chain, author to reason about what gets generated in the different cases, but I think I think it's manageable as long as they're.

G

All in the same shape, but there are some things to think about, like you know not accidentally, creating meaningless things, if that makes sense, based on your input.

F

Yeah, so like one example, I can think of right is you might have a supply chain that defines kind of like two paths right one starts with source: it builds an image and then passes that image on and then another another kind of branch in that supply chain, something that just you know comes with a pre-built image right, and so I think I, I think, you're saying that just make sure we don't come up with um like a git source that does nothing right.

F

B

F

So to me so to me, in that case it would. It would skip kind of like those first two templates because it doesn't match on them. It would go straight to the image source template um so that it would just like just start discovering from there and then those artifacts would be fed forward, but yeah user interface problems for sure. I.

B

I think this adds a.

F

C

B

Sorry, hashima, okay! I I.

C

I I'm surprised to hear a an approach that assumes that right now it is still the case that, if, uh if uh step n in a supply chain can't be stamped out, step n plus one will not be stamped, will not even be attempted.

C

um So to achieve what you were talking about, josh, where there is a um where you could have a resource that says like oh, should I does that label one? No. Does it have a label? Two? No! Does that label three! No! Okay, I'm not gonna! Do anything! I'm just gonna go to the following step um would be a a change to the supply chain.

B

It's only like an underlying detail, though right it's a it's something we never got around to making sure that they all operate, no matter what right.

B

There was an issue at one point to go and make it so that they always got stamped if yeah. This is my point. That's what I was gonna say to that.

C

Undoubtedly, um uh I think the idea that you would use the conditionals to say make the I had assumed that if you define three conditions on a step and none of the match that the um that that would be taken as an error condition not as a.

F

B

C

User expected user behavior.

B

I was that's that's what my comment was going to be the stevens point like during the hack day. I've got a bunch of ideas in my head of what criteria I'd like to be able to meet, and I think one of the criteria I'd like to be able to meet is the ability for a supply chain author to have defined and declared the state of their supply chain such that they can tell if it's.

B

uh If it's unsolvable, if there's a way that the selectors that are required to select paths through the supply chain, results in an unsolvable so that they are made aware that you know, if someone doesn't supply this or does supply this you'll end up in a place where you it never ends well before they even have to supply a workload to test it right. So that's going to be one of my criteria to see if we can't fulfill that. That would be quite awesome whether or not it's possible it's another thing.

B

But that's uh it's a good point. It's a valuable point, because it'd be nice to be able to say, like to have a strong type check right on your on your supply chain. Assuming your template is something that takes an input and an output.

B

You know a set of inputs and an output successfully. Does the declaration of your supply chain result in those all connecting uh based on the different variables you could provide? That would be quite neat, not sure if it's possible, but it'll be awesome.

G

I think, as long as you allow for as long as you say that you have to and like for a given like forgiven, step right, uh this step always results in something that looks the same. Regardless of what labels happen right, then you get a strong guarantee that you're always going to get a functional supply chain.

G

It'd be interesting. If you could say well, you don't have to as long as the graph is solvable or something like that, it.

B

Makes me feel like you need nested nested templates right, that's going to be the interesting thing, because some things need to be replaced with multiple steps so and that's why I want to do a hack day, because yeah yeah, that makes sense.

F

We could talk forever.

B

Or we could demonstrate some of these ideas. I.

F

Think we have an rfc about this too. We kind of have an rc around that too um supply chain snippets right, that's kind of the idea of like grouping together sections and so and then making those sections swappable.

G

Kind of embedded snippets or something that's a way to.

F

Or like yeah, you have like two build snippets right: one is uh a git source and an image builder, and then the other snippet is just the image source and those are interchangeable.

B

As long as they have the same inputs and output, the requirements right, I think one of the struggles we have at the moment is our templates. Don't clearly declare what their input requirements are. We could ensure that we know what their input requirements are if we could abandon a white dtt all right, because ytt makes it very hard for us to be decisive about what inputs we used, whereas our templates make it possible for us to be decisive about what inputs expect.

A

C

Yeah, actually, the whole conversation just now is what I was going to talk about was. Should we specify that, when you.

C

In the rfc I say like template, refs and then uh yeah. It specifies each as a list specifies each ref in the same manner. But uh it's like I was thinking. Maybe we should say template refs, but we declare these are all image, template, refs and there's an error if they are not um essentially uh in an implement implementation step for the same along the same lines as what stephen was thinking.

C

One one thing that would become interesting, then, is: do we declare up front what the um what the type is for each snippet.

F

Yeah, I think, there's about 10 million small decisions we need to make for this and they're all sort of related and sort of not related at the same time. So lots more thinking to do in this area.

A

Right and as you may see, rfcs always trigger really interesting discussions so interesting that they have their own space of these hours, so yeah so far, it's great. If we need to continue this just feel free to add it to the office hours agenda. For now we need to move on.

A

We just have less than 15 minutes for this meeting. um Okay, thank you all follow up from previous meeting well on previous meeting. If you uh remember, we had members from the oss supply chain team from vmware and they also request to have a demo to have someone walk them through.

A

uh You know really instructor level how cryptographer works. What's the the overall story on on using it and uh I've been kind of collecting the similar requests from even from the beginning, in the in the introductory blog post, when cartographer was announced, the idea was to have a demo recorded there and it's an outstanding request so far, and there are, there has been some other teams also asking for this, so uh I was wondering if we could solve of that in one single uh space.

A

If someone would like to volunteer sorry to have a demo here in the community meeting, it will be recorded and I will be able to extract that and use it as a enablement resource to put in the website and also in the youtube channel uh 101 demo intro to cartographer.

A

So um I don't know what do you think and.

D

Are you looking only for uh like the developers on the team or anybody anyone here?

D

um I would love to like I'm working on a demo, but I don't know that it's like exactly what the development team would want to show. So if somebody's on the team wants to is willing to like take a look at what I have first, I'm happy to use that if you want, uh if it helps and then of course you can always say, that's not what we want on youtube, you didn't get.

A

It thank you cora. Thank you. Oh I don't.

D

A

Ushuma has come in yeah. I was just.

C

Gonna uh point out um rash and I are scheduled to do uh tgik in mid-february, so I was like oh maybe we should get our act together and figure out what that's going to look like and then our practice run could be.

C

Then I rash, if you're anything or I want to talk about, scaring you, but I need to be scared so that I get the the fire under my and my pants to get going. Yeah.

B

I had yeah, I had committed to a history sort of leading into why cartographer. So I hope you know I'm not going to. I haven't put my hand up for demoing at this point. Maybe cory can.

A

Help with that.

B

A

It looks like we could again work. uh You know, attacked him with korra and ushuma to produce this demo. It will be helpful for for koran and also for yeah for the engagements we already have with djik and in general. So if you don't mind, I will out you both, and I will you know, coordinate with you uh when you feel ready to do this here and I think it will be useful. I will make sure that things that have requested demo will be here the day that day that session, so they can provide comments.

A

Thank you great open, my discussion. Well so far, there's only one point there. If you need something, please drop it there, uh but yeah I was. I was thinking considering um you know watching what what other uh oss projects are there, how they are handling community meetings?

A

What's the overall theme on the overall goals for that kind of meeting I've seen a pattern on having a space for issued, triage or user story grooming revision you may call it and- and I was wondering if we could make it uh a part of the community meetings so in in the future users out there could have a boat or who have visibility into the decisions of what kind of uh user story to review before committing to uh iteration to a release.

A

So I wanted to grab your thoughts around that.

C

C

I think my first thought is we're going through a lot of road map discussions right now.

C

And they take more than half an hour so.

C

uh Yeah, we, I think, the the suggestion and like hey, we we're an open source project. We should. The roadmap should be open, makes total sense. um We should be able to take. Community feedback, makes total sense and.

C

Then there are a number of everybody's maintainer on the project. Right now happens to also work for the same company and have a lot of time that we spend together.

C

So yeah, I don't think that we could do a one-for-one swap of that and have all the time that we do there in the open. And I don't imagine, there's any community member that would want to come to all of those meetings.

G

Do you have an ipm or like a planning meeting, that's a closed meeting for cartographer.

C

Yeah I mean we have. We have a pre-ipm on the calendar, a weekly pre-ipm, a weekly rpm that are both on the calendar. um We don't always hit both of them, um and then we also have.

C

This week, we've had multiple meetings about uh just a road move.

A

Next month, yeah, I was wondering about the probably the pre-ipm and probably I'm wrong, but I don't know if the gold free ipm is exactly to review user stories before uh planning the actual iteration or the actual release.

A

So um not exactly a roadmap weekly roadmap discussion, because that will be just too much just something similar to a pre-ipm.

G

Is there a reason we don't just open the meetings that we're having if we're just working on open source and it's you know, yeah.

A

I'm not sure if in that meeting right now there are some property stuff that we cannot discuss there. There are some issues related with the commercial distribution. I'm I'm not sure.

G

I I think that you know the team isn't focusing on commercial things right kind of moving forward, so.

G

Unless, unless something's changed in the month, I've been gone, it seems, like maybe it'd, be possible to uh open more that's.

F

It well what's our goal: is it just to give community members a say in our roadmap and our priority and stuff.

A

Like that, or is.

F

It to surface that information or.

A

uh Yeah first thing: I'm trying to level set on what are the um the: what is the design for a for a community meeting? um It's a space for users to bring questions. It's based for maintainers to give status updates and also it usually have a space for uh issue, issue triaging issue revision before committing to a new inspiration.

A

So I'm aware that, right now the cryptography team does weekly user story revision before ipms. So I was wondering if that previous revision could be a part now of the community meeting it's useful because he could reduce one meeting. He could condense both things in a single meeting and also it will provide visibility for users out there on the decision process.

F

I mean yeah, I'm personally fine with opening up our our ipm. I was just like yeah. If people want to attend um yeah, I have no problem with that. um It was just like I guess my my point was that the the output of our ipm right is: is our issue board and that's already publicly visible, but if people just want to uh to be involved in that process, then sure.

A

Yeah cool thanks!

A

Thank you. Okay, uh anything else. You would like to comment. Discuss nope, okay, again, thanks you thanks! So much for your time and see you next week have a nice day.