 All right. Hi. Good afternoon. Thank you for joining us at the end of the day We're Maria no end from a red hat. We represent the product team in the business side As well as engineering today, and we're gonna talk about how to modernize the red hat open-stack platform For your operational experience with Kubernetes I will first like to say that this is a sponsor session. So it will be heavy on the red hat part of the You know of the product so if we talk about open sack It will be red hat open stack and if you talk about Kubernetes, it will be in the form of open shift Needless to say it still mirrors very much what both communities are doing. So with that So let's start if I represent the business side So we're going to talk a little bit about strategy So red hat it's been around for 28 years and those 28 years we have caused a lot of disruption and in the open-source community and Provided a lot of value and innovation to customers and partners. So We want to You know, that's very close to to where we are it's part of our strategy But it's also part of how we work and how we bring together and collaborate with transparency meritocracy shape our business Practices as well as the organizational culture In the past few years, we have seen companies accelerate their move to More cloud-centric services either ship based on the pandemic or because that shift was coming already and our Strategy and our vision has grown not just from the data center to the cloud But also to the edge and it's you if you see that Open stack represents sort of the base of that hybrid platform over here And then we see that strategy growing all the way to the edge of course following open source principles collaborating with companies and our latest release open stack 16.2 We made sure that we had features and values that you know represented a good standing for For the workloads that our customers were deployed So in open stack, what can you use open stack for where you can use this open hybrid edge? for obviously You can use it for clouds in the telco space We've heard about that a lot and I will talk a little bit more about that here But it's not just telco a it includes AI ML Workloads like we saw in the presentation earlier today as well as public clouds and to run container-based workloads all sorts of different use cases We have invested a lot in the telco I guess vertical and our customers are really what drive our investments So we have been a leader in the telco digital transformation You know you can see that here both on the infrastructure side being sort of the base for 4g and that's open stack Has been the base for that where we're also a big part of the core that supports the 5g deployments going forward all of this is Also double-clicking on the low key message that the foundation has been talking about Today and as part of the summit of linux open stack and coronet is coming together again for us There will be red hat enterprise linux red hat open stack and open shift coming together to support all of these use cases but in particular with telcos So bringing some examples all of these have press releases and press announcements either from analysts from our customers or from red hat All of these represent different use cases of how this low key stack has been deployed in production And it's currently running. It has been for the last, you know More than five years and it continues to be what drives us moving forward In particular, I wanted to double-click on trick telecom whose trusted Partner customer Messaging that red has been key part of their digital transformation And it's not just red hat open stack although that's a big part of it But it's also all the rest of the red hat services coming together It has helped balance the Investment and made the transformation to digital a lot quicker But we continue to talk to customers and again customers are the ones that are driving how we invest in in in our open source projects and then how we connect to the rest of the community to validate these use cases So in that spirit from the product team, we ask our customers and the market and And analysts etc Where you know what describes your strategy because at red hat that helps Kind of shape where we're going and that informs our strategy decisions. We see that there's a lot of investments in private cloud still and a lot of investment in this hybrid multi-cloud And we see again open stack as being the base of the On-prem kind of deployments But we see that combination happening in a lot of different ways So I will show you a couple of use cases that are in production at our customers deployments and The names have been removed to protect the innocent And our commitment to them But for example in this case The use case to solve or the problem to solve is 5g deployments, right? And we see in this case it being demonstrated as red hat a cm running with open stack director The open stack controllers on one side with open stack running VMs are bare metal and then open shave masters running a sort of side-by-side You know running on bare metal as well with OVN and then out to the edge And an LTE ran. This is what we call shift with stack. So open shift with open stack both Platforms sort of running side-by-side Again, this double clicks on what happened earlier in the keynotes where we talked about it's not one or the other It's more an end and sometimes it is side-by-side sometimes one on top of each other This is Again running in production It shows the benefits of running both platforms It showcases AC red hat a cm as that single plane that allows you to control and manage both The reasons for the side-by-side deployment could be a large deployment of open stack was already present Didn't want to disrupt what was going on and rather decided that workloads that were more cloud native and needed Sort of open shift or Kubernetes to manage The additional growth we're gonna run in open shifts sort of side-by-side both clouds continue to run at the scale that they're needed and And that's addressed that way Same problem. How do we solve the 5g question? Resolve for another use case in production as well with a different approach. So this approach is the shift on Stack so basically running open shift as a workload on top of open stack In this case, we also have red hat a cm and OSP director running the open stack Controlling we have open stack computes running alongside ocp workers and We also have Open stack controllers and open shift masters running together One with it on the other Again the Loki stack represented one on top of each other Not just side-by-side So we see also many other variations, but you continue to see the same thought that it's not one and the other It depends on the use case how we merge this Technologies together Another technology that we are sort of facing out is rev red hat virtualization and in order to Continue to support our customers that run open stack Currently using red hat virtualization to virtualize the control plane of open stack. We invested in something that we call The director operator. So basically using an operator running an open shift To be able to manage the deployment of the control plane of open stack running on open shift. So basically virtualized control planes virtualized controllers of open stack running on Kubernetes and shift and We have that running today in tech preview in Open stack 16.2. So this is out and available and we have a couple of customers running this in production today We see a lot of requests for these kind of Deployment model so that customers can continue to run both open shift workloads and open stack But also leveraging the virtualization of the control plane or sort of reducing the footprint to to run the control plane and other services This one had some of the usual suspects that you may recognize On their left-hand side, you have triple O heat and ounce levels are working together as part of that open stack client and then the hardware provisioning side happens thanks to a Kuvert and metal cube Working together with both the Kubernetes community or internally with an open shift and open stack teams to pull this off to support our customers But this is not where we start. I have shown you today what we have in production today What we have supported today, but where we're going and the next step of how we continue this sort of modernization I'm going to pass This to Owen so he can cover what are we doing on an engineering side? Cool. Thank you, Maria. So I'm Owen. I work with the engineering team The works on open stack at Red Hat Now as Maria has been explaining we've been bringing our product through an evolution And a lot of that evolution is kind of built on the adjacencies between Open stack and Kubernetes or in our product terms open stack and open shift, right? And we kind of overlap in various different ways So I'm going to talk a little bit more detail about some of the efforts that we're doing in the engineering side to To put flesh on the bones here and to make this a reality essentially, right? So obviously this is a big effort, right internally We've been talking about it as our our next generation initiative, right? So we're going to be putting a lot of work into this and it's it's always good to kind of step back a bit When you're kind of embarking on a big investment like this And to ask the question as to, you know, hey, if it ain't broke, right? Why change it? Yeah And it isn't broken right is the I guess not the overarching message from this slide. So open stack the the Red Hat Productization of it. It's currently at version 16 or two, right? So we brought it through many major versions over Over the years we have evolved the form factor of the product We've evolved the deployment tooling right to the point of which it's a very mature offering. Yeah, so basically you've got a fair amount of of You know Options and freedom there Flexibility you can deploy your control plane on bare metal. You can deploy it in a virtualized form on rev Which as Brea mentioned earlier is a long-standing product that we are currently bringing to the end of its life we've got a Scenario whereby resilience and high availability and so on is provided by very mature tooling including pacemaker and system D Our services have been containerized for many years, right? I think we brought this in I might be corrected by some of the engineers in the audience But I think we brought in an OSP 12 possibly so multiple releases into the past It's it's a very mature and battle-hardened thing, right? So it's essentially all of our control plane services containerized and managed on the control plane nodes using podman We've got a sophisticated set of tools to manage your day to operations in your data plane You know, so what do you need to do? You need to be able to do scale out and Upgrades and another day to operations and they're all managed by OSP director as we call it Which is essentially just our distribution of triple O, right? And then we've had various different approaches to telemetry and observability that we have Used over the years, right? So we've got a set of tools like salameter no key collectee and various other You know adjacent tools, right that basically provide Observability, but in a very open stack specific way. That's what I mean by bespoke here, right? So it's basically, you know, something that's that's very much open stack flavored, right? So that's where we're at very mature scenario, right? And it's worked very well for us and it's brought a lot of success to our customers Well, what do we want to do differently? Well, essentially the whole point of these next generation investments for us is around providing a more modernized operational experience for our customers, right? So essentially building upon the operational idioms that have grown up more recently and they're usually aligned with With Kubernetes essentially or or open shift from our productization perspective So what will this look like in in practical terms? Well, essentially we'll take those Currently monolithic control plane nodes, right? And we kind of break them apart so that we'll end up with a set of fine-grained Potified control plane services that are distributed across your Kubernetes cluster. We'll build on a leverage the simplicity of things like the operator framework in open shift We're for replication and failover instead of using a very mature tooling like pacemaker Which you know, it's kind of showing its age at this point We use the simpler and more intuitive patterns around for example the the replica set idiom in Kubernetes, right? the last point there I think is is really a you know one that's kind of close to my heart given my background would open stack but We'll build a more unified observability mechanism that builds on Kind of de facto industry standards and best practices that we see Right across the industry, right? So we'll build on things like Prometheus for metric storage We'll adopt a variant of the node exporter pattern that That Kubernetes uses to export metrics and we'll use Kafka based streaming to essentially stream metrics and logs and events and other pieces of observability data between Multi-cluster deployments. Yeah, so that's essentially the modernization that we're going to provide This is all about incrementally building upon a proven model of success something that's been out there for years And it's worked very well for us and our customers so up to now I've kind of concentrated mainly on the control plane right what about the data plane what what do we mean by the data plane will essentially it's the compute tier with other agents for example neutron agents etc or You know in your hyper converged kind of storage mechanism, maybe some elements of Ceph for example that all run out on the compute tier Right, so essentially we want to look at some of the pain points that have been surfaced up by our customers over time right these are things that Basically could be done better within the product or it could provide a better operational experience So one thing we really want to do here is around this simplification agenda. Yeah, so triple O is a very mature project It's been around for a long time Red Hat has supported it for a long time And over that time period it's evolved to encompass multiple different tools, right? And this is you know, essentially making the tool chain more capable, but obviously adding a bit of complexity as well So we've added things over the years like mistral like heat pop and ansible lots of different things All right, and that's all good in the sense that we're playing to the strengths of each of these tools Right, but it also introduces quite a lot of complexity, right? So if things go wrong sometimes it can be hard to diagnose the source of the failure, right? so the goal here is to essentially and provide a cleaner set of tools, right or Essentially less tool proliferation, I guess right and to essentially rebase it all purely on ansible, right? Also, we know from experience from talking to our customers and we know our customer base very well that upgrades Historically it's not being a particularly pleasant experience with our product, right? And part of the reason for that is the disruption to workloads in the data plane, right now It's improved the measurably over time right the actual Process itself is very is rock solid now and very extensively tested right, but it still has one Real kicker as far as and many of our customers are concerned And that's the requirement to do a reboot see it cycle across your entire compute tier right when you're doing an upgrade So you move to and essentially this is caused by moving to a new version of the operating system, right? So you have to move generally. We have aligned versions of open stack and rail And generally when you do an upgrade, you know essentially up to now You've been forced to move these two things in lockstep, right? So you move to a new version of OSP you also move to a new version of rel right booting into the new kernel Requires you to either, you know, do a cold restart in your workloads or go through that complicated live migration dance that nobody loves Right and and that's essentially the thing that continues to make upgrades Something that would be a point of friction for our customers, right? So one element here that I think will be quite transformative in terms of addressing that pain point is Giving customers the option to essentially decide the pace at which they move to the new version of rel Right and to do that gradually within their data plane, right? So you can imagine a case where your compute here is say a hundred nodes, right? And you decide initially to move 20% of those in new version of rel, right? And then you open a new maintenance window two months down the road You move another 20% and you continue doing that pattern of moving your groups of maybe in groups of racks or whatever to the new version of rel doing it gradually within fairly limited maintenance windows, right and it also gets around the problem that many customers have that the Applications that they're running for example vnfs within their data plane might only be certified For a particular version of rel, right and the ability to leave behind Subgroups of their computes on the older version of rel can be very kind of convenient in the context of that kind of certification lag right now one thing that I think is very You know definitely should be emphasized here is that the data plane will remain external to open shift Even though we're re-platforming chunks of our product on open shift or giving people the option to do that Right the data plane will remain external to open shift now That's for a very deliberate and intentional reason, right and it's based essentially on life cycle Right, so one of the big points of value that our customers get from the way we approach life cycle And when I say we I mean both the red out open-stack product and rel operating system is the ability to continue running the same point version of rel for many years Right, you know for two three four five years even right so basically that kind of longevity Right, and that stability and the ability not to upgrade To a a new major version of the operating system over an extended period of time would be viewed as a major point of value Right, and that's why we're keeping the data plane external to open shift, right? So we'll continue to offer that value to our customers Right, so you look at all of those changes, right? You might ask yourself the question if you're an experienced red hat open-stack platform customer, right? Okay, so you got all of these things changing. That's got to be only for greenfield. I'm a right. I will know Okay, so we realize that basically restricting this to greenfield only deployments and not giving people the option to evolve The pre-existing deployments wouldn't really be a good option for a group for many of our customers Right, so they're in a scenario where they have an existing footprint, right? And you need to be able to evolve that those existing deployments to the new form factor, right? Without having to do a clean rebuild in this essentially, right? So to facilitate that, right? We have basically Within engineering come up with a solution, right? And we're calling this adoption, right? So the idea is very simple really at a conceptual level. So you have an existing deployment, right? And basically What you do is you come along and you build out a fresh control plane, right? You then take the knowledge of the workloads that are currently running in your computer in your data plane, right? And you essentially inject that knowledge into the freshly built out control plane and that freshly controlled Built out control plane would be of the new form factor, right? So it would be hosted on open shift. Yeah So now your new control plane knows all about the workloads, right? And essentially the old control lane control plane is no longer required for all intents and purposes, right? They may still have some services that are still running there For example, you might have had some Seth Mons or something of that nature, right? That you might have to keep some of that hardware around but it's essentially repurposed, right? The guts of your control plane are now Recast in the new form factor, right? And the the beauty part of all of this is that it happened with essentially zero disruption to your workloads, right? All of your VMs continue to run as before all of your networks continue to pass data around as before Etc, etc, right? So it's the point here essentially is this is not for Greenfield only despite the fact that the form factor of the product will change Significantly, right? It can still be applied in cases where you're essentially upgrading from from a pre-existing deployment Okay, yep, so let me illustrate this You know, I'm a bit of a visual thinker here So it always makes more sense to me when I see a picture, right? so imagine you've got a case where you've got a Traditional form factor deployment of red hat open stack platform, right? So you've got your controllers and that's they're running all of the Control plane services in the normal way and you've got just for illustration here I'll just put two computes, but in realistic terms that would probably be a hundred two hundred whatever number, right? So that all runs fine It's all running directly on bare metal and that's the existing shape of the product that we've had true Whatever 16 major releases up to now, right? so essentially the Adoption mechanism will work like this first off you need an open shift, right? because the whole point of this is to re-platform a chunk of your of your open stack and product on open shift to to take advantage of the more modernized Kubernetes operational experience and that open shift has its own form factor, right? It's got masters It's got workers and so on right The actual control plane Elements are represented using the the kind of dark blue Rectangles up at the top there and running on the worker nodes, right? And these are essentially sets of fine-grain Potified control plane services so things like your Cinder volume service your nova API service your nova placement service your glance API service that kind of stuff Right, and that's all distributed right across your cluster, right now initially that's totally empty, right? It's a control plane, but it's not it doesn't really have a purpose, right? It's not doing any useful work for you It doesn't know about any compute capacity, right? the next step then essentially is to take a representation of the data right that basically describes fully the Workloads that are running on your your computer and essentially inject Knowledge of those workloads into the pot a fight control plane, right? So the pot a fight control plane essentially takes over The management of those workloads without disrupting the workloads themselves, right? And it's that without disruption point, right? That I think is is transformative about this this idea now once you've achieved that the purpose of the old control plane nodes is essentially You know, they've come to the end of their useful life Right, so you can repurpose those control plane nodes and from you know at that point forward all management of the actual Workloads and life cycle and so on is all mediated via the freshly built out control plane of the new form factor So that's essentially where we're going to be and we're working towards that, right? There are no good presentations complete without a call to action, right? So Basically, even though this was very product-oriented, you know very much built into Redats DNA is The open source model of development, right? So we're going to be working on all of this in You know fully open way as we always do all the work we do is is essentially done in the open, right? and one thing we really want to build on is our large customer base and their knowledge of the challenges and the problems and The different things that they're facing, right? so we're going to be making a sequence of very regular tech preview drops, right of different tranches of these features as We work on building them out on the engineering side, right? And our hope and expectation here is that our customers will work with us, right? And they'll pick up these drops maybe Deploy them in their staging environment or in pre-prod basically give us some feedback, right on You know what we're doing right, you know what's actually working for them and how they'd like to see it evolve, right? And that'll be super helpful for us to guide our kind of our technical direction here and help us kind of course correct as we go, right? So that's essentially the engineering vision on this. I'll hand you back to my colleague Maria Yeah, so basically to close out we talked about our strategy where we're going where everything is kind of working together. We talked about our customers and some of their Use cases and some of their deployment models. We talked about our strategy also being influenced by their feedback and With that, I want to invite you to later this week to come to this talk where we're gonna talk to Proximus They run OpenShift and OpenStack So we're like, you know, they will be speaking about their experience. They will hear directly from the operator and How all of these comes all of these technologies come together That's it. This is it for us and we're gonna open it for questions now. Thanks Yeah, go for it. I think there's a mic over there if you don't mind, but you can just scream the question We were talking I'm gonna repeat to see we're talking about the migration work How much is that manual work? How much is that automated? You're talking about migration on maybe Option so this compute adoption We're building this feature So it is not automated today for sure Obviously the goal for us more than just automation is to make sure that There's no impact to the workloads. That's sort of the clear principles that we have and the other Second goal would be that there's a rollback procedure or there's a way to back out if something You know, it's just not adopted correctly and and then the third is that In most use cases or some of the use cases that I've talked about where around telco telco windows are for hours Including time to set up do the thing and then roll back. So that has to happen within four hours all of this All of these kind of goals are kind of meant So automation will be high on the list And in addition to that and maybe Owen can expand we will be using Open shift to sort of manage the compute here and then leveraging ansible to do the automation for Then the management of the compute here once that is adopted to the new can compute here Ansible is very good at automation So that that would be something that we definitely will leverage for for that Owen. Yeah, absolutely Yeah, just to reinforce what Maria said the plan here is for it to the whole point is to make it a more convenient mechanism, right? So the plan would be for it to be a smoothly automated relatively painless Operation for you to apply. Yeah, so we're going to leverage on things like the operator framework when the leverage ansible The mechanism as it currently exists is more of a proof of concept So there are manual aspects of it, but the eventual productized version of it will be highly automated Also, another thing this management of open stack Using Kubernetes. It's not new for the community. We understand this is not like fresh innovation Why didn't we do it that before is because we just didn't have an Easier and gentle way to bring our customers on this journey, right? We couldn't just rely on doing a green field only like Owen was talking about like just for fresh new deployments because we don't leave customers behind So migrating and having Adoption being able to roll back to an existing control plane. So like no control plane outage, right? There's actually to control planes. You can always come back here All of those things are in the forefront of for us to think about this technology Other questions Yes, go for it. Yep. So that's good point. Let me just repeat the question there So what did we really mean by without disruption, right? So the like you could say Disruption basically as I was describing it was more around the actual Existence of the VMs right and they're continuing their ability to do work, right? But if you were to have a very strict version of disruption, right? You would probably count a period of API outage where it's not possible to spin up new VMs It's not possible to make structural changes to your cloud, right? So there will realistically be a brief period where Essentially, you will not be able to do Some API operations, right? But it'd be relatively brief and measured in terms of seconds and minutes, right as opposed to hours and days, right? The workloads themselves though will be completely non-disrupted and that's like that's non negotiable That's the whole point of doing this is to have a scenario whereby your The value you're getting from your cloud, right will continue on a baited during this process And I would just like to point out that this description of the process that we are doing again heavily influenced by telcos where SLAs are really high and Workloads sometimes cannot even be moved like you cannot touch it. They're in a remote location, etc however, if There's a customer or a scenario where moving workloads or migrating them to a new hardware Because it is time for a hardware refresh. It has been five years since we had hardware We have additional capex and we want the latest and greatest, you know Hardware accelerators and whatnot and we have the cash to roll out and new deployment by all means We have the means to help migrate workloads when that's needed. It's just that's an easier target Than achieving this but that is also possible. So what we're bringing in is sort of new possibilities to you know with less disruption Also, I would point out that while we were talking about this not being triple low at this point Rahe has no plans to discontinue investment in triple low. So this is not a substitution This is an end today So we obviously expect customers that are running with it to continue upgrading that path This just brings another You know really a true hybrid cloud where both open stack and open shift live together You can expand on one side or on or the other whether it's more cloud-native workloads whether it is more Existing workloads that need to scale Some that you need to keep on prem once you bring an open shift into the mix that opens up to just in a whole other universe of hybrid Yes What are the specific reasons we don't want to do this for the data plane? Okay, great question Some when when you are in in this scenario You could make the case that Computes can also run on the open shift side, right because you see I think worker zero. Yeah There's a worker zero right there that doesn't see it is OSP infrapods Control plane control well, we're saying for control plane But you could you have three control plan and you can have another one That's just a traditional worker node and you could essentially run comp opens that compute over there Fully agreed open shift today has a life cycle that is between 18 to two years 18 months to two years and Does require a quicker kind of turn around and upgrade If the workloads are sort of more cloud-native and can take the churn of those two years life cycles You can absolutely grow you can you can scale that sort of to the left no problem whatsoever However, we work with a lot of customers that have workloads that have to be certified on a specific version of the operating system so a very tight to rail and rail components and that certification process is long and It is disruptive so Customers usually say no, I need this to be supported for a longer period of time I'm gonna run through a certification process with partners and with the vendors of the particular workloads and I need this to Make sense of my investments So I needed supported for say four years five years and that's where we it's sort of traditional open stack with the rail life cycle Well open cycle lifecycle, which is longer four to five years versus a two-year. That's the main reason Okay. Yeah, so just to build what Maria was saying It's technically possible to do of course and we've actually done it like so with a long long running proof of concept project Where we did exactly what you were proposing, right? the The point is though it's all about life cycle, right? And it would be a different life cycle experience where to compute was internally hosted with an open shift And it's not what the majority of our customers want I would I would expand to say also It's all about the workloads like the workloads are the ones that are dictating What is the infrastructure that I need to have to be able to support this and what are the workflows that I have today? What are the workloads that are coming tomorrow? Any other questions great questions by the way, awesome. Yeah, exactly what we were thinking which is Yeah, cool. Thank you so much. Have a great another day Cool. I need to stop bowing. I'm just like, thank you You're right on time at 40 minutes