On 09/10/13 6:10 AM, "Pedro Roque Marques" <pedro.r.marq...@gmail.com> wrote:
>Darren, >Using ActionEvents is not desirable for the plugin either... today >CloudStack lacks the ability for a component/plugin to associate itself >to the life-cycle of an object. It would be ideal if there was a generic >way to accomplish that... >The contrail plugin wants to know about project creation and deletion. >Projects need to be reflected in the contrail-api server; the project >delete notification is necessary to understand that the project is not >longer used. > >When it comes to network objects it would also be nice if there could a >for a component/plugin to associate itself with network creation / >implementation... Currently there are calls from the NetworkManager to >components such as firewall/LB/etc which should be optional. > >Ideally, i would like to have a common notification mechanism for a >cloudstack object (e.g. project, network, nic). This could optionally >allow a plugin to "veto" an operation and/or just get notified that it >occurred. For 'veto' to operations, yes you are right that CloudStack core does not give hooks into workflow for plug-ins to veto. But there are defined abstraction (Guru, Planner, Investigator etc.) through which plug-ins can hook into orchestration. Also there is a publisher/subscriber modelled EventBus that was added in 4.1 by which CloudStack components can get the entity life cycle and state changes. I see that contrail plug-in implements an Interceptor for achieving this, but I will leave a comment in the review if 'EventBus' can leveraged. Thanks, Murali > >thanks, > Pedro. > >On Oct 8, 2013, at 10:25 AM, Darren Shepherd wrote: > >> I'll take some time and review this code too. I already know there's >> going to be a conflict with the stuff I did in the spring >> modularization branch. Moving to full spring we have gotten rid of >> the custom ACS AOP for the mgmt server. This code relies on that >> framework so it will have to move to being a standard >> org.aopalliance.intercept.MethodInteceptor. I don't particularly care >> for the fact that functionally it being keyed off of ActionEvents (or >> AOP in general). I'll need to review the code further to provide more >> useful feedback, but just giving the heads up that the AOP stuff will >> have to change a bit. >> >> Darren > >
