Open Stack

On 06/08/2015 12:30 PM, Robert Collins wrote:
> On 9 June 2015 at 03:50, Chris Friesen <chris.friesen at windriver.com> wrote:
>> On 06/07/2015 04:22 PM, Robert Collins wrote:
>
>> Hi, original reporter here.
>>
>> There's no LB involved.  The issue was noticed in a test lab that is tight
>> on disk space.  When an instance failed to boot the person using the lab
>> tried to delete some images to free up space, at which point it was noticed
>> that space didn't actually free up.  (For at least half an hour, exact time
>> unknown.)
>>
>> I'm more of a nova guy, so could you elaborate a bit on the GC?  Is
>> something going to delete the ChunkedFile object after a certain amount of
>> inactivity? What triggers the GC to run?
>
> Ok, updating my theory...  I'm not super familiar with glances
> innards, so I'm going to call out my assumptions.
>
> The ChunkedFile object is in the Nova process. It reads from a local
> file, so its the issue - and it has a handle onto the image because
> glance arranged for it to read from it.

As I understand it, the ChunkedFile object is in the glance-api process.  (At 
least, it's the glance-api process that is holding the open file descriptor.)


> Anyhow - to answer your question: the iterator is only referenced by
> the for loop, nothing else *can* hold a reference to it (without nasty
> introspection hacks) and so as long as the iterator has an appropriate
> try:finally:, which the filesystem ChunkedFile one does- the file will
> be closed automatically.

 From what I understand, the iterator (in the glance-api process) normally 
breaks out of the while loop once the whole file has been read and the read() 
call returns an empty string.

It's not clear to me how an error in the nova process (which causes it to stop 
reading the file from glance-api)  will cause glance-api to break out of the 
while loop in ChunkedFile.__iter__().

Chris