Good evening, everyone. Welcome to the Bill of Justice Junction Trustee meeting for Tuesday, August 13th. I'll call the meeting to order. Please join me for the Pledge of Allegiance. The Pledge of Allegiance is to the flag of the United States of America, the Institute of Public, for which it stands, one nation under God, indivisible, with liberty and justice for all. All right. Mr. Manager, do we have any agenda additions or changes tonight? Mr. President, we do not. Okay. So hearing none, we don't need to approve the agenda. It's already been done. Moving forward to the public to be heard. So now is the point in time of the meeting where if there's somebody in the public who would like to speak to something that is not on the agenda, now would be a time to do so. If you have something that's on the agenda, please wait until the time and we'll make sure we have time for that. Does anybody from the public have anything? Okay. Seeing none, we shall move forward to the public hearing. So I will open the public hearing for the final public hearing on the proposed amendments to and re-adoption of the Village of Estates Junction's comprehensive plan, the proposed Essex Community Enhanced Energy Plan. So for this one, I'm not sure if Robin, if Melanie, if somebody would like to come on up. Both? Two for one. Thank you for being here. So this is the last hearing for a Village of Estates Junction's comprehensive plan, which includes the Essex Community Enhanced Energy Plan. Because assuming it's a Village of Estates Junction's comprehensive plan, it gives you substantial deference. Yes, at the Public Intelligence Commission. So we thought that was important rather than having to establish a local which would give us substantial deference. I believe the public hearing is on July 12th. So we're hopeful there were a few changes made. Yes. So at the last public hearing. July 23rd. Yes, the trustees agreed to make the updates to two paragraphs in the wastewater section, and those have been included in the draft. So that was the only comments that we heard during the public hearing period, and haven't heard any comments in this next iteration of the public hearing period. What are the next steps after tonight? Just so we, just plainly. So this goes to the RPC, and we, you know, just sort of go over that for everybody too. It's really gone to the Planning Advisory Committee of the RPC. They have a few comments. And those comments have been addressed in earlier drafts of the Comprehensive Plan, and they've made a recommendation to the CCRPC Board to consider the plan for adoption. And so at the September CCRPC Board meeting, the Board will consider the plan for... Could you CCRPC for the people who may not know what the happened? Oh, sorry. Yes, the Chittenden County Regional Planning Commission Board. So the Planning Advisory Committee, which is a subcommittee of the Chittenden County Regional Planning Commission Board, has made a recommendation to the Board to consider it for adoption at their September Board meeting. And the Planning Advisory Committee has made a call to directors of planning for the municipality of Chittenden County. And they have, I mean, the PAC, which is the Planning Advisory Committee, has also recommended a determination of energy compliance, which the Chittenden County Regional Planning Commission gives to any enhanced energy plan. So that will, too, be up on the Regional Planning Commission Board agenda in September. Thanks. Sorry to make your life difficult. No, that's okay. I appreciate your nudge. Every once in a while, people say, yeah, you said all those letters. Right. We don't know what you're talking about. There's a lot of letters. And the point of it going to the CCRPC, now that we know what that stands for, is to help make sure that there's coordination among the communities within the county, correct? And that it's not one community going rogue doing its own thing while others are having more of a cohesive plan. Yes. Correct? Yes, the Chittenden County Regional Planning Commission looks at the plan and evaluates it against state statutes, the planning elements to make sure that the municipality is following the planning elements. As well as the energy planning requirements as determined by the Department of Public Service. And the CCRPC staff have reviewed this as well as the county advisory committee. So it's had two or three levels of review already. And it's passed all the things. Not to mention the public hearing that happened at the Village Planning Commission. No, it's not true. Just maybe for the audience, what are the main highlights of what got touched on and their importance? So a few areas of the plan needed to be updated to meet state statute. So since the plan was last adopted in, I guess it was 2000, maybe it was 2016. Sorry, I'm getting my dates wrong. But the municipality needed to add a flood resiliency plan and add language from reporters to be consistent with the agency of natural resources, flood resiliency requirements. The municipality also needed to be consistent with Act 171 talking about forest integrity and strengthening the language, talking about the ecological importance of areas identified in the Vermont Conservation Design Project. And that's referenced in the natural resources section. There's also a flood resiliency section in the document itself. All the data has been updated extensively. Any local land use or transportation plans that has been developed since the last approval of the plan that has been incorporated by reference, mainly talking about the Crescent Connector and Design Five Corners. All the maps have been updated. So the focus has been updating the data and bringing the demand into compliance with recent state statutes. And also developing the Enhanced Energy Plan for Ascension and Essex Town so that the village can get substantial difference at the Public Utilities Commission. Do you have anything to add, Robin? I think it's also important we adopted tonight because the existing plan expires first. Great. So, with this being the final public hearing, this is the last chance that the public and trustees, we have an opportunity to provide input on the comprehensive plan. So again, I'll just open it up. Is there anybody else in the public who would like to speak to the comprehensive plan? Any concerns? Okay. Trustees as well to exclude. Okay. One change, if I could ask, do you want to wait for it, Lynn? Okay. So the one change I would ask for is that I see somebody put me as the trustee and then the left me in as Planning Commission. I take me out of Planning Commission just to create, you know, avoid any confusion that I did both of those things at the same time. And because it's as of the time we adopted. It says. Hopefully, if I can change. Yeah, that's not a substantial change. It's not going to require you to. I didn't think so. I didn't think so. Thank you. I'm fine with that friendly change. So hearing no other comments, questions or concerns, I would now close the public hearing on the comprehensive plan. And that will move us on to business item 6A where we will have an opportunity to adopt the Bill of Justice Junction Copy as a Plan, the Essex Community Enhance Energy Plan. Okay, so I will make a motion and I think I don't know if we have two separate motions that we adopt. Do we need to adopt the amendments to the energy plan or by just adopting the municipal plan as amended? Do we have a sense of that? I would say the municipal plan is a job because the energy plan is incorporated. I didn't know if we had to make two motions to move that we adopt the municipal plan which includes the Essex Community Enhanced Energy Plan as presented at tonight's meeting. Second. Is there any further discussion? All those in favor, please signify by saying aye. Aye. Anybody opposed? Great. Thank you very much. Thank you both. Thank you for your time. Thank you. Thank you. And so we can now go on. Oh, we also need to thank the planning commissioners who have spent a fair amount of time on this as well. And also thank the planning commissioners and those from the public who came out to help inform the process. So moving forward to 6B, the Village Road and Bridge Standards. Greg's not here, so I'm going to assume that that's what you teach. Sure. We'll move to that. Very much an a lot less fanfare than the Village Comprehensive Plan at an annual basis. The state wants you to adopt the road standards. The town works with the village to help put these together and they're in your agenda for approval. The couple things a lot of their changes were mainly in unpaved road areas class 4 and where FEMA comes in when you have a storm or a event. If it gets to a classification where there is disaster relief funds you submit a lot of paperwork to the state who then goes on to FEMA but you have to be in compliance with your road standards to be eligible for those funds. So this is another reason why we go through this process every year and make sure that our road standards meet those requirements for the village that's not terribly hard because about 99% of your roads if not 100% are paved. I was noticing in the document itself that it was handed in that there are no roads in the village. So I will make a motion that we adopt and sign the new road and bridge standards. Second. Dan got it. Alright, so any further discussion on the motion? All those in favor, please signify by saying aye. Aye. So now we can move along to business item 16, the approval use of the infographic about the infomerger. I can do this if you want. Would that be good? I wasn't sure who was doing this. I know I'm doing the governance subcommittee update. Yeah, I mean I don't but if you want to take it away. The governance as part of the public outreach we're doing the focus groups it was felt that if there was something which is going to sound odd that is easier for people to understand, you know, people, one of the ideas of this focus group and the people that were selected is we weren't looking for people with an extensive knowledge of local government, people that had served on boards. So they were looking for people that were interested in the community, interested in the topic, but they may want to have something handy for some of those questions. Then the idea of putting that together and trying to get in as much information into a one pager both sides was our task. This is what's before you. We've got two different things. We've got the infographic which is going to go on the website that Anne and Jan is working on. And then the focus group. Okay, so you're doing the focus group first. So this is in your packet. It went to the select board last week. They had made some corrections, some additions and changes to try to make sure that we're being more balanced with the presentation of what is at hand. And so in your packet you will see the edited version. And they would then go to the focus groups and I believe the first ones tomorrow night. One question is can you go over the intent? Is this to give to the focus group or is the intent for this to really be a one pager if you will? So that way people in the community can understand what this is. Well, first it's for the focus groups and then if the village and the town want this to go on their website, I mean you certainly... Right, I think the thing that's going to go to the focus groups is if you look down after the infographic you'll see municipal governments model options. Option one unified charter, option two. So it's just three boxes. Keep flipping down and you'll get to it in our agenda. Yeah, there you go. So this is the thing that's going to that the focus groups are going to have. And I only know this Evan because we, the government subcommittee, I'm going to be updating this. I may as well just combine the two. This is what we worked on initially and then it went to the boards for approval and some revision. And the idea was to really provide as simple as possible a stimulus for conversation. We're not trying to get specific answers. We're not trying to direct anybody towards a specific thing. We're just trying to stimulate the conversation around governance and potential merger. And so we had those three, those sort of personify the three options that we had governance options and then we broke it down. The boxes underneath it that talk about representation. Again, there's no correlation between the above three and the bottom three. Each one of those could be separate. But we're just trying to explain what's the difference graphically between at large versus a voting that might have two or more wards or districts and then some combination. If you don't mind if we can just pause on that one just to go with the infographic for now. Yeah, if you want to go with the infographic because I think the infographic is the thing. That's what's going on the website as well. And I think it's, I'm not sure if it's up there. I haven't seen if it's up there yet or not. I've not been on the site today. So we haven't seen it. So maybe it's not going yet. So the intent is that should the two boards approve of this, this is then a public facing document to talk about what is this process that we're talking about in Greater I6 2020? Right. So the select board discussed this. Yeah. And I understand that there were some requests. Did they make any changes? So the second one in your packet is with the changes. So there's two. So we're not going to use it. Not using the first one and looking at the second one. Unless we change that. Unless we change that. I'm going to mix them up. Were there any substantive changes? It looks more like they're just kind of changing the way things are laid out. Formatting issues versus... I think one of the things you'll note, well you could, we've added and puffed up a little bit more key challenges, which is taxation, governing board structure and elections, community identity. We moved some things around to be able to fit that in. That's on the cover page. Yep. I don't want to blow this up. Was there any discussion? Because it seems like there's a lot of... Not much on the back. Okay. There's a lot of folks coming into the process now. Or maybe a month ago and there will be some folks coming into the process three months from now. And the impression it seems that's left with them is that this is starting the minute they get into it. And that's understandable. But this has been going on for a long time. These governance meetings, these governing subcommittee meetings, the select board and trustees working together on this purposefully has been going on for a very long time. Oh yeah. And so it just seems to me looking at the timeline that, again, I realize having done this kind of work before, I'm not going to be very popular at suggesting this, but pushing it back to at least when the subcommittee was made, was formed so that folks know that there was a purposeful process to vet very many options and that trustees and the select can all describe what they thought it meant. Just at least saying that it didn't start in June and August for this summer. I agree. There is a little bullet point about that. The governance subcommittee was established in 2018. I mean, it's just not on the timeline. Yeah. So let's just totally agree. I agree. I think that's very important because it looks like it just jump-started all of the sun where it didn't really start in back in 2016 or 2017. And definitely 2017 will really get underway through last year. And I want to kind of pin it down. I mean this hasn't been going on for decades. There's various attempts have started and stopped. And this is starting up again. It's started up in full force. Right. So that's kind of good. Yeah. Because I know one of the questions that has come up is why are we doing this in the first place? And the meeting that we had back in, I believe it was 2018 at a previous select board configuration at that time where we went around the room and joined me. And we said, we all want one board. We want one community. And so to do that, we have to merge. So at that point in time, coming to an agreement of this is where we're going. Right, right. That fact and what you're talking about, it didn't just start a few weeks ago, but it hasn't been going on for a period of time. It does make a lot of sense. Yeah, that's a very good point. I think that's a very good point. So I mean, this is like, I think they're considering this as a work in progress. And they're looking for just exactly this kind of feedback. Okay. You know, they're building the skeleton, but they want the boards to be telling them what they expect to see and not to see. I think that's good feedback. The other thing I would say is that we've got some key challenges now, but after the focus groups, we may have other key challenges. We may have some new key challenges may arise that we've worked. We didn't think we're big deals, but maybe things on people's minds. So I would look to probably amend that as well. So we can consider this sort of a living document that will get updated for people. Right. So we'll have to keep versions, but you know. What do you think about saying that, I mean, do they want to put, so they haven't, she hasn't posted this yet? No. No. Okay. So the idea is do we, do we see misinformation here that we do want to post it and then we want to keep editing it, adding onto it, or do you want to just, do you want to say, let's not post it until we get it right? What should we do? I don't have a problem with it being a living document that is posted. And then if the boards agree to then change, we then change as conversations evolve. I would, go ahead, sorry. No, sorry. I just put a revised date on it too. So we know when, you know, and it makes it clear. Make sure the other ones are available. Yeah. But maybe before they post it, do what, do your suggestion, go back and get, you know, pin down the actual dates when we start really subject to police talking about this and extend that little, the little, it reminds me of like a board game. I want to roll the dice. No, I don't know. I'm sorry. Maybe that's silly, but. Hopefully there's no ladder. Yeah, yeah. All the way back to the beginning. Can we just make the change or ask the change we made and then go back to the government's son committee as opposed to coming back to both of us and then it can be posted? Because I think it's going to delay. So this is part of the problem. Trying to do something with 10 people is impossible. And public input, it's impossible. Somebody wants a little tweak, a little this, a little that. Can we all agree that merging two communities just isn't easy? And really cannot, everyone just cannot be happy. So I think one of the things that we would like is if you like this product and we make the one or two changes and get it going and we only change it because we really made an error. Something is not correct versus not quite the way somebody would think it should look. Personally, I hear what you're saying. In some ways, I would say that the timeline did start before June and August between 19. So with that one, yeah, I think that that would be something that I'd like to see changed. If you were only to look at this starting today, you would think, oh, they started this in June. How far could they possibly be? This has been going on for a few weeks. I can get you. Is there any discussion around the key benefits that you carry out in this level? One of the things we, what we did with this is we didn't want to get specific. These are just what was out there and also every time we tried to get specific, we get long. Yeah. And we just get rambling like me right now. And we just, I think some of that will get teased out much more in the coming stuff we're also going to do and started to do FAQs. And we're going to do more than just these outreach forums. We're going to go out to the public and do face-to-faces with people. You're still working on sort of honing in from the public. What are those key points and honing that into less ramble, more sizzle? Yeah. And the stuff that doesn't, stuff that's not positive or may not be positive to one segment of the community but is to the other. You just have to be honest about what it is, who gets affected, when you get affected, and how much you get affected if it costs money, and then what you get out of it. But that's the way this merger is going to have to be dealt with. I mean, you're going to, this is going to be on the website. It's going to be, if someone wants to go in, I think you probably, there's going to be some keywords that you went and there's going to be text and it's seven seven FAQs. So they can go more heavily into, this just is, just visually, there'll be a lot more information. And I think the plan is just to keep building more FAQs and other information as we go along. Our hope is by the time if you still agree that you want to do this vote in November 2020, by that time, hopefully a vast majority of people's questions will have been asked and answered. There may still be some things out there, but we've got a year and a couple months before that date. But that's all you have if you want to keep that date. Well, at the same time, one of the things I'd love about this is that it shows for one, when we talk about a merger plan, it isn't final. And that there is so much that is still unknown. So that's why we are really doing the public outreach at this point to make sure that we're going down the right path to our concerns. Let's learn from that. For the people at home, one of the main reasons for the outreach is while you all work at this and are here every two weeks and you have the benefit of the staff and the people at home don't. And while we think we know a lot about what they may want in this merger, we aren't 100% sure. So to go out to the public, do a survey, do focus groups, do a resurvey and then take all of that and still go out for more is the process of merger and a process of what should be in the document that people have to vote on and it is a new charter for the community and a charter being what was, you know, it's a legal document that sets the framework for the powers of that municipality. I will add one thing. If we look at this, you're going to have a dramatic change. If we stick to this plan, we say in November, December, probably more like December, develop a preferred governance model of the merger plan. Well, then you're going to really have to start focusing on the details of that specific plan and why it works and then there's probably going to be a whole big revision of this. So I think that's going to be a major thing. Just add my two cents and say developing the second resident survey by September we'll be lucky if we get that, if it's not in October, because it just seems to take a lot of time. But that's, we shoot for goals. Yeah, we shoot for goals, but that's, I think we need to stick to that, but I think that's going to be a big revision. Well, I think it's great that we have a governance subcommittee that there is. It is.  We also said getting the first survey out was going to be a huge challenge by the timeline that we set. Right. And we got it done, maybe by the skittiest of margins. We can do it, but I'll just go to see. But we also, we don't want to just we don't want to just meet a deadline to meet a deadline. We want a good product. Yeah. And that's why we hired KSV to get that good product. And I think, you know, in reading through their first survey and their results and the data that has been generated so far that we're still chewing on gave us a lot of insight and a lot of things to bring to the subcommittee and elsewhere. Okay. Questions, comments on service? Okay. So for a process standpoint, it sounds like are we not approving making the motion to approve the document today and wait until the changes are made or do you want to make the motion to approve it with the changes? I would like the latter and then leave it up to staff to fit it in. So someone wanted to make the motion to move the trustees authorized the use of the infographic grader S6 2020 answering your questions about the November 2020 merger vote during the focus groups about governance change. I'll second. I'll second. And that's going to that we understand that that includes the revisions. So we're going to do Raj's at our beginning of the bubble and then a revision date. That's fine. Great. So any other questions, comments and concerns in the motion? All those in favor please signify by saying aye. Great. Thank you. Thank you. And George do you want to continue where you left off? Continue where I left off and it's not very much. So I'll go to the other the other graphs with the one tax rate.  This is the specific information this goes to the focus groups so they can just sort of pictorily get a sense of what it is. One interesting thing I'll just draw as a sidelight we asked I said I really would like to see it would be helpful just looking at all this information. What are the populations of the two parts of the community? And it's interesting that we're both if you look at the representation options a little graphic we're both pushing 11,000. We're neck and neck to see who's going to reach 11,000 first. Which is more I thought we were both around 10 and a half so it's we've all right. The current tax structure of the show we wanted again people to get a sense of what when they look at their tax bill because we understand just from a lot of the questions we saw from the first survey people conflate school taxes, village taxes, town taxes, other things all into our bill. And we need to be able to we want to be able to help them distinguish between what the municipal government's control and what the school minister that's pretty much it. And so we went over this I think we had a lot of revisions so this is the document that's going to the focus groups. That's great. How are things going on the this committee with the increase in membership and first and second tier alternates? Well the new members have been you know they've added a lot you know I mean it's it's some of the original members I'm not sure who the new members are because they seem to it's sort of like a revolving seat I'm just kidding. It's been great so I mean I think we this was our last big push and to get this out the door and get this finalized and so now we're meeting again but the idea is well it's KSB will be there and they're going to give us the results the sort of summaries of the focus groups and we're going to take it from there so the next big step really is what I alluded to earlier was starting to work with them and the board in putting together this more comprehensive survey that we're going to try to get out in September and hopefully we'll get as big a response as not bigger on that. Did I miss anything Raj? Amber? Well you both you were on the left and I think that was I think you covered it because you went over all the things we did I was just trying to keep up with KSB's timelines Great. Yes I certainly appreciate the work it's totally has been a lot going into it and happy it's not happening at the board level We're taking way too long I'll add that As far as we understood the last communication we saw from KSB they had I believe they had all their slots filled Maybe you wanted to but I think they had last time we said they had 80 inquiries 60 slots Wow So it'll be interesting to see the result again two distinctly outside the village specifically inside and then two next And they're going to be done by They'll be done by the end of this week So I think it's early next week Sorry You can see we're trying to stay out of the process We don't even know what to say So just to be clear we are staying out of the process the governance of committee and staff had absolutely nothing to do with the selection of the people They went off of survey results the only restriction for KSB was based upon what the the joint board the joint board's direction no serving or former serving elected official They wanted people without direct influence on the other than that they made all the selections we haven't seen the list we have no idea who's going to correct there if we have anything else on the governance of committee good looking forward to the input though yes absolutely so we will go to item 6 yes sir sure what is the first focus group meeting what is the first focus group meeting I believe it's tomorrow or today or tomorrow it would be today at 6 o'clock you just approved the document you're supposed to be used at the focus group no I heard you say that the focus group document was the second one that I started telling I believe the text of the motion was approve this document for use at the focus group yes focus group is tonight the focus group got the second document that we talked about with the three governance structures before you approved it you have to approve it now I'm sorry so if it's is a concern that something is going to be used at the focus group that hadn't been approved yet my concern was it's okay I think because they got this document which was just approved but I would just point out that it's retroactive it's a little odd that we'd approve a document now to be used at a focus group taking place now and they got it in advance that's all thank you is there anything else they knew our method graphic is better okay so we will go on to 6e which we'll actually go back to this a little bit later on in the meeting we're going to have this in a deliberative session so we will now go on to set the agenda I'll move to agenda second any further discussion with agenda agenda so in the trustee's minutes melody the reading file is bronze bicycle friendly community very Indian brook specifically and I don't see any of brook mentioned at all so when I went back through I was thinking maybe we could put it in somewhere like line 141 ish this is at the joint meeting that's right it talks about reopen select boards and trustee agree the discussion needs to be scheduled about how to address off leashing in the local parks unless I am mistaken I think the only part we're talking about is India brook yeah so what we typically do is if there's a change to the minutes that we would like to have to state what we would like it to be so I guess my change would be discussion needs to be scheduled how to address off leashing at Indian brook could you state the number so it's 141 on the joint line 141 on the joint trustee select board meeting minutes is that I mean I'm open to suggestions I agree with exactly the same response I said boy we talked about it for about 15 or 20 minutes should we revisit the minutes and read through these later or these tapes we didn't solve anything I don't think we did I mean I don't think we concluded or solved anything but we did because I got a bunch of email about our discussion from Indian brook would be having another reporter and not having any minutes yeah well back to there was no action taking there was a lot of public comment and a lot of public thoughts on it there was no action so I think one of the things we have tried to do is not get verbatim minutes so if we could just have a comment that there was discussion and that there will be a future meeting on the topic that's really what is I totally understand that as somebody who used to take minutes we're not asking for verbatim but literally the words are not mentioned at all so that would be my change would be to add that piece so 143 I have after awfully strike in local parks and add Indian brook that's good sounds good did anybody have any other changes to it I don't have any other changes but I would like to ask if the materials from Sarah Quinn Lindsay about the tethering and dangerous dog statutes they said they left those but can we get those or did they not leave them the lady that left are you talking about the lady there was two so in the minutes itself it indicated that the woman who spoke about the dangerous dog statutes in other states that she was going to leave materials for us Lindsay who was the woman with the rescue she talked about leaving the anti-tethering law information for us and I didn't see either one of those so I didn't know if they had left them or not and staff could forward them to us good calls so would anybody like to make a motion to approve the consent agenda as amended I will make that motion that we approve the consent agenda as amended sir is there any further discussion all those in favor please signify by saying aye aye so going on to the reading 5 starting off with corn member comics I'm good nothing then going on down from that we shall enter into a deliberative session and a deliberative session is one in which we require privacy in order to speak with our attorney given some given a legal matter at this point in time we will take a brief recess so that way we can we're going to have some privacy so are we going to convene a public session after that after the deliberative session we are going to be making a how about then since to have to not have everybody leave if we want to go into the into the office and then we'll come back when we're done sure that way we shall return we are going to we already have a public action yes we are going to make an action yes thank you welcome back everybody thank you for waiting as we had the deliberative session with our attorney I'd like to ask this point in time not seeing Mr. Calange is here if Mr. Calange's attorney is here not seeing the attorney present just want to make sure to note that into the record so we have in front of us a request to delay the compensation hearing in discussing the compensation hearing the Mr. Calange's and the attorney have been well aware of the required appraisal for months in advance adequate time had been provided by the village and the only basis for the request really came down to a matter of costs not availability of experts not availability of people purely down to cost so at that matter and with no rebuttal from either Mr. Calange's or the attorney I personally would find that a delay would be due to the contestant's lack of a timely action and to not approve the continuance that has been requested of us my assumption is we need to make a formal motion to not approve of the great I will make a motion to not approve the request for a continuation to consider damages relative to the Crescent connector project second any questions any further conversation on the motion I will just agree that I don't see any compelling reason for all the reasons that you stated I think you stated it very clearly they knew an appraisal was going to be necessary and there's been lots of time and to get it done and it's not a matter that they can't get it done it's just a matter of the cost being more than they had anticipated so it's not compelling reason hearing no further comments all those in favor of the motion please signify by saying aye anybody post great hearing none the motion passes and we shall go to the end any further discussion aye anybody post thank you everybody thank you for waiting thank you


All right. Welcome to this talk. Houston, we've got a problem. How to debug your pipeline in Tecton. I am Vincent de Mistyre, Senior Principal Software Engineer at RELAT and I am one of the lead of the Tecton project. I also work at RELAT and I work on a lot of Tecton stuff on Tecton as well. And yeah, today we are going to talk about how to debug your pipeline in Tecton. All right. So let's go through the agenda. First we'll define a little bit what do we mean by debug? In debug what? Then we'll go rather quickly on what is Tecton in Tecton in another shell. Hopefully you know already a bit what is Tecton when going to this talk, but if you don't, this will be a really quick introduction to Tecton. Then we'll do a little bit of magic in Russian dolls, explaining how all this works. Then VBAP will do a demo and we'll finish with the next steps after this demo, after this work what will be the next steps. So first, debug what? So let's talk a little bit about debugging. So debugging is the process of identifying and removing errors from computer hardware and software. And in this case, we will be talking about debugging, but it will be in terms of pipelines and debugging pipelines themselves. So what do I mean by debugging pipelines and what are pipelines? So pipelines usually is a linear sequence of specialized modules used for pipelining. Basically, this means you do a task or an action, then an election, then an election, and some can be in sequence, some can be in parallel. There's a lot of types of pipeline, there's data pipeline, there's even pipeline, there's a lot of type of pipeline. In our context, in the context of this talk, we're mainly talking about CICG pipelines. And in our example, it's more accurately be useful in a continuous integration pipeline. But yeah, we will focus on the CICG pipelines, but this could probably apply to other type of pipeline that can be done inside Texan if we want to do. Yeah, so why would we ever want to debug our pipelines? Now, if there is a pipeline which works on your machine, but not on the CI, it's very hard to understand why it's not working on the CI because you would need to understand what is the environment the pipeline is running in. And that would be the CI environment and you would need to get access to the CI environment and understand this thing. So debugging pipelines could be helpful in this way where you just get access to the CI environment and figure out why it's not working on the CI. But then there are also times when it only runs on the CI and you can't run it on your machine because of resource constraints and you will have to debug your pipeline while it is running and go to a particular part of the pipeline and debug it there.  But there are better ways to debug pipelines and instead of doing it in this way and some CI tools allow you to debug pipelines while they are running and they provide great support for this. Some of these examples are so-called CI, which will do this very well. So getting inspiration from this, we in Tech Town figured that we could do this in Tech Town as well. So how would you debug pipelines? So this is kind of explaining what we will do in Tech Town and what other tools kind of do in some manner. So debugging pipeline, what do you want for it to do once, one first? You want to be able to pause the execution of your pipeline at demand, so anywhere if the user wants to, and or in case of a failure. So some steps or some action failed, I want to stop the execution there and be able to drop in. So we want to allow the user to drop in directly in the CI environment so it sees what files are there, what processes are running, anything really that could help them debug more what happened and why it failed and probably also re-execute some stuff in the context of the environment, the CI environment. And of course, once we allow the user to drop in the CI environment, we want to allow him to continue or break the flow. So if he feels like he knows what's happening, he fix it manually for this run and wants to see if there's anything else that will fail later, he can continue it with success and the pipeline continue running. Or if he knows how to fix it, he's pretty sure it's not gonna fail after, he can just go and fix it and thus he wants just to not consume too much resources and break the flow, finish the pipeline as it would have been without the debug. And how we will do this in Tecton, we'll dig a little bit more how we do this in Tecton, but this is based on TEP, the number 42, so TEP stands for Tecton Enhancement Proposal, and this TEP is about adding breakpoints on failure for steps inside a task run. This is focused on task run to start the work, but this TEP is gonna extend more and more as we go. So first, let's go quickly on what is Tecton for those who do not know what is Tecton or have a really general idea of it. If you do know Tecton very well, the next few minutes will probably be a little bit boring, but it's okay. So what is Tecton in a nutshell? Tecton is an open source project that aims to provide a set of standard and shareable components for building a Kubernetes-sized CICT system. This is governed by the Continuous Delivery Foundation, the CD Foundation, which is a kind of a cousin of the CNCF, and contributions are coming from literally everywhere in the world and lots of companies. Some of the most important ones are Google, Red Hat, CloudBees, IBM, Pivotal, and D2YQ. There's many, many more. It's a really highly active community right now. So in a nutshell, a little bit more. So Tecton allows you to write declarative pipelines with standard Kubernetes custom resource. This means we're using the exact same mechanism used for services, deployments, codes in Kubernetes, but to be able to declare pipelines. Everything runs into containers. So Tecton itself, the control plane, etc., are running inside containers. And any steps, any task, anything that you might do inside your pipeline will be running in containers, in Kubernetes. You can do almost whatever you want inside your pipeline, because as long as it runs into a container, it's going to run into pipeline. One example is you can build images using Kubernetes tools inside your task. You can use whatever tools you want, and then through parameters, and through results, and through resources, you can reuse what you just built somewhere else. So you can use image, build, icon, whatever you want. You can deploy to multiple platforms. So of course, you can deploy on Kubernetes. So anything like the Kubernetes pods, deployment services, serverless, etc., but you can literally deploy on anything as long as you have tools inside your containers allowing you to do that. One example that we have upstream is there is some task that allows you to create a Mac mini VM. I don't even know if it's a VM or not. Maybe it's a real one. Somewhere in the cloud, deploy something in there, run your tests, get back the results as everything is running into containers. You can do this. And it aims to provide a set of powerful user interface. Right now, we do have an official command line tool, an official dashboard, the command line tool being TKN. And yeah, let's dig a little bit more into the tecton concepts now. So there are a few concepts in tecton that really help to understand how the tecton pipeline itself works. So these will be step, task, pipeline, past run and pipeline run. And you couldn't think of these resources of two different kinds. The first one would be the definitions. Second would be the executions. Among the definitions, we've got task and pipeline, where a task is a list of steps that are sequentially in the same port. And each step is by itself running in a container. And a pipeline is a graph of tasks with inputs and outputs executed in a certain order. And a pipeline. And when we see a graph of tasks, we mean that these pipelines can be made of different tasks together. And these can be pre-existing tasks, new tasks that you can create right in the pipeline itself. And then you can just basically compose different tasks together to form a pipeline. And this really shows the composability of tecton itself when it comes to creating pipeline. And to run each of these tasks and pipeline to have these as reproducible as possible, you can just define these tasks and pipelines once and then run the equivalent run resources, which are that you have a task run for a task and you have a pipeline run for a pipeline. So if you want to run a task with certain parameters, you would basically create a task with a task run. And when you create this task, you can give any parameters that you want the task to run with. If there are some other parameters you would want to run the task in the future, you can do that as well. You just have to provide different parameters in that case. And the same is the case with pipeline run. You already have your pipeline with the tasks, which can run either in sequence or in parallel. And you just provide a pipeline run, which has all the inputs that are necessary for the pipeline. And then you can just run the pipeline run. And in this way, you can just keep testing your tasks and pipelines with different parameters. And you can compose different pipelines with multiple different tasks. And you never have to have to write different pipelines every time, even if you're using the same functionalities before. So Tecton is in this way very reproducible and composable. And it makes it easy for the users to just kind of get down and start making pipelines easily, if you have a certain set of tasks. And a lot of these tasks are present in the task catalog, so the user can just start building different pipelines. Okay, so let's look at what a pipeline looks like here. So you can see that there's a pipeline, and then there are four tasks over here. And the first task is running the first three steps, and each of these steps runs in a container of itself. Then the output is being passed to the next two tasks, which are running in parallel. And the second task, which is there, is sending its output as an input for the last task, which is there. And you can see that the first task is running by itself, second to in parallel, third one by itself. And this is just a definition of the pipeline, and the task that it's references or has defined and defined in the pipeline itself. So to run this pipeline, actually, you have to provide a pipeline run, and which sees that there's an execution of the pipeline, which creates task runs in itself to create each of these tasks, task runs and execute them. And before there were pipeline resources, and currently they are being deprecated, and they are replaced with inputs, other kind of inputs such as workspaces and parameters, workspaces, obviously, places where resources can be shared or data can be shared through volumes, and inputs can be given via parameters also. And these two concepts replace pipeline resources completely. Let's look at, let's now look at like what a task run actually looks like, because in this demo, and in this scenario, we are going to focus on how to debug a task. And in the future, we should be also able to debug a pipeline run, but for now, we'll only focus on a task. So let's talk about what a task actually looks like. Okay, so here in the task, we've got a spec, and there are steps which we can define in the task, and we are going to focus on this task, not this task in particular, but we're going to focus on tasks and task runs, and trying to debug them. In the future, we should also be able to debug pipelines, pipeline runs. So for now, we are going to look at this task and create a task run from this task, and I'm going to try and debug it. So let's actually understand what debugging looks like, and how we've gone ahead and implemented it. For that, we'll look at something called the Russian Doll entry point hack. And Vincent, you'd like to go ahead with it. Yeah, so let's dig a little bit about the Russian Doll debug. So we use the Russian Doll as a reference, mainly in reference to the talk that Christie Wilson and Jason Hall from Google did in 2019 in KubeCon, where they described a little bit what Tecton was doing, what Magic Tecton was doing to be able to run containers in sequence inside a pod, because this is some need we had to be able to control the flow of execution inside a pod, and this talk is a bit going through this. So I'll let you, after, watch this if it's interesting, but in a gist, what we do, let's just first define what we mean by entry point, and then what this hack is all about in one slide. So another point in the container world is whatever binary or command that is going to run when the container starts. It's either specified by the image itself. So if you build your image using the Kafe, for example, on the left, it's whatever was defined as using the entry point keyword. If you don't want to use the image entry point, you can always specifically explicitly define the entry point when you describe your container. So inside a pod, it's going to be container step, which is in the step container spec, which is what we have in steps in the task on the right. So you are always able to define or override the entry point you want when you start a container. But yeah, this is what we mean by entry point. And the talk that Jason and Kristi did, resumed in one slide is we do overload the user entry point. So either the entry point that comes from the image or the one that the user provides, we override this one with our own one we control. This is a binary called entry point. So what Tecton does when it's scheduled a pod for a task, it's copying itself the entry points inside each and every container so that we know what we execute. Then we do change the entry points to be our own entry point. And then in arguments, the whatever was the original entry point. So if the user didn't specify anything, we will check what was the image entry point and then we'll append it to our arguments. If the user provided something, we will append it to ours. So for example, if the user wanted to do a ls-l as entry points, in a really simple way, this is going to be executed as our entry point then ls-l. And thus we can control whatever gets executed. And thus the third step is going to be our binary is waiting for some signal to start. We are using files from previous steps if there's any previous. And then if we got the signal, we just run the initial command that the user provided. And then when it's done, we can gather the result. So gather if it failed or not, which exit point it was and signal the next step. So in the natural normal flow, if the command failed, we will write that it's an error and the next step entry point will know that the previous step failed and skip and so on for all the other steps. So this is how the entry point works. If you're interested in digging more, I'll let you watch the talk after. But for our debugging purpose, we needed to enhance this and this is where the debug breakpoint story happens. So as you said, to actually start debugging and providing the feature for debug, we've had to expand the entry point hack and a little bit flip it over its head and use this hack to actually control the lifecycle of the steps itself so that when a step is executing and it fails, the step should stop at the failure and not stop the execution of the task on itself. And the user should be able to go into the environment and then debug it and troubleshoot and figure out what's the issue and then go back and fix the issue that is there that they come. So for this, what we do is first of all, we mark the task on this debugable by adding the debug spec and also adding where we want the breakpoint to be. On failure over here is a dynamic breakpoint which basically stops the task on any step that fails. So how many of the steps fail? The step would be paused at that point and the user can basically gain access to the environment of the step at that point. And what is done is when the user gets environment access, they can debug do whatever they want over there and then they can after that continue the step from there by marking the step either as a success or a failure. So to continue and break the breakpoint and mark the step as the failure, we provide scripts which help to do all these things. So we provide a debug continuous script which basically marks the step as a success and then breaks the breakpoint. And the user can also mark the step as a failure by using the debug field continuous script. And the step would be marked as a failure and in the end the task can also be marked as a failure. So when this execution is complete, the user can basically go ahead and get an idea of what exactly fails so that they can go back to the task run and fix it over there. So yeah. Now we'll actually look at how to do this in an actual demo and let's go ahead with it. Okay, so we are running Minikube and with tecton installed and you can see that there is a tecton controller on the web for what's over here. And what we are going to do is we are going to run our task, a task run which contains a task spec so we don't have to create a different task. And this is going to have a task which is going to write a file and then start it and then read the file. And let's see how that goes. So this and somewhere along the way the task is going to fail and we will probably figure out by the end like how we can debug and fix the task. So let's go. I'm going to go ahead and create this task which is called step script bash. And then you can see here that the task run has been created called step script and a generated name. And it's in pending mode because the port is initializing task and port is initializing. And over here we should be able to see the task and logs which come up. So we'll just wait for a second till that comes right up. Okay, so you can see the task, task run is running. And but you can see in the logs also that we have got an error in the stat step, which says that cannot start shed data, new write no such file or directory. So I don't know what's going on here. Let's go back and check in the task and so like what happened considering like we are on on failure right now, we can see this debug steps saying that skipping writing on writing to the post file related to debug. And what we do is we will get into this pod and go to the step start container, which is basically step dash step name that is the container name format for this. So this is the step that we are going into, we're going to see like what is going on. So we are using the Ubuntu image here. So there is the bash shell. So we are able to use it. So we are in the bash shell in the container right now. And what we are going to do is we are going to check cannot start shed data new write. So we're going to check if new write is there or not just in case. So there is no such file or directory. Let's just go ahead and share data if we can figure this out. So we are in shed data. Oh, it seems like there is data in the shed data going to be there is something that is awesomeness inside. Now what we're going to do is we're going to, okay, now we know that the data is in data file and not in new write file. So we are going to go to the task run and try, I'm going to try and debug it. So the task that we ran was the step script bash in the step script bash. So the second step, so the write seemed to work well. And the stat is doing a stat on shed data new write, which is wrong because it seems like it's writing to data and not new write. So I'm going to go ahead and fix this right away. And then considering that considering that at the end in the last step, we are eating shed data data. So I think it should work. So we just mark this step as a success for now. So let's go back to the container and then mark this task run as a success. So I'm going to, so how do I mark this as a success? So I'm going to go to tecton debug scripts. And in the scripts we have, so these are the debug scripts which come along with the debug spec. And the user can use to either mark the step as a success or as a failure and close the break point at the same time. So I'm going to go ahead and run the debug continue script over here. And yep. So the board terminates and the task run is marked as a success over here. And you can see that, see that you can read awesomeness over here as well. So basically the task is passed with success. Now let me just go and test out if the check that we made, the debugging that we did came to fruition after changing the new write to data. So I'm going to run the same task run again. So we've got, we've got this task run right here. It's, the board is initializing. It's running. It'll start running soon, I hope. Right. So as, as we saw, and as we are seeing it right now, we were able to quickly get in the container and see what's was inside. And it helped us see that we were looking at the wrong file. So yeah, this was pretty useful. Vibab right now decided to mark the step as the, the step and the task as a success because we knew the next step would succeed. But we could have done the opposite, doing, marking it as fail and just have a new one. I don't know if you want to demo that. Let's actually see how that works. So how marking a failure works. And if it actually marks the task on the failure, so I'm going to go ahead and go ahead and start again the wrong, wrong file. And then we'll try to run this again. And let's, let's mark this as a failure and see how it goes. So I'm going to create this again. And this one, as we know, it should fail on the second step. So let's get the pod for the task run. And let's wait for the step to fail. So we have this fail step over here again. So we're going to put it in it. And then we know, we know the drill and we know that the file is wrong. But we are just going to mark the step as a failure. So we are going to run the script for failure. So debug fail continue. So I'm going to run this. And even if, even if the task continued, and we had the output, the step failed, so you can see that a task run over here is in a failed status. So in this way, like you can mark this as a success or a failure. So let's recap the demo and let's recap the demo and see like what we did basically. So there was a task on which we executed and a step in the task and failed. So we had already provided debug breakpoint on failure in the spec. So the task and did not complete the execution rather it halted so that the user can come in for debugging. And when the task was halted, the user could get access to the debug environment in this case that is a step and container. And the user could figure out why the step failed and then mark the step as a success after failure, after it failed. So they can just let the task and continue as it did. Then after figuring it out, the task continues executing with no problem. The user now knows the reason why the step failed in the first place. So this basically didn't involve any kind of hacky processes internally. It did, but externally it did not let the user to figure out like, okay, why did this fail? I probably need to run this again. The user had to run the task in just once. The failure happened only once and they were able to debug it, understand the root cause of failure, and then go ahead with running the task again. All right. So this is more or less the current status of our proposal and our work. Let's see what are the next steps for this. So there's a few things that we need to enhance our ad to have a more complete debug feature. One thing is right now there's a kind of shortcomings, which is if you are using inside your steps an image that doesn't have a shell, then the debug scripts won't work. You won't be able to continue or break the flow because we need the shell to do that. One thing that we would like to provide for this reason and for other useful reason is for Tekton to be able to provide its own shell, probably as part of the entry point itself. Either the same binary or using the entry point injection act to inject another binary. This would be useful because then no matter what image is used inside your step you could debug it, but it would also mean no matter what image you use you could use the script feature of Tekton. Then we also want to support more modes or breakpoints that the user can provide. We demode the only mode that is currently supported which is the unfailer mode. We would like probably to add more things like debug on each steps or specify the steps that we want to debug, those kind of things we need to support and probably the same on the pipeline itself. So be able to say I want this and this task to be debuggable but not the other ones. In addition, we would like probably to go forward. We are waiting for feedback of the community but we are thinking of in the future being able to actually do the software debug of a process running in the CI directly from your IDE. So the flow would be something like I do run my pipeline. There's some end-to-end tests that runs in my services running and is opening a port to debug. I would like to be able to hook my IDE on this running process somewhere and just do my usual IDE debugging feature on there. And of course one of probably one of the most important except is the better user experience. So we would like to make it even more easier for the user to actually debug each steps or each pipeline. So integrate it with TKIN, the Tecton official client or dashboard where you could just see it failed and it's in a debug mode. So just do TKIN debug and get dropped in or from the dashboard just okay it's in debug mode just drop me in the shell. And of course more tooling integration. So integrate it directly within your IDE, being IntelliG, being VS Code, etc. And those are the next steps that we are seeing right now. Of course we are open to any feedback on this because it's not set in stone, it's going to be an experimental feature to start with. So yeah we would like to hear from you. And yeah thank you for attending this talk. As other beautiful talk we are available and on chat for questions. So yeah thank you for listening to us and watching this talk. Thank you everyone. Take care, bye bye.


Hey, everyone. Thanks for joining us on a primer on Gateway API extensions. My name is Damian Hansen. I'm a software engineer with Solo.io. I've been involved with Gateway API either as a maintainer, a contributor, or an implementer since the project's inception. Hey, everyone. My name is Sanjay Bhatia. I'm a software engineer at VMware, and I'm a maintainer of the Contour Ingress Controller and a contributor to Gateway API. So what is Gateway API? Gateway API is a project that's managed by the SIG network community within Kubernetes, and it is a collection of resources used to describe service routing within Kubernetes. And it is the next generation of Kubernetes routing and load balancing APIs. You may ask yourself, what's the next generation about Gateway API? Gateway API supports a ton of different protocols from GRPC, PLS, of course, HTTP, Layer 4 protocols. The protocol support continues to evolve within the project. It can perform advanced traffic routing. This could be routing across different namespaces or based on information within the request if it's a header, and not only the request, but also the response as well. So Gateway API allows us to do a lot of really cool, fun things for routing traffic within Kubernetes cluster or into or outside of our Kubernetes cluster. And I mentioned that Gateway API is a collection of resources. There are some core resources that we want to talk about in more detail here. There is the Gateway class resource. The Gateway class resource represents a set or a collection of gateways that have a common configuration and behavior. You could think of a gateway class that's called internet-facing that would include all gateways that are exposed outside to the public internet, while another gateway class called internal would only be for internal communication and not exposed outside of your trust domain, for example. And so beyond the Gateway class, we have a gateway. This is a resource that actually is the core of Gateway API. So the gateway resource is what actually instantiates the infrastructure used to perform these operations. So typical implementations of a gateway would be a load balancer or a proxy. And when you create a gateway behind the scenes, there is a controller that's responsible for watching and reconciling a gateway that then goes ahead and instantiates that infrastructure, creates the proxy or the load balancer, maybe it creates a Kubernetes service that allows requests to the gateway to be load balanced across a series of gateways. And then we have routes. In this example, we see the HTTP route that's used to route requests that match traffic for a particular gateway. And you see the lines that go in between all these that represents how these different resources are interrelated. So when you create a route, you attach a route to a gateway. When you create a gateway, you tell the gateway that it's part of a particular gateway class, and that becomes a relationship between these resources. And then last but not least, we talk about the gateway being a piece of infrastructure within a gateway class and HTTP route being configuration to tell the gateway where to go ahead and send that request, but ultimately that request needs to go to something. Typically, it's a service that's within the route, it's represented as a backend, but it doesn't necessarily have to be a service. And we'll talk through some examples here as we move forward through some of these slides. So we talked briefly about the different core resources and what gateway API is at a high level. But let's dive into a little bit more about the extensibility and really talk about extensibility for gateway API. We need to understand a concept of feature support levels. So features are expressed through maybe fields of a resource or a particular resource, and the different resources and fields actually have different support levels. And so if a field or resources considered core support, that means that all implementations that are conformant to gateway API must support the resource, the fields within the resource if it's considered core as well. And here's an example of a core resource, right? Gateway is a core resource, and this gateway defines core fields. A gateway class name, right? What gateway class is this gateway a member of? And then a listener. This is an HTTP listener that's specified the name, a protocol, and a TCP port to expose on the gateway. And these are all core fields. So no matter what the implementation is for gateway API, it must support these fields. And that ensures that users of these APIs that allows you to that portability, right? To be able to go between implementations and know that you're going to get the expected behavior. So now the next support level is extended. And what this means is an implementation doesn't necessarily have to support an extended feature, but if it does, that it must support the feature per the specification. And here's a few examples of extended features, right? So you can go ahead and use the address field to specify a type of address and the value for that address type. Or more likely you would go ahead and you'd create a filter within your HTTP route or your route resource that performs some kind of operation on that request. And in this example, the URL rewrite filter is an extended filter, although gateway API has route filters that are core. And leading into extensions, implementation specific features, they are not portable. They are not part of the gateway API release. So the types for these implement implementation specific features, those types are not part of the Go types that are specified within the project. What the project does instead is it has these extension points that reference an object, right? In this example, we see that it's the gateway class parameters ref that's referencing an object. And when we reference an object, it's by group, kind, and name. I can also include a namespace. We'll talk a little bit more about referencing resources across namespaces. And in this example, we use that parameters ref extension point to expose configuration through a custom resource that we as an implementer would be responsible for support. And again, since it is implementation specific, it's not portable across implementations, hence the name implementation specific. But in this example, we see that the my config resource is used to create an address pool. And I would expect that this implementation uses this address pool that when gateways are instantiated from this gateway class, that the implementation has a controller that assigns addresses from this pool to those gates. So you see in the examples that I provided for these extension points, typically it's a reference to a group and a kind and a name, right? And so that's a local object reference expecting that that resource that is being referred to is within the same namespace as the reference. But gateway API also provides that flexibility, right? Being able to balance both being secure by default saying that the reference has to be in the same namespace as the referring resource, but also providing the flexibility to say, you know what, I may need to reference a object that exists in a different namespace. And here's a perfect example, right? Having an HTTP route in one namespace that needs to refer to a service in a different namespace. And that's where the reference grant resource comes in. And the reference grant resource is a flexible resource that allows you to specify the to and from, right? So from what resource do you want to give a grant to reference for another resource? And of note, as you can see in this diagram, when you create a reference grant, you always want to put that reference grant in the namespace of the resource that's being referred to, right? And what that does is in the background, there's a controller that'd be watching the reference from the HTTP route to the service. And without the reference grant, the controllers say, no, sorry, would surface some kind of status condition in the HTTP route saying, yeah, you're, you know, invalid reference. But with the reference grant, the the implementations controller which would look and say, okay, if you're out, you're trying to reference service in back end namespace. This isn't a different namespace. But I see that there's a reference grant there that allows this. So I'm now going to allow that configuration to exist. And then, of course, requests that come through the gateway and will eventually go to the service in the back end namespace. And again, this reference grant resource provides that flexibility for Gateway API to allow that cross namespace reference. So hopefully this is starting to make a little sense to you. And this will allow us to dive a little bit deeper into the different extension points provided by Gateway API. The first that we'll talk about is the parameters ref within a Gateway class. I've already touched on that a few times. So we won't dive too deeply into it. But the parameters ref is used for exposing custom configuration. It's optional if you want to create gateways of a particular Gateway class and that Gateway class just has a controller name, no parameters ref. Then what's expected is those gateways would be instantiated with default configuration. But in typical environments, you're going to want to be able to have custom configuration if it's maybe some type of network publishing strategies to be able to say I want to use node ports or external load balancers for my gateways, all these kinds of things. That's just scratching the surface of the custom configuration that you can provide to your gateways. This is the extension point that you want to use. It doesn't necessarily have to be a custom resource. This could be a config map that's supported as a core support level. But what I've seen quite a bit in projects that I've been involved in is the desire to have typed configuration and not just a data blob within a config map. And that's typically where you see this parameters ref use. Gateway certificates provides another extension point for us to use. So we've already talked about what a gateway is. And so for gateways, they could terminate HTTPS, TLS traffic. And to do that, it needs to know about the TLS certificates and keys to do so. And by default, you can store these TLS certain keys in a secret and that's supported as a core support level for that feature. But if for some reason you have a use case that says, hey, can't store these certs or keys in Kubernetes secret, I need some other kind of resource. Gateway API provides that mechanism within the cert refs field. Again, local object reference, if you need to refer to this resource in another namespace, we need a reference grant and we specify namespace within certificate refs. And one point about that certificate ref is it doesn't, or the reference grant is, it doesn't necessarily need to be used with a custom resource, right? So if you have a secret in a different namespace, you could still use a reference grant and you don't have to specify the group in kind because it's inferred that it'd be a secret and it would just be the name and namespace. Route backends. So as part of a route, for example, HTTP route, that route is configuration to match traffic for Gateway to optionally do something with that traffic, modify it, transform it and such, and then eventually route that traffic to a backend such as a service, right? Well, we can do matching requests, I'm sorry here, we can go ahead and have a backend that's potentially not a service, right? And here we have an HTTP route backend named MyCubeService that refers to a service. This slide's actually incorrect, I apologize for that, they should say service and not secret, we'll fix that after the recording. But we can also specify some type of implementation specific resource. In this example, MyCustomBackend, this could be an AWS storage bucket, this could even be a multi cluster service, right? So if I don't want to route to a service within my cluster and I want to route it to a different cluster I could use, the Kubernetes multi cluster services has a back end as well. And then optionally routes, as I mentioned, can modify the traffic using filters. And this mechanism can be expressed at the rule level, or it can be expressed per back end, right? So if I want to go ahead and have a filter for all match traffic, do something to that traffic, let's say authenticate it first before sending it to the back end service, I would do it at the rule level, but if I say I just want to do it with for a particular back end, that's where we start, we can have filters as a field on a per back end basis. Now, an important distinction here is there are filters within Gateway API that are core or extended or again, even using the resource reference model for referring to implementation specific resources. But even if a core filter is expressed on a per back end basis, that filter is no longer considered core, it's considered extended. And then no matter where you express your implementation specific filter, either at the rule level or the back end level, that's always going to be implementation specific from a support level standpoint. But I just wanted to make sure you understand that distinction of using the core filters either at the rule level or the back end level. And typically what I see is filters being used at the rule level. I've already touched on this, that there's filters that are part of Gateway API at the core or extended level. Here's an example of the request header modifier filter. That's core. And then there's actually a response header modifier that's not core, that's extended. Or in this example, I say, hey, I want to actually authenticate those requests that are matched. And before forwarding the request to my back end service, I'm going to go ahead and have this my off filter be able to express all sorts of authentication configuration that my implementation would utilize to authenticate those requests before forwarding their quest onto the back end. So that provides an overview of some of the extension mechanisms for Gateway API. Hopefully that helps you kind of get that foundation set. And now I want to go ahead and hand it over to Sanjay to talk more about the additional extension types. Yeah, thank you, Daniel. So Daniel's talked about a lot of the extension mechanisms within Gateway API resources that allow you to refer to a custom configuration resource from within one of the Gateway API core resources. There's a few fields within these resources that also allow you to provide some custom configuration, particularly in the form of what you would call a domain prefixed string that you can use to provide some custom types or custom values. So for example, the Gateway address type, you can provide a custom domain prefix string to provide a implementation specific interpretation of that type there. In addition, the Gateway listener protocol can have a domain prefixed string to supply a custom protocol that your implementation may support. And similarly, passing TLS options for a Gateway listener, you can specify some domain prefix strings for the keys for these options that you may provide. In addition, the regular expression match type on various routes is implementation specific support level, because various implementations may use different regular expression engines, or what have you. So HTTP route path header or query parameter matching, when it's of type regular expression, that's implementation specific support. And similarly for GRPC route. So now we'll move on to a pretty powerful type of extension point that Gateway API is enthusiastic about. And that has to do with it's called policy attachment. And more generally, we're going to talk a little bit about meta resources, which Dan has actually talked about a little bit with referenced grant. So a meta resource is a Kubernetes object that augment the behavior of another one. So in the case of reference grant, you are able to allow cross namespace references by with the configuration that you have in a reference grant. Similarly, a policy is a meta resource that allows you to augment behavior of another object. So for example, you may want to apply some configuration to an HTTP route or a gateway or a service that is implementation specific. But, and this gives us a huge opportunity to do implementation specific things without having to add these things to the Gateway API or the core networking APIs in the case of service. This sort of standard method to plug features into the Gateway API and possibly in the future, more broadly in Kubernetes, offers a great opportunity to augment the APIs in general and offer a uniform user experience. And we're hoping that this standard approach, standardized approach for using these types of meta resources can be a nice way for implementations of the Gateway API to extend the Gateway API. So the core of policy attachment is the target ref. So every policy resource should contain a target reference field that allows you to specify a similar to reference grant and some of the other extension points that Daniel was talking about a local object reference for the target of this policy. And along with that target reference, you'll have some configuration that you want to apply to this to the target of your policy. There's two types of policy attachment, the first of which is direct policy attachment for when you want to augment a particular individual resource. So in this example here, we have a TLS policy that is targeting a service. And in this case, we may want to apply some configuration that proxy implementation or an Ingress controller implementation of Gateway API uses to apply TLS connection details between the proxy and the back end service. So this is a way to, instead of having to change the service resource itself, we can add a meta resource or policy that targets the service and allows us to have some implementation specific configuration on top of what service gives us already. And another next form of policy attachment we have is inherited policy attachment, which is useful for when you want to have settings that flow down a hierarchy of resources. And in a former iteration, this was called hierarchical policy attachment. This is particularly useful in Gateway API, because we have hierarchy of resources, right? We have Gateway class gateways and then the routes underneath them. And then they also reference back ends and other other resources. So in this example, we have a Gateway and some HTTP routes that attach to that Gateway. And we have a target ref in this rate limit policy that targets that Gateway. So all the configuration in this policy should be applied to the Gateway and all of its sort of child resources, the routes that attach to that Gateway. And the core part of the inherited policy attachment idea is that we have a concept of overrides and defaults. So overrides are settings that are applied at the higher levels of the hierarchy and they cannot be changed by objects lower down in the hierarchy. So you imagine in this example, we have a policy applied to the Gateway. That means that any routes attached to this Gateway, if requests come in that match those routes, if they're rate limited, the status code 503 should be returned. And that applies to all of the routes in that Gateway and that cannot be changed by any configuration applied specifically to those routes. On the other hand, we also have defaults, which allow us to set some default values that can be overridden by resources that are further down in the hierarchy. So you can see how these overrides and defaults may be a powerful way to replace something like webhook validation or gatekeeper policies or other things that administrators have to use to ensure compliance, for example, in resources that are created in that cluster that they're managing. So here, going along further with this example, we have another rate limit policy that's targeting a particular route in our Gateway and route hierarchy. And it is overriding some of the default values that were set in the higher level policy. So we have a stricter rate limit in this policy that's applied to this particular route. So you can see if you expand this out to some more complex use cases and more complex hierarchies of resources, this could be a really powerful tool that fits really well into the role-oriented and the different personas and the role-oriented design of Gateway API. So now we've talked about a bunch of different extension points in Gateway API. If I'm a developer working on an implementation, what do I do next? How do I sort out all these different extension points, all the flexibility that the API gives me? How do I use it? So what we found is really useful is to document your use cases using the Gateway API personas. For example, even just writing down statements as an app developer, I need to route traffic across multiple clusters. That go a really long way into helping you decide which extension point to leverage, what resources are involved, what the access levels and RBAC rules possibly are needed in your design. And then to design your API, the Gateway API project strives in this documentation to provide guidelines and documentation and recommendations on how to develop extensions. As the ecosystem matures and there's more implementations contributing to the upstream policies and documentation, this will grow and you'll be able to get really good recommendations on how to design your APIs. And of course, following Kubernetes API design conventions as is expected. And of course, if you're implementing your API, if you chose an extension point that involves custom resources, you'll likely have to implement a controller that watches your custom resources and reconciles them along with other Gateway API resources. And so a huge part of this is also sharing and contributing and collaborating with the upstream community. These Gateway API extension points are still under active development and changing. A lot of the stuff is still being developed in Gateway enhancement proposals. And we're still thinking about how policy attachment, for example, is observable, how to surface status and errors and what policies are in effect, what configuration is in effect on a particular route for users to be able to understand what's going on in their cluster and what they should expect from the configuration that they've applied. So as we go through this process, as developers that are working on implementations of Gateway API or users, we would love to have feedback and discussion on the upstream channels about your experience and your ideas as well. And so that's a neat little segue into talking about Gateway API extensions where they're headed and how we can get involved. So this active, as I said, is active development going on with Gateway API enhancement proposals and active discussion in the weekly community meetings in various time zones. So definitely get involved in the community meetings on Slack in the community Slack at the SIG Network Gateway API and, of course, in the Gateway API GitHub repository. Enhancing with proposals, issues, discussions, pull requests, of course, everything is welcome. And with that, Daniel, do you have anything to add? No, thanks, Sanjay. I would say that we hope that you found our talk useful. And that there are many Gateway API implementations out there. But when it comes to the extensions, like a majority of the current implementations focus on core or maybe even some extended feature level or support level features. But this area that we have focused on our discussion for today, the extensions, that's an area that is still very few implementations take advantage of the extensions. And so it's a great time to get involved in the community, especially around these extension mechanisms. And you see here the weekly gamma meetings. So even the APIs are evolving in the sense that gamma, which is a subgroup that's focused on Gateway API for mesh management. There's just a lot of opportunity to really help develop extensions, extension best practices, or even how Gateway API evolves for mesh management. So with that said, we hope you take a moment and give us some feedback on today's talk and feel free to reach out to us. We're on Slack, a part of the Slack channel, and involved in different projects for CNCF. And we really appreciate your time.


The Inspector General of Police, Al-Khali Usman Baba, is in Plateau State, where he commissioned 50 patrol vans and 200 motorcycles donated to the force by the Plateau State Government. While appreciating the State Government for the gesture, Baba noted that the state is faced with security challenges, and a lot must be done to address them. The Chairman of the State's Traditional Council and the Bonguom Joss, Dajay Kabuba, amended the role of the security agencies in the state to bring peace and make a case for the recruitment of more men into the police. The State Governor, Simon Nalong, appealed to the police to intensify the training of its men and urged them to make judicious use of the donated items. The Traditional Council will always work with government and with other security agencies and let me at this point commiserate with the Inspector General of Police and other security agencies for the loss of life of officers and men of the force due to these insecurity challenges. It is not easy, but I assure all of you that we appreciate you, we are not taking you for granted. Plateau State presents a unique security challenge, with the constant threats being posed to the state by bandits, harders and other criminal elements. The situation is being fueled by the increase in cases of arms trafficking and illegal firearms roll-in vocation. Indeed, just recently a special police operation team monitored and successfully arrested a seven-month criminal syndicate would expertise in local fabrication of AK-47. The syndicate whose local fabrication enclave was here in Joss, Plateau State, where they were arrested had been locally manufacturing assault rifles and ammunition, which they had been supplying to bandits and other criminal elements in the state NPO. There is need for greater synergy between states and the security apparatus. That is why, as Northern Government, we have continued to engage with the top security hierarchy to ensure we block this loophole. In order to address the challenges of security agents, which include manpower shortfall and call logistic, we have taken various measures over time to improve the security of the state. We have offered logistic support to the police and other security agencies, as well as invigorated our operation rainbow towards addressing the security situation.


You ain't getting away that easy, buddy. Oh, maybe you are No, you're not All right, let's show up. I hope we're get river Yep, and there's camera Hey, you want to help out a little bit? Thank you Jesus it's only a five-stack not gonna kill but it should force him out He did oh No, he's not really surely this time. I didn't need it.  Oh, get on my way Buff is all up in my grill On the cop of feel and these big old rampage titties. He got good squatted.  He might be dead to that. Hey, there we go He was probably typing to his team just now, which is hi, Larry's be one more Haha, we'll make it cause it be enough. No, it will not you chose wrong to beck. I don't have the manna I don't have the manna.  I'm right here Cheeky follow you's ultimate the buffet. I dare you we all saw that coming.  I don't know that feeling.


What does it mean to you to be a graduate from the university, to be an alum from the university? I think it's very nice that Aarhus University is ranked, you know, it's ranked top 100 university and I like that and I think that sells because if I'm going to apply for jobs out of Denmark, I could easily say that I am an alumni from a top ranked university, that helps a lot. And how have you stayed connected to the university since you graduated? You know, I'm a part of CONNECT, the ASB Alumni Social Network, I tried to go for all those interesting events that they have but because I work in Silkeboi, it's quite difficult for me to reach Aarhus or go to Copenhagen in time for these events but what I do now is I teach part-time at Aarhus School of Business, I teach cultural theory and analysis and I think it's great because I not only get to share with the students the theory but also my personal experience in coming from a different culture and working in a different culture so that's how I get to contribute the very least I can.