 Hi. Welcome to the session on the Evolution of the Glance API. I sort of have a favor to ask as long as I've got people here from all over the world. My daughter's fifth grade class is collecting postcards, so if you are so inclined to send a postcard when you get home from wherever you live, that would be great. You can take a picture of that, or this will be in the slides when I upload them. Okay, let's get to business. Okay, so the Evolution of the Glance API, talking about on the way from V1 to V3. Just a word about me, so I'm Brian Rossmata. I'm a senior software developer at Rackspace. My Twitter handle is BrianR. You'll see me in IRC as Rossmata. I've been in OpenStack ATC since Falsum, and I'm a driver for Glance and also for Searchlight. I'm not Nikhil Komomar. He could not be here. Had to cancel his trip, so I'm just filling in for him. All right, so at Rackspace, we have this product called Cloud Images. You may have used it. It's basically the Glance V2 API, so that's it. We're talking about the API going from version 1 to version 3. This is like version 0 of the Glance logo with the complete with the CD. All right, so when Nikhil asked me to fill in, I think I took the title too literally, because I thought, you know, Evolution, let's see what's happened with the API. I think he had a more focused idea of what he wanted to talk about. But I realized we're at the, we're planning M, so we're halfway through the alphabet. It makes sense to sort of go back and see what's happened with all those letters that came before and up to L and see what's going on. So what I'm going to talk about is the Images V1 API. It's not going to be an exhaustive look. I just want to say some highlights about what's been implemented and have some interesting observations. And then with the Images V2 API, sort of the same deal. So it's not going to be an exhaustive tour of every feature in Glance, but just some of the highlights showing what's happened with V2. And then a little bit of foreshadowing about the future, where V3 is, and that's what Alex will be talking about. So I'll just give a little hint and then he'll take it from there. Okay, so in the beginning there was Nova, which is dramatic, but not quite true, because there was also Swift hanging around. Now, let me see if this will work. Stuart McLaren made a nice chart, and I'm not sure I'm going to be able to find it here. So this is from a talk Stuart and I gave last summit at the Design Summit, we're just trying to figure out exactly what to do with Glance and how it should evolve. This is a nice chart of just how OpenStack has evolved over the years. Now, this was true as of the last summit, so with the delivery of Kilo. And Stuart's sort of observation was just that what you see is right, basically you start with Nova and then it's just shedding projects like crazy. But when you look at Glance, Glance has taken on a few things recently. You can see the little bump there is the mission change, that's Juno. So right after Juno, we have artifacts, metadata, and elastic search coming in. What's not in this picture is elastic search has gone back out of Glance with this release. But that gives you an interesting idea of how OpenStack has developed. All right, let me go back to our regularly scheduled show. Okay, so alphabetically, let's take a look at what's happened with Glance. So Austin, all right, so the Austin release was five years ago. So October 21st, 2010, and it's a release of three components. You had the OpenStack object store, Swift, you had OpenStack compute, basically Nova, and you had some OpenStack clients so that you could use the other two items. Now, when I found out I was going to do this, I contacted, well, I sent emails out to former Glance PTLs, trying to see if they had anything they'd like to say about Glance. This is from Jay Pipes. So he said, Corey Wright and Rick Harris had originally created a set of endpoints called Teller and Parallax that eventually became the Glance registry and the image streaming services. They were modeled after similar image services inside Slicehost, if I remember correctly. So what's actually in the Austin release notes is that there's a partial implementation of an image registration and caching proxy named Glance. And it's not enabled by default and it's only used by Nova with the OpenStack API. So when Nova uses the EC2, it would use the S3 type store. And then there are some interesting known issues with the Austin delivery. So images without RAM disks were not supported and the OpenStack object store unfortunately didn't support any objects greater than five gig, which if you've been working with images recently wouldn't do a lot for you. So Jay said, started working with Corey and Rick and what would become Glance from the Teller and Parallax code in the Austin timeframe. For the life of me, I can't remember if we had anything called a PTL back then, or even when I became Glance's PTL or even why. I think I just kind of fell into the spot of PTL for Glance around the Austin release. So that brings us to Bexar. So in Bexar, Glance's APIs for the registry and the delivery service were unified and a specific client class was created. And then that's the publication of the images 1.0 API. And then there was support for uploading disk images directly through the Glance, RESTful API, documentation for Glance was available. This is a kind of interesting one, the dependency in Twisted was removed, and Glance only used Eventlet for its server side internals. Then some known issues, the S3 and Swift back ends don't support posting to images. You could only do gets on them. And then full support was projected for the Cactus release. So then in Cactus, we see the images API continuing at version one. There's an introduction of a Glance CLI tool. Introduction of some metadata, disk format and container format. Check some for verification of uploaded images. And then lots of other changes that should go unnoticed. But they actually did get mentioned in the release notes. So support for database schema migration, non-static versioning, standard use of paste deploy, config parser, and op parse. So all stuff that you'd expect probably wouldn't notice, but they are now in Glance. That brings us to Diablo. So with the API enhancements, first thing is there was versioning of the API. And the reason we had versioning of the API was because 1.1 was released. So 1.1 becomes current, 1.0 becomes supported. Then the additions in Diablo are custom ordering of results, results filtering, results limiting and pagination, and the new ISO disk format. And then there were some performance improvements, local file system cache, delayed deletion of images, integration with Keystone, sharing images between tenants. We've got that in bold because that's why there's a new API, because the image sharing calls were added. Event notifications and internationalization of error and output messages. So a lot of stuff in Diablo. All right, so we go to Essex. The focus of the Essex release is on stabilization and usability. So basically the API stays unchanged from the previous release. With 1.1 as current and 1.0 supported. Contributors fixed 185 bugs and implemented 11 blueprints. It's great that all those bugs were fixed. Introduction of role-based access control, introduction of protected image properties so you wouldn't delete things by mistake. Configurable number of API processes, you could get, you could copy from, well, implementation of the copy from functionality. And then there was an image upload progress bar in the Glance command line interface. All right, and then with Falsum we get some more excitement because that's when version two of the API gets introduced. So 2.0 and 1.1 stay current, 1.0 is supported. We have a Python Glance client that replaced the earlier client and then some things like SSL certificate validation, tenant-specific storage and Swift. So we go from having only the single tenant store to a multi-tenant store. And then there's the Glance replicator that would allow you to replicate images. And so the key question here is why version two? And version one of the images API was not really designed for human consumption. So for instance, the way it would work is that when you did a get, well, the way still works, right, if you do a get on V1 images with the UUID, it returns the image data and the payload and then all the metadata and the image properties are in headers. So that causes a bunch of problems. I'm just going to list a few you can imagine the rest yourselves. But for instance, so the number of loud headers can be configured at multiple places in the request chain. And so Glance might not even see some of them. Various components in the request chain think nothing of monkeying with headers, right? They don't monkey with actual request bodies. But with headers, they seem to be fair game. So all sorts of things can happen. One sort of theoretical thing is when you use the server's API, so the compute API, and you do a get on V2, your tenant ID, servers and the UUID, what you get is a representation of an instance, not the actual instance. And so it makes sense that with the V1 API, if you do that same type of call, you actually get the image data delivered to you, right, the actual image thing, not a representation. So for sort of consistency with OpenStack and general Rust practices, it makes more sense that with the V2 API, what you actually get returned is the representation of the image to work with. And there were some architectural considerations. V1 is designed to use the Glance registry, which introduces an extra layer between the images API and the database. And you can use your imagination about the additional complexity you get without much payback. So the idea with version two is that it's going to include features suitable for making the images API public. So as you saw with the chart from Stort, Glance got split off from Nova. It was really designed for Nova to use. And if we're going to have people use it, we need to do some work. So projected stuff would be anti-spam image sharing. So it changed in the image sharing model. Property protections so that deployers can put licensing information or other data on images that the owners of the image can't mess with, right. Possibly a distinction between an import process from end users, bringing stuff into the cloud as opposed to image upload, which would be an admin or Nova putting an image in. And there's some architectural considerations. So with v2, a new domain model was introduced consistent with sort of modern software engineering practices. And then the Glance registry becomes optional so the v2 API can deal directly with the database and eliminate that whole extra layer of complexity. So that was falsome. So now in Grizzly, we get another bump in the API. So now it's version 2.1. So 2.1 and 1.1 are the current ones. 2.0 and 1.0 are just supported. The new features are version 2 of image sharing, JSON patch, draft 10 support, and then Glance control status that will allow you to monitor the status of Glance programmatically. And Glance manage downgrade would allow you to downgrade easily from Grizzly back to falsome if there was a problem. Then with Havana, we get version 2.2 of the API. So we're moving pretty quickly. So 2.2 and 1.1 are the current ones. And now we have three supported versions of the API. And we have multiple image locations. So that was a change in the response that merited the bump, I think, in the version. Property protections, the images, and the registry API, and some policies on image membership. And then some backend storage support for various storage like Sling, Sheepdog, Cinder, and GridFS at that point. Okay, then we go to Icehouse. All right, no changes in the API version. We got a new storage backend from VMware. There was an image location selection strategy to take advantage of the multiple image locations that have been introduced the previous release. And then there's a new field added on the image object virtual size. Got API message localization. Improvement in the way you calculate quotas. And then zero-based indices in the multiple locations because of the JSON pointer standard. Okay, Juno. So again, no changes in the API versions. But we do have asynchronous processing introduced in the Juno release. So that's the tasks endpoint on V2. Glant Store got pulled into its own library. So the backend code that stores images is now in its own location. And we got the metadata definitions catalog. So a new endpoint V2 meta-defs was introduced. And there's a restricted policy for downloading images. And also with Juno is the mission statement change. So the original mission statement was merged June 11th, 2014, which is not a typo. It turned out that the mission statement for Glantz had never actually been filed anywhere. So when we wanted to change the mission statement, we decided we first had to put the mission statement in that said what Glantz was doing up to now, and then we would put in the one that said what Glantz was going to do. So the original mission statement describing Glantz basically up until Juno is that it would provide services to store, browse, share, distribute, and manage bootable disk images. And then the change was done a month later. And the change, so the new mission statement of Glantz from Juno on is to provide a service where users can upload and discover data assets that are meant to be used with other services like images for Nova and templates for heat. And that takes us to Kilo. So some features of the Kilo release, there's enhancements to the image import process. So basic support for image conversion and image introspection. Reload configurations on a signal. MetaDef's got a whole bunch of stuff, tag support, support for multi-value operators and software metadata definitions. Also changed to allow none values to be returned from the API. And the digest algorithm is configurable. Okay, and then with the Kilo release, there are some API changes. So there's image deactivation was introduced so that an admin could make it so that you can't actually use an image in case it needs to be investigated for some reason. And so the images API version got bumped up to 2.3. So that became current, 1.1 became supported. So this is also a change. 1.0 and all the other ones are just supported still. And then there's the catalog index service as an experimental API in Kilo. So a lot of stuff happened in Kilo. So with the API changes, just downgrading V1 from current to supported is a step toward deprecation, right? And the ultimate elimination of the V1 API. So ultimately we'd like to see this thing go away completely. All right, and then that brings us to Liberty, which just came out about a month ago. So we've got support for uploading signed images, scrubbing images in parallel. There's health check middleware to monitor the health of a glance node, changing the Python glance client so that it defaults to using the V2 API. And then catalog index service has pulled out of glance and is now its own project of Searchlight. So since the kill couldn't be here, I've got a few quotes from him. So the current glance architecture tries to handle three domains, namely metadata registry, image format, and interface to store image data blobs. It becomes ineffective at handling each of them at large scale, mainly as the separation of concerns is weak. So I find an indexing mechanism better at handling large scale image and related metadata, like properties, tags, and members info, a dedicated transfer logic to better handle large scale data blob movement, and some asynchronous way to cleanly handle the image interoperable formatting. So in Keelan and Liberty, I've attempted to provide a platform to developers, operators, and product managers alike to bring glance to a state that would handle each of these domains in a better manner. So that's from Keel. All right, so with the Liberty release, the API changes. The artifacts API is now available for use. It's exposed as V3 on the glance endpoint. It's marked as experimental. So 2.3 is current, and then everything else at this point is just supported. Okay, and then Y version three, just here's the foreshadowing part. So generalization of glance from cataloging and delivery of VM images to cataloging and delivery of digital artifacts. So some of the shortcomings of glance images are addressed by artifacts. So images are unversioned, but artifacts are versioned. Images are independent items, whereas artifacts can have dependency relations. And images right now have a single payload, whereas you might want to have multiple payloads. So the other thing is an artifact, cataloging and delivery project would duplicate a lot of glance functionality. So it seemed to make sense to try to put the two things together. All right, so this brings us to M and halfway through the alphabet. So what about Metaka? Well, that's what we're here in Tokyo for. So you can check your conference schedule. Most of the glance design sessions are tomorrow. So feel free to come by and see what's happening. After the summit, you can go to the specs.openstock. org and find the glance specs for Metaka. And then if you want to see the discussion that's going on, if you go to review.openstock.org, you can search for the glance specs and see the discussion on the patches. And then there's going to be a priorities document among the specs, certainly after the summit. So Flavio has put up a pull request already. There's comments. I think the idea is to get that merged probably on Friday or something so that we know exactly what we're doing. So away you go. All right, and then just want to some thanks to the people who've made this talk necessary. That's sort of a tribute to Yogi Berra who unfortunately died the past month. I know baseball is very popular in Japan. So I thought I'd get a Yogi Berra reference in here. But these are the glance PTLs. So starting with J-Pipes who really did a lot of PTL work for four cycles. Brian Walden, Mark Waschenberger. I can't find a photograph of Mark anywhere and he refuses to answer my emails. So this is the image he's got up on his GitHub repository. So I put that there. And then there's Nikhil and then Flavio who's also in the back of the room is up here. I just want to close with a quote from the first glance PTL J-Pipes. So the hindsight is of course 2020. If I had it all to do over again I probably would push for not having an API's image streaming endpoint at all in glance and just have glance be a general purpose metadata registry. So I promised I'd share his view. So there you go. All right, so I just want to thank you for listening and a reminder don't go anywhere because Alex is going to take it from here. Thank you, Brian. That was a very good history drive. So let's now speak. Why do we want to proceed further? So I'm Alex Devilka from Arantis and I've been driving the Artifacts Initiative since it began almost two years ago. So I will start with a history to proceed the way Brian took and I'll just describe how this idea appeared at about Ice House timeframe about almost two years ago just right after the Hong Kong summit. There were two concurrent initiatives in OpenStack community. One was led by HIT, HIT team and another one was led by my team, by Morano team. We are both were trying to have the repository of things having both binary data and metadata and to have like search API and indexing API and the registry API to browse them and leave them. And we had some kind of a hot discussion. Well, when you are working with HIT, the discussions are always hot. So we had some kind of a hot discussion in mailing lists and finally the technical committee had their final word on that saying that guys, you're inventing the wheels, stop doing that. There is a catalog of things in OpenStack and that's glance, go there. And so at the mid-cycle of glance in January, 2014, we had the first gathering when I joined the glance team and just expressed the idea of artifacts and glance and it was well-met by the team and we just began learning the core concepts, began to know what do we need, what do we want. Eventually that led to the change of the mission statement Brian has told us about. So at June when we have changed the mission of glance towards the artifact repository of things reusable by other project, we had all those core concepts. We knew that the artifact should be versioned objects, having some strictly typed schema reusable by other OpenStack projects, such as HIT, such as Murano, such as, while there was interest from other components such as Sahara, Solum, it was alive at the time and others. And then we had like different concepts like dependency relations between them, multiple binary objects, type specific and type independent schema properties and the interactive creation of artifacts when you create a draft of an artifact then modify it relatively one by one, uploading its binary parts and changing the data. And then you just set it in stone, like publishing the artifact, making all its properties immutable so you have its available in the catalog for the usage. So all of these properties were settled by the June timeframe. At Applanta Summit, we have presented the core concepts, approved them and proceeded with them in the next cycle. So in the key of the actual work has begun. So I've got a team, we've joined the core team of the Glance and began implementing what was later called Glance v3. So for time being, it was part of the v2 branch of Glance v2, we have added the data model, we have added the domain layer in the very same manner as Glance domain of v2 is organized in the layered model, having each layer representing a particular aspect of API and registry. So we just reused the same approach, popular among the other open stack developers. And I would even say enterprise developers, Brian has said layered domain models are mostly originating from enterprise world. And we have created the plugin loader which allows to load the type definitions and easily extend them by providing new plugins, having the schemas for artifact types and defining the structure, defining the binary contents, defining their type specific metadata properties and their life cycle. And by the end of killer, well, we actually planned to have artifacts landed by the end of the killer, but the amount of work turned out to be too big and eventually the final steps were postponed till Liberty. And by the release of Liberty, just one month ago, we've got the follow functional artifacts implementation exposed as v3 experimental Glance API. It was decided on the Liberty Design Summit that we are going to be the v3. Before that, we thought that we'll be separated into two different endpoints, but at Liberty Design Summit, we decided to stay in Glance in the same process on the same port, but under the different URIs. And that's intentional. We do not want artifacts API to be confused with v2 API with images API. And important thing here is that v3 is not going to replace or substitute v2 as they were developing in Peril. They will coexist in Peril for quite a long amount of time because of the deaf core initiative you probably know about the OpenStack APIs, the APIs of the core OpenStack projects have to be stable and maintained for a long time. And v2 API of Glance is part of the deaf core definition. That's why it will remain stable for a very long amount of time. So we have to coexist with that. And because of that, v3 and v2 will not compete. They will coexist and they will exist for different purposes. v2 will remain the primary OpenStack images API while v3 will remain the artifacts API for everything else for all other projects to use their binary assets in OpenStack. But before this happens, we have to solve a number of API issues which we have faced during the Liberty Cycle. We were lucky enough to get lots of feedback on the proposed experimental v3 API. OpenStack's API working group has provided a tremendous feedback on what we have done. And I just want to highlight some of the issues we have in the present experimental v3 and how we are going to solve them. So one of the important things we have in v3 is a type versioning. So schemas of artifact types are versioned as well and that's intentional. If the particular OpenStack project which wants to store their data in Glance adds an extra field or adds extra binary object to their artifact type, it changes the schema. And we have to somehow maintain that. We support this in v3, however the API gets confusing URIs because of that. The URI may include or may not include the version suffix for the version of the plugin and this adds complexity to the consumers because the same artifact can be accessed by the URI which contains the version of the plugin and the same URI but without the version plugin, the version of the plugin. The artifact is the same, however, if the plugin is upgraded, the version of the plugin changes but artifact remains the same. This contradicts to the basic REST principles. The URI of the resource would remain the same for all its lifecycle. It should not change if some infrastructure components such as plugins are upgraded. So this was one of the main concerns of the API working group and we are going to address that by separating the type version from the artifact itself. So the type versions of artifact plugins will be similar to the API versions. So for now, as Ryan has demonstrated to you, for example, images, maybe the same images may be accessed either using the v2 API or v1 API and both of these API allow to access the same image but with different set of features and capabilities. The same will happen for artifacts of the same type but different plugin versions. So the plugin versioning will be handled as a versioning of the private APIs of the particular type or the particular artifact type and particular artifact type plugin. And another important issue with the v3 API was that we had different collections of artifacts in different states. In the URIs of our APIs, we had the sections for artifacts in a different state. In regular correct restful APIs, you usually filter by the name of some property but due to some earlier feedback when we were just prototyping artifacts in KiloCycle, we decided to split all our artifacts into different collections if the artifact is in the draft state or just being created iteratively, we were putting it into the drafts resource collection under the v3 API and if it's ready, we were putting it under just artifact slash artifact type slash the ID resource collection. Once again, this means that during the artifact lifecycle, it changes its location inside the URI URI pass and this contradicts with the restful principles. This is one important flaw of our artifact and it has to be fixed of our artifacts API. Another important thing is that the filtering of the artifact collections should be different for artifacts in different states and for different use cases, for different usages of the API. If the consumer wants to get the artifacts which are ready to use, there are different default filtering values than for artifacts which are being just designed or artifacts which has been, for example, administratively disabled. So this has to be streamlined, this has to be just brought to the common denominator under all the artifacts API and that's what we are going to do in the next cycle. So this is required to, that's required for us to move from experimental to stable. We should address all the comments of API working group. We should eliminate these draft sections in our URI locations and we have to bring artifacts closer to images because right now the images are accessed only via V1 or V2 glance APIs while artifacts are accessed only via V3 and the data structures are quite different they're separated entirely. This is a legacy of the killer killer cycle when we envisioned artifacts as a standalone entity which could be even using the separate database but now we have to have a clear roadmap on how to merge the data structures for artifacts and images. Eventually the image should become, the image should become a regular artifact. They have different data models, they have different properties, they have different extra features, they have different life cycles but eventually they have to become the same and this is a main design challenge for us for now because we want to bring images to V3 without compromising V2. We don't want to change any of existing deployments, we don't want to putries counter-existing production V2 usages but we want the V3 to be able to operate on both images and other artifact types. That's what we're gonna do in Mitaka and probably the next cycles. So for Mitaka our primary goal is to technically stabilize the API. We cannot promise that it will be officially stable by the end of Mitaka cycle but we will try doing our best to reduce the number of needed changes. If we are successful enough and if we have enough resources to review the changes and just drive all the required code changes, we will try to make it stable officially in the API listings. If not, it will be postponed till the next cycle but still we are trying to address all the comments, all the issues and have the API ready for declaring it stable. Another important moment is the cross-cloud interoperability. In this deaf core driven world when we have the definition of what is OpenStack and what is not, it's very important that all the clouds act the same. I think I had a slide for that. Yep, the APIs which are defined by the plugins cannot be considered truly interoperable and the artifacts API is defined by the plugins. So what we have to do, we have to split artifacts API into two parts. One of them will be the public API which is plugin independent. It's not, it doesn't depend that the availability of that API doesn't depend on the presence of some plugins deployed on that glance cloud or not. This API will be used to just discover the assets present at that repository and organize the cross-cloud communication if needed because eventually we want to be able to build a federation of artifact repositories in different clouds and be able to distribute artifacts among them. But this thing is just a public interaction of the user with the cloud or the clouds with each other. But when we speak about the particular projects using artifacts, we speak mostly about the private APIs of that particular project with the plugin in glance. Because of that, these APIs can be considered private and they may be plugin dependent, maybe plugin-driven, schema-driven and they should not be interoperable because the usage of these APIs doesn't come out of the particular cloud. So that's our answer on how to make the V3 interoperable and how to align V3 with the def core requirements. And this is another important action item for us for the Metaka cycle. We will just do this API separation and we'll attempt to just send a clear message to the users that the public API is truly interoperable while the private ones are intended to be consumed by OpenStack projects within the same clouds and they are plugin dependent so they shouldn't be exposed externally to the other consumers other than OpenStack components. So that's our plans for Metaka and we will try to address all the needs of OpenStack projects required to have artifacts in the artifact repository. And now if you have any questions on this roadmap, I'll be happy to answer. So yeah, initially, as I said, this initiative was in parallel started by Murano and Heat. So technically, Heat is still interested. They're just waiting for the API to become stable because they don't want to reimplement the plugin when the API changes. And then we had interest expressed from Magnum. Adriano has said that they're interested in that. Also now we are speaking with a community app catalog because my understanding is that they're having very similar cases for REST API and we're just in the middle of communication on that. And then there were interest from Sahara from Solom. I don't know if Solom is still alive or not. But I believe that as soon as the API is stable enough, we will have more potential plugins because this is a real common use case in OpenStack. Lots of projects and components operate on reusable data annotated with metadata. Does it answer the question? Other questions? Thank you very much.