 Is that readable now? So my name is Christopher Ado. I'm a product architect at Morantis. And I've helped with several other hardworking folks at Morantis get the app catalog launched for the sake of the OpenStack Foundation, which we officially launched yesterday. And we had one session to kind of give a little bit more of an in-depth demo of it. And then the idea today is to talk about it a little bit more from the community perspective and capture some of the features that everyone thinks should be added to it and organize the community effort behind it. So get people actually building the blueprints and expanding this with us. And my compadre today is Craig Peters. I am now the strangely famous Craig Peters, just because I stood on stage. And it feels a little kind of awkward. It's only keynote famous. So it'll wear off in a day or two, don't worry. Awesome. The first one is on the keynote, you know? True. So you guys have no idea. That's awesome. So the thing that I just want to say is we really did just create the seed of what a catalog can be. It's just a place to get started. And we really wanted everybody to contribute to what it can be. And the whole idea is just to have a community curated place to find stuff that makes your cloud more useful. And how we do that is up to all of us together. So I'll show of hands who has seen the app catalog. A few people, all right? OK, really quick, I will do a quick demo, just to show what it is. So I'm not going to do any slides. I'm only going to spend two or three minutes. The community app catalog is a central place where anyone in the open set community can add right now. It's set up to add glance images, heat templates, and Murano packages. It's added by the normal community review process. So these are just YAML files behind the scenes. And you can see the Murano packages have descriptions. You can click on any one of them and get lots more information about it. Same goes with the heat templates and glance images. And so adding things, if you're an open set committer, adding things to these is really pretty easy. If you've never committed any code to OpenStack and you are unfamiliar with editing a YAML file, maybe it's not as easy as we would like it to be. But we definitely took this route because this is supposed to be a community-driven thing. So keeping it really consistent with the way things work in OpenStack was kind of priority one here. And I can probably show if anyone wants to see it. So here is what the YAML looks like for. So you can see it's pretty straightforward. This is for a glance image for Debian testing. Get the name, who provided it, and the description. And once this gets reviewed and committed into the catalog, then a short time later, it shows up in the catalog. And feel free to add anything. It's pretty simple. It could use some things, some more things. So what we'd like to do today is start off by just talking about different features that you people think we should add. Yeah? How do you avoid the kind of thing that's like creation? So how do we avoid getting the catalog cluttered with lots of duplicate information and all junked up with lots of random things that are abandoned? That's a great question. I don't know. Let's could someone add that to the form? So right now, the general idea is, as it grows, because it's community-driven, everything before it gets in there has to be reviewed by people and then plus twoed by a core reviewer. So there's an assumption, at least at the beginning, before it gets all junked up that it'll be obvious, oh, we already have from Canonical Ubuntu 14, what do we need the second one? And you can respond back through comments. Long term probably needs something better. And I think some of the things we had heard yesterday, we were talking about the ability to tag and review things. So something that would have to live outside of Garrett because it needs something that has much less friction and much easier for someone to just say, oh, five stars. I love this image. Or one star or add a simple comment that says, hey, I installed this image. And now all of a sudden, all my bandwidth is gone and my ISP says I'm running a botnet. So that would be good to be able to put that feedback out there. Well, so minimal, yeah, why don't you go ahead and ask again? Should the images be tested beforehand of some kind of review process or whatever that it needs to pass, checking that some of these things don't happen, that all the resources aren't being eaten up all of a sudden or? Right. So that's a good question. Do you have a response here? Oh, yeah. Well, there's nothing to guarantee you that some bad actor won't wait seven minutes rather than six minutes to do something bad. So he only has his hand up. I think he has a response. I had attention first to get back here. Yeah, please. Go ahead. So one more question, actually. Is there any way to actually categorize these catalogs, actually, instead of having, because there could be a different operating systems or different type of catalog them, right? So do you have any idea of grouping this catalog so that anybody logging into the website, they can see, OK, here are the grouping of things so that they can easily see the picture of it? It may not help you with the? Yeah. Well, and what we actually? Someone recommended yesterday, was it you, the tags? So yeah, so we talked about tagging and using that as a way to categorize it. And by the way, if in case it wasn't clear, this is not a merantist, like we obviously, this is purely community. So when will we have election? That's a good question. Well, we'll come back to that in a minute. And we'll come back to the tags, because Elya wanted to say something about images and seeing whether or not they were safe. Right. Yeah, I mean, we're going to start to jump a bit on the topic. Yeah, yeah, I want to. Let's try, I mean, let's try to at least try to cover the topics like one by one and capture some outcomes in the other part, because it's, I guess, supposed to have an element of the design session and what's going on here. And I just wanted to comment on the original question about validating images or different type of the artifacts. This is a very valid question. And I guess there are several levels to this. And I mean, the first thing is like, I would propose to try simple things first. And one of the simple things, just as a suggestion that we could possibly do, is to introduce a concept of trusted publishers. So I mean, validating each and every bit of information would be a lot of clutter and a lot of work. But if we have a concept of like kind of validated publishers that kind of we generally trust as a community of this catalog, and it could be some kind of open process of how this certification goes, that might help to kind of, yeah, you establish yourself as a kind of trusted publisher. And then you can publish kind of the information, maybe just differentiate it somehow. This is information that's going from the trusted source. Right. Right. Yeah. So the question is, wouldn't that be externally controlled? Like, who do you determine? Who is a trusted publisher? And so before we get completely bogged down the details here, I think, and I will then, yeah. Docker has the same problems with the Docker hub. So maybe looking at what they've done might help. So we actually did exactly that. And it's a different thing because they're a commercial entity. And what they've done is they have a dedicated product manager whose job is to build relationships with the publishers. And they sign legal agreements with the publishers. So one option would be that the foundation dedicates somebody to accomplish that. So that's a valid proposal. But it's a little bit different than the normal way OpenStack works. Right. So your question, then I'm going to go back to that. Oh. Sorry. But he did have his hand up before Alexander, I think. And then I'll go back to you. Some things. They've gone through a little bit more validation. And it was a very good way to sort of begin to look at, well, OK, this is not there. And it's not been maintained for a while. Right. Yeah, so just helped a little bit. That's good. And like we were saying earlier, that it would have to be someone probably from the foundation. It would probably become their full-time job. But yes. So I just wanted to just put it a little bit different way. If we compare it with a common package repository, it's like PyP, or I don't know, Node packages and anything similar, they're not pre-moderated. So anybody who's registered with the system can push any package without any review process. But that's just a package without any trust from foundation or anybody else. So I would believe that being able to publish something should not be pre-moderated process. I agree. And in glance, we have a Blueprints. And we have initiative for signing images with public keys. The same idea we had in Murano for signing images with public keys of the developers. And the same may go for any other kind of artifacts, as a leader of artifacts. I had this in my roadmap. So I believe that anybody should be able to submit their application of packages to the catalog with a signature which binds a particular package with a particular publisher. And it's up to foundation or whoever drives the catalog as a governance to pick up recommended, trusted, validated publishers. And I don't know, like in App Store, you have featured apps or community-selected tab. And everything else can be just added in five seconds. And it's up to consumers to trust this publisher or not. OK. So what I want to do, actually, is put a pause on everything. And what we should do, I think, is just ideas, not discuss the ideas. We'll get them up on the etherpad until maybe in five minutes, probably will be enough for everyone to have a chance to say, it should do this and not debate how it should do it. Let's get it up on the etherpad. And then we can go through for the remaining time and talk about it. And ultimately, what we'll have to do is continue the conversation in the hallway and on the OpenSec.dev mailing list. Sound reasonable? Yeah. OK. From my perspective as a service provider, I think a lot of this discussion so far kind of makes a giant assumption that the image booted successfully. There's so many other options that we need to think about for the format of the image. What clouds can you actually run these images on? Right. So more details about the image, like where it can run, how it was built, so on. Right. Yeah. OK. Right. So we got license agreements and license concerns, which falls into the more image details category. Yeah. All right. I had to ask by mail one of the app catalog guys what features the VM had. It looked like it was something that maintained state. But it was like, well, if I run one of these things and I delete it and I launch it again, does my data stay around? Or is it transient? So some kind of metadata for if it's intended for just one-off little things or if it's designed to be permanently around. Right. You know, that kind of stuff. And then kind of tying into a previous comment, what things of the underlying cloud are required in order to make it work? Do you need LBAS on your cloud? Yeah, exactly. What are the dependencies? Do you need Swift? OK, so we get that. I think you need some kind of data tracking usage on the specific images. And after a while, those stats will speak for themselves. So if you successfully deployed it, and people can then both come back to that image and say, it's successfully deployed, and you have that data available. So whoever's in charge of, I forget the term, but whoever's in charge of keeping track of these things can remove useless ones over time as these stats. Yeah, exactly. So whoever's curating it, probably going to be, yeah, the garbage collection. So I would say all of that falls under kind of that same category of extra information around images. So the ability to tag them, the ability to rate them, and even a discussion thread underneath the images so people have a place where they can exactly say that, oh, I launched this image. It says you need LBAS, and it didn't work for me. Or I ran it. I tried to run on an ESXi hypervisor, and it didn't work, and someone else can say it works great on KVM. So yeah. Can I have a comment? Excellent, thank you. OK, we've got words here. Yeah, we had similar discussions in the product managers sessions over the last week, and they're like at the same place trying to get their feet wet here. But I think that it would behoove us to have a lease with that team, because they're trying to solve some of the same problems. They're trying to put governance and infrastructure around all of this wonderfulness, and the fact that there's so many products out there. Compatibility is a huge issue. And I think the concept of tagging fits exactly in what the product managers are doing. Yeah, and that's, I think, yeah. So tagging and collaborating with the project managers. Unfortunately, I wasn't able to make it to the product managers working sessions. So just really quickly, is it tagging of individual components and open stack, or is there some measure of compatibility with a tag? It's all of it, as far as I understand. To prepare for the compatibility matrix, because we're going to have multiple versions of everything running in every environment, you've got to be sure. So this has to feed into that, whether it's part of a releasable product, or if it's just some piece of code sitting out there that everybody's going to snag. It's got to work similarly, or we're doomed. Or we have chaos, yes. Or no. Yeah, a couple of things about the images, and in Glenn's perspective. First of all, we have pretty much most of our public cloud providers already permitting normal users uploading images to avoid malicious images going in. And if the marketplace doesn't validate what's going on there, if we can't trust the images there, none of the cloud providers will accept any level of automation pulling actually those images in Aether. So that's one big thing. Second thing, what I noticed is that the metadata what there is on the ML on the images doesn't actually provide most of the needed details to actually create the image in Glenn's out of those. So even you get the blob of data, you see that it's QCOW2, but you have no other properties of the image what you need to actually create the image. So I would really like to see at least the mandatory properties added on the details. Yeah, so right now, extra stuff can be added under additional attributes, but it's not checked against any YAML, so it would make sense. So yeah, I would definitely capture that. And if you can, on the mailing list or whatever, give some feedback on exactly or even update the schema and for the additional required things for Glenn's, that would be super helpful. So are those clouds also restricting docker containers? Because it's the same thing. You can get a compromised docker container just as easily as you can get a compromised Glenn's image. So I'll participate for a second. The thing about docker is that docker hub is not the only source, right? So the containers can come from some alternate source. I suspect that most of the service providers are using an alternate source, and so we could have a similar model where, and in fact, we do in some of the sub-projects. So in Murano, I know you can specify the source URL for the repo, and it's up to the service provider to point to that, and so you can create a moderated clone of the repo inside your firewall. So the service provider has complete control over what the source is. So that sort of works to some extent, but it's not going to capture the binary. Does docker container references then belong in this catalog and govern the same exact way as all the rest? That's a very good question. Good question. I think we kind of, I'm not trying to remember if we captured it already, but just the idea that there is definitely a need for more categories because there's clearly a desire to put more assets in the app catalog than only Murano, Glantz, or Heat. So I think if we haven't captured at surge, make sure we get down talking about how to add more stuff and how this should grow. So let's keep going on other ideas and before we get into the weeds on discussion again. Yeah, I have a couple of things. Like, are we thinking about having some kind of versioning for the artifacts? Like, I'm really worried about the drift of the catalog, like generating multiple instances that is just the same thing with the small delta. The other thing will be about images. I mean, are we really thinking about having rich images on the catalog? Like, it's not only the operating system, like it's going to require LBAS. I put an application inside. Will it be a kind of best practices to have just an operating system and then heat templates or whatever else Murano thinks? Like, just two. So we should certainly capture as a question. I know as I'm walking with the microphone, I'm going to put my two cents in there. I think one of the things that we could add to the catalog as kind of metadata on top of it is a set of best practices for certain use cases. I'd love to see a way to capture all of these bits and pieces pulled together as solutions for a specific use case and have those also be rated. But that's another idea that we should probably capture. Just one other idea. In my perfect unicorn world, I will see this thing. Also known as an open stack environment. Exactly. It's open stack U release. U stands for unicorns. So I would see the catalog as a federation of catalogs. So apps.openstack.org, which is like a top level community application catalog, is like a top level thing. But on every enterprise user or any grouping of clouds, they may have their particular catalogs. And the particular cloud may have like a little catalog of artifacts, which is artifact repository. And so I would see this to be like a federation of assets. Federated assets. Yeah, so it's not today, not tomorrow. But at some point, I believe we should go that way. Yeah, in that vein, can the applications catalog, the global one be run locally in an enterprise so that all the enterprises, clouds can share one? The answer is true absolutely today with the current naive implementation because you can just get clone the current implementation and change the URL. In that same vein, too, some kind of REST API might be nice so that you could integrate Horizon so that you can just search through it. Yeah, so REST API. And I had put in one of the seed ideas earlier, was it would, I think I put that in here anyway. I was thinking it would be really great if plants. Further up, it says search functionality. Yes, there we go. Glance, claret, heat, claret, and somewhere in Horizon. Yeah. Yeah, because basically going kind of aping Docker again, it would be great if you could just type glance searchubuntu14 and get, hey, look, there's this many images and glance pull and have it fetch the requirements from the catalog so that it can properly drag it in. Hey, what about glance push? Yeah, for me, that falls under the category of making it easier to add. I'll provide you some claspers back. Ha ha ha ha ha ha. T-shirt. All right, so other ideas or thoughts that we should capture before we get into the weeds on discussions and arguing? Because I know that's what we're going to do at the summit. That's all I'm going to do. That's why I'm on here. that kind of crowd. Oh, sorry. So just how far in the weeds are we going there? I've been trying to dig up support for solving some of the problems with making really generic heat templates, you know, putting keys in Barbican and being able to get the VMs to talk to them. Trying to get Nova and Keystone and Barbican and Zachar guys all in there to talk about it all at once and it's proving difficult. Yeah. I actually think this effort could be a great way to kind of force that issue. Yeah. I really want to make templates that I can put in the catalog that have no credentials at all and a user can launch and point out, you know, the credentials for their track site that they're trying to launch and it comes up with their SSL certs and everything just kind of works. That would be great. Can we capture that search? Did you get that? Or do you not understand? Get it. So the idea is that we have a way to give a best practice for componentization of each of these things in a way that you can fit them together so that you don't hard code environment-dependent attributes. Is that reasonable? Yeah, sort of. And credentials in particular, they're really hard to not put in a template today. By requiring it to be in the template, it makes it hard to contribute those templates back to a generic pool of resources, like the app catalog, because you can't write them generically. So the question also remains, so this is an interesting cross-project issue because it could be that this is actually a requirement on each of these projects that they have a common, well, it'd be nice if it was common, but a way to externalize some of those parameters so that you can manage them in a cloud or tenant-specific way after consumption from some catalog. Do you get that, Serge? Would it make sense to add other types of artifacts, for example, Tosca files or Mistral workflows? It would make sense to add other stuff, and I think we... I mean, I don't know if we captured anywhere. I know I've heard from the Trove guys. Yes, and what I'm thinking, and not to get into the discussion, but basically we need to be able to expand this and capture lots of other types of resources in the app catalog, but it also goes back to how do you find this stuff, how do you weed through it, which ties into tags, categorizations, and stuff like that. And usability. And usability, exactly. But let's capture just the ability to add more different types of assets, and yes, you had something. Yeah, I mean, we talked about Tosca yesterday, so absolutely. Right. But if you recall, about a year ago, HP had a project called Graffiti, and the concept was, and it relates to Tosca as well, which is people wanted to find specific types that are used in service templates to bring in their own definitions, and they were using tagging to identify those types, so that at runtime, deployment time, a template could be read, and look up types from a tag. Okay. That sounds like a good suggestion. Yeah. HP's Graffiti is now an experimental API in Glantz. So like most of the stuff that we're talking about can be done in Glantz partially right now. Like the artifact database layer is already in Glantz, and the API layer should probably land this cycle. We're actually going to discuss this afternoon, right, whether or not artifact should be its own project or not, and same thing for catalog and search, which is Graffiti. And can you pass the mic back? So I was going to ask a follow-on question to that. Does that mean that you're suggesting that Glantz be the backing store, potentially for the public repo? Yeah, well, again, I want to get into the, let's not discuss that yet. Let's stick on other ideas before we start discussing the backing store. Did you, or did you want to discuss the backing store? No, something else. To go back to tagging a little bit, it was the types. I can see maybe two different types of types. One is that user wants to just go to the app store and launch something, and they don't require much foreknowledge. We're deploying a cloud for research scientists, which are non-computer scientists. And the app store is very interesting from that standpoint, where they can just go pick, I want to track site, or I want a website or something, and hit launch, and it happens. Some of this stuff like a glance artifacts, or those sorts of things, are building blocks that CS folks might want to easily be able to get access to. But it's something that the other category of users might not want to see at all. And so some kind of, some way of classifying them. So even further, sorry? So Serge, I think tags are an implementation that would allow that, but I think one of the things that you're suggesting is that there would actually be a tiered user interface, sort of the kind of starters user interface. Here's your quick start, and then if you want to get into the weeds and get the detailed components, here's how you get there, like the advanced user. Not necessarily the right structure. I would even say that if we have APIs for search and filtering, we may have multiple dashboards, which display multiple types of objects. And you may customize the dashboards for particular users. That makes perfect sense. So when does this session end? Now? In five minutes? Six minutes, okay. Ten minutes, I'm hearing. Ten. Seven minutes. Yes. So before this session ends, I would like to clearly bring up a topic about community, forming community around Cadillac, especially selecting PTL, and after that selecting few people as course to push this initiative further. And I think this is the first question that we should solve after the session, I mean after the summit. And then return to all these topics, through the mailing list, through our RCs that we will establish, obviously, and go... We already have it. My bad, sorry. That's all right. And going through them. What's that? Sorry. Tag and mailing list. Yeah. Okay. Well, the one I sent out this morning was, I think I just called it app-catalog. And I agree. So we do need to kind of decide how we'll do that, build the community right now. Does anybody have a proposal about timeframe for elections or how that works? So I've seen a lot of discussions in other young projects where they decided to select PTL just the first day when the project started. But the suggestion was just work together as a group. Don't select anyone as a PTL. And then after some time it will just figure out who can do this work. Who's coordinating the most and kind of being the lynchpin. Who will be the course of the project who will be able to murder it. Also right now. So we do at least need to have a discussion about who the core committers are. On the community-building side, I would propose to start actually with actually building the community and seeing the community of people who is interested in initiative for around this initiative. And then kind of naturally, you know, there will be more and more course. Like for now there's kind of a few guys who are like originally involved. And it's like kind of a good start. And then I mean just enforcing right now like all of these elections and you know like electing the course. There's no data. I mean all of these decisions is typically data driven in the community. And right now there is no data because there was no activity. It just starts. So I guess the question. I guess the next question then is, do we have somewhere published the list of people who are core committers right now? Have we made that public? Yeah. So that's obvious. Do we have anybody who wants to be a member of that small club? So I'm one of the core reviewers right now. What I would say, Ali will volunteer to coordinate and organize right now and keep bringing people in and we'll just see how it goes from there. So you know certainly if there are other people who feel passionate that they you know want to add a lot back and help do this. I'm not going to fight for it but you know for the short term I think it makes sense to just we'll keep doing what we're doing. Certainly if someone is getting really serious about reviewing and adding things back we have the discussion on the mailing list about adding them to the core reviewers. It's all totally transparent. So right now I know Serge, myself, Tom Pfeifield from the OpenStack Foundation and who else is a reviewer? Cora. Someone from heat, I believe? Someone from heat. Is it? Okay. And also I wanted to point out that we do need the developers to develop the actual front-end because like front-end is like the first version. It's not feature, it's all of the features that you guys talking about is kind of there are none existing. They need to be implemented and JavaScript maybe. Right now just a simple JavaScript of some YAML files from the Git repo maybe we need to kind of build some kind of proper website with some proper functionality around it and that's... And for me that falls into kind of that category of the longer term planning what's the real back-end for this going to be because the long-term back-end can't be the YAML files with JavaScript in front of it because it won't scale. And it doesn't really allow for I would say 90% of the functionality that we're talking about right now so something else for us to discuss. Yeah. And from your right side we obviously will help to carry out this initiative forward but it would be really great to see other people jumping in and making like really community efforts. Right. Because I mean one of the biggest things that the reason that the foundation wanted this to happen was so that there would be a vendor-neutral common ground and so like if you look at the platform as a service stuff most of the Paz players would actually really like to very carefully build big walls around their garden all of them want to do that. And we all see that that's not really good for OpenStack. It's not good for the community it's not good for adoption. Actually getting people to all come in here and start stop worrying about their own private catalogs and just work together in one common community place is fantastic for OpenStack and that's probably one of the most important driving principles behind what we're trying to do here. So any other ideas that we want to capture? Or any hands want to be raised that are not raised? Did anyone not get called on? Because the light is right in my eye. Oh, John's taking a nap I think. I woke him up. He at least made a face at me. I guess I was wondering if there's anybody who wants to raise not a Maria to this employee to come and be a core participant. I don't see anybody jumping forward. Oh, you do? Right there? Hey. So, yay. Sure. Okay, so can you put your name in there or something so we can in your contact info so we can reach out? And the thing I'm so as much as possible let's take stuff to the mailing list too we capture the people who weren't lucky enough to come to Canada. And, yeah and I'll write up a kind of try to write up a summary of what we talked about and identify some of that. We can just do that in the etherpad the summary and we can probably do it in the etherpad and then we can add the link to the video for anybody. Yeah, so, yeah, exactly. I can scroll back up and since it will be on the video, I'll make it right there at the top. And it's on the OpenStack Dove and OpenStack Operators mailing list I sent an invitation today so if you check out those lists, there's links to this and links to the slides that Craig and I showed yesterday kind of talking about the genesis and what the app catalog is and so on. Any anything else? Any hands? How much time left? That's it. We're done. Perfect timing. Thanks everybody so much for coming. I really, really appreciate that we got some people here. Thank you.