 Hello uncle you're there Hello, yes. Good morning. Hey, how's it going? Good. How are you? Good? Hey David morning and Clemens Before everybody jumps on the SDK meeting is right after this correct? Yes, but not this week We're back to every other week thing today after this call. We're gonna talk about Discovery interop and implementation stuff. Okay. All right. Yeah, but the SDK So every other week and then next week is the KubeCon Europe. Are we gonna have it because of that also? That is one of the questions I have on the agenda is do you want our calls next week? Yep This booth thing Even though it's pre-recorded Yeah, hey Tommy. We are recorded Clemens. Be careful what you say. Oh, yeah, sorry Yeah, I know, you know, there's no filter Hey Vlad Hey ginger Hi, Doug and Nick hi dark. Hello Well, you guys are all eager today Actually, I'm probably gonna get myself in trouble, but what the hell So, you know how Scott's continually nagging me about using the word guys, right? I Noticed and none of you you've noticed this but in the CNCS slack if someone used the term guys is a bot that will slap your wrist and It's a I just think it's kind of amusing. Yeah, someone actually went out of the way to create a bot for that thing It's a new thing because it wasn't there a couple weeks ago. It is new. Yes, I Just thought it was amusing and apparently as far as I could tell it actually paced a link to Different articles that talk about why it's it's bad to use the term, right? And I don't know how many different articles they point to but I've noticed at least two different ones that points to These kind of things amuse me Is you all okay? I Think it is what I Want to get in a really pissy mood later this week and sure will happen I'm what I was gonna do is put a comment in one of the slack channels over there saying you know guys and gals and see whether it complains Considering I'm the only girl I think that attends this call it doesn't offend me if you say guys so So actually I actually contemplated asking you to be perfectly honest But I given every all different comments you've made over the what the years we've been here I assumed you were not offended by that kind of stuff. No, and even on our team calls I'm the only girl in our company and our boss will say guys and then stops and says Oh, I mean and I'm like that's worse just guys and move on I Gotta be honest I actually thoroughly enjoy it when I'm at a comfort or something and there's some woman on stage talking And she used the term guys constantly left and right I decided to sort of smile Okay enough of the PC stuff, let's move on Urban flat just posted In the link y'all is fine. So So how about you use y'all see actually I would think y'all actually could be offensive to people because are you making fun of Southerners? Right, I mean, it's definitely a southern term. Yes, absolutely. So anyway We could go so many places for this conversation. So maybe we shouldn't um Craig. Are you there? I Hello, is this your first time on I can't remember if we've seen you or not I might have joined once a couple back, but um, it's been a while So looking to kind of join and see what's going on in the community Okay, I'll look later to see if I have your company affiliation. If not, you may want to add that in there Mark are you there you all are too funny. Thank you Christian Good thing this is recorded right Kristoff. Are you there? Yes, I'm here. Okay continue with the C's Colin. Hey, Doug. Hello Mr. Doug, are you there the other Doug? Yes, here. Hello. How many are you there? I Am here. Thanks. Oh, it's Lance. Are you there? Yes, I'm here. Excellent. Remy. Yep. All right Scott Oh Yeah, slinky are you there? Hello. Hello. Hello a tumor tumor Howdy. Hello. I get everybody Really? Oh Oh Eric. There we go. I don't know. Eric. Hello All right, it's three after let's get this thing started 21. All right Community time anything from the community if you want to bring up All right, a couple of housekeeping activities. So for those of you who have forgotten next week is coupon We are currently signed up for Three different activities at least from the cloud events side of things We have a booth at 330 European time and on Thursday at 115 European time Looking for volunteers To I know it's that's both those times are gonna be really challenging for West Coast people Let me just look at for Thursday, okay, but anybody else on the call willing to raise their hand at this point in time Virtual coupon and what would the volunteers have to do so I okay So ginger help me out here because I think you might not know more than me But I believe it's basically joining a zoom call Um Potentially having a presentation ready not necessarily to present the presentation but to talk to it if you would if that would help you in Your conversations with people who join the zoom call to ask questions about cloud events. Is that a fair summary ginger you think? Yes, and they can be Whatever you want them to be frankly, it's 45 minutes for a session and it's open for any of the coupon folks So it's just like having a maintainers booth, but it's virtual So if you want to present something or show a demo or something and then take questions or whatever, that's totally up to you guys Okay, I'm gonna I'm gonna take the Thursday 115 slot. Well, thank you Clemens If you have no one on Monday, I mean when being on West Coast I can do it Okay, thank you. Just let you guys know I was planning on joining both of those so I'll be there as well People just in case You do Monday, excellent How do we how do we Get access to those I don't know yet to be honest Hey, I actually asked this yesterday because I thought maybe I missed it and the information I got was they'll be sending out the zoom link In the coming days is the only thing they said now it starts Monday, so it better be soon Last night Say it again, Scott. I got my email last night. It's there's a bunch of links and there's a bunch of Rooms on the cloud native slack So so do I oh presumably you registered because I'm not Well, so you don't have to be you don't have to be registered to do the main thing or both So Scott, I'm missing that note, but is there I don't think there's a coupon that clown native I know there's a coupon serverless group. I Mean, that's right. Not coupon. Clown native coupon cloud events So I think I'm not sure that those Channels have a one-to-one relationship with like working groups and stuff I Could be wrong. That's true. I don't know I just saw it last night and there's a bunch of rooms a little too much to be honest Yeah, so Channels, they're not zoom rooms That is true. They are zoom rooms. That's like channels. Either way, we need more information for zoom So I will assume that somehow a link will show up in my inbox When we're another I'll make sure that happens. Yes, and I'll also paste it into the slack channel If I hear anything anytime soon Doug, I'll let you know. Thank you very much Okay, so the other thing is not that way next thing needs to do anything, but we do have the cloud events session itself I assume Clemens that time is good for you to answer questions with me, right? Absolutely. It is. Yep. Yes. Oh boy. You sound excited. Okay Okay, obviously anybody else is free to join if you want, but it's not required to like the booths You know I have to have other people there Clemens and I will definitely handle that one for sure I'm sorry. What it's a great talk. It is an excellent talk. Yes. We've been one of our better ones Okay, um any other questions or comments relative to the booth or the session before we move forward Okay, um Now the next question is do we want to have our calls next week? I may be wrong, but I'm pretty sure none of these sessions A kubecon that we're doing anything With overlap with our regularly scheduled calls So we can't technically have a call next week and in fact the and the stk call But if for some reason people feel like they don't want to because they're really busy with kubecon activities And other sessions they want to attend We can skip next week if people really want to Any opinions? Okay, not hearing anybody. I'm going to lean towards. Let's have the calls anyway. Yes Any ejection? Okay, we shall do so. Thank you everybody all right, um Just a reminder Before September 13th, we need to decide if we're going to have a maintainer session for cloud events or serverless If you're interested in speaking, please reach out to me Um, do not be shy and do not feel like you have to have a ton of experience or anything Or even that deep of a knowledge of this stuff. Just if you're willing to talk Okay, definitely looking for other people to speak up besides the regular folks because we want to make this Open to everybody and give everybody an opportunity to talk or present if they want to all right, um Okay, just a reminder. We will not have an stk call after this one this week However, we will have a discovery interop and implementation call right after this one whenever this one ends Okay Team or anything you want to mention relative to the workflow stuff or anything going on with kubecon Um Yeah, I mean if you guys find any information about the booth stuff, please include me in that as well because i'm kind of clueless Completely of what's happening with that But other than that. Yeah, just preparing for kubecon as far as specification goes We're looking at unstructured or ad hoc processes just to see if they make sense And also some sort of security with jason web tokens. So if anybody here has any You know experience with jwt I highly appreciate some input um And other than just trying to figure out when we can do a next release of the specification That's all right, unclean your hands up Yes, uh, he dog has i mentioned last time the schedule on the scenes they have a public event calendar Shows the the the service workflow is still bi-weekly at 5 p.m Which is wrong, I guess Yeah, thank you for mentioning that because I did mention a team where we weren't sure what was incorrect about that So team very you got that I looked into that. Thank you so much and thanks for yeah I looked in that it is bi-weekly We changed that recently from a monthly to a bi-weekly meeting. So I think that is correct Uh at the time, however, I'll check on it because when I look in the calendar looking at eastern time, it looks correct But if it's wrong Oh, it's it is bi-weekly No, yes, sir. Yes, sir. If we change that we used to be monthly And after the sandbox inclusion, we thought it would make more sense to And the new repo we had a lot of stuff going on and okay. Okay. I think I guess it's the service workflow.io the the schedule on that page is incorrect It shows it. Yeah, because those two are inconsistent Okay, definitely. I included the cncf public calendar. I had An old one. So maybe try to see if that update made it refresh the page but Yeah, instead of having some custom calendar We added the the cncf public one and if that is wrong I'll check that right away. So, okay. Thank you so much and I hope you can join. Yeah, thank you All right, anything else relative to the workflow stuff All right, moving forward. Okay before we jump into issues and prs Is there anything else that I should have added to the agenda, but I forgot to add All right had a nation So again, I apologize last week for not pushing this up before last week's phone call But I don't think I've made any changes since I did update it. Um I guess the one other thing I wanted to add was Uh, so I last week's call is I think was last week's call. We had a very very brief conversation about things like Whether we should use offset versus next versus index and that kind of things and I apologize. I completely forgot that the use of those query parameter names is actually implementation specific And this then this specification actually doesn't mandate what you use It's completely up to the server side of this side What query parameters or even entire shape of the url to use to represent the next chunk of data So we don't actually tell people what they do The only thing we do specify is the link and rel attributes and let's show an example of how they appear So They appear Like this, right? So we say you have to have a link and you have to use the link header And then you have to have the url followed by a rel And we do specify or point to a document that says Next and previous and what those things are defined as But in terms of the actual values in here, that's completely up to the implementation decided what to do Right so you can do whatever you want Okay, as I said aside from that, I don't think there have been any changes made since last week Are there any questions or comments on this? Okay, I'll ask the question then is there any objection to approving this as the first draft of this spec? All right. Thank you everybody and please Let me know if you have any open prs or issues of any problems As with anything All right slinky Would you like to update people on What changes you may have made on this one and just as a refresher for people Um, we are planning of doing the boat on this one today unless there are major objections or major issues People find but this has been out there for a while and we did talk about this on the sdk call last week And we did agree that we do want to have something at a global level across all sdks But then sdks themselves could have specific Tweaks to the process if they want in their own repo But we thought it'd be good to have a high level process across all of them that is a little bit consistent So slinky you want to bring us up to date on what you might have changed in here? Well, I think you already said I just On the initial draft I may I wrote some more stricter requirements but then after both the meeting Last week and the slack discussions. I end up making those requirements more soft But then I say that in theory sdks themselves the projects themselves can decide to To develop more stricter requirements to uh, it's not specified how the sdk should develop those stricter requirements Look, yeah, I think it's actually it's wrong. It's actually this whole section. I think this is the newer stuff Yeah, your stuff is the same. Yeah I gave everybody on the call just a 30 seconds or so just to look this over since that is a little bit new All right, any questions for slinky on this? I'm neither the section or the entire pr All right, any objection then to approving Excellent. Thank you everybody and thank you slinky for your patience on that Um Okay, I believe let's skip these two for a sec. Let's drop down to the third one the jason streaming proposal I believe on last week's call. We were asking people to go back to their respective organizations to see if there's any interest in this jason streaming thing Did anybody do that? And would anybody like to speak up in terms of what they may have discovered or found out The silence mean everybody shy or did everybody forget I'm trying to remember who spoke up. I'm trying to remember who spoke up last week to pick on them, but I can't remember It was me Doug. Yeah, it's good And you know my findings still stand the data Big data people are interested in this kind of use case for cloud events because they like the the fact that the payload is decorated But it needs to come in faster than What htdp Requests can do and batching isn't quite the right thing. So They would like some sort of streaming solution. That's cloud event based Okay Anybody else want to chime in? Okay, so I'm hearing at least one person say this is useful now Francesca, can you remind me on this one was the discussion about whether The existing specifications cover this or was the just do we need the the feature at all? I can't remember how that conversation went I don't remember it. I think there was some discussion around What should be the record separator? and I and I proposed the RSLF which is an RFC The um The reason no other topic which I didn't really explore that is that We might make this compatible one-to-one with service and events But service and events uses new line for echo card. So maybe this is worth investigating. I don't know you can Uh, I mean for for me, it's fine this one RSLF for me is fine. But if we want experiment to look for supporting one-to-one service and events from W3C then Okay, well, it seems to me that Most people probably have not given this a whole lot of thoughts So I'm a little bit nervous about trying to do some sort of deeper dive discussion right now And I'd rather save it for next week so people can go off and you know review this as a homework assignment Is that okay with you? for the next two weeks If so, I'm I'm still Okay, go ahead I still don't like any of these of these Okay And so I'm wondering so there are there are ways to do this with htp2 htp2 um If if you want to And that's like if you look at how aws kinesis Is doing its uh, it's delivery of multiple events and that's something to look at But that is an htp2 feature But then if you really want to have streaming of of jason then we can Then I think the cleaner way is to say we're going to do a web socket binding and Use web socket text frames if we really want to have a Streaming a streaming model. So either have either have a feature that's explicitly binds to htp2 And I just didn't have my glasses on. Oh, so scott said htp2 is funny. I know where that comes from Is it fine that funny? um, or We're gonna do a web socket binding or we're gonna do both because htp2 um, obviously is incompatible with web sockets But but instead of instead of doing hackery around the the htp delivery model I would basically just drop down to the respective Transports that are optimized for that particular use case because that's why arguably why web socket Text frames exist and that's also why this um This eventing feature in htp2 exists and and use those I I have a moderately popular app that that uses web sockets to stream cloud events out of kubernetes Yeah, and that seems to be a very natural Uh Match Yeah, I would love like an actual spec to follow right now. I'm just pushing A new line delimited json blobs And and there If you drop down one layer, they're like pretty much every web socket protocol allows you to go and send frames Like this distinct frames where what there are labeled text and then web sockets actually does all the limit Uh delimiting for you where you don't have to go do any parsing at all No, that's really cool. I yeah, I'd love to explore that Because I think that's the cleanest way to do this where you really want to have a torrent of of events and you want to um, like if you wanted to do a stock ticker with That's a popular example That's why I'm mentioning that so you you connect to a website and the website is a stock Has a stock ticker and now the stock ticker wants to go and give you a stream of events that you can then go Dispatch on your on your ui and um, you want that to be to be cloud events then, um Using web sockets is exactly the right tech to use And the text frames are exactly there so that you don't have to do the parsing So francesco Since you're the one that brought up this issue if we went and looked at either hv2 or web sockets As the preferred choice for this Would that be satisfactory to you or do you still want an htp one type of solution? I think so. I think it's it's fine for me trying to explore hv2 or web sockets my My concern is just that still not all the web is on hv2 but I mean But everybody supports web sockets by now Like the there's all the browsers do have it and well the browser has it. Um and Uh, most of the web framework support web sockets. So that's that's a pretty pervasive thing htp2. I agree is uh Something that is more like an internal pain for the for a lot of our architectures. So, right So so web web sockets web sockets is Would have been an issue. I would say until about three years ago But now it's so pervasive that everybody has mostly given up on all the alternatives like All the other tricks long pulling etc. And it's just basically going to web sockets and that works pretty well Okay Okay, I'll finally be exploring that. Okay. Um So in terms of next steps on this particular issue, it sounds like we may choose to close it Are you volunteering francesco to to open a pr for a web socket binding? Um, I think I should look at it together with scott because scott already has some Practical experience on that. So I like the idea of volunteering scott. Yeah No, no, I mean we can do it together. I know what you meant Okay, scott scott agreed with you. Uh, just look to the uh through the chat. So Yeah, I don't I don't have enough work to do. Let's let's go. Let's do I agree. Yes. Okay Uh It's like the pr. Okay. Now the other question is will this right up right here Satisfy the requirement for the multi content one Yeah, I think we can close it to be honest I I went through this again a couple of times and yeah, I think we can close it Okay, so to be clear We're actually going to close both of these issues and then wait for another pr to pop up, right? Yeah, okay. I just want to keep the initial Issue open, you know the one yeah Okay, is there any objection to heading that direction is to be clear? We're talking about closing these two prs and then Waiting for this brand new web socket pr or web socket binding pr to pop up I I think if this happens though, we're gonna want to talk about um Some sort of options protocol negotiation to understand if an endpoint can upgrade Well, the great thing is that Web sockets already has has that with you define the we will define here the cloud event sub protocol And the so protocol negotiation of what you want to pick up is already in in web sockets But how do you know to initiate the the protocol discovery in in web sockets? the The server so when you do the the initial so there's always an initial discovery request You effectively do a get on the on the server Um, and that will tell you what sub protocols it supports and then you're going to be offering the upgrade So there's a whole there's a whole handshake that everybody does So for instance, if you're using mqp or mqqt with web sockets You always start with with a regular htp request and then the server says hey I can also speak mqp and then you go on upgrade Yeah, do we have to define that or at least point to that semantics in claudevin spec? We basically have to define the sub protocol The cloud event sub protocol which we will then go and upgrade to But the sub protocol doesn't have to be so so some of those sub protocols are Layering a binary an extra binary layer on top of web sockets like mqp do and like mqqt do And our sub protocol here would basically just be Text frames, but it would be it would be announcing itself as such so that you know that you are now using your code path that understands the the cloud of the cloud event stuff um, I I can um We can we can work into this together if you want Yeah, come come join slinky and I I like that third volunteer I wonder if we can uh Maybe I'm is understood by that. I wonder if we can take existing web book spec and kind of do the protocol negotiation there Uh, that's I think that's different. That's different. Okay. Okay. Okay. Uh, I'm still trying to understand that Yeah, the web hook spec is really just for delivering events kind of in a push fashion to to um to a target and this is really here a A way to establish a web socket and have a particular A particular way of how the web socket is being used, which is we're putting we're putting Cloud events into into the text frames And that might actually be bi-directional Because there's no there's no reason not to constrain to to constrain that I'll I'll write an email we saw but we also do the slack thing Um I'm just trying to I'm just I'm having a schedule problems. Um I will try I will try to make a to to summarize this mechanism. Um until next week Okay Okay, great. Cool. So so we can basically just to educate and get as get us all on the same on the same level and then We can decide who Really picks up the pen. So I'm not going to write a draft spec with the must and the shoulds But I'm just going to try to summarize in like a page of of what the Of how that works with the sub protocol stuff Okay, I would love to try an implementation to Maybe on sdk. Yeah, because just to check out towards them So implementations are super easy because we all have existing web socket stacks That will relatively make it relatively simple to go and implement all this We and nobody has to go and drop down to the to the wire level anymore to go and realize any of those things Um, but to have a formal spec We we still need to go and define how that actually happens down at the wire So I just want to make sure that we have both those things even though we're we're all going to use Ultimately, we're going to use some existing pre-existing both clients for this And lance just paste it a link in there to to an rfc that might help in this So that's a that's a that's an action item for me for next week All right, cool All right Any other top any other discussion points about these two pr's are then yet to come pr okay Now scott has a Pasted into the chat issue or linked to an issue that I think it's kind of related to this But scott before we get to that just in case we end up rattling on that one I just want to quickly Cover something that I hinted out. I was going to do last night Which is scott opened up a syntactyl typotype issue to me And I wanted to see if we can just get that out of the way even though it's under the two-day Limit I figured it said since it's just typo we can do that You notice that we're missing the required protocol field in the sample service output So I think that's a no-brainer right there And then the other commit Is just he did a ran he'd ran lint on it. So I'd assume there was no actual changes in there There was one other change one of the other jason samples had an extra comma that the linter removed. Oh good. Okay, cool. Thank you but Any objection then to approving this one and keep in mind if you had if you want more time even though It's just typo. Please speak up, but I figured if it since it is just typo Maybe I'll get out of the way any object any Any concerns with approving this one now? okay In that case we can get that out of the way All right scott you wanted to talk about this one because I do think it's related to what we're just talking about, right? Yeah, I just there's a hole in the spec around the callback and the secret. I think it this has been months, but I don't I don't understand how to do the out-of-band get But also deliver Whatever secret there was supposed to be Clemens you have any thoughts on this one? uh Oh, yes, oh, oh, so so this uh, so the get with the browser client you mean Yeah, there's a provision that you can authorize the call But but it doesn't tell you how to also send the the rate limits and the other option headers in that out-of-band call so there is a there is a For if you if you simply have if you're simply building a website and this is not too Uncommon, so you're building a website with the simplest possible mechanisms It is possible to go and grab effect of the url from the log and then simply do a Confirmation request against that endpoint with a browser To sidestep having to go and and do a complete implementation of that handshake Yeah, yeah, I understand that part, but it it doesn't it doesn't look like there's a method to actually give the The correct rate limits in that out-of-band case. Oh um Ah, no, I get it But but but I have to go and take a look at that I have to think about this. Can you sign it to me? I bumped it I bumped it into I bumped into this when I was implementing the webhook support in cloud events as decay go So I opened this when I was doing that. Yeah, can you sign it? Assign it to me. I'll take a look at that and I have to think about this You say a sign it to you There's a sign. Well, you want me to go back for it next to be official with it. Oh, I see We have such a crazy torrent of notifications and github that It's like the pings and I can't see any of those things really interesting Because it's just too much. I've enrolled in I don't know how many reposts that I have nothing to do with but But you will get notifications about assignees differently Well, there is a I think there's a different panel where I had bugs that I own our city and so I hope that will help it I'll I'll take care of this. I have to drop out now. I have to drop no because we have an internal media. I have to get to Okay, sorry. Okay. Bye Clemens. Thank you All right, um Okay, so we resolved that one that one. Okay. So scott Actually, let me ask a question Scott opened up these issues. I think it was just as soon as yesterday. Um, and obviously there are issues in that pr So there's nothing to necessarily vote on or anything Um, but were there other topics people wanted to bring up before we get into these I'm gonna do it in the discovery call or here Well, I kind of want to do it here because I think the discovery call is more about implementation details And I pulled out these two specifically because I thought these were more spec related questions and worthy of a broader discussion Or at least to start the discussion going if that's okay Got it. Yep. I'm ready Okay, let's talk about this one first. I thought this was the bigger one Sure, um, I I am um In in implementing this in looking at what the api does. I think that the types endpoint is sort of out of place It's because it's a I like I say it's a projection of the data in the services web book It strikes me as slightly unrestful because there's two ways to get the the data through two collections and when you do Do the aggregation around types for the query you group services that have similar types, but Possibly, uh, they're completely unrelated like if if if two producers make a create event One is a pr and one is a database record And like it doesn't make a ton of sense to group those things next to each other So my proposal is to drop the whole endpoint entirely and Just maybe add some more filtering capabilities on service endpoint So for people who don't haven't looked at it recently. This is what scott is talking about dropping, right? Yeah, that's right. The oddity is this the type Map and the fact that it has the full service inside there is very strange to me it looks like a specific use case convenience method versus something that's Required for the implementation and I think There's nothing that stops anyone from Implementing their own version of this, but I I don't feel like it belongs in the specification All right, I am but having Christophe you're often you did you have a question or comment? Oh, sorry, no Okay, uh, remit your hands up Yeah, he's I think but maybe we'll discuss even more after but uh, what Scott said I think is I do understand his point of view, but in that case even the pagination should be out of that spec because that's also kind of Selecting some implementation on the side It's hard to set the where is the limit between the norm And the implementation by itself Or maybe I don't know if I'm clear on that I'm not Scott, did you want to comment on that or? Yeah, it's it's an interesting point or like I do kind of feel weird about defining this on api in the specification Where we might get away with Put possibly just defining the payload shape So that we can serve this data through other means to not just uh, restful apis Kubernetes, right? So I have a couple issues with the discovery api to be honest Well, there's nothing stopping us from Separating these specs out, right? Having a have an htp rest Binding for the core spec is I think I think we just it's just once at least in my mind It's just one document now for convenience But may split later was the way I interpret it. I think I think the overall question you raised Scott though It's something we've needed to discuss is do we want to have more than one way to get back the list of services, right? Because we have the We have the slash services endpoint And we have the slash types And they return very similar data other than the type one is now grouped by type And I believe we had this conversation in the past where people thought that it was more Friendly maybe the right word. I'm not sure I'm sure to have a Have a types thing as the searching mechanism for types So this felt oops that I think people thought this was more natural than Using this type of thing where instead of name you say type equals something I seem to recall that conversation Does anybody remember if I remember incorrectly because I thought that I thought we talked about this briefly before Like I said, I think that's true for certain implementations and views of this data, but it Because the two Return exactly the same data. It it seems very strange To do this grouping and actually spec it out Anybody have any opinion whether it's strange or not Anybody disagree with scott's assertion that we should just get rid of this entire section And I assume scott if we got rid of this section, we'd need to add another Query kind of a thing here. It allows you to search based on type Yeah, I think that's right We would get services listed and Have an additional filter of Of some sort of type and we can determine some sort of fuzzy matching right Okay, anybody want to speak up in favor or against that path Because I wouldn't want to ask scott to write a proposal or a pr if it's going to get rejected because Too many people don't like it I'm the surface of it anyway But so keep in mind like what I'm proposing is The the actual producers when they're Hosting their discovery api They just have to implement services And services id It doesn't stop anything from Implementing their own projection view in an aggregator But that could be a separate component that consumes the The services api Right, but if they do that it's an extension. It's not a Core part of the spec. So there's zero interability guarantees That's that's right. They they have their own custom semantics, right? Anybody have any opinion? Oh, come on. Tell me so I don't want to So do you hear me? Yes, I do. Go ahead. Okay. So don't want to throw the conversation off track But have we ever considered Uh discovering based on any arbitrary uh attributes Because I see, you know services and types Being the top level, you know discovery path but How about for example based on subject or Center like that? Yeah, that's that's exactly where my mind went. I think defining this types and the pivot table around type value to service map mappings is cute for one case, but I assume that someone's gonna want You know based on schema or based on The service URL or whatever, right? So I don't think we could possibly identify all the ways that you would like to pivot this data So my I was like, well, maybe we shouldn't try. Yeah All right, to be honest with you Scott, I completely agree with this I access it just a while ago and it got shut down. So Okay, so Scott, are you the one Focusing on this one right now If you want I can spend some time with you working on that's certainly something I'm interested in Working on I'm sure yeah, I've been I've been trying to do the reference implementation which we can talk about in the next meeting Okay, sounds good. Thank you Okay, so based on what I'm hearing in the group or not hearing from the group It sounds like people are generally okay with heading this direction and see what the PR looks like And potentially removing this this type stuff What types API I should say For me if I'm vocal is just that I'm Still trying to figure out where it goes. We're all discovering Stuff so I don't have a stronger opinion in either direction Okay, well you have time to think about it. We all do. Um, PR is not there yet. So we'll see Okay, um in that case the other issue I thought was worthy of a discussion Even though it doesn't seem like it'd be a very big issue. It actually Kind of is to me Scott you want to Talk about this one Yeah, sure. So the at the moment we have services Types, which is an array of of these type objects and internally The type object claims its name by calling itself type which in Most modern apis when you get down to the the actual object that talks about itself it it says like hey, I'm My name is this not my type is this so I think that type that is highlighted there should actually be called the name So its name and description And that refers to the type object of the cloud event type And I doubted comment in the issue. I think I think the reason we went this direction was because Um, this is the way that would appear inside the cloud event attributes The same way all these would appear. I believe this way at least the ones that do line up with cloud events Data schema and so like that interesting enough. I guess yeah, these these two anyway, right? um to the question there and to me is Abstractly, I think I agree with you scott name makes a lot of sense It's just from the consistency perspective would people prefer to see type here and then type is what appears inside the cloud event That's the only thing that would that was right through my mind, but I'd like to hear what other people think I'm gonna pick on people Eric I'm gonna pick on you You have a comment on this one or thought on this one. Uh, not a good one. I Thought that uh, the consistency argument held a little weight. I liked it. Um, my kid also was Down all night and screaming to that's to come so I'm not totally here That's a good excuse. I like that. Okay. Um anybody else want to chime in Lance hasn't has an sdk get person you may uh Have some thoughts on this one. I'm not sure I have any thoughts that I'm willing to share at the moment Okay Okay, well I picked on two people. That's that's my quota for the day um Anyway, think about it. Obviously, it's not a huge pr um But it is I I do think it's kind of an important one Because it it does kind of impact the the ux side of things slightly potentially good potentially bad depending on your point of view It I mean the the name of the cloud event attribute That's interesting. I hadn't thought about that, but it also doesn't apply to most of these attributes like description Schema type schema content and extensions don't apply and description So what we're really talking about is type data content type and data schema match up But the rest of them are oddballs. So Yeah, totally true. And then up above service has a name Should that be service? That's a good question Does this does this appear in the cloud event? No, I don't think it does is it no Yeah, and do we want do we want to have a unique name for types and keep type so you can Type could be create but this the name of it could be database injection row create event See that again one more time you lost me. I don't know why you lost me, but you did Well, so let your actual implementation could keep type very small It could have description, which is very long, but maybe there's this like medium thing of A little bit more context around what What this thing is creating so it can be like a database row create for the name, but the type is just create Where would you see that field showing up or is it strictly just for informational purposes when they're looking at the discovery stuff? It's just for discovery. It it serves a similar purpose than to name I don't know. I'm just a spitballing Something to think about. I know Okay. Well, anyway, everybody, please please think about this one. Um I do think we should probably have a discussion next week I don't know. Scott, if you want to wait or create a PR or not, but Either way people please think about it Any other comments on this one before we move forward? Okay, um, I think that's it for the normal agenda Um before we jump over to the discovery interrupt or implementation call Are there any other topics people would like to bring up? Okay, and let's just do the last attendee list thing and then we'll let everybody go. Um, normo, are you still there? I don't I don't see them unfortunately, but uh, josh, you there josh Yeah, I'm here, but I you know um Honestly, there's just been there's been a lot of developments in the service Serverless world this week and I was just dialing in to see whether or not Y'all were talking about them. That's fine. We like we like lurkers That's okay. Yeah, I don't have I don't have opinions on these changes. No, no, I wasn't asking about that I just want to get you on the attendee list and you just had to say yes. I'm here. That's it. Yes. I'm here. Okay, cool Manuel Yes, I'm here. All right, and grants you're there, right? Yeah, actually I got to use it All right, normo. I don't see him anybody else. I missed for the attendee list All right in that case everybody else is free to go anybody sticking on we'll start the Discovery implementation call in about a minute or so. Thank you everybody. Just a couple more seconds Let's go ahead and get started. Um So Trying to think about what I want to talk about scott. Let me pick on you Since you're the latest entry into the implementation side of things Is there anything from your perspective that you'd like to bring up aside from the issues that you opened? Or I guess if you want to talk about any of those issues we can talk about those too No, I think I my main focus is around simplification of the The service that is trying to host this data right Was there anything in the spec that you've come across so far that just I know you know, there's lots of things in there or a couple things in there anyway They all don't they seem relatively minor so far, right? Did I didn't you didn't raise some huge objection to the spec in general? Is that a good sign? Or do you think you just haven't gone far enough along yet to know whether this is a piece of crap and we need to revisit You know the core design. No, I don't think there's anything Majorly wrong with it. The one big question I do have is around The actual risk interface and I like the fact that we're trying to define the payload means I I want to make sure that there's a room enough to implement this thing as a Like a crd-based Kubernetes thing Right okay Okay, um I'd like to talk more about that at some point, but let's get to the other stuff first So in terms of moving forward here Do has anybody have given any thought to um How we might do some sort of interrupt testing or something along those lines Well, we could we could implement the aggregation part and then chain a couple of these things together Interesting How do you see that playing out from a client perspective? Is it is it then each each person would like maybe write their own client and talk to The different options in terms of endpoints like they talk to the base one and then talk to the aggregate one and make sure They get the same information type stuff Had you given each link in the chain is a client to the next the the previous thing Oh, that's interesting. I think of it everyone's Front end as someone else's back end as the phrase goes Trying to figure out if you make it completely circular It would be fine it would I'm wondering if you get into like a you'd have to it would be kind of interesting if you actually did that right Where maybe each one only added like a couple of things to the picture And after a while would they all end up having the exact same set of data because they all sort of synchronized with each other Yeah, I think the chain would all Harmonize. Yeah, I mean that would actually be kind of a cool little exercise And then have a client to hit every single guy, you know, or every single Client in the ring and make sure they all return the same data, but everybody starts out with different data. That'd be kind of cool The code that I wrote is is a very super basic Implementation just reading the spec and writing some go code. It's not a ton of lines of code And not totally not intended to be like a library that you host some stuff Out I was just reading the spec trying to make sure it makes sense to me Right, there's it's not dynamic data and it doesn't do Fetching and look up, but it could Well, I I don't know whether it's goofy or not, but I actually really like this idea of this circular thing and seeing whether They all sort of get interventional a consistency state across all of them Right because that would test things like the id stuff and then If we introduced the notion of well, one of them is going to update their list Um, and if you get everybody say 30 seconds or so, you know, does that does that change get propagated every Accordingly and then you know delete something Does everybody pick that up properly? Was it a pr or an issue around um some some discovery changes for watch? I don't think we actually have anything. I think you may have mentioned a watch type of api, but I don't think I've actually seen an issue or pr Yeah, I think there is. I'm going to check Okay But I think I think that's actually a really cool idea Well, I'm kind of full of cool ideas. You are it's awesome Anybody else want to chime in And grant just to pick on you for a sec. Um, in case you joined hoping to do the stk call We're not having one this week. It would be it's coming next week In case you joined for that Okay, um, not that you have to leave you're you're welcome to stay just I just realized that you may be here for that call Now the discovery is interesting. Okay, cool Okay, well Scott's looking for that Did you find it what clemens uh proposed is that the services emit cloud events based on changes which Could could work. That's a push model. I was looking for more of like an active watch model, but It's interesting That would that would definitely do what we're trying to do Yeah, well this I think what's neat is this circular thing Could help reinforce the notion of whether we need one or the other or or both type of thing Because as part of the scenario if we describe if we define it as One of the One of the guys in the chain updates something. How does everybody else find out about it, right? We need to answer that question and this would be a good way to force it Or force that discussion. I like it Now Scott since you volunteered for some stuff earlier today Unless someone else wants to chime in here. I wouldn't mind taking a first step writing up A very rough outline of what this scenario doc would look like Sure. Okay. Anybody else want to Volunteer I don't mind handing it off to somebody else, but I also don't mind doing it myself I actually have a random question Doug. Um, is there um previous details on the discovery spec? Say that one more time. So so this segment that we're actually talking about is I'm looking at the Uh, the repo right now. Um, there was a lot of content. I was wondering if there was a previous discussion that actually happened last week that I missed A discussion around I found here we are. Yeah, there's there's a whole spec You know, I'm actually in the wrong location. Never mind. I was looking at a different segment of this. Cool. Thank you Okay I haven't I'm the pagination PR either Because that was just accepted today. Yeah, I haven't done that but I think that'd be a good thing to test too Actually make pain make a note of that So test things like update Deletes Pagination And conflicts Uh, I elaborate a little bit about conflicts Well, so, uh, let's say that you have that change situation and uh, The source of truth updates their um, their event, but then they're informed by the the their other ring member that uh, The source of truth that they think is true is now coming in as stale data. So like Maybe we need like a resource version on those things like Or a version number to understand what like which one should win if it if there is a conflict In the service that you can define And one is stale data and one is uh more fresh I'm trying to understand how that would happen. So in your mind Do you see one, uh node in this chain having Multiple inputs or just a single input. So it's just a single link list or circular link list I will in the simple case that there's just a circle and there's three entities, right? if So a b and c if a is a source of truth for the a event and it But it's also watching for changes on c a changes the a event And c provides the previous version of a's a event to a Now a's job is to go in and merge that data into its data set. So how does it How Yeah, it's gonna be interesting And then, you know, I don't know maybe there's If you have more of a tree architecture where a informs b informed c and a also informs c and b is out of date with a's events c should probably listen to a as the source of truth not b Yeah, that's this almost sounds like it's getting to the whole category of I don't say a new spec, but it definitely is a section in our spec that talks about how to do this aggregation Right. Yeah. Well, it could be as simple as a resource version or a version number, right like Or an updated event, uh, maybe the the last update time or something like that, right? Like I think version numbers are usually simpler because it's easier to implement than time comparison Yeah Your resource version thingy Okay, something to add to the mix. Yep. Okay, cool Okay I like this a lot. I like this actually sounds like a really cool scenario. Um Okay, anything else People want to bring up either about the interrupt scenario or about next steps that we should take relative to our Our respective implementations How many implementations are we working with here? I know of at least three yours mine and remies Oh, cool. Yep I'm kind of stalled because um, I really see two different kind of implementation and like, um Probably work less with cloud events than you guys Because I want to use it, but it's clearly not Close to production in our company um But when I when I did the discovery my thinking was like if I created like a microservices I want to be able to host a small discovery service So basically then people can know what that microservice expose as cloud events and things like that I didn't took like the example of like the big one, which is basically the aggregator Where can be my enterprise discovery system that will aggregate all my microservices But in that example as a developer my thought was like when I develop my microservice I just want to expose that And whenever I redeploy when I do continuous deployment It's gonna evolve and add the new events automatically But when I do that my issue is like first It's gonna be hard to send cloud events because it's based on the deployment So it's it's not like I'm basically changing the service. So I don't really see how I will they meet the cloud event because then it will be relying on the ci parts that does the cd I guess or maybe I'm But like I have issues like philosophical issue, I suppose and Well, I'm not sure I understand completely What we try to achieve some kind of stuck there for now So in in my exact use case, um, I work on k-native eventing We have the concept of a broker which you could you could think of as a general purpose Like kafka or nats broker The it'd be interesting to be able to ask that that broker All of the microservices that are sending it events And so, you know, there's some magic Under the hood there to to make sure that the microservices all serve up a discovery endpoint But a consumer of events off the that broker Don't want to go and ask every microservice Yeah Yeah, and so in your scenario for now I did the discovery service like of the microservices But I didn't do the aggregator on the I didn't do the the aggregator on the On the broker part, which is most valuable for the client I do agree I don't think the aggregator is going to be a very common Implementation, I think it's only for these very special broker like things that would like to host a super set Like maybe they don't omit events themselves at all, but they do facilitate the aggregation of several microservices into a single consumer Yeah, and in my case is like So I would like to have the microservice that expose like a really basics Endpoint of discovery, which basically the less logic I have the better it is And then I was seeing Like maybe doing a small open source product that but maybe your broker make can make it and it's even better for me That will be like our enterprise Way of discovering it so then like it's our single point That's where you go and when you create new microservice a kind of register to that one I think we still need to figure out how your microservices tell upstream that they've they've updated their catalogs Yeah, you're right But like one of the things like by sending cloud events the issue is really like maybe I'm Not having the full picture, but if I change my pod and I create like basically I update my versions Then I have new events, but when I do that Like how the new pod know what was the previous pod it's kind of To to know what kind of cloud events you need to send to send That's where I'm still confused Um Maybe do not spend enough time implementing or playing with it or not To have a less confused idea Lance your hand is up. Did you want to chime in this conversation or was this something different? um Well a little of both um ready, um the The discovery spec that you've implemented. That's the pr in the javascript SDK Is that correct? Have you iterated on that at all? Is it or is that the The point of truth for that? I didn't iterate more while we were changing some spec like I wanted to To get better understanding I don't think it will take that much time because like the whole logic is already there So it's not like a crazy. I had to implement the uid stuff It was like so same thing the uid I talked with doger in the past like it was a bit Disturbing me because as it's kind of statically linked into your code uh generating the uuid was kind of In English in that situation. So what we agreed is like to create a uid based on the name Which is a specific case but um Because again, it makes sense when you have like a big discovery service as a standalone product, but if you embedded it into service Then you don't want to have states. You don't want to have all those and even pagination is kind of And I will say a bit annoying to do it's not impossible, but it's like Not the same I think But I'm happy to revisit if you need some updates No, I was just curious, but but I'm also and this is maybe just you know Unfamiliarity with it on my part, but What the question that kept coming to mind for me was well if these discovery services are admitting events Where where do they these events get emitted to and Scott you mentioned the Knative eventing broker That makes a lot of sense. But obviously that's not going to come along with just some implementation of the discovery spec so Is there like I guess I don't know to me There's kind of a gap like it's emitting events to what is that part of any Anything that needs to be specified You would probably have some sort of hook registration process in the microservice This is like hey, I would like to be informed of events. Please send events to me and likely that is going to be a fan out And that hook that registration service is and I'm sorry, I you know, haven't spent enough time with the spec to be to know Is that Part of the spec or is that Something that's just left open to the reader I assume it would have to be part of the spec similar to how the subscription api is In fact, like you could probably apply the subscription api to the the control plane events for the discovery api Sorry, I was distracted Are are we done with those with that conversation? Doug get in the game man Yeah, whenever I host this phone call It's like that's when people decide to start talking to me and it's like for this whole hour hour and a half Everyone it is it's like my backlog of slack messages just gets huge So I apologize Yeah, my questions were just sort of a little basic background information, I guess Okay Okay Actually, what's interesting is remi your your comment earlier about your preferred implementation choice of you know, just a single Discovery endpoint for one or more services that's back there not necessarily part of this whole aggregation thing I actually think that would actually be an interesting Twist to the scenario that I was going to write up because we could have Obviously a circular list of aggregators, but there also could be Branches, I guess my pretty the right word of just one offs who aren't necessarily participating in the aggregation But their inputs into the circular aggregation, right and see how that plays into it It shouldn't matter But it'd be interesting to make sure it doesn't impact anything. Yeah, the topology is usually called the ring and spoke There you go. Thank you Okay, anything else you guys want to bring up on this call it all I think I've really cool direction laid out And I like it and it's been a nice forcing function for testing some of these things I think lance has a good point around like how how does that If if the thing's gonna raise events like what does that really mean and One option could be that we we implement the HTTP watch api And it's like if if someone is interested in receiving the events they The the consumer of those events initiates the requests and it's basically a hanging get And when an event gets raised that gets distributed to all the clients that are connected So push versus pull Was there a question there or are you just explaining the difference between push versus pull No, I'm I'm I'm thinking about the implement Implications of adding these these events to The discovery api for changes. Okay. I think we need to solve both the like How do you know the consumers of the the changes to the discovery api and And then also this thing we've picked up around Some sort of like resource version or Version of the service that the discovery api holds Yeah, so Let me ask you a slightly different question. Although it's related your watch api Do you see that being A completely separate api. I mean, I know you're in your mind. You're thinking of the the kube watch thing So I know that's where your head is at but Would it make sense to set up that watching mechanism Via the subscription api spec that we have So you think of it more as a subscription as opposed to the watch and it just happens to be a pull style yeah, I I kind of implied that we could leverage the subscription api to do this because Right like the discovery api microservice becomes another subscription right Subscriber subscriber Yeah, because that's another cool aspect of this, right? You had we had we then get to bring in the sole subscription api spec into the mix, which would be nice Yeah, Remy is your hand up new or old? It was new. I was just thinking I don't know if it exists. Do do we already have like a Kubernetes system out where we could all push like the basic functional System like the discovery the subscription to understand the whole cinematics. Maybe I'm completely off as it exists I'm uh, I'm asking stupid stuff, but It's just for me the same. I really need to make it real and I didn't read enough of the subscription api It's also like a knowledge on my side But like I like to understand the full cinematic of a complete scenario where Like I have like either I'm a microservice developer and I push on your service inside that cube and basically magically appears in the discovery and starts ending and as an external developer The scenario where I'm just like using the discovery service find new stuff and just have to register to those new stuff and Make it all work. I suppose maybe it exists in your company and it's just me lagging but that's For me, I like to see things working completely in corner when I developed it the discovery service I was doing it abstractly like without really using it. So I don't know if such a cube that we could share all together what exists or not And I don't know of one anybody I'm called no one. I'm sorry. I don't I don't think anybody does But he was one no one what? I guess I like Go ahead. Remy. Sorry. Michael. Go ahead. Remy like Basically one place where maybe a cuban is because I think cuban it might be easier where we can all deploy our discovery service and like having a full Cloud events environment working meaning the subscription api the kind of the broker. So either the kafka or Whatever but like a full small working cloud events to be able to test and Play with it more Because for me, it's still abstract because we don't use it in our company. You might have this in your company, but I don't I mean, this should work kubernetes or not I think it's exactly that doesn't require kubernetes, but it's possible Yeah, it's just to all share basically to all be able to deploy small pods all together Like a different company, but just to see the interrupt where interrupt their ability That was my fault. So cuban it is just a technical Detail. Yeah, I mean, I'm going to the k-native horn. It's basically what we're doing So you stand up k-native eventing and you see cloud events We get land um, yeah, I mean, I I was just going to say that basic basically that um, it it might be useful to have some instructions in order to set all this stuff up using I think um Carlos Santana has a a kind cluster set of instructions that gets k-native serving running Can adding eventing to that is just a few crds um, and then it I don't know. I mean it might be useful to have some images and a couple of YAML files so that we you know, once this these things come, you know Into a little bit more concrete form So that we could easily just stand something up locally and play with it on a kind cluster or something like that Just a thought I think it's a good idea. I just feel a little premature since we don't really have running code yet. Yeah. Yeah Yeah, but that that will allow us to basically then for the interoperability test we can just all push our stuff in it and Make it work. Yeah, I can I can probably spend sometimes looking at it like I was looking at k-barling some some stuff But then and and then you just open it to all the members from this group So they can push to the same cluster and we can play Like a playground Okay, okay. All right anything else anybody want to bring up? um, this is the Excuse me. This is the first time I've attended this particular call um, and I only did it because you said it was happening at the end of the the The meeting before and I didn't know about it. Um Is how often does it happen? Is it doesn't appear to be on the calendar, but this is the very first call Okay. Well, that's why I haven't attended before That's right. And we we just decided to do it last week. Um on the on the claudivans call. So You didn't miss anything paying more attention last week. There you go Yeah, um, actually that's something we didn't talk about Should we assume that we're going to do this on a regular basis like maybe do it every other week? And you know one week stk other week discovery or interrupt testing Or is every other week too far apart? I suspect if we did it every week We may not get as much changes done on a weekly basis to warrant a call, but like the every other week interrupt Interrupt call. That's interesting that Should we put on that my little plus one? Okay. That's one I like that idea. Okay alternate I mean, I I see this as one big deficit of the the claudivans spec community is that there isn't a ton of Interrupt development that's happening You know comparing this uh participant list to the claudivans call participant list Like there's a lot of opinions on the spec, but not a lot of fingers typing the implementations Yeah That is a good point. I I know that there are lots of implementations out Oh, I don't know lots, but I know there are there are implementations out there because when I've gone to talk to customers about other subjects and Claude events just happens to come up Um, I hear about them implementing stuff, you know, and they're excited by it. So they are doing stuff with it um I just get the feeling that it's more just proprietary homegrown stuff and and you know, They just do whatever they need to do to get their job done And they're not really interested in interrupt beyond what the spec says Yeah dapper rolled their own implementation Of claudivans of claudivans. Yeah, cool Yeah, I mean you think about it. It's not exactly a whole lot of code, right? So I'm not that surprised There's a lot of cornered cases that they probably don't have Correct All right Anything else maybe I want to bring up All right in that case. I believe we are done Do we have a place that points to the the code like is everyone's implementations open source? Mine is not yet. I will open source it at some point when it's not embarrassing, but I not yet What what language are you using I'm using go dog? Why not? It's the language of choice for me these days Yeah Remi yours is what javascript Uh type script. Yeah It's uh, I just posted a link to the pr. It's in the SDK repo um, which opens another question about whether that's the right place for it to be but for me, it's really if it's like the micro service discovery part Inside the SDK was not for me the wrong place if it's the full aggregator service with like way more feature then it should definitely be another repo So I was thinking almost that of doing it twice one smaller like That you can just pack with your service And like a bigger one that is almost a standalone product, but Maybe I'm wrong. I I'm still open again like I don't claim to understand the full scope of what I'm doing Which is a bit uncomfortable Yeah, maybe I always move stuff later. That's nothing said in stone, right? We can always create, you know, brand new SDK or implementation type of rebos as necessary Yeah, I guess, um If that brings up a good question, so is like There's a discovery part is that Is that part of the SDK? spec I don't think it's part of any sd. Cool. Do we even have an sdk spec? I don't think we do doing We have the sdk markdown Doc in this. Oh, no No, no, not not as of right now Okay Did there isn't any Real project yet? So yes, like If this if the discovery part would bring any dependencies Into the sdk That probably wouldn't be ideal For for people that don't use discovery Yeah, I do agree Grant. That's why I really Like strip it to no dependency at all even the express implementation is done without express dependency I can There's two perspectives there. There's the the hosting part and most of consuming the api part Yeah, you're right. I didn't do the consuming api part yet, but that one should probably be in the sdk Then no Okay, anything else? All right in that case. I believe we are done Thank you everybody for joining. I'll talk again next week. All right. Bye everybody. Bye. Bye. Bye. Bye Thanks. Bye. Bye