 OpenShift Commons briefing today as we like to do on Mondays. It's an Ask Me Anything with either a project or an upstream project or a product or a new initiative. Someone's kicking off. And this week, we have a new community manager, Melanie Core, with us, who's getting the pleasure of managing and herding cats for pulp informant. So welcome, Melanie. And we have two folks, Eric Helms from the Foreman Project and Dennis Kilden from the Pulp Project. I think, yeah, it's right there in front of me on the screen. I should be able to see it. And these are faces that many of you probably have known and seen in different aspects of Red Hat projects and products and stuff. And Pulp and Foreman both have been around for a while and are very heavily used in the side of Red Hat and outside of Red Hat. So I'm really psyched to have them come here to give us an update on what's going on in each of these projects and for Melanie to take over the reins of managing these cats. And so Melanie, tell us a little bit about where you came from and your new role. And then let's rock and roll. Learn more about Foreman and Pulp. Thank you, Diane. And thank you very much for having us all here today. It's a pleasure to be here. So first of all, yeah, my name is Melanie Core. I have been with Red Hat for just over three years now. And I've been working as a community manager for almost exactly six months. And quite interesting. So before community management, I was working with Red Hat Satellite on the documentation team, leading that team for about 18 months. And so I suppose the bit of background, the Foreman project itself is 11 years old. And from a lot of that time, they had a dedicated community manager. When that community manager, Greg Sutcliffe, decided to start exploring career and data analysis. A lot of the roles were divided amongst different people for the community. But then after about a year, they decided it was best to maybe dedicate someone full time. And for the last six months, I can see that there's an enormous amount of herding cats and an enormous amount of traffic on our discourse to ensure that our community is well served and people get answers to their questions and demos run. I think it is important to have somebody leading that herding, poking people. So it's been an interesting few months. And then on the other hand, there's Pulp, which is also a very interesting project and also feeds into Foreman. And I've been working with them to maybe grow the community a little bit more. So this year has been also extremely interesting because we haven't had any live or in-person meetings or conferences. So we're all here together from all different parts of the world meeting in new ways. So that has been particularly interesting. We had our first ever virtual hold-con this year and our first ever Foreman birthday party. And so I was quite excited and delighted that we got to meet so many faces that we wouldn't have otherwise. And I think, unless I knew of any particular questions, I think that's pretty much everything that I can say to introduce myself at this point. So if not, I'd be very happy to hand over to Eric Helms for his first demo or piece. All right, Eric. That's great. Well, welcome aboard. And thank you for taking on that challenge, Melanie. It definitely is. And Pulp Con and the birthday parties are always fun for Foreman. So Eric, tell us a bit about yourself and then maybe quickly Dennis so he doesn't feel left out. And then we'll go run into your presentation about what's going on in Foreman and where it's going. Okay. So I've been at Red Hat for like nine and a half years. And I started as an intern working on what is now a plug-in to Foreman. But you can effectively say I've been working on part of Foreman and its downstream product that Red Hat makes called Satellite for the whole nine and a half years that I've been here. And so I've seen a lot through the community. And more recently, I moved into an architect role within Satellite, the product. So I get to look at the ecosystem with a different light and think more about how we build and how we shape the community. Dennis, you're up. Tell us about your role and how you came here. Yeah. So I'm a senior software engineer. I've been with Red Hat for about seven and a half years. I started out working on a project called Image Factory that was part of CloudForms. However, when I joined, we had purchased the company to replace CloudForms. So I had to find another project to work on. And I ended up working on a pulp, which was great because I was already friends with the folks that worked on pulp. They sat near where I sat. So I felt like I was part of the team before I even joined. And so I've been working on pulp for six years, maybe more. And for a lot of that time, we've been rewriting pulp. And I'll talk about the rewrite of it whenever it's my turn to go after Eric. All right. Well, thanks. And I'm really grateful that you're all here today. So thanks very much. And it's wonderful to see faces from all the teams too. So Eric, why don't you give us your spiel and your talk about where Forman's at today? It's nice having the historical perspective too. So take it away and share your screen and we'll rock and roll. All right. I will do my best. While I get that Sharon, a fun fact, Dennis and I worked at a lab on North Carolina State's campus before we both moved on to Red Hat. Yep. We have a long history together and we just happened to land here doing this together. Yep. I was so glad to see that you were the one I'm doing a talk with. All right. Just check that you can see that. We can see it, but it's not full screen yet. So if you pop it into full screen, there you go. Perfect. All right. Take it away. All right. So I'm trying to give my best view of what Forman is and some of the evolution as I talk through what it is and why you might want to consider using it. You can think of it, plug it into your brain, that it is a life cycle management tool aiming for your data center and the hybrid cloud. It's going to give you a single place that you can come manage all your various real estate and concerns in the same way and in the same place. You can look at this from a green field or a brown field perspective, depending on where you're at in your evolution, whether you're an individual or a group or a company, whether you're new or existing, you can approach it and you can look at it kind of a lot of similar ways at least towards the end of the story becomes the same in both cases. It's just a matter of how you start. So think of and I'll go into what these things kind of mean or how we look at them as the Forman project. But you start by defining what it is that you want to, what you're planning to create. Is it a web server? Is it a database server? Where does it live? Is it on a cloud provider? Is it on bare metal that you have? What are the properties of it? Your networks, your domains, your subnets, maybe what content it has, RPMs, files that you want on the machine. You can create what you, how you would define these things. And then if you're in a green field situation, you can start by trying to define these things. Then you can move to provisioning bare metal hosts as cloud machines based on the definition that you created. And once it's provisioned, move on to a configuration step where you're applying how you want the machine to look, what software you want on the machine, how you want it configured, what things you maybe want it connected to. And at that point, it is talking back to and part of Forman's inventory. And then you can move on to active management of that machine through its life cycle, whether you need to apply updates, whether your creation of it, putting your software on it, reprovision it. Maybe you want to move it to a different cloud, so you want to reprovision it after you've updated your definition. You can also look at this from a brownfield case where you've already got some real stuff in your data center or in the cloud. And you want to start to move to managing it from a single place or your pending, say you're planning to expand and scale. So you want to start managing stuff from a single place so that you can start to scale out maybe certain types of deployments that you have. And in that case, you can import the existing machines you have through a variety of mechanisms to get into those. And then once you've imported them, you can start to build out your definitions just like the greenfield case. You can use the data and attributes from the import process to then define what operating systems you have, domains, your subnets, your software. And then you can start to configure those machines that you could even go back to the greenfield path and provision new machines based on those definitions and end up in sort of the active management state where you're monitoring the configuration and you're making changes and you're looking at reports and you're keeping an eye on things and applying security changes and configuration changes and doing all of the life cycle of your posts and systems through just a single point of view, which is Forman. So from that, what does Forman look like? What are you trying to deploy? What are some other, like when you think about the aspects of it, like this is kind of our old school, you could say this is very part of the history of Forman. This image has been around for like seven or eight years in the architecture. It has evolved, but it hasn't really changed from the central concept that you have. You have a central Forman server that's receiving reporting and data and information from various sources. You've got a web UI. You've got this rich API. And then there's a piece of software called the smart proxy, which serves a number of purposes. So you might install a Forman server and then you might go install a smart proxy on a different machine and how you deploy that machine may depend on your network topology or what you're trying to achieve. You can deploy a smart proxy with the idea that you want it to sit at the edge of your data center. So you can deploy different smart proxies to different data centers at the edge of those different data centers or cloud. So you can use it as the sort of like isolated communication to anything inside that network. And the smart proxy can talk back to Forman. It also provides a sort of restful API to things that traditionally don't have web-based APIs, DNS, DHCP, TFTP, some providers that you would typically have to SSH into the box or run or configure that way. The smart proxy provides a way to do that through a common API for those and as well it provides a sort of like an abstracted API over different providers. So you can really start to build up common patterns and API to your advantage or use it, you know, like for isolation, for scale out, offloading a number of hosts that are being managed or routing traffic through. This applies when we get to some of the cash send out content. So like RPMs, files, Debian, push out content to those things so they're much closer. If you have networks that are unreliable, you can push the data out there so it's closer to the machines that need to get it rather than each and every one of them having to reach all the way back to Forman to get that data. We'll talk more about that as we come along. So let's look at a little bit of each of those topics give kind of an idea of like how Forman looks at it and how you would create these things, how it provides some tools for organizing your data, viewing your data, your definitions. So if we start just start with the defined state, we have this concept called a host group. You can define lots of attributes on a host group. You can define environment, the content, what config management provider you want to use, whether it's Ansible or Puppet or Salt or Chef, domain, subnet, OS, architecture, all the things that go into how you define what this machine is or when you provision it or you figure it. Host groups are nested so you can create different layers, different concepts, and you can organize it how you want to organize it. So maybe you want to organize it in a way where you're creating what a base level REL7 host looks like. And then on top of that, you're building out what your web server looks like, what software is on the web server, what configuration go specifically to what your web server looks like. Or maybe you want to think about it in a different way where the concept is the thing that doesn't change but the OS changes. So you want to start with, here's how I'm going to define what our Jenkins nodes look like. The content that's on them, the layout on the file system, the puppet modules I want to apply to it, or the playbooks I want to run on it. And then you might have small variations that you want to apply on top of that if you happen to have this node that's running REL versus one that's Debian. So really, host groups provide this way to configure and define what your hosts look like so that you can provision multiples of them. You can make updates and then run updates across them. You can scale those deployment types. Then there's other, so I hadn't mentioned this, but Formin started itself as a way to manage a UI and a way to manage puppets. And then it brought a lot of provisioning capabilities on top of it. Then it built out a kind of plug-in ecosystem. And that plug-in ecosystem brings in a lot of powered functionality. I've got a good little list of that later to kind of give an idea. So some of what I talk about, for example, content comes in from a plug-in and is a good setup for when we get to Dennis because the content side of things is driven and powered by pulp. And what we provided for Formin is some abstractions and some layers on top of that to help with how you define your content, how you customize your content, how you think about doing lifecycle management with your content. So you can, as part of this definition thing, just define what repositories you want. Do you want to Fedora? Do you want to REL? Do you want a boondoo? What other kinds of content do you want to store and manage just files? That could be anything from something like SSH keys or even VM images. Maybe you want to keep those together. Maybe you want to lifecycle your vagrant boxes as an example of something we do internally as part of our development cycle. Maybe you want Ansible content. Maybe you want container images. You can define what those repositories are, what that content is, and you can use this concept called content views to further customize it. So say you sink down. You want to be a REL shop and you want to customize that REL or you want to lock it down to certain kernel modules or something like that. These are use cases that people do and content views in this definition allow you to do that. Then you can get into the defining on the config management side by choosing what provider. And so Forman started with puppet integration, but over the years, people have added plugins that provide all of the other providers out there. So you may define and want to set what puppet classes or Ansible roles or chef cookbooks or salt states that you want applied to your system whenever you provision it or update it. And then you can go into this very party parameter management as well, where you can define what is the key value for these inputs to these figuration artifacts. You know, after you've defined what you want, then you can get into the visioning space, which Forman has been doing for a long time. You can do bare metal, virtual provisioning, you can pixie, you can do it through image-based provisioning. There's a plugin that's known as Discovery, which provides this concept, the metal as a service concept, which is kind of the idea that you can go plug in a brand new bare metal machine and it will call out and register itself back to Forman. And then based on a set of rules that you've set up, it can automatically provision itself. So you plug it in, it boots up, it reaches out, provisions itself based on your set of rules, and it's just ready to go. There's a number of compute resources that we support that come in through plugins, you know, the various cloud providers, various virtualization providers, you know, there's plenty out there that we support today and individuals, teams, businesses can come in and add support for any of that, that concern them if they're not on the list already by creating a plugin. So the other way, right, in the brownfield ideas is say you don't want to define and provision, but you've got all these machines that exist out there in the world, maybe you're managing them through Chef, maybe you're managing through Puppet, maybe Ansible, you can import the machine, you know, the hosts out there back into Forman to start to get your landscape, your inventory all together through their kind of, you know, native methods really it's just about sending facts and information about that machine back to Forman and there's various integrations for each of these out there. You know, Puppet being Forman's, you know, original use case where Puppet Facts and Reports would send back and now you can manage that host through native Puppet methods. We got the red hat side with subscription manager and then there's curl up there because I mentioned this when we get to like what's upcoming, we're working on a more generic way if you don't use one of these providers, configuration providers pay a more global direct way we're calling global registration to get import a host into Forman for active management. On the configuration side, so I've kind of talked a little bit of this so far right, but like the main drivers for configuration is what is your config management solution? Is it Puppet? Is it Ansible? Is it Chef? Is it Salt? Is it possibly something else? You know these like I think the four big ones but it could be other homegrown ways that you want to manage it or it could be that you want to take what I mentioned in a minute which is a remote execution route but there's plugins and ways that these are each supported so that you can assign them to your hosts or assign them to your host groups, apply the ones that matter you know if you have your web server case here you can you know have Ansible roles that set up Apache for you or you could have your Chef cookbook that sets up say engine X for you on the machine and when it's provisioned or if you assign it to the host it'll get run and they'll get picked up and run by that particular config management solution which will also then send back you know reports and data about what happened and what's new and what's changed what are the facts on the machine. You can get into defining parameters and their values then you can change them, apply that configuration you know key value management that get seen as inputs into those things which allow you to sort of scale out managing different kinds of configurations and systems. If you you know either don't have a config management solution or you look at things more as I just run something on the machine at a time when I need to run it and then I just keep an eye on its configuration, make updates you can use the remote execution which comes through from a plugin. This provides the ability to just go run you know user defined bash scripts through the templating engine and templating language that's inside of Forman or you can run Ansible playbooks or Ansible roles this is both of those currently happen through SSH but they're both still backed by the templating system I haven't really mentioned yet but it shows up in a lot of places in Forman and has a lot of power so provisioning is very template driven you can define templates for all stages of provisioning that will get generated based on parameters and then executed on the hosts. Same with remote execution you can define whatever batch script you want in a template with variable inputs coming from Forman from its rich set of data they get executed same thing with the playbooks and the roles and then also here in the past couple of releases there's been some reporting that's been given to the user where they can define use the same kind of templating idea to generate reports of what is within you know Forman's database within its inventory that then can be you know exported and looked at or you know done whatever a user needs to do with that sort of information of everything that's going on and then you can also through the Catello plugin have there's this concept of lifecycle environments where you can choose that your hosts are in the dev environment or the test environment production environment and you can push content through those environments you can make choices based on what environment hosts live in so say you're rolling out a new software update you can roll it out to your dev environment hosts that are in your dev environment could get you know updated through say remote execution to get that new software you could then go out and test it look at reports coming back Forman about what's happening in that environment and when you feel good about it you can roll that update into maybe the QA environment or just straight out to production and then go issue either updates like I said through remote execution or say you're using puppet by rolling it out to production you know your puppet and you know puppet agent out there wakes up and says oh hey there's updates I'm going to apply them and now those systems are up to date and sending reports and information back or the you know active management side of things and there's a lot that you can do with the active management right you can still like that's what you know I mentioned iterating through dev test prod you can then you know be thinking about inspecting your inventory looking at the systems what status they're in what's new information coming through lots of different you know there's reporting mechanisms stuff coming from the configuration provider itself you know upper reports and ansible runs reporting back the you know what happened during the run there's open scap integration for compliance reporting through a plugin you can schedule tasks so say you want to apply you know YUM update on every Sunday at midnight for example you set up something to go run and do that for you you can also set up how off frequent you want to sync new content or you can manually sync content you know when you want to go apply security errata if when they're synced down or brought in when you want to do updated OS and application software it really gives you the tools and the power to figure out and decide how you want to do it based on your needs and schedule around that and then also add you know it's it's has a lot of enterprise level features that have been added to it over the years and supported and you can you get to manage those things to you know users roles what we call organizations which is a way to like sort of segment all your systems locations which add you know you can add the metadata around an organization around where the systems are sso a lot you can do once you get everything in there you know to actively manage it keep applying to configurations keep your systems healthy deploy new versions of those systems so that's a that's sort of like a pretty think kind of high level overview of trying to like tell the story of what you can do with Forman you know I like to think of it that you can do a lot with Forman but there's a lot involved with you know defining what a system looks like provisioning it actively managing it keeping on top of security updates keeping it from drifting with you know having configuration drift having it look and feel and do the things that you need it to do and and Forman has a lot to help you with that and handle all of the ways that that can a lot of the ways that that can be done I will say all of the ways and do it from one place so that you're able to manage different footprints largely in the same way and reduce the amount of effort you have to put into managing those things especially as you start to you know scale up to the hundreds thousands even 10 thousands of machines under management and then I'll just kind of give some I think ecosystem highlights for anybody curious at that level about Forman it does have an API I labeled as I like to think of it as ways that you can help you automate and scale out your form and deployment your use of Forman we have there's the API there's the CLI which is known as hammer and then over the past year so we've been building out an Ansible collection known as Forman Ansible modules that provide a set of Ansible modules that you can use to automate against your form and instance it's a couple technical items so it is a very heavy Ruby-based project the UI is predominantly these days there's some old school JavaScript and ERB templates but there's a lot of newness being written in Yacht but both the Forman and the smart proxy which are the two I'd say main you know software projects and then plugins after that are all written in Ruby Forman is based as a Rails application there is a robust installer that is based on a set of puppet modules kind of harkening back to Forman's roots the installer provides an interface and an installation experience but it's on top of a set of puppet modules where each one is built to deploy the various services that someone might want there the project does provide RPM and Debian based packages for each of it anytime there's a release you can go to the forman.org is the main website community.theforman.org is our discourse instance where you can find support rfcs for any new features development discussions infrastructure related items and then you can go to the main github.org at slash the forman yeah so I mentioned I'd kind of give you an idea of like okay so what is built through plugins because I think that's there's a lot of power in plugins they allow individuals or teams even and companies to go build additional functionality you know sometimes we see these plugins show up in the community show up in the open source we also know that in some cases businesses build stuff for their internal needs and they keep it you know closed source because they're specific to their workflows that they're building off of forman but you have probably the biggest plugin which is Catello it does content and entitlement management it is the main interface to the pulp project which is doing all the heavy lifting content under the hood which Dennis will give us lots of good details about there's plugins for salt, chef, ansible, configuration management providers I mean I mentioned remote execution discovery if you want to do you know provisioning through metal as a service you know plugin provision based on rules open scap for open scap compliance there's a web hooks plugin in the works there's plugins for cloud providers for vault integration if you want you know to do secrets management alongside your host that you're provisioning and I think what is my last slide here is to give you an idea of what is the roadmap and how does forman release so it's a three month release cycle again rpm and debby and based releases current release is forman 2.1 and the 2.2 release is in the rc phase and then looking ahead we are looking towards a forman data in the future and say the the biggest reason we're looking ahead to that is because like I've said part of its formans history it's you know has been its puppet integration which was built into forman and so there's a team working hard to pull out the puppet to a plugin which puts it on the same footing as the other configuration management providers and provides a little more you know cohesive experience for what your config management provider is and puts a little more focus on the main forman app to be you know the place that bring allows you to do provisioning brings your inventory in and has integration points um for these different import methods these different uh you know providers that can send facts and tell you about a host um the cartello project is doing a big migration uh to pulp three for its content and that make make a lot more sense when i hand it over to denis in just a minute uh the global registration api which is going to allow you to not necessarily have to have a you know provider such as ansible or puppet or subscription manager to import a host you can do it through their through this new global registration api and enables more workloads webhooks plugin on the rise um and then um a lot of some look into reworking some some older ui pages that haven't seen been touched in many years looking towards a focus on sort of what user workflows rather than just providing maybe information and how things were seen seven eight years ago we're looking to say how do we enable users to have more guided better workflows with those uh primary uis and that while felt short to me was probably a fairly long uh that i will end i think form and segment with there um and yes turn it over to denis yeah i think that that was great i really appreciate that um the insights and and it's i've been a long time since i've uh looked at puppet stuff and ansible stuff and all salsa so it's really a good refresher for me so um thank you and and i really do like the single pane of glass for the monitoring as well so sometime we're going to have to get you on and do a demo of all that really really well done so denis queue up um pulp and tell us how pulp fits into this puzzle um thank you uh yeah i don't have any slides i have we have our website uh that i can hear in a little bit but i just uh want to give an overview of pulp and pulp is a platform i think of it as actually as a toolbox um for managing uh software repositories and we are also plug-in days like foreman is and each uh type of content that you want to manage is managed by a different plug-in uh historically the rpm plug-in uh has been like the most robust and has had the most users i would say and it is probably what drove for pulp to be created uh red hat actually uses pulp to make all the rpm's that it publishes available to the world and uh many other companies actually use uh pulp as the system that they distribute their own custom software uh through um but in addition to being able to distribute software that you've created you can also make uh other software available inside your organization so as eric talked about you know uh having uh your servers being provisioned in different clouds or on premises uh you want to be able to make sure that those servers have a very specific set of content available in uh on those servers and pulp is what lets you uh make that software available and only that software available so that nothing can accidentally uh you know be installed that you did not intend to install on there um so we call that use case a mirroring of content but also curating of it where you are able to pull out a certain set of packages and make only that set from the remote repo available as i mentioned we have uh multiple plugins and when i first started working on pulp uh we were uh actively developing pulp to and it had a limited set of plugins and the architecture of pulp to was such that it was actually very difficult to add support for additional content types and there wasn't really a defined plugin api every time you had to you wanted to add a content type to pulp you had to go make changes to the core and then you could write a plugin um or if you wanted to make a change in the plugin you always had to pair it with a change in core and so it wasn't a real plugin uh architecture and so we uh decided to go on this long journey to rewrite pulp to and create pulp three um and i say long because it took us about three years to rewrite all of pulp and our focus was on plugins and to make it a lot easier to add new plugins to pulp and that has actually worked out really well for pulp three we now have the rpm plugin which you know as i said is our most important plugin um but we also have the file plugin the container plugin that lets you run your own container registry um an ansible plugin that lets you upload ansible roles and ansible collections uh so you can manage your ansible content for managing your infrastructure um we also have a debian plugin which we did have with pulp to also we have a python plugin which is uh about to release a two oh uh generally available release which will allow users to create a full mirror of pypi and not only uh create a full mirror it will let users um sync uh multiple times and only sink down like the changes that were made to pypi and pypi is a very large collection of python packages that you would not want to sync over and over again um trust me i know that one i i don't want to be doing that then yeah so we yep and so we also have a maven plugin for those java artifacts we have a ruby gem plugin and a chef cookbook plugin um and we allow our users to choose how they want to uh fetch this content we uh refer to this as the download policy and users can have an on-demand policy which is what i would recommend for users of the python plugin when they want to mirror all of pypi uh because with the on-demand download policy uh pulp only fetches the metadata and it's no it will know that there is this package available there and only when a client actually requests this package from pulp it will go download that package save and serve it to the client but then it will also um save it in pulp so that any subsequent request will be actually served by pulp and for content types like python it is definitely recommended to use the on-demand policies and i believe actually foreman and katalo by default uh create repositories with the on-demand policy unless the user asks to do otherwise and um so we've been doing this rewrite and we actually released pulp three back in December of 2019 and uh we released it uh we've been releasing about every five weeks a new feature release so we are now on 3.7.1 um and with each one of those feature releases we're uh getting closer and closer to having a feature parity with pulp two even though we were able to improve the plugin api and we've made for a better rest api we are still missing some features that we're uh uh we really want to uh uh you know get to and one of the ones that we're actively working on is role-based access control and we've already actually added um the machinery that's needed inside of core to provide role-based access control and now plugins are working on adding that to their feature sets and um we're hoping that that will be done before the end of the year and this will really allow users to migrate from pulp two to pulp three and have um that very important feature with their migration um the other things that we're working on as far as uh feature parity is the cli um the pulp users are used to having a tool called pulp admin and in pulp two uh they can use pulp admin to interact with pulp to create repositories and publish them and check on status of tasks uh pulp does a lot of asynchronous work so checking task status is a very important part of the workflow um and so we've started the work on the pulp uh cli and the command is just called pulp no longer called pulp admin it's called pulp and um we've uh sent out a call for feedback on our mailing list uh earlier today I believe Melanie sent this out uh asking for users to take a look at this uh first edition of the cli so that we can know if we're doing it right or if we need to change things up before we get too far with it um another thing that we are adding is ansible modules and the ansible modules that we've uh created are inspired by the form in ansible modules actually and uh they are very popular uh we've noticed that people are downloading them a lot from uh ansible galaxy and I don't think people are just using you know pulp out there to think them all the time which uh if you look at other packages like Ruby gems you'll see that oh my god my package is so popular but I suspect people are just mirroring that content all the time I don't think it's quite the same for the ansible module uh the ansible collection quite yet um but another thing that we've introduced with pulp three is our open api schema and the open api schema that defines our rest api uh is what allows us to generate client libraries uh for python and ruby and the big integration that Eric mentioned between katalo and pulp three is using this these auto generated bindings the client library that is allowing katalo me to make uh great strides in this integration with pulp three and another great thing about the open api is that it not only lets us generate clients in python and ruby I believe it's 40 plus languages that the open api generator supports so our next uh client is going to be actually a javascript client that we're going to start publishing to npm and that client is going to be used by students from university of massachusetts at lowell to build a ui for pulp um historically whenever we've uh been asked about a ui we've uh had to tell folks that there's katalo you can use that um but it's a pretty big tool that you have to install as Eric described it does a lot of things it's very useful but it's not necessarily what every user wants um some users just want to use pulp and uh we want to make pulp more accessible to users and having a ui will help us make that happen and we're really glad that um the university of massachusetts decided to help us with this that's great that's where i'm from i'm from umas amherst as i'm an alumni so it's nice to hear a shout out to umas um any day so well done yep yeah and uh they actually um there was a project last semester done by some students from umas and it was for katalo and they did such a great job that we wanted to get their help this semester well we better get them on um melanie to talk about what they're doing when they get to get to that um demo demo definitely that would be awesome yeah now we'd love that um to showcase some of the community efforts that are going on especially at the universities too and um that that would be wonderful yeah and so i referred to pulp as a toolbox earlier and that's because we provide a lot of rest apis and our project has been consumed through the rest api for a long time and you can integrate it into your continuous integration systems or into your you know continued delivery or just in general delivery of content and there are many different ways to make the content available and to curate it but um we want to make it more than just a toolbox but a tool also that is a little bit uh prescriptive definitely to make it simpler we have to prescribe certain workflows um but i think that will attract more users well i also saw that there was a kubernetes um pulp operator in the works in your that's right there is um it said it wasn't production ready yet but that's right that'll bring in another whole slew of uh community members too so can you tell us a little bit about that effort oh definitely yeah um we have multiple ways of consuming pulp uh one of them is through our ansible installer which has a lot of options lets you install pulp on single node multiple machines however you choose to we also publish a container that is a single container where all the services run inside that container and you can get started using pulp right away just by running that single container and then the last option is what you just brought up is the kubernetes operator and it is not production ready but it is functional it lets you deploy pulp on kubernetes and currently it spins up its own database um and one of the things that we'll be working on in the near future is decoupling that and allowing users to bring whatever database they already have running in their cluster um and use that our postgres database but uh to boot this image and you have pulp running it's this is the quickest way to get started with pulp awesome um we have plugins um the list of them is here um there are links to the source code to the issue trackers to the packages on pi pi um to the documentation for them each one of them it has its own documentation site we are in the process of combining all that into a single site so hopefully that will that project will finish soon and it will be easier to navigate all of the plugins documentation um we also have a blog where we try to post uh our progress frequently um we definitely announce our releases but we also try to announce any sort of um testing we do for example we sometimes do performance testing we post about that um we have some community updates that melanie helps us with we are trying to get back into doing more youtube videos um we were doing them as we were getting ready for the pulp three release getting people excited about things and then over this past year that effort has slowed down and uh when we were having our pulp con which was virtual earlier this year we definitely uh had requests from community members uh to post more videos and uh i agree with those community members and we will start doing that well pumping out the content is really um kind of key um but then there's also i love that you have such great strong docs as well um i think um we have a tendency at least in the open shift team to document by blogging or by creating content and that goes that fades away so don't feel too bad about not having a lot of video content but you've just created a wonderful one today so uh they'll they'll be happy about and we'll get that out and push push this out in the social channels as well so um we have about two minutes left uh melanie is there anything that you want to um incite these guys to um talk about um or promote that's coming up on the radar next like the next pulp con or conference or thing that we need to make sure that's on everybody's radar um not particularly at the moment i suppose from the pulp team as denis said we have a call for some feedback on our pulp three proof of concept for the cli and you know if you do test that there is some swag on offer for that and with the foreman community we have a demo every three weeks and this thursday we have a demo of the latest and greatest changes in the foreman community so that is live on a on a thursday it's in our calendar on the community so if you're interested in joining you're very welcome to attend and ask questions or even talk so i think that's that's everything for now perfect well um i'm going to get you to send me the links to all of that um we'll push this video out on um the open shift commons um playlists um for the am a you're welcome to reuse it edit it any way you want and i am just really happy to have all three of you here today um to share this it's there's a great update thanks eric and denis and and melanie welcome aboard um you're you're a welcome site um to have some community support behind all of this stuff now um it'll be really great and as soon as that operator is functional enough and i think it might be now let's get it in operator hub.io and um get it in front of some of the kubernetes and open shift and okd working group people because i think um if you want people to break things fix things and give you feedback um the okd and the open shift community definitely um are good folks to break things and to fix them as well so yeah let's let's give them a shout out and um make sure that they're aware of it we get you um some more folks contributing back into to pulp and other places in form and so thank you for all that you guys do and it's much appreciated so take care all thanks for having us thank you for having us bye bye yep thank you