BlockedOnError needs further thought about smith HOT 6 CLOSED

If we're only keeping blocked on error for the case where the dependencies are in error, it doesn't seem to add much value to me as long as we have good overall state (just replaces 'blocked on dependency' with 'blocked on error from dependency' - you're going to look at the dependencies anyway). Doing RO processing would be sort of ok, but I don't understand why it's safer to terminate early (as a user, wouldn't I want it to get as close as possible to success, so when I correct only some stuff has to be mutated? Also, non-determinism, simplicity...).

from smith.

@ash2k opinions on just removing BlockedOnError? I think the upsides outweight the downsides.

from smith.

There are two things that come to mind. The first is not sort of misreporting the status of an object if bundle processing is stoped due to an error. Whether or not bundle processing stops when a single error is encountered is less important than the way that condition is reported to a human using the system. The second has to do with improving the readability the current bundle status. At the moment it can be inferred, barring this blocked on error message confusing things, from a combination of all condition states. This is both more information than a human requires to understand "what is the state of the bundle" and not enough because they have to go through the mental effort to turn the condition set into an actual summary.

It would be good to not confuse an individual resources state with the sate of the bundle (blocked on error) and to introduce a human readable summary.

from smith.

Sounds good to me. Seems like we have two actions:

• remove blockedOnError as a particular resource state
• have a more human readable 'bundle state' which includes the concept of blockedOnError in some way (though if we list things in an error state, it may be obvious?)

from smith.

First of all I agree in general that things need to be improved. Some questions:
Why do you want to remove blockedOnError state? I think a better approach would be to keep it but only for cases where a resource is actually blocked by it's dependencies error. What we do in other cases is up to us. I see two options:

• Continue to process resources i.e. create/update/etc
• Do "read-only" processing. E.g. if a resource is ready we mark it as ready (today we mark everything after first error is encountered as blockedOnError). But no mutative actions are performed in this option. E.g. if a resource does not exist we do not create it but say... what do we say?

I like the second option more because it feels safer. Reporting for ready resources is good (same) in both options. Thoughts?

Edit: I re-read the issue description (I read it a while ago and was writing this comment based on what I remember). My options are the same as yours, looks like. We should see how hard it would be to implement the second option.

from smith.

This is also coming up as an issue with the early validation (#187)- something might be 'blocked on dependencies' but be able to error out even so (because the early validation happens before dependencies).

i.e. we still want to evaluate things that might be 'blocked on error'. This confirms to me that we want to have 'blocked on error from dependency' as the only state change. i.e. remove the existing blockedOnError handling in favour of changing the blocked on dependency message in case the dependency is in an error state.

from smith.