[SPARK-36543][CORE] Rearranged logging in decommission loop

[sungpeo]

What changes were proposed in this pull request?

Lower logging level, and transferred logInfo in a loop to outside

Why are the changes needed?

[SPARK-36543] Decommission logs too frequent when waiting migration to finish

Does this PR introduce any user-facing change?

Yes, it changes the level of logs, and make it less frequent.

How was this patch tested?

It doesn't need

[sungpeo]

@holdenk
Made it simply logging less.
I changed logInfo without changing states to logDebug.

[HyukjinKwon]

@sungpeo BTW, Apache Spark repository leverages the resources from GItHub Actions in your forked repository for your PR so it should be enabled in your forked repository to run the tests, see also https://github.com/apache/spark/pull/35094/checks?check_run_id=4699635992.

[AmplabJenkins]

Can one of the admins verify this patch?

[sungpeo]

@HyukjinKwon
Thank you for letting me know.

I enabled Github actions again, and sync (rebase) my branch to the latest master.

[dongjoon-hyun]

Sorry, but I'm -1 for this change. This is helpful to detect the decommissioners' misbehavior or some deadlock situation. Why do you need to suppress this, @sungpeo ?

[sungpeo]

@dongjoon-hyun
logInfo for other cases in the loop remain.
I think those (the remain logInfo) are enough to track the decommission.

Below logInfo(s) were repeated every loop for waiting done.
I agree with that was too much.

• https://issues.apache.org/jira/browse/SPARK-36543

...
          logInfo("Checking to see if we can shutdown.")
...
                logInfo("No running tasks, checking migrations")
...
                  logInfo("All blocks not yet migrated.")

[github-actions]

We're closing this PR because it hasn't been updated in a while. This isn't a judgement on the merit of the PR in any way. It's just a way of keeping the PR queue manageable.
If you'd like to revive this PR, please reopen it and ask a committer to remove the Stale tag!