VMware Contour Community Meetings, 4 Aug 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Contour Community Meeting - August 4, 2020

Description

August 4, 2020
News
Contour CVE - Ingress data plane (Envoy deployment) is vulnerable to DOS
What have we been working on?
Office Hours this Thursday!
https://github.com/projectcontour/community/wiki/Office-Hours
New distribution lists
Discussion
Renaming master to main once Github adds tooling for that
Move to two reviewers per PR
Endpoints Slice Support
ExtensionService for Auth support
Next week
Move to Envoy go-control-plane: Some discussion around how to handle Endpoints
Finalize discussion around changing the number of reviewers for PRs.

A

Good morning, good afternoon, good evening, everyone and welcome to this episode of the contour community meeting, as you can see here on my screen um today is august. 4Th 2020 we've got some news for you, we're going to talk about what we've been working on and then move into some discussion topics.

A

So, let's get to it I'll share my screen, so y'all can see.

B

Yeah well uh all right. First up is the news um so yeah we have. We have had our first uh cbe. um The uh envoy deployment um had a vulnerability. uh If you could reach the uh any of the node networks, then you could cause envoy to shut down. um So theoretically you could take the entire. um You could take the entire onboard deployment offline and uh stop all the english traffic to the cluster, which is bad so thus we've. um So we have our first cve. um Luckily, this was a relatively straightforward fix.

B

uh Steve got the fix in pretty quickly uh and one point just before the 1.7 release, so we didn't even need to issue a patch release, um so the timing worked out really well um yeah. All the details are in the um are in the vulnerability thing in there and um we also got to try out the uh the vulnerability process and some of the new stuff that we've had since uh going to the city going to cncf um on a relatively, not too ridiculously scary, cbe for our first one. So lucky all round.

C

And this just means that your deployment manifest will look a little different uh if you're utilizing the shutdown manager. So we moved the hook from an http handler to an exec handler and that's how we've mitigated the the issue. So it's the endpoint, which does the shutdown is no longer exposed.

C

Only the kubelet can call the the endpoint directly or the um the binary. So that's so if you are not following along with our releases and doing your own thing, just note that that's a different, a different change.

A

Awesome. Thank you. Nick um any questions, comments on the the cbe here or the information within.

A

All right uh moving on to what have we been working on, so this is more what we uh will be doing this week uh so later this week, we'll have another contour office hours, so uh steve sloco will be leaving that if you have any questions regarding contributing to contour or setting up contour or administering contour, or what have you please join it's going to be at 1, pm eastern and go on for about 2 hours, so yeah, please join us and uh yeah we'll have some fun.

A

The other thing uh that is new here is that we have some new distribution lists. uh You should all have gotten emails. I think last week from michael michael asking you to join the cncf contour mailing list, so yeah, please do that since we're going to retire the google group there any questions.

D

Comments, oh just a comment um you might want to make the day before and on the morning before I just drop a note about office hours into the slack chat. That'd be great yep.

A

That's the plan cool thanks, janice thanks james.

A

um Steve while you're here do, you have any um updates on the topics for the office hours next uh this week.

C

So I was just looking up, I think, on our schedule. We had blue green deployments and canary deployments. That was on that list of things that we came up with a few weeks ago. That's out in the uh I can stick it in the notes right there um office hours here, yoink.

A

C

That's what we set up, we didn't really do the stuff. Last time we talked about um for the last one, which is totally fine. We ended up going down some routes as to how contours built and how you know we get from from watching objects and kubernetes to getting it things into. You know the the graph that we build and then out to envoy we kind of went through some of those topics. So um again we can.

C

We can keep on schedule or go back and do whatever, but that was our initial thought that we were going to talk about. Should no one else have anything else. They want to talk about awesome. Thank you, yeah, but again the whole. The goal is it to have folks come chat, so those are just uh filler items to fill time. Should we need it? So please come by no means, that's that has to be the schedule. So come chat about whatever we can. We can talk about it.

A

Awesome thanks any questions, comments.

A

All right uh moving into the discussion items, who has the first one.

B

That's me, um so I think everyone should have noticed that lots of people are talking about uh renaming their mainline development branch from master domain. uh I propose that we do that as soon as github's tooling uh renders it practicable. um Github have uh issued a statement, saying hey you unless you're already doing something like this, you probably should wait until we we're going to add, make this whole process a lot easier right now. um Renaming master domain is 100 possible on any git repo.

B

Obviously, but when you use github, it basically means that all of the open pls will be closed and a couple of other sort of sub-optimal side effects. um Github have issued a statement that said that they're gonna work on making something that will make this easier for you. That should be out in a few months. So I just wanted to register that. I I think we should do this. I think it's pretty unambiguous. We should do it, there's!

B

No, um the only the only cost that I see is if people are consuming master, um which they shouldn't be really. If you're consuming contour as a dependency, you should be using a version tag.

B

If you're consuming a brand like a docker image, you should really be using a tagged, docker image, not master and all the other reasons, all the other ways that I can think of. It's kind of you shouldn't really be doing it anyway. um Does anyone else have any thoughts.

D

My main thought is for the branches. We should do what everyone else in the open source development community is doing. So I think that's consistent with your.

A

Plan what what's the timeline that github talked about there? um I.

D

A

It was like they're gonna, have initial support for some some pieces in september or something and then full support for for a move in, like october november.

B

Something like that. Yes, um sorry, I actually linked that they linked their thing in the issue, but not on the back md.

B

Just says later this year,.

A

Yep perfect all right.

B

Thanks, yeah no worries, um so I think I think it probably is worth waiting um for for that. um You know as much as I would like to have this cleared away and be using more inclusive language today.

B

um You know, I think that it's better to wait to be able to do this in a reasonably straightforward way and not break lots of stuff um yeah yeah as much as I just like having to do it.

B

So I I uh in the ticket that uh that steve currently added to this uh discussion item uh you can see you know I did go through and have a look at what would be involved, and it is, you know possible, but yeah, but the it closes. The fact that it closes any outstanding pr's is pretty tricky because we have a lot of pr's in flight at any one time.

B

Well, not a lot, but eight is enough to that. It would be tricky to coordinate so yeah. um If no one has any other objections, then I'm gonna sort of mark this down. As we talked to, we talked about it on the community meeting and there were no significant objections um and put that on the issue um and leave that open for comment for from now on. um Like I said, I don't think that uh I think that we need to wait um for that one.

B

I think there are other um inclusive language stuff we can do um michael mentions there running the I'm, not sure if it's veil or valet uh tool to um yeah I can see, I can see a case for it being either so um yeah, either the english word veil or the latin word valley, so um yeah, um but yeah so yeah. I I think, there's probably a case to have that done. Asap um and just update this ticket with those details.

A

So um for that part, uh steve uh late last week I created a um just a test repo. Essentially so we can go through um the the docs here, so I can show you how that works. uh If you want, we can do that tomorrow.

A

I didn't get a lot of hits, so it wouldn't be a lot to to change here.

C

Yeah, that's fine. Let me know we can work on that cool.

A

B

So um who's has moved to two reviewers.

C

Yeah, so I added this um so it was, it was more of a. I was chatting with with steve chris who's, one of our new uh maintainers in the project, and he worked on valero previously and one of the things that valero uses is. They have two reviewers on evpr to get more eyes and stuff on uncertain changes.

C

So it was just an idea and a thought of you know: should we have more more than one person reviewing just eliminate issues of you know, folks, reviewing and asking for changes and someone else approves it and it gets merged without fixing those other things um or not. You know, as we work u.s australia distributed that sort of thing. You know.

B

Yeah I mean, I think, right now, there's a there is a risk like there's two sides, there's two things here: one uh there is a risk that we that we are not like that we you know, because we've got two people in each time zone. um You know it's easy for people in the other timezone to miss things, because one of us didn't review it, um and so that is a good advantage of having uh two reviews per pr. Also, it's probably better. um We've got now that we've got um four four maintainers.

B

Then um two two reviewers is kind of effectively quorum. uh So that's good! um I yeah I mean the downside is that it'll take longer. It means that the fact that it crosses a time zone means that every pr will take at least sort of 24 hours to to merge. Probably so you know, that's the downside, I think it's probably worth the trade-off, but um you know that's. This is not just a made decision, uh james steve, for your thoughts and everyone else, of course, but yeah maintenance. First, that's all.

C

Yeah, I see both sides of it. I think I think there are some nice benefits to it to having that extra set of eyes on things um just I just it came out recently, just because there were some things that we got merged and someone else came back later. I was like, oh what about this. We forgot this. Did this thing wrong?

C

You know, and that's obviously going to happen just because we're human and mistakes happen, but uh it was just you know, thoughts and I guess steve's- not steve chris- isn't here to to throw his scents in either. So maybe james, you can give us your thoughts and then we can maybe push it to next week or the week after when everyone's here again to discuss fully yeah yeah.

D

I've had a couple of cents, so normally, when I see someone's picked up a review I'll back off reviewing because um as a as a contributor, it's it can be frustrating having two reviewers tell you either the same thing or two reviewers. Tell you completely different things. um So having multiple reviewers at the same time is is not a great experience.

D

I think, from the team overall point of view, I think, having two reviewers. I think that would be a win and I think I think that's a good idea. um It's. What I would like to think about, though, is um having a bit more structure around like which two reviewers, so since I've been on the team, like the general practice, seems to have been just to tag everybody as a reviewer, and you kind of just hope that someone will pick it up.

D

Maybe we want to add. Maybe we want to kind of experiment with um a bit more convention around that and say: okay. Well, if, if we're going to have, if we have a two reviewer policy, then maybe we just explicitly tagged the two reviewers or um we have some way to flag. We have some kind of convention that we use to flag to say like I want I'm looking for. I need that.

D

I need to I needed some reviewers on this, so I just wanted to get some. I just think we should, I think so in general, yeah two reviewers. um I think that's a solid improvement on board. um I just want to figure out how to get the two reviewers and which two yeah. I think that's a good point.

C

Yeah yeah, I don't know if a bot or anything would help randomly sign, or I don't know it's hard to there's only four right now. Only four of us, you know to date so yeah one person.

D

I mean what one one one from each time zone yeah. I I think that's good, because I think that kind of is that's like a forcing function that um forces us to communicate with each other, which is good. It's good to have those kind of binding ties.

B

Yeah great um people who haven't talked already on this one, any thoughts.

A

So um one thing that actually came up in the community meeting today for valero is that the um uh the team right now um because they they have this set up and, of course, you you can always override it right if need be, but right now they they have. um Some team members are on pto. uh So that means that if one of the maintainers puts in a pr and gets reviewed by a another maintainer, they don't have another maintainer, a third maintainer to actually review it.

A

So just something to think about. I know we don't usually have um pto during the same time or we're offline during the same time, but it it can be worthwhile to have some language in there saying hey when need be. We can override this if a cve comes out or if something really crucial comes in, and we need to take care of that absolutely we can override it, but per like a standard to have two reviewers just to make sure it's reviewed by more than just one. I think it's fine.

D

Get more maintainers.

B

I mean one way of doing that. There's also another thing that we absolutely have to do anyway. So yes, uh so it is a good voicing function to help us do that too I mean maintainers. Do get special cow powers right to uh to push the you know bypass all the checks button, but we all try not to use that um without a very good reason.

A

B

Yeah, uh okay cool, so I guess I'll call that one agreed for now.

D

So the next step, so the next step on there is for you, is to update the contributing documentation right.

B

Yeah yeah, so I think um yeah, so we need to so. uh Yes, we need an action to update the contributing go with those details.

B

I'm sorry so, uh let's, let's just be clear, though, have we do we do? We want to wait and talk to steve k about his thoughts on this before we say. Yes, we're definitely going to do it or are we going to go ahead and do it since he suggested it, and we all agree with him.

D

I think we should confirm, with steve k, yeah.

C

Okay, yeah and that's so much that he suggested it was more of a us talking and passing about his last project. So, okay.

B

Okay, so I think okay, so let's uh let's put this one, let's put that one back on uh the agenda again for next office hours, uh uh so next to community meeting and we'll um and then we can have someone uh pick up the pick up there.

D

Okay, so so one more the one last thing about, if we do this policy does, that is this going to be for all project, contour, repos or just contour contour.

B

That might that is a good point, um since uh yeah integration, tester and ir to proxy currently pretty much have a single maintainer each really, although everyone has permissions, uh you know james is the only one who really does any integration tester, I'm the only one who does any work on. I had a proxy, so uh you know yes, that is a very good question that I don't have an answer to right now.

D

Yeah and I have a strong opinion, yeah.

A

Yeah, I I just think for ancillary projects uh that are supporting. uh I think it's fine to with go from from this.

B

Yeah, I think so too, but but let's have a think episode of thing about it and then, when we talk about it again, cool, okay, uh so inputs. I support uh thank you for uh for working on on a branch for this yeah. That's awesome, yeah! Thank you, yeah, I'm sorry uh as I I commented there just so that we would have a com type record of it. um I think that we've got some there's some. You know with the control, plane, work and also the um and also the external work.

B

It looks like they're all sort of getting a little bit tangled up on um some of the ways that we deal with eds and cds and the endpoints translator and some other stuff. So I think it's probably, although you've done a great job of getting it, getting it ready with what we've got right now.

B

I suspect it may actually need a substantial rewrite in the very near future, because we're gonna we're probably gonna poke at some of those internals um for regular endpoints um in one way or another. um So I think um we might need you to hold off on on much more on that for now, which is a sucky answer, and I'm sorry um but uh yeah, um the the other thing.

B

The thing that I would like to see, though, is that when we are ready to do endpoint slice that we do apply our dynamic type detection rather than um rather than like specific feature flags for contour uh andrew you are here. So I can ask you um the what I remember about endpoint slice is when you, when it's available the details from one are copied into the other. Pretty much is that am I right.

E

Yeah so today, if you um well like, if you were to pull in a 118 or 119 cluster, um the endpoint slice objects, there's a matching. Endpoint slice object for endpoints already, so it's up to the implementer to read one or the other.

B

Right, okay, so um the uh and endpoint slice is currently beta in 118 and 119.. Is that right.

E

Yeah, it's it's beta right now. um I I s. I heard I think I heard rob say that they're pushing for ga in 119, but I need to double check that right.

B

Okay, so I mean realistically, we don't need to worry too much about this object, only being beta, it's not gonna. Probably it's not gonna change very much more before it's ga. Is that yeah? I think so, okay right.

B

So what that tells me, then, is that um we could pretty easily use a similar sort of type detection logic to what we've done with the extension service and other crds, where, if we detect that that it's enabled in the cluster that is present in the cluster, we just use it and we stop using the old endpoint one um I mean there there is. That does mean that there's a version boundary break.

B

um You know where we might be running code that has not been tested as much but yeah. We need to cover that. I think with tests.

B

I really like us to move towards that being the pattern for supporting new kinds that that we that basically, if the kind isn't available is available, we use it uh we'll or we inform on it. um Maybe we have a feature flag, that it doesn't that we don't that we use it or not, but we should always. If it's present, we should always be running the informer for it and and soaking in the data, but then maybe the actual informants for it.

B

Don't do anything um so that pattern is then useful for um endpoint slice for the service api university ids that the project contour wants to add um and all those sort of things, and then we don't have to have a bunch of feature flags we'll just you know enable whether this kind is available or not, and it also lets old types sort of fall away as as they fall out of support. Pretty naturally so example, there is like uh extensions extensions v1b1 ingress would be would have been if we had this earlier.

B

We wouldn't have to fuss around so much with that, because you use the storage version and whatever the api server gives. You is what you get um it's sort of. That's the ideal that I would like to aim for um thoughts on that anymore, steve. You.

C

Yeah, that's fine. I mean that was the reason I wanted to get these bits kind of discussed. First just so, we um had some guidance as to before we hit to the pr stage of.

D

Having all these things.

C

Set up quickly, so it wasn't like here's a bunch of work and then we go hey change all these things. You know, so um that was that yeah just getting those bits. Those bits worked out um in terms of integration yeah. I don't know when I know some folks will disable beta features in their clusters because until they hit ga, but I think that, given your the idea of using the detection, that should still work if someone's disabled, because it just won't be there, so I think that that still holds true.

C

So that's that's a great way to do it.

E

Yeah, I also agree that um yeah, it probably doesn't hurt to like watch endpoint slice, but there I definitely think there's there should be a gate for like yeah, like switching the actual um endpoint slight uh endpoint like what which resource you read um yeah. I think there needs to be a gate for that, because if you just watch endpoint slice first and there's gonna be big changes in 118 and 119 on that right. Okay,.

B

Okay, okay, so yeah, so so it's probably so probably better for this particular one, it's probably better to to use the um kind detection to detect whether or not we add an info for it, but then have our feature gate um in contour that detects whether or not we use endpoint or endpoints slice for actually generating the endpoints, and that is, but that is a an endpoint, an endpoint spy specific thing, not a general thing. So the general thing should be.

B

We don't add, we don't add flags to add kinds, but we do, but we may add flags to flip behaviors based on coins. Is that that's probably the way? I always think so. Does that sound reasonable to everyone.

D

Yeah, at least for endpoints. The way I see that working is that endpoint and endpoint slice are two equivalent data sources and you you use one or the other, but they both feed into the same fit the same subsystem, yep yeah, yeah,.

E

Sorry yeah in future releases um they actually made divert diverge a bit in terms of functionality, so um there's a pr open right now that actually includes endpoints. So endpoint slice is gonna start, including um the set of terminating pods um right now like if a pod is terminating. The end point like endpoints doesn't include at all, but endpoint slices gonna start, including a terminating condition in that. So things.

B

Like that, that's actually that's actually might also be useful for us in terms of being able to do separate stuff with endpoints that are terminating. um So if we want envoy to do different thing to drain connections to specific endpoints or something like that, I can't remember the exact mechanisms that are in vds and cds and stuff like that in envoys api. But having that extra bit of data available of these endpoints are should not be accepting traffic anymore is you know they might still be healthy, but we should actually start draining them.

B

That's that would be useful to be able to tell envoy that at some point, um so that would be another good reason for us to move to endpoint slices as we can um to be able to do that. So hope. That's another way that we could address some of the problems that say the canadian folks have seen about um you know about 503s and stuff, like that, where the endpoints are new, they might be healthy in one way, but they're not healthy enough to actually serve the traffic or vice versa.

B

um So there's a lot of stuff: we've got to do there about mitigating mitigating churn.

D

B

And you know, there's a um as dave always used to say, there's a there's a bit of a slider between how fast you respond to endpoints going and the risk of the endpoint not being valid, because you haven't finished, checking that it's valid yet and we've tended to to slide towards the responding as fast as possible in the past. But the indications are that some people are running big enough deployments.

D

B

That's a problem so anyway, that's that is a thing that um yeah uh I and the other maintainers would like to have a bit of a chat about to to sort of talk about some directional stuff there um and come back to the community um in the community meeting about that next week. um Yeah so, and I think that probably slides actually into some of the stuff that we're talking about with the extension service for all support, doesn't change.

D

um Yeah, what what.

B

So I think, I think, sorry so, basically, I think we're just um you know. I think this is just. uh This is a bit of a heads up, that the way that we're thinking about doing external auth is by adding a new crd, which is uh extension service, to allow you to configure an extra envoy service in an extensible way. That's useful, not only for external auth, but for other things, like logging, red, limiting and so on. um We, this is a thing that we're going to need to look for a lot of different onboard.

D

B

And so we need to build out a way to do it in a reusable and sustainable way. That means that you don't need to learn seven different ways to specify the thing you need to connect to for some third party for some extra third service between contour and envoy, and something else does that summarize it james.

D

Yeah yeah pretty much so um I think steve was trying to explain something to me and I was being a bit dense, um but I read this: I read the. um I just realized that the issue, one one, nine- um that he references- covers some of the issues that I've run into here. So this is one. This is something where um the way we deal with endpoints needs to be a lot more sophisticated.

D

Currently currently, contour has you know a kind of a hard-coded notion that a set of endpoints is a cluster but to implement to implement extension service. uh We really need to be able to say that a set of endpoints can be the um union of multiple kubernetes services.

D

B

A set of end points in the envoy sense, not a set of kubernetes endpoints correct. Yes,.

D

So envoy has a thing called a cluster, a cluster, a cluster load assignment, um and that contains the members of a service cluster. So currently envoy builds those one-to-one with kubernetes services.

D

um So we need to make envoy's notion of that of more sophisticated, because the envoy api is there's the envoy apis want to deal with things in a way.

D

The other apis for extensions want to deal with things as one cluster, whereas the envoy apis for http are fine with dealing things dealing with multiple clusters so basically running into a whole. Bunch of um you know, modeling mismatches.

B

Yeah, so I guess to to preempt one of the things that I wanted to talk about in the next community meeting. um I feel like we've as we've started. We've started working on adding some much bigger features into contour than we've done in the past.

B

um We've also been working on adding a lot more configurability, uh and I think that what we're finding as we do, that is we're starting to run up against uh limitations of the way that we've originally built contour, you know, contour was originally built to be very slim, um and so it made a lot of you know, opinionated choices that flowed all the way down very deep into the way the code was designed, um and so now, as we're trying to do things extended a bit more we're sort of running up against some of the limitations of that, and so that's why I'd like to have.

B

You know we're going to have some sort of maintainable level chats to just you know, get make sure that we're all in the same space about where we think about this stuff and then come back to the community, with some of the things that we're going to change to to hopefully free up some of this stuff and to make it easier for people who haven't been working on this for a year to uh to actually contribute to some of these things uh right now.

B

It's there's a bit of a mess in the sense that you, in the sense that any organically going project has a bit of a mess, um and so where things have been added onto other things- and you know you know this is this- is the time when we're gonna have to.

B

We may have to slow down for a minute and address some protected and remove some craft to uh you know to be able to go faster later, and I think the the work around the go control plan has really sort of uh thrown up a lot of that thrown up a lot of that stuff that that there are places where we just have impedance mismatches between the way that go control plane wants to do things.

B

The way contour does things, um some of which are for good reasons, and some of which are just historical and so we've got. We've got a bit of work to do, to identify some of that stuff and um and do that, and I think we want- we need to do this in a higher bandwidth way than github tickets at the moment.

B

So um so we're going to do a little bit of chatting first and then, uh hopefully we might be able to talk more in like an office hours or something like that about where we're at on that. um You know next week or the week after.

B

So that's uh that's! That was in the uh yeah, so that was one of the things that yeah I wanted to mark down for next week. So great thanks for adding that. Whoever added that into the end of the agenda appreciate it.

D

I was going to editorialize a little bit about, I guess, contour history. I think it occurred to me the other day that um you know configurability, there's this there's a slider between configurability being configurable and being opinionated right, and I think the slider changes where, as you go up and down the stack, so if you're further down, if you're down low in the stack, you need to be configurable, you can't afford to be opinionated and, as you go up to higher and higher levels of abstraction, you're, more and more opinionated right.

D

So, as you go up to like my custom, my businesses custom platform as a service which is uniquely bespokely tailored to my business you're like really opinionated, but you need to build that thing on things that are configurable, so I think ingress over time is changing its position in the stack right so ingress three years ago, probably would have felt felt like it was really high up in the stack. It's like an opinionated thing.

D

um Today, people are building that people are assuming ingress and people are saying. Well, ingress, isn't what I want to use. I want to use something that consumes ingress, so ingress is like kind of getting pushed down in the stack and that change in your location in in people's development. Stacks kind of forces changes. It changes everyone's expectations of of your project right, so, whereas before were opinionated- and it was like- that's a really good opinion. We really like that opinion um now they're like well.

D

I need you to be configurable because now, instead of the top of my stack you're like three levels down- and I need like 16 16 different knobs from you- and so I wonder how much that change in that kind of ecos. That kind of movement in the ecosystem has changed the way people think about projects like contour.

B

um Yeah I tend to agree.

B

I think that when contour was supposed to build a lot of you know a lot of a lot of the ingress usage was you know, please expose my service and you know, and that was it so they were people didn't people just wanted it to work and didn't need a lot of things, but as people have started actually doing this more for real all of a sudden, it turns out that yeah, like the proxy, is a great place to do lots of fix up stuff that you can't do in services that you can't control you know and if you've got some busted service, that's three years old, that everyone who's responsible has left the company.

B

But you need to keep it running.

B

While you build something new, then guess what sometimes someone's got to fix it, and if the people, if the service can't fix it, that that you know that heads straight to the infrastructure team who controls the proxy um and you know they and the infrastructure team who controls the proxy, are one of our key users they're the cluster administrator, um and so we need to make sure that we're serving them as well as we're serving the application developer, who actually owns the the app that it needs to be exposed of iron ingress of some sort, whether that's an ingress document or whatever document you're.

B

Actually using do it. um So I think that uh yeah, that's um and that is uh yeah a really useful way to think about it. James. I do think we've also run quite a bit over time, though, um and so we probably should consider finishing up unless anyone else has anything urgent that they would like to talk about.

A

I just posted a link in the chat window to issue 2287 and we don't necessarily have to talk about it now, but yeah.

E

A

Would like to discuss this um since service apis, uh we're going to cut a release here soon, I'd like to start kind of breaking down what work needs to be done so that myself and others can start getting involved.

B

Yep cool, um I think uh uh you um you've done some work with doing a test implementation of those service apis with nginx. Am I correct.

F

B

Yeah cool, so so we've got so. Zion is currently for like a week right or something still interning at vmware, um yeah.

F

Yeah, actually, my internship will end this friday. Okay,.

F

Sorry, yes, of course I can. I still have uh one month for my summer break before I start the first semester, so please uh feel free to contact me and I will be very happy to stay in the community.

B

Excellent, so yeah, so, given that you've already done some work, uh doing that I would love for you. I would love for contour to really get ahead of the game here and and get get the actual behavior implemented. um Yeah. I haven't been able to be as involved as I would have liked um in doing that, but yeah thanks daniel. uh I we should definitely add that to next uh next. The next meeting agenda.

F

Yeah sounds good.

B

Okay, well, I think yeah. We are way over time, um thanks for that, and uh we will talk about that one next week, thanks everybody. Thank you. Thank you. Everyone have a good one. Bye, bye.