 All right, I think we're ready to get started here. So my name is Brian Walden. I am here to talk about the OpenStack Image Service. I've been the PtL over the past release. So hopefully I know enough to actually do this correctly. So I get asked this question quite a bit. What is glance? Or specifically, why does glance exist? Which is not a really great question to get asked. But hopefully I have a pretty good answer for you here. So glance is really just a catalog of virtual images. So it's here to help you. It's not here to own your data or own your images. It's here to provide a cataloging service to help you find what you need more easily and to help interface with all of the OpenStack services behind the scenes. So over Falsum, we accomplished quite a bit. We've been talking about this V2 OpenStack Images API for a year and a half now. We finally got a start on it, which has been eaten up quite a bit of time. So we've been planning for about two releases, what it should be, what it should do. This was one of the first real APIs that the community worked together to design. And there was a lot of talk on the list back and forth. We had four or five drafts that were sent out. So we finally decided to get down to it and implement something and hope that it worked out. So we spent quite a bit of time, this past release, on specifically on implementing this new API. So going back to my hopefully acceptable answer to what is glance, glance doesn't own your image data. So we're pushing towards letting the authenticated users that are interacting with glance push data directly through to whatever storage service they're using. So in this case, we implemented tenant-specific storage for Swift, for a Swift back-end. So up until now, you configure specific back-end drivers that glance can stuff data into. But in the end, the user doesn't actually own that. It's tracked by glance. If you delete the image, if you delete the, I guess, the glance API image, that correlates directly to what data is stored on the back-end, and that gets deleted too. So we implemented this tenant-specific image storage to allow users to actually stuff data into their own Swift account. And they can see it there for the use case, which might be where you're getting billed for everything. Now anybody who's storing images for users can actually bill for that. Image replication, we've been asked over and over, can we solve the maybe cross data center image replication problem? And there are a ton of different ideas, ton of different implementations. And we said, well, we're going to give you something simple. We have essentially a Python binary, which you can use to take images that are in one physically separate glance deployment and copy them over to your whatever other deployment you might have. Now we haven't gotten a lot of feedback on this yet, but I'm really hoping to see how we can improve that and how we can move that forward in the gridly time frame. The client rewrite has been a little controversial. We completely rewrote the Python glance client and just put it out there and integrated into the project, specifically Nova and Horizon. There was a bit of a blow up on the list about backwards compatibility. So we actually ended up preserving the old interface in the new client. But it's all new code. It lines up a lot better with all the other clients. I like it quite a bit. But hopefully, we move away from having separate clients altogether to a more unified client. But this is what we've accomplished in Folsom. And as for bug fixing, we had 34 different contributors fix 125-ish bugs, which I think is pretty fantastic. But if you look on the negative side of it, we had 125 bugs in a project that's about a magnitude less in size than Nova, which fixed like 600 bugs. So I don't know how to take that. So looking forward to Grisly, we actually had all of our sessions yesterday. We didn't need much time to talk about what we want to do, because I think a lot of us are all on the same page. So we had three sessions. The first, we covered incremental images. We really want to provide efficient ways to track your images. And whether those images are full raw disk images or if they're just QCOW, well, not snapshots, but Diff images. So we talked about this idea of incremental images where an image can have a parent that when you download the child image, you actually have to download the parent and coalesce them or if they're QCOW, load them both. So moving forward in Grisly, I think we're going to explore how to do this correctly. It's going to be a lot more of coordination with other projects that are consuming our images. In glance, it's just going to be a parent ID. But hopefully, we can provide a lot of tooling around this to make it a really nice user experience. As for multiple image locations, we've been asked several times how we can fix the user experience problem. It comes up a lot. So image locations, we really want to allow users to provide multiple locations as in back-ins, so Swift or Cinder, for their images to reside. So it might be more efficient to boot your image out of an object store if you don't have it on some volume ready to go local to your compute node or if you can land a VM on that compute node that has local access to your image, then that's going to be most efficient. So this is more about enabling efficient scheduling. And as for image workers, we've had a feature called Copy From, which is an asynchronous image download when you create an image in glance. So what glance is going to do is take a sum back in URL. When you create the image, it's going to kick off an asynchronous process that's going to go pull down the image data behind the scenes. And you'll see the state transition from queued to saving to active, and the image data will just magically show up. We've had some more asynchronous processing type things come up, such as coalescing these incremental images on the back end. Once you have 30 maybe daily backups in a row where it might not be really efficient to boot off of that 30th snapshot, glance could provide some sort of auto coalesce for you behind the scenes. And there's also the topic of image conversion, which comes up every single summit, that we may end up tackling with this approach. That's not going to commit to that, but we will at least have a nice system set up to possibly tackle it. So those were our three sessions that we had yesterday. We had a lot of great conversation. We had a lot of really engaged people. I have two other things that have been on the radar through Folsom that we didn't necessarily finish in Folsom. We know we need to tackle pretty soon. One is implementing designing first. Hopefully it doesn't take another year and implementing the next minor version release of the Images API. So we have feature parity, well, I shouldn't say that. We have some level of parity between the V1 and the V2 APIs. We're missing specifically being able to create images from external locations. And with the copy from feature that we have hidden away from the user in Glance. And protected properties also, which is something people have been asking about. But we hope to very quickly rev the API and get that out in front of users, because I personally don't feel like the V2 API is ready to go until we have creating images from external locations. If Glance isn't supposed to own your data, and the only way to create an image is to stream data through Glance, that's kind of backwards. So protected properties specifically. Nova, the way it uses Glance, it ends up adding several properties that Glance doesn't specifically know about. They're metadata, so they're owned by the user. But if a user owns the image, then they can change the properties. And then what happens if Nova depends on those properties being there to be able to boot an image, or if people are billing on specific properties, and the user changes it, which changes maybe their license or something silly like that. We will be implementing a way for users to, well, for deployers to select specific properties as protected, which means the user that owns the image won't necessarily be able to delete the property, but he'll be able to see it. And maybe we need to have hidden properties also, which I think we'll have some discussion within the Glance community about that. And last on the list for Grizzly, the architecture of Glance has always been a bit interesting. The way it's set up, I'm not sure how down deep people are with Glance at this point, but it's designed to have an API layer, which talks to a layer of registry servers, which kind of, they hide away database access from that front layer of API servers. And the most common call that's made through Glance is list slash images, just like Innova's list slash servers. I mean, if you refresh that page on a control panel, that's what you're going to get. So we really need to optimize to make that call super efficient. The main API layer was also responsible for streaming data in and out of whatever stores you had configured. And if our goal for Glance is to stop doing that and to get away from it, we really need to invert that architecture to make that whatever database access that has to happen be the first thing in that layered approach. So I think we're going to look at moving image streaming into the whatever image worker setup that we come up with and make the database access on the API servers the first class citizen here. And as for domain objects, the actual code quality in Glance is questionable, mainly because we don't have any service layer. So we have API servers or API code controllers, serialization code talking directly to the registry client, which I guess it used to be our service layer, but now it's not going to be. But we had API code talking to clients, talking to API code talking directly to databases. And there was no way internally to actually do anything the correct way, which makes for quite a few bugs. And maybe that's how we got to that 100 and something bugs fix this past release. But we've had a lot of new ideas come up to how we can completely overhaul the internals of Glance while preserving the API interfaces, the APIs, but getting it to a much better place for developers. So I know I went through that pretty fast. It's not Glance Lite, it's just fixing a lot of glance. So I had a magnitude less of stuff to cover than Vishy did, so I can't fill up 40 minutes. So I'm going to leave the next 35 minutes to questions. Or we can go to lunch. Yes, right there. Oh, I'm sorry. Come on up. I guess so. So you mentioned that you changed the API a little bit to rewrite the client. The rest of the API from V1, how much did it change? So the V1 API hasn't changed at all. We haven't touched that. No, but in terms of updating V2 API, how much has that changed from the V1 interface? Right, so to give you a bit of an overview of what the V2 API is, we really wanted to explore some new ideas that we've been playing around with, move away from having alternate serialization formats for the same data, depending on what methods you were using on different resources. So we ended up communicating through HTTP response bodies all of the specific image data that you're asking for. Well, image metadata, not the binary image data. And we're also using JSON schema, which is in draft 4 right now, I think, but it hasn't not been changing very much. And it looks like it's going to be accepted. I think the RFC is going to be accepted very soon. We're also using HTTP patch, which is something I haven't seen anyone else implement yet and support for it in Python libraries isn't quite there. But we're actually spending a lot of time getting that up and ready to go. So using HTTP patch, the specific method helps make it a lot clearer about what changes you're making to JSON entities, which is exactly what we're kind of tracking here. Glance doesn't own your image data. It's a metadata record. So that's really what you're interacting with. And if you're using JSON, it's really natural to use JSON schema to tell you what that entity really means and use patch to know how you're actually changing it. So does that answer your question? Yes. Great. Another question after this. Is it a follow up? It's a different question. You mentioned something about adding this location. He said you're making changes to support SWIFT, et cetera. You're not changing HTTP location or file location. Correct. I think as a community, OpenStack is moving towards a more efficient image boot story. So I think moving things onto volumes out of object storage, out of other arbitrary backends, letting the actual storage services own that, such as Cinder, because it knows how to talk to a bunch of volume backends. We don't need to teach Glance how to do that. So we're absolutely not getting rid of any back end support. It's going to be there for compatibility, but it may not be the most common use case at that point. One more question about the API. Glance B1L supports obviously file upload. So streaming, Octave Stream, and so forth, and it's sort of hardcoded on the server. You can't really use that for my hidden frame, et cetera. But the problem is on the back end, you don't have the multi-fine support, data support. Have you made changes to support IE or file upload? Through web browsers? Yeah. No, we have not. That has never been brought up. No. OK, well, it's so my team is working on making that change. We've done a change. And I just want to make sure that I'm not sure if anybody else is doing file upload. I know Horizon doesn't really care about it, because all the images are on the back end. So how do I get that pushed back into? OK, I think were you in the previous talk? No. OK, so we would just go through the normal code review process, get it up for review with the community. And I can help, obviously. Yes, we can catch up after this. Thanks. No, I am a contributor, so I know how to do it. But I want to just get that design into stack. Yeah, absolutely. Yeah, I would love to see it. We absolutely need to care about API compatibility, specifically in V1. We really have not talked about making changes to that. But if this is something that's just a little tweak or is a real bug fix. Right, it's a tweak. It's really modularized. Make sure that we support Octave Stream as well as other forms. And that's really important for IE users. I don't really care about IE users. OK, yeah, I would love to see that. OK, thank you. Question, sir? I was just pointing about the future of the separate glance API and the glance registry server and the number of the two API talks directly to MySQL. Can you just explain to Google more about that? Yeah, so right now the, so I guess you know how the services are set up, like the Glance API service and the Glance Registry service. So the Glance API service accepts incoming requests so that's supposed to be the public-facing service that's handling user interaction. It will either go talk to your back-end store. So talk to Swift, talk to local file. And it'll also proxy over HTTP back to the registry service. So once the domain object layer is more concrete, I think the code paths between the V1 and V2 APIs will line up much better. Because right now we've been exploring this new architecture of moving database access up to the Glance API service and forgetting about the Glance Registry service, specifically for the V2 API, which was a bit of a shortcut that we took. I'm not sure how well that's working out right now. But the end goal here is to offload that streaming work to completely separate services, completely separate processes, and not have that be done by the main HTTP service that's accepting incoming requests. And to completely get rid of the Glance Registry service just because it's, I don't know why we're making that extra hop. Yeah. OK. OK. OK. I think we should continue looking at that. Because really, right now what we can do is, first off, you can keep with the existing behavior 100% by just not configuring V2 on. And I don't think it ever makes any big opportunity to like SQL. But what you would do in this case, is just you can probably look at distributing out some of the, if you didn't want to talk directly to Swift or to Cimber or something like that, some other service through the location, you could still talk to Glance. But we would just want to have some option of deploying different Glances that only offer the file part that don't need to be in the initial response. Yeah. I think we need to be a bit more transparent or opaque, one of the two, about what we're planning on doing here. Yeah. And more visible. Yeah. And get our more specific plans out there. Because we've been kind of playing around with it in code at this point. And we need to be a lot more upfront about what we're doing. So yes, I would love to continue this conversation and probably with the greater community if we're missing something here. Okay. We haven't, no, so short answer, no. We have a notification system set up in Glance right now, which is rather incomplete. It's not, I don't think it's sending enough information. It's sending the bare bones, like image was created of this size, but not necessarily more of the statistical information that you're looking for. That's a good point. So we do have the use case where people are using Glance to track images, just completely separate from all of the rest of OpenStack, which I was really delighted to hear that. I made some changes to notification as well because it wasn't rich enough. I haven't pushed them into it, but that was on ASICs. And that's another thing that I want to push into. Yeah. So we have a blueprint filed for Grizzly to actually completely overhaul the notification set up. So obviously keeping backwards compatibility, putting them in the same place, putting the same ones out there. But we need to be pushing out a lot more information and figuring out how we can consume those and actually make the whole... But you don't want to put a lot of pressure on the buses either, so that's... Oh, absolutely. It's a balance. Yes, sir. It's a balance. Okay, any more questions? I want to put the notification on, so I would love to keep the V1 API forever. There are people using it... Auditon. I'm missing words up here today. I absolutely don't want to get rid of APIs if we can support them. Once it becomes infeasible to support APIs, that's when we can talk about it. But we need to go as far as we can to hold onto those for as long as possible. One of the kind of the side effects of maintaining support for the kind of family and social information. Yeah, absolutely. Yes, like I said, the V1 and V2 paths are kind of right next to each other, but going to the same data source. And we will be lining those back up using the domain object refactoring that we're looking at. I think at the same time, we need to be careful that part of the idea of keeping the whole API around is stable. So if you do look at code, you're technically actually changing that code, right? So we'd like to reduce... Yeah, so... Since glance has only been an API up until now, it doesn't do anything else. Well, I guess it's been moving data in and out, but it does very little. The API code has talked directly to the data store code and directly to the backend storage code. So there is no real service layer to build a new API on. You have to copy all that and put it over here, and then you fix a bug in the V1 code path and then the V2 code path needs to get fixed, but maybe that's changed in a different bud. So we will have to get them lined up at some point in Grizzly, but the API code and the API spec, like the code that's specific to implementing that spec, I don't think should change, because as Mark said, you're in danger of introducing the new bug. Yeah, absolutely. Great. We don't want to keep changing the spec. Oh, no. Definitely not. Yeah, I would never change another spec. Yeah. Just curious if there's any talk about taking out the base stuff and then moving it away. So it's kind of confusing for some people. Yeah. But putting out, like, oh, here's one version of this, and the line isn't the same, but someone's renamed something. Okay. It's a hard way. Yeah, are you working off of Essex or... Essex. Okay. So in Pulsom, well, I guess I don't remember exactly, in Essex is the paste config in the main service config, or is it in a separate file? Pre-essex. Pre-essex, okay. So at this point, we have the paste config in a separate file, and we have, like, selecting a paste flavor, we're calling it, from the config, which if you're making custom changes to that paste config, then you're still kind of screwed. We aren't really in a position to make that call for all of OpenStack, because that's... I'm going to start from Essex. Okay. You're very much... Are you talking specifically about, like, I guess I'm not... Okay. Sure. I'm specifically, I'm personally pushing for that. Glance is, it's this little thing over here that helps all the other projects, but it's not necessarily a vital code path, and it's not really driving. Any of the other projects in any direction, just because it's so small, and it has its purpose. So I'm... I'm very interested in following what the other projects want to do, specifically using what's in OpenStack Common, just so we're not unnecessarily duplicating things and having to dissolve our own bugs. But no, I don't think there's a lot of code in Glance that we should really push too hard upstream. Sure. Right. Okay. So during Grizzly, we're going to be focusing on boot-from-volumes quite a bit. If you've got an image stored on a volume which is tracked by Glance, which might be... which Glance might be storing in a sender backend, which doesn't exist yet, but it might one day. We don't need to be duplicating that backend storage code. So right now when we talk to Swift, we have to write our own Swift client interaction code. I mean, it's not a lot of code, but if we're duplicating it in multiple places, such as in Nova or in sender, then that's going to be an issue. So in... I guess in preparation for getting the efficient booting, not even boot-from-volumes story ready to go, we need to be allowing Nova to pull images directly out of whatever backend store Glance is using. So if Glance is putting an image up in Swift, we don't need to be streaming that image back through Glance into Nova. And Nova should just be able to go directly to Swift. So I think we're going to be working with possibly Nova, well, definitely Nova, possibly sender to align that backend storage interface, for all of the back-ins that we have. So coming up with a common set of methods that we use for these shared interfaces to talk to something like RBD or to talk to Swift or to S3 or to just some arbitrary HTTP store. And that would just be to put data in and pull data back out using all the same code. So that code might end up in OpenStack Common or it might end up in OpenStack Common back-in stores. So I think we might create a new project that has not really been discussed to that degree yet. I think with that, we might be good. All right, thank you very much, guys. Thank you.