cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darren Shepherd <darren.s.sheph...@gmail.com>
Subject Re: [HOW-TO] Custom REST call on Destroy and Deploy
Date Fri, 04 Oct 2013 21:46:37 GMT
Once the Spring work gets merged to master this will change as
componentContext.xml or the nonoss version is gone now.  You would
need to create a file like
META-INF/cloudstack/core/spring-eventbus-context.xml on the classpath,
so if this was production, that would probably be
/etc/cloudstack/management/META-INF/cloudstack/core/spring-eventbus-context.xml.

Really we should properly package this in its own optional RPM, but
that's a different discussion.

Darren

On Fri, Oct 4, 2013 at 1:19 PM, Chip Childers <chip.childers@sungard.com> wrote:
> On Fri, Oct 4, 2013 at 4:15 PM, Musayev, Ilya <imusayev@webmd.net> wrote:
>
>> > On Fri, Oct 04, 2013 at 07:21:03PM +0000, Musayev, Ilya wrote:
>> > > We would like to add additional operations in ACS when we do deploy and
>> > destroy.
>> > >
>> > > For example, when VM is destroyed, we want to make create a JIRA ticket
>> > (rest call) to track the decomision process.
>> > > When VM is deployed, we may need to do something else, but also rest
>> > based?
>> > >
>> > > I can see 2 ways of doing this,
>> > >
>> > >
>> > > 1)      Extend the UI and initiate extra REST calls via java script
>>  (low risk)
>> > >
>> > > 2)      Add more functionality to API Command (extra work and
>> maintenance
>> > burden)
>> > >
>> > > 3)      Create a Custom front end (seems like a lot of work)
>> > >
>> > >
>> > > How can this be done most efficiently and hopefully with least
>> intrusion?
>> >
>> > Have you considered using the RabbitMQ eventbus plugin, and tying into
>> the
>> > events that you want to act on that way?
>>
>> I see you made an awesome post on integrating RabbitMQ with ACS.
>>
>>
>> http://www.chipchilders.com/blog/2013/7/16/tapping-into-apache-cloudstack-events-via-amqp.html
>>
>> You've made it a part of simulatorComponentContext.xml.in, however, in my
>> case its going to be a production system with real events, where would you
>> recommend this go?
>>
>> Thanks
>> ilya
>>
>>
>>
> In the Component Context file that you use in prod.  The different build
> targets pull in one of the different component contexts as the version to
> use in the specific build.  I suppose that means (because I know you use
> Vmware), that you'd put it in nonossComponentContext.xml.in.

Mime
View raw message