| *** zhurong has joined #openstack-glance | 00:33 | |
| *** nicolasbock has joined #openstack-glance | 01:10 | |
| *** zhurong has quit IRC | 01:58 | |
| *** zhurong has joined #openstack-glance | 02:10 | |
| *** nicolasbock has quit IRC | 02:53 | |
| *** catintheroof has joined #openstack-glance | 03:43 | |
| *** catintheroof has quit IRC | 03:51 | |
| *** markvoelker has joined #openstack-glance | 04:05 | |
| *** udesale has joined #openstack-glance | 04:20 | |
| *** Dinesh_Bhor has joined #openstack-glance | 04:22 | |
| *** adisky_ has joined #openstack-glance | 04:22 | |
| *** dharinic has quit IRC | 04:54 | |
| *** ratailor has joined #openstack-glance | 05:02 | |
| *** rcernin has joined #openstack-glance | 05:25 | |
| *** mosulica has joined #openstack-glance | 05:30 | |
| *** groen692 has joined #openstack-glance | 05:43 | |
| *** gcb has joined #openstack-glance | 05:57 | |
| *** pcaruana has joined #openstack-glance | 06:01 | |
| *** mosulica has quit IRC | 06:02 | |
| *** hieulq has quit IRC | 06:07 | |
| *** ratailor is now known as Guest5432 | 06:14 | |
| *** mosulica has joined #openstack-glance | 06:24 | |
| *** namnh has joined #openstack-glance | 06:43 | |
| *** tesseract has joined #openstack-glance | 06:48 | |
| *** jaosorior has joined #openstack-glance | 06:49 | |
| *** mosulica has quit IRC | 06:54 | |
| *** mosulica has joined #openstack-glance | 06:57 | |
| *** markvoelker has quit IRC | 07:12 | |
| *** markvoelker has joined #openstack-glance | 07:15 | |
| *** ezoszed has joined #openstack-glance | 07:20 | |
| *** daidv has joined #openstack-glance | 07:35 | |
| *** mosulica has quit IRC | 07:36 | |
| *** gcb has quit IRC | 07:46 | |
| *** mosulica has joined #openstack-glance | 07:48 | |
| *** zzzeek has quit IRC | 08:00 | |
| *** zzzeek has joined #openstack-glance | 08:01 | |
| *** hieulq has joined #openstack-glance | 08:06 | |
| *** gcb has joined #openstack-glance | 08:12 | |
| *** knangia has quit IRC | 09:01 | |
| *** haplo37 has quit IRC | 09:44 | |
| *** dalgaaf has quit IRC | 09:46 | |
| *** tovin07 has left #openstack-glance | 09:47 | |
| *** dalgaaf has joined #openstack-glance | 09:48 | |
| *** haplo37 has joined #openstack-glance | 09:53 | |
| *** aarefiev_afk is now known as aarefiev | 09:59 | |
| openstackgerrit | XieYingYun proposed openstack/glance master: Add Apache License Content in index.rst https://review.openstack.org/455203 | 10:08 |
|---|---|---|
| *** gcb has quit IRC | 10:16 | |
| *** hieulq has quit IRC | 10:19 | |
| *** nicolasbock has joined #openstack-glance | 10:22 | |
| *** hieulq has joined #openstack-glance | 10:33 | |
| *** daidv has quit IRC | 10:33 | |
| *** namnh has quit IRC | 10:37 | |
| *** udesale has quit IRC | 10:37 | |
| *** jamielennox|away is now known as jamielennox | 11:25 | |
| *** aavraham has joined #openstack-glance | 11:25 | |
| *** belmoreira has joined #openstack-glance | 11:36 | |
| *** smatzek has joined #openstack-glance | 11:48 | |
| *** mtanino has joined #openstack-glance | 11:51 | |
| *** markvoelker has quit IRC | 12:10 | |
| *** markvoelker has joined #openstack-glance | 12:25 | |
| *** zhurong has quit IRC | 12:26 | |
| *** aavraham has quit IRC | 12:33 | |
| *** catintheroof has joined #openstack-glance | 12:36 | |
| *** gcb has joined #openstack-glance | 12:50 | |
| *** Guest5432 has quit IRC | 12:53 | |
| *** jdillaman has joined #openstack-glance | 13:07 | |
| *** mtanino has quit IRC | 13:28 | |
| *** chlong has joined #openstack-glance | 13:31 | |
| openstackgerrit | Hao Li proposed openstack/glance master: Fix some bugs in db/sqlalchemy https://review.openstack.org/455322 | 13:32 |
| *** openstackgerrit has quit IRC | 13:33 | |
| *** smatzek has quit IRC | 13:35 | |
| *** wuyanjun has quit IRC | 13:35 | |
| *** wuyanjun has joined #openstack-glance | 13:35 | |
| *** openstackgerrit has joined #openstack-glance | 13:47 | |
| openstackgerrit | Jesse J. Cook proposed openstack/glance-specs master: Eliminate Redundant Downloads of Uncached Images https://review.openstack.org/206120 | 13:47 |
| *** Elaine_wu has joined #openstack-glance | 13:50 | |
| *** wuyanjun has quit IRC | 13:52 | |
| *** smatzek has joined #openstack-glance | 13:59 | |
| *** hongbin has joined #openstack-glance | 14:01 | |
| *** adisky_ has quit IRC | 14:09 | |
| *** mtanino has joined #openstack-glance | 14:16 | |
| *** lucasxu has joined #openstack-glance | 14:27 | |
| jcook | stevelle rosmaita multihash updated and commented. | 14:27 |
| jcook | also LMK if there is anything you need me to review | 14:27 |
| *** dillaman has joined #openstack-glance | 14:45 | |
| *** belmoreira has quit IRC | 14:46 | |
| openstackgerrit | Hemanth Makkapati proposed openstack/glance master: Dev Docs for Writing E-M-C Migrations https://review.openstack.org/443741 | 15:02 |
| *** rcernin has quit IRC | 15:03 | |
| *** TravT_ has quit IRC | 15:06 | |
| *** udesale has joined #openstack-glance | 15:09 | |
| *** TravT has joined #openstack-glance | 15:09 | |
| *** dharinic has joined #openstack-glance | 15:10 | |
| *** dosaboy has quit IRC | 15:10 | |
| *** TravT has quit IRC | 15:12 | |
| *** TravT has joined #openstack-glance | 15:13 | |
| *** mosulica has quit IRC | 15:16 | |
| *** udesale has quit IRC | 15:18 | |
| *** ezoszed has quit IRC | 15:22 | |
| *** dosaboy has joined #openstack-glance | 15:23 | |
| *** aarefiev is now known as aarefiev_afk | 15:27 | |
| *** cmart has joined #openstack-glance | 15:53 | |
| *** lucasxu has quit IRC | 16:00 | |
| *** groen692 has quit IRC | 16:06 | |
| *** jokke__ has joined #openstack-glance | 16:11 | |
| *** jokke__ has quit IRC | 16:11 | |
| *** gyee has joined #openstack-glance | 16:14 | |
| jokke_ | specs reviews done | 16:17 |
| jokke_ | time to fix those darn iir patches next | 16:17 |
| *** knangia has joined #openstack-glance | 16:29 | |
| *** jaosorior is now known as jaosorior_away | 16:51 | |
| *** tesseract has quit IRC | 16:52 | |
| *** lucasxu has joined #openstack-glance | 17:02 | |
| dharinic | rosmaita: stevelle: hemanthm: I wanted opinion on the possible ways to handle a partial download request coming for an image stored in a non-random-read supported store. | 17:09 |
| dharinic | Currently it is a 206 and a full image. | 17:09 |
| openstackgerrit | Merged openstack/glance master: Dev Docs for Writing E-M-C Migrations https://review.openstack.org/443741 | 17:12 |
| openstackgerrit | Merged openstack/glance-specs master: Update spec template for db migrations https://review.openstack.org/448107 | 17:20 |
| hemanthm | dharinic: 416? | 17:22 |
| hemanthm | that's one possibility | 17:22 |
| hemanthm | that request is valid in this case though, so it's not necessarily a client-side error | 17:23 |
| hemanthm | Hence 4xx doesn't make sense. That's one argument | 17:23 |
| dharinic | yeah. A 416 means the request range is not satisfiable | 17:24 |
| dharinic | Yeah. Its arguable.. | 17:24 |
| hemanthm | I said 416 because we are throwing that for multi-range requests | 17:24 |
| hemanthm | but there at least we can document that multi-ranges are not supported. At which point it is a client-side error | 17:25 |
| rosmaita | dharinic: i think 206 + full image is ok, but you have to have a Content-Range response indicating the entire thing | 17:25 |
| rosmaita | my reading of the standard is that 206 response must have a content-range header | 17:26 |
| stevelle | 206 reads as the wrong choice, but I'm not really engaged | 17:26 |
| dharinic | yes. Currently for a non-random-read store, the content-range is set. But wrongly. i.e., the actual bits requested.. though we return full image | 17:26 |
| timburke | fwiw, it seems like the spec lets you 200 and return the whole thing | 17:27 |
| stevelle | ^ | 17:27 |
| rosmaita | yeah, so my problem isn't with the 206 or the full image, it's that the content range is incorrect in the response | 17:27 |
| hemanthm | why not 200 + full image? | 17:27 |
| dharinic | I was thinking of 200 + full image too. | 17:28 |
| hemanthm | That's a clear indication that we ignore the range request. | 17:28 |
| stevelle | ^ w/o content-range | 17:28 |
| dharinic | Yes. But I kind of like rosmaita's suggestion too. 206 + full image (as it is now). But with the correct content-range response | 17:28 |
| dharinic | timburke: Can you please tell me which spec? | 17:29 |
| stevelle | 206 looks wrong to me | 17:31 |
| stevelle | if given full img | 17:31 |
| hemanthm | +1 | 17:31 |
| dharinic | The 206 (Partial Content) status code indicates that the server is | 17:31 |
| dharinic | successfully fulfilling a range request for the target resource by | 17:31 |
| dharinic | transferring one or more parts of the selected representation that | 17:31 |
| dharinic | correspond to the satisfiable ranges found in the request's Range | 17:32 |
| dharinic | header field (Section 3.1). | 17:32 |
| dharinic | Yeah, 206 is indeed not right | 17:32 |
| dharinic | as per rfc7233 | 17:32 |
| stevelle | unless the range request results in the full image being requested, it isn't successfully fulfilling a range request | 17:33 |
| dharinic | Yes. | 17:33 |
| stevelle | if the range happens to cover the full image, don't try to notice and return 200 though | 17:33 |
| hemanthm | I feel response code is a much stronger indication than content-range because we know virtually all clients read the response code | 17:33 |
| stevelle | content-range should only appear on a 206, was my reading | 17:34 |
| stevelle | never any other time | 17:34 |
| rosmaita | that's what my reading is too | 17:34 |
| hemanthm | stevelle: yes, I was referring to 2-6 + full image + content range header | 17:34 |
| dharinic | Yes stevelle. Thats right. | 17:34 |
| rosmaita | ok, i agree about the 200 (with no content-range) | 17:34 |
| hemanthm | *206 | 17:34 |
| rosmaita | here's from the section about an alternative to 416: | 17:35 |
| rosmaita | Note: Because servers are free to ignore Range, many implementations will simply respond with the entire selected representation in a 200 (OK) response. That is partly because most clients are prepared to receive a 200 (OK) to complete the task (albeit less efficiently) and partly because clients might not stop making an invalid partial request until they have | 17:35 |
| rosmaita | received acomplete representation. Thusv, clients cannot depend on receiving a 416 (Range Not Satisfiable) response even when it is most appropriate. | 17:35 |
| timburke | dharinic: https://tools.ietf.org/html/rfc7233#section-3.1 -- "A server MAY ignore the Range header field." | 17:35 |
| rosmaita | so clients have to expect a 200 could be a possibility | 17:35 |
| timburke | if we ignore it, then there should be a 200, no content-range | 17:35 |
| hemanthm | yep | 17:35 |
| stevelle | ok, I think we all agree now | 17:35 |
| rosmaita | timburke: agreed | 17:36 |
| dharinic | yes. | 17:36 |
| dharinic | So if a range request for a full image download in a non-random-read store comes, we still ignore it, send full image + 200 + no content-range right? | 17:36 |
| hemanthm | +1 | 17:37 |
| stevelle | this is different from the multi-range request, where we decided not to return 200 + full img. instead we choose 400. I'm still mostly ok with that but this is what I wanted there too. | 17:37 |
| dharinic | although that could possible be returned a 206 cos the request is actually satisfied..? | 17:37 |
| stevelle | no, if you don't return all the data asked for you didn't satisfy it | 17:38 |
| stevelle | 1 of 2 blocks of bits isn't satisfying | 17:38 |
| stevelle | the full image includes all requested blocks though :) | 17:38 |
| dharinic | a range request like "bytes=0-" will be served with a full image anyway stevelle | 17:38 |
| dharinic | though it was a non-random-read store | 17:38 |
| hemanthm | that's a full range :) | 17:38 |
| dharinic | yep. | 17:38 |
| stevelle | dharinic: as I suggested before, "if the range happens to cover the full image, don't try to notice and return 200 though" | 17:39 |
| dharinic | but currently we return 2-6 for it cos technically we are satifying the range though it is for a full image | 17:39 |
| stevelle | agreed | 17:39 |
| hemanthm | I agree with stevelle. | 17:39 |
| stevelle | this is where sigmavirus would remind us that RFCs are terrible. | 17:40 |
| dharinic | I did not understand the "and" there stevelle. did it mean do not try to notice it, send 200 or did it mean do not try to notice it, do not send 200. | 17:40 |
| hemanthm | the rfc has no mention of the server evaluating the ranges anyway | 17:40 |
| dharinic | sorry about that ^ | 17:40 |
| hemanthm | dharinic: he's saying don't evaluate the ranges to return 200 for requests that request full range | 17:41 |
| dharinic | okay cool. | 17:41 |
| stevelle | that | 17:41 |
| stevelle | 206, content-range, the range of data that happens to represent the full img | 17:42 |
| dharinic | okay great. thanks for clarifying stevelle | 17:43 |
| stevelle | next cycle, we play with If-Range headers | 17:43 |
| dharinic | sure. :) | 17:43 |
| hemanthm | extending this topic further: what happens when I try the same partial image download again? | 17:44 |
| hemanthm | the first time I get 200 + full image | 17:44 |
| hemanthm | at this point, the image is cached | 17:44 |
| hemanthm | next time for the same request I get 206 + partial image + content-range header | 17:44 |
| hemanthm | because we server the content from cache (assuming dharinic's spec is implemented) | 17:45 |
| stevelle | I haven't given a + on that lite spec yet :P | 17:45 |
| hemanthm | *serve | 17:45 |
| stevelle | don't confuse me | 17:45 |
| stevelle | I had to check to see if it merged there | 17:46 |
| hemanthm | sorry | 17:46 |
| stevelle | :D | 17:46 |
| hemanthm | I should have established the context | 17:46 |
| hemanthm | I just downgraded my vote based on that concern | 17:46 |
| stevelle | So, before we do that work maybe we add support for proper range requests to glance client? | 17:47 |
| stevelle | that way nova can get the benefit | 17:48 |
| dharinic | hemanthm: we were discussing about glance root app | 17:48 |
| dharinic | if the request came to glance root app | 17:48 |
| hemanthm | dharinic: yes | 17:48 |
| hemanthm | I'm discussing your lite-spec | 17:48 |
| dharinic | okayy | 17:48 |
| * hemanthm should learn to set the context | 17:49 | |
| dharinic | So the concern is that once one would get 200 + full image but later get 206 + partial image? | 17:49 |
| rosmaita | hemanthm: what's your concern about that? | 17:49 |
| dharinic | I brought up this topic after seeing the comment on the lite-spec :D | 17:50 |
| hemanthm | rosmaita: what dharinic said above | 17:50 |
| hemanthm | dharinic: yes | 17:50 |
| rosmaita | hemanthm: how far above? | 17:50 |
| hemanthm | rosmaita: once one would get 200 + full image but later get 206 + partial image | 17:50 |
| dharinic | Hmmm. is there much we can do there? The store does not support random-read. so the first request simply cant get a 206 and partial image. But once it is available, we serve what we have to | 17:50 |
| dharinic | I understand it might be wierd for the user to see that the same request got different responses at 2 different times | 17:51 |
| dharinic | but I am not sure we should keep giving him the full image once it is cached and we can actually satisfy his exact request | 17:52 |
| rosmaita | that's why i suggested always serving range requests from the cache | 17:52 |
| dharinic | always? | 17:52 |
| rosmaita | yes | 17:52 |
| rosmaita | in order to support range requests, you must have the cache enabled | 17:53 |
| rosmaita | otherwise, no range request support | 17:53 |
| rosmaita | that way, we support all back ends in the same way | 17:53 |
| hemanthm | why don't we remove range request support from cache instead? | 17:53 |
| hemanthm | let the root app serve all range requests | 17:53 |
| rosmaita | because it can't for all backends | 17:54 |
| dharinic | cache can for all backends | 17:54 |
| hemanthm | cache is an optional middleware | 17:54 |
| rosmaita | yes, so no cache -> no range requests | 17:54 |
| dharinic | yeah. We cant expect everyone to have cache to use partial downloads i guess | 17:55 |
| dharinic | but i understand rosmaita's point | 17:55 |
| rosmaita | if you dont' need the cache, then you probably don't need partial downloads | 17:55 |
| dharinic | Or we go with the lite-spec. First req will get 200 + full image. but second will get 206 + partial image. | 17:55 |
| hemanthm | I see that but it's weird to see that connection | 17:55 |
| hemanthm | dharinic: that's the sign of an unstable API | 17:56 |
| hemanthm | or some weird statefulness between requests | 17:56 |
| dharinic | Hmmmm. Agreed. | 17:57 |
| dharinic | If eliminate redundant downloads merged, this issue would be solved probably. | 17:58 |
| dharinic | even if we do "use cache if u want range requests", we will still depend on the image to first be cached | 18:00 |
| hemanthm | yes | 18:00 |
| hemanthm | or we expect cache middleware to first cache the image | 18:00 |
| dharinic | or like hemanthm said, never care about range requests in cache. Always go to root app. But that way, even if it is there in cache..we are uneccsarily going to store | 18:01 |
| dharinic | yeah thats a part of the eliminate redundant download spec proposal hemanthm | 18:01 |
| hemanthm | I see, I didn't review that yet. | 18:01 |
| dharinic | Hmmm. would u like to review it and then we can rethink about this maybe? | 18:02 |
| hemanthm | Are we putting too much in the middleware? | 18:02 |
| dharinic | Maybe | 18:02 |
| dharinic | https://review.openstack.org/#/c/206120/ | 18:02 |
| dharinic | For now I will hold on to the lite-spec | 18:03 |
| rosmaita | i think it makes sense to support range requests out of the cache ... if you make one range request, there is a high likelihood you are going to make another | 18:03 |
| rosmaita | i mean, no one *really* wants just a few bytes of an image | 18:03 |
| rosmaita | you really need the whole thing | 18:04 |
| dharinic | Hmmm | 18:05 |
| * hemanthm is wondering if we should deal with this when the need arises | 18:06 | |
| stevelle | I don't agree with the idea that we have a need to treat all back ends the same way, or that we have to treat serial requests for the same image the same way, FWIW | 18:07 |
| stevelle | we should document clearly whatever comes about though for users, and then explain again in admin guide the implications of each store and of using cache | 18:08 |
| stevelle | e.g. If you request a partial image using Range, you may get the segment you asked for with a 206, content-range or you may get the full image with a 200, depending on how your cloud is configured. | 18:09 |
| rosmaita | good point, just explicitly say you must be prepared for both, leaves us room to improve things later | 18:10 |
| stevelle | and the only case I can see for range requests really being used is in the case of an interrupted download you want to resume | 18:10 |
| *** dharinic has quit IRC | 18:10 | |
| rosmaita | or if you know you have a unreliable network | 18:11 |
| stevelle | I see that as the same case | 18:11 |
| stevelle | perhaps there is something I am missing | 18:12 |
| rosmaita | not really, if you know you have a crappy network, you may never try to get the whole image, just have a client that grabs 5 meg at a time | 18:12 |
| rosmaita | so you only make range requests | 18:12 |
| stevelle | I would assume you lay down bits as you go, when it dies you resume from the failure point wherever that was. | 18:12 |
| stevelle | but the first request starts from 0 and doesn't need a Range heaer | 18:13 |
| stevelle | good enough, though | 18:13 |
| rosmaita | well, the other thing is you can make parallel requests for 5 meg segments and write them to the correct place in the file you're constructing | 18:14 |
| stevelle | there is a better protocol for that, but we've discussed it before, no need to retread that | 18:15 |
| stevelle | In time I imagine that use case might appear if we get some solid behavior on Range | 18:15 |
| hemanthm | stevelle: aren't you supposed to be taking sick day? :) | 18:17 |
| stevelle | yes | 18:17 |
| *** cmart has quit IRC | 18:33 | |
| *** cmart has joined #openstack-glance | 18:33 | |
| *** dharinic has joined #openstack-glance | 18:50 | |
| dharinic | rosmaita: Out of the cache as in, only out of the cache? | 18:52 |
| rosmaita | dharinic: sorry, lost the context for that | 19:00 |
| dharinic | No problem rosmaita. W.r.t to your previous message, I was asking if you were suggesting that we support range requests only from cache and never from root app. | 19:05 |
| *** edmondsw_ has joined #openstack-glance | 19:15 | |
| *** edmondsw_ has quit IRC | 19:15 | |
| *** cmart has quit IRC | 19:23 | |
| *** TravT has quit IRC | 19:27 | |
| rosmaita | dharinic: sorry, was in a meeting | 19:38 |
| rosmaita | dharinic: yes, that was my thought, here is my reasoning | 19:38 |
| rosmaita | if we're going to support range requests at all from the cache, then we are not limited to supporting them only for specific backends | 19:39 |
| rosmaita | but, we are giving a 400 for those backends that don't support range requests | 19:39 |
| rosmaita | so, we could move all range requests into the cache | 19:39 |
| rosmaita | then, it doesn't matter any more what backend you are using, you can still have range requests satisfied | 19:40 |
| rosmaita | but ... the cache is optional middleware | 19:40 |
| rosmaita | so, maybe the thing to do is: only support range requests from the cache | 19:40 |
| rosmaita | but, is that too restrictive? maybe, but i think that the clouds where people "need" range requests probably overlap with clouds that use caching | 19:41 |
| rosmaita | because a really small cloud on a really small network, you won't have any problems downloading an entire image each time | 19:41 |
| *** cmart has joined #openstack-glance | 19:42 | |
| rosmaita | anyway, that's my thinking | 19:43 |
| rosmaita | not 100% sure it is a good idea, but not convinced it's a bad idea either | 19:43 |
| dharinic | I understand your point rosmaita. While it makes sense, just as you point out, it might seem like restricting a feature only to cache. Other option is to leave it as is now..but fix how we handle range reqs for non random-read stores (for which we all agreed upon something). | 19:45 |
| dharinic | Will wait to see what other have to say | 19:45 |
| dharinic | and proceed accordingly | 19:45 |
| hemanthm | I don't have a strong opinion yet. | 19:54 |
| hemanthm | Making partial image downloads depend on cache seems like an implementation constraint to me. | 19:55 |
| hemanthm | If I want cache, I get partial image downloads too. | 19:55 |
| hemanthm | If I just want to partial image downloads, I must enable cache. | 19:55 |
| hemanthm | We can add config to isolate them. | 19:57 |
| hemanthm | But, like I said, we seem to be placing an artificial constraint. | 19:57 |
| dharinic | To still support partial reqs for certain stores alone without cache? | 19:58 |
| hemanthm | If I have to take a side now, I'll probably go with 206 first and then 200 | 19:59 |
| hemanthm | but I haven't made up my mind yet | 19:59 |
| dharinic | I am not fixed on one solution now too. Need to think more and decide what is best | 19:59 |
| hemanthm | oops, 200 first and then 206 | 20:00 |
| hemanthm | yeah, let's think a bit more. | 20:00 |
| dharinic | okay | 20:00 |
| rosmaita | that's why we have specs! this is a good discussion | 20:16 |
| *** knangia has quit IRC | 20:31 | |
| *** smatzek has quit IRC | 20:33 | |
| *** cmart has quit IRC | 20:34 | |
| dharinic | rosmaita: hemanthm: This was the patch to enable experimental multi node grenade for glance and it was merged. https://review.openstack.org/#/c/414326/ | 20:37 |
| dharinic | However https://review.openstack.org/#/c/426428/ has to actually merge to make it "multi-node". Cos glance services were not enabled on the sub (second) node by default. | 20:38 |
| rosmaita | yeah, what's changed since february is that now only v2 runs in devstack by default, so i think this should be ok now | 20:41 |
| dharinic | We need to merge the second one, to have g-api on the second node | 20:42 |
| dharinic | for the gate job | 20:42 |
| dharinic | s/we/they :D | 20:42 |
| rosmaita | well, it's a non-voting job, so what the heck | 20:42 |
| dharinic | Was just discussing w.r.t rolling upgrades priority | 20:43 |
| rosmaita | ok, i +1d it, will follow up tomorrow if an infra core doesn't see it | 20:44 |
| *** cmart has joined #openstack-glance | 20:51 | |
| *** pcaruana has quit IRC | 21:15 | |
| *** catintheroof has quit IRC | 21:25 | |
| *** cmart has quit IRC | 21:25 | |
| *** cmart has joined #openstack-glance | 21:28 | |
| hemanthm | dharinic: will look at it | 21:31 |
| dharinic | Thanks hemanthm | 21:31 |
| *** lucasxu has quit IRC | 21:40 | |
| *** Sukhdev has joined #openstack-glance | 21:41 | |
| openstackgerrit | Cyril Roelandt proposed openstack/glance_store master: Implement update_capabilities for the filesystem store https://review.openstack.org/455454 | 21:42 |
| *** smatzek has joined #openstack-glance | 22:02 | |
| *** smatzek has quit IRC | 22:06 | |
| *** hoonetorg has quit IRC | 22:16 | |
| *** Elaine_wu has quit IRC | 22:23 | |
| *** Elaine_wu has joined #openstack-glance | 22:23 | |
| *** knangia has joined #openstack-glance | 22:24 | |
| *** catintheroof has joined #openstack-glance | 22:27 | |
| *** hoonetorg has joined #openstack-glance | 22:39 | |
| *** dharinic has quit IRC | 23:15 | |
| *** dharinic has joined #openstack-glance | 23:40 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!