Question #2062

Clean up "big red button" code ?

Added by François ARMAND over 2 years ago. Updated over 1 year ago.

Status:Discussion Start date:2011-11-18
Priority:4 Due date:
Assignee:Nicolas CHARLES % Done:

0%

Category:Architecture - Refactoring
Target version:Ideas (not version specific)
Needs translating:No

Description

In the last time version, we choose to remove the big red button UI.

Do we want to completely clean it up, or to put it back ?

We should not let the 2.4 be released with the half-backed solution we had for 2.3.

My personal feeling is that "big red button" may be a killer features, but clearly not in the state it was : it should be accessible on a group by group basis, or node by node one.

History

#1 Updated by Jonathan CLARKE over 2 years ago

  • Target version changed from 2.4.0~alpha1 to 2.4.0~alpha2

#2 Updated by Jonathan CLARKE over 2 years ago

  • Assignee set to François ARMAND
  • Target version changed from 2.4.0~alpha2 to 2.4.0~alpha3

François ARMAND wrote:

My personal feeling is that "big red button" may be a killer features, but clearly not in the state it was : it should be accessible on a group by group basis, or node by node one.

I agree with this. I can tell you that the code in Policy Templates to manage this is mostly ready to manage this on a node by node basis, so I don't think we should remove. I don't know about the code in the webapp though, I'll leave that up to you.

#3 Updated by François ARMAND over 2 years ago

Jonathan CLARKE wrote:

I agree with this. I can tell you that the code in Policy Templates to manage this is mostly ready to manage this on a node by node basis, so I don't think we should remove. I don't know about the code in the webapp though, I'll leave that up to you.

For now, there is no way in the webapp to mark a group or a node as "not managed".
To be consistent with the real node state regarding CFEngine, we need to use the same logic to check if a node is currently in "not managed" mode or not. I believe that that state is marked thanks to a given file (promise) in some directory, and so we can't use any sort of memory/db cache of it (the "red button" feature could be use from the command line or the file put by hand for a given node)

Once that is done, we can start to think to a group-level "red button", whose actual state would be the state of each of its node. The problem is that checking that state may be quite inefficient, as it would imply to check for perhaps hundred of file presence.

So, in the end, I do think that not much of the actual logic in the webapp can be keep, and that their is quite some specification and implementation work remaining, even for the node-only "red button", or to find a 80%-good solution.

#4 Updated by Jonathan CLARKE about 2 years ago

  • Target version changed from 2.4.0~alpha3 to 2.4.0~alpha4

#5 Updated by Jonathan CLARKE about 2 years ago

  • Priority changed from 3 to 4

#6 Updated by François ARMAND about 2 years ago

  • Target version changed from 2.4.0~alpha4 to 2.4.0~alpha5

#7 Updated by François ARMAND about 2 years ago

  • Assignee changed from François ARMAND to Nicolas CHARLES

#8 Updated by Nicolas CHARLES about 2 years ago

The CFEngine code is indeed valid (and on a node basis)
As for the webapp part, i'm afraid we are a bit late in the release cycle to safely remove it; even more since there are event related to it, and scripts run by it.

#9 Updated by Jonathan CLARKE about 2 years ago

  • Target version changed from 2.4.0~alpha5 to 2.4.0~alpha6

#10 Updated by Jonathan CLARKE almost 2 years ago

  • Target version changed from 2.4.0~alpha6 to Ideas (2.4 specific)

#11 Updated by Jonathan CLARKE over 1 year ago

  • Target version changed from Ideas (2.4 specific) to Ideas (not version specific)

Also available in: Atom PDF