VMware Cloud Community
Windspirit
Hot Shot
Hot Shot
Jump to solution

vRO Configuration Elements not refreshing

So here is a funny thing: when running the same workflow (session) a config element's content isn't refreshed.

Meaning:

you have a workflow running for some time and it's checking a config element in vro for its values. like so:

isDone=true;
confCat=Server.getConfigurationElementCategoryWithPath("vlabsMultiDeploy/"+id);
for each (conf in confCat.configurationElements){
    System.log("looking at :"+conf.name);
    if (conf.name=="deployInfo"){
        continue;
    }
    status=conf.getAttributeWithKey("status").value;
    System.log(status);
    if (status=="new"||status=="working"){
        isDone=false;
        break;
    }
}

Now you have during the runtime of the Workflow an external workflow changing the content of this Configuration Element. e.g. status="Created"

The workflow that is still running won't see the update, it still looks at the old value. I even used a workflow instead of a scriptable task, as I thought that would look at a refreshed version...but no dice.

Anyone any idea?

Reply
0 Kudos
1 Solution

Accepted Solutions
carl1
Expert
Expert
Jump to solution

So you are runing 3 vRO instances (even if you are a single vRA node).  The workflow that is changing the value is likely running on a different node than that which is checking it's value.  Config Elements are cached in RAM.

So if vRO 1  checks the value

vRO 2 changes it (but this is in the vRO DB only)

vRO 1 checks the value again but the cache has not changed

So what you need to do is do a "config_element.reload()" to load the new value.  If there is any chance that more than one vRO workflow could change it at the same time, you will need to set a mutex lock to ensure only one running workflow changes it at a time.

For example, here is a code sample that gets sequence numbers.  Sorry it is in XML form but you can get the idea.  My lab is not up tonight.

Carl L.

View solution in original post

3 Replies
carl1
Expert
Expert
Jump to solution

So you are runing 3 vRO instances (even if you are a single vRA node).  The workflow that is changing the value is likely running on a different node than that which is checking it's value.  Config Elements are cached in RAM.

So if vRO 1  checks the value

vRO 2 changes it (but this is in the vRO DB only)

vRO 1 checks the value again but the cache has not changed

So what you need to do is do a "config_element.reload()" to load the new value.  If there is any chance that more than one vRO workflow could change it at the same time, you will need to set a mutex lock to ensure only one running workflow changes it at a time.

For example, here is a code sample that gets sequence numbers.  Sorry it is in XML form but you can get the idea.  My lab is not up tonight.

Carl L.

carl1
Expert
Expert
Jump to solution

<?xml version='1.0' encoding='UTF-8'?>
<dunes-script-module name="getNextSequenceNumber" result-type="number" api-version="6.0.0" id="5fd1baf9-d866-4253-af5b-50405abec0d2" version="0.1.1" category-name="community.utility">
<description><![CDATA[Get the next number in a sequence in a vRO cluster safe way. Requires a configuration element "Sequences" to exist.]]></description>
<param n="sequenceName" t="string"><![CDATA[Sequence name]]></param>
<param n="autoCreate" t="boolean"><![CDATA[Optional: If sequence is not found, should it be created with an initial value of 1. Default is false.]]></param>
<script encoded="false"><![CDATA[/*
All codes are used at your own risk. We take no responsibility for any unexpected side effects.
We do ask that, should you find an error, please report it so that we can fix it for others or
join the community to assist in the correction.

Licensing is under GPL, which can be found at https://www.gnu.org/licenses/gpl-3.0.en.html

*/
/*
Version Date Developer
Description of change

0.1.1 Dec 18, 2021 Carl Linkletter
Initial
*/

System.getModule("community.utility.log").logDebug("community.utility", 1, "Start: getNextSequenceNumber: " + sequenceName);

if (! autoCreate) autoCreate = false;

var configElement = null;
var ans = null;
var path = "Sequences";
var lock="Community_ConfigElement/" + path;
var owner = System.nextUUID();

var configElement = System.getModule("community.utility").findConfigurationElement(path);

if (configElement == null) {
throw "Configuration element '" + path + "' not found.";
}

// Lock affinity group to ensure another cluster is not doing the same thing at the same time.
try {
System.getModule("community.utility.log").logDebug("community.utility", 2, 'Acquiring lock "' + lock + '"');
LockingSystem.lockAndWait(lock, owner);
System.getModule("community.utility.log").logDebug("community.utility", 3, 'Acquiring lock "' + lock + '" acquired.');

configElement.reload(); // flush vRO Config Element cache

var attr = configElement.getAttributeWithKey(sequenceName);
if (attr == null) {
if (! autoCreate) throw "No key found with name " + sequenceName + " in path " + path;
ans = 1;
} else {
ans = attr.value;
}

configElement.setAttributeWithKey(sequenceName, (ans+1), "number");

} finally {
LockingSystem.unlock(lock, owner);
System.getModule("community.utility.log").logDebug("community.utility", 2, 'Lock "' + lock + '" released');
}

System.getModule("community.utility.log).logDebug("community.utility", 1, "END: getNextSequenceNumber: " + sequenceName + " = " + ans);

return ans;
]]></script>
</dunes-script-module>

Reply
0 Kudos
Windspirit
Hot Shot
Hot Shot
Jump to solution

Thanks heaps.

as usualy relaod() isnt in the API docu.