 Okay. So, good afternoon, everyone. Welcome to the talk on application catalogs and how to understand them. The speakers today will be Alexander Tyvelkov. That's me. And I'm one of the core developers of Morano project and the driver of glare artifact repository. And clear lights of the PTL of Morano project and the core of community catalog and well, the great guy after all. So, today we'll speak about the different entities we call catalogs. There are a number of catalogs in OpenStack. There is Morano, there is glare, there is community application catalog, and different people usually mean different things when they speak about catalogs and cataloging applications. For example, even Keystone has a catalog, a service catalog. And some people think that this may be used as application catalog. They are obviously wrong. But our task for this talk is to dot all the i's and cross all the t's to understand what's the app catalog, what it really is, and what are these projects which are often called application catalogs should do with it. But let's first understand the project themselves. So, it all began with Morano and I'll pass the ball to Morano's PTL, so he'll tell the story of this project and how it relates to application catalog mission. So, it all dates back to somewhere around Havana. And Morano originally started with complex windows apps as a service. Apps like MS SQL, active directory, complex cluster, windows-based solution, and so on and so forth. So, originally Morano was something like a windows as a server, or Windows data center as a service. Hence the name. But, well, Morano, even originally Morano was more about apps and less about windows. So, with time, Linux support was added and basically any operation system support was added. Mind that that was a no big tent era. So, we couldn't be at that time, we couldn't call ourselves something like app orchestrator or pretty much any orchestrator of sorts because there was heat and that would mean unnecessary competition. But, well, hence there was some identity search. Morano tried to find what it was, how it was. And finally, Morano, and while we were looking for our identity, we were building more and more apps. And those apps were more and more complex and big. And at some point in time, they were big enough and a lot of those so that we could finally say that we should be the app store of the open stack. The official name is the application catalog service. And, yeah, then there was BigTent. So, once the BigTent was a thing, Morano applied and was like one of the first or second BigTent project with this kind of mission. This mission hadn't been changed. I think there was one tiny little change to it. More of a wording thing. Or to provide an application catalog service so that users can compose, deploy composite environments on an application abstraction level. That's pretty much our mission since the beginning of time. The beginning of BigTent. But what does it exactly mean? Here's how we imagine the application life cycle stack. And in this stack, we usually see different roles for different catalog users. So there are, obviously, should be some people who develop the apps. So these are the people who create the apps, publish, and distribute them somehow. Then the cloud operators are the folks who decide which apps go to the app catalog, to the current cloud. And now they design the role-based access, design what goes in, what goes out, how people can use them. And, finally, the end users are exactly those who, well, find the apps and say, I want this app, compose them into the application stack they need and deploy and finally use them. That's how we imagine things. But here's how most people actually interact the app stores or the app catalogs. The first one is solely about development. When you imagine, say, an app store, you don't really imagine developing for the app store. And the sixth is deployment. Again, it's not really about the catalog usage. And, well, what we really know in Murano how to do is we know how to write apps, deploy apps, and combine them, have the life cycle for these apps. But some of these things are more about categorizing and catalyzing things. And this is not exactly what Murano is good at. So these four middle blocks are a little bit special. There's an inner story of their own inside the app, which has nothing to do with the complex deployment in orchestration scenarios. And that's why they were, we decided that it would be logical to extract some of that functionality to a standalone component. And that is the component that is known today as glare. It's glare. But let's nail the things down, since it's not very easy thing to understand, and that's why I'm here to help. So, as Krill said, it all began with the extraction of these four middle components into standalone service. But in the beginning, we just were doing it as part of Murano itself. We just identified a set of use cases we need to handle for this application repository thing. And this would be just plain old index of binary assets. That's it. We are just cataloging binary assets. These assets have some metadata. They have some dependencies between them. They should have versions assigned. And they should have some, well, pretty basic role-based access control rules and other stuff you usually expect from the catalog. And initially, we started implementing this inside Murano itself. Like, Murano can do lots of things, and we started just baking this package repository thingy into Murano. And basic, the first implementation was pretty naive. We just even were storing the packages as zip archives in my SQL database as blob fields. A lot of you who are developers probably know that's really bad. Well, luckily, the size of the packages was small enough, and this didn't impact performance much, but still, it's bad from an architectural point of view. And at some point, we understood that we are reinventing the wheels. We are just building the things which has no Murano specifics in it. Other projects in OpenStack ecosystem would probably have to do the same. Like, for example, at that point of time, HEAT was thinking about how to catalog the HEAT templates for their usage. They were using HEAT as a storage for that template, and they needed some more appropriate way to have a catalog of packages. So we went to the community and proposed to spin up a new project, which would be a repository of assets, of artifacts, we call them, but we got a counter-proposal from the technical committee. Once again, this was a pre-big-tent era, and there could be no competing projects in OpenStack ecosystem. So the technical committee said that since there is already an OpenStack project which acts as a catalog of assets, and the project's name was Glance, so instead of just spinning up a new project, we should join the Glance team and just enhance Glance with the ability not to just catalog the VM images, but other assets types as well. And so we decided doing that. This is a development history of the feature known as a Glance Artifact Repository, or GLARE. So we began development in the KiloCycle, and by the liberty we had the first working prototype, and at that point we were considering it as the version 3 of Glance API. Glance had two major releases of their application programming interface, the V1 and V2, and we envisioned the Artifact interface as the version 3 of Glance API. However, the OpenStack ecosystem evolves and it becomes more and more user-centric. And because of that evolution, there is no such user-facing entity as a project. So in some sense there is no such thing as Glance at all. There is images API. And images API is very specific thing which is intended to be very stable, very well maintainable, and it should not be changing and evolving this time unless we want to increment the major version. And it should be focused on images. And Artifact's API, which we have implemented, eventually was a different thing. So we had long conversation with different stakeholders in the community, and finally we've decided that instead of being the V3 API of Glance, or V3 API of images, we should have a new standalone API which would be called Artifact's API or Glare API. And this happened in Mitaka. We have made a standalone API specification for Artifact's API. And in the Newton cycle, in the last cycle we have just finished, the working group for this API has split into the standalone working group, standalone project called Glare. So since it's now unrelated to Glance, the acronym translates not as Glance Artifact repository, but rather like Glare Artifact repository. So it's a recursion like GNU. And, well, this process was kind of painful. You may see by the changes of Glance mission. It all began like the mission to provide a bootable data essence, build VM images, then it was changed to accommodate the needs of Artifact's, and it was more generic statement. And then finally it was changed again, and now it says about the bootable VM images once again. This just demonstrates how complicated the process to align all the APIs and all the project missions in the upstream, but eventually it all leads to better granularity and better user experience. So this thing that Glare now covers these two blocks in our usage stack, but what about the upper two blocks? So today we're not used before the Vancouver Summit, and then another project appeared. Kirill, please tell us. So you're winding back to Vancouver Summit's apps.openstack.org has been presented there, and the ultimate goal of the project is, was, and is to have a single entry point, a single place to discover all things that run on OpenStack. And from the app user perspective, from the catalog user perspective, this exactly fulfills this publish and distribute and find an input part of the app lifecycle workflow, from the catalog workflow. It was already a big tentera, so it's not just a website or some Git repositories, but an OpenStack project with a mission, and here the main part is to give users a central location to find and retrieve apps, cloud native apps. Originally started with Morano, Glance, and Heat templates, now with Doska, always open to contributions of both individual assets or new assets types, so not limited to any of those. So here's what it is now. It's a website at apps.openstack.org hosted by their foundation. Go visit, download the things you like, share the things you have. No really extra cloud components needed. Of course, if you want Morano, you'll need Morano on the cloud, and Heat if you want to consume some of the Heat templates. But, well, strictly, you don't need those for Glance images. And there's a Horizon dashboard plugin available that will allow you to do that from inside your cloud. Still, we have some limitations there. The main thing right now is that all the assets are described in a big static YAML. The way to add an asset there is view base. You have to submit a review. You need to note just a tiny bit about how submitting works, how OpenStack review process works. And we have a simplistic V1 API that allows you to retrieve all the things, but doesn't yet allow you to upload things through the API. Those things are roadmaps to be fixed in Okata. So here we have the three catalogs of things. So how do those align? So we just reviewed, quickly reviewed the three projects, which are usually called catalogs. And now we have like three major questions. Like, there is an application catalog, Murano, but it actually doesn't have the actual catalog capabilities. There is a community catalog, which is also a catalog, and how does it fit in with Murano. And then, finally, there is artifact repository or glare. How does it fit in in the picture? And the answer is that when we are just speaking about these components, we are looking from developers' point of view. That's how developers see this, like company in one, company in two, company in three. But the users, as we said before, do not care about projects or components. The users just consume a single application catalog user story. They have a single feature, single catalog experience, and they just have a single workflow, starting with Create and then with Deploy. And they actually don't care much about what are actually bits of software code running under the hood of different infrastructure solutions. So if we look at this, we just understand that there is an application catalog feature, which is much more than any of the projects besides it. So is it a program? Yeah, kind of. At some point, OpenStack had the notion of programs. Then it was abandoned in favor of other notions. But in this case, we may speak about app catalog as a feature, which is more than any of the projects which compose this feature. So yeah, it's kind of a program. We just need to understand that the projects which compose this feature are still different from organizational point of view. They are made of different people working on different schedules and different communities and different time zones. But what we are trying to achieve right now is to align the roadmaps of these different projects to align the goals of the teams, to align the, well, whatever code we write, to meet the single user's goal to get the application catalog up and running from A to Z. And that's why we are trying to bind all those things together. They have value on their own. Like Morano may deploy application packages without any community app catalog thing. Community app catalog may be listed even if you don't have your OpenStack cloud at all. It has its value on its own. And glare is just an optional back-end. It's an implementation detail on how to store images, or images, or heat templates, or Morano packages, or any other artifacts. But in synergy, they will give the end users the most benefits. And so that's what we are working on, as three distinct community initiatives to make a one. And so this is a work in progress. And Kirill, being a PTL of Morano, can give us an update on what's actually going on in a community report. So yeah, kind of community report of things going on right now. Here's what we have achieved in Newton. So there's the unified dashboard. I actually think we only merged it right after Newton, so you need a more recent version. But anyway, it's a single horizon dashboard to browse remote and local applications. And that's the way forward. That's the way we see it should go. It's going to evolve. So now it allows you to see both the remote assets in the app catalog and the local assets in, say, local apps in Morano. Then Glare has been incubated into a standalone project. It has the artifacts V1 API released. It's not yet a Big 10 project, but that's an intentional decision to have a faster development pace at this point. But that's probably going to change and Glare is going to apply for a Big 10. And Glare is experimentally used both by Morano as a backend for storing the assets, and we're trying to abandon and deprecate our database storage. And for the community app catalog as a backend, we are really close to deploying a staging server with the Glare. All the bits are already there, already here. That's how it actually looks like right now. So we have the single app catalog dashboard with all the stuff there. And by the way, if you only need Morano, if you only need a catalog UI, it will still work together, oh, or without each other. But yeah, it's intended to work in synergy. And here are some of the plans that we have for Occata and Beyond. Well, first of all is adoption of Glare V1 for both Morano and the app catalog backend. In Morano, we use the experimental V0.1 thing. So now that Glare has published the V1 and it's stable, we're going to transition to that. Same with the apps OpenStack.org. We had plans to use the experimental V0.1, but since V1 is now there, we're going to use just that. Then improved API for the app catalog that would allow you to log in, upload from the API, possibly the UI improvements that would allow you to upload from the app catalog dashboard from the app catalog UI. And finally, we are actually doing a lot of things to improve operators' life. We want these three components to be deployed as easy as a single one. There's a lot of work on the Morano side on making, installing, and having Morano installed simply. And yeah, finally, we can't for Glare. And well, we'll always like to welcome new contribution possibilities. All the three projects are open for new contributors, or new contributions, be it the assets, types, code contribution, user feedback, operator feedback, stuff like that. And I think that's all we wanted to say today. I hope we have cleared up the situation and the confusion with all the app catalogs in OpenStack. And if you have any unanswered questions, we are here to answer them. Not sure if you have a mic. Yes, of course. In Python Morano Client, we started that work, I think a couple of cycles ago, to have our own plug-in for the OpenStack client. At the previous summit, we had a conversation of exactly about that on the app catalog working sessions. I think we had two conversations, one about the dashboards and the second about the CLI. And we implemented the dashboards, but didn't touch the CLI yet. That's exactly the case, exactly. That's a very good question because this OpenStack Unified Client is a very good example of the users caring about features and not projects. Like, the old clients had all those commands starting like nova, list, something, or hit, list, something. In the Unified Client, the users care about OpenStack and their features. They say OpenStack servers list. And in this case, this should be one of the integration points of these three projects into a single app catalog as a feature. And this will be like... OpenStack applications list. Yes, OpenStack applications list. So it has to be designed properly to include both local and remote case, but it should be a single entry point of the users to work with different kinds of applications provided by different servers, regardless of which particular services they have in a local cloud. Other questions? An instance of the running application. An instance of the running application. Yeah, so the question is how to identify the instance of the running application. So it depends on what particular OpenStack service you use to run the application. From implementation point of view, it depends, as I said. So as we have demonstrated, right now we support different kinds of applications in the cloud. This may be the heat templates or the Stosca blueprints, Morana packages, or just plain images with pre-baked software. But as we said, from a user's point of view, these are just applications, and they have to be discoverable in the same way. And that's where another OpenStack project may come handy. There is a project called Searchlight, and it's like a cross-indexing thing which allows you to index different types of resources owned by different types of OpenStack projects, but groups them or arrange them by different kinds of metadata associated with them. And so if we just have a centralized way to spin up applications, then we may add appropriate meta-informations to them, and so we may use Searchlight to search the resources which belong to particular application entities, the instance of a particular application. And this is yet to be defined. This is another point of integration between different projects to have the combined and unified user experience, but we definitely are working towards that. We actually had this kind of conversation when we were discussing the unified dashboard that we should be somehow able to identify, say, if you have a glance image and you use that as an application, then probably the VM spawned from that image is the running application. So, of course, with Murano we have that, but you may not have Murano. So, yeah, we had that. We've discussed that, but it's complicated. We'd like to do that. There's not an easy solution to that, but yeah. But there is a way towards it. There is a clear direction where to go, and yeah, that glare, that glare, yes, it does. So, it's a separate service, a listening on an independent port, and it's listed in Keystone Service Catalog as Artifact Service. So, it's independent, and by now the version one even has a distinct code base. The experimental version 0.1 shared the same code repository with the main glance, but it turned out that the code overlap is reasonably small. Glance has lots of image-specific things, and it's much easier to create a cleaner and lighter implementation from scratch. So, we decided to separate the repositories. Of course, we use the same libraries. For example, we use the so-called Glance Store library to access the underlying storages to retrieve the actual bits, actual binary information from, say, SWIFT or SAF, or whatever you use to store your bits, but the source codes are different for Glance and Glare. So, theoretically, you may install glare without having Glance. I don't know if it makes sense a lot, but at some point, I believe it will be. So, you're right. Right now, Morano is using v01, the experimental thing, and the experimental thing is currently in Glance code base. It's in Glance code base, but it's still a separate part. It's a separate project, but, yeah. It's a bit complicated with all this moving from a v3 to a separate API to a separate project. I understand all that. I regularly get that kind of questions about this contribution. There will be emigration. So, there will be a deprecation period, first of all. So, by now, the glare support in Morano and Newton is experimental. By default, Morano still uses its legacy database-based back-end. And, like, if you're using Morano in production, you're probably using the legacy Glare database and the legacy non-glare database, unless you configure it otherwise. So, what we plan for Occultant in Morano is to switch this default to use Glare by default and Glare v01, not the v01, to announce the legacy implementation of storage as deprecated. Deprecation in OpenStack means that it's there for at least a cycle. And it means that if it's announced as deprecated in Okata, it will be removed, not forever. In Queens. Queens. Okata, Pike, and only in Queens. Officially, Morano doesn't have this badge for those standard deprecations, but we want to apply for that for no reason to break the rules. And by the time we announce the deprecation, we'll have the migration utility, obviously. It will be just part of Morano which announces this application. We don't have that now, but that's a really good feature request. Definitely need to know that. Other questions? If you're raising your hand, but I don't see you, just please speak up. The lights are very, very, very bright. I just don't see you. The faces. There are some. But if there are no other questions, then thanks for coming. Thanks for joining. I hope this stopped. Use the applications. Write the applications. Launch the applications. Yeah. That's it. We love applications. And downloaded them from community app catalog. Don't forget that. Okay, thanks.