Add a meeting Rate this page

A

Hello.

B

Uncle here there.

C

Hello, yes, good morning,.

B

Hey how's it going.

C

Good, how are you good.

B

Hi david, hey david morning and clemens.

A

Hello doug before everybody jumps on the sdk meeting is right. After this correct.

B

uh Yes, but not this week, we're back to every other week thing today after this call we're going to talk about uh discovery, interop implementation, stuff.

A

Okay, all right yeah, but the sdk um so every other week and then next week is the kubecon europe. Are we going to have it because of that? Also.

B

um That is one of the questions I have on the agenda is: do we want our cost? Next week, cool yep.

D

This booth thing.

A

You know it's pre-recorded.

B

Yeah, hey tommy.

B

Yeah, it's we are recorded, clemens, be careful what you say.

D

Oh yeah yeah, sorry.

D

It's in my head ever.

B

Yeah, I know you know: there's no filter, uh hey vlad, hey doug, hey, hey, jinger,.

E

Hi jag.

B

And nick hi doc, hello- well, you guys are all eager.

F

Today,.

B

Actually, uh I'm probably gonna get myself in trouble, but what the hell, um so you know how scott's continually nagging me about using the word guys right, um I I noticed- and I don't know if you've noticed this, but in the c and cs slack. If someone uses the term guys as a bot that will slap your wrist and it's, uh I just think it's kind of amusing and someone actually went out the way to create a bot. For that thing.

G

It's a new thing because it wasn't there a couple weeks ago. It is new. Yes,.

B

I just thought it was amusing and, as far as I could tell it, actually pastes a link to different articles that talk about why it's bad to use the term right, and I don't know how many different articles they point to I've noticed at least two different ones. It points to. I just just these kind of things amuse me is.

D

Is y'all? Okay,.

B

I think it is what I I I when, when I get in a really pissy mood later this week, I'm sure it'll happen. 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 what their complaints.

H

Considering I'm the only girl, I think that attends this call, it doesn't offend me if you say guys so.

B

So actually I I actually contemplated asking you to be perfectly honest, but I given every all the different comments you've made over what the years we've been here, I assumed you were not offended by that kind of stuff, so.

H

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. You know you know.

B

I got to be honest. I actually thoroughly enjoy it when I'm at a conference or something and there's some woman on stage talking and she uses the term guys constantly left and right. It decides sort of smile.

B

Okay, enough of the pc stuff, let's move on.

D

um In the link, y'all is fine, so how about you use y'all.

B

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, uh we could go so many places with this conversation. So maybe we shouldn't um craig. Are you there.

B

Hello is this your first time on? I can't remember if we've seen your ad, 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 and see, if I have your company affiliation, if not, you may want to add that in there um mark are you there?

B

You all are too funny. Thank you. uh Christian.

I

Yep, I'm here hello,.

B

Yeah good thing: this is recorded right. Kristoff. Are you there? Yes, I'm here. Okay, continue with the seas. Colin, hey doug, hello, uh mr doug. Are you there, the other doug? Yes, here, hello? uh How many are you there?

B

I am here, excellent lance. Are you there?

B

Yes, I'm here excellent remy, yep, all right, scott yeah slinky! Are you there, hello, hello team, tumor, howdy, hello? I get everybody really hello! Oh eric there we go eric hello.

B

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.

B

All right couple of housekeeping activities, so for those of you who have forgotten next week is kubecon. We are currently signed up for three different activities, at least from the cloud event side of things. um We have a booth at 3, 30 um european time and on thursday, at 1 15 european time.

B

um Looking for volunteers to I know, that's both those times are going to be really challenging for west coast people. Let me just in. Let me just look at.

J

For thursday, okay.

B

But anybody else on the call willing to raise their hand at this point in time.

B

Virtual cubecon, and what would the volunteers have to do so? I okay, so jinger 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 joined the zoom, call to ask questions about cloud events. Is that a fair summary jinger? You think.

H

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 kubecon folks. So it's just like having a maintainer's 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.

D

ah Okay, I'm gonna, I'm gonna, take the uh uh thursday um 115 slot cool. Thank you. Clemens.

G

If you have no one on monday and on being on west coast, I can do it. Okay,.

B

Thank you just let you guys know I was planning on joining both of those so I'll, be there as well.

K

People just in case.

B

I say it again: you do monday excellent.

J

um How do we, how do we uh um get access to those? I don't know yet to be honest,.

H

I I actually asked this yesterday because I thought maybe I missed it. um The information I got was they'll be sending out the zoom link in the coming days is the only thing they said. No, it starts monday, so it better be soon.

L

Last night say it again: sky. I got my email last night. It's there's a bunch of links and there's a bunch of uh rooms on the cloud native slack.

D

Oh so so do I oh so, presumably you registered because I'm not.

M

Well so.

H

You don't have to be, you, don't have to be registered to do the maintainer booths.

B

So scott, I remember seeing that note, but is there I don't think, there's a coupon tag. Cloud native, I know, there's a coupon serverless group.

B

I mean that's right, not coupon cod native coupon uh cloud events, so I think I'm 900 sure those channels have a one-to-one relationship with like working groups and stuff.

L

I could be wrong, that's that's true. I I don't know, I just saw it last night and there's a bunch of rooms a little too much to be honest,.

F

Yeah.

L

So.

B

Black channels, they're, not zoom rooms- that is true. There are zoom rooms, not slack channels, so either way we need more information for zoom.

D

um So I will assume that somehow a link will show up in my inbox.

B

When we were another I'll make sure that happens, yes and also paste it into the slack channel.

H

If I hear anything anytime soon, doug I'll, let you know.

B

Thank you very much, okay, so the other thing is not anybody needs to do anything, but we do have the cloud event session itself. um 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. uh Obviously anybody else is free to join if you want, um but it's not required, like the booths.

B

You know I have to have other people there clemens, and I will definitely hang on that one for sure, since we are I'm sorry what it's a great talk too, 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.

B

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 at kubecon that we're doing anything with overlap with our regularly scheduled calls so like we can technically have a call next week and in fact, and the sdk 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.

B

We can skip next week if people really want to any opinions.

B

Okay, I not hearing anybody I'm going to lean towards. Let's have the calls anyway. Yes, any objection.

B

Okay, we shall do so. Thank you, everybody all right, um just a reminder. um Before september 13th, we need to decide if we're going to have a maintainer session for cloud events or serverless.

B

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 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 the opportunity to talk or present if they want to all right, um give us a reminder. We will not have an sdk call after this one.

B

This week, however, we will have a discovery. Interop implementation call right after this one. Whenever this one ends okay, uh timor, anything you want to mention relative to the workflow stuff or anything going on with kubecon.

K

uh Well, 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, um 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 uh security with jason webb token.

K

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.

K

That's all right uncle your hands up.

C

uh Yes, he talked a lot, as I mentioned the last time. The schedule on the same set of public event calendar shows the the service workflow is still bi-weekly at 5 00 pm, which is wrong. I guess.

B

Yeah. Thank you for mentioning that, because I did mention a team. We weren't sure what was incorrect about that. So tim murray, you got that.

K

I looked into that. Thank you so much and thanks for yeah, I look and I looked in, that it is bi-weekly. uh We changed that recently from a monthly to a bi-weekly reading, so I think that is correct. uh 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.

C

It is bi-weekly.

K

No.

C

Yes, sir,.

K

Yes, sir, if we changed.

C

It we.

K

Used to be monthly and after.

C

The.

K

Sandbox inclusion, we thought it would make more sense to and the new repo we had a lot of stuff going on and we thought.

C

Okay, okay, I think I guess it's the service workflow dot, io. The the schedule on that page is incorrect. It's.

N

Just.

K

Yeah.

C

Because those two are inconsistent.

K

Okay, I'll 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.

F

You so much and.

K

Hope you can join yeah. Thank you all right. All right.

B

Anything else relative to the workflow stuff, all right, moving forward. Okay, before we jump into issues and pr's, is there anything else that I should have added to the agenda, but I forgot to add.

B

All right, pagination, so again, I apologize last week for not pushing us up before last week's phone call, um but I don't think I made any changes since I did update it. um I guess the only thing I wanted to add was uh so last week's I think was last week's call.

B

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 this specification actually doesn't mandate what you use it's completely up to the server side, to decide 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.

K

And rel.

B

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 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, decide what to do all right, so you can do whatever you want.

B

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.

B

Okay I'll ask the question, then: is there any objection to approving this as the first draft of this spec.

B

All right, thank you, everybody and please, let me know if you have any open, pr's or issues. I have any problems as with anything all right slinky. Would you like to update people on what changes you may have made on this one, just as a refresher for people?

B

um We are planning on doing a vote 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.

B

That is a little bit consistent.

B

So slinky you want to bring us up to date on what you might have changed in here.

N

Well, I think you already said everything I just uh that on the initial draft I may I brought some more stricter requirements, but then, after both the meeting uh 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 develop more stricter requirements. Atu it's not specified how the sdk should develop those structure, requirements right.

B

Yeah, I think it's actually it's wrong. It's actually this whole section. I think this is the newer stuff yep.

N

Yeah, your stuff is the same.

B

Yeah and give everybody on the call just uh 30 seconds or so just to look this over, since that is a little bit.

B

New right any questions for slinky on this on either the section or the entire pr.

B

All right any objection, then, to approving.

B

Excellent, thank you, everybody and thank you slinky for your patience on that. um Okay, I believe, let's skip these two for a second, let's jump down to the third one jason's 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 json streaming thing. Did anybody do that, and would anybody like to speak up in terms of what they may have discovered or found out.

A

Silence.

B

Does silence mean everybody's shy, or did everybody forget.

B

I'm trying to remember who spoke about I'm trying.

K

To remember.

B

Who spoke up last week to pick on them, but I can't remember it was me doug. Yes,.

L

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 uh what http 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.

B

Okay, anybody else want to chime in.

B

Okay, so I'm hearing at least one person say this is useful now um francesco. Can you remind me on this? One was the discussion about whether the existing specifications cover this or was it just do we need the feature at all? I can't remember how that conversation went.

N

um I don't remember it. I think there was some discussion around uh what should be the record separator and I and I proposed the rslf, which is an rfc. The.

N

There is another topic which I didn't really explored is that um we might make this compatible one-to-one uh with server sent events, but server sent events uses a new line for echo card, so maybe this is worth investigating. I don't know okay, I mean for me it's fine. This one rslf for me is fine, but if we want to experiment to look for uh supporting one-to-one uh server, sent events from w3c.

B

Then, okay! Well, it seems to me that most people probably have not given this a whole lot of thought. 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.

N

For the next two weeks, because next week I'll be to you.

J

So I'm I'm still: okay.

B

Go ahead guys.

D

I still don't like any of these of these okay.

D

And so I'm wondering so there are. There are ways to do this with http hp2. um uh If, if you want to- um and that's like, if you look at how aws kinesis uh is doing its uh its delivery of multiple events, then that's something to look at, but that is an http 2 feature. But then, if you really want to have streaming of of json, then we can.

D

Then I think the cleaner way is to say we're going to do a websocket, binding and use websocket text frames. If we really want to have a streaming streaming model so either have either have a feature that explicitly binds to hdb2, um and I just didn't have my glasses on. Oh so scott said, http 2 is funny. I know where that comes from.

B

Now he said fine, not funny.

D

um Or uh we're going to do a websocket or we're going to do both because http 2 obviously is incompatible with websockets, but but instead of instead of doing hackery around the the http delivery model, I would basically drip just drop down to the respective uh transports that are optimized for that particular use case. Because that's why? Arguably why websocket text frames exist and that's also why this um this eventing feature in http 2, exists and and use those.

L

I have a moderately popular app that that uses websockets to stream cloud events out of kubernetes yeah, and that seems to be a very natural uh um match yeah I I would love like an actual spec to follow right now, I'm just pushing uh new line, delimited, uh json, blobs and and.

D

They're, if you drop down one layer, they're like pretty much every websocket protocol allows you to go and send frames like this distinct frames with their label text and then websockets actually does all the the limit, the delimiting for you, where you don't have to go, do any parsing at all. Oh, that's! Really!

D

Cool 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 uh that's the popular example. That's why I'm mentioning that. So you you connect to a website, and the website is a stock.

D

uh It has a stock ticker and now the stock ticker wants to go and give you a stream of events that you can then go and dispatch on your on your ui and um you want that to be to be cloud events then using websockets is exactly the right tech to use and the text frames are exactly there so that you don't have to do the parsing.

B

So francesco since you're the one that brought up this issue if we went and looked at either http 2 or web sockets as the preferred choice for this, would that be satisfactory to you or do you still want an http1 type of solution.

N

I think so I think it's it's fine for me trying to explore hp, 211 sockets. My my concern is just that still not all the web is on hp2, but.

D

I mean, but everybody supports websockets by now, like the there's all the browsers to have it and well, the browser has it um and most of the web frameworks support websockets. So that's that's a pretty pervasive thing. Http 2, I agree, is uh um something that is more like.

N

Painful.

D

For a lot of architectures, so right so so websockets websockets 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 polling, etc, and it's just basically going to websockets and that works pretty well.

O

Okay,.

N

Okay,.

B

I'm finally 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 websocket, binding.

N

I think I should look at it together with scott, because scott already has some practical experience on that. So I.

B

Like the idea of volunteering, scott yeah.

N

No, no, I mean we can do it together. I know what.

B

You meant okay, scott scott agreed with you uh to the uh to the chat so yeah.

L

I don't have enough work to do. Let's, let's go, let's do it. I agree. Yes, okay,.

B

uh Pr, okay: now the other question is: will this write up right here satisfied the requirement for the multi-content one.

N

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.

B

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,.

N

I just want to keep the initial issue open, yeah.

B

Okay, is there any objection to heading that direction is to be clear, we're talking about closing these two pr's and then waiting for this brand new websocket pr or website a binding pr to pop up.

L

I I think, if this happens, though, we're going to want to talk about some sort of options, protocol negotiation to understand if an endpoint can upgrade.

D

Well, the great thing is that websockets already have has that with you define the we will define here, the cloud event sub protocol and uh the so protocol negotiation of what you want to pick up is already in in web sockets.

L

But how do you know to initiate the the protocol discovery in web sockets.

D

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 inquiry or mqpt with websockets, you always start with with a regular http request and then the server says hey. I can also speak npp and then you go and upgrade.

L

Yeah, do we have to define that or at least point to that semantics in cloud event, spec.

D

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 websockets like inkipido and like mqtt, 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 the cloud the cloud event stuff um I I can um we can.

D

We can work into this together. If you want.

L

Yeah come come, join slinky and I I.

B

Like that, a third volunteer.

N

I I wonder if we can uh maybe a misunderstood, but I wonder if we can take the existing web book. Spec and kinda do the protocol negotiations in there. uh That's, I think, that's different. That's different! Okay, okay, okay,.

D

I'm still trying to understand that yeah, the webhook spec is really just for delivering events kind of in the push fashion to to um to a target, and this is really here a a way to establish a websocket and have a particular a particular way of how the websocket is being used, which is we're putting we're putting um a cloud events into into the text frames.

D

And that might actually be bi-directional, uh because there's no there's no reason not to constrain to to constrain that um I'll I'll write. An email.

D

But we also do the slack thing.

D

I'm just trying to I'm just I'm having a schedule problems um I will try. I will try to make it to to summarize this mechanism um until next week.

O

Okay, okay,.

D

Okay, great cool, so so we can basically just to educate and get get us all on the same on the same level, and then um we can decide who uh really picks up the pen. So I'm not going to write a draft spec with the most of the shoulds, but I'm just going to try to summarize in, like a page of of what the uh of how that works with the sub protocol stuff.

N

Okay, I would love to try an implementation to um maybe.

D

Because the.

N

On.

D

Just actually turns out so implementations are super easy because we all have existing websocket stacks.

D

That will relatively make it relatively simple to go and implement all this where you 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, build clients for this.

B

And lance just pasted a link in there to an rfc that might open.

D

This, so that's a that's a that's an action item for me for next week.

B

All right cool all right, um any other top any other discussion points about these two pr's or how we're done yet to come pr.

B

Okay, now scott has a paste it into the chat issue or a link to an issue that I think is 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 at.

B

I was going to do last night, which is scott, opened up a syntactical, typo type issue to me, um 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 commits is just he did a random.

B

He ran length on it, so I assume there was no actual changes in there. There was one other change, one of the other json samples had an extra comma that.

L

The.

B

Linter.

L

Removed, oh good.

B

Okay, cool, thank you, but any objection then, to approving this one and keep in mind if you have. If you want more time, even though it's a typo, please speak up, but I figured if it is just typo, maybe I'll get out of the way any object. Any any concerns with approving this one. Now.

E

Okay,.

B

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.

L

Yeah, I just there's a hole in the spec around the callback and the secret. I think if this has been months, but uh I don't- I don't understand how to do the out-of-band get but also deliver whatever secret. There was supposed to.

B

Be clemens, you have any thoughts on this one.

D

Oh yes,.

L

Oh.

D

So so this uh so the get with the browser client, you mean yeah.

L

There's.

D

A provision.

L

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.

D

So there is a there's a um 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.

D

It is possible to go and grab affected the url from the log and then simply do a um a confirmation request against that endpoint, with the browser to sidestep having to go and and do a complete implementation of that handshake.

L

Yeah yeah, I understand that part, but it it doesn't, doesn't look like there's a method to actually give the the correct rate limits in that outer band case. Oh.

J

ah No, I get it.

D

I have to go and take a look at that.

L

I have to think about this. Can you send it to me? I bumped it. I bumped it into I bumped into this when I was implementing the web hook, support in cloud events sdk go so I opened this when I.

J

Was doing that yeah? Can you send it um assign that to me and I'll take a look at that and I have to think about this.

B

Let me say, assign it to you, um there's a sign. Well, you want me to go that far and actually be official with it.

D

Oh.

D

We have such a crazy torrent of notifications on github that um it's like the pings, and I can't see any of those things really interesting. Okay, because it's just too much I'm enrolled in. I don't know how many uh um reposts that I have nothing to do with, but.

B

You will get notifications about assignees differently.

D

Well, there is a, I think, there's a different panel where I have bugs that I own are sitting in 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 now because we have an internal media. I have to get to okay.

B

Okay, bye clemens. Thank you.

E

All right.

B

um Okay, so we resolved that one that one okay, so scott. um Actually let me ask a question. Scott opened up these issues. I think it was just as soon as yesterday um and obviously their issues are not 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.

L

How do I do it in the discovery caller here.

B

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.

B

Okay, let's talk about this one first, I thought this was the bigger one.

L

Sure 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.

L

It's because it's a I like, I say it's a projection of the data in the services web hook. It strikes me as slightly unrestful because there's two ways to get 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 two producers make a create event, one is a pr and one is a database record like it, doesn't make a ton of sense to group those things next to each other.

L

So my proposal is to drop the whole endpoint entirely and uh just maybe add some more filtering capabilities on service endpoint. So.

B

For people who don't, I haven't looked at it recently, this is what scott is talking about. Dropping right.

L

Yeah, that's right and the oddity is this: the type map and the fact that it has the full service inside there is very strange to me.

L

It looks like a specific use case, convenience method versus something that's required for the implementation and I think, uh 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.

B

Okay, all right anybody having uh kristoff you're off to you. Do you have a question or comment.

B

Oh sorry, no, no, okay, yep remy your hands up.

G

Yeah, yes, I think, but maybe we'll discuss even more after, but uh what um scott said I think he's. 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. But it's hard to set the. Where is the limit between the norm and the implementation by itself?.

G

Maybe I don't know if I'm clear on that.

B

I'm not scott, did you want to comment on that or.

L

Yeah, it's it's an interesting point right like I. I do kind of feel weird about defining this, an api in specification where we might get away with uh possibly just defining the payload shape so that we can serve this data through other means too, not just restful apis kubernetes right.

L

So I have a couple issues with the discovery api. To be honest,.

B

Well, there's nothing stopping us from separating these specs out right um having a http rest binding for the core spec, which I think I think would just it's just once, at least in my mind, it's just one document now for convenience. um It may split later. This was the way I interpret it. I think I think the overall question you raised scott. That was something we 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 to do.

B

We have the slash services endpoint and we have the slash types and they return very similar data other than the type 1 is now grouped by type, and I believe we have this conversation in the past, where people thought that it was more friendly. Maybe maybe the right word mushrooms are to have a have a types thing as the searching mechanism for types, so this felt whoops.

B

I think people thought this was more natural than using this type of thing where, instead of name you say type equal, something I seem to recall that conversation.

B

Does anybody. Remember. Am I remembering correctly because I thought that I thought we talked about this briefly before.

L

Like I said, I think that's true for certain implementations and views of this data, but I it because the two return exactly the same data it. It seems very strange to do this grouping and actually spec it out.

B

Anybody have any opinion whether it's strange or not,.

B

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 thing here. It allows you to search based on type.

L

Yeah, I think that's right. We would get services listed uh and have an additional filter of of uh some sort of type, and we can determine some sort of fuzzy matching right.

B

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.

L

On the surface of it anyway, 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.

L

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.

B

Right but it, but if they do that, it's an extension, it's not a core part of the spec. So there's zero internal ability, guarantees.

L

That's that's right: they have their own custom semantics right.

B

Anybody have any opinion.

B

Oh, come on, don't be so close. I.

O

Don't wanna, uh so do you hear me? Yes, I do go ahead. Okay, so don't wanna uh throw the conversation off track, but uh have we ever considered uh discovering, based on any arbitrary uh attributes,.

O

Because it sees you know, services and types being the top level. You know discovery path, but how about, for example, based on subject or something like that.

L

Yeah, that's that's exactly where my mind went. I think, defining this types and the pivot table around uh type value to service mappings is cute for one case, but I assume that someone's going to want.

L

uh You know based on schema or based on service url or whatever right yet, so I don't think we could possibly identify all the ways that you would like like to pivot this data.

L

So my I was like well. Maybe we shouldn't try yeah.

B

All right to be honest with this guy. I completely agree with this. I actually suggested this a while ago and it got shot down so.

O

Okay, so uh scott, are you the one uh focusing on this one right now? uh If you want, I can spend some time with you working on. It's certainly something I'm interested in uh working on.

L

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.

O

Okay sounds good. Thank you.

B

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 or the types api. I should say.

G

uh For me, if I'm vocal, it's just that, I'm still trying to figure out where it goes, we're all discovering stuff. So I don't have a strong opinion in either direction.

B

Okay, well, we have time to think about it. We all do um pr's not there yet so we'll see.

B

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.

L

Yeah sure so the at the moment we have services uh 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 name. So it's name and description, and that refers to the type object of the cloud event type.

B

An identity comment in the issue. I think I think the reason we went this direction was because um this is the way it would appear inside the kataban attributes. The same way all these would appear. I believe this way at least the the ones that do line up with cloud events like data schema and so like that interesting enough, I guess yeah these these two anyway right.

B

um So the question there and to me is uh 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.

K

Mind.

B

But I'd like to hear what other people think.

B

I'm gonna pick on people.

B

Eric I'm gonna pick on you. You have any comment on this one or thought on this. One.

P

uh Not a good one, I thought that uh the consistency argument held a little weight. I liked it. um My kid also was up and down all night and screaming it has to come. So I'm not totally here.

B

That's a good excuse. I like that. Okay, um anybody else want to chime in lance as it has an sdk gut person. You may uh have some thoughts on this one.

M

I'm not sure I have any thoughts that I'm willing to share at the moment.

M

Okay,.

B

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 do think it's kind of an important one, uh because it it does kind of impact, the the ux side of things slightly, potentially good, potentially bad. Depending your point of view.

L

It I mean the the name of the cloud event attribute. That's interesting. I haven'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 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 totally true and then in up up above service has name.

L

Should that be service.

B

That's a good question: does this? Does this appear in the cloud event.

M

No, I don't.

B

Think it does, does it.

M

No.

L

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.

L

Event.

B

Say that again, one more time you lost me, I don't know why you lost me, but you did.

L

So 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.

B

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.

L

It's just for discovery it it's. It serves a similar purpose than to name I I don't know, I'm just spitballing.

B

Yeah something to think about, I don't know okay well, anyway. Everybody please, please think about this one. um um I do think we should probably have a discussion next week. um I don't know scott if you, whether you want to wait or create a pr or not, but either way people please think about it.

B

Any other comment on this one before we move forward.

B

Okay, I think that's it for the normal agenda before we jump over to the discovery, interop or implementation call. Are there any of the topics people like to bring up.

B

Okay and let's just do the last attendee list thing and then we'll let everybody go um normal, are you still there? I don't. I don't see them. Unfortunately, what about josh you? There.

F

Josh, hey.

E

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.

B

Fine, we like we like lurkers, that's okay, yeah,.

E

I don't have, I don't, have opinions on these changes. No.

B

No, I wasn't asking about that. I just want to get you on the attendee list and you just have to say yes, I'm here, that's it. Yes,.

E

I'm here.

B

Okay, cool uh manuel.

E

Yes, I'm here.

B

All right and grants hear that right, yeah. Actually, I got to use the chat you're good. Yes, all right, nermal! I don't see him anybody else. I miss for the attendee list.

B

All right, in that case, everybody else, is free to go anybody's sticking on we'll start the discovery implementation call in about a minute or so. Thank you.

B

Everybody.

B

All right just couple more.

A

Seconds.

B

All right, let's go and get started.

B

So trying to think about we're going 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 those issues, we can talk about those too.

L

I no, I think I, my main focus is around simplification of the the service that is trying to host this data.

B

Right was there anything in the spec that you've come across so far that just I I I know you, you noticed lots of things in there or a couple things in there anyway. They all don't. They seem relatively minor. So far, right dude, I hadn'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 chord design.

L

No, I don't think, there's anything majorly wrong with it. The one big question I do have is around um the actual rest interface, and I like the fact that we're trying to define what the payload means um I I want to make sure that there's a room enough to implement this thing. As a like, a crd based kubernetes thing,.

A

Right.

L

Okay,.

B

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, has anybody have given any thought to um how we might do some sort of interop testing or something along those lines.

L

uh Well, we could, we could implement the aggregation, part and then chain a couple of these things.

B

Together, interesting.

B

How do you see that playing out from a client perspective? Is it is it then? Each person would like maybe write their own client and talk to the different options in terms of end points 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.

L

In the chain is a client to the next, the previous thing, oh, that's interesting to think of it.

L

uh Everyone's front end is someone else's back end, as the phrase goes.

B

Trying to figure out, if you make it completely circular,.

J

uh

J

I don't.

L

I say that it would be fine, it would yeah.

B

I wonder if you get it's like you'd have to it'd 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 synchronize with each other.

L

Yeah, the I think the chain would all uh harmonize.

B

Yeah, that would actually be kind of a cool, little exercise and then have a client hit every single guy. You know or every single uh point 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.

L

The code that I wrote is is a very super basic uh 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.

L

There's it's not dynamic data and it doesn't do fetching and lookup, but it could.

B

Well, I 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 individual con a consistency state across all of them right, because that would test things like the id stuff and then enter. If we introduce 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 everybody accordingly and then you know delete something.

B

Does everybody pick that up properly.

L

Was it a pr or an issue around um some discovery, changes for watch.

B

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 let me check okay, but I think that I think that's actually a really cool idea.

L

Well, I'm kind of full of cool ideas. You.

B

Are.

L

It's awesome.

B

Anybody else want to chime in.

B

And grant just to pick on you for a sec um in case you joined, hoping to do the sdk call we're not having one this week. It would be it's gonna be next week in case you joined for that.

I

Okay,.

B

Not that you have to leave you're welcome to stay just. I just realized that you may be here for that call.

I

No discovery is interesting.

B

Okay, cool, okay, well, scott's! Looking for that, okay did you find.

L

It what clemens uh proposed is that the services emit cloud events based on changes which 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.

B

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 defined it as one of the one of the guys in the chain, update 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.

B

I like it now scott, since you volunteered for some stuff earlier today, unless someone else wants to chime in there, 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 out somebody else, but I also don't mind doing it myself.

A

I actually have a random question: doug um is there um previous details on the discovery spec.

B

Say that one more time.

A

So so this segment that we're actually talking about is I'm looking at the um 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 I found oh here. We are.

B

Yeah, there's there's there's a whole spec.

A

I'm actually in the wrong location, never mind uh okay, so I was looking at a different segment of this cool. Thank you. Yep.

B

Okay,.

L

I haven't the pagination pr either because that was just.

B

Accepted.

L

Today,.

B

Yeah, I haven't done that, but I think that'd be a good thing to test too actually make a note of that so test. Things like update, delete, oops, pagination and conflicts uh elaborate, which means by conflicts.

L

Well, so, uh let's say that you have that chain 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, uh is now coming in as stale data. So like do, maybe we need like a resource version on those things like or a version number to to understand what like, which one should win if it.

L

If there is a conflict in the service that you can define, and one is stale data and one is uh more fresh.

B

I'm trying to understand how that would happen, so in 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 linked list or circular linked list. I well in the simple case.

L

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?

L

How.

L

Yeah, it's gonna be interesting, and then you know well, I don't know. Maybe there's if you have more of a tree architecture where a informs b in form c and a also informs c and b is out of date with a's events.

L

C should probably listen to a as the source of truth not be.

B

Yeah, that's this almost sounds like it's getting to the whole category of, uh I don't say a new spec, but it definitely is a section in respect that talks about how to do this. Aggregation.

L

Right, yeah: well, it could be as simple as a resource version or 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.

A

Okay,.

B

Generic resource version thingy, okay, something to add to the mix: yep: okay, cool, okay. I like this a lot I like this. This actually sounds like a really cool scenario. um Okay, anything else, people want to bring up either about the interop scenario or about next steps that we should take relative to our our respective implementations.

B

How many implementations are we working with here? I know of at least three yours, mine and remy's. Oh cool yep,.

G

I'm kind of told, because um I really see two different kind of implementation and, like um probably work less with cloud even than you guys, because I want to use it. But it's clearly not close to production in our company.

G

But when I, when I did the discovery, my thinking was like, if I created like a micro services, I want to be able to host a small discovery service. So basically, then people can know what that micro service exposes cloud events, and things like that. I didn't took like the example of like the big one, which is basically the aggregator, where it can be my enterprise discovery system that will aggregate all my micro services, but in that example, as a developer, my thought was like when I develop my micro service.

G

I just want to expose that and whenever I redeploy when I do continuous deployment, it's going to evolve and add the new events automatically. But when I do that, my issue is like. First, it's going to be hard to send cloud events because it's based on the deployment. So it's it's not like.

G

I'm basically changing the service, so I don't really see how I will limit the cloud event because then it will be relying on the ci parts that does the cd, I guess or maybe I'm wrong, but like I have issues like a philosophical issue, I suppose and well I'm not sure I understand completely yeah what we try to achieve some kind of stuff there for now.

L

uh 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, uh like kafka or nats broker.

L

The uh it'd be interesting to be able to ask that that broker all of the microservices that are sending it events, and so that 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.

G

Yeah and so in your scenario for now I did the discovery service like of the microservices, but I didn't know the aggregator and I didn't do the aggregator on on the broker apart, which is most.

L

Valuable.

G

For the client, I.

L

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 superset like. Maybe they don't emit events themselves at all, but they do facilitate the aggregation of several microservices into a single consumer.

G

Yeah and in my case is like so I would like to have the micro service that exposed like a really basic uh end point 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, uh but maybe your broker may can make it, and it's even better for me um 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 micro service, they kind of register.

G

To that one.

L

I think we still need to figure out how your micro services tell upstream that uh they've they've updated their catalogs.

G

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.

G

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 uh to to know what kind of cloud events you need to send to send? That's where I'm still confused.

G

Maybe do not spend enough time implementing or playing with it or not, to have a less confused id.

B

Lancer hand us up: did you want to chime in this conversation or is it something different.

M

Well, a little of both um remy um the the discovery spec that you've implemented. That's the pr in the javascript sdk is that great.

K

Correct.

M

Have you iterated on that at all? Is it or is that the the point of truth for that.

G

uh I didn't iterate more while we were changing some spec like I wanted to to get better understanding yeah.

G

I don't think it will take that much time because, like the whole logic is already there, so it's not like crazy. I had to implement the uid stuff because, like so same thing, the uid I talked with dog in the past, like it was a bit uh disturbing me because, as it's kind of statically linked into your code generating the uuid was kind of meaningless in that situation.

G

So what we agreed is like to create a uid based on the name, which is a specific case, but 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 state. You don't want to have all those and even pagination is kind of, uh and I would say a bit annoying to do it's not impossible.

G

It's like not the same idea. I think, but I'm happy to revisit. If you need uh some updates on anything.

M

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 native 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.

M

There's kind of a gap like it's emitting events to what is that part of any anything that needs to be specified.

L

You would probably have some sort of hook registration process in the microservice it says 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.

M

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- um is that part of the spec or is that something that's just left open to the reader.

L

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 control plane. Events for the discovery.

B

Api, sorry, I was distracted me all right. Are we done with those with that conversation doug get in the game? Man?

B

Whenever I host this phone call, it's like that's when people decide to start talking to me and it's like for them. If this is a whole hour hour and a half how long it is it's like my backlog of slack messages, just gets huge, so I apologize.

B

My.

M

Questions were just sort of a little basic background information. I guess.

I

Okay,.

M

Okay,.

B

um Actually, what's interesting is remy 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.

B

I guess might be 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.

B

Okay, anything else you guys want to bring up on this call at all. I think a really cool direction laid out and I like it and it's been a nice forcing function for testing some of these things.

L

I think lance has a good point around like how. How does that, if, if the thing's going to raise events like what does that really mean- and um one option could be that we we implement the http watch api and it's like. If, if someone is interested in uh 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.

L

So push versus pull.

B

Was there a question in there or you just explain the.

L

Difference between person, first of all, 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 this recovery, 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.

L

Yeah.

B

So that's just slightly different question, although it's related your watch api, do you see that being a completely separate api?

B

I mean, I know you're in your mind, you're thinking of the kube watch things 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.

L

uh Yeah, I 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, subscribing yeah.

B

Yeah, because that's another cool aspect of this right, you get we again. We then get to bring in this whole subscription api spec into the mix, which would be nice.

F

Remy is your hand up new or old yeah. It was new.

G

um I was just thinking um I don't know. If things do do we already have like a kubernetes system out where we could all push like a basic functional system like the discovery, the subscription to understand the whole cinematics? Maybe I'm completely off, but it exists, I'm asking stupid stuff, but it's just for me. It's the same.

G

I really need to make it real and I didn't read enough of the subscription api, so I it's also lack of knowledge on my side, but, like I like to understand the full kinematic of a complete scenario where, like I have like either I'm a micro service developer and I push on your service inside that cube and basically it magically appears in the discovery and start sending and as an external developer, a 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.

G

uh 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 and for now, when I developed it 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 altogether or exist or not.

B

Yeah, I don't know if one anybody on the call know of one.

B

I'm sorry, I don't, I don't think anybody does, but.

G

Like um basically one place where maybe a cuban is because I think then 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.

L

I mean this should work kubernetes or not. I think yeah exactly make sure that it doesn't require.

G

Kubernetes but it's possible yeah, it's just to all share like basically to all be able to deploy small pods, all together, like a different company, but just to see the interrupt player and interrupt their ability. Sorry, that was my thought. So kubernetes is just a technical.

L

Yeah I mean I'm gonna toot, the k-native horn. That's that's! Basically, what we're doing so. You stand up. K-Native eventing and you see uh cloud events own okay, lane.

M

um Yeah I mean I, I was just gonna say that basic, basically that um it, it might be useful to have some instructions in order to set all this stuff up using. um I think um carlos santana has a a kind cluster set of instructions that gets k-native serving running.

M

Can you 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 uh a couple of yml 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.

M

Okay, I.

B

Think it's a good idea. It just feels a little premature since we don't really have running code yet.

M

Yeah yeah.

G

But that will allow us to basically then for the interview test. We can just all push our stuff in it and make it work. Yeah.

K

I can.

G

I can probably spend some time looking at it like. I was looking at kyogre and some stuff yeah.

B

But then.

G

And then you just open it to all the members from these groups, so they can push to the same cluster that we.

K

Can.

G

Play like a playground: okay,.

B

Okay, all right anything else: anybody want to bring up.

M

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 um the meeting before and um I didn't know about it um is. How often does it happen? Is it it doesn't appear to be on the calendar, but this.

B

Is the very first thing call.

M

Okay, well, that's why I haven't attended before that's.

B

Right and we we just decided to do it last week um on the on the cloud events call, so you.

M

Didn't miss anything paying more attention. Last week there you go.

B

Yeah, um actually, if 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, sdk of the week uh discovery or interop testing or is every other week too far apart.

B

I suspect that we did it every week we may not get as much changes done on a weekly basis to warrant a call, but likely.

L

Every other week interrupt in interop call. That's interesting. Did you plan on that? My little plus one.

B

Okay,.

L

This one.

M

I like that idea.

B

Okay, alternate.

L

Oh, my gosh, I'm gonna do this. Okay, I see this is one big deficit of the the cloud events spec community is that there isn't a ton of interrupt development, that's happening.

L

You know comparing this uh participant list to the cloud events call participant list right like there's a lot of opinions on the spec, but not a lot of uh fingers typing the implementations, yeah.

B

That is a good point. I I know that there are lots of implementations out on my own lots. I.

L

Know there are.

B

There are implementations out there because, when I've gone to talk to customers about other subjects and cloud 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 you know they 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.

L

Yeah dapper rolled their own implementation.

I

Of cloud events of.

L

Cloud events, yeah cool.

B

Yeah you think about it: it's not exactly a whole lot of code right, and so I'm not that surprised.

L

There's a lot of corner cases that they probably don't have uh correct.

B

Maybe yeah all right anything else. Anybody want to bring up.

L

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.

B

Mine is not yet. I will open source it at some point when it's not embarrassing, but not yet.

B

What what language are you using I'm using go dog? Why not.

B

It's the language of choice. For me, these days, yeah.

G

Remy, yours is what javascript uh typescript.

F

Yeah.

M

Script: 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.

G

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 services with like way more future, then it should definitely be another repo. So I was thinking almost out 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 uh maybe I'm wrong.

G

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.

B

Yeah we can always move stuff later nothing's set in stone, right, you'd always create. You know brand new, sdk or implementation type of repos as necessary.

I

Yeah, I guess um that brings up a good question so is like uh the discovery. Part is that is that part of the sdk spec.

B

I don't think it's part of any sd card. Do we even have an sdk spec? I don't think we do do we.

I

We have the sdk markdown dock in this. Oh no.

B

No, I don't know not as of right now.

N

Okay, there isn't any real project yet so.

I

I guess 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.

G

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.

G

Okay,.

L

There's actually perspectives, there's the hosting part and there's the consuming the api part.

G

Yeah you're right, I didn't do the consuming api part yet, but that one should probably be in the sdk. Then no.

B

Okay, anything else.

B

All right, in that case, I believe we are done. Thank you. Everybody for joining.

F

I'll talk.

B

Again next week, all right, bye,.
youtube image
From YouTube: CNCF Serverless Working Group 2020-08-13

Description

CNCF Serverless Working Group 2020-08-13