 Okay Good morning everybody. Yeah morning. I hope you all have coffee or something something similar So anyway, let's let's get started in our keynote slot Glad to see we're so well attended I mean we filled out basically every seat here. So that's good. I'll turn it a fact of the day Okay, so my name is gamma night burger. I'm with rec space and I'm Adam Harwell. I'm with go daddy and We're gonna be talking about Octavia load balancing for open stack Today, so I guess we could give a couple seconds for people to get seated here Well, if somebody quickly needs to run get more coffee we can Yeah, first slide will just be the overview. So you might have a minute Yeah, everybody excited to be here 9 a.m. This morning Yeah, yeah, so yeah, I'm not Yeah, it's the it's the week of load balancing So so you had a talk every day and today is special. We have two load balancing talks. So yeah, that's right Yeah, we're gonna have another project update for Octavia Later today, I think 1150 You have more questions. We'll stop by this and actually As a note, we we've got a lot to talk about But we definitely are saving a good deal of time for questions because I know a lot of people have had a lot of Questions and we're hoping that we can get a lot of those out today Where everybody can actually like hear the answers. So don't be shy if you've got a question like at the end of our Presentation go ahead and line up at the mics. We'd love to actually hear you get that stuff captured on camera I know in the past we've had people come up and sort of talk to us after with all the really juicy questions. So Really like to get those answered in a broader forum Can we do something about the echo? Okay, then let's get our first slide Yeah, so our agenda for today pretty simple. We're gonna do an intro talk about the user surveys for last year and this year We're gonna talk about how Octavia is now an official top-level project. Yes Also the neutron albass merge into Octavia, which is probably the biggest topic on a lot of people's minds right now Why we're doing that and how the transition is actually going Then we're gonna talk a little bit more about Octavia in particular give an overview of that project What's new in Okada? What's new in pike and a little bit about our roadmap for the future and again? There will be a lot more about Octavia specifically At the project update at 1150 so And then yeah, we'll give the the info for that session at the end So the 2016 open-stack user survey was exciting for us We were the most requested networking feature at I think 48% So Thanks guys for filling that out Definitely fill out the user survey if you get it. It's really helpful Information for us to know how to prioritize things so and we're happy to be at the top of that So you guys asked overwhelmingly for software load bouncing and we're gonna try to deliver that And in fact in 2017 we were even more popular Over 50% of people who responded to the survey said we were their number one networking feature So yeah, we're we're trying our best So yeah, we are an official top-level project Three cheers Okay, so we are now the same level as newtron so we kind of eclipse them Yeah, so now that that's out of the way. Yeah, not eclipsed, but but we're up there So yeah official open-stack project We have a number of repositories to take note of our main repository Octavia The Octavia Tempest plug-in for our testing Python Octavia client, which is Just now like just I think actually made its first release a week or two ago Not everything is merged there yet, but we're working really hard on that and by the end of The pike cycle we should have a fully functional client For Octavia and we'll talk more about the client in a little bit, too We've also got Octavia dashboard, which is almost a direct port of the newtron albass dashboard Which we're also still supporting and of course newtron albass, which is deprecated But we're still supporting until Octavia is able to completely replace that it will be marked deprecated Yeah end of the cycle So yeah newtron albass is merging into Octavia So as part of the stadium decomp albass is no longer a newtron sub project Octavia is officially the albass project for open-stack so to simplify code bases we're merging the newtron albass API and Driver support etc into Octavia So Octavia is going to give a super set of the albass v2 API. So we're adding a few things on top of that too And yeah when we're done with this newtron albass will be deprecated for removal So we're hoping we can get people excited about the switchover. There's a lot of advantages to that again We'll talk about in a second And newtron albass CLI and newtron client is also deprecated following the overall newtron clients deprecation I know if you're using that right now every time you run a newtron command you get the little deprecation warning We're hoping that you'll be happy with the Python Octavia client CLI is which is an actual open-stack client plugin now So why are we doing this? So before we were tied really closely to newtron So it was very difficult to run a different version of albass than newtron Octavia itself is actually pretty close to release independent So I know at GoDaddy. We're running pretty close to master On a Liberty cloud which works fine. It's there's a few interesting caveats to that But it really isn't that big of a deal to do that Since we relied purely on the upstream APIs Deployment and packaging will be a lot easier because there won't be a newtron extension it'll just be Octavia and We improve performance and we make the experience a whole lot easier for TLS offloading with the move to Octavia because yeah, the newtron API Integrating that was fun Running our own API server makes things a lot simpler And yeah, we no longer need to modify code and up to three repos to get that done So that goes along with having our own API server we were updating newtron albass and Octavia and sometimes The client it just to get things actually working. So we don't need to do that anymore features will move a lot faster We don't need to maintain state into databases anymore, which is great if you're using newtron albass right now I don't know if you notice sometimes things get a little bit out of sync depending on What happens and hopefully that will Completely vanish because we're going to have one state of truth, which will be the Octavia database, which is Really nice. Let me tell you And this will prevent the albass drivers from bypassing the stable neutron APIs. So right now it's possible for the drivers in newtron albass to kind of Go around the the API's and actually dig straight into the newtron internals Do direct database access etc. Which is really dangerous and can cause some weird compatibility issues and upgrade issues. So We're moving things such that everyone will need to rely on the actual stable neutron APIs Which should make things a better experience for everybody in the long term So for the transition We've provided a pass-through proxy driver for newtron albass So it will just forward all the requests made to the newtron endpoint directly to the new Octavia endpoint There are some other there's a number of other ways to do this as well If you have your neutron API behind a load balancer, you can do Layer seven redirect rules to redirect as well And also the new client will go directly to the Octavia endpoint. So you won't even need to worry about newtron albass We plan to provide some good migration documentation and some tools that'll let you migrate existing load balancers to Octavia That isn't there yet, but for this transition to be complete We're gonna need that because I know nobody wants to be mucking around by hand trying to move these things across So we want to make it as smooth of an upgrade as possible Also, the endpoints can be run at the same time So if you need to run a legacy load balancing solution in newtron albass and you want to still run Octavia You can actually do that and they'll you can go in either through the original newtron endpoint Or we have a new load balancer endpoint in Keystone For Octavia that you can use And so you can actually run them both at the same time until you are able to end of life in newtron albass if that's the direction you want to go and We also plan to provide a shim driver Inside Octavia to allow existing newtron albass vendor drivers to run inside Octavia with minimal changes So I know if you're a vendor You've done a couple of rewrites now of your driver from v1 to v2 and there's some agent stuff in v2 But we're hoping that you don't have to do a lot of work to get the drivers ported over Which is good for vendors because they don't have to do a lot of rewrites And it's good for users because it speeds things up So hopefully that should be a pretty quick process to get that stuff working. That's in the pipe now So hopefully by I think that's on our roadmap for Queens But we'll talk about that I think a little bit more as well or we'll talk about that at the project update No, we have a roadmap in here. Yeah, and then The new open set client will like I said exclusively support the Octavia endpoint directly So if you're still using newtron albass, you'll still need to use the newtron client To access that So we've got a lot of questions about the existing HA proxy namespace driver So we know a lot of people are still using that We don't recommend it. It's not really scalable. Nor is it really highly available if that HA proxy process goes down There's very little to keep anything working. So It also has a lot less tenant isolation than the Octavia solution. So we highly recommend if you're using the namespace driver Sweat look at switching to Octavia You're gonna get a lot better experience and we do Understand that there's a lot of demand for this driver still. We've gotten a lot of concern that it's going to disappear It won't disappear. We're moving it out of tree, but it will still Hopefully be supported by the community which means if you guys are using it we could really use your help maintaining it It will need to be refactored a little bit to work with the stable neutron APIs and the the new Octavia this infrastructure but Won't be our wallet won't be our focus going forward We don't want to neglect it too much because again, we realize a lot of people are using this so If you if you can you if you can give us support on that it would be great We'd like to see it Octavia has been a reference in representation since Mitaka, right? Yeah, you there's been a long time to look at switching over but Again, it's we know it's useful for like Dev and test things We don't recommend it in production, but if you need it it will still exist. It just won't be in tree Okay So let me talk about how our Octavia architecture is evolving Let's give a few ground to a few things to understand Octavia is a very overloaded term nowadays We used to be the reference representation for the load balancer and the API we called albass version 2 and they would be the then we would be like any other load balancing driver like an F5 or Radware something like that. That would be the Octavia load balancer We are changing that to overload the term a little bit more since Octavia We made a name of the barge the project now instead of albass v2 We call all load balancing Octavia now. We also will make it our API endpoint will reside inside your Octavia so so so Octavia will become basically Not only a load balancing driver, but also the load balancing API hosting all the other drivers So so what it means now architecture all the things we had in neutron where albass v2 where we had is Nudon extend albass v2 extension is going away and and People can directly go to our Octavia API to create and manage the load balancers And basically if you go to Octavia API We if it's a quick thing we look it up in the database give it back to you if it's something takes longer like rating a load balancer you forward on the Messaging bus and then our Octavia workers picking up the request and is using all the Using the controller worker driver which we put in almost all of those things and We are very driver-based and it's an m4 driver and we are I don't know if you're familiar with Octavia m4 so we came up with the name of before because it could be in the beginning thought it could be bare metal could be a Containerized load balancer. It could be a VM today. We only have VM So but we wanted to make a but we didn't want to call it VM and then have a metal thing So we came up with this and for our name and in hindsight is confusing a lot of people but the four driver talks to them for us and Tells them what to do Then we have a certificate thing where we can go to barbecue and get TLS certificates So when you want to use TLS certificates with load balancing and open stack It doesn't need barbecue and to manage those certificates then compute right now. We only support Nova Are we also in the community that people would like us to run less with open stack and For networking we support Neutron So basically when we build a load balancer goes Octavia worker talks all those things provisions of VM brings it up gets certificate if that's needed gets a network for it and Configures the load bands are inside the VM or inside the m4 Then we have two more services with health manager Which basically is a watchdog and if one of our load balancers fails will be automatically replaced and Then we have a housekeeping manager Which cleans up things in the database or if you have chosen to do one with the spare pool So we allow you to have a spare pool of m4 ready So they can stand in any time that the housekeeping manager will manage the spare pool So what would you see our system is basically a cycle management solution for load balancers? And trying to keep them highly available and all those things So what is new in Okada with us? So in the past we only supported in our m4. We are running Linux there, too We only supported the Ubuntu flavor of Linux, but since Okada, we can also run Sandress or Fedora or a retell or redhead Enterprise now I'm for We also updated it to have support for Ubuntu scene yell and also system D And we also added support for pkcs7 encoded certificate bundles Then we did a lot of work to prepare for this big change where we become the top level project of our own API endpoint So we've added in a keystone authentication for the Octavia API. We put in The are the RBAC policies so you can kind of put roles in who can do what on our Octavia API And we also added quotas in the Octavia API So now if you're running a Newton albass and Octavia together, you've got to see that the quotas match So you don't want to have mismatch quotas because then it gets confusing for users Per default we switched the quota system off in Octavia. So if you configure that keep that in mind Okay, what are we planning for pike? So we are we want to release our you new v2 API endpoint Which we call the load balancing endpoint and then you can directly create load balancers in Octavia Without going first through neutron albass The other thing we did we we worked a little bit on deployment So what we heard a lot from people is it works great in depth stack and then was very difficult to deploy That the whole Octavia system in a more production like or even in a multi-node setting and so we Develop an open stack Ansible role to install Octavia. So if you're using open stack Ansible, you can now do that and Then we are also getting triple O support So since we have have now one role and people can see how it's done the triple O people looked over that and and They're making now support for Octavia, too And we have so we have full support for Python 3.5. It was one of those housekeeping things Open stack wanted to do We are doing doing the open stack client plug-in as I said, it will be as you said It will be exclusively for the Octavia API that's part of our migration deprecation strategy is that we don't port the new don't albass We to command line client which is part of the new don't client to the open stack client world So we so we start fresh there with a client which exclusively targets the new API endpoint We also added a single call create for fully configured load balancer So so before you had to create a load balancer I'll listen our pool and so on and we changed that because there's always the thing There's a thing get me a network get me this and so we made a single rate Corvia can just give us a Chasen document which defines everything you need from the specific load balancer and we will create all the elements for you I also added as we're going to add cascade delete so I can delete a load balancer on all its Children basically all his child objects, and we also added the proxy protocol support. So for So basically there's a proxy protocol Which age a proxy our the load balancer we run inside them for supports and which you can wrap Sphinx inside and I have a couple notes on this also, we do have roles in cola and cola ansible so you can use those to build Docker containers for Octavia and We just merged the single call create and cascade delete this morning actually so those are now in master And we'll be released in pike. I'll note there was a bug That allowed deletes to function like cascade deletes kind of so if you're wondering What's this cascade delete thing? It kind of functioned like that accidentally before but it wasn't fully there so you would have gotten a little weirdness this will allow you to as a query parameter say cascade Equals true, and it'll actually fully delete the object tree Otherwise your delete is going to be blocked on a load balancer object for example if it has any child objects so Look forward to that actually functioning properly in pike forward Okay Okay, so a little bit about open stack ansible since that's that's the thing we we wrote So man's opensack ansible is a project to deploy deploy open stack in a Production cloud as I have an all-in-one So if you just have one computer can also use it to deploy open stack and they deploy all the control plane things in containers We created a new Octavia ansible project So they they do everything it goes in there I guess it's on project that will deploy Octavia and configure it when they graded it So if you say I want Octavia in there will automatically configure a nude one to Point to Octavia and everything And we and it's flexible So there's always a thing about how to do the management network in Octavia How to do certificates how to do the and for images you can configure all of that to your needs There's a support different apologies basically if you're saying I want so I've seen our control plane has like for services API So and you can decide if you want to have all of them on specific hosts Or just some of them the way you want it and we also incorporate some of the best practice from our deployments So for instance we put IP firewalls in and things like that to keep it safe and it has been deployed successfully somewhere and We as of documentation for that so so documentation and that's up there on there On the developer documentation so you can read through that if that's interests you and the good thing about it is if you are developer of Deployers, then you can look to how we done it and kind of do it in other things like they did with triple O Okay, so let's look at our roadmap And of course, it's it's all everything we say is subject to change because there were guarantees of doing Open stack open source development. You can't really promise anything but our plan for What if I didn't know Carter was this things already talked about native quotas framework for the API This cycle we want to complete the API and we wanted all those things I talked we talked about The future is what's interesting is we are still working on the active active and four things So we still want to horizontally scale Things right now. We only offer active passive as our with As our reliability model, but you want to move to active active so you can scale things So we have we have some patches sitting there which will introduce that but I've gotten stale There's often you contributing new contributors Have promised to come in and help us with active active It's which gives us the for the horizontal scale. We are looking forward. We're also Thinking about container supporters that earlier them fork could be a container and we were pretty close to have it run with Nova LXD, but there were some bucks in Nova LXD. So it doesn't work It's not on our side. It's on their side. If they fix that Maybe maybe that's we can get that in in the future, too Yeah, I think we proposed something so hopefully we can get that Taking care of sooner rather than later because it would be really nice to be able to deploy in containers I know a lot of people have been asking for that. So We want it to it would make our gates work a lot better as well. So, yeah So so so this is then of course in a container where we always get asked So I don't need to blow inside kubernetes. I don't need the boy with dog on all those things It's all of that is possible and we might do that But the closest we have is Nova LXD right now the other big thing we want to tackle and which is important to us is the flavor framework support because right now you can only specify one Nova flavor for your load balancing VM, which is not sufficient because Because then you have to do one size fits all and especially if a specific hardware, which for instance does As a VI also have you you have the network card kind of going straight into the VM Then you might need other flavors so you can target maybe high performance high performance hosts for a load balancing less performance or you want to do TLS offloading and So so we want to have flavors so you can basically set up specific things and say flavor orange is for high performance less offloading Blues for high performance load balancing and then green is for yeah, not that high performance Yeah, and flavors will also help us with multiple providers. So we're hoping to have it so you can run either with the Octavia back-end which is to say the service container VM framework or third-party vendors like f5 or a 10 or the many others that we support Or so you can run them at the same time and have people specify like I want a hardware versus a software solution as a flavor Yeah, also flavors as of when we talk about the hardware vendors a lot of them have Specific features. We don't support in our API because not everybody has them. We want to be something everybody has and so they are hoping that for the flavor framework support Users could unlocks specific features in hardware load balancers That's also one of our stated goals if you want to use some something specific only a five has or only right where has Flavor will allow you to do that. Of course if you do that, then you're locked into those people because other Other load balancing back ends might not support that almost So we have one more session today, which is the project update and we did a bunch of other sessions if you're interested in In other aspects of our load balancing thing, then you can watch them on video but now let's Let's get to our Q&A as we can get it So if you don't want to if you don't answer all your questions today You can always find us in our IRC channel open stack albass if you find a bug Please be so kind and go to our launch pad and report the bug And if you want to contribute you can go to our github and our documentation will be It's still working out. So it's a big push in Pygis So improving our documentation and our documentation will then be on Octavia cloud if you want to DM us directly and I'm ex-german Yeah, I'm RM work and our fearless leader is John Song So who couldn't be here today, but but he made lots, but he made a slide so Good stuff. Okay questions Yeah, any any questions. I know we've gotten some really good ones, but people tend to be shy But please like if you've got a question, we'd love to answer it for you. Yeah, I Don't have one actually on Octavia per se, but I just want to know in load balancing in general in open stack So in the past we had albass v1 then we say no, it sucks. We'll go to albass v2 now Octavia I always good reasons to trash the previous one and go to the new one But it's always a pain to go from one to another you have to understand how to install that be that beast And fight with that and migration. It's another nightmare. It's more trash and replace Is it the last one or in six months somebody else will say hey that sucks as well Octavia and we'll have a new one again Well, so we've been working on this for probably the better part of four or five years now I mean, this is the end goal of about five years of effort. So we had to go through several stages Even at the beginning of working on v2. We knew that this was the end goal There were a lot of politics involved some various other factors Let us to have to create the API under neutron albass and then move it over to Octavia So again, it's it is the same API. So the API Should be like just drop-in Replacement compatible you should not notice a huge difference Between the two so basically if you're running Octavia today Nothing will change for you except you have to change some endpoint if you're not running Octavia today that will be More difficult situation So the the vendors promised us they will provide migration tools to their customers if you go there So so they say if you're with a vendor they will migrate whatever is in the database over there and we want to make a migration tool for the haproxy namespace driver But so you can reassure us nobody is working on a new albass project that will say this one sucks and Given how long it took to get us to this point and that this has been in planning for five years I mean, I can't promise that five years from now there won't be another one, but No one is working on one at the moment. So No, no, yeah, we are not but but we can't give any guarantees. There might be a project somewhere. We don't know about Yeah, no with an open stack load balancing. This is this is the thing that we've been working towards So we're really excited to finally get this done. Yeah Two questions if I may sure on your operating system support for the M4 image How does how does a new operating system get supported? I mean, what would be the process if you wanted for example to add open SUSE So we use disk image builder, which is another open stack project to build our M4 images It has an element system So basically you would need the base elements for how to get a SUSE image Like how to retrieve it and get it up and running at a base level and then from there We you would need to edit our Our elements which are inside the Octavia tree That allow like the our agent to be installed and our tweets to happen You just have to edit those to understand the specifics of SUSE's like operating system Yeah, there are always a few wrangles. So so we do network stuff which is different And so you would have to adjust our so we have something we call them for agent which runs there and does our networking For us basically the other thing does that if up and Configures the interfaces and I know we had and I know we had to change that For for redhead so we had to make that more driver base So you can so the thing nowadays now the conversion detects the operating system is running in and then uses appropriate ways of bringing up Right. Yeah, it's actually most of that stuff is based on ginger templates So you just provide the ginger template for what the networking configs or various They the init system looks like on that system put in the like if SUSE then do this and you should be good and there now that we have Support for two that was really the the big jump So you should be able to look at what was done to support our HEL and and like distributions and just clone that for Yeah, we'd love to see support for more Yeah, we are definitely not not against it. It's just it's not our priority to develop it ourselves So yeah, and then one of the follow-up question when you talked about cascading not kind of not working So is it just always a manual cleanup then or is there a better way to do it? No No, the way it works is it when you say Delete then if I delete something I tell you have to delete other things before you can delete the certain thing so yeah, so right now basically it Should have blocked you from deleting and actually so I will note This is only in Octavia that I'm talking about so if you're using Neutron albass. I think it should have been okay Probably this doesn't apply to a whole lot of people But if you were if you were already running Octavia, there was a bug in the delete system But that is cascade delete will clean up everything Appropriately it'll be great If you don't specify cascade and you try to delete an object that has children it will tell you you can't do this It has children go delete those first and that's in piker. Oh, that's in pike And again only if we're only talking about Octavia there So Neutron albass should have been fine and probably most people are still running that I wouldn't assume. Thank you Yeah, I had a question on the on the shim driver that you're talking about for our for the For the vendor drivers. Yes, I was curious if that is for an operator to use to to to integrate a current driver with Octavia or is that for the Vendor to use to make it easier for them to create a new driver It is for a vendor to use because some of the vendors they They go in the database directly to do things and the Neutron database and when they run on Octavia That won't be possible anymore so they would have to give you a new version of their driver which Tested and works in this new thing But the shim layer is there to make it easier for them that they have to do only minimal changes Not depending on how the driver works, but yet that nothing changes upstream up on the API interface for them And we as a discussions with them where they wanted more features just not the features they had right now for the LBSE to plug in but they want a new features and we are still on the fence of Let it on the fence how to kind of do it if you do a shim driver and then make something few features or extend it Or if you start a few features right away, so it's still a little bit on the fence how to do that perfectly Yeah, no We definitely we heard a lot of feedback from vendors that they were tired of rewriting their driver for every new thing to come along So this was yeah, it was a tool for that to aid them primarily as an operator We hope to just have the same vendor drivers that you're used to shipped with Octavia already So you shouldn't have to do anything and yeah, we're also the shim driver is is to allow for that quick port But it's also possible for a vendor to write a driver against Octavia natively as a provider and That would actually allow them to do a lot more customization like everyone was saying so add more features and stuff like that And and is there a is there a timeline where the existing elbas features in neutron? Will will no longer be there and we need to make sure that that that our vendor has definitely updated their driver by a specific release so I mean right now like I said the The shim should be ready along with hopefully at least a couple of the vendor drivers by Queens It would be awesome if we had all of the vendors over by then But I can't commit to that because I'm not them Deplication plans so so we are there's a little bit on the fence if you announced application this cycle without a shim driver If we wait until if the shim driver next thing so basically you get at least from So if you would go and be aggressive and announced application this cycle, then you have at least two more cycles before Yeah, I don't think that's gonna happen I think the deprecation will probably happen in Queens along with the initial shim driver And even if we do announce the deprecation until Things are stable to a point where we expect people can actually move over We're not just gonna delete everything. So, yeah Yeah, we don't want to leave you guys high and dry Thank you very much appreciate it. Yeah Okay, I believe as part of Elbas the ml2 plug-in was required for neutron Is that gonna continue with Octavia? So we are not With Octavia, we don't really look at the internals of neutron. We use neutron as essentially as a client So we call in the neutron just the same as a customer would However, neutron handles its networking is fine by us So I know I think the ml2 driver may have been for specific Implementations some of them plug into the network to kind of route the traffic out of your cloud into their Device and back and then they needed ml2 integration and we talked to some of them Then they say they will now maybe make something for neutron to get that functionality in some for Octavia But so yeah, I can't speak for specific vendors. So if you have one that you're using I would definitely reach out to them and ask them how that's gonna affect you But as far as Octavia is concerned, we we don't really care about the as fast Internals, yeah Octavia the load balance on Octavia the API Hi, my question my question is Neutron low-band service version to support TCP or UTP protocol Octavia in the future is also support TCP or pull or only support HTTP or HTTP as a protocol we do support TCP protocol I don't think Neutron albass supported UDP did it. No, no, we're not Supporting that moving forward at least yet. I mean if someone wants to contribute support for that great Our back end though, I don't think supports doing that So the background story for that is there's no good open source UDP load balance So we can plug in in the back. And so we only support TCP based protocols HTTP HTTPS and so on Yeah, but yeah, we will support just TCP load balancing So there's a lot you can do with that. And yeah, we use we do at the moment use HA proxy for Octavia's back end That again is a driver. So if we have folks from like any other load bound open source load balancing System we'd love to see like integration with you guys as an option for our back end But right now it's HA proxy base. I don't believe it supports UDP load balancing That's all the UDP load bands and cases are usually very rare. So that's the other thing Yeah, I know I know there are some use cases for it, but it's yeah, it's not very common So we're we're trying to solve for the the 99% use case. Okay more questions Did we answer? Oh good Do you guys plan on doing SSL all the way through going through I know you guys do offloading but A bit a lot of our client especially in the protected environments. They like 443 all the way through. Yeah, we do that You can just yeah, we have HTTPS Full so we don't encrypt it just hand it over Yeah Pass through but what we don't do is that we decrypted the load balance and then reencrypted and send it on yeah I would love to actually see support for that. I think HA proxy Does support that just as a flag basically we just don't have support for it yet But I mean it's something that that I would love to actually see us do It's just we have to figure out where that fits on our roadmap But granted our roadmap is just kind of for the Contributors that are working on this like full-time if you want to submit like a patch to help us support that will be Very glad to review that and help you out Yeah, right now we do pass through if you need re-encryption We don't have that yet Hey, are there any recommending tools or methods for migrating your load balancers All your vips for example between provider a provider B or flavor a flavor B Are there any tools for those type of migrations? I don't think we've provided anything around that or Not sure if there are any that we know of because it's it I think it is gonna depend a lot on the specific vendor to the specific vendor that you're doing Because some of that stuff Gets very strange under the hood Yeah, I think it would be it would be very hard for us to provide something. That's kind of a one-size-fits-all solution Yeah, it's yeah, it's I can't say that we have anything like that right now But yeah, thank you. Are we How are we doing for time? See people filtering in we may be every two minutes behind. Yeah, so okay. Well, thank you guys for coming. I have to go sit now Thank you guys for coming