Add a meeting Rate this page

A

Doug Doug Doug mornin.

A

You.

B

Hello.

B

Hey hey sorry, I was on mute, taking a different call just to get this one set up how's it going guys.

C

It is going well.

B

Well, that is good. Yes,.

D

It's.

B

Hard to get that kind of swing of things after the nice break between koukin and Thanksgiving, and everything.

C

Obviously, I'm watching the you know yes keynote. At the same time, Oh.

B

Any exciting going on there.

C

Not for me, okay, no talking about the ends and like virtualization stuff all whole things that I'm not III, can't get too excited about this other people problem.

B

Hey Tommy.

B

Christian hey the morning, hello, ginger,.

E

Hello.

B

Find you there. Yes, I am welcome back yeah thanks everybody. Yes,.

B

Roland, are you there.

B

Hello, I think I barely heard you them that gun there, hello, yes, I'm yeah there you go. Is this your first time on the call.

F

Okay,.

B

Do me a favor um I pasted, a minute I'll link to the minutes. If you can just put your company name next to your name and the agenda. Just so, I can give your company credit for joining I'd appreciate that alright, thank you and.

B

Hey Christophe.

D

Mm-Hmm.

B

Hey and John either yet good.

G

Morning.

B

You know if I don't remember somebody please remind me: I was gonna, ask if people actually want to have a phone call in the nineteenth, because I don't know about you guys, but at least within IBM a lot of people start taking vacation or right around the fifteenth or so so I, don't know how many people are actually gonna. Take a phone call on.

C

The 19th oh yeah,.

B

I'm supposed to pay, but for you guys, I, trying to call yeah. Oh that.

C

Is so nice.

B

Yes, yes, I, don't know whether it's dedication or insanity or something but there's something I know how my wife feels about it. So.

B

What you guys are out early today.

B

huh New York.

B

And then we'll are you there, man well Stein. Yes, said: oh I'm, yeah, hey! Is this your first time on the call? Yes, it is okay, great. Do you a favor, I'm gonna paste, a link to the agenda talk into the chat, if you could just add your company name next to your name. Just with that way, you guys can get credit for joining I'd appreciate, Thanks!

B

Thank you and Ryan. Are you there? I am.

H

Yes, hey.

B

I know this isn't your first time on the calling he remember. If I have your company name associate with you render that I am.

H

With Twilio.

B

Okay, that sounds familiar. Okay got it I'll break that just in case I forgot it. Okay,.

H

Just just 1l, okay.

D

Holy cow I must know where you found.

B

Jeez, okay, thank you and let's see Jimmy there. Yes, sir hello.

D

Mm all.

B

Right one more minute that we get started: Mohammed are you there.

F

Hey good morning.

E

Collins on a plane.

B

Okay, thank you all right class. Are you there yet? Oh, maybe okay anyway, got some up later right. Sixteen that's going to get started. um Okay, community financial! For those who are new to the call to me. This is a time for anybody who's, normally, not on the call to bring up a topic that they might want to bring up for discussion for the community to to ponder. Is there anything if you want to bring up.

I

All right moving.

B

Forward then just reminder we do have a call December of 26 or the second. Does anybody want to have a call December? What is that 19th I know a lot of people give me on vacation starting around the 15th or so do people have a preference for a call or not on the 19th.

E

I'll side with your wife and say no.

F

Okay,.

B

So is there any objection, then, to cancel in the 19th okay I'll make sundered about that? Thank you guys and Klaus I think you're there. Now, yes,.

A

I'm, okay, did you hear me? Yes,.

B

I can thank you, okay, cool all right moving forward, then SDK I, don't think. We've had a call for several weeks now, so nothing is anything to mention other. Then we do have a call scheduled for today.

B

So if you're interested in that part, the discussion to stick on the call after this one will started basically immediately after this one ends, even if it ends early, let's see I don't see Cathy on the call or anybody else from that work group to mention anything so I, don't things anything to talk about where that's, if to the workflow other than still the work is still going on over there server interested in that please join. They are ramping up.

B

What I want to do now is give an opportunity for people talk a little bit about what happened to kook on I. Do have a whole section down here talking about what we're going to work on next, so save those discussions for later. But does anybody want to bring up anything relative to the practitioner summit or the cloud event session, but they think might be of interest to the group in general.

B

Nothing: okay, tell you what I, just let you guys know at Keuka itself. I was hit up for quite a few press interviews around cloud events well mainly about cloud events, obviously because we reached 1.0, but a lot of them also did then ask about you know what could happen next with a service working group and they all seemed really generally interested in and excited by a cloud event. So that was all good and they're, also very much interested in what we're going to work on next.

B

The service working group and I did let them know what the current thinking was in terms of some of the ideas that we've talked about, but I definitely did not tell them what program work on next, because obviously haven't decided yet.

B

But it's thought that you guys know that there is interest out there, at least from the PR type of people, that I talked to not only in terms of what we've done so far, but in terms of what we're gonna work on next, because a lot of them seem to really like what we've done, not just from a straight technical perspective, but in terms of the community aspect in terms of bringing everybody together, they seem to think that this was a little bit of a unique currents, because while there have been standards, work done in the past other things they didn't see it being quite as collaborative and and non-political as this one has been, and hopefully I wasn't lying and you guys feel the same way when I expressed that to them.

B

So they do seem to really like what we're doing here and they're very eager to see what we work on next and to see if we can keep the the good feelings going with all this I thought that was all kind of nice. But again one last chance. Anybody else want to bring up anything relative to cook on they might not give interest all right cool in that case moving forward.

B

What I wanted to do in the future calls is to make sure that we don't ignore some of the stuff that's going on in cloud events as we work on something new is I want to do a little bit of things like issue triage or PR trios, if needed, but I'm not going. Obviously, gonna spend the entire timeline. That's what I did I just picked out three of the newer issues and just to make sure we this has some owners are going to take a look at it. Clemens I thought.

B

Maybe you could take a quick look at this, want to talk about AMQP, since that's in your wheelhouse yeah, so.

B

Well, we don't think it's written now. Just could you just reply acto on the column well,.

C

I will take a look and then we'll okay, because this expired draft has become the proprietary protocol of one particular product and, as such, I think.

C

The similar rules apply as they do for other products of that sort and that we link to spec it's okay.

B

Cool and the next one, the person who opened it. He basically said whole bunch of questions about about how to use cloud. Events.

B

Ed and I did my best to try to answer his questions, but there was one outstanding thing that I wanted to get clarification on from Scott in particular, so Scott I was wondering if you could at least take a look at the at the mention of your name in there to see if I got the answer right about Kay native, if you get a chance, thank you and the last one was somebody wanted to talk about open API for our stuff and Scott I know you said you had some experience with the opening API stuff I was one of you could take a look at that one as well.

B

Unless there's someone else like all who feels like they have enough knowledge in that space to take a look at that one.

J

Can you can you clarify what the question there is which one there's.

B

A the.

J

Open API one, oh I,.

B

Think you just want to know how to write a swagger doc for it, but I'm, not a presenter. Let me go back and remind me refresh my memory here. The.

A

Thing that's funny about that is that it's not going to work for HTTP for both encoding, so you're gonna have to choose up front which encoding your swaggering for.

J

Yeah I'm not quite sure what you I'll see if we actually did that, whether we bothered to or not because it isn't, it's questionable whether actually makes sense.

B

Okay, well good, if you guys could take a look at that appreciate it just so, you don't feel like this. Guy doesn't feel like we're, ignoring him.

B

Okay, yeah.

J

I'll have a look and see what we did cool.

B

Thank you, and did you raise your hand for a different question, or was that it? You know I just forgot to lower it: okay, cool okay. Luckily we have no PRS review, so that's all good. So now I could jump into the fun stuff. What to work on next. Let's see I want to show something here. So a couple things. First of all in terms of the face-to-face meeting and the server this working group session, I've had a coupon, we did take notes and the link to it is in the meeting minutes.

B

It's this link right here. We did take notes in terms of people. Were there brainstorming sessions to me, the most important thing was once we parody was done with they're sort of brainstorming ideas of what we could possibly work on. We then asked the group ok. After all these ideas, let's narrow it down to what we actually think is doable and possible to work on, and people could actually get behind, and it came basically came down to this list right here, which is did it do? Where? Is it I? Don't have there anyway?

B

Okay, which is basically this list right here now, and this is in the meeting minutes as well. The other thing is, though, at the birds of a feather working group session. We had here's basically summary of the notes that I took there. What was interesting to me was a couple of things. First, there seemed to be a split in the room about how important portability and lock-in was.

B

We had some people who thought it was very, very important, and we had some people who thought it wasn't important at all, and people just managed to work around it. So I thought that was kind of interesting, because in the past most people seem to think that Interop was actually really be concerned. So it kind of took me aback a little to hear that for some people, it's not an issue whatsoever, so that was kind of interesting.

B

But the other interesting thing is that, in terms of what to work on next, there definitely seem to be a lot of people, leaning towards the discovery and catalog side of things which was interesting and in terms of adoption of surplus and functions itself. The general consensus I got from the room was for newer things. People don't necessarily seem to be having a CERN was going towards service, the bigger concerned to be seeing more around things like you know. How do they get there from where they are?

B

Today is our example: how would they break up the monolith, not just in containers, but then all the way down to functions or they're a little bit nervous about technology, so they may start with tooling type of stuff or utilities and not necessarily jump full head. You know head on into using it for product level code. Quite yet, so it's a slow progression kind of thing which, which makes sense from all perspectives in terms of you, know slow learning curve, so that was that was kind of nice to hear.

B

But the biggest thing I think for us is to actually talk about what to work on next and, as I said, I think discovering catalog was probably the top thing that kept coming up and a very close second was function. Signatures so I think those are so the two top things, but let me pause there and see if other people who are at coop con I had a different take than in my view of it.

B

You.

D

Nothing.

B

Scott Clemmens, Klaus and remember boss was there he had one. You want to add anything to that.

C

Oh, my god, I didn't pay.

B

Attention to what my question or the entire koukin I was wondering if you had anything to add to my commentary or summary of what happened koukin, you.

C

Are.

B

Okay; okay, in that case, what I'd like to do is this.

B

Okay, I'm not quite sure how to procedure; I'm, sorry, so I'm gonna to speak up there, yeah.

K

Can you tell me one sentence, what catalogue discovery means is that for cloud events, or instead for function as a service.

L

In general, so I'm gonna hand it I'm gonna force someone else to talk here. Scott.

B

I'm gonna, have you answered that one, since this was more your idea than anybody else's, that I could got itself anyway, yeah.

A

So catalog.

A

Catalog for producers and consumers, so, basically I think open API, but open API is tied to usually HTTP, so it dictates a certain protocol. You need to speak to the that producer that consumer, but what we've done with cloud events is kind of reduce the that dependency on the protocol you choose. So I would like to explore a some sort of concept.

A

Where you can, you can get a catalog of events from a let's, let's take a producer and says I produce the following: conical versions of cloud events possibly also says: I can speak on these protocols.

A

So if an agnostic way to ask about what what the shape of the event and what? What does it mean to you to use the extension foo where foo is not defined in the cloud event spec, but but may be used in your organization you're trying to negotiate which foo you actually mean.

D

Help Christophe, yes,.

C

Got it? Thank you, yeah, see, I, think we had so we had custard a few things in the discussion and three things we costed together or the idea of of this catalogue, and it is, you know, ask a and ask a publisher or its its delegates inform a middleware what events are available and then a schema registry, which you know tells you what the payloads are in those events, I think those things work very well together and then the subscription API to now you have discover and how you gonna get at those.

A

Yep yeah d and the subscription API and kind of requires what what the shape of the event will be, because we would like to filter on only things that are inside the the envelope of the cloud event. And so you need to know what the envelope looks like yeah.

C

And I think, even if you didn't want to be intelligent inside of the inside of the middleware for scheme abounding coatings, like I mean we we keep those out now, but I think proto is going to be back for schema bones encoding swear you can't even decode the body without having a schema hands. I think a schema registry will be important, even if the middle, where it doesn't reason about the payloads yeah.

B

And what.

C

I, like about.

L

This direction.

B

Is that I know in the past we've talked about subscription. Api is something possibly to work on next and I think is, as Scott has pointed out, a couple of times that that's all well and good, but without the discovery side of it, it's going to be hard to automate it all right, tooling around that stuff, so I think what's really cool about this is Clement said. If you can link you know the discovery of what events are being generated, what their schema is that goes very nicely with the subscription API definition as well.

B

You know they all kind of fit together into this sort of attack in the same general problem. You know how do you get have you started asking for the events at what types so you can receive and it all just seems to fit nicely. Of course it's also a nice next step for the evolution of cloud events in terms of using the cloud of a metadata. They were defined in the next step of your tooling exploration kind of stuff, so I thought it was kind of a nice.

D

Thanks, oh yeah,.

I

Sorry uh I would like to invite people that are involved in that topic to maybe have a sidebar discussion. The reason I bring that up is. We have actually got a beta product that is, the catalog automatically generates the events. We've actually pushed that into a sync API, which is a parallel thing to open API, except for non HTTP, and we have code generators that have actually demonstrated internally just this week to our executive branch to generate spring cloud streams.

I

Applications based on cloud events in the category in the catalog and for some self-discovery, so I'd be interested in some opinions and what we've generated that might help us on the product direction as well. Cool.

B

I, don't suppose you have a link to legal pointers to it to you. Well,.

I

I could but then you'd have to be an employee. It's only can I.

B

Could.

I

Actually, sometime in the future, people are interested post a little demo or a little video if you're interested as well. Okay,.

B

That's cool all right, um any other questions or comments just around the idea of catalog discovery subscription, API type stuff. Look at it. Basically, these two things here.

K

Yeah.

B

This is.

H

Okay,.

K

Yeah, if I can make one comment on the subscription API, so what I? So I basically write a software service a time and we would push our events into a middleware and, if they're hosted like, for example, every event quit then our d end consumer would subscribe, should subscribe at the event quit api and then our api would push the events even quit, and I meant great boot boot and further, but there's a problem in that.

K

If we push all of our events to vanquished can be a lot of them and the end consumer, maybe only once the few of them. So what we end up with, maybe as pushing hundreds or thousands of events and the end consumer only one or two of them. So that's like a huge waste of money, so we could get like a standardized subscription API so that it can be forwarded along multiple hops. Then the first event producer can already know what events to send on so I would be very interested in this one cool.

B

Yes, that sounds interesting like that, and we getting problems.

A

In K native, we call the technique upstream filter propagation. It's.

K

A very nice name.

B

Who else raised their hand in there Kimber who was trying to speak as well? There.

H

Was me, it says, Ryan from Toledo I'll, just echo that we are working on some things that we basically need to invent. All of these are on our own, so I think that's a good validation to focus on these. Next, from from our side, cool.

B

Good to hear that yeah, so I'm hearing lots of people jumping on board with the idea of of catalog discovery, submission API. That kind of stuff, however I, don't want to assume make too much of an answer here. But so let me, but let's take a step back for a second and see. Are there other ideas that people have either arm lists from? You know the minutes that I'm highlighting here or just other deities in general, that people think no we're missing the boat.

B

This is the next best thing which we were working on instead and.

J

Jim Europe, so I I, guess the only one that I would add this list. I mean I, I think this list, it's good is sort of end-to-end security. So you know how you prove norm, tampering of payloads and and all that sort of stuff, yeah.

B

I think that I see did come up during a brainstorm session together that the at the face-to-face.

J

I mean I think it's to me what we need probably an opinion on whether it needs to be respect to the level of a subscription API or anything like that. I'm, not sure it's more of a pattern, I think initially.

L

So.

B

And that one I'm trying to figure out what you'd like me to do, would you like us to do with that? Is that something that you would like to ponder a little bit more to see what that actually means? Or do you want this to? Actually, you know put that on par with the other one and say you know we need to choose between the two it because this one's just as important I, don't.

J

Want to railroad I mean I'm I'm interested if other people think there's a need for that, because you know if I'm, in a extreme minority which isn't uncommon by the way to push it. No.

B

Kind of I kind of inverted the discussion here. So let me ask anybody else on the call. For example, Clemens I think you may have brought up security at one point as well, but you didn't seem to think it was. He was at the same level of that we should work on next. It was just something that sort of was in a hopper or something to consider. So what are the people think on the call about the Indian security idea?

B

Is it just interesting idea, or is it something that no, we actually should consider working on that next, so.

C

I think the the Registry's as we call them, that are a bit more importance and, and so security is something that we can.

C

We can probably tackle next now there is a I think the the pieces that are up to us to peak or to standardize, even if we think about creating an ecosystem which is backed by improper or software, then it's not so much about the end-to-end encryption per se. That's a that's an aspect of it, but there we have to go and pick pick something that we all can understand like s/mime or something like this. But then the question is from an internal perspective. Is how to restore are the the cryptid material?

C

How do we share it? So if you go and publish start publishing events and you use asymmetric encryption, and how do you share your public key and if you, and because it's asymmetric and because it's pops up your your keys, really great quicker than they usually would because you can't negotiate session keys, which means you don't need to be able to roll them, which gets you to the point that you have to have a schedule of keys. So there's I think there's lots of stuff that is required for and uniquely required for ready flows.

C

That calls for having you know a common interface to a key, vault and I. Think that's something that we should go. Take a look at more than then really, you know figuring out what a new crypto model, because ultimately I think s/mime or something like this is ready to go but I think having having you know a unified view of a key vault. That would be more interesting. I think that's something that we should eventually tackle, but from a priority perspective, I think of the subscription and discovery and schema registry as higher pry.

B

Thank you comments. Eric your hands up.

M

Yeah I actually have to say that I effect, idli agree with everything that Clemens has just said. I was also surprised along with Jim or, like he didn't state. This I was surprised that end in security concerns signatures encryption. That kind of stuff hadn't been on the list is something to discuss so I want a second that as something valuable to keep up there. I do think that the I I think there's a delivery API that perhaps is separate from a discovery or subscription API.

M

That also is, is higher priority than some of the security concerns for this group.

D

In a minute.

B

Okay, oh just from my own understanding when you say delivery API.

B

What what does that encapsulate is? It is something like the the web expect that we've already produced at fault. That category are you thinking something different.

M

Yeah I mean if he squinted the subscription API. When you ask to be delivered something inherently. You should then probably also talk about how that will be delivered, mmm but there was, um there was a bit of a I.

M

I was I, was envisioning the discovery and subscription as as kind of developer experience, or you know, although there were the other things and then the the delivery API is gonna, be far more productionize dand far more performant, it's gonna have a different kind of an environment and set of concerns. That's going to need to fit into in order to be fit for purpose, so I did there seemed to maybe not be enough separation and how that was being discussed, and so that's why? Every though okay.

B

Okay, thank you for the clarification and I think John your hands up next howdy.

G

Yeah I wanted to echo stuff that Clemens was talking about, but also the fact that the discovery, work and catalog work were we're. Gonna have to deal with authentication of those things, so it kind of leads into the the start of a bunch of the security work anyway.

B

Okay, thank you and Scott your hands up next.

A

No D I think I want to add to what Eric was saying. We did talk a little bit about function, signature like function signatures and making that more common, but I, don't think that's what you're saying one thing we didn't really talk about- or maybe we talked about super briefly- was protocol negotiation where you could upgrade some like if you wanted to talk over kafka queue directly, and maybe that is that we were talking about, was being able to negotiate to talk about how to get things delivered in the subscription API.

M

Yeah I think that's a really that's a good sophistication of what I was saying yeah. So you know what are the rules and expectations kind of? What are the guarantees that each side should make to the other? If it's a you know, Kafka queue. Was there a set of delivery requirements? You know, do I just say: hey: did you did I successfully open and transmit that data or hey? Are you gonna act that it was actually written to the disk? Some of these nuances really matter for how you design system.

B

So Eric um do you look at the deliver. Api is something that's actually distinct from subscription API, or do you look at it as a sort of a subcategory of subscription API because you have to do as Scott calls it protocol negotiation.

M

Yeah I kind of I was that's what I was saying if you squinted subscription to the API. It includes a delivery API but I think they're fairly different requirements for the delivery of data through a specific protocol and and using maybe even within a protocol specific rules about what that means. It might be nice to have amount of standardization across protocols, but that gets us into some pretty difficult waters. Yeah.

B

Okay, okay, go! Thank you! Okay, so John's got your hands, are still up. I assume those are old, right, okay, cool anybody else want to jump in here and comment on this and just want to point out. There were other things that were mentioned. Obviously, focus signatures popped up there to refresh the white paper and that's of Education stuff as well, um but as anybody else want to mention something that they think that they're just flat-out missing, it should be added to the list.

B

You a Heinz.

I

Sorry I was still on mute, having done quite a bit of work with the api's in the last couple of weeks and the fact that, as I mentioned, we are doing a lot of cogeneration based on the schemas. Some more expansion on the actual cloud event schema where right now, it's quite elegant with all definitions.

I

However, I don't know if this is the best practice or something that should be defined farther. So, for example, I ran into if I had to add a JSON schema that represented the data in the cloud event schema. How do I merge? Those should I make it. Another definition should I make it.

I

You know so, there's quite a few ways to do these things and there might be a better way or a worse way, but might be recommended and possibly, for example, we found some of the libraries for some validations and things really don't like everything using definitions. They expect a more common definition, less schema. That might be something that is produced as well, so just a little bit more work around the actual schema, because there is one one example only and there's multiple ways to do: JSON so.

B

Make sure I just understand there. So when you talk about the schema, you think about the schema of say the structure cloud event payload, we talked about the schema of.

F

The business logic, the.

I

Jima in the structured, so we have this schema for the structured message, which is old definitions. There's one example, however, for the data part right that in itself may be another complete JSON schema.

D

So.

I

What is the best way to reference it do I, do it with definitions?

I

Do I inject it directly in the definition like what do we recommend for people that are doing JSON within JSON, which becomes very important, for you know things like code generators which we're using where I can actually extrapolate that into then the resin has an SDK I, actually generate a full object, setters and getters, so you know, or maybe a- and we also ran into some of the validation libraries using a schema that is there now, which is purely based on definition, does not work correctly, all the time so having one example where it's not definitions, when a regular, you know you know structured attributes with all the properties and everything kind of manually define, might be of value as well, but just more work around the actual I mean.

I

All of this is based, if you're doing the structure. It is this. You know the cloud event schema, which right now there's one example and really no discussion or and again, even though it's nice, it should be cleaned up where some of the definitions, where they define the event and the event, is then referencing. Other definitions, the kind of some at the top some below you know just clean it up a little bit might not be a bad idea either. Okay,.

B

So it's interesting because this doesn't this I sound like I, say a whole new work stream as much as it's just additional tweaks to the spec, its to the other spec or the primer itself and I. Think these from my point of view, that's always been a sort of on the table, as as people raise issues or concerns with the spec right.

B

There's a classification. It's.

I

Not the spec is fine, it's kind of like when you're doing the SDK it's great to have the libraries, but without examples it's not going to be adapt adopted and people get frustrated. So again the spec is not affected. It's purely the samples of the JSON schemas provided which, to your point I think, might be reference more towards the primer than the spec itself. Okay,.

N

Okay, thanks for clarification, all right post vetoed one I, don't know if it's if it fits but I'm sort of missing the packaging contract that was discussed and face to face it's clusters with the function signatures right screaming.

L

Earlier.

N

Pointing it we had the discovery, catalog a delivery, API subscription, API sort of all fitting in one cluster and I think we had more about how the functions would be described and factory signature.

N

Yeah.

B

Right be difficult, but that didn't include it was because well, it was mentioned during the face-to-face like that. It was my impression that it didn't get as many votes as the other ones, but you're definitely right at Dave was mentioned.

B

Okay, anybody else want to jump in there, okay, so I'm, trying to think in terms of next steps. Here. My natural inclination is to believe that wow it would be wonderful to work on multiple these things. At the same time, given our history I tend to think we have to be kind of single threaded.

B

Is there anybody that thinks we can actually do more than one next new thing, meaning not just tweaks to the current cloud event, spec or anything on that, but in terms of a new project or a new specification, does anybody think we could do more than one at a time.

B

Okay, cuz that to me says we're gonna have to come down to a vote and we're gonna have to pick what that makes. One thing is and I'm sorry there's somebody in the kitchen I think. Maybe we can go on mute, I'm, not sure what that noise was.

B

It seems to me that you might be good for people that go back to the respective companies and do some thinking about what they think they'd like to work on next I. Ultimately, though, I do think as of right now, I'm hearing more people, leaning towards the subscription API type stuff more than anything else.

B

Whether number two is things like function, signatures or packaging contract or internet security I'm, not sure yet, but I'm not sure it matters. Both we gonna pick one, but what I'd like to do is come back onto the next week's call and basically take a vote in essence and say: you know: is it going to be subscription API? Is it going to be in security or any other ones that are mentioned?

B

Does that sound fair to people? Give you guys one week to think about it and come back and basically vote next week and see which one gets the highest number of votes, or is there a different process you'd like to follow.

D

Those good to me, okay, thank you, commence, I, don't like.

B

Silence anybody else, wanna chime in otherwise I will assume. Silence is a agreement you, okay, so in terms of thinking about what we'd actually gonna vote on just to reduce the number of choices. I do think subscription, API and discovery is on the list. I think we're. Not people have said. Yes to that one is there anybody who thinks that functions signatures should be on the list for people to consider. Oh I'll go first with voicing opinion on this one personally, I love the idea of function, signatures I, think that's a wonderful thing to tackle.

B

However, I think that is a. It is a non-trivial problem to solve because of the differences between the various platforms that are out there today, which also tells me it probably might be very, very political and so I would love the work on this thing at some point in the future, I think it may require a little bit more discussions offline first to see that about the feasibility of it.

B

So I like to sort of keep that in the back burner, but in terms of as a top order vote, possibility I'd like to not include that in a list just because I think it's it's not as a father that cat, where, in my mind of small next baby step, this one feels like it's a bit. It's a biggie to think about, and maybe a rat hole for us to think about. Anybody else want to advocate function, signatures being on a list of considerations.

B

Okay, these two things, I think can be done anytime, would honestly have to take a vote on it. There's just need people to volunteer to do that kind of stuff and insecurity I'm assuming that will be on the list just because Jim you mentioned is, and you thought it was important enough. Is there anybody who disagrees with keeping it on the list in terms of on the vote for next week.

B

Okay, delivery, API Eric, since you mentioned it, I assumed you'd like that on the list or not.

M

However works we need to that. Maybe under a subscription API I don't have strong opinion. Okay,.

B

Anybody else have an opinion as to whether it should be a standalone entity, or we should consider it under the subscription API model for a project.

B

Brian I.

H

Think that they are interrelated and I, don't think that they can be just having thought about this a bit in the context of what we're working on. Actually, oh I, don't know that they can be developed independently, so I would advocate, for even if they are, you know conceptually separate things. I think they need to be thought about together, including.

B

My.

H

Experience: okay.

B

I should mention offline just because of all the discussions that have been going on. I started the process of putting together just something a little more concrete about what's discovery and the subscription API with concepts would be, do not interpret this document as as a as anything other than just my ramblings. Just try to get something a little more concrete, so I could have a conversation with people about what we were thinking about. Doing and I said. You know the link is here in the in the notes Eric. What?

B

If we did this, what if we start off with delivery, API being considered a subset of the subscription API discussion and as we make progress on there, if it turns out it's either too big or something caused us to think you know, is really need to be pulled out. We can pull it out later. Does that make any sense, yeah, okay, cool? Thank you, I'll move it into there.

B

Okay, all right um Hines! Is it okay with you if I consider this to be just a normal part of maintenance work on the cloud event specification, so it's not initially considered as a top-level potential new project. Well,.

I

I'm totally a now it's how I had envisioned it anyway, so we're on the same page: okay,.

B

Cool and Manuel, do you think there was enough support for packaging contract to be considered a top-level vote possibility for next week.

N

Whoo I'm in the balance. If it was just container OC ice, then it might be low-hanging fruit. If it was functions, delivered wrapped up, then it might be similar to function signatures a bigger one.

N

Has.

B

Any comments.

N

Yeah.

B

I was going to ask anybody else on the call have any opinion on this one, whether they think it should be part of the vote for next week, because as a right now, we'd have two items, discovery and and then deliberate. So this would be the third one. Anybody have an opinion.

B

Just trying to reduce the amount of thinking you guys have to do for next week. It's a pretty crowded space.

B

You know what's interesting is when I think of a packet of contract. Well, I think it actually kind of falls in the same category from some signatures as G's that were really nice about. If there was commonality it feels like it's gonna get very political, very fast. Oh that's just my. My gut feel yep.

N

Let's.

B

Leave it undefined okay, okay, so it sounds like we have intense security and the discovery subscription. Api, slash delivery API as the two topics to consider for next week that sound right to people.

B

Okay, thank you. Any objection. Oh Clements, freaking seasonally I, was.

C

I was not.

B

Even lovely, nothing, okay, all right, so what I'll do is I'll send out a note saying that we're going to vote next week. These two items for next big work item to work on and people should come very to vote either next week or if they can't make the call, then it's just votes through email or, however means we're means they want. Then I'll record their vote all right. Anything else, relative to post, 1.0 or future work out of discussion. Any of the topics.

B

All right, in that case, any other topics for the agenda at all. You'll want to bring up.

B

All right, in that case, let's just do the fun of alcohol, then you guys are free to go except for the SDK folks, um Doug. Are you there, the other Doug here all right and Vladimir? Are you there I'm.

M

Here, thank you. Hey.

B

Excellent anybody else that I missed from the roll call all right cool, in that case everybody but SDK folks, are free to leave. Thank you guys very much and we'll get started in just a minute or so as people need the call I'm.

C

Perfectly SDK: well, okay,.

B

Thanks Cummins, you know I suspect, I'll be short anyway, but we'll say yes,.

C

I mean triple both this slot, not a problem. Okay, excellent thank.

H

You goodbye.

B

So, while we're waiting um Scott, do you have anything to talk about I'm, a yes to kick off and.

A

Not really and I want to go to the kata call in 15 minutes, there's a key to call yeah really.

B

Where is that for who's hosting that it's a gated community? Oh, oh, okay, okay! Well, in that case, is there anybody who has any topics at all for the SDK side of the house, because if not, we will just adjourn very early.

I

Actually had a quick question.

N

I.

I

Was trying to work with the Java SDK and had some good success except like could not get the vertex virtual vertex thing working I! Wonder if there's like a working sample that somebody might have a.

B

Mana call use the Java SDK.

B

You may try asking in the SDK slack channel or open an issue because I think favio while I don't he doesn't typically join his calls anymore. He does want it or they get her repo fairly well and he does respond to my slack messages. So he is in both of those places. Okay,.

F

Maybe.

B

I'll help you, okay,.

F

Thank.

I

You, okay.

B

Anything else or anything at all for the SDK meeting.

B

Alright, in that case, we're probably done then: okay, thanks guys and we'll talk again, mystic a perspective and I guess not too weak so back in be in January, then, because in two weeks we'll be on vacation I'm, not sure when the first meeting is in January, we'll figure that out all right.

F

Bye guys have a good one, Thanks, okay,.

I

You.

I

You.
youtube image
From YouTube: CNCF Serverless Working Group 2019-12-5

Description

Join us for Kubernetes Forums Bengaluru and Delhi - learn more at kubecon.io

Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects

CNCF Serverless Working Group 2019-12-5