 Let's get it going, OK. All right, so this is Making Glance Tasks Work for You. And just a little bit about me. So my name is Brian Rossmata. That's my Twitter thing, although I never really use it. And on FreeNode, I'm just Rossmata. So that's nice. I'm the Compute Control Plane Product Manager at Rackspace. So what that means is basically I work with the Nova and Glance APIs as they impact users and our other products that use those APIs. Been an OpenStack ATC since Folsom, so I'm pretty proud of that. And with Glance Driver, and I'm happy to be here. Hope you're enjoying the summit so far. There's been a lot of stuff happening. Each year I come here and think it can't possibly get any bigger, and then it does. So it's just kind of amazing. All right, just want to mention a little bit about Glance at Rackspace. Over on the left is the official Glance logo. And on the right, we've exposed Glance v2 API as the cloud images product at Rackspace. Now, there was some discussion at the last summit about the Glance logo. Namely, everybody hates it, but nobody had a good suggestion for what to do. So if you go to launchpad.net for Glance, you could file a question. If you have an idea for a better logo, just file a question saying, how about this? And people may thank you very much. OK. All right, so I have done a bit of an old bait-and-switch here. So the talk was originally planned to be given along with Nikhil Komar, who's the Glance Project technical lead. So you may have seen that in the program earlier. Unfortunately, he can't be here today. So it's just going to be me. So I'm still keeping the title, Making Glance Tasks Work for You. But the focus is not going to be on how to implement your own tasks, because that was the part Nikhil was going to do. So basically, what I want to discuss is just what tasks are, why you should consider using them, and then you can sort of take it from there. And I've got some requests for feedback, because as you'll see, there are some still open questions about using this addition to the API. And I like to find out what actual users think, because we have our own ideas, but those don't always map to what people actually think. All right. So I just want to bring to your attention, there is an ops feedback session for Glance tomorrow. So that's Thursday. But it's 11.50 AM in room 218. So if you're an operator and you have some opinion about Glance or the directional Glance or what's going on, it would be nice to show up and just give us some feedback about different aspects of how operators interact with Glance. So if you can't attend, we do have an etherpad. So Liberty, Glance, ops, feedback. So you could put some comments or questions on there. But we're interested in finding out more about how people actually use Glance, at least from the deployer aspect. And that would be useful to know. All right, so getting to the main point. So making Glance tasks work for you. All right, so I was told that to have an effective presentation, you have to start with a compelling story. So I am going to give you one. I was also told that it's good for your presentation to include some controversy. So I will give you some of that, too. And in fact, here's some to just kick off with. So there's another design session coming up on the direction of the Glance project. Talk a little bit about this, and you'll see how it impacts tasks. But this is today at 2.40 in room 222. Again, if you don't have a full access pass, I'm not sure you can get into that part. So feel free to look at the etherpad or put some comments. Now, let me just say something about the Glance project, so you know what I'm talking about. So the Glance mission statement is that Glance's role in OpenStack is the image service. So that's our official role. Now, I thought this happened a longer time ago. But I look back. July 10th last year, the mission statement was changed, and this got merged into the programs.yaml. So Glance's official mission now 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. So it hasn't changed too much, but there's sort of a generalization of the understanding of what exactly it is Glance catalogs and stores and makes available to users. There's a long discussion. If you're curious, you can go look at the Garret review. I have a lot of comments in there. And interestingly enough, none of my suggestions made it into the final mission statement, but that's OK. So we're all a big community. All right, so some recent developments in Glance. So just now with Kilo, V1 has been changed to supported status, and V2 is now considered current. So the V1 API, if you've worked with it, it really wasn't designed for human consumption. And so V2 is the way of the future. There's going to be work going on in this cycle to get Nova to start using V2. And then we can finally get rid of V1 completely. If you haven't used the V1 API, right. Yeah, so this time we really mean it. Yeah, no, we've gotten, so right, so at the Glance Summit Cycle Summit, we did meet up. We identified a couple of gaps that need to be addressed. So we just need a little bit of work on the Python Glance client. And we have to implement, if you're just in the technical of these, it's the changes since that Nova allows Glance doesn't. So we need to implement that. And I think that pretty much closes all the gaps. So Nova team's excited because they prefer to use, right now they're using a kind of hacked-together custom Glance client. And that's hard to maintain. They'd rather use just the standard Glance client. So I truly believe it's going to happen in Liberty. It's one of our main priorities. So a good question. OK, another recent development in Glance is the addition of the MetaDefs Catalog, which I've got here as Juno, but may have been Icehouse, I'm not sure. But very recently, and what the MetaDefs Catalog allows you to do is store metadata definitions that Glance and other services can use. So it basically allows you, it gives you an endpoint where you can define what type of metadata you want on your images, servers, or whatever takes metadata. Then you can also specify enumerations of values that they can have and things like that. And descriptions of what they are. So it's kind of a useful service. So that was added in the last cycle. In this cycle, we've got an experimental API for the Catalog index service. And so that's why it's the slash v.0.1. What that does is it exposes elastic search for Glance images. So you can do all sorts. Whatever basically elastic search allows you to do, you can now do that, hitting this endpoint to basically the first use case is Horizon can have a better user interface, because we can do a lot more sophisticated searching. And then coming up in Liberty, the artifacts API. And this is, when I said what the mission statement was, you saw such as images for Nova or templates for Heat. And this is the basic idea of the artifacts. It's a generalization of the concept of an image more or less. But it's the idea of you have a digital artifact, you have metadata that describes it, you have the actual payload, and then this stuff will be stored in Glance. So it's kind of a generalization of images. So that's scheduled for Liberty. So that's coming up. So once it's controversial, sort of dirty laundry, because this is controversial in Glance, whether it's becoming too broad, it's doing too much stuff, or whether this is completely appropriate. You can tell by the way I'm framing the issue. I think this is a completely appropriate way for Glance to move. But it has impacts on deployers, because you've got a bigger system. If all you want is Glance to deliver images, you've got this extra stuff. But the extra stuff is kind of cool. So we're discussing today, actually at 2.40, exactly where we see this going and how things are going to show up. So if you have a strong point of view, it would be nice to attend, or just check out the etherpad to see what happened after the discussion. OK. And then I just want to give a plug. So the catalog index service has a particular design session today, also 330. And it's just what's going to happen. It's a really cool demo. If you want to see how you can adapt Elastic Search and be using it in Horizon, you might want to come check this out. It's pretty nice. So that's in room 222. OK. So enough advertisements for Glance. So making Glance tasks work for you. So here's the outline of the talk. So I'm going to tell you a compelling story, as I promised. And we'll talk about Glance tasks. And then I'll give you some more controversy, since we haven't had enough. I'll give you some concluding thoughts, and then question and discussion. So here we go. Here's the compelling story. So end users would like to bring their own images into your cloud. You've probably heard this request. People have expressed this. And you may have different attitudes toward that. But if you've thought about it, there are a few complications to allowing end users to do this. So here's the first one. Some end users don't quite understand what the open stack image service is. So for instance, this actually happened to me when we went to early release for cloud images product at Rackspace. One of the people who applied for early access, I sent him the information about using the API and putting up images. And he sent back and said, I don't need to do this. I wanted to store some JPEGs. So you just never know what you're actually going to get. So you can upload as many JPEGs as you want. But I think, well, it's extremely unlikely that one of them would actually boot. So it would be a pretty bad user experience. But it's a type of thing that people might try. Now, some end users do understand what the open stack image service is all about. And they just happen to not be nice people. So someone might upload malicious images and then share them to other users in the hope of putting back doors in them or doing some kind of nasty stuff. Somebody might upload a malicious image that could try to attack the hypervisor, which is possible and of course unsavory and not something you want to have happen. So that's another complication with allowing people to upload images. Now, another thing is some end users just have really slow connections. And images, our base images at Rackspace are on the order of 7 and 1 half gig probably for Linux, 12 for Windows with SQL Server. And then the average snapshot that people take of an existing server is around 35 gig. So it's a lot of stuff. So people tend to, when they create an image, they like to load it up with stuff. So it's all there. And if they're going to upload it, it's going to take some time to get up there. So upload can take a long time. And if we have a lot of long running, slow uploads, it can really tie up the image service. And as you know, the image service is kind of important for Nova, because Nova uses the image server to get the images so it can actually boot VMs. So it's another complication we need to be aware of. Another thing is how we're going to get information back to users. The image status field isn't very descriptive. And it's because it's made to describe the status of an image, not the status of something that's being uploaded that could or could not be an image. So since the uploaded thing might not actually be a VM image, somebody upload a JPEG or something, do we really want to create an image? So one suggestion is you could just do the normal image create process. It would be queued, queued, queued. Eventually the thing would be there. You'd realize it's not an image, and you kill it. Or a JPEG is probably going to upload just fine. And then it'll be there. And then kind of frustration when you go to boot the thing, fast upload, which is nice, fast download to the hypervisor, and then sadness. So probably we don't want to create an image until we know for sure that the thing we've got is probably an image. So here's the summary of the compelling story. So we want to find a way for end users to upload their custom VM images into an OpenStack cloud in such a way that the uploaded data could be verified as a VM image, at least. Possibly scan for malware or exploits, depending on who you're exposing your cloud to. And we'd like to use an interface that's common across OpenStack installations, because that's what we do. But we also would like it to be customizable to the actual workflow, because different clouds use different hypervisors, different technologies. You may need to do different things to the images. Or depending on if you're exposing it, if it's a private cloud, you can trust most of your people. You might not have to do the same kind of scans you need to do if you're just opening up to the outside world. So we want to be kind of customizable about what you do. And the other advantage of being customizable is that if suddenly you learn about a new exploit, you could put something in without waiting for the six-month cycle for Liberty or whenever Nova starts using V2. And we'd like to provide useful feedback to the end user. So that's a key thing, is that it would be nice if something, because the current image object doesn't have a way to, because it's not designed for that. So you just find out that your image is killed or something if an upload fails. But you don't know why you're sort of up in the air. So we'd like to provide useful feedback. And we could continue this. So end users might want to download images to move them to another cloud for various reasons. You can think of some. And the same problems are going to present themselves. So a provider might want to pre-process the image before you let it out of your cloud. I mean, you may have some kind of license key or something in there that needs to be scrubbed. Who knows? All sorts of possibilities there. Or you might just want to package it some way. Who knows? The end user might have a slow connection again, right? So then you're going to wind up wasting glance connections with this really slow download that's taking forever of a 35 or 50 gig image. So we're dealing with another long-running asynchronous image-related activity. So this would be another candidate for some type of while you can see where I'm going before shadowing task. And end users, so we want to handle that direction too. That's what I was going to say. And end users might want to move images from one isolated cloud region to another. So depending on how your clouds are arranged, you may have different regions that are sealed off from each other. And somehow you'd like to have inter-cloud communication. Or end users might want to move images from one open stack cloud to another open stack cloud. It's another good use case. People like using images, and so they'd like to use them in any cloud they have access to. So that's another long-running, asynchronous image-related activity. So the compelling story is that there seems to be a good use case for having some new way to upload, download, and move images around in glance. And so glance tasks. So with glance tasks, we provide a common API across open stack installations. So it's at slash v2 tasks. And the workflow of the actual operation is customizable per cloud provider. And we don't create an image until there's a high probability of success. So you get the image, do some processing on it, and then you go ahead and store it once you know it's past whatever kind of checks you have. And they provide a way to deliver a meaningful, helpful error message. Of course, this depends on how, since you're doing the workflow yourself for your particular purposes, the goodness of the error message depends on you. But that's OK. But the point is there's a way to do it. And what's kind of nice is the concept of expiration is built into these things. So the task object that you create, once it reaches a final state, gets an expires at tag, and then it will expire, and that's configurable in glance. How long the expiration is. And kind of nicely, it frees the normal upload or download path for trusted users. So for people who are bringing stuff into the cloud, we're not sure what it is. We need to do some kind of processing. They take a separate path from NOVA that NOVA creates a snapshot, just slaps it into glance. We can do that because NOVA is a trusted user. There's not stuff in between NOVA and glance that's going to get in there and mess things up. So that's good. And same thing on the download path, we'd like to just get stuff out of glance as fast as possible to NOVA so you can boot your VMs as quickly as possible. So you can have separate paths for different types of uploads. All right, so with the blueprints, just so you can check this out, so glance tasks were introduced before the specs process. So there aren't actual specs. They're just the old fashioned blueprints. But there's a lot of details. So I just want to point those at you. Yeah, you probably don't want to write these URLs down. But if you basically Google open stack glance tasks, you'll get a bunch of stuff coming up. So the main point was that the original title of the blueprint that was implemented was the new upload workflow, and we called it import. There's a full specification basically describes what the API would look like and what the tasks should look like and how that's going to work for import. There's also a task API proposal. So as we were developing, we started out with import and then realized we needed to have a more general framework to use. So the tasks API basically accounts for that. And then there's a task product package, which is, I did this experiment basically to, I read the, I'm trying to remember who wrote the book, there's books by some guy who worked at Amazon, just you should write press releases and FAQs before you actually start coding. So I figured for this, let's try that out. So if you go to that product package page, you'll see the press release for Glantz tasks. Not too overblown, but it's a press release. And then it's got FAQ just about how you would use tasks. And that gives you a pretty good idea of what tasks are for and how you can use them. All right, so let's take a look at some details. I don't know how well you can see this. This isn't, so in V2 with Glantz, as you may know, all our responses have JSON schemas that describe exactly what you should expect. So tasks are just like that. This is an abbreviated version because I couldn't fit the whole thing on the slide. So I just wanted to point out a few properties that are kind of important for tasks. So we've got expires at, so that's the date time when the resource would be subject to removal. There's an input element and that's just a JSON blob. So I'll return to that point a little bit later. There's a message field and that would be the human readable informative message that will show up when it's appropriate. So usually on failure you want to get some kind of message out to the consumer about what happened. And so the message would be used for that. The result is also a JSON blob. So talk about that in a minute. Then there's a status. So statuses, I'm sorry, so tasks have their own set of statuses, pending, processing, success, and failure. There was a lot of discussion about this, whether they should be customized per task or they should be generic and the decision was it made more sense for them to be generic. So just something to keep in mind there. And then there's the type. So right now the enum for type is just import. So that's the vanilla task that you would get with glance. So that's what the scheme is like. So you can do a task list, so slash v2 tasks would give you the list of tasks that you've created. And you can see it doesn't have all the elements of the actual task object. So it's an abbreviated listing. But you get the expires at the status and the type. And then if you do a task detail list, so slash v2 tasks and then the uuid of the task, which you saw the id in the previous one, you get this. Now I just slammed all the, to fit this on the screen, I slammed all the unimportant stuff up in the top of the task. So you get the usual stuff you'd be interested in, created at, updated at, id, who the owner is. The schema, because we provide that for all our output and then the reference to the task itself. And then we have the expires at time. And then here's an example of using the input field. So it just takes a JSON blob, so it's a JSON object. So it's got two elements, the image properties and then an import from. And then there's a message, which is null right now, because if you look at the status of this guy, it was success and it was an import task. And it's got a result field. Since this was a successful import, what we want to have happen on import is that an image gets created. And so this is reporting the id of the image in glance right now. So that's kind of nice. All right, here's a task detail for, if you look at the status near the bottom, this one's a task that failed. So it's got the same properties. You see the input, I just put in a PDF instead of an actual VHD. And then the message we get is the image cannot be imported. This file is not valid VHD. Now you're wondering, where the heck does VHD come from? And that's because this is being exposed at rack space and we use Xen as our hypervisor. So the image format that we use is VHD and so that's what we've exposed so far. So that's where the customizability comes in because you may have different needs for what type of image you're gonna accept or how you wanna package it or what you wanna do with it. All right, so that's a brief idea of what tasks are. So here are tasks in the big picture. So why do we care and what do they do for us? So tasks address manageability, right? Glance is only gonna store real images. You could imagine somebody, you know, some dope continuing to upload JPEGs, right? And they could be, there's nothing to stop it from regular glance taking that as an upload and they're gonna go fast. But you're gonna fill up your image list with junk. So we prefer to only store real images in glance. So that's a good thing. Keeps glance highly available for Nova. So the upload and download paths are separated and so Nova can use that and then we can control the tasks. Mainly because they're asynchronous. One thing I like about tasks is that you create a task and then you can pull it to see what the status of the task is. So the expectation it creates in the end user is that this is something that's gonna take some time, which it very well may if they're uploading 35 gig. But then you're gonna do some processing, it may take some more time. So what we can do is you can queue up the tasks and process them as resources are available and then that's kinda nice. And then with security, you can screen images for vulnerabilities if you desire. So that's a nice thing too. And then with scalability, I was just saying this. So the task allow you to process images asynchronously. So according to what resources you have available, you can do it. Because some of the scanning you might do might be pretty CPU intensive. So you might not be able to do a lot of that at once. Or depending on how big your cloud is, how many nodes you have to do work, you can do different things. So this really does help with scalability, I think. And then also with usability. So as I was saying before, tasks help manage end user's expectations because it's the kind of thing, well, it doesn't actually say this in our documentation, but you want to start your task and then go get some coffee and then come back and see what happened. So I think they can reduce user frustration because at least if you do upload a JPEG, you're not booting 500 servers and then calling support to find out why none of them booted. So we address that up front. This thing's not an image, boom. If it's not gonna work, we can tell you. And tasks can provide better error feedback. So there is a way for you to get information to end users about what exactly is going on and why the image may or may not have been imported. Okay, I'll talk a little bit more about tasks, but first I just want to say something about the future of Glance Tasks. And so here's another plug for a Glance design session. So there's a session on intercloud image sharing that's happening today at 5.20 at room 222. We've had some initial discussion about this. It should be an interesting session. I think the basic idea is to be able to do moving images from cloud to cloud. So it should be an interesting discussion, but it's obviously a good one for tasks because you don't want to try to boot from another cloud because if you're pulling stuff over the public internet, even if it's a small image, it's gonna take time. So really what I think you want to do is actually get the image over and then once it's in the cloud, you're gonna boot servers in away you go. So it makes for a better user experience. But anyway, so that's something to look forward to. All right, so using Glance Tasks. Okay, so from the operator side, what we've got in Juneau, there was an eventlet-based task executor. And then in Kilo, there's a brand new, brand spanking new, actually, Taskflow-based task executor. So you can use Taskflow to configure the workflow that will process your tasks. This is the part Nikhil was gonna do, so I'm not gonna say much more about this. Now with the baby, I'm not sure if I'm trying to say tasks are great and so easy that even a baby can do it or if I'm, oh, is that Miguel Greenberg's talk yesterday? Maybe I'm saying something about the maturity of the task API, which is the next thing that's coming up. But first, let me just say a few pros about tasks just so we can see before we look at the ugly part. They're flexible, so that's kind of nice. They're customizable, that's nice too, and they provide a common interface across OpenStack installations, which is what we're all about. So that's pretty good. So now let's take a look at the cons for tasks. Well, they're flexible, they're customizable, and they provide a common interface across OpenStack installations. Now, I hadn't really thought about the cons until recently, but basically all our pros are also cons, and that's where I wanna get feedback, but let me sort of set the stage for that. So tasks are flexible, which is nice. So now we have alternative upload paths to get stuff into glance. So in most clouds, you'd have at least three. Administrators are gonna use the classic upload, which is the way your public images get into glance in the first place. So you've got those and then you can, you've got public images to use in your cloud. Then when you use the NOVA image create action, NOVA creates a snapshot, and then that gets stored into glance. So it's another way you can get an image into glance, and then end users could use the import task. So that's nice. So we have three different ways to do things, and that gives you some flexibility. But the problem is, how does a particular user discover what upload path is available to her? So in our cloud, we've exposed glance v2, but we've only exposed the import task to end users. So I know we've only documented the import task, but people are familiar with OpenStack or they Google OpenStack or Glance or something, and they find out you can upload stuff, and then they're getting 403s and they're wondering, why can't I upload, why can't I upload? So the documentation way of explaining to people what your upload path is has not been uniformly successful. So we need to think some more about that, about how the discovery can work, and hopefully you have some thoughts. Tasks are customizable. So if you take a look at the way that a task looks, so this is what the task request body would look like when you create a task. You say what the type is, you provide some input, which would be a JSON blob, and so for this one, the input's got the image properties, so some properties that you take and import from. So that seems simple enough, but if you look, this is from the schema, the way input is described is just the parameters required by the task, a JSON blob. So it's very flexible, so if you wanna accept, who knows where you want to take the input from for an import, you can customize it, but the problem is this doesn't give the end user a lot of ideas about exactly what parameters they need. So there's another thing we've done through documentation about how it's used in our cloud, but that's something to keep in mind. And then the same thing with the result. The result is defined in the schema as a JSON blob, which it can't be anything, but you don't get a good idea of what the structure is. So that's a little bit of the downside of customizability. So I mean, by making it a JSON blob, it's pretty rich as far as what's available to you to expose to your users, but as far as discovery goes for how to actually use the thing, that's a little bit up in the air, right? And it's just the same thing. I mean, the common interface is kind of undetermined with respect to what you actually wanna provide. I mean, it's strictly determined, but you know what I mean. I mean, basically you just got input and you got result. And so that's nice. A task is gonna look like that in any OpenStack installation, but because of the customizability, you don't know what exactly is gonna go in there. And so the stuff that might go in it quite validly for one cloud is not gonna work in another cloud, possibly. So we designed these things to be flexible because right upfront we realized there are gonna be a lot of different things you might wanna do to import an image. On the other hand, this flexibility is kind of killing us. Well, particularly since the API working group got started, because they looked at this thing, it's like, ah. But we want customizability, we need, so anyway, just throwing that out there. And that's a request for feedback. I mean, so let me just set this a little more clearly. So tasks provide a common interface. And I think the compelling story, at least as far as I'm concerned, is that tasks are really necessary. We need something like this. If you're gonna allow users, just regular end users, to put images into your cloud, you don't wanna just let anything in there because of either security reasons or just frustration, right? Because they're not using it right, who knows what kind of stuff they're putting up there. So you really want to only store stuff in glance that's got a very high likelihood that it's gonna boot when you try to boot a server with it. But the problem is we've got the common interface, so we can use that across installations, but the way the interface is designed really hides the differences among cloud providers. So that's not so cool. So that's, you know, and what's the best way to make these differences available to end users, right? So documentation's one way. I don't know how we can do it programmatically. I mean, whether we specify a particular JSON schema, I proposed this at one point and was rejected horrifiedly because JSON schemas are kind of a pain. But that's another thing is you could define a schema, but you'd have to put it at a location where it could be discovered, right? So we get this chicken and egg thing, but at least we'd have it somewhere. But you could have a schema for what the input's gonna look like and what the result's gonna look like for your particular cloud. So it could be discoverable and, you know, provide the correct structure. I don't know how clients would handle that, but that's an idea. And then the other thing is how do users discover what upload facility is available to them? So that's another thing is, you know, you try to upload stuff in the Rackspace cloud as an end user using Glance, you're not allowed to do it, right? But how do you know, right? So we've tried to hide it by just only telling them about using the import task, but that doesn't always work. So I wanna thank you. I'll go back to that slide in a second to get the questions, but I first wanna get the thank you out of the way. And I was also asked by our recruiting people to mention that Rackspace is hiring, so this is kind of crass, but I'm gonna do it anyway. So lots of stuff. Feel free to look through the list. There's bit.ly slash Racker talent. If you're curious or stopped by our booth and talked to many of our many recruiters who would be happy to talk to you. And let me go back. So that's basically it. So the moral of the story is, right, tasks are great. I really like them. They have some problems that are not insurmountable, I believe, but could use some input from actual people about how we wanna solve this thing. Because we have these two conflicting requirements, we definitely want the flexibility because you just know the way clouds work, right? People have different hardware, they have different hypervisors. There's all sorts of stuff underneath. We need to take that into account. And you have different levels of concern depending on who your customers are or who the actual end users are. So I think we definitely want the flexibility, but we need to figure out a better way to make it discoverable so that people can use this. So I'm hoping tasks are here to stay. And it's just a matter of where do we go next. So feel free to chime in and let me know what you think. So I've got a few questions. First of all, who actually defines the tasks? I'm sorry? Who defines the tasks? Well, so the basic task structure, the framework with the schemas and stuff is defined in Glance. And then the operator would define the actual, because you have to have access to the Glance node to put the actuals. So for the eventlet-based thing, you could provide a Python script that would handle your validation or whatever. And then with the taskflow-based one, you have to use taskflow. Okay, so how many tasks do you spin up? And what triggers a task to be spun up? So the task gets spun up by the exposed to the end user. They just post to slash v2 tasks. And if they have permission, they can create a task. Okay, so you could have many running at once. You can, right? Or you can queue them. So it's another flexibility option about exactly how you want to do that, right? So depending on your resources, you can spin them up and process them as fast as you as you want. If you have like a dedicated node for, and you expect a lot of imports, or you can queue them and spread them out because the user can pull the task to get a sense of what the status is and when they can expect it to finish. Okay. Are they able to be triggered on a periodic basis for images? The reason I'm asking is I'm actually writing an image vulnerability scanning service. So we can do that as a service to our users. And one architecture is to have a service, you know, like a daemon, and that you actually provide the images to that service and it then runs all the checks, the validations, it does regression tests. And then it's the only thing in the cloud that's allowed to actually upload to glance. That's one model. The other model is to actually use tasks. But with an image vulnerability scanning service, it's not just when you upload the image, you've got to keep doing it, right? Because, you know, today the image is good, but a month down the track, you know, zero day vulnerability, you've got to say, oh, okay, that's, we need to know and then pull it down. So do you have essentially an asynchronous mechanism in there as well, or are you really tied to an event that is triggered by the user doing something? No, there's nothing like that right now. So, yeah, we could, you could, yeah, there are various possible solutions, but it's not built into this, would be the answer to your question. Okay, I guess then, Lisa, the philosophical, why do it this way with tasks rather than having a front-end service which does, you know, all this kind of processing, you know, vulnerability checking, regression testing, all the policy things that you want to do and restrict access to actually getting into glance just this service. It's a different way of doing it. I'm wondering, why do it this way versus that way? Yeah, I guess, because this is sort of the same, I mean, because we didn't think of that first. I mean, I think this is sort of the same thing. We have the common interfaces that use the images API to do image related stuff is the basic idea. So with the task, you would create the task and then what the task, so the way the task works in our cloud is that we have the user upload whatever it is they say is an image to the object store and then when they create the task we use their credentials to just get the thing and then we start to analyze it. So you could have the task get the thing and send it to your service. Might be a roundabout kind of way, but so I don't have a, that's the best answer I can give is that we thought this was a really good way to do it. Okay, I think we'll come to the session this afternoon. Maybe we can talk more. Yeah, thanks. Okay, so it does seem a little weird. Why is Glance handling importing when you have generally a Swift cluster sitting right next to Glance that would be on the same network? We currently allow customers to import images and we do it to Swift first. It does seem a little weird to add this into Glance. Well, I think what we wanted was to have, so there are a couple ways to do that. So with Glance you can configure it so that all the images are kept as owned by Glance as opposed to in user space. So we have it like that, so we do need to move the images in Swift because you can't really, we don't want to copy them directly because we want to do the pre-processing to make sure that we can check for various things. I'm not sure I'll answer your question though. Oh, well, I guess, so if a task fails, what happens to the image that's stored in Glance? Is it immediately removed? Oh, we'll see, right. So one of the key things about the task is that the image record isn't created until it's passed everything. Sure. So if the image fails validation, then we just delete the thing that we have gotten out of Swift, can leave the thing in the user space so we don't mess with their stuff. And then we don't create an image from it. So it's never available on Glance to be booted from or even to be visible as an image. So if you were going to debug why an image failed, like let's say the customer says, oh no, this is the right image. Have you now removed it from your archives? So you would have to ask them to upload it a second time? Well, it depends on how you arrange the task. Okay. Right, so you could, so and it depends on your resources, right? Whether you wanna keep a lot of these things sitting around and for how long. So I think that the key thing we've done for the first pass at this is just to leave it, since it's in user space, the user is paying for it and they've got it. So if they want to try to re-import it, they could do that or if they want to contact support and say, hey, this looks like an image, what the heck's wrong with it? It can be examined sort of in their space and not in inside, not in the internal part of the cloud. Okay. Thank you. Hey, Brian. Hey, Alex. So this is cool stuff. Well, I've been with Glance for 40 years so I know about that. I wanna know, do we have any plans for bundling some exact tasks with the Glance as it's upstream distribution? I understand that the tasks are intended to be configured by the cloud operators, by the employers. However, there are common use cases which are, well, generic for all the clouds and I'm mostly speaking now about this application catalog initiative announced by Foundation yesterday because for what I know right now, it uses Glance V1 copy from API to import images from application catalog, community application catalog to particular cloud and as far as got you and at many deployments, import from copy from is not available to end users. And given the V1 API is going to be deprecated soon, at some point we'll just, we'll not have this API at all. So I believe that we should have some, as a Glance team, we should develop some generic task which will allow our users to import images from community application catalog and maybe work with a community application catalog team to provide a good way of discovering images in catalog and run the tasks to import them from that. Do we have any plans on this? I personally don't but there's no reason why we can't make that a priority. Yeah, I mean, the tasks are flexible so we could do that kind of thing. I mean, how are we going to bundle tasks on Glance? I don't know about, yeah, I'm not sure what you mean by bundling tasks. Okay. No, that's a good question. I don't know. Right now with it, I'm sorry. We'll have to end this session. We're descending into a conversation that's outside of the microphones. Thank you. Okay. So in V1, we had the import by default. We had it just out of the box. With tasks, we do not have it because we have to write a task. Well, the generic task that comes is basically just a pass-through task. I'm not sure it's actually working. No, I think it doesn't. Pass flow. It was working with the eventlet where it just passed things through so it was sort of just an alternative to upload just out of the box. But in terms of like, you're right. It seems like they're common things that people want to do. It would be good to either put them in Stack Forge or something. Yeah.