 Good day. In this session, we will be providing you with an introductory overview of the AERSHIP project with a focus on our upcoming 2.0 release. My name is Andrew Karanja. I'm a principal system engineer with AT&T and a member of the AERSHIP community with a focus on design and requirements. And my name is Drew Walters. I'm a professional software engineer with AT&T working on their network cloud, as well as a member of the AERSHIP working committee. So let's jump right in. What is AERSHIP? AERSHIP is a collection of loosely coupled but interoperable open source tools that declaratively automate cloud provisioning. AERSHIP consumes a collection of YAML documents that define a site and turns them into a functioning cloud. This includes Kubernetes manifests, bare metal provisioning, network definitions, and more. AERSHIP orchestrates one simple and repeatable workflow for both deployments and updates. This is perhaps one of AERSHIP's strongest features. AERSHIP allows you to consistently and predictably deploy multiple sites substituting the specifics for that site in an automated fashion. The process for updating a site is effectively the same as the initial deployment. You feed AERSHIP a set of YAML documents and it performs the updates. AERSHIP does not require operators to develop their own set of complex orchestration tooling to automate AERSHIP. AERSHIP uses containers as the primary mechanism of delivery and takes full advantage of native Kubernetes resiliency, including health status, pod restarts, restarts, and so on. AERSHIP leverages native Kubernetes security features like RBAC and roll binding. With AERSHIP 2.0, AERSHIP also provides integration with DEX for external authentication and provides tools for secret encryption, decryption, and rotation. While AERSHIP provides out-of-the-box templates that aid in defining a site, it's incredibly flexible and allows operators to deploy any additional software that's required and also supports customizing site definitions as needed. Next, we'll dive into a little history of how AERSHIP got started and where it's headed in the not so distant future. In 2016, the OpenStack Helm project was initiated. Why is this significant? While it's a separate project from AERSHIP that can be considered a companion project, it was the first step in the journey towards being able to deploy and manage all software and hardware in a site via Helm charts. In 2017, the yet-to-be-named AERSHIP project was initiated in collaboration with SKT, Intel, and AT&T. AERSHIP formally launched as an OSF pilot project in 2018 at the Vancouver Summit, and the first release candidate was released in Berlin later that year. The AERSHIP 1.0 GA release was announced at Denver in 2019. In October of 2019, AERSHIP was confirmed as an official OSF project, and today, AERSHIP 1.0 is successfully running 5G workloads in production at AT&T. We did not stop there. Building on the foundation of 1.0, the community has been designing and coding the next generation of AERSHIP. The Alpha version of AERSHIP 2 was released in May of 2020 with beta releasing at the end of last month in September. We are shooting for a general release of version 2.0 at the end of this year or in early 2021. While AERSHIP 1.0 is successfully running workloads in production, we've learned a lot along the way in taking those learnings into consideration when designing AERSHIP 2.0. One big takeaway from 1.0 was the complexity and challenges of updating the AERSHIP components themselves. AERSHIP 2.0 solves for this by introducing the notion of an ephemeral under-cloud control plane, or EUCP. The EUCP is a control plane that is 100% transient. It only exists to run when necessary and removes the need for long-running local components beyond the basic infrastructure. The lack of a local EUCP improves the security posture by reducing the attack surface area of the infrastructure and also by reducing the complexity of the components that need RBAC protecting. When AERSHIP was initially conceived, we created several custom solutions for site provisioning and software management. In the time since AERSHIP 1.0, many best-in-class open-source projects like QBADM, customized cluster API, and helm operator have reached maturity. By leveraging these projects in AERSHIP 2.0, we're able to greatly reduce our development overhead and technical debt. A new AERSHIP component, AERSHIP CTL, provides a consistent interface for these other components and introduces additional features to easily manage the deployment process. A benefit from this approach is the fact that AERSHIP will support a wide array of deployment use cases, including BYO infrastructure, third-party public clouds, virtual machines, and bare metal. This is achieved by utilizing cluster API and its supporting components. Another goal of AERSHIP 2.0 is to reduce the amount of downstream customization of manifests. AERSHIP will provide out-of-the-box type and site templates through Trezermap. Leveraging customized and various replacement catalogs, AERSHIP 2.0 will improve the substitution of site-specific values in a more real-time and automated fashion. This is an improvement over 1.0, where operators were required to download the entire contents of Trezermap, then fork and modify them locally. While we're on the topic of documents, a lesson we learned in AERSHIP 1.0 was that expressing a site as a complete set of document declarations was challenging to manage and mentally digest. In AERSHIP 2.0, we represent lifecycle management as a series of phases that simplify how a Kubernetes cluster is built and subsequently managed. Phases help people deal with a much smaller document set that are granularly scoped to particular objectives. AERSHIP in a pod improves the onboarding experience. It provides a single containerized execution environment, which can be used for CITD, demos, and development purposes. AERSHIP 2.0 also introduces the AERSHIP UI, which will allow operators to visualize and manage document sets, integrate various tooling dashboards, and will integrate with the AERSHIP CTL command line for execution purposes. And on one last note, in early testing with 2.0, we've seen significant improvements in the deployment times that will be compared to AERSHIP 1.0. There are a number of components that make AERSHIP 2.0 possible. At the top, you'll notice we have AERSHIP CTL and AERSHIP UI, two tools that are at the forefront of integrating and orchestrating open infrastructure in AERSHIP 2.0. We took these tools and designed them from the ground up with operators in mind to allow them to easily orchestrate deployments and visualize their infrastructure. These two tools drive the rest of the ones you see on the screen, like the image builder. The image builder is AERSHIP's way of supporting declarative intent for the lifecycle of bare metal hosts. And it does so by producing a reusable ISO or Q-COW image that can be used to deploy hosts for the first time or redeploy them. What this means in practice is that bare metal host upgrades in AERSHIP 2.0 are predictable and efficient, customized. We took customized, which is a widely used tool in the Kubernetes community for customizing YAML documents. And then we developed a model on top of that that allows for deduplicating and representing declarative software intent. AERSHIP CTL understands that model and allows operators to quickly preview and then apply rendered documents. QVADM, Cluster API, Metal 3 with Ironic, and the Flux Helm operator all make managing the lifecycle of AERSHIP 2.0 simple. AERSHIP CTL drives these tools to facilitate bare metal cloud provisioning, make the lifecycle management of Kubernetes easier, and make the lifecycle management of your software easier, all while supporting the tools native document sets. The host config operator is AERSHIP's day 2 host management answer. It allows you to configure things on your host after a site's been deployed without actually the redeploying host using a new image. This can include things like permissions configurations, host package management, or even just executing arbitrary scripts. That and much more is supported by the host config operator. And finally, you'll see TreasureMap. TreasureMap is still an integral part of AERSHIP, even in AERSHIP 2.0. But rather than being a library that's forked and modified as Andrew mentioned earlier, TreasureMap provides a robust set of functions and templates in AERSHIP 2.0. And as an operator, you can inherit for your deployment needs and build on top of. The AERSHIP community strives to keep our project open source, our design transparent, and our community as well as our development process open to all. Here are some changes that we've made over the last few years. We've evaluated the frequency and scope of our community meetings. This includes the IRC meeting, which was recently moved from a weekly meeting to a bi-weekly meeting. This has allowed us to keep our agendas more focused and also get more participants as the meetings don't happen as often. We've established a publicly accessible Slack channel for working in technical committee discussion. Just by joining the Slack channel, members of the community can be a part of the planning process, which typically used to happen over email. We've expanded the purpose and scope of the AERSHIP flight plan meeting. Every Wednesday, the AERSHIP flight plan meeting plans for upcoming milestones by reviewing issues that have been submitted on GitHub to the various projects and then prioritizing them for developers to work on. Now, with the expanded scope, we've been able to include release planning and release tagging. We've also adopted additional collaboration platforms used by Kubernetes, things like GitHub issues that have allowed us to work closer with those projects. You'll notice, though, that we're still using the best in class open-dev tooling, including Garrett and Dool. Thanks for your interest in AERSHIP. We sincerely hope that if you have questions, you will join us in our mailing list. Or we also invite you to our AERSHIP IRC channel, which is hashtag AERSHIP and on free note. And of course, our Slack workspace, AERSHIP.org slash Slack. There you'll find more members of the community who are happy to answer any questions that you have and look at specific use cases. Thank you.