On 06/08/2015 12:30 PM, Robert Collins wrote:
On 9 June 2015 at 03:50, Chris Friesen <chris.frie...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
