fapifta edited a comment on pull request #1611: URL: https://github.com/apache/ozone/pull/1611#issuecomment-733932797
Hi Prashant, thank you for working on this one, great work so far! I am thinking about the refactor of the UpgradeFinalizer. In the BasicFinalizer, there is a finalizeFeature, that is called from the SCMUpgradeFinalizer, while the OMUpgradeFinalizer has its own finalizeFeature method. What if we generalize this one to be the one in BasicUpgradeFinalizer along with the worker, or why don't we? Roughly this is what I would try: - BasicUpgradeFinalizer defines the Worker, and we encapsulate the component into a wrapper behind an interface and use that in the worker. - the component's wrapper should have the two hooks, preFinalizeUpgrade and postFinalizeUpgrade - if we add a getStorage method we can avoid the problem that comes from the different Storage getters as well - we can add any other required stuff into the wrapper, and cut off the upgrade finalization logic from the component's implementation without cutting the UpgradeActions, as there we can still provide the component from the wrapper. So at the end of the day we may get to one generic UpgradeFinalizer, that uses a let's say UpgradingComponent interface for which the implementations may be OzoneManagerComponent, and StorageContainerManagerComponent. I started to think about this because of the similarities in the two concrete UpgradeFinalizer, and the two pretty much different approach on how we handled the Optional UpgradeAction :) ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
