Currently engine-setup need to map some of the values listed in the enum provided by VdcActionType in a python dict manually synchronized with that enum for handling async tasks on upgrade. We should have those values either in the DB or in a text file (json, conf, whatever) that may be used by both java and python avoding to duplicate code and require manual synchronization.
Can you describe first what's the problem you're trying to solve? Perhaps exposing VdcActionType isn't the right approach to solve it.
The problem I'm trying to solve is to have the list of the async tasks with its descriptive text available in a single place, accessible from the engine for its internal use and from engine-setup for its async task handling. Currently if you add an async task to the engine you need to align the setup code manually. I'm pretty sure that in 3.6 some new async tasks has been added to the engine and they're not handled in the setup just because it has been forgotten to sync the python code with that and the aim is to avoid that this could happen. (guess based on having more than 400 values in VdcActionType while the python code counts less than 50 values and python code being updated last time on Fri Oct 18 2013 before my change last week)
I really think that this functionality isn't required. And, exposing the enum is not a good practice. Please check whether we can remove this error-prone functionality in the first place, only telling the administrator that there are running tasks, and to look at the UI for further details.
Still discussing if we can remove this functionality
(In reply to Oved Ourfali from comment #3) > I really think that this functionality isn't required. > And, exposing the enum is not a good practice. > Please check whether we can remove this error-prone functionality in the > first place, only telling the administrator that there are running tasks, > and to look at the UI for further details. Sandro, do we have the engine service running and UI available during this stage (async tasks review) and does it applies to zombie tasks as well?
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
(In reply to Moran Goldboim from comment #5) > (In reply to Oved Ourfali from comment #3) > > I really think that this functionality isn't required. > > And, exposing the enum is not a good practice. > > Please check whether we can remove this error-prone functionality in the > > first place, only telling the administrator that there are running tasks, > > and to look at the UI for further details. > > Sandro, do we have the engine service running and UI available during this > stage (async tasks review) and does it applies to zombie tasks as well? The engine is still running at that point, yes. Not sure about the details, but even for checking if we need to alert the user, we need something to query about. Obviously this can be handled differently, e.g.: 1. Have a single PG function saying whether there is stuff that requires the user's attention prior to upgrade, which engine-setup can query and then prompt/abort if needed 2. Handle all the rest in the engine.
dropping needinfo supposing it was for question at comment #5 answered by didi at comment #7.
Closing, as we're not gonna expose that in the engine.