 I'm going to start with the next talk. It's going to be consuming and replying cloud events by Pablo from TriggerMesh. Take power. Thanks a lot, Carlos. Can you hear me? I guess that suggests. So I'm Pablo from TriggerMesh. I'm an engineer there. And hi to all the people I haven't said hi so far. So this presentation is, you know, there's been a lot of smart people here with super cool topics. And now I'm going to talk about replying to cloud events. So I feel a bit like the underdog here, because this is mostly trivial. But I'm going to focus on that space between a broker and a sink. If I name something called targets, it does how we call sinks in TriggerMesh. So oh, yeah. Thank you, Carlos. So that is going. We are going to go through five scenarios. And those scenarios are all about if you have sinks, if those sinks should reply or not, in which scenarios you need to reply. And what are your choices when replying? So the reason for this is I don't know if people here follow the activity around Kubernetes, around Knative. There's a new task force called Knative Flows. And in there, we started to have some discussions. We ended up with two different initiatives even there. So one of them is Knative as an streaming platform. So an streaming platform where you probably want to do analytics on your events on a time frame, on a time window. And then you also have integrations kind of flows. And there you want to have something maybe that will be in the end some higher order object. And when you have that, you will need to do translation just as Roland did now. So you have a number of components. They might be parallel or not. But you have something that will need to have different cloud events interacting among each other. So if you think of what we have so far or what we find at the repo so far, you will see this ACK, not ACK, should be familiar to all of you. So if you call a component the choices for a broker is that this answer with ACK or not ACK. ACK, other than just saying, hey, this went OK, you also have the chance of producing a new cloud event. But with not ACK, you could produce a new cloud event, but it's not going to go anywhere. So at TriggerMesh and also at this new task force, we are facing some challenges in there. So let me introduce the first scenario. So this first scenario should be, by the way, that symbol is like a broker or a channel. And in fact, this is not specific to K-native. This should be applicable to any Q system that you have. So there on the right, there should be a component that might subscribe to something delivering an event. And if you say ACK without any payload, that means OK, I received that. You don't have to repeat that, because this track there might have delivery options and might have the retries and might have deadlier queue, for example. So what happens if your component returns a non-ACK? So those retries are going to, the ones you configure, are going to retry again the same request, the same cloud event. And if none of them are successful, they will get to a deadlier queue in the end. So this is super trivial so far. And there's something we've been doing at TriggerMesh for more than a year. So since we repeat that over and over at our syncs or targets, we created something called the reply, which is a library that we need to revisit now. So if you follow here all these ballots, these are more or less the requirements for that. So this is highly opinionated. I'm super interested if you have a different point of view here. But this is what we learned so far. So Kennedy Beventine does delivery. So you could think more or less this is imperfect, but you could think of the broker as being the postman or postwoman that knocks your door, hands you a letter, and says, good one. You open the letter and say, hey, I don't like this. And they say, I don't know. I tell you with the letter, that's up to you. So you either say ACK or non-ACK. But the analogy is imperfect because you could also produce a new one. Hey, postwoman, here's my letter. So that's not fitting perfectly. But in this case here, we have a non-ACK is used for messages that were not delivered only. If you had a different kind of problem, let's see what happened with non-ACK. We'll see later. So the letter thing contains non-delivered events. Should we use non-ACK if we receive an event and the event is malformed? If we use non-ACK, it is up to the broker or maybe to your subscription or your trigger to define the delivery. If they repeat, if you have, hey, five retries in a linear of five seconds away one from the other, so you're wasting your resources. You are making it easy to do a DOS on your cluster five times easier. So let's see the next scenario. So what happens if I send ACK plus a payload? So this is also expected by all of you, I guess. You get a new Cloud event. So this is OK. But you know, I saw this in a presentation in the community some time ago. So you should avoid loops. Usually when you subscribe, you don't subscribe to, please don't subscribe to all the events. Use filters. But then if you filter by type and you do some kind of transformation or reply back, make sure you are not replying with the same filter that you put there, so with something that matches the same filter. So I'm going to take note of that, that we should take care or create somehow at that reply library that we should be making sure that users don't use at least the same type. The type is usually always in the filters. What else? And let the user decide if the response cost event should be produced. So let's say that you have a sync and the sync returns something. It creates something at a database and brings back with how many bytes that the size of the new record. But you are not interested in that. And as you are not interested, there's no component listening to that. So it could be nice if we all create syncs, the same as people create sources. We also create syncs. And those syncs have the option of saying, hey, no one is listening to that. I don't want to flute a broker or whoever is calling you with messages no one is interested in. So it could be nice if we have a spec. We hand that to the user and say, hey, you have the option here to opt out of any response. So here start the super opinionated stuff. So what happens if there's an error? And it is not a delivery error. So the cloud event gets to our sync. And our sync fails for a different reason. Credentials. The credentials are obsolete. So what should we do? It sounds probably good to let it repeat maybe three times because the delivery option says that. And maybe it will end at the letter Q. But it will be there along with the non-delivery stuff, other errors. And you know what? Any reply you get in there is not going to be there. You are going to get at the delirious sync, the original event. I think there's a good reason for that. So if you get some other thing at the delirious sync, you are making up a new event. So should a broker do that? Sounds super opinionated. I'm not saying no, but sounds super, super opinionated. So here's what we did. And some people who are not agree at all with this, but works for us. We are saying ACK in the sense that I received that. I didn't have a problem with you, my dear broker. I had a different kind of problem. And then we recommend people to create a new type, which is an error, so we can later check what happened there. And inside there, we should have a structure. We should have a schema we always use so that if we want to put it somewhere in some log analyzer on some automatic tool, it could be digested by whoever. So this is more or less the summary of what I already said. So only ACK will get a Cloud Event response. The Knetive code will discard any Cloud Event that you get back, but has some non-ACK. So it won't benefit from Knetive delivery options. Also, it won't get the noise of a Knetive delivery option. So that's up to you to measure and act on in consequence. So and the development hints, we already said this. So defining error type and schema could be super awesome if we all do that in the same fashion and we don't have a, hey, trigger mesh error, and then red hat errors, VMware errors. If we have something common, that could be super awesome. But let's give us some time. Then including the original Cloud Event, I think that's a good idea. But you know, what does Cloud Event contains? We don't know. So if we are going to create a library here and the library contains medical data, your medical history, probably we don't want that to be in there. So we should have at the library a check somewhere that says, hey, please anonymize this somehow. We don't want this data to be there. And then obviously, let the user decide if the response should be produced. Just as the case of the ACK, if there's nothing, if you are doing a one-way shot and you don't care about errors for some reason, because probably you're, I don't know, if your Cloud Events are, are they cattails or are they pets? Do you care? Do they have a name? Are they a bank account? And you are withdrawing money? Or is that some kind of metrics? So depending on that, you will probably need to configure or allow your users to tell them if they want it to be produced or not. Before this one, and just to picture, because I don't have a proper demo, but I have something that I don't know how this is going to be. I don't know if you can see this. So I have a tool, a super, super stupid tool I'm not very professional. I hope it doesn't panic. And I'm being honest, because I was touching that there, and I'm half asleep. But I have a broker, a car pod, and then a number of services, and those services are syncs. And they're super simple. They just have a parser of how to reply. So I'm not even giving you the GitHub, because it's a shame of the code. But I'm going to show you here how the broker works, what we are getting in the scenarios we've seen till now. So I don't remember if I have this deployed. OK, seems so. So I have, I think, four services. So you have those services. I don't know if you can read it, but I'll go one by one. So we have the CE receiver. So that one has a trigger, and it's listening to. I think it's called in-types. It has a filter for cloud events coming in there. But then the kind of load that the sync is accepting goes like, let me show this, goes like this. You see that there? That's it. It's going to parse something like that. So it's saying, hey, return ack. Later we will say, hey, return not ack. So that's how we are going to test all this. I know this is going to be super boring for people here used to write targets and sync or so, but it won't be long. So let me show you. Here at the top right corner, I'm going to show the logs for the receiver. So right now, that's empty. But that the receiver is going to, if there's any response from them and there's a payload, I need something else to listen to that. So I'm going to, and also, the broker has a little sync. So I'm going to put there at the right the little sync. So the next one is going to be the sync that is listening, that the alert sync is configured with. So K logs, CE, I don't remember the name, that alert sync, user, blah, blah, blah, minus F. So then we also have KSBC. We also have, if there's an error, I hope it gets to the KSBC and only CK. But if there's an ACK and also a payload, I need another service that is going to listen to the responses from the one above. So I'm going to put that one here. And that is the CE reply receiver. So log CE reply receiver, user container minus F. And I think that's it. OK, so let's start with this. I'm going to, I also have a curl pod there. So I'm going to issue this command. And that is telling me, hey, I have a cloud event for you. So if you check the type, it's in type, it's the one, that one at the top, right, is listening to. And if I press Enter, I just expect. You see the info in there in blue, so blue means cool. But now I'm going to do something different here. And I'm going to send a message that tells you, hey, do not accept this. This is going to be an error. But it's not ACK. We are simulating that the event never got there. So let's see what happens. You see, 1, 2, 3, 4. And then at the data sync, we got the original type. You see that? So the reason for that is because the broker was configured with three retries, I think three seconds away linear. So that's what you get. And yet all this is expected. But now let's take a look at this. I'm going to issue the same command. But I'm going to totally mess here. So this is malformed. This is not JSON. So the application is going to crash. So if you look there at the top right, error, and another error, and yet another error. And in the end, I get the original event. So it's not helping me. So it's a malformed. So the delivery was done. But then I know I'm going to, you can send it 100 times. I know that's going to fail. So does it make sense to reply with non-ACK? And then look at what I get at the data sync. It's not helping me on knowing. I know that wasn't delivered. But does it help me to know the reason why it failed? So that is the reason that move us to reply ACK plus some kind of error. So let me show that to you. Obviously, I think this is trivial. But ACK plus event, which is this one I have here. You see, you get this ACK here. And then down here at the receiver consumer, you also have the new event. So this request there had the data, another action, with ACK. So that one over there, send that here. You see the response type is the one this was listening to. But this is super trivial. This is expected that if you reply with a cloud event, it will get back to the broker and be delivered to whoever is listening to that. So let's get to the malevolent creation here. So you see, we are going to do something super similar. But check that out. So we are saying ACK. But this is an error. So in this case, oh, yeah, I'm missing. There's another receiver here, K get KSBC. So my old eyes are not super good yet. The CE error reply. So K logs, CE, yeah, that one. So I'm going to send now that one that is sending ACK but with error type. And there you go. You get a processing of the event. We are not telling K native this is wrong. We are sending that back to the broker. And this one here is getting the error and could be processing and doing some automatic analytics or whatever or trying to fix what went on. And if you are curious about, hey, but what happens if there's a problem delivering? So this doesn't get in the way. So still, if there is a real non-ACK, so you can see that there are two instructions. So the first one is if the retry count is less than 2 based on the ID of the request. But if the request count is less than 2, say non-ACK. But after the second retry, send action ACK. And also this error type. So we are simulating that the delivery was not made for the first request. Then the last one was successful. But it wasn't an application error. So follow it. You see, shouldn't be more of those. Let me check. OK, there you go. Warning, warning. And then the third one was an ACK that got in here as an application error. So that is the thing that we are doing. I don't know if that sounds super weird to you or not. But so far, it's the only way we have. And I think if you think of Knative as a delivery platform, this totally fits. So if we move a bit farther on this, when I saw Sebastian Demo, the lightning talk, he was talking about correlations. So yeah, we have those all over. So if there's a cloud event or a stream of cloud events that this one, a matching sync, is reading, hey, I took note of this. I'm interested in this data. But I need something else. I need the orders there. But I need the list items for that order. So then there's an event, send there, say, hey, someone is going to need this data, put that back in the broker. And this one will need to match both of them. So we will need to do some propagation of IDs. So there should be some IDs over there that are matching them with some other IDs from there. So this one is able to do that matching. So we will need to provide users with some capabilities for propagation. This is not super, super trivial, to be honest, because if you think about that, if you do propagation of all of them, you could end up with, I don't know, how many attributes. And probably some of them don't make sense if you have a super long workflow. You are piling up all your attributes. So what we recommend here is to have some kind of list or maybe some reggae patterns for this kind of, this kind of correlation propagation or attributes propagation. And the last one is my less favorite one, but since I know there are people using this, I included it here. So sometimes you receive, at your component, at your sync something, but then that one, that component, instead of getting the cloud event back to the broker, is sending that to a different sync. So for me, what I don't like from here is that, well, here is, this is a bit more obvious that HTTP is not transactional. So what happens is something fails there. So probably you've delivered already the cloud event, but you are telling back here that this wasn't delivered, but that happens everywhere. So I'm not going to focus on that. I'm going to focus on that component there doing routing. And this is probably a nuance, but I would like to, you know, brokers, if we create or educate our users, brokers, triggers, filters. For me, that's my preferred mechanism for communicating. But we have components that have this policy and possibilities. So if you don't configure a sync at the component, they replay back to the broker. If you configure a sync, they will return to the, first of all, they will contact the sync, put there the cloud event, and then get back to the broker saying, hey, this was okay or not okay. This is just what I mentioned about the, hey, that sync failing. And this is probably the requisites we have for revisiting this reply package that we have. This is the summary there, some more, and probably we will come up with some new ideas in there and investigate what other people are doing. But this is the summary. You know, this doesn't have to be too advanced if we at the community think that some other people will benefit from that. We are more than happy to bring some kind of wrapper of cloud events client where you can have all this. But to be honest, at this stage, it's super opinionated on our side, but we are sharing it here. I'm super eager to know what you think about it. So that was it. I don't know how long it takes. I have 25 minutes. Do we have time for questions? Yeah, maybe we'll have one question, Evan? Easy. So you were talking at the end about the, oh, I send this target an event and it goes off and sends events somewhere else. One case I've seen for that is if you have multiple events you wanna generate from a single inbound event, there's no current way to stuff that back into the reply. I don't think that it's optimal, but that's one of the reasons that you might do that. I know, I know. I don't want to argue on that, yeah. Reply an array of events. That was a quick question. More questions? If not, you can find Pablo at the social, I hope in the states. Thank you so much. Thank you, Pablo.