cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Murali Reddy <Murali.Re...@citrix.com>
Subject Re: Contrail plugin
Date Wed, 09 Oct 2013 14:03:46 GMT
On 09/10/13 6:10 AM, "Pedro Roque Marques" <pedro.r.marques@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
>
>



Mime
View raw message