Bug #2342

Downtime Issues

Added by Douglas Strain almost 9 years ago. Updated over 8 years ago.

Douglas Strain
Target version:
Start date:
Due date:
% Done:


Estimated time:
First Occurred:
Occurs In:


This is an issue reported by Marian Zvada. I created a ticket for it since we should at the very least discuss it:

during setup of new factory we've hit the following case:

- once we put all entries "down" (without any record in
glideinWMS.downtimes), we are not able to bring entry back "up", it
fails. I guess it might be related to non-existent record about specific
entry down rather that record that "all" entries are down.

I was able reproduce this behaviour, few step how one can do it are
listed below [*].

Don't know whether it should be classified as bug or something which
might be documented as "feature" if someone installs factory from
scratch and tries to migrate tens of entries from the other factory.

If one do downtime particularly per entry, it is indeed possible bring
it back "up" w/o hassle.


#1 Updated by John Weigand almost 9 years ago

Understand that I am not at all familiar with how downtime is implemented. My question is "why is does this just affect newly 'newly' installed factories?". It would seem like this would/could affect any factory to which new entry points are being added in mass (and maybe just one perhaps?)

John Weigand

#2 Updated by Douglas Strain almost 9 years ago

Yes, this affects all factories with multiple entries for at least several versions back, not just newly installed factories.

#3 Updated by Igor Sfiligoi almost 9 years ago

Here is my take on this:
What Marian is describing is not a bug, but a "feature".
We want to have a way to put the whole factory down, and bring it back up, while preserving the various downtime states of the various entries.
Please make sure this functionality is preserved.

However, Marian pointed out an interesting new use case;
when installing a new factory, one may indeed want to proceed cautiously and start with all entries down.
And then bring up one at a time.

However, I don't think this should be implemented in the "manageDowntimes" tool.
It should be instead a feature of create_glidein/reconfig_glidein; i.e. if so desired, new entries are created in downtime state already.

#4 Updated by Douglas Strain over 8 years ago

  • Target version changed from v2_5_5 to v2_5_6

#5 Updated by Parag Mhashilkar over 8 years ago

  • Target version changed from v2_5_6 to v2_5_7

#6 Updated by Douglas Strain over 8 years ago

Here is my proposal:

This functionality would CHANGE:
./factory_startup down -entry all [or -entry entries]
would now be the same as doing "./factory_startup down -entry X" for each entry X. This would destroy any combination of entries up/down you have. All entries would be set as in downtime. Conversely,
./factory_startup up -entry all [or -entry entries]
Would be the same as doing "./factory_startup up -entry X" for each entry X. All entries would then be up and out of downtime regardless of what they were previously.

However, I propose that the following stays the same as before:
./factory_startup down -entry factory
This would set the factory as being down, and leave all the entries alone. This could be used to preserve entry-specific downtimes while setting the whole factory as down and then later as up.

Does this solve the problems? If so, I will code this later on this week.

#7 Updated by Douglas Strain over 8 years ago

  • Status changed from New to Rejected

This has been decided that it will not be fixed, as the solution requires a potential destruction of history of entries being up or down. This would be disruptive to factory owners and operators.

#8 Updated by Burt Holzman over 8 years ago

  • Target version changed from v2_5_7 to v2_7_x

#9 Updated by Parag Mhashilkar over 8 years ago

  • Target version changed from v2_7_x to v2_6

Also available in: Atom PDF