 Hey, thanks Jonathan. Thanks Mark. Hello everyone. My name is Matt McEwen and I'm Jeff Collins And we're here to tell you what we've been up to in the airship projects Now in past summits, we've talked a lot about what airship can do in production as we should be able to Take a look at this little track that we built here So this is the this is the session running through our 5g core And I've pulled the the UUID of the VM that's serving that session and I'm gonna I'm gonna hard Reboot the that VM and what we should happen is Gus should we should have that teaming take effect And we should be able to to hold on to Gus. There'll be a there'll be a slight interruption as a new VM Picks up that session and it transitions, but we should should be able to keep them. So that's now happened and And let's see Gus you're still there Yep, should be reconnecting And now what you what we should see is you'll see in the bottom right We've lost the VM and there's Gus is back Hey guys and And now we have a new UUID For the VM that's picked up this session and today We're excited to share an update on the progress toward the airship 2.0 release Now the fundamental motivation for airship 2.0 is the same as for airship 1.0 to integrate best and breed open source Projects into a platform that transforms declarative yamls into ready-to-go open infrastructure Taking care of things like bare metal provisioning kubernetes and open stack instantiation security and network policy and day-to-life cycle management this declarative model ensures predictability and repeatability across sites and across upgrades the Drivers for airship to include the fact that a lot of good things have been happening in the kubernetes ecosystem Which airships can now take advantage of as opposed to implementing itself Along with the ability to consistently specify and control deployments across bare metal public clouds Open stack and other kinds of use cases The ability to deploy sites faster and with smaller footprints and many other new features and improvements We've also created a web-based UI that can be used to introspect a site and to drive deployments and upgrades Building on airships confirmation as a full OSF project late last year We cut the beta release of airship 2.0 in September and are targeting a GA release in first quarter next year Now although the mission statement for airship 2.0 remains the same you'll notice that the integrated projects doing the heavy lifting are Substantially different and Jeff's going to dig into that now Airship 2.0 uses 10 components to bring up and manage the infrastructure We start with airship CTL Which is the one stop shop client for managing the documents and deployments of the declared infrastructure into multiple target environments We're using airship now for deployments of the infra across both private and public clouds Now we've had several requests over the years to provide a front-end GUI And we're happy to announce that we now have that with airship UI What image builder brings to the table is the ability to to just bring your own YAML and let image builder Do the packaging of the image as either a Q-COW or an ISO Then these are used for generating the bootstrap images for the host machines Which could be a VM based deployment or bare metal in which case the ISO would be streamed over redfish now airship uses customized to remove the duplication of the manifests and Supplying that the site specific changes required such as Secrets for example, and then we have a QB QB ADM as one of the most most popular pieces for managing and deploying the binaries for config of Kubernetes itself There's a cluster API as the de facto standard for declaring Kubernetes clusters Using cluster API. We're now able to deploy into multiple custom customer environments from a single airship CTL binary For provisioning airship uses metal 3 and ironic as the cloud native bootstrap manager to handle the infrastructure resources We're using flux helm operator for managing all of the helm CRs the custom resource definitions Post config for day two operations based on the declarative YAMLs And then last we have treasure map And that's the reusable source for the manifest that gets used as the reference configuration of the target environment So if you want to make a change to the environment It's the treasure map manifest that gets overridden for the site or operator specific changes Which is which we use customized for now We've made a lot of progress since the beginning our work towards the 2.0 release and in Q1 next year is well underway And we'd love to have others join the project either in the airship project directly or in the other projects where you reuse Go to our website at airship.org to get the latest updates and connect with us on how to help and develop