20:05:28 #startmeeting glance 20:05:28 Meeting started Thu Mar 6 20:05:28 2014 UTC and is due to finish in 60 minutes. The chair is markwash. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:05:29 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:05:31 The meeting name has been set to 'glance' 20:05:52 o/ 20:05:55 o/ 20:06:04 o/ 20:06:39 o/ 20:07:01 o/ 20:07:12 o/ 20:07:14 so, we are in feature freeze 20:07:25 there are some blueprints and bugs targeted to rc1 20:07:34 #link https://launchpad.net/glance/+milestone/icehouse-rc1 20:08:49 the idea is to get these in before tuesday so that I don't have to beg or explain the case for more time :-) 20:08:55 and so we can cut rc1 sooner 20:09:01 will do mark 20:09:28 also, landing fixes to important bugs is high priority 20:09:49 the sooner we can do that, the sooner we can cut rc1, and the sooner we can get it in some more people's hands 20:10:33 people should feel free to slam me with review requests, i may be able to pick up a bug here and there 20:10:49 I don't have any more immediate items for today's meeting, should we check in on the status of the artifacts work? 20:11:00 that would be nice 20:11:12 markwash: yeah whats the word? 20:12:24 are there any blueprints? 20:12:30 seems we're still in design phases. . but I don't see alex or jbernard around to discuss with 20:12:35 at the end of the meeting I would like to discuss a behavior that I am seeing: I want to confirm that this is not a bug 20:12:42 ameade: there are blueprints but they're still being defined IIRC 20:13:44 https://blueprints.launchpad.net/glance/+spec/artifact-repository-api 20:13:58 also, https://wiki.openstack.org/wiki/Glance-artifacts-api-faq 20:14:14 rosmaita: ty sir 20:14:22 np 20:14:48 Mark do we have randall working on the heat side? 20:14:48 seems there's not much new information however 20:15:07 arnaud__: I haven't heard from him in a bit, but I think he's still interested 20:15:19 okay 20:16:01 arnaud__: you and I had some good conversation about directions the artifacts structures could go 20:16:18 iirc, we had hoped to share that info with alex, have you had a chance to follow up with him? 20:16:34 Iwas busy on some other stuff this week 20:16:41 its been one of those weeks for me as well 20:16:45 I have our conversation 20:16:55 I will talk to him before next meeting 20:17:13 all right, looks like we don't have much more in terms of status updates 20:17:23 markwash: do you know if anyone is working on the cinder driver? 20:17:33 ameade: not that I'm aware of 20:17:45 it's basically just a stub atm 20:17:56 I know zhiyan was interested in it 20:17:58 ameade: cinder store driver? what do you think? 20:18:23 zhiyan: i'd like it to get finished :) 20:18:26 ameade: IMO the issue for it is Brick 20:19:09 there are a few other issues as well that have come up 20:19:20 zhiyan: can you summarize brick and why it's a blocker? i know brick is part of cinder 20:19:28 1 is that we don't have support for multi-format images, so its a bit hard to use cinder drivers for anything other than raw images 20:19:34 ameade: without it we/Glance (and other project who outside Cinder) can't access volumes 20:19:47 ah i see 20:20:06 2) is that its not clear that the deployment pattern for glance and cinder would allow glance to own the cinder volumes, so they could get deleted, leaving the location a dangling reference 20:20:18 that makes sense too 20:20:26 i really dont want dead code sitting there then 20:20:27 right, currently it is *part of* cinder, but a standard lib 20:21:01 what i really wanna see is the glance.store code turn into a transfer service 20:21:09 +1 20:21:15 but it gets weird i think when you mix block and object storage 20:21:44 there was a really interesting idea put forward by lifeless at the triple O summit that could help us kick off the transfer service 20:21:48 ameade: is is not a dead code, via image_handler within nova, we can consume that volume acted image as we needed (since nova side has volume accessing code) 20:22:19 \o/ 20:22:27 I captured it in a blueprint (which links to lifeless ideas in an etherpad) https://blueprints.launchpad.net/glance/+spec/multicast-image-transfer 20:24:03 hmm ok, i'll try to digest this stuff and form some opinions 20:24:26 the whole idea of the transfer service isn't entirely clear in my mind 20:24:39 that seems to overlap a bit with the bittorrent protocol within the xfer service 20:24:43 so a usecase like that was interesting in that it seemed like it *could* help clarify some things 20:24:54 nikhil___: yeah, I think there is a lot of similarity 20:24:59 we have a few use cases markwash 20:25:03 imo multicast still is a thing for "copy", my idea is zero-copy 20:25:05 I kind of think they would be side-by-side protocols 20:25:15 would like to provide feedback 20:25:18 markwash: yeah 20:25:34 zhiyan: ? 20:25:47 zhiyan: you're right, but I think there are requirements for good copy support as well 20:26:12 anyway, I'd like to avoid ratholing too far down at this point :-) 20:26:13 yeah i think both are important though 20:26:43 so, arnaud__ you had a quick bug you wanted some discussion about? 20:26:45 markwash: ok, but tbh prevent copy is my finial target. 20:27:18 zhiyan: you mean related to multi-attach volumes? 20:27:18 markwash: yes 20:27:29 zhiyan: are you the one working on that in cinder? 20:27:45 ameade: they are different topic, iiuc. 20:27:50 +1 20:27:51 yes, i am 20:28:21 kk, sorry we can move on now 20:28:43 ok :) so here is the story 20:30:39 in nova, I create an image - upload content of size 0 (StringIO('')) - then get the location for the image - then replace the bits at this location with something much bigger than 0 - then update the image with the new size of this big thing 20:30:43 this works 20:30:55 after that I am able to boot the new image from nova 20:31:15 I feel like something is messed up :) (i.e. the checksum) 20:31:24 is it clear? 20:31:32 hmm 20:32:11 arnaud__: ah yeah, like nova isn't checking the checksum? 20:32:29 arnaud__: did you check the checksum value after you update the image? 20:32:35 Hi. Sorry I am late. 20:32:58 may be we need to add verificaion of the etag (checksum returned from store) with the one store in glance? 20:33:09 arnaud__: so you just update the size directly in glance? 20:33:13 yes 20:33:23 markwash: yes, I just update the size 20:33:28 and modify what is at the location 20:33:47 this is cool for me, but that make works what I want to do 20:34:02 but I want to make this isn't working because of a bug 20:34:03 :) 20:34:19 zhiyan: the checksum of the image is populated after update 20:34:40 ok, if so seems like it's a bug in nova but glance 20:35:20 so this is OK behavior to have Nova replacing a location behind Glance's back? and update the size? 20:35:30 it does seem like there is a bug in glance somewhere if you can update the size or the checksum, or have the download work with an invalid checksum 20:35:51 ok 20:36:04 ok, cool. 20:36:10 arnaud__: humm, i think this use case is too hack to glance 20:36:18 markwash: are you saying that checksum, size, and location should be linked so you must update all at the same time? 20:36:19 this is sort of hilarious, asking you to file a bug for a functionality you really want to use :-) 20:36:40 zhiyan: I agree with you, but at this point I need to get the Glance location and size the location is provided after content is uploaded 20:37:28 arnaud__: why you need replace image bits via location? 20:37:44 markwash: I don't want to file a bug, but I want to be sure that in the future no one else file a bug and change the behavior 20:38:07 to move the bits of the snapshot instead of uploading them 20:38:15 zhiyan: upload behind the scenes 20:38:20 yep nikhil___ 20:38:28 ;) 20:39:17 the core problem here is that clients don't know where to put data if they don't want to send it through glance 20:39:23 yes 20:39:42 arnaud__: I think its pretty likely that we will file a bug and "fix" the behavior you're seeing :-) 20:40:13 ok... 20:40:14 :) 20:40:55 feel even more need for a xfer service which is kinda glance aware 20:40:56 I would like to see a location provided before having to upload the content 20:41:16 +1 nikhil___ 20:41:21 there was a suggestion at some point for glance to provide the "upload location" that clients could use 20:41:34 arnaud__: iiuc, currently we support it 20:41:46 zhiyan: could you develop? 20:41:57 I am not seeing the direct_url just by doing image_create afaik 20:42:06 isn't this what breaking out glance.store is for? 20:42:16 not exactly 20:42:17 arnaud__: create a image, it under "queued" status, and you an prepare the image bits on nova side, then use PATCH api to add that location to glance 20:42:26 arnaud__: then the image will turn to "active" 20:42:36 ameade: sort of, but its difficult to imagine all of the clients getting the right credentials for talking directly to the store 20:42:43 zhiyan: the thing is that I need to have this location 20:42:44 heh yeah 20:42:47 before 20:42:54 so this is what a third party transfer service would do 20:43:12 you don't know the format that is used by glance to store the image 20:43:25 the file name, the folder or whatever info contained in the URL of the image 20:44:07 do you get my point zhiyan? 20:44:14 so, can someone file a bug documenting this behavior? 20:44:24 I will markwash 20:44:26 arnaud__: yes, but i'm thinking if this use case on nova side is make sense 20:44:32 okay, cool 20:44:46 if there aren't any other items atm, I have something I need to run off to 20:45:56 thank you guys 20:46:16 bye everyone 20:46:22 thanks! 20:46:25 #endmeeting