 Hey guys, good morning. How's it going? Good. All right. Oh, there's no mic on Linux basics. I can't ask who that is. Can't believe I'm one of the first in. I know you're early today. A long time ago, I learned that when my calendar entry pops up to remind me of a meeting, I have to join right then, even though it's like 10 minutes early because otherwise something will come up and I'll forget them and I'll end up being late. Well, I'm allowed to be slow. I used to be a national commercial for Heinz Ketchup where their whole tagline was, it's so slow. I'm not sure if that's what you want to be known as. Yeah. Well, there was the other one, which is there's no other kinds when you taste the Heinz. Not like that? Well, okay. No, maybe not. I don't know which ones were better or worse. Hey, there are national TV. That's all I'm saying. Oh, that's funny. With all the political correctness, neither one would be shown today. Yes. It's funny. You go back and look at some of the movies and I don't know how old you are, but at least when I go back and look at some of the movies that were out when I was a kid, like the original Bad News Bears, it's like, Oh my gosh, I can't believe they actually showed that because they could never show half that stuff today on even on even on a movie. Exactly. Well, I am pretty old. Actually, I'm 64. So, okay, so you're older than me. Okay. Yeah. Sorry. Go ahead. Sorry. I'm just going to say one thing that I've been finding intriguing in the last couple of weeks is I discovered this channel where it's what they call pre code Hollywood movies, which were from before 1934. And it's pretty amazing what they were showing. You know, like just the you know, violence and beaten up women and, you know, heavy drinking and it's like, wow. And that was in the 30s. By 34, a lot of that is cleaned up. But even today with, you know, our ratings, I'm wondering if some of those might actually have to go to, you know, the MC17, MA or whatever they call it. Yeah. Yeah. It's interesting. I think it'd be really fascinating to take a group of people from back then and drop them into today's culture and take a group of people from today and drop them back in that culture and just watch the reactions from both sides. Because it's fun. Yeah. Oh, what was the name of the movie? It was with, um, I think it was with Sylvester Stallone. I want to say Demolition Man where he was like a cop frozen in time and then and then yes, yes. And they were it was they were completely making fun of the, you know, the PC world and stuff. And so I would love to see at what point we're going to end up being that movie, right? Yeah, I just don't want that every restaurant is Taco Bell. Yeah. Oh, my gosh. Okay. Hey, Tommy. And who is Linux basic? I know that I think I've seen it before, but I can't remember who it was. Hi. So I wrote some student paper with cloud events. And yeah, I just want to do. Okay. Yeah. Welcome. If you if you type your name and the company you're with, if you want to be associated with the company into the chats, I'll add you to the to the attendee list. Just we keep track of attendance that way. People can get voting rights because we base voting rights based upon attendance. So if you're planning on joining joining on a regular basis, I'd love to add you to the attendee list. Yeah. Okay, cool. And Mr. Scott. Hello. Morning. Vlad. Good morning, Doug. Hello. And John Mitchell. Good morning. Cool. Okay. Thank you, Linus. Hello, sir. And ginger. Hello. Good morning, Doug. Hey, Vladimir. Are you there yet? Good morning. Good morning. Hey, Mark. Hey, Doug. Hello. That's Francesco, right? Yeah, it's me. Hello. Luckily, I recognized your slinky developer name. Quite characteristic, right? Yeah, at least it stands out. Put it that way. Yeah. So for those of you who are new to the call, we usually start about three afters. It's good people will change the filling. Wait, wait until we start? Three afters, another two minutes or so. Okay. Okay. And do you want to be associated with a company or just for yourself? That's our question. What my colleagues does? The only reason I'm asking is because voting rights are usually based upon attendance on the calls and stuff like that. And if there's someone else from your company who may join, they may want to say, Okay, either one of you can show up to get to get credit for showing up today. But if you think it's only going to be you, then that's fine. We can just keep it as just you if you want. Yeah, for today, let's do like that. Okay, that's fine. I'm just lurking inside this meeting. Okay. And frankly, I have to go quite early. Okay, not a problem. All right, let's see. Let's see if I can remember the names here. I think that's Albert Lucas, right? Yes, okay. Ryan, are you there? Yes, I am. Hello. Hello. I have to leave a little bit early too. Okay, not a problem. As long as you get that little star next to you, you're all good. Mike, you're there. I'm here. All right. I think I got everything so far. Oh, Manuel. Yes, I am. Hi. Hello. And Jim, welcome. Thanks. And unfortunately, I will be here for the whole session. Darn. All right, three after, why don't we go ahead and get started? Let's see. Wow, small group today, only 70 people. All right. Let's see. AIs, believe it or not, at least I don't know about Mark and Ken, but I'm at least thinking about this every now and then. So at some point, we will have some sort of some sort of proposal for what to do relative to us going to some SIG or creating a new one. All right, community time. For those you knew the call, this is just an opportunity for new people or community members to bring up topics that are not on the agenda, but they think may be worthy of a discussion on today's call. So anybody have any topics they want to bring up? All right. Go moving forward then. EU planning. So I believe relative to things that we need to let the conference organizers know about, I think for the most part, we're pretty much okay because we have speakers. I know that the workflow guys are still trying to figure out exactly who's talking, but we can worry about that later. The one thing I do want to talk about today if possible is the answer bar stuff. This is the booth thing. Does anybody have any preference for what we sign up for? Full time, halftime each day or basically random hours? Before I state what I was thinking, does anybody have any preference or ideas on which way to go with this? Okay, fine. I was thinking picking halftime for each day. We could alternate morning or afternoon. I thought full time might be a little hard in terms of finding people to actually staff it and random just kind of bug me because I don't feel like it's fair to people who actually do want to talk to us to not know for sure where we're going to show up and it might change. But I figure if we can at least say we're there morning or afternoon on each particular day, at least gives a little more definitive time to people. Anyway, that was my thinking on the idea for the topic. What do you guys think? I'm going to pick on people. Okay, fine. I'll pick on someone. I'm going to pick on Mark. I picked on you in a while. Mark, do you have any thoughts on this? No, because I won't be going, so I don't have... I could give you my opinion, but I'm not going to be there to deal with it. Okay, fine. Let me pick on people who actually signed up here. Vlad, let me pick on you. Any thoughts on this? I agree that random is annoying. As an attendee, it would be absolutely terrible not knowing when people are there. So definitely not random. Full-time would be rather intense. So half-time sounds good to me. Okay. Who wants to mend the cask or be there? Right. We need a list of people first to see could we do full-time? It might be nice, but I don't know if we're gonna get the people. Yeah, so for the people who are listed up here, do you guys think you will be able to staff the booth at least partial time? Like Clemens, Scott, Klaus? Yes, sometime, definitely. Okay, I can give several hours. Okay, but I don't really want to be there the whole time. Right. Go ahead. I mean, if possible, I would love to sign up for a single four-hour slot. Okay, well I think it's definitely doable. So okay. I agree with Clemens. You mean Scott. Yeah, okay. So, okay. I'm not hearing anybody jump up and down being too overly excited about full, you know, full-time coverage. So I think, correct me if I'm wrong, but it sounds like we're leaning more towards half days. Does that sound fair? Yes, time slices. Yes. Okay, so I think that the real question then is we just need to figure out whether we're morning or afternoon each of those days and I forgot some way to press to sort of vote or do something about that. I'll probably just put together a spreadsheet or something and you guys can fill your names in and we'll figure it out. Doug, I have a suggestion. Yes, please Scott, please. Okay, let's let's do this. We'll do half time. We'll do AM the first day, PM the second day, AM the third day. Done. What do you think? Any objection? All right, I'm going to make a comment even though I won't be there. That you may want to staff it during the busy time when there are parties going on, which is probably the PM-ish time on Tuesday. So we could do this. But that's just me. No, I think considering the PM on Tuesday is the booth crawl, it would be really nice to have somebody there, yes. What do people think? I was aiming for that morning Tuesday hype period where there's not a bunch of beer. The only AM Tuesday and then we get to avoid like this six or eight hours of Tuesday's requirements. This Tuesday is like double the day. Yeah, but doesn't it feel a little bit awkward to miss out on booth crawl? Who's going to bring the beer to the booth? I'm sure we could find some way to get you with your stuff. Now it'd be fun to like talk to people about that during that too. Yeah, it's a good point. I just don't want to do Thursday PM because that's when the swag run happens. People are exhausted, people don't want to be there anymore. Right, I think AM on Thursday makes sense. I think PM on Tuesday makes sense because the booth crawl. Why don't we tentatively say Tuesday all day and we can see if we can get three people to do four hour slots? What if people think about that idea? You guys are killing me today. Could we confirm how many people we have? Like I'm up for four hour slot. Scott is up for four hour slot. That is true, we probably don't want one person. You might want two during the booth crawl just because it tends to be pretty busy. So the one thing is I would have to go back and check with them to see if we could do all day on Tuesday because they didn't give us that choice. It was either AM or PM or full-time. I see. Well then let's keep it like this and we'll roll with that. Okay. Split it up into four hour chunks and we'll start doing a sign these. Okay. When is the face-to-face? We don't know yet. It depends on when they get it. Yeah, I just was wondering if it shouldn't block with a booth. Hopefully not. Ginger, were you going to say something? I was going to say also there's nothing that says you can't be at the answer bar even if it's not your specified time. Like it's a it's a little section and there's people milling around all the time and if for some reason they have an empty booth and you decide that you want to be there then you can always stick your name up there and be there. So in those kind of situations is there like a a cloud of would there be like a cloud of events like logo or something to make it clear that I'm standing here because of cloud events? Yes, well for San Diego anyway they they boo booed and did not have logos which was problematic. So unfortunately it was just a plain white sign with the name of the project. It still worked but it was a little unfortunate. So I was told by Katie that they were going to fix that for the next one so hopefully it will have logos and everything but they put them up with like Velcro. So if you only have part time then they'll split your time with another project maybe and so they'll change the sign out depending on who's supposed to be there. All right okay okay but that's a good point we could we could technically just crash. Okay but as of right now I think this is what we're going to head for right. So I should tell them option two and then PM AM AM as the plan. That's not right? Okay not hearing any objections let's go with that. Let me just make sure I'm not missing anything else. Can anybody else think of anything else relative to KubeCon that we need to talk about? Okay one thing Clemens I thought I sent you a note but I might have forgotten. Can you send me your title that you want? I need to let them know you're a speaker and they're going to ask for your title. You mean my job title? Yeah. Chief Messenger. Send me a note of what you want to really say. Chief Messenger. Okay fine fine fine fine okay anything else for KubeCon? All right SDK call we didn't have one last week so nothing to update us on. I do believe we're on schedule to have a call today assuming people want to talk so hang on after the call if you're interested. Relative to the Rust SDK just this morning I did hear back from these folks who were students at some university I believe I remember correctly and they are interested in contributing so I was going to try to get a conversation going between those folks and Francesco to see about whether it makes sense to try to merge these efforts and stuff like that so I don't want to try to ask for a vote yet because we don't know exactly which project would come forward or whether we both kind of a thing so I want to have those discussions offline first before we bring that back to the group here assuming everybody's okay with that um but I'm bum bum but also okay Kathy I don't see Kathy on the call. Kathy you're on the call. Kathy is there anything you'd like to update us on relative to the workflow subgroup? Kathy are you still there? Okay maybe she's set the way for a second we'll circle back around. Let's go ahead and jump over to the cloud description stuff and Mike please you want to go first. I always have trouble in muting in zoom um I think this is the beginning of some of yeah so I updated this doc to just reformat a little bit into like we had the use cases shoved down in the querying event producer section we hadn't written goals um so that that's stuff that I wrote came out of my head probably needs review from others um one thing that I wanted to point out it's below the querying event producer added a new start of a section called registering with a producer or an aggregator um and I'm wondering if we should think about a protocol um to advertise that you produce events that can be discovered maybe it's a little circular here but thinking about um a common a really common use case that that I hear from um the customers that I talk to is uh you know they're writing systems that might receive an event that is triggered by some outside system a file is uploaded to a cloud storage system the database record was updated um but then they want to turn around and uh emit another event so um you know a concrete use case uh an image gets uploaded they do some ml on that and maybe you have you know three events that are made up out of the bounding boxes of interesting objects um so being able to have the production of those events and the consumptions of those events fit into the same discovery and subscription system that events coming from the cloud storage system I think is a useful thing to think about so um haven't talked to anybody about this so I would love to get feedback from folks and see if this is something we should explore further um from the from the subscription subscription API side there's clearly a um a need for a need for having these um uh the discovery registry whatever we're going to call this thing um federated in a way that you can um that effectively anybody who's who's interested in subscribing has a registry with all the interesting events somehow in reach and uh and in reach means within their um networking scope which which means in many in many cases that um somehow we have to figure out how to propagate um those event registrations from the producer to some middleware so that that is already the the first case that you that you have here where you have a event producer is delegating the subscription management to a middleware that means that the producer at that point when it registers when it basically announces I'm going to go and publish events to that middleware it also needs to go and advertise which events are going to be published and then if you have this multi a multi-level distribution where you have let's say a scenario you have an a producer which is a device which publishes to an intermediary which is an iot gateway that sits somewhere behind a firewall that then in turn goes and publishes out into a cloud's iot system uh cloud iot uh infrastructure that effectively anything that can be raised by that iot gateway must then be further down published into the cloud gateway so that if there's a downstream consumer that sits at the cloud gateway can know what's available from the devices that are upstream so there's some propagation of of of advertising data that needs to happen in some way that's a good use case i think it'd be interesting for me to think on that a little bit more yeah so so effectively we have we know already that we have the problem that you need to subscribe and and klaus raised this first two weeks ago where you are just you are subscribing to events that are on the middleware that is are not raised by that middleware but that are raised upstream and then exactly this eventing domain idea and where you are you know you're just you're subscribing from this in this big picture you're the event consumer and now you want to have a an event that is raised by you know one of the producers which are on the other side that link outside that box and the question is how does that happen how do first how do we propagate the subscription and that's one thing that's kind of in the subscription api part and you know how do we make this so that we can go and propagate but then also how does that consumer even know that the green thing that sits outside of that box in one of those other domains can can raise that event so there has to be some advertising propagation that's happening and then arguably goes first before you can subscribe there has to be knowledge about those events being available back up there anybody else want to comment on this topic here so jim good i'll take a stab so i agree with what clements is saying and i think that does all have to happen internally but i wonder you know if you take a client-centric view to this capability all of that should be hidden from them yeah so for instance yeah if if we were emitting our current web hook event stream you know using cloud events and obviously today you you know what it is so you would actively subscribe to it but um you don't need to know all the component domains within PayPal that actually are producing those events yeah you're just from a client perspective you're just subscribing to a stream so i um without sort of dismissing what clements is saying i i wonder if that's going down into the weeds a little bit um but obviously you know you guys that have cloud infrastructure to deal with is maybe you're coming at it from a slightly different angle than maybe i would if you get what i mean ryan your hands up next yeah i was just going to add in addition to and forgive me if this was this was stated and i missed it in addition to the events being you know sort of i guess centrally or or a consumable vice through some middleware that isn't the actual producer of the event i think we are interested in in having the same sort of model for discovery as well we want we have at tilia we have all of these different systems all these different products at all are going to be you know generating events but we want one place for clients to know what those events are and how to go and get them yeah so i was just going to say i mean i i wasn't saying that that function doesn't need to exist i i'm just wondering what it needs to exist in the spec you know that that sort of internal aggregate publish republish you know delegated subscriptions all that sort of thing is more of an internal concern um unless i'm not understanding the comment correctly so my hands are fixed um from my point of view i i can definitely see a definitely a use for this kind of thing because especially with other systems that like we have with nivm we want to try to promote the notion of self-registration for things right when you bring our new services or whatever it is you don't want to have some someone or some process be a bottleneck right you want that new service to be able to register itself automatically and so having standardized apis and mechanisms to make that happen just makes everybody's life easier my only um concern and concern might be too strong of a word is whether that would be part of this piece of work or a secondary piece of work because i think as jen was saying it feels a little bit like you're talking about a different of a different role or user would use these apis right because the subscription and the discovery stuff that's all in essence you know that consumers are going to be using those things and this is more like an administrative kind of thing or service provider kind of a thing at least that's the way i'm thinking of it anyway uh claus your hands up next yes i think it just becomes relevant as soon as you want to also achieve interoperability between those eventing components so i mean we are we are running our infrastructure on top of other infrastructures and so we have naturally also some need for interoperability there anybody else want to comment on this um i think i i i kind of agree with jen i think you know kethy i wasn't sure it was just me enough but you're breaking up really really badly you have a very very poor connection yeah is it now is it better now oh yeah actually it is yeah that is better oh okay um so i okay um i tend to agree with jen i think you know um we need to solve this as a classroom um do this is the i so you're breaking up you're breaking up again kathy oh i'm sorry then maybe i should just call in again i don't know what happened okay okay sorry yeah sorry about that kathy anybody else want to comment on this or on the above section that might get it up here okay anything else with the discovery section if you want to bring up or talk about so it um as a next action item i was going to try to put together some example api calls in additional we have there um it's it helps me think anybody would like to help with that that would be awesome are you guys having very little phone calls uh we're not if you if you would advise that we should i'm happy to schedule that as well it's up to you guys every you know as long as the work is done i don't you know i don't care how it gets done i was just wondering um whether you guys are having you know offline discussions among the four of you to to figure out what goes in the doc kathy you guys how you want to work i just i was just curious okay um in that case clemens you want to take us up to are we going to speed up where you are with your section uh yeah we left um except for addressing your objection on the uh producer and consumer sorry no on producer and intermediary um which you made a comment about about the section quote the the text being repetitive god um i then continued kind of a little bit further down if you would scroll a little bit um not here not here even further down and in creating subscription so um i have um i have done the unspeakable and i have pasted a uri temporarily to a w star spec and i apologize for that specifically to you dog i i loved it personally i thought it was great so this is for the younger for the younger amongst us um so this so that i have pasted the w's eventing spec specifically because that is literally the prior art and w's because w's eventing does quite literally exactly the same thing as what we're trying to achieve here so um uh this is a great point of reference from a from a terminology perspective and also kind of from an information model perspective even though like all the w star specs w's eventing suffers a little bit from being um from enjoying abstract abstraction and not getting concrete enough um but um so i pasted this as a point of reference um and also to justify the the term of a subscription manager um and uh i basically put this in so that the rest of the folks who are working with this um have also you know can read this ones and kind of know what has been done 15 years ago about the same topic in standardization um so for the subscription per se we have not gone so far to bind that to a protocol um and the uh but we have worked on the um i have i've worked on and we all have worked on the information model um because uh the sync ui which i took from your description um dug and where i think we still want to go and change that name to um target or something else um because that is not sufficient for the ui itself or the scheme of the ui itself is not sufficient to indicate what protocol you're speaking um specifically there's stuff like like web socket bindings for protocols which make the ui w s s and then you can't tell whether that's you know mqtt or whether that's nqp because effectively you learn the client will learn about this as the um as the the sub protocol is offered um we need to have a special indicator for what the protocol is supposed to be and so we have a protocol indicator um nqp and then mqtd3, mqtd5, hdp, mqtp, kavkar, nats um i've separated mqt3 and mqtd5 out here i'm not sure whether we can keep this then um for all the protocols for the particular protocols there will be protocol related settings there is um we're going to scroll down in a moment not yet not yet um and so those will effectively indicate all the things that are relative that are specific to the chosen protocol and that endpoint um and then um the sync might be the endpoint and then the config the the config map that was there already will might then hold information that is not protocol specific but related to that subscription um you could think of as a retry count or retry duration we haven't really thought of you know through what that might mean but that is an interesting thing to keep there whether we're going to go and take the protocol settings and the config and fold them on top of each other or something we're going to go and see and then um we all know that there we need to have filters um and we have decided that we will want that we will write a section about the filters um that will initially just cover some very simple ones um related to the existing cloud events properties so we're likely covering subject source um and type uh with the prefix suffix and a direct match filter as a as a start and we can still think of whether we need to have something that's a little more sophisticated if we scroll down one and then for the protocol settings there are um I filled out two sections of the ones that we need which should illustrate what I mean with protocol settings so for mqtt you might have an endpoint uri which simply points to the broker and then in the protocol settings you you've um defined what the topic name is that you want to go and send to then you will define whether you want to have the quality uh cost level of zero one or two for mqtt whether you want to set the retained flag with the expiry of that message is um whether you need to have the correlation data header set and whether you need to have extra user property which might be used for dispatching inside of the mqtt broker in some way and then for Kafka similarly we need to have a topic name that we want to send to then we have defined in our protocol binding we have to find um that we want to go and select the uh the key partition id using a selector um and that selector needs to live somewhere so this is the the place where that would live um in the configuration model and then whether you want to set a client id explicitly um what your acc level is that you're expecting here and whether you want to have any retries and there's more for other protocols and that we can go and set and um klaus has volunteered to start filling out um some of those things until our next meeting next week so that's how far we got very cool any questions or comments for clement oh hey jim hey no no this is cool um so a couple of questions um is commenting on this doc the the sort of ways get questions in or commentary in um and the other thing is from a subscription perspective and this is going to go down a bit of a rabbit hole but you know um our customers you know they would need oauth to be able to talk to our subscription end point um to discover what they might be able to subscribe to but for then us to deliver stuff to them we would probably need oauth to them as well so the um the subscription is a bit of a handshake yeah where the client is saying in this instance yeah please deliver to this end point and by the way maybe here's some credentials that you need to use to establish that connection is that the sort of stuff that you would be covering in the um those other sort of uh config maps yeah so there was a there was an expensive expensive credentials field which i cut for right now okay because we need to go and we have to we have to figure out how to do this holistically because all these um there's there's a bunch of different scopes that collide and for which we have to have an idea of how to um to manage those because yes there's a quite a bit of the dance there's the discovery question of you know who can talk to the discovery service the discovery service might be living completely elsewhere from where the subscription endpoint is because the the discovery service is kind of like dns um and you know that has publishing things over there is um different from actually being able to subscribe then the subscription service needs to have it needs to have a different authorization scope and then of course when you subscribe then you need to go and pass the the subscription manager basically some kind of a authorization um grant to then talk to that endpoint and that might be if we're agreeing on oauth then you would probably go and pass a refresh token um with a renewal with you know where you need to know what to go and renew that token or to actually get the access token um so that's all kinds of security stuff that we have to go and figure out how to do this and yes oauth 2 is my clearly would be my preference um to deal with all that and with that dance what i think we also need to have a pedestrian version that literally deals with username password credentials because in very many areas i think that's still where we are yeah no that that makes sense i um there's obviously some um commonality between this and the web hook spec yeah because that today sort of describes how that endpoint is meant to behave that i would be sending stuff to um so okay that's cool thank you yeah the the web expect the web expect that we have is effectively um the the way how we normalize hdp for for push deliveries right right yeah that already says here's a token um and please use that token in the authorization header now the question here is why creating the subscription how do you get that token there and is and is that token that you give to the subscription manager one that it can use directly or is that one that the subscription manager first needs to go and trade for um a an actual access token yeah and and my i'm inclined for since those things need to be long-lived those subscriptions potentially that there is a refresh token rather than an access token that's being traded yeah that made sense cool thank you and but to the first point is commentary on the dock uh the right way or have you guys got a separate slack channel uh no comment on the dock on the dock okay cool right cool um thank you gem uh ryan you're up yeah i just wanted to um add a comment to the the auth piece um there are other um ways of granting access that don't um where where auth might not make sense uh in uh in the negotiation um when creating a subscription or sending events so for example you know a lot of cloud vendors as you're all familiar with um uh have access control mechanisms that sort of fall out of band of all of this so um you know amazon kinesis right um if i wanted to grant access to that i can do that through iam um and that sort of bypasses the need to do auth in mine yeah yeah but you still there's still a token flow is that true yep okay so all the references so for instance we have um i'm not 100 familiar without aws does it but um in um but i think they do this in a similar way but in so in azure you have these um managed managed service identities um which are effectively the identity of the process that you're executing and then you can talk to one of our managed services and it looks like you don't have to go and pass the credential but all the magic is done all the covers ultimately your client still gets gets a token and passes the token you just don't see it got it okay yeah i'm not familiar with how azure does it but i can read up and uh get a better understanding for myself yeah okay i think you're right uh hines your hands up next uh yeah just wondering why the uh um desire to add to the subscription details that have to do with physical authentication and such to the brokers because they'll probably be opening a can of worms already mentioned was the access controls but you'll also need to know things like which broker can i connect to which can't i connect to where i might have multiple subscribing but because of access controls between brokers per road i mean i assume the messaging layer will automatically do that from the event perspective all i think that uh would be relevant would be what is the event so i know how to serialize and deserialize over the messaging and what are the topics that those events are actually flowing across the rest i think you might be opening a can of worms that you don't want to go down that path not just from the protocol specific but because this will work in things other than maps and kafka and everything else you'll suddenly be telling all of them don't use this because we have all these protocol specific clients and authentications and you know it's going to get into what about kerberos and pki and i mean you might want to avoid it because is it really necessary for subscription management discovering of subscriptions and getting enough information to actually publish and subscribe or however you want what message exchange pattern you want to use so the the the goal of this api is to tell someone to deliver events to you so there's a there's a there's a there's a foreign party and you want to tell that foreign party to to deliver events to you and you have an endpoint in your system that's that's the goal of the that's the goal of this of this api so it's for push style subscriptions where someone has events and you want to walk up to them and subscribe so that they will deliver events to you that means that you make an end point available and that endpoint available may be may not be htp but it might be one of those other protocols and therefore you have to go to configure that relationship there is no there is no out of bad magic that you could establish that would make the thinking for operable if you don't communicate all the details but you are again asking for a client to the consumer to produce a direct relationship which is completely against eventing with event brokers where they are completely decoupled and the producers and the consumers are anonymous to each other why would you want to suddenly bind them together in some relationship so that's not true so if you if you go and and and you product example if you use azure event grid in azure event grid the producer produces into into a topic in azure event grid it knows nothing but azure event grid but if you if you want to subscribe to azure event grid which is a push delivery channel then you need to go and provide to event grid you need to provide an end point htp or or one of our built-in ones service pause etc and then you need to provide a connection string or you need to provide with which contains all the information like the credentials which contains the correct address and the port etc all the information that is required for event grid to know where it needs to go and connect to to go and and deliver and that contains the the protocol information everything take a basic mqtt broker it is completely anonymous and almost every event broker are using decoupled producers from consumers including services such as persistence in that because you don't know if the downstream consumers are even online and really don't even care and that's so you're describing pull the pull model which we are describing is a dug if you scroll up a little bit more which we which we define right here so we say there's two final different types of subscriptions one is pull where you walk up to a intermediary intermediary is delivering events through your um through that channel and we're describing exactly how that works in mqtt and mqp and that's where you are effectively using the mechanisms that are in that broker but the what this what this particular message a particular api that we've that we're defining in that on the next pages about is how is if the if that mechanism is not available in the broker when there is no message broker that allows you for pull for pulling events out then there needs to be push delivery and push delivery necessarily requires the subscription manager to connect out and for connecting out it needs all that information in that case i think it might be a nomenclature issue i'm glad you brought that up because from all the work that we've done in the past to me push model is asynchronous eventing and pull is synchronous so it sounds like uh your definitions might be a little reversed i'm wondering if we might want to come up with something a little different where those terms are kind of overloaded because i i would see the exact opposite of what i've always seen as a definition so pulling pulling is i go and get something i don't understand how the synchronous or asynchronous pulling is i go and get something like pulling yeah push is i'm asynchronously delivered something where i'm waiting for somebody to send it to me which is normally what event brokers do right when they're completely decoupled well pull pull pull basically just means that you are you're creating it pull pull means you're creating an outbound connection into the broker and then you're soliciting messages from you soliciting messages from there and push the events themselves are pusher pull not the client connection i assume you always want things to do be from the perspective of the event i'm no i'm i'm looking at the at the perspective of the application programmer generally and from their perspective when they walk up to broker they say receive actively when they use a pull model and and that's the that's that's generally what what pull is like you receive something actively and with push they make they make something available that act that actively listens and then something shows up which means stuff is being pushed to them yeah that's true in a rest model that's not true in an event broker in an event broker everything is done from the perspective of the broker which means is the broker pushing or pulling it has nothing to do with connecting to the broker yeah yeah but doing this with 25 years with message broken yeah well me too just just because i don't want to run it completely out of time i'm wondering hind whether it would make sense for you to add some commentary to the spec itself so that to your perspective it could be taken into account as they start you know hashing on this yeah again my only suggestion is to use term other than pull and push because they're overloaded terms they're not really computer science terms so i think it's the term where i agree with what clements has for definitions i just don't agree that push and pull are common enough that i'm using i have the exact reverse what he's saying is true but i reverse what i call a pull and a push when i do a venting from event holders okay so it sounds like documentation all our blogs all that is exactly reversed right so it sounds like it might be a a wording type of issue so maybe you could offer up either some additional text or to put these words in the right context or offer up different words besides push and pull and then that could be part of the discussion exactly and the common terms that we generally seen are synchronous versus asynchronous versus asynchronous is in my mind something completely different asynchronous synchronous synchronous is really you if you are if you're initiating an operation in your you get an immediate result you're basically waiting for a result and asynchronous is if you're initiating an operation do go do something else and then later the the result either comes to you or you go pick pick the result up which means you can do an asynchronous completion either using pull or using push those things compose it's not it's not it those are different things well maybe you can describe it then by message exchange pattern which is request reply versus publish and subscribe those are also yeah that's so what i mean here right so the pull subscription and pull subscription is also when you go walk up to an mpt broker and you say subscribe this is that you you tell that the mpt broker to send you a message whenever a message shows up and this might be a thousand messages that are coming to you and you've but that's still a pull because you have open up a connection to that broker and then the broker is now surfing on that pipe is serving you messages which means you've done so it's pushing you messages you're not pulling them from the broker the broker is pushing them to you no but there's a there's a there's a there's a clear difference between that activity and you telling you're telling a subscription manager to go and open up an mpt t connection right and then using the pop-up or the publish operation against that endpoint because that is the push thing pushing means pushing means in in this definition is that the subscription manager actively goes and opens up a connection and starts sending events so this is the difference in mpt difference between the subscribe operation and the publish operation okay i'm going to call time here i actually think you guys are in a agreement it's a wording issue maybe i'm wrong so so let's let's end this discussion and hinds can you offer up some alternative text as commentary in the doc itself and that way you and clements can go back and forth offline well actually it might be easier if i do it back and forth with clements because we could come up with 10 different suggestions so we hit on one so that's fine that's fine however you want to do it is fine i'm just trying to move forward in this call right now yes okay done cool all right so jim you get the last word on this before we move on okay so actually i was going to disagree with with hinds until i actually read the stuff that we're looking at at the moment and i think when i hear the words push and pull from a again i'll put myself in the shoes of a client yeah for me a pull and this is a use case we have today is where a client comes to us and says can you give me all the events that are due to be sent to me so it's literally them coming and saying give me a block of events you know so that's them coming and pulling the information from us whereas a push model is where a client says you know please push events to me on this endpoint yeah and so that so the the terminology is slightly different because in a pull model the subscription manager doesn't deliver any events all it does is buffer them up until somebody comes and pulls them so i'll stick this in the notes but that was that was sort of my terminology okay thank you jim so any 30 second other topics or questions for clements about the the text that he went over okay cool in that case i'd like to see if maybe we could close out some of the pr's that are open so let's go to the first one here and just to refresh everybody's memory this is for the cloud event spec um the original issue there we go just to refresh everybody's memory the person who opened this one up was complaining or questioning about some of the limits we had in the spec like the 64k thing whether that was a hard limit or just a recommendation so what i ended up doing was adding some text in here and i believe he gave a thumbs up to it so he was okay with it basically adding some text to the primer saying that these aren't hard requirements they're just recommendations and if you want to go outside the recommendations you're fine but then you got to make sure all the hops in the message path are ready are prepared to deal with it any questions on this and he had injection to approving thank you this one flat he's doing the call yeah but i think you took a look at this one right i don't remember oh no it's fabio i'm sorry i got you messed up with fabio so this one there were he updated our jason schema um for the jason pseudo experts on the call have you guys had a chance to take a look at this one yeah like scott could you take a look at this one because i'd love to get your opinion on because i know you've touched on stuff close to the space i have no do you want time to look at this or yeah sure can you can ping me in the issue yeah okay pr okay we'll do i feel bad it's been waiting so long but i don't want to rush this one because i don't want to screw people up if they have a tooling that's used as stuff so okay um all right administrative stuff this one's fun so last week's call i mentioned potentially changing the governance stock to talk about how you can be added or removed from the list of admins with a greater than 50 votes um that's basically what this says right here so you can be added or removed just open a pr to either add yourself remove yourself the normal voting rules that we have in general are greater than 50 percent anyway so didn't need to say anything special there the only tricky part is well what if someone wants to get you know wants to leave that group on their own not get voted out you know voted off the island kind of a thing um basically the same thing you can as long as you're not the last one you just open a pr um and you can do a self-merge because we can't force you to stay however if you are the last one there and then talk about how really we need to have a discussion first because we have to at least one admin to keep the the group alive and so at that point we need the question whether the group should stay alive at all i didn't come up with any decisions about what to do about that other than to say we need to have a discussion so i figured that's at least a step in the right direction we can get more formal later if we anybody has any brilliant ideas but anybody have any questions on this okay any objection to approving i already approved it yep okay cool thank you and i'm sure well i was objected thank you guys let's see um actually claus we have a four minutes left do you want to talk to your pr that you just opened even though we can't approve it because it's too soon do you want to talk to the pr that you open where was it here to go well i um as we discussed i think two weeks ago or something like this um i added some section to the or a paragraph to the um primer i think it was this section about creating events so there were already um was already discussion in the in the primer before that about um what an intermediary does and or in which case it's a new event so about different cases creating events and so i thought might fit in here um and that there is might be the special case of of creating nested events and that in those cases the data content type should be taken care of that not this cloud events plus json or whatever format is used for the event can be used and then i added the example we had also in the github issue okay yeah good sorry no it's just uh i mean um as i'm not a native speaker i'm i'm happy to correct my wording whenever someone has some things i should correct any questions or comments on this that just on the face that just looks a bit odd i wouldn't know if is the type of that event my then or is it cool event i'm not sure if i take one of these in isolation how i would know it is two events that's the point so there is an inner event of type cool event that is nested into an outer event of type my event yeah this this is correct and the important part here is that the content type of for the as it is shown in the outer event is application json and not cloud events plus json hey obviously like i said we're not going to approve this today but i wanted to get out there for people to be thinking about it and look it over the the challenge here is that it's the whole nesting issue is it's quite confusing in the beginning so to just add some short section that explains that this is really challenging for me i felt the premise already very long so i didn't want to to add a long explanation my only comment is if you can wrap it at 80 characters i'd appreciate that oh yeah sure i thought i did but somehow i am still struggling with visual code i guess so so the more i actually i get it now okay sorry for that mental brain fart for a second um is there an argument here that if you're going to do this you might as well or we might as well standardize what the type is what the c type is to represent a body of another cloud event in this situation i think it's dependent on your application so like for example in a pipeline you might have a follow-up where you want to have the follow-up be structured and the invoking request be binary i wonder if you could use the data schema yeah okay thank you okay i think with that we're technically almost up just turned one o'clock in my clock so let me just do a quick roll roll call um dug are you still on the call i'm here all right cool and eric hello hello and whoa how did i do that ray are you there yes i'm here okay now if you can even your company name appreciate that yes and um rxm rxm okay cool and hamsa are you there okay if you can come off mute if you know anybody else i missed for roll call uh linux oh there you go he's there okay yeah hamsa if you can give me your your full name in a company you're with and that's chat i'd appreciate that just for the attendee list otherwise i think everybody else is free to go unless anybody wants to stick around for the sdk call immediately after this one so we'll give you every good people a minute or so to to hang up and then we'll start the sdk call thanks everybody all right thank you i'm just gonna look dug if that's okay of course merrier i don't expect it to be a long call but we shall see we've been surprised before now i have to go back into a check linux basic who is that again i apologize lining those yeah there we are okay i'm timeboxed to like 10 15 minutes because i have to run to another meeting so i wouldn't really put myself on both okay that's fine thank you all right when we're going to get started any topics for discussion i have a slight one and so it's another reoccurring theme i guess i would like to break apart the golang sdk client piece because it's all donated to the cncf i think it has to live in a repo inside a cloud event somewhere but i think it probably should get pulled out of the sdk that deals in encodings so i'm sorry say that again which part you want to pull out the client have any comment on that sorry not the cliv i want to break out the client piece it's it's not a command line client it's the the go interface client that deals in events okay all right so there's like there's two layers to it there's the protocol bindings that converts cloud event conical forms into the bits that should be going on the wire and then there's this other piece that leverages those to to do like kind of runtime yeah interactions can you want to do this and you want to do this because it'd be easier for people to consume it or for some other reason i think that the the target audience for most people would be leverage some like some of the convenience methods that help you take the conical form of event and turn it into something that's for a transport or a protocol and not take the client wholesale so at the moment the cloud the cloud events sdk is structured so that those two things are decoupled but there's more choices that the client makes that aren't really in alignment with what cloud events says could there be more examples of that oh sorry scott did you hear john's question no i did not hear that one he's asking for more examples of that uh well so for example um one of the goals of the client side of the code was just like three lines of go code and you've got an up and running receiver if it takes in it's basically like a function framework and i've i've been waffling between like is that overstepping or not for the what the guise of cloud events is and i there's integrators like amazon that are interested in the sdk that are only interested in the parts that are the the encoders where you take a conical form and you turn it into the the version for a protocol and there's optimizations we can make that we never pop it out into the conical event sort of like how when you in go if you're interacting with a htdp you get uh the uh you get requests and responses and then it's your job to like decide if you want to take the the buffer from the incoming request and do something with it not really giving that choice in my client i see yeah so so if i'm understanding you correctly i have that same question about the those two rust sdk uh repos right one one talks about being a micro kernel and sort of it's got all these pieces and the other one's a lot simpler yeah so i think i think i think you're bringing up an issue that's kind of broader than just the go sdk if this is something you know from from sort of an engineering consumption perspective that that should be talked about kind of as a best practice or something like that yeah and we touched on this a little bit when we updated the doc about what the sdk's min requirements are but i i you know i i did more than what that doc even says inside the go lang sdk and so if other repos are looking at this and they're saying okay well i'm gonna i'm gonna do all the encoding bits but i'm also going to do some like opinionated client bits it it gets a little confusing for people yeah uh marx asking if there is multiple packages it already does that i but i'm like the simple rust case i think that there's a a market for like this core just convert things like give me a request and turn it into some sort of other thing that i can transfer around that's fairly fast versus fairly easy which is the goal of the client how often would the two repos be used together though so the client would depend directly on the core part right like the core part would be probably blocking and take opinions about how how like if everything is unidirectional the client might choose to allow responses for certain integrations of transports or protocols like hdp so i have in so in the csharp sdk so i have i have a second repo as well that sits on the side and they haven't published yet um because we obviously also need to have product specific integration and that have no place in the in the cncf repo so i'm trying to figure out what what a home for that is right that's that's my issue too and and it's it's even worse because now it's all in the cloud events library and it it's like technically donated to the cncf so i can't just like push that back into some other non cncf project or repo so so my so i have so what i've done what i have done from the start is i have this core thing which is um just the cloud event so i have i have this cloud event attributes class which is the the the thing you can't really see but that deals with all the version management and and all this what we need it's well we're still working on it and now we have a little bit of legacy if not much but that class deals with effectively the the data model handling and then there's the cloud event per se was the kind of wrapper around this and has the strongly typed 1.0 uh surface area and um and then i have and that's kind of mostly what you deal with in the sdk that's what for the product integrations that's the thing that i come for effectively um because they map since i don't have like pure in a pure inqp surface um i can't i need to go and map to the product sdks so literally just pull that i literally just pull that that package for the cloud events class and then do all my mappings to the transports uh then effectively separately into the product sdks and the the cloud event sdk per se has you know common mappings to um the most popular sdks in dotnetland so it knows how to map to the htp request in in dotnet and so the htp listeners and there's two versions of this and then otherwise i've taken some some popular sdks but these these product bindings the transport bindings is something that i'm going to add effectively in further external libraries which then use um and that's specific to c sharp use the extension mechanism where i can effectively just add a um i can add a two cloud event to you know the transport message class but i cannot have this i have this core that this core class which is really the cloud event sdk which i'm then re reusing in in in the in the further external libraries they do the transport bindings yeah and then i have for for i have i chose only to embed really like the the thing that everybody needs htp into that core library and then i have extra assemblies for mqt and for mqp and for kafka yeah i i i do a similar thing but the those extra integrations are in the repo and they're yeah in separate directories so that they only get linked if they are imported yeah and i have everything in the same repo as as long as it's product independent and then everything that is product dependent i still need to find a home for yeah interesting so but the question about the you know should there be this like client thing that kind of over steps with the cloud events spec says live in this repo or should it be a separate thing um so it depends for what right so it's it's arguably for the k-native is at this weird place right which is you can look at it from depending on where you sit that is something that belongs or doesn't belong into into a cncf repo right so that's that's something that theoretically because of the status of k-native should really live somewhere else and then that yields a native a a a bit of a split in here's a you here's a universally useful thing for how you express and handle the cloud event in in uh in go and then here's another set of classes that um then deal with that do an integration to k-native and those are then and we we have that right that's all over the place right there's nothing that's k-native specific in the go lang sdk the the only thing that is leaky is some of the runtime object model that k-native supports is is enabled by the cloud events sdk you can do other like way other a lot of other things too but you know this sdk is the thing that drives a lot of the eventing pieces inside of k-native yeah i don't want to police it i just i just want to kind of the philosophy of that since you were talking about the philosophy of all this i just want to share what i think about it yeah thanks um this kind of sounds like the takeaway might be what do i want doesn't sound like anyone's concerned about the client so maybe i just leave it yeah okay we um we had a meeting a slinky developer and i see here not here no we we are making plans to do the v2 migration which uh does some some more optimizations about uh there's a lot of use cases where if let's say you're a piece of middle where and you you want to route an event that you've delivered and maybe filtered from the import to the export the at the moment i i always go to the conical form and there's been work that allows buffering and like buffer copies between two encodings so like it can read straight from htp's buffer in and send it to the NATs out so you avoid the intermediate version of that object oh okay which gives like a 10x improvement a lot of the times if the message gets if there isn't any other thing to do with the message i would love to have that kind of time that yeah right well i'm not doing this work sort of but i would love to have those kinds of resources yeah yeah it's awesome anyway that's just a heads up we were the goal is to get the v2 out by kubcon and i i think we can get there it's going to be a lot of work well thank you scott any other topics for discussion okay case i anybody representing java citizen anybody representing java i don't think copy is in the call actually that's a really good question Doug have you worked on is there a table of the owners for all these stks that's funny you should ask um let me show you something i have this i haven't put it to so i have that um now uh what i've been doing recently was opening a pull request in each repo to identify the leader for that repo so someone knows who to go poke if they have any questions yep um i i was going to put this list into the main read me of the cod events repo at some point i just hope you don't have to go to each individual repo directly yeah sure um here's my email address man this is and we'll update it if it ever changes okay yeah the one thing i can't remember we didn't did we talk about the ruby sdk on the c8 call i don't think we did no we didn't yeah i i was going to propose oh no we did we did and mark suggested that rather than archiving it we just change the title to say no one's working on it if you're interested volunteer and i did that already oh yeah okay yeah okay so we did yeah so i think the only action i haven't left for me is to actually put this someplace global so okay um i think it's we probably should have a template of uh some kind of information of the owners in each like you've been adding yeah um i can work on or yeah i mean i could work on about that template would be and put it someplace global and then have each repo owner copy it into their in their reading basically right yeah yeah right like add that to the requirements of writing in sdk's you you have to have this file and it uh it tells people how to contact you the reason why i asked that question was that uh apparently as i just learned over i am from elsewhere um is that confluent is triggered enough by the existence of the java sdk uh and the kafka binding that they have looked take a look at taking a look at it and they're very unhappy with it and so um apparently they're going to bring a pr to bring the kafka part of the sdk in order that'd be cool yes i and you know if that's if that's what it is you know if we just put code there and the code kind of half works and then the vendors come and fix it that's uh you know that's not a bad start no that's good i have a to-do to support kafka as well so before i forget the clements um what title do you want again i can't remember what you said you what you called yourself it's like a master of hearsay i'm a principal architect if you don't want to have the chief messenger which one do you want officially on the website i think i've used chief messenger but to see as you have before okay i just gotta remember chief or chef one of the two okay i always misspell that okay actually i think i think last time i asked you this you said principal architect but that's okay you know peak either one okay okay and anything else you guys want to talk about that's all that's all cool in that case it's lunchtime for me i'm so excited it's uh it's uh it's not for me it's seven 20 maybe i'm gonna if i go upstairs i get something to eat we'll shall see all right all right okay have a good one talk to you later bye bye thanks cheers cheers