Project

General

Profile

Feature #17417

Inform the admin in case multiple service reload is done in rapid succession

Added by Marco Mambelli over 2 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
08/09/2017
Due date:
% Done:

0%

Estimated time:
8.00 h
Stakeholders:

Factory Ops

Duration:

Description

In SL7 a service reload triggers the sequence sop reconfig and start and this is asynchronous.
In production factories (~600 entries) a reconfig may take 5min or more. And factory operators may have further changes and invoke a reload before the previous is complete.
I think at the moment the second reload is ignored (the SIGHUP is not listened to during the reconfig)
Options are:
1- interrupt current reconfig and restart it (and restart the service only after)
2- queue a new reconfig right after the current (before restarting the service)
3- notify that reconfig is in progress and the request is ignored

Jeff expressed a preference for option 3.

History

#1 Updated by Marco Mambelli about 2 years ago

  • Assignee set to Dennis Box

This is almost a duplicate of [#17570].
If possible a notification should be added ("Reconfig already in progress"), otherwise add a note why this is not doable or too complicated.
Thanks

#2 Updated by Parag Mhashilkar about 2 years ago

I am confused with this ticket. Wasnt this resolved in v3.2.20?

#3 Updated by Parag Mhashilkar about 2 years ago

  • Subject changed from Handle multiple service reload in rapid succession to Inform the admin in case multiple service reload is done in rapid succession

#4 Updated by Marco Mambelli about 2 years ago

  • Target version changed from v3_2_21 to v3_2_22

#5 Updated by Marco Mambelli almost 2 years ago

  • Stakeholders updated (diff)

#6 Updated by Dennis Box almost 2 years ago

  • Estimated time set to 8.00 h

#7 Updated by Marco Mambelli almost 2 years ago

  • Target version changed from v3_2_22 to v3_2_23

#8 Updated by Dennis Box almost 2 years ago

  • Status changed from New to Feedback
  • Assignee changed from Dennis Box to Marco Mambelli

Changes in branch v3/17417 branched from branch_v3_2.

Implemented preference choice 3). Output goes to /var/log/messages and is viewable with systemctl status gwms-factory or systemctl status gwms-frontend.

Easiest way to test is probably to put a sleep call in creation/reconfig_glidein or creation/reconfig_factory.

#9 Updated by Marco Mambelli almost 2 years ago

  • Assignee changed from Marco Mambelli to Dennis Box

#10 Updated by Marco Mambelli almost 2 years ago

  • Target version changed from v3_2_23 to v3_4_0

#11 Updated by Dennis Box over 1 year ago

  • Status changed from Feedback to Resolved

#12 Updated by Marco Mambelli over 1 year ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF