Open Stack

Hi All,

In current scenario we are not closing the original server socket, we are closing the duplicate socket.
Server socket will hold the connection until its time out from client side.

IMO, this behaviour is good in end-user's point of view, as user will not get error immediately.
It will wait until the requests time out and before this request time out completes, if SIGHUP signal is complete and service restarts completely then this request will get processed immediately.

This is what we feel good for the end-user, but we will like to hear the opinion of the community.

Thank You,

Abhishek Kekane

-----Original Message-----
From: stuart.mclaren at hp.com [mailto:stuart.mclaren at hp.com] 
Sent: 01 September 2014 21:25
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [glance] Use Launcher/ProcessLauncher in glance


I've been looking at the most recent patch for this (https://review.openstack.org/#/c/117988/).

I'm wondering what behaviour do folks feel is best in the following scenario?

1) an image download starts (download1)

2) send SIGHUP to glance-api

3) start another download (download2)

4) download1 completes

5) ?

I think there's a few potential options:

5a) The request for 'download2' is never accepted (in which case the service is 'offline' on the node until all in-flight requests are completed).

5b) The request for 'download2' is killed when 'download1' completes and the service restarts (not much point in new SIGHUP behaviour)

5c) The request for 'download2' is accepted and completes using the existing process, but in this case the service potentially never restarts if new requests keep coming in

5d) A 'swift reload' type operation is done where the old processes are left alone to complete (download1 and download2 complete) but new parent (and child) processes are spun up to handle new requests ('download3'). The disadvantage here is some extra process accounting and potentially stray old code running on your system

(See http://docs.openstack.org/developer/swift/admin_guide.html#swift-orphans)

-Stuart


On Mon, Jul 28, 2014 at 8:12 AM, Tailor, Rajesh <Rajesh.Tailor at nttdata.com>
wrote:

> Hi All,
>
> I have submitted the patch "Made provision for glance service to use 
> Launcher" to the community gerrit.
> Pl refer: https://review.openstack.org/#/c/110012/
>
> I have also set the workflow to 'work in progress'. I will start 
> working on writing unit tests for the proposed changes, after positive 
> feedback for the same.
>
> Could you please give your comments on this.
>
> Could you also please suggest me whether to file a launchpad bug or a 
> blueprint,  to propose these changes in the glance project ?
>

Submitting to github.com/openstack/glance-specs would be best. Thanks.


>
> Thanks,
> Rajesh Tailor
>
> -----Original Message-----
> From: Tailor, Rajesh [mailto:Rajesh.Tailor at nttdata.com]
> Sent: Wednesday, July 23, 2014 12:13 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [glance] Use Launcher/ProcessLauncher in 
> glance
>
> Hi Jay,
> Thank you for your response.
> I will soon submit patch for the same.
>
> Thanks,
> Rajesh Tailor
>
> -----Original Message-----
> From: Jay Pipes [mailto:jaypipes at gmail.com]
> Sent: Tuesday, July 22, 2014 8:07 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [glance] Use Launcher/ProcessLauncher in 
> glance
>
> On 07/17/2014 03:07 AM, Tailor, Rajesh wrote:
> > Hi all,
> >
> > Why glance is not using Launcher/ProcessLauncher (oslo-incubator) 
> > for its wsgi service like it is used in other openstack projects i.e.
> > nova, cinder, keystone etc.
>
> Glance uses the same WSGI service launch code as the other OpenStack 
> project from which that code was copied: Swift.
>
> > As of now when SIGHUP signal is sent to glance-api parent process, 
> > it calls the callback handler and then throws OSError.
> >
> > The OSError is thrown because os.wait system call was interrupted 
> > due to SIGHUP callback handler.
> >
> > As a result of this parent process closes the server socket.
> >
> > All the child processes also gets terminated without completing 
> > existing api requests because the server socket is already closed 
> > and the service doesn't restart.
> >
> > Ideally when SIGHUP signal is received by the glance-api process, it 
> > should process all the pending requests and then restart the 
> > glance-api service.
> >
> > If (oslo-incubator) Launcher/ProcessLauncher is used in glance then 
> > it will handle service restart on 'SIGHUP' signal properly.
> >
> > Can anyone please let me know what will be the positive/negative 
> > impact of using Launcher/ProcessLauncher (oslo-incubator) in glance?
>
> Sounds like you've identified at least one good reason to move to 
> oslo-incubator's Launcher/ProcessLauncher. Feel free to propose 
> patches which introduce that change to Glance. :)
>
> > Thank You,
> >
> > Rajesh Tailor
> > ____________________________________________________________________
> > __ Disclaimer:This email and any attachments are sent in strictest 
> > confidence for the sole use of the addressee and may contain legally 
> > privileged, confidential, and proprietary data. If you are not the 
> > intended recipient, please advise the sender by replying promptly to 
> > this email and then delete and destroy this email and any 
> > attachments without any further use, copying or forwarding
>
> Please advise your corporate IT department that the above disclaimer 
> on your emails is annoying, is entirely disregarded by 99.999% of the 
> real world, has no legal standing or enforcement, and may be a source 
> of problems with people's mailing list posts being sent into spam boxes.
>
> All the best,
> -jay
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ______________________________________________________________________
> Disclaimer:This email and any attachments are sent in strictest 
> confidence for the sole use of the addressee and may contain legally 
> privileged, confidential, and proprietary data.  If you are not the 
> intended recipient, please advise the sender by replying promptly to 
> this email and then delete and destroy this email and any attachments 
> without any further use, copying or forwarding
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

______________________________________________________________________
Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data.  If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding