 All right, let's get started. Thank you, everybody, for joining us today. We're here. I hope you are here to hear about the Community App Catalog, which we launched this morning together with the OpenStack Foundation. So let's get started. First, let's do a little bit of introduction. So my name is Craig Peters. I'm a, it says here, I'm a father of bicyclist and technologist, which is all true. I'm also a product manager at Mirantis, and I'm focused very much on making sure that everybody can consume open source and closed source software in a very smooth way. It's really important to me that people have a good experience when they work with their software, and that's what I've been working on for a number of years. Christopher, you want to introduce yourself? I'm Christopher Ado. I do OpenStack things, product architect at Mirantis, and before that I've been in OpenStack since around the, I guess, derelease, maybe. And I do a lot of community stuff, and my focus with this is really to drive right now the community adoption of the app catalog. Perfect. So what are we here to talk about? We're talking about how you get applications onto your OpenStack installation. So this is something people have been struggling with over the years. So how do we do it? And you kind of want to push one of these buttons, right? It's like, well, how do you get the workload onto OpenStack? I love the sort of boring mirror thing. One does not simply deploy OpenStack workloads. It's like there's many steps to making sure you've got your workload correctly deployed on OpenStack. And there's a lot of moving parts. So the APIs are complex, so it's not always clear exactly what level at which you should do an integration. You can't just sort of forklift them in as one big thing. You can't push that second button, and you don't just plug it in. And we all like to have the transporter to make sure you push the button, and it just appears there. And essentially, with the work we're trying to move towards here, we're trying to get towards that last step. So in order to introduce that, what we've done is we've introduced a central repository where, as a community, we can all publish common ways of thinking about our applications and representing them in ways that are consumable into your cloud. So essentially, there are a lot of different kinds of assets that represent applications. So if you kind of think from the most basic thing, typically you'll start a virtual machine, and you'll use an image to create a virtual machine. And Glance is the service in OpenStack that supports doing that. So the question is, well, how do I get Glance images? Where do I get those from? How do I find those? So Google has been a great tool for all of us. Who's done that work? Who has used tools to create images that are consumable in OpenStack? Well, that's not a really scalable way to share information, to have it highly distributed throughout the internet. The concept here is let's get this all in one place. Let's find a way to curate that stuff as a community, and then make it really easily consumable into OpenStack. So the idea is then you've got this central repository. You can either consume it directly into your OpenStack repo if your nodes have access either directly or through a proxy server into the internet. Or you can curate that yourself. So a lot of organizations want a kind of wall around their cloud, and you want to make sure you have control. So essentially, this repo allows you to directly consume them or create a clone of that. You can replicate that inside your firewall and have some governance over what images are available inside your organization. And so let's talk a little bit about what actually constitutes the catalog. So essentially, at its core, it's a set of definitions of what each of the elements are. They're in the YAML format, which just makes it very straightforward for anybody to define a new one. There's a UI that displays all that information and just makes it easily easy to find and consume this data. And the bits are either hosted like for a glance image, for example, you may want to have direct control of it. And you may have a CICD system where you want to publish a set of images that you want to share with other people. So you publish those to some URL you're under control of. Or if you don't have a CDN and things like that, the CICD system for the catalog can also automatically copy them into Rackspace CDN, which is the one that the OpenStack.org organization, the foundation runs. And essentially, all of that content goes through exactly the same curation process that all OpenStack contributions go through. And Chris is going to go through that in some more detail in a little bit. But what I wanted to talk about a little bit more is how this is really just the seed of what we can do. So having a bunch of glance images and heat templates and Rano packages kind of forces us all to think about what it means to be able to share that kind of information. So if you think about what's happened a little bit over the arc of the IT history, in the old days, all of IT was centrally located. And everybody, just get a drink of water. I'll be back later. Sure you will. In the old days, the IT organizations really had all that information kind of centrally located. And everybody could collaborate on how to build their systems. And as IT systems got more and more distributed and more and more complex, those organizations specialized in certain processes and skills and tools. And they got very dispersed, and even more so once outsourcing kind of took over. So it became very hard to even understand what pieces made up IT infrastructure. And then what's happened in cloud, essentially, is we've said, well, we've taken all of that kind of dispersed knowledge and things that are run by other people. And we've decided that we need to create a common shared definition of what that means. And that's what the cloud kind of represents. It's a consolidation of all of that knowledge that has been dispersed. And I think what we have here is an opportunity that's represented by OpenStack in general to come to some consensus about what's common between the way we all want to run our clouds. What are the best practices for specific application use cases? So what's the best way to do CI-CD for applications that sit on top of OpenStack? What's the best way to do testing and scaling of underlying infrastructure for your cloud? And if we can, as a community, come together to define a place to share what the bits and pieces. What are the building blocks of each of those? Then we can also start defining some patterns. How do we solve different kinds of problems? And I think that if we do this in the right way, we can make it consumable for a much broader set of people to get on board and understand how to consume and take advantage of their clouds. So I'm going to take a minute here to walk through the app catalog, and what we'll do is we'll just take a look at what's in the catalog today. And I want to think about this as a way to hopefully inspire you guys to think about how you can contribute, how can you share with other people in this room what you've learned about how to take advantage of OpenStack. So for starters, what we wanted to do was describe the primary ways in which you could consume this stuff. So there are really currently three different kinds of assets. One can imagine there are lots of other kinds of assets we could add to this catalog over time, but we just wanted to create a starting place. So glance images, as I mentioned, are the building block for virtual machines. And at launch time, essentially, we managed to get participation from a number of different folks who wanted to contribute right away. But this is just the, I have said that over and over again, just the beginning of what we can do as a community. But the idea is that each one of these images has metadata about it. And so you can see, for example, what it is, what provided description right now in this initial instance. The description field is just a text block. I think in the future we should do things like add the support for formatting and things like that. But it's got a set of metadata attributes that help you kind of understand what it is you're getting, right? So you can get to the documentation, you can understand what the hash key is, you can get links to other releases. And that set of metadata is just the first set that we've defined. And what it does is it helps represent some dependencies. So you can define not only glance images. One of the things I forgot to mention when I was in there, let's do that, is that we've tried to create a few nice little utility ways to make it easier for you to consume these things. So right here we've just got the command line that you would just copy and paste into your bash shell to download that image right into OpenStack. So it makes it super easy to consume. But if we look at Morano packages, it's billed as the OpenStack application catalog, but it's really a whole lot more. It is a framework for automating the life cycle management of applications on OpenStack. And packages for Morano represent how does that get exposed in the catalog in OpenStack? How do you deploy it? How do you upgrade it? But even further, it exposes a set of actions which you can take on applications, like, for example, you could scale up an application or you could back up an application. And if you want to do that in exactly the same way every single time, that's how you represent them in a Morano package. And then you can share that across organizations. And that's what each one of these things represents. There are actually two kinds of things in here. You'll see over here there's packages. And then there are bundles, which is bundles of additional assets. So these are, in this case, you'll see this is a simple bundle of application servers. And it's got Apache HTTP server and Apache Tomcat. So it's an easy way to get whole sets of things. So here is a container-based apps bundle. So you see it's got a bunch of dockerized services that you can bring into your application. So right away, if I download this into Morano in my cloud, I'll be able to provide to my users self-service deployment of all of these kinds of applications into your cloud. And so one of the other things that's represented in here that's important to understand are the dependencies. So for example, if I look at Cloud Foundry, you'll notice that Cloud Foundry, this is a package that allows me to configure and deploy a single node Cloud Foundry open source instance onto my cloud. And it depends upon the Sabuntu image. And the Sabuntu image also has the Morano agent pre-configured on it. So Morano takes advantage of post-deployment actions and uses the Morano agent to accomplish those actions on the server. So if you missed the keynote this morning, in Kilo, unfortunately, I don't have Kilo running right now, so I can't show it. But basically, all you have to do is you find the package name, and you copy and paste that into Horizon. Or we've also added to the Morano command line the option to download these package by package name or from a URL, much like Glance. So there's a variety of different ways to consume it. So the idea here is this catalog is just a starter, and we can all add to it. So I think we can come back to this after if we have other questions, but that's the demo that I wanted to share. And I think I want to pass it over to Chris to talk about how you guys can all can contribute and make this even more awesome. Thank you, Craig. Excellent. So I'm going to talk about the community aspect of it and the idea of getting people to share stuff. And I figure puppies will make everyone want to share stuff because puppies are cute. And remember, sharing is caring. So to use the catalog or actually to contribute to the catalog, you've got to make something. And like Craig was talking about, right now the catalog can host Glance images, heat templates, and Morano packages. So I'll talk briefly about how to make some of these different things, and we will leave a fair amount of time at the end to talk about this more. And then we have a working session tomorrow at 11. In the same room, I think at 11.30, for everyone to talk about it, because like Craig was saying, this is a community thing. And it's really meant to be something that we all build and grow together. So actually, a show of hands, who here has built a Morano package ever? All right, a few people. It's actually not that complicated. And the docs have a really, really good walkthrough that steps you right through basically building a really simple Morano package, but hitting on all the different elements that you would need to use to build something much more complicated. And obviously, these slides will be made available later, so that's why there's a bunch of URLs in them. How about Glance images? Who has made a Glance image in their day? That seems, yeah, better. Or more people, anyway, have done that. So obviously, easiest way to do it really is with disk image builder. But there are a bunch of different methods for making Glance images. And like Craig was saying, a lot of times when you stand up a cloud, one of the first things you want to do is actually launch a VM. And you might have the seros image, and that's fun for a minute. And then you're like, all right, I need more stuff. And right now, really the only place that I've seen that actually links to more than one image is the OpenStack Wiki. And it's just a handful of images, and it's not really updated by anyone very regularly. So this is, as Craig was showing, we already, just today, SUSE added an image to the catalog about five minutes after it was announced at the keynote this morning, which was awesome. I was sitting there. I got an email. I looked, and it was a code review from, oh, sweet. So awesome example of how easy, relatively, this is. One other thing you can do is make a heat template. So there's actually a lot of different good examples out there. The user guide is really good, and there are some people working on the Merlin project, which is would allow you to potentially build heat templates within Horizon in a kind of wizard walk through fashion. So that's pretty cool, and hopefully it's going to continue to see support in people building on it, because heat templates are cool, and it'd be nice if they were a little bit easier to make. And actually Merlin has the primitives to work with Merano as well, so really cool project. So one of the things that I'm really excited about this is that committing to the open stack is daunting, and maybe not super easy. So show of hands, who here has, first show of hands, who has signed the open stack CLA? All right, now who has committed code and gotten it into open stack? So almost the same number of people. It will be kind of awesome if, six months from now, we have almost everyone in the room can raise their hand and say, well, yeah, I committed code because it went into the catalog, and I've been through the Garrett process, and I'm totally familiar with it. The great thing is that this is probably with the least painful way to actually commit code back into open stack. And I think getting a lot of people over that hurdle and getting them used to using Garrett and doing reviews and stuff will probably, at least potentially, get a few of those people who have wanted to add an image and gone through the hassle, maybe not hassle, not fair to say, but gone through the steps that are required to get to the point where you can type in get review. If they've already done that for the sake of adding a few lines to a YAML, there's a great possibility they might actually do a review and start contributing back to open stack in even bigger ways. So I put this in there, and actually, it's probably, for people who have never committed, it looks a little bit confusing. So maybe we'll just skip past it. But it has the URL, and you can learn more about the process. And we saw this slide earlier. Craig talked about the contents. Like, basically, it is just a YAML file behind the scenes. So here's the process. It's a few steps, but it's pretty straightforward to actually add something to the repository. So you clone the repo, you edit your image. Two and three are supposed to be backwards. Craig must have changed my slides earlier. But I'm happy to fix it. Sweet, real-time. Yeah, that's the way we roll. Thanks. Anytime. Glad to help. So clone the repo, edit your thing, add the stuff, and the steps are on the wiki. It's pretty straightforward. Then you run talks, and run Python simple server just to see if it renders right and looks nice. And you can make sure you're happy with how your description reads and everything else. And then I get commit, and I get review. And after it gets reviewed, it'll get merged, or it'll get some comments. And this is what the Fedora one, the review looks like. You can see for a glance image, at least, this is all it takes. So this is the YAML. It's really straightforward, really easy to do. And the whole point of taking this approach was to lower the barriers to sharing, but still do it in a way that's really consistent with Open Stack and consistent with the community. So I feel like it's pretty good, but I really look forward to having a conversation with everyone here today. And hopefully, having a conversation with same people and more tomorrow, like figure out what we should be doing together in the months to come. So some of the things that we've had ideas that we think would be really beneficial, similar to the way the Kilo Murano is integrated with this and can directly pull things in from the repo, it would be kind of cool if, on glance, you could actually search for an image similar to something like Docker, where you could actually just go, you know, glance, search, Ubuntu 14, how sweet would it be if you actually got a list of a bunch of Ubuntu images that are in the repo, have been reviewed by people and committed back in by the community as a whole, and then be able to just type glance pull and have glance get that image straight out of the repo and put it in your local index. I think that would be pretty cool if you could do the same kind of search in Horizon with just a search panel, without potentially even having to go out to the catalog to scroll through it and switch back. I, like I was talking about earlier about lowering the barriers, I think it would be great to make the becoming an OpenStack Committer process less onerous and a little bit easier. And so we're talking and thinking about different ways we can even streamline the process, not really by changing it by just, but by making it easier to walk people through those steps and get to that point where you can type get review. I think we could probably make a YouTube video or something. Better than that, make it a magic wizard or something. Excellent, magic wizard. And some of the other ideas like more artifact types and making it a little bit easier to update. So for instance, if you have an image, it would be great if every image included its hash and you were verifying that if you had your own CI CD when you were pulling it in. But for some of the images that are built nightly, like what you'll see from Coros or Debian, it'd be nice if there were a really painless way for those images to stay current as indexed in the catalog. So right now the way the catalog does it is just by linking out to like the Coros nightly, for instance, and it for hash it says unknown, which kind of sucks, because you then you're, you know, you have, it's be nicer if that could be updated. So it'd be good to have a conversation with everyone here about some ideas for how we could do that. And then we have that working session tomorrow. So it'll be in this room at 1150. And that's it for the talking part. So how about some questions and thoughts? And definitely this is like a, this should be a conversation for everyone in the room, not a, hey, Mirantis guys, what are you gonna do with this? Because that's one of the other really important things. This is not a Mirantis thing at all. This is something that we did in collaboration with the foundation. We did it really fast. And the whole point was to get it out there. And this is a purely an open stack thing. There is a couple of us who have been working on it who are core reviewers, but it will be treated probably like any other project. So there will be an election cycle and it's just gonna work like every other project. So, yeah. So questions or thoughts or feedback. And if you can come up to the microphone since this is being recorded. And then any hard questions I'm gonna point at Craig and just pretend that it was his idea. Okay. My name is Michele and the question is how long did it take to do this, to implement this? And how many people? So I think we started this effort three weeks ago in a very lightweight way. And there were probably a grand total of four people working on it. I'd say about right. Yeah. And a lot of that work actually happened in the last week. Yeah, that is absolutely true. We had a stepping stone in a way where this is very similar to Stakelytics if any of you have ever seen Stakelytics. It's, there's some similar components. But it was, you know, we put it together pretty fast and some of us, Craig worked a lot of hours. I didn't, but take credit for it certainly. But no, it was a pretty intense effort to get ready for the summit. But it's also, we're all really excited about it. Especially like, you know, I think everyone who's been in the OpenStack world for a while can appreciate doing something like this that can make it a little bit easier for those people who are standing up clouds and for the people who are trying to convince others to deploy OpenStack. This is one more thing that kind of helps and says, look, it's not just some weird esoteric infrastructure as a service thing, there's actually end users can really get right into it and deploy an image. And I think, yeah. Next. What are the plans to keep the, given that you can write a Murano package with Chef with Puppet or Shell scripts, how do you keep only, you know, one version? Do we really need something like Puppet has where they've got 20 different people uploading packages to install the same version of Apache in slightly different ways? I mean, is there a process to have the blessed version like Puppet has now with their supported modules or is it kind of still a free for all? That is a fantastic question that we as a community have to decide. That one's kind of worried me. And basically the approach I've been thinking about is that I could come up with a suggestion for how we ought to do that. But I decided that it would probably be better that we do that as a discussion with the whole community to talk about how we curate. So there are lots of different ways to do it. So there's the Puppet way of doing things, there's the Docker way of doing things, right? Or it's just the Wild West. Well, it's the Wild West plus of their official images, and there are a bunch of different ways we could do it. So one idea is to have reviewers do things like ratings. So we could sort of have a crowdsourced way of thinking about, well, what are the different things? We could even do it based on use cases. So for this use case, have ratings, associates for that use case. There are a lot of different ways we could go into it. I think tomorrow's working group is really intended to flush out exactly those kinds of questions. And I don't think we in any way want to dictate the answer. Yeah. Oh, come on. There have to be other questions or thoughts or feedback. If they're not, that's okay. Any other thoughts? Yeah. Go ahead. And then you'll have to get up. Or I can just repeat your question. Have you had any pre-study where you compared what you were about to do with your competitors so that you can help us selling neurano and open stack better and easier compared to the competitors? So do you mean competitors as other cloud technologies? With the cloud stack. Our catalog is going to be better than the other. So similar comparison? So, I don't know. I'm not sure I really, you know, no is the answer. That's right. The idea here wasn't to try to make a catalog that was better than what cloud stack would have or that Amazon marketplace would be. That wasn't really the frame of mind at all. It was more about how do we help people in the open stack community share practices and processes to get applications onto their clouds and how can we do that in a straightforward way that's done in the community in a community curated way. The notion that it would be better than one of those other things is what wasn't really in our minds at all. I think that it will become the best possible thing for open stack through all of our contribution. That's sort of my point of view. Yes. Yeah, I'll just repeat it. The contents. Okay, so the question is for the sake of the recording is the review process, is it just reviewing the YAML or is it reviewing the contents like of the glance image or of the Murano package and the subsequent stuff that it downloads? It is just for the YAML. So in similar to, I mean exactly like Docker or Amazon an image is shared kind of at your own risk but so there is some risk there certainly of someone uploading something maliciously. But the truth is it's pretty, I personally think it's really unlikely that we'll see that because you have to be part of the open stack community to do it in the first place. And there's certainly the possibility that someone sets up an account just for that and goes through the trouble to create something and upload it. But the very first person who I guess thinks there's something fishy about it can quickly put in a review and it gets taken right out of the catalog. But there probably are better ways to do that as well and especially quicker ways or ways to democratize the review of the contents which leads back towards some of the things Craig was talking about like ratings or ways to review them and maybe quickly mark an image for like this one is questionable. It should be reviewed by maybe flag something so it can be reviewed by a different committee of people. Well another idea that we should discuss tomorrow in the working group is should we do things like include in the CICD infrastructure virus scanning, right? Right. To look for malicious code as an example but that's not in the first implementation and so that's a big subject. Yeah we actually did talk about it and I came down on the side of not doing a virus scan and basically my stance on it frankly is that if we look at it and we say it's okay, oh yeah we scanned it, it's cool. No viruses, no back doors, no nothing to worry about then we're saying oh this is good and if we happen to miss something that's pretty bad deal so it's I mean it is a balance and I think you can, I don't know, I would love to have a longer conversation with people too about some different ways we can do it and I'm also something that I have been itching to write about this on the OpenSec Dev Malling List for the last couple of weeks so I'm so excited that we've launched it and now we can actually have a more open conversation about it with people who are not here in Canada with us. Absolutely, thanks for your question. Bernard. I'm Bernard of Cloudbolt Software and my question is, you may have covered this but how in depth and complicated can these items be in the catalog, could it be a multi-BM, multi-tier kind of deployment with steps other than just deploying the images, could there be scripts that run in between or afterwards or before and things like that? So that's a Murano thing. I mean so yes, basically heat templates can be incredibly complicated. So for instance, Triple-O stands up OpenSec. There's a lot of stuff involved in that. You can host the Triple-O templates from Red Hat. Could be in the catalog very easily. Murano can also do the same, Murano can do some incredibly complicated things and a bundle can have lots of other sub-dependencies. So you can do some pretty crazily, crazily complicated stuff. Yeah, so for example, this morning in the demo I showed how you can quickly deploy a Kubernetes cluster running. In this case, I just ran my HTTPD but you could do a very sophisticated application, multi-tier application with HA and all that. As a configuration that's bundled as a single item in here or in separate pieces, depending on how people actually consume it. Good. Thanks. Yes. So the question is what kind of considerations do Glantz image creators, would they have to put in for the catalog? Are you wondering if they, right. Okay, so the question is like which clouds would it work with if someone built a Glantz image specifically for Rackspace or for the HP public cloud? That's actually a great point. Right now the documentation on the Wiki doesn't give you a guideline about that, but it should. The guideline should really say for your Glantz entry, note any specific requirements. Like this will run on only one specific cloud or this image relies on, I don't know, something else. That's a good point. So we should add that to the documentation. Maybe file a bug. Right, no, that's an excellent point. So format is one of the attributes of the Glantz images. So if that's sufficient, but that may not be sufficient. I don't know, we have to look at. Yeah, yeah, I mean that's, so any dependencies built into the image should be definitely noted in the image description. We don't, the documentation doesn't really suggest that right now, it's a good point. Yep, very good. Other questions? All right, all right, great. Thank you very much. Thanks so much. We really appreciate you coming. Thanks.