VMware Cloud Community
rkrichevskiy
Enthusiast
Enthusiast

Working with AMQP subscriptions and vCO policies

I am working with over a hundred AMQP subscriptions and finding that I have to manually build a vCO policy tag for each subscription. When working with multiple Orchestrator instances this can become quite cumbersome task. Is it possible to scan my AMQP broker entry from the plugin to pick up subscriptions matching a pattern, and then build a single policy with all my subscriptions.

I do have vCloud Director notifications package loaded for some samples but so far I haven't been able to figure out a way to loop through broker subscriptions.

Thanks.

Tags (2)
0 Kudos
2 Replies
tschoergez
Leadership
Leadership

Hi,

I assume you saw the "Create a vCloud Director notification policy" workflow in the notifications package, which creates a new policy for a give subscription?

I haven't seen a way though to get all subscriptions of a certain broker (or even "link" back to the broker for a give subscription).

So the only workaround I imagine is to use Server.findAllForType("AMQP:AMQPSubscription") to get all subscriptions of the inventory, and use some broker specific naming strategy for them so you can identify which broker the belong to...

Regards,

Joerg

0 Kudos
rkrichevskiy
Enthusiast
Enthusiast

Yes, saw that example, but "Create a vCloud Director notification policy" relies on pre-built policy template. However, in my POC I'd like to have a single policy with multiple elements that are added "on-the-fly" during start up. Pre-building template manually is what I would like to avoid as it fairly laborious task to set an element, designate a trigger event and finally choose workflow to run (times ~100).

I also dug up an example with Server.findAllForType("AMQP:AMQPSubscription") but wasn't able to cook up much with it.

Right now I am getting away from the policy approach and trying to use a workflow runner (subscription listener workflow example). Just loop through an array of subscriptions and have many listeners in waiting event state on standby for an incoming message. The downside I am seeing is that to initiate this routine takes much longer than what we are accustomed to with policies. I may need to look to tune my looping method. Also, I'd like to have a way to cancel all waiting-signal state workflows that are produced as part of the start up. I am doing this right now manually by selecting them into an array from wfToken chooser, but will need to come up with a better method. The goal is to provide play/stop type of functionality for queue monitoring, which policies do accomplish, it just that method requires hell of a prep in our environment.

0 Kudos