Hi All,
There am thinking of two ways of creating vm resources with Advance Services designer. Let me know your thoughts.
1. ASD service invoking VCO workflow
Infrastructure:
1. VCO DynamicType . i.e LinuxVM
2. VCO workflow that creates and returns object of type LinuxVM
3. VCAC Custom resource based off of VCO Dynamic Type LinuxVM
4. Custom Actions
Pros:
* Flexible/Customizable - developer will have complete control over the workflow
Cons:
* More moving parts more error handling : Our environment distributed(multi-node plugin)
* More development work: Need to develop provisioning, action workflows
2. ASD Service invoking VCO Workflow which in turn call VCAC Catalog Item - Blueprint
Infrastructure:
1. VCO DynamicType . i.e LinuxVM
2. VCO that invokes custom catalog item and returns object of type LinuxVM
3. VCAC Custom resource based off of VCO Dynamic Type LinuxVM
4. Custom Actions
5. VCAC Catalog Item - Blueprint
Pros:
* Easier transition from ASD to Blueprint when VCAC matures
Cons:
* quicker development
* deal with two objects - one created by blueprint and other by ASD
Thanks,
@SeanKohler - That workflow you have pointed to does use the reconfigure action (hardcoded in the scripting element)
var Operation = "Reconfigure";
Actually, in my opinion it's a poor workflow. One long script makes it difficult to read and we have hardcoded values in there (6.1 to 6.2 changed the resource action name from edit to reconfigure for example). The workflow I have posted does pretty much the same thing but it's modularised compared to that one long script.
Oli
Thanks Oli... for some reason I thought it wasn't, my mistake....
This is what I got out of GSS in February when I asked if we can get a Plugin method to "Change Any Catalog Resource." (They gave me a method that also uses "reconfigure", but only works for machine resources... though I have a way of changing ownership of custom resources.) It may be you wrote this for us...?
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
I did just get some suggestions from the developer. Re: 2. Change Ownership of Any Café Catalog Resource through vRO workflow.
You can use the workflow "Request a resource action" to change the owner of the catalog resource. Following needs to be passed as the inputs.
1. Catalog resource : The catalog resource whose owner needs to be changed
2. Resource Operation : Reconfigure (The machine should have this action entitled)
3. Input values :
provider-operationId = Infrastructure.Machine.Action.Reconfigure
provider-machineId = dfd188bf-7ea9-4490-ae87-72e411876820
provider-MachineName = test005
provider-Cafe.Shim.VirtualMachine.Reconfigure.PropertyBag = [] provider-Cafe.Shim.VirtualMachine.Owner = ownerID (How to get this is explained below) provider-Cafe.Shim.VirtualMachine.Reconfigure.Networks = []
In order to obtain owner ID(or userID) you can run the attached workflow "Get UserId from UserName" where the input has been give as a string(eg fritz@coke.vmware.com). You also need to set the value of the attribute host of type vCAC:vCACHost. This workflow prints the userID. So we can pass this userID in the workflow Request a resource action.
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
I have a feature request in for a better change owner method on ANY Catalog Resource. I really think it should be a scripting method of the CatalogResource object type (where there is a getOwner and NO setOwner). I imagine it isn't that easy because there are a lot of hooks into ownership that I am unaware of... but I suppose it doesn't hurt to ask.
catalogResource.operations returns array of zero length in the script. Tried VM with service acct and my id as owner same result. It shows all actions in VRA portal for both my id and service acct. That means it is entitled correctly. Any idea.
Are you talking about Oli's workflow?
The code is in both scripts.
getOperations() method returns "0" operations when the resource is from getCatalogResources. It displays correct operations only when the resource is from getCatalogResource
var requestId = "92c57c89-cbd9-4275-8385-230ff4d5e578";
var count = 0;
var allItems = vCACCAFEEntitiesFinder.getCatalogResources(vcacCafehost);
System.log("Total number of catalog items within the environment is: " + allItems.length);
//Get resources associated with the request
while(allItems.length > count)
{
System.log(allItems[count].requestId);
if(allItems[count].requestId == requestId)
{
System.log("Catalog Resource match found");
deployedCatalogResource.push(allItems[count]);
}
count++;
}
var VM = deployedCatalogResource[0];
var resourceActions = VM.getOperations();
System.log("resourceActions.length:"+resourceActions.length); //// This always returns "0" length
VM = vCACCAFEEntitiesFinder.getCatalogResource(vcacCafehost,VM.id);
var count = 0;
resourceActions = VM.getOperations();
System.log("resourceActions.length:"+resourceActions.length); // This returns correct length
The service account that runs the plugin. (you can see which one it is on the inventory tab) Put that in your Business Group Support User Role... Then add it to the Entitlement that can do everything (including Reconfigure). I use a dedicated Entitlement per business group specifically for the Service Account.
My bet is that you do not see the Consumer Resource Operations (which is an "entitled" "resource action") here....
Check if you actually DO see Actions under your Items Resource. (Machine Resource) If not... then perform the above.
Hi Sean,
there seems to be a bug with the vCAC Plugin for vRO anyways. Tested this with the vCACCAFE plugin version 6.2.1 and vCAC plugin version 6.2.1.
I'm using a shared session for both plugins and the plugin user has sufficient permissions. Also, as shown in your image, I'm able to see the actions for each item when browsing the plugin inventory.
The results I found don't make sense (yet) but seem to indicate a bug.
// This works if the vCACCAFE:CatalogResource is provided as workflow input parameter
var ops = item.getOperations(); // will return a Array containing all operations
for each (op in ops)
{
System.log("Action: " + op.name); // works
}
// But it fails, if the vCACCAFE:CatalogResource is dynamically collected using EntityFinder or other methods
bindingId = iaasVM.virtualMachineID;
cafeItems = vCACCAFEEntitiesFinder.getCatalogResources(cafeHost);
for each(item in cafeItems)
{
if(item.getProviderBinding().getBindingId() == bindingId)
{
// The correct item is found and of type vCACCAFE:CatalogResource
var operations = item.getOperations(); // however, this will ALWAYS return an empty Array!
}
}
As you can see the plugin user seems to have sufficient permissions, because when calling item.getOperations() the array of operations is returned (first case). In the second case, where we dynamically search and find the item, the method will return an empty array.
Anyone at VMware has an eye on this?
Check this for a workaround: https//communities.vmware.com/message/2551061
I am not sure if it is specifically a bug or if it is how the resource finders (vRO server or EntitiesFinder in vRA) retrieve the object. I have seen this elsewhere in the product, and I thought that perhaps there is a difference between object instantiations that live within the execution of a script and an object that is bound to source. Though, come to think of it... you are probably right. What use is a temporary object not attached to its real object? It seems like the key is the vCACCAFEEntitiesFinder.getCatalogResource(cafeHost,CatalogResourceID) method. That is the only method that I was able to find that worked.
Here is what I have in my workflow examples. Looks like the main difference is that I am getting the "buggy" resource object using Server.findAllForType(...) and using that to supply the ID into the method that appears to work. Similar approach... same result...
var myResources = Server.findAllForType("VCACCAFE:CatalogResource",stringName);
//var myResources = vCACCAFEEntitiesFinder.findCatalogResources(cafeHost,stringName);
for each (resource in myResources){
if (resource.getName() == stringName){
System.log(resource.getName());
resourceTarget = vCACCAFEEntitiesFinder.getCatalogResource(cafeHost,resource.getId());
System.log(resourceTarget.getName());
for each (operation in resourceTarget.getOperations()){
System.log(operation.getName());
}
}
}
So I also wrote this... which shows the "buggy" object has no resource operations, but can be used to get name and ID. With the ID, you can get the object in a way that provides the operations through the method. I am probably drawing some incorrect conclusions though.
var stringName = vcVm.name;
//Get the resource using the vRO plugin inventory method with a CAFE plugin filter on name for CatalogResource
//Would probably be an array of one.
var myResources = Server.findAllForType("VCACCAFE:CatalogResource",stringName);
for each (resource in myResources){
//In this loop, resource is your object of VCACCafe:CatalogResourceif (resource.getName() == stringName){
System.log(resource.getName());
System.log(resource.getId()); // If this truly is all you need
//Operations?
var resourceOperations = resource.getOperations();
for each (operation in resourceOperations){
System.log("? " + operation.getName());
}
System.log("Nope... not going to find any, but... ");
// Differences between execution objects and source objects
System.log("When you GET the object by ID through the entities finder...");
System.log("And your Plugin Service Account has permissions in the business group to see resource operations...");
resourceTarget = vCACCAFEEntitiesFinder.getCatalogResource(cafeHost,resource.getId());
System.log(resourceTarget.getName());
for each (operation in resourceTarget.getOperations()){
System.log(operation.getName());
}
}
}