Skip to content

Closes OOZIE-130 build workflow progress information in Oozie #775

Open
wants to merge 3 commits into from

3 participants

@brookwc
brookwc commented Aug 1, 2011

I relaxed chain type in my patch:

1) if the wf dag does not contain fork/join, i evaluate the longest possible execution path.

2) if the dag contains fork/join, I simply count total number of work actions (excluding control nodes and dummy nodes like "start", "end", "kill").

@mislam77

DONE is bot a terminal state. So I believe it should not be counted as completed.

What happened to other states : KILLED, FAILED, ERROR? Does progress count only the SUCCESS case?

you're right. I only considered success state here - consider all terminal states make more sense.

Done looks to me a terminal state, no?

@mislam77

If there are FORK and DECISION in the same WF, are we still counting the all paths in decision for total count?

For this patch yes - i took a simple approach if wf has fork/join - count all actions, even for decision case.

As i said, it can be improved later - purpose of this patch is not to provide a full-blown solution.

@mislam77

Why it is displaying conditionally? It will make the output inconsistent. For example, if someone is parsing this output, he will need to consider the presence and non-presence of this field. Moreover, when we will add more columns, it will be hard to isolate this column. If there is no work done, could not we show 0%?

Will remote this. Originally it's for the cases where no progress info is available from oozie server.
But for now, all wfs will have some progress score - so can be simply removed.

If there is no work done, should show 100%, rather 0%.

@mislam77

I believe DONE is not a terminal state.

removed this state.

@tucu00

The value here, to be consistent with other primitive types must be ZERO.

later review feedback commit already removed -1 piece.

@tucu00

The value here, to be consistent with primitive types must be ZERO.

same here - this has become orphan code - already removed in later review commit.

@tucu00

don't do a return in the middle o the method, difficult to follow flow, return should be only one at the end of the method

fixed.

@tucu00

don't do continue, instead use an if block to skip

fixed

@tucu00
tucu00 commented on f7cab5e Aug 23, 2011

Wouldn't be easier to for users if the progress is an integer representing the percentage, then is always 2 digits, easier to display

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.