Re: [openstack-dev] [glance] Use Launcher/ProcessLauncher in glance

2014-09-02 Thread Kekane, Abhishek
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.mcla...@hp.com [mailto:stuart.mcla...@hp.com] 
Sent: 01 September 2014 21:25
To: openstack-dev@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.tai...@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.tai...@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:jaypi...@gmail.com]
 Sent: Tuesday, July 22, 2014 8:07 AM
 To: openstack-dev@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

Re: [openstack-dev] [glance] Use Launcher/ProcessLauncher in glance

2014-09-01 Thread stuart . mclaren


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.tai...@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.tai...@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:jaypi...@gmail.com]
Sent: Tuesday, July 22, 2014 8:07 AM
To: openstack-dev@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
Disclaimer:This email and any attachments

Re: [openstack-dev] [glance] Use Launcher/ProcessLauncher in glance

2014-07-29 Thread Mark Washenberger
On Mon, Jul 28, 2014 at 8:12 AM, Tailor, Rajesh rajesh.tai...@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.tai...@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:jaypi...@gmail.com]
 Sent: Tuesday, July 22, 2014 8:07 AM
 To: openstack-dev@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@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@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@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman

Re: [openstack-dev] [glance] Use Launcher/ProcessLauncher in glance

2014-07-28 Thread Tailor, Rajesh
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 ?

Thanks,
Rajesh Tailor

-Original Message-
From: Tailor, Rajesh [mailto:rajesh.tai...@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:jaypi...@gmail.com]
Sent: Tuesday, July 22, 2014 8:07 AM
To: openstack-dev@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@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@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [glance] Use Launcher/ProcessLauncher in glance

2014-07-23 Thread Tailor, Rajesh
Hi Jay,
Thank you for your response.
I will soon submit patch for the same.

Thanks,
Rajesh Tailor

-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com] 
Sent: Tuesday, July 22, 2014 8:07 AM
To: openstack-dev@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@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [glance] Use Launcher/ProcessLauncher in glance

2014-07-21 Thread Jay Pipes

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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev