It's got a fun haircut plan for you guys today. We're going to work on a short haircut focused on combining those shapes that we talk about, open, closed, and balanced. So we're going to work our way through that. And we can do the combo of shapes all different ways in all the different sections, and it would be a different haircut every time. So that's really, when it gets down to it, exactly what I want to get through to you guys today is being able to see a haircut, associate it with those shapes, and then execute it from there. So the sectioning for this cut, I'm going to use a white comb today because we've got dark hair. We're going to comb this straight back. I'm going to part it in the center just for sectioning sake, but she's going to wear this kind of wherever she wants. So we'll comb this back, right over the nose, straight back to the crown. Or that. You guys know that I keep sectioning pretty basic because it doesn't need to be complicated. As long as it has a purpose. So we split left and right. Now we're going to split front and back. So we go high crown down to behind the ear, splitting it. Follow that hairline right here, all the way up to that high crown. We're going to do the same thing on the opposite side here. All these are the same densities together. So you've got the back is the same density from here all the way around. And then you have the front is the same density from here. So we've got this much hair all the way to the front, right? So we know what we're working with. Now what I want to do to just finalize this is separate the top and bottom. So I'm going to go right along the parietal ridge. And now we'll take away that center part because we don't need it anyways. So I'll comb this side up. And I'm going to do the same thing on the opposite side. All right, I've got this top section. It's not balanced yet. So I'm going to comb it straight up so I can really look at it. I see it's a little further over over here. Let's take a little bit more. Now the goal or what we've got to figure out is what shapes are we going to put in each place? We could go balanced in the back, closed on the sides. Balanced would look like this, right? And everything shape-wise happens from the top view down. That's why I love the top angle because the top view down shows the shape of the haircut. The front view shows the elevation of the haircut. Is it layered? Is it graduated? Is it one length? That's how you look at it, right? But let's take the back in the day, how they taught it, is circle. So a round shape would be following the round of the head. This is all horizontal, right? This isn't up and down. This is horizontally around the head. So you see that circle, right? Just like that. Now we change it up. Now we have a square shape. So everything stays balanced. So when you think about how you would hold everything, let me grab a different color comb, when you're here on the head, I pull this out and I cut everything in this square line and it's going to go like this. Because I'm on a round shape, this hair doesn't take as long to get to my comb as this hair in the corner does. So when this hair in the corner comes to my comb, you got that, and this hair here comes to my comb, look how much further that hair in the corner, this hair here, takes to get to it, about another inch. So what's gonna happen when I cut this in a straight line, a square line in the back, it's going to fall a little bit longer because of the round of the head, the head starting to push away, right? So when I say balanced, because I think square confuses people in triangle and circle, to me it was a little bit confusing because when you say I'm gonna cut a triangular haircut, some people think it's from the front view. Some people are taught in school that round is this and that's fine, that doesn't make it wrong. What I'm saying isn't right either, right? Because this is round if you fall the round of the head this way, it is. Some people think a square haircut would look like this, it's a box sitting on the head, but that's not what I'm talking about. I wanna talk about the flow of the weight horizontally in a haircut. I call it balanced because we're cutting a line that just stays balanced in the back.   We're pushing all that weight to the front of the head.  So those are the three things that I'm focused on. So in the back here, if I cut a balanced shape short on the back, I'm still gonna get a little weight in the corner.  So now we don't have weight. When I get to the next section, so we're about to go into the next section, and now I can shift that from being not open anymore to then closing it off, right? And if I close it off, I push a little length and weight towards the front. But I've held on to the same length all the way around the head so I don't get too much weight and then all of a sudden I cut it so it gets a little bit longer. Or I cut an open haircut around the head.  So this will all come out. This will be the shortest point because we're on a round surface right here in the center. And then this will be a little bit longer. So we'll get a little extra length in the front but it won't look extreme John and Kate plus Adish style, right? Does that make sense? So we got decisions to make. For me, I'm going to cut a balanced shape here. It's going to work into an open shape around the back and then we're going to cut a closed shape on top. Combo of shapes. But I want to show you guys how to combine these shapes together. The way that I like to focus on shapes especially on short hair, let's just say majority of the time on short hair is cut my first line horizontal. Cause this will get me at the length that I want. It'll also give me a guideline for every section that I take. So if I come here, hold this hair out. I wanna go light on the tension. One thing you gotta really focus in on here is the elevation, right? So if I'm here, I'm building a weight line. If I'm here, I'm not building a weight line. We've talked a lot about the horizontal shape. We haven't talked about our up and down, our vertical and vertical is gonna play a pretty big role in where that weight sits. It starts to build out from the haircut. So right here, my elevation, I'm going to go at 90 degrees out from the head shape here. I wanna make sure I'm standing parallel to the head, shoulders parallel to the head. And I cut my line with the right elevation and I choose my length and I start to cut. You can already visually see that this part here is shorter than this part here. Because, look at the curve. We're working on a curve. Here, recomb. And notice I'm combing underneath and pulling up because that ensures that my intent is to pull the hair to the sky and not combing it down, then my intent is to push it to the floor, right? I wanna make sure everything I'm doing has a purpose. There's my line. I lost a little bit of tension there towards the back end, so I'm gonna just cut. But you can see visually right here, the length. I cut balanced, but it got longer because I cut balanced. If I cut closed, this would be even more extreme. Now, I've chosen my length for the sides and I'm gonna start in the front and I'm gonna work my way towards the back vertically. Now, my section has a slight, I'm gonna clip this away just to make it easier for myself. My section has a slight diagonal back feel to it. Here, over the top of that section. Now I'm going to bring the previous section halfway. This is really important. You don't wanna bring that previous section all the way to the next one. You wanna bring it halfway to it and don't take too much new hair. Bring it halfway to it, meet them in the middle. That way it's not really changing too many lengths because if you bring the previous section as your guide to all the way to the new section, now the new section is way shorter than your guide. And then the next section will be shorter than that section. So you'll start to continue to build a shorter, by the time you get here, you've kind of almost cut a closed shape because it got a little bit longer towards the front. And we are working our way towards the back here, towards the back section. We're here, I'm gonna go one, and we'll go probably two, that'll put us right behind the ear. And then we'll go into cutting our round for open shape. I'm initially combing this into my hand by pulling it this way, but then my last comb is back. And once we have the side cut, now what I'm gonna do is I'm gonna do a little scissor over comb just to cross check any inconsistencies in that shape. Okay, so there's the side. Now we shift from vertical to slightly diagonal back, and we're gonna follow the round of the head all the way through, cutting everything the same length about it. Now, I want my elevation to shift and change a little bit throughout the back of this haircut. I don't want all of this back to be the same length, that would get us the John and Kate plus eight haircut, spiky in the back here. I want this to have a nice soft lie to it. Now, we've done this before in our last short haircut session, where we create the triangle in the back here, and that we just cut a little bit different. I'm not gonna do that in this one, because I wanna really challenge myself and you guys, not always have to put that triangle there, but just have the awareness of the crown of the head, right? So I'll go against the head, against the head, all the way here, but as I'm up here, I'm gonna drop and still continue to go against the head. I have this section, but it's gonna be cut here, drop, because wherever you want the weight line to sit is where your fingers should kind of stop elevating. Saturation on the hair here, and now we are going to work, diagonal back, the hairline. This hair, I'm going to comb over, get it out of the way. I'm using the tight teeth of the comb, because that will help keep everything together and cleaner.  It's not chain, it's not going up the head shape. So this finger angle isn't like this. I'm leaving that corner, that's that weight. So now, to take these sections, I comb everything in the direction I'm gonna part it, because that'll give me an easy line to follow with the top of the comb. So then I take the tip of the comb here, at my starting point, follow it with my thumb, and your thumb kind of presses into the other hair, the hair that you're not, that you're splitting, and allows it to be separate. So comb it in the direction, follow your thumb through, and then comb everything over, get it separated, and then come through here, comb this stuff over, switch to the fine teeth. It'll keep it a little tighter. The cutting lotion helps keep this clean, and now you're good to go. Here, keeping that finger angle, we talked about, building that weight in the top end. See my fingers are pointed towards the sky on that top section, not coming over. Here, see that? Now shift, the finger angle's gotta be up. It's harder and harder as you're working through the top here because you're moving away from the head shape. It's easy to follow the head shape because you kind of know your angle. Once you start pulling away from that, you start to have to rely on your visual in your eye. Go, up, comb it over, but last comb has to be towards me. Keep that weight moving through. And then here's our buildup right there. So even though I changed my body position, I'm still pulling the hair, or the old hair to the new section. So still taking the same partings, scooping up my section, still going straight up to the ceiling. It's just what makes you the most comfortable because when you're comfortable cutting hair, you're more consistent. When you're uncomfortable, that's when the inconsistencies come in. So you're gonna leave it. Now that we're over here, because I wanna cut all this diagonal back. So I'm gonna move into this side and do my cutting the same. So cut my balanced shape here. Another reason why these two sides need to be as balanced as possible with this square section. So you're working with the same lengths. So what I'll do here is I can actually, there's a couple of ways you can do it. You could measure it if you wanted to, like I can see right here, good benefit of the Wyest Park Comb is you can kind of count these little marks here. So I could go here and cut myself a piece. And the number one thing here would be, if you're gonna do this and lay it on the head like this, is to not have really too much tension in it. But I can come here and literally cut that piece and then check it here.  Now that I'm here, I take my slight diagonal back section, I've got this all in my hands, pull it away from the face, and I come in and cut. The first comb is to get it kind of away from all this hair, the long hair. You comb it away and then scoop it up to cut. So now we're gonna go into where I cut on top of my fingers, right? So I pull with that guide there. We're cutting straight up towards the ceiling. So the crown, straight up and down. I know I got a dark shirt on. Watch my fingers. I know you can't see the hair, look at my fingers. So really loving all the texture in this. I'm gonna texturize the, I almost said. I'm gonna texturize it a lot on the top here. So now we've created balanced sides, open back, closed top, combining all three shapes. So we've got the top. I'm gonna take, we'll call it horizontal sections across the top. So one, two, three, four.  That's how we're gonna do the front. We're going fingers parallel to the floor, section one. Notice I'm using point cutting because I really want that texture pop.  So horizontal across, back. So two, section two goes to one for a slight over direction. I gotta re-comb at this point. And the reason I have to re-comb is I lose so much tension right here in my fingers. So if I didn't, watch this. If I don't re-comb and I cut this, this is why you don't cut past your second knuckle. This is gonna be a very good visual, ready? When I comb this, look at the length here compared to here. Your tension, hair gets scrunched, the round of the head, all that plays into it and now all of a sudden this side's way longer than the other side. So you have to re-comb it, come up, have grip with that second knuckle and cut. Section three, back to section two. So we're not going all the way to one because I don't want that much over direction. Don't want that much length in the front. Now, section four is gonna come all the way back to section two. So we're skipping a step to give us just a little extra length in the front. It's me, it's just me. But once I get this hair back in there, then I can really start figuring out what I want this cut to. Start calming it down. And see, even if you did that top, like this little top area here, when we over directed it all the way back, when we over directed four all the way to two, that gave us this major amount of length. If we went four back to three, it would be a little shorter in the front. So, kind of gives you that option. What do we think? Very cool. So hope you guys enjoyed the class. I really appreciate all of you guys being a part of the group, being a part of the club. If you guys have questions about anything, please write them in the app.  But if you have questions, again, I wanna be your cutting coach. We're doing the live classes one day a week, but my goal is to now free up a little bit of my time to put out more YouTube videos. But you'll get them before you'll get the alerts on the app. Part of the Facebook club, you're on the Facebook group. If you're a part of Patreon, you're on the Patreon app. It's the exact same thing, it's just on two different platforms. That's it guys, enjoy your week. I hope you took a lot from this class. Implement it. I wanna hear your successes. Other than that, I will see you guys soon on the next video, on the next live, whatever it is. Thank you guys, I appreciate all of you.


Well, welcome. Thank you everyone who made it in here and sorry to those that didn't we are streaming online as well Today we're talking about Gateway API and our path to beta and GA. I'm Rob and this is Nick Good day everyone. We are both Gateway API maintainers Before we get any further. I want to ask a few questions first off how many of you have used Kubernetes services to create load balancers anyone? Yeah expected that would be most of you Anyone use Kubernetes ingresses before? Okay, great great. Oh, it's great. How many of you have tried out Gateway API? Okay, a few of you hopefully. Yeah. Yeah, I mean that's good But hopefully by the end of this talk we'll have even more of you wanting to try it out So let's work on that So for those of you who haven't tried it out yet, you may be wondering what is this thing? Well, I look at it as the next generation of Kubernetes load balancing and routing APIs Why would we build a new API right? This is a very familiar problem. We already have an ingress API We already have a service API. Why start with a new one? Well, the ingress API simply wasn't able to express advanced configurations that so many people wanted This the the failures of that API led to lots of custom annotations and other things which worked They were the best option available but we wanted to provide a better API in Kubernetes that didn't require all those annotations and For those of you familiar with the service API You've seen new fields just get stuffed in over and over again and the combination of those fields may not make sense and it's very hard to Test to work with to implement all those things. So a new API Hopefully offers a solution to this we can unify load balancing configuration across L4 Which was the service API and L7 ingress? We can allow custom components to easily be added on plugged into core resources So extensibility is a huge part of this API We recognize that anything we build in the core Kubernetes API system is not going to be sufficient for every Use case so we want to make it easy to extend and finally we want to enable some additional use cases We're not sure what all these look like yet But there's been some discussions around mesh around egress around policy lots of things that this API could potentially be Used for don't forget my nuts ideas about GRE tunnels VPNs Yeah, lots lots of fun ideas coming. Yeah. Yeah. Yeah So with that let's talk about our timeline and how we got to where we are The last kubcon I was that in person was kubcon San Diego And you see some of us there many of us Ended up becoming maintainers Danians in the audience. I think maybe some others as well The initial work really began at kubcon San Diego We had some initial brainstorming sessions and then it took us a year and we got v1 alpha 1 out the door We had so many different prototypes and many different structures of the API that we experimented with a Few more minor releases some additions and then kubcon EU it was all virtual But kubcon EU we presented our first overview of Gateway API at a kubcon Again, it was all virtual but that was around a year ago and this talk is really going to focus on everything that's changed since that point so in the past year In the past year v1 alpha 2 was released That was a huge change for us We saw it as really the the beginning of our stable API I know it still said alpha, but we thought this was the API we could take to beta and that largely ended up being true Since then we've really been focusing on conformance tests some new experimental features some patch releases Just stabilizing what we have and we're finally at a point where we're confident to go to beta so we'll be talking about that but let's take a few steps back and Describe the API itself If you haven't seen Gateway API before it all starts with a gateway class A gateway class Describes a kind of load balancing or proxy infrastructure So for example, I work for Google and for GKE we're going to bundle with GKE clusters a XLB gateway class and an ILB gateway class for l7 and more to come This is a way to describe load balancing infrastructure every different implementation of Gateway API will have different gateway classes that they'll support Second we have gateways these represent some kind of entry point to your system It could be a load balancer it could be some kind of proxy configuration, but they Represent some kind of entry point to your system But really the huge part about this API even though it's called Gateway API The most important important part is the routes We have a lot of different routes and the routes are where the vast majority of the functionality comes from so in this case I'm showing HP route because that's our most stable most full-featured route that has a lot of advanced configuration in it But you could also attach a TCP route TLS UDP GRPC is coming soon We've got a lot of different routes for different protocols and they define different routing configuration that is protocol specific So you attach HP to your l7 load balancer You might have an l4 load balancer to that you attach TCP routing configuration to Yeah, so one thing I would you want to say there is um with the I think the distinction between them is HTTP routers for terminated HTTP traffic TLS routers for stuff where you're passing through a TLS and then TCP and UDP are for like Proxying TCP and UDP traffic not routing proxying the distinction is important. Yeah, good point. Yeah, good point Okay, so this is a huge feature list Vo dot 5.0 refers to our upcoming release. I'd say hopefully a couple weeks from now. I There's a lot in here. I'm not going to cover all of it But suffice it to say many of these things have not been seen in other Kubernetes APIs This is an official Kubernetes API that supports all of this and more So this is a big thing for Kubernetes But you may be asking you look at that slide you see all these things and you say how on earth can this be portable? You know, we're we're trying to build a portable API. This is a Kubernetes API How can you promise all those features and then say it's portable? Well, unlike ingress unlike previous Kubernetes APIs, we've built in this concept of conformance levels So we start with a conformance level that's called core and that's something that we expect every Implementation to handle in a consistent way and support a good example of this is with HCP prefix path matching Just about everyone can support that basic capability Now we also have an extended level of conformance and that is something that we expect to be supported consistently When it can be supported, but we recognize not everyone not every implementation can support something like header modification A lot of implementations can but not quite everyone. So that's an example of an extended feature And finally we have something called custom. This is not that common in API, but there exists a thing called regex I think that is the only thing this exists for but If you're familiar with regular expressions, you're familiar that there are lots of different variations of regular expression implementations So we can't write conformance test that expect this specific path this specific regex We match the same way when the underlying implementation may support a different flavor of regex So we say okay, this is a concept that is widely understood, but we recognize there may be some variation in implementation here So those are our conformance levels With all that background, let's spend a little bit of time talking about what's changed in the past year and there's a lot First we went to V1 alpha 2 as I mentioned, but maybe most important We went to Gateway Networking Cate's IO API group. What that means is we're an official Kubernetes API That's a big distinction previously. We were just an experimental Kubernetes API this status as in the Cate's API group means that Not only are we Gateway API maintainers reviewing every step of the API change So are upstream API reviewers. So this goes through Nick myself and a few other Gateway API maintainers and then it goes up to Tim and some other upstream API reviewers That's actually the state we're in right now for vo.5.0. We're in that final set of review Hopefully we can get a release out soon I'm really proud of this we have more than 70 people that have already contributed to this API and that number keeps on going up And again, if you're interested, we are always looking for more contributors maintainers and maintainers yes Right now, I think this number is a little out of date, but we have around 15 implementations You may have heard earlier on in kubecon. Envoy Gateway was announced. That's based on Gateway API There's a lot of very cool implementations and I think more on the way and What I'm excited about we we already have conformance tests in place Yeah, that is cool. Yeah, some of the graphics so I wish you could see my screen I'm not trying to do a contour pitch. This has like 12 logos on my screen. It's a second click. Whoa Yeah, cool. Okay. There they are. Yes Anyways Many implementations are fully passing conformance tests now We're really excited about it the fact that we already have a pretty robust conformance suite Means that I think we're going to have a pre consistent experience across implementations Okay, let's talk about what's changed We did a thing with route gateway binding that we hope will simplify things for any of you that may have looked at v1 alpha One before the idea was that gateways select routes So if you've used kubernetes, you're familiar with the idea of a label selector So you say I want to select routes. I want to select routes that have a specific label What we ended up seeing is that Users would just have a creative way of doing this of they'd say I want to select routes that have this gateway label on it That says prod web gateway. So basically gateway name a weird way of attaching to a gateway So we tried to simplify that a little bit by instead saying hey the routes Reference the gateway. So the routes have this parent refs thing And that points up to the gateway and the gateway just says here are the namespaces. I trust routes from And actually that's kind of an important detail a gateway Can trust routes from multiple namespaces if you've ever wanted to have your load balancing infrastructure in one namespace And your routing configuration in another namespace. That's possible with this api Yes, thank you Thank you So we're really excited about that another neat thing about that parent refs field Right now that that is used to refer to gateways There are some other interesting use cases here There's a gap. We you know, if you've heard of kubernetes enhancement proposals We have gateway enhancement proposals and we have one right now that's talking about route inclusion Where that parent could refer to another parent? And another route We'll just see this is still in proposal phase, but there's a lot of really interesting stuff happening here All right Let's move on to reference policy. We're talking about crossing namespace boundaries This is a slightly different way to do it. This is for some very specific instances If you've ever had this idea in your head that I have my routing configuration here And I want to forward to a back end in some other namespace So I have all my routing configuration in a routing namespace, but I've got my service. I've got my app in my app namespace This is what that's intended for or if you have your tls certificates in a separate secure namespace But you want to allow them to be referenced from somewhere else This allows for that so reference policy at its core is a resource that exists in a namespace that I own And it says I trust references From this other namespace. So in this case this reference policy says I trust references from htb routes in the prod namespace to services in my namespace This this pattern is something like we ran by sigoth sigarch sig apm machinery We run it through. I think it's a good pattern, but we're very much interested in feedback here I should Hold out this little note here. We've called this reference policy But there's a decent chance it's going to get renamed Because we have this whole other concept that's a little bit newer called policy And policy is such a generic term. We're thinking we may rename it to something like reference grant So don't get tied to that name this concept. I think it's here to stay the name may change Okay, moving on. Let's talk about policy attachment. This is that thing I mentioned the policy. That's a really broad scope We really want this api to be extensible. We want users to be able to plug in and Build new stuff on top of our api as much as we want to include as much as we can in the api We recognize there are things that just don't fit One of the things we really struggled with in our api is something as simple as timeouts You would not believe the variation timeout configuration, whether you're talking to nginx Envoy some cloud they they all have different versions of timeouts that they support and trying to build portable configuration for that was very challenging So instead what we're suggesting for these kinds of things is that implementations or groups of implementations decide on a common policy that works for them So in this case, you might have a retry policy that you could attach to a route And a health check policy that you could attach to a specific service There's a lot in here, but this is really defining a common pattern for extending the api Yeah, yeah, there's a lot in here. I can I just add one more thing in I would probably say at the moment This is a a framework to be able to build extensions to the api. It's not extensions yet, right? Like we expect we need people to build some examples of this We haven't even built the example of the timeout one fully yet, right? So this is very early But like the idea here is that you can have settings that can be overridden or Or defaulted and stuff like that that allow you to Make settings that sort of a higher or a lower level and yeah, there's a whole document It's a very long it took us a long time to write I encourage you to read it if you're interested in this at all But yeah, it's because it's quite complicated and there's some serious subtleties That can be a bit tricky to explain that we just don't do not have time to explain Yeah, I'll just give a concrete example for gk. We're building an lb policy That includes some of our low balancer specific policy Configuration that just doesn't fit in the api itself and I imagine other vendors will have similar things All right, so let's talk about graduating to beta. That's a big part of this talk We finally are making it to beta But only part of it so We have defined a graduation criteria that involves a number of things One of them is that we wanted to have a robust conformance test suite in place for the resources that graduate To we want them to be widely implemented and widely used And we wanted to feel confident about the state of the apis that they weren't going to need any kind of breaking changes We feel like gateway class gateway and htp route all meet that criteria Unfortunately, some other resources are not quite there yet reference policy tcp route tls route and utp route We're working to get them there, but they're not quite there But we are expecting that gateway class htp route and gateway are going to make it to beta in the next couple weeks There's one more thing I I've kind of haven't mentioned this much but this api is built on crd's We live outside of the kubernetes release cycle. Nick's going to talk a lot more about what that means But one key thing is That that means we don't have feature gates if you've used upstream kubernetes before you may be familiar with a concept called feature gates where when you add a new field It starts an alpha you can opt in with a very specific feature gate and then it gets to beta and then it gets ga We we don't have that concept. We have crd's and after talking it through with a few different sigs This is what we came up with Stable channel is what you'd expect it's the resources that have graduated beta And all feet all fields that are not considered experimental But experimental is kind of that playground where we start with new things. We have alpha resources We have new fields that we're adding that we think are promising But we're not quite confident enough to graduate to to stable quite yet So everything starts and experimental Some stuff graduates the stable and some stuff disappears from experimental So if you want the most stable experience just install these stable crd's But if you want a new feature if you want to test out some new thing You can install an experimental set of crd's, which will always be a super set of what's in stable I guess Can you go back to that? Yeah, sliver's sake. So there's a couple of things I wanted to add to that that I just thought of so notably You probably noticed that the reference policy is still in alpha As of the the next version. This is all as of the 050 Reference policy is still an alpha Which means that you won't be able to make cross namespace back end references Or refer to secrets that are not in the same namespace as a htp route Those both require reference policy to be done safely because reference policy won't be alpha If you're only using stable you just won't be able to do it. There's no mechanism to do it, right? So just wanted to call that out It's still like the gateway api with the the resources we move to beta is still perfectly functional Is just that it's a bit less. You can't do some more complicated stuff We are hoping to get reference policy in really soon, but like that's going to be another round of api review and we didn't want to block That on having to figure out a new name Like, you know, I'm sure all of you have tried to name something before it's really hard It's even more hard when you're implementing an open spec that a million people are going to have different people Have to implement the bike shedding is crazy So yeah, so it's really important that we get that right, but at the same time We didn't want to block some resources going to beta for that. Yeah Yeah, I want I should call out reference policy is is far and away the closest to graduating of the ones that aren't yet It already has conformance tests in place. It's we're in a pretty good spot. We just Didn't quite make the cut. Yeah, but because of the rename thing. Yeah. Yeah. And so, yeah, let's swap out. So yeah, look Rob mentioned, you know, we're really the first official kubernetes api to be built with cids We're the first ones to be doing this api review process You know, we the sea with crds as opposed to As opposed to, you know, just doing it in the in the core and having doing using feature gates That's why we've got all of the sort of fancy versioning and the performance levels and a bunch of other stuff Is we're trying to make sure that this feels as close as we can manage To the experience of using upstream, right? But it's delivered with crd. So there's just stuff that's got to be different. So Here's some of the some some of the things that are good, right? Let's go pros and cons First we're not tied to the kubernetes release cycle, right? We can cut a release anytime we like We don't have to wait for the next round of you know, of everything and be and also more importantly be tying up upstream resources talking about these apis when they're not we don't need to be um You don't need to know all of kubernetes because where It's it's a set of crds and associated webhook like it You don't need to know as much about the rest of kubernetes to be able to contribute. So, you know, like we said Please come contribute I would hope you should all be pretty familiar with how you go about installing crds and using them and all that sort of stuff and We are making sure the webhook validation is required for you to pass conformance Well, it will be required for you to pass conformance. Um, the Currently, we don't have the performance test yet But we will be adding conformance tests that will test that the the bits we are checking for in the webhook Get rejected You know and because there's some stuff in the webhook that we're using the webhook to protect you against You know, serious safety errors and some security problems and stuff like that. So it's really important that that gets implemented And but yeah The big part here is that we're part of the kubernetes aio api group That's intended to signal to all of you that this is a real thing. This is an upstream api This is safe to use once it's you know once it has reached your desired stability level It's it's safe to use like it's not going anywhere. It's not some company doing it This is an upstream thing. However It's had some you know, it's made some things really hard Um, we're the first person we're the first people to do this So no, there's no prior art. No one else has done this before We've got to figure out all of this stuff and hopefully do it in a way that other people will be able to copy Yeah, and and make the life easier for other people Um, you we've had to reinvent all the functionality from the upstream release engineering about feature flags and You know, how we how we actually do our features and cut bundles and all that sort of stuff um Yeah, because we don't have feature flags The api version that is the v1 alpha 1 it's just too coarse grained for what we're trying to do So we've had to add the stuff about conformance levels on a port per field basis And the stable and experimental tracks in order to be able to slice that up as finely as we need to And yeah, lastly Designing an api to cover this enormous set of use cases is really really hard. Um, and so it's taking us You know, it's taking us two years just to get even close to beta for some resources You know, like and so but the reason we've taken so long is we really want to make sure we're getting this right You know, like we only get one shot at doing this again You know, like we don't want to end up with a situation like ingress where Where it's just not specific enough and so we're erring on the side of over specifying rather than under specifying Okay, so I want to run through a few quick examples here. I will try and keep this super quick So we have some time for questions Okay, this is a simple hdp route, right? So Most of this should look pretty similar to you if you've done ingress before, you know, like you've got a host name You've got some rules. You've got some matches You've got various types of paths and stuff and then you've got backends, right? So this is basically ingress Pretty much with some extra stuff. It's some extra magic. Maybe it's a better way to say it Okay, so that's and that extra magic is stuff like this where it's the advanced bit This is just the rule section from that object But you can see so you can do header matching query matching path matching method matching and these are ended together So that means that this my service too is going to get only things that have the exact header set The exact query program set the path the path exactly right and the method and the method is get right So that's an and set So that means that you can get hyper specific about what goes to where Um, a lot of this stuff was possible with ingress via Via different implementations and they all had either their own crd I mean, that's what I did on that's what we did on contour or you had to do like a million annotations On your ingress and hope that you know, they were they were relatively portable So the whole point here is this this config Is portable right like any any implementation that implements htp route and influence the extended bits of htp route will work You should be able to pick this up and move it across to another implementation and it'll just work tm Yeah, well should but that's what the conformance tests are for right like the whole idea is if they are both conformant Implementations then they will pass the test and you can be confident that everything will work so Also, we got filters so some of these So request mirror is actually a uh extended htp filter Request header modifier is a I think it's extended to that's extended to yeah I think there is one of the other ones is core. Yeah redirect. Yeah redirect is core. That's right. Yeah, so Um, so yeah, this one is a pretty simple thing. You can you know You can modify headers. You can add set or remove headers You can send a mirror of the traffic off to another service Um, you and if none of those get hit then you go to the to the standard back end Um, okay, so this is again what rob was talking about This is how this is a little bit more detail about how the cross namespace thing I wanted to talk a little bit more about this because this cross namespace thing is a super tricky problem to solve So many things in kubernetes are built around the idea that namespaces are isolated creating references between Uh namespaces that are not extremely that you're not extremely careful with is a huge massive Gaping security hole right like uh, this is why like Contour doesn't support external name services for this reason because it allows you to work around namespace isolation There are other there've been other problems with like endpoints and stuff like that that'll allow you to work around namespace isolation So we wanted to be super careful here that that we're being very careful to keep these namespaces isolated Except in so far as there has been agreement between the two parties that it should be allowed And that's what this is the aim to do the person who owns the gateway has said I will allow routes to attach from this selector now. They could be just like I don't care It's going to be all you know any any namespace no problems. It's all fine But they have the option of doing that right and then the the hdp route has the uh, you Specific is the owner of the hdp route is the one who selects which gateway they want to attach to And we chose not to do a label selector or something like that there So there is a definite action and you as the hdp route owner have to pick which one it is a list So if you want to have your hdp route owned by two gateways That's fine. So if you're moving your hdp route between gateways Say you want to try out like fancy new gateway implementation You just pointed at two gateways and both of those implementations should take the same config and end up with the same result, right? So but the the important part here is it's a it's a two-party transaction, right? Like one party says I'll allow it one party says I want to do it, right? And so that's the same with the reference policy and that's why That's why we have it, right? So in the case that you're doing like the back-end ref thing You know we do have the field in there that you can do a namespace Unless you have a reference policy the your implementation must reject across namespace reference like this and that is because The otherwise I could use this To refer to super secure service that I just happened to know about in some other namespace and but a bing butter boom I am now, you know Representing the the billing system out of line on you know some other 100% not the billing system owned a hp route, right? So So that's that's the idea here is there's a two again. There's a two-way handshake We've got the hp route owner has said yeah I want to point this to a service But then the service owner has to say that is okay I allow that by saying services are allowed to be pointed to by hp routes in the prod namespace Notably you don't have to specify both of these you can only specify You can say all hp routes in any namespace or only or any object in particular namespaces, right? Or you can say all all routes in all namespaces right like or all things So what I the two use cases we talked about um is the um Is as it says back end ref but the other one is the classic You want to keep your key pairs in namespace that only the people who own the key pairs to www.mycompany.com Shouldn't you know should be able to see the private key for that for that? So obviously and so like that's that's what this is is all aimed at doing obviously like I said This is not going to be an 050 because it won't be beta it will be in the experimental track Okay, so We talked we talked a little bit about the graduation criteria. This is what they are We've got the conformance test coverage. We have multiple conformant implementations That is multiple implementations that are passing the conformance tests and There's you know, we there's multiple implementations of actually being used like it's no point us saying hey You pass the performance test if no one's using it And that we need to leave it for at least six months as a beta api before we go to ga I think six months is probably going to turn out to be a little Aggressive we're probably going to want to leave it for longer than that But what we're really aiming to do is just to make sure 100% sure that there's nothing more we need to add Because once we go to ga that is our commitment to all of you that this thing is never going to change ever like ga is forever like And so, you know the We really want to make sure if it's going to be forever. It's really what we want so Well, this is all the stuff we're working on More conformance tests improved like improved ux through fixing up the status right now Um, you know the status is a little tricky to understand. It can be a bit weird There's some edge cases that aren't handled very well Um, so we're really trying to just make that really consistent and really straightforward for you all to understand My my personal goal is that if you are a htp route owner You should only need to look at your htp route to know if something if everything is working Like you shouldn't need to go and find out what gateway you're pointing to and check that the gateway is okay You should just be able to look at the gateway at your route and that's the that's where you need That's the only thing you need to know We've got some new features as rob mentioned route delegation That's you we did some work on this in contour and other people have done similar ideas That's the idea where you can break up your route configuration and have a route sort of Allow another route to attach so in the same way that a gateway Allows routes to attach your route can include instead of a back end and a loud route stands itself It's the sort of the rough design for now Something like that and the idea there is that just lets you Break apart things that have different teams own different parts of the config In the same way that a different team could own the route to the gateway. Exactly the same way grpc route is being implemented the get The design for this has been we approved it. Um, yeah, we're in the process of implementing it Yeah, we really want to do more layer 4 stuff. So those of you who are doing tcp stuff and udp stuff Um, I'd really yeah, we really really need use cases and to talk about it Most implementations that we're talking to at the moment are proxies not Like load balances like not true load balances So they're actually terminating sessions and restarting them and that has big implications for like tcp route and udp route and how viable they are Um, I would really like to talk to people who are okay with that and people who are not okay that and what they want to see Um, so we really desperately need use cases for those layer 4 things. That's one of the reasons They're still in alpha. We just don't have enough information about what's really needed there um Yeah, and we're looking at some more wild use cases like Having a mesh it's a having a mesh object instead of a gateway object So instead of just in that case your routes are kind of describing what happens at east west instead of what happens north south Right. So and so the mesh object then would describe like how everything fits together Not how you get in and out of the cluster Um egress use cases. Um, we've started talking about this. Um, we know people need it Um, but I'm worried that the constructs we have at the moment don't fit well for egress So I really want to spend some time with people who need this to talk about the use cases again There's that thing. Oh, yeah, we need more use cases always need more use cases um and uh cluster ip It's a real stretch call, but it was once mentioned I had I had to add it to the slide But it was once mentioned that maybe we could have a gateway class cluster ip Right, we'll see. Uh, just throwing it out there in case that interests anyone Yeah, so if you do want any of this stuff that you do want Go come to us talk to us about it log an issue And we can talk about it like all pretty most things are on the table at the moment because it's so so early days And if you've got use cases you need addressed Then we would love to do them Um, lastly, yeah Please get involved just like I've been saying um at the weekly community meetings are on monday specific time That's us specific time. I am in australia. So it's my tuesday morning Um, so, uh, yeah, I can't I can't do the time zone math in my head. I'm sorry to tell you what time it would be in central european time but the uh, yeah We do one one meeting a week at the moment. Um, if you need if you all need it We can talk about like standing up alternative meetings and stuff like that right now We just don't have enough people to need it And yeah contributors from l backgrounds welcome like I said we desperately need use cases So if you are interested in contributing to an upstream thing that you're probably going to end up using Please please come and tell us about what you're trying to do if you are an implementer implementing this api Please come and tell us of what your experience about was like Implementing it like we need to know Like what have we missed what's hard to implement like what was easy like the the plus ones are nice too Um, yeah, this is our website gateway api.cigas.kates.io. We are at uh, Cig network gateway api in uh, kubernetes slack, uh, and on github right there That's it. Do we have any time for questions? How am I doing? Two minutes two minutes? I knew you were on on track Do we have any uh, virtual questions? Can we get the uh Yep Can we get the um Tech crew no They don't seem to be in there. Okay. We'll work on that. Oh, so cool. All right. There we go. Yep. Yeah. Okay. Perfect. Thank you All right, so questions in the room And do wait for the mic because we want them on the live stream. Yeah. Yeah, so I think yeah cool I don't sure I am uh, understand This is will be a part of kubernetes if I have a kubernetes cluster in the latest version Does actp out include and if yes Does it come to replace ingress? Does the the future plane is that ingress will be deprecated and there is no Resource name ingress in kubernetes. That's that's a great question. Uh Ingress is around to stay ingress is the simple api. It works for a large portion of the community This is the advanced api ingress will be around indefinitely It is a ga api what nick said earlier ga is forever Gateway api is a new api It as as nick mentioned, this is something that is a crd. It's not dependent on the latest version of kubernetes You could take these crds and install them in a 1.16 cluster But so it is definitely not included as part of your kubernetes install You will need to you will need to install the crd manifest plus the webhook To be able to get the functionality Does there is a use case that I should use ingress and not actp out because I don't I don't see If you if you don't need yeah, if you don't need um the advanced functionality that we talked about with htp route Yes, you absolutely should use ingress Yeah, I uh That's okay. That's okay. I I want just to use A a api gateway not use ingress any any more anytime That's great. Yeah good to hear. Yeah. Yeah, so um, so The I think the the reason to use the gateway api is that you have advanced functionality that is not addressed by ingress You know and so I mean we're hoping that That we can make the api so good that you don't want to use ingress right like that It's simple enough to use and easy enough to use that you can just uh, you know That you can that you want to use the gateway api instead. Yeah, thank you. Yeah, no, right. Thanks And we're at time. So if you want to leave, please do so quietly, but we'll continue taking a few questions Hi, thank you for the conference. So uh question is about Have two questions about ingress. I find it Very interesting use case but also Very challenging to attract the traffic from the cni because it's also cni dependent. That's one question And the second question is could you elaborate on what you meant with cluster ip please? Uh, so I didn't hear the second part. Yeah, I I didn't get what you meant with cluster ip What what what is the use case you are looking at? Yeah, I I can cover that one This this is way pie in the sky theoretical. We haven't we don't know what it would look like It's just hey could could we use these api constructs to represent the cluster ip routing we have today with service And maybe service becomes some a little simpler. I I don't know this is like years in the future theoretical Yeah, yeah Yeah, and so so you were saying about that you're you're worried about getting traffic from the cni with the ingress Yeah, the traffic from the cni right so um, usually we're actually kind of yeah I think we actually kind of expect that Um, people will eventually use like a sort of stacked gateway system Like if you have an ingress controller that is taking htp routes. It may actually use a Uh gateway like another gateway that has tcp routes to sort of expose the to do the functionality that a load balancer A service of type load balancer does today And so right right now if you install a ingress controller a lot of the time It's actually using a service of type load balancer under the hood to create a load balancer to expose the thing That's actually doing the ingress for you and we actually anticipate that that'll stick around I mean that will still be there, but eventually people will probably end up using like an ingress level gateway and Sort of layer four level gateway Does that answer your question? Okay, okay I think we had Uh, so we've got another question over here and while I get to you Uh, the only question online is where can I get the power point from so I think We'll upload it. Uh, we will upload it to to this right after yeah Hello, um So yeah, you're the first project to use crds. Um Are you like Obviously you've had like the teething problems and like the first project problems Um, do you see this is going to become like a more common thing? I quite like the idea of the sort of modular Yeah, it's a more modular element of implementing things in kubernetes Like getting involved in it so yet No, go ahead. Sorry Sorry the the admin network policy api is one that is Following in our footsteps. Uh, so another project under sig network that is working towards a crd based api That's that's a great question. There there are definitely It's not all perfect yet. Uh, but we are trying to blaze a path that makes it easier for others to come We are trying to pull things out of core and make the more module exactly like what you're saying I say yeah, I mean there's a there's an ongoing effort to pull things out of the tree for the main kubernetes and to make it so You know, ideally everything in kubernetes should end like main kubernetes should be ga and not changing very often That will make all of our lives easier when it comes time to upgrade, right? Like the more we can pull out of the tree the better awful it will be Yeah, awesome. I believe there was one more question Okay, yes, that'll be our last question for now So you talked about on boy, right? Uh, so the only way is going to work is on why with istio the istio control plane will translate gate vp Either do something on one understand and on why will then implement? Yeah, so istio so istio is one of the implementations that supports this istio takes the gateway The gateway api objects and turns them into config that it passes to its envoys It's not modified to understand No, so on boy itself doesn't need to be changed because on boys configured with the xds the xds apis and so Anything that you can write as a envoy gateway is all about Take writing a separate thing that doesn't need istio that can take Kubernetes gateway apis and turn them into envoy config and configure your own voice other people You know other implementations ingress controllers use nginx You know other load balances like I think hf proxy and middle of be talked about Supporting the gateway api the idea is that anybody can use these constructs to sort of Describe any sort any level of that functionality and it will work And then if you move to someone else who supports a similar level of functionality Then you can just switch your config over and it should just work Yes, that's the whole idea of the api. Yes is here already supports the gateway api. Yes Actually, I said that would be the last one, but we got one more online. So I'll throw it in here Do you use a reference implementation like kubernetes nginx ingress? so We don't we do not have a reference implementation We don't have any plans to have a a single standard implementation Uh, there are you know, there may be you know, like nginx ingress There may be one that is widely supported in the community in the future that that kind of becomes the de facto one that we reference But that does not exist today Yeah, and we do not we do not ever plan to annoy into like the one true gateway api implementation The the idea is the conformance tests are the source of truth if you pass the conformance tests You're a conformant gateway api implementation no matter who you are And we are planning to have like a bit of a feedback loop where you will be able to like take your implementation Do something with the perform run the conformance tests pass them back to us And we will be able to have a canonical list of these implementations pass the conformance test on this date at this level And blah blah blah blah blah the same as you do for upstream performance You know you get like a sticker that says you are an up a conformant community. It's just right same idea Alrighty, thank you


Okay, so everybody last slot of the day lightning talks We got actually four people signed up here. First one would be oh rules are six minutes and I will do would be hard and forced So ten minutes ten seconds to the end of the talk. We're just we're gonna stand up and applaud So it's very nice and run some way to cut you off Okay, first off it's one two What is this? Okay, I call it distributed ODF applications Where is it? Is it going this way? Okay, so from a bird perspective right ODF applications adjusting can we Toss and toss and I've got a screen problem. Can we switch it that it's fit? Should should it's should switch the screen. It's a it's over here. So I'm Yeah, I'm just a pedantic. Sorry. Sorry. Sorry. I'm waiting six minutes for a brilliant thing I just leave it this way that's it's good enough for me full screen that's much better, but it's it's should be wait a minute No, then it's Why is it working? Okay But but give off the page you know of page feel it Fit page fit page is better fit page is good. Let me switch. That's much better. Okay. Sorry. So I've got one minute left Okay from a bird perspective, okay So every every every we have all the ODF applications Microsoft Office or they have toolkit or so on It's always starting with your load the ODF file into yourself And then you there the state machine the user macros they adding deleting or modifying Document right and at any given time you flush it out. You save it export it to another valid ODF So this is from a bird perspective everything that Libraff is doing right, okay Very abstract right because this is this very important, okay And the next thing is when we have multiple of these state machines working together like here Then and we want to collaborate in a perfect sense like we do with software then we need to You can think of even as not even as three Libraff's versions or Microsoft Libraff So but it might be git repositories and look this about this guy here is adding something is inserting your second paragraph and The others are pulling these changes and this one is just modifying the third paragraph And this one is just doing nothing just receive the changes, right? This is our goal. We want to go that direction so currently we are not able to Receive any of these changes these high-level changes We cannot receive some XML snippets because in the internal model. We don't and know anything about parts we can only load everything and Drop everything so this is very very important if you want to do collaboration that Libraff is learns to Accept changes so these changes are just some high-level Fused changes so what I'm going to do is I'm currently working on I did it tomorrow There this morning that this ODF XML grammar is a nightmare It's a very huge text file with a lot of XML notes. So what I do to answer questions like What is the late? What is the? What is the minimal document? I loaded in a graph database because this is exactly what they can do What is the lowest smallest ODT possible our paragraphs nested at all and all these things you have to look into this long text file And this is horrible. So what I did is you see a lot of using a graph database and Making visualize it and this is only the table table element with all the child elements and The red things are the attributes, right? You can even see it from here. So I I'm going now to improve this graph because this is just an internal model and There are few things that we have to to to skip this To to to view better, but we have to extend this grammar. We have to have a better tooling Otherwise, I mean one otherwise we cannot cope this complexity, right? And this is I think this is the brilliant way to go using graph databases annotate more annotate these changes because we think XML all this now we specified everything but in our lines and all the users minds the user changes of all the same You can in every ODF application you can add a paragraph add to lead a table and so on or like I said Modified format a paragraph ground and we have to define these things and we have to find it in an automatic way and specify this Three so we have something like ODF git repositories like we have real coloration where I can oh here's my pull request, right? You have your ODF book outside and as I read it and said oh, there's a typo I've got a pull request to you and you don't have any ideas you can internally have ideas But you we should be able to have a coloration as powerful or even more powerful than the kid. That's it. Thank you So I'm having a quick talk about this state of labor office at the city of Munich First of all who am I I work for the Linux team since 2016 and I had of development for LibreOffice of the city of Munich and Presenting the city of Munich in the OBS PA and also in the advisory board of the TDF And I'm also working on GIMP dark table and a lot of other stuff, but mainly doing packaging but You may ask wait, didn't you decide to switch to Microsoft Office? not really the government only decided to switch to Windows and The city council will decide in November if they are going to switch or if they want to switch or not so but even if we switch to to Microsoft Office, we need LibreOffice for the next four or five years and at least two or three or maybe four releases and so we are going to continue the development as usual and Also continue our community efforts and the advisory board membership What have we done in 2017? We started development of a new relief for office release based on LibreOffice 5.2 We finally got a new build server which improved building time a lot building for releases at the same time We also started development for one looks 18 Which will be released on one looks net and Jmux did a lot of work upstream on scheduling and bug fixes and We also sponsored a lot of work at CIB and KDA be mostly CIB re-rotating images and Also the border frames you talked about signature lines as I talked about today and improvements in hyperlink sending KDE 5 plasma back ends which is based on GTK3 a lot of work by KDA be in cooperation with CIB and More than 40 improvements in OO XML and also many many more bug fixes and performance improvements and What is to be done in 2018? We want to improve web-duff support Polish with KDE 5 support For our next buzzed line 6 no release which is based on or which does use KDE 5 We also want to roll out LibreOffice 5.2.8 All patches for this version are upstream and back ports are also available on our private branch We are getting rid of more than 100 internal bugs fulfilling a lot of feature requests by by our users and finally getting rid of LibreOffice 4.1 plus 300 or something like that back ports and patches Which is diverging from 4.1, which is upstream And we also are going to start development for the next release which is based on LibreOffice 6.1 We want to make change tracking rate again, but it doesn't crash and But we are going to pay for it ourselves so More improvements of our OO XML support and also at bug fixing and some user requests And hopefully we can host a bug-scratching party Munich last year. We didn't have a chance, but maybe next year. Oh, we'll see you Okay, that's all. Thanks Okay, while Thorsten is preparing the A Website hopefully my website I sent you a link to a site stops in clock Okay We're talking about GSOC as a pro organization we applied for being accepted and Application has been submitted. I have the dates here Announcement if we are accepted will be on the 12th of February and Student application follows between March 12 and 27 so we are Hopefully looking for a lot of mentors and of course students, but since here are more mentors and students I am happy to Be able to announce. Yeah, we have some Success stories from last year that could be you the next year So that's the successful projects from from the last GSOC Season and Yeah, so um, so we've been doing GSOC in one way or the other since I think 2008 back in the day with with OO build and before that I was doing that I think two years with with Sun at open office So roughly, I don't know. Let's make it 10 years of of GSOC Between I think between always between four and twelve students So it's a great opportunity both for For mentoring for getting into mentoring for students. So if you know students in your community or Friends and family encourage them to try GSOC. It's a great thing. You get paid for open source work It looks great on your resume And you get a t-shirt and That's yours Is it really no the left side is for you? Left side is mine. Oh, cool. I got the left side and have two minutes left I'm really happy to have chance to advertise some ideas from the design team We just We have a really large list of topics that Could be improved for instance change tracking. No question Something what I would like to highlight is the addition thing addition means to integrate our Extensions more closely into the program integrating means at the place where you use function you get the chance to add things from a certain place our extension site or if you are in a in a company you could Restricted to the company extension for instance if you are in the templates manager You can click on the link to add a template. You don't need to go over the side Should be a quite an easy thing just a framework it downloads A file from a link kind of configuration should be behind it and the dialogue Sounds quite easy to me Blurry shadows, that's something we really Desperately need we have a really hard shadow a shape has a shape behind and that looks really terrible blurry shadows makes the draw even better if it's possible at all in this sense we could also improve the The lines if we have some kind of brushes so that lines get Looks like scribbled lines. It makes tool a really great mock-up creation tool Font handling I talked this afternoon about font handling we have some topics around font handling where Mentors are welcome. I think students should be really smart if they do work of that Next one. Welcome scream is two minutes left It's not really a welcome scream. We have a problem with user Configuration we are still placing things in in the user directory under slash four and everything what the user Configured themselves in the past is not overwritten So if you update you don't get the updated information and that's not that good The idea here behind us that you can Show a screen for the updated when the new releases Reheable what of the previous Configuration should be overwritten so that user can say yes, I accept it and this dialogue could be used as well for Welcome and tip of the day right so this was all the user experience High-level great ideas That you can really make an impact with and a big splash and the right side is a few sometimes a bit more low-level project ideas just a random Subset of the ideas page page maker this document liberation project for import Domain specific language for UI testing. This is to make it easier and quicker and nicer to write UI tests Smart art that got recently the last year had the import finally done. So now will be great if you could also edit that and Charts and or course or because I say special calc filter import filter Python support for into a liberal officer clips and VML import for writer VML is a part of the OXML standard Okay, and we're running out of time So Yeah, just a summary and two links to the resources Please do go out and advertise Encourage people encourage mentors or mentor yourself or you student yourself. Thanks everyone Okay, and we have I think Olivia, okay. Yes. Let's see if we can see so Here we are I want to show you a very little. Oh my god Sorry. Yes I would like to show you everybody knows in the in the work office that the help files are quite Hard to to write so we had in the past a small extension that allows you to use a writer file and generate a XHP file, but We had some issues with this extension we have some problems, so I decided to and One of the issues that you have to review the XML that is generated and sometimes fix each of the points of the tags, so I Decided to look into Kate Kate is the kitty editor and Kate has a very nice Feature which is some widgets that you can have here and When you click on the widgets you you can generate all the XML and just Insert the contents that you want so I'm gonna just show you how it works. It's very simple. For example, I have this Content which is purely text and if I want to start generating a specific Help file for example, I come here with this. Oh, there is With the here new XHP file so double click here and then he it generates It generates The the XML I can let me So I can here in page topic Write anything I want. Okay. The page title also I can type anything I want and The fun name is automatically generated. So I want now this hidden heading one I want to generate the XML for this heading one and I get here a specific widget Okay, so H1 And it generates. Oh, I'm sorry. So I select I Select and I Double-click on each one and then it generates Paragraph role equals feeding ID This this ID is the most cumbersome Activity that we have to do because each ID has to be unique level X equal one XML language In us and your content here. So if you have For example here, I want Emphasize This Put emphasize into this String I just double-click here and it inserts the tags Okay, so and then I want to trust on that into a paragraph and Double-click and you have all the XML things that you need to do. So quite a fast way to quickly get some contents and generate an HP file and Most of the very boring things that you need to do With the IDs it's automatically generated it's a set of JavaScript that runs in the text and You can have most of the X HP Tags implemented here. So this is what I wanted to show and You can There is a page in the wiki where I describe how it works. So no more excuse for Like missing help pages Hey, thank you Okay, thank you very much that concludes the very last session of the day Thank you all of you for being here. Thank you all the speakers for For great information for great talks. Thank you for them for hosting us and Yeah, I have a good evening and a great Sunday. I don't know. I think