Using ASD Blueprints to call IaaS blueprints on behalf of user

[pizzle85]

We currently have a mix of ASD and IaaS blueprints. I want to move all our IaaS blueprints to be ASD blueprints that call the underlying IaaS blueprints. Right now my vRO vRA plug-in uses a service account to connect to vRA. I have some ASD blueprints that use the "requestCatalogItemOnBehalfOf" action. This doesn't work very well because the IaaS catalog item im executing on behalf of the user needs to be entitled to both the user I'm submitting on behalf of and the service account submitting the request. What this means is that the user will see both the IaaS and the ASD blueprints in the catalog. We want users to only see the ASD blueprints.

My thought was to entitle the IaaS blueprints to just the service account and the ASD blueprints to users. I would then just run the "requestCatalogItem" action which would provision the IaaS item in the business group the service account was in and owned by the service account. During the "provisioned" stage I would change the group and owner of the item to the submittors. I see how to change the owner and the group pretty easily but i don't see the connection for the storage part.

Is anyone out there doing this? Any suggestions on how to approach this or just the method to update the storage associated with the group im moving the ownership of the provisioned item to?

[sbeaver]

For my ASD deployments I have an action that gets the Requested By information, which is the user that made the request from vCAC.

That code for the action looks like this:

return System.getContext().getParameter("__asd_requestedBy");

Is this kinda what you are looking for?

[SeanKohler]

>>> but i don't see the connection for the storage part.

I haven't had much sleep or coffee, but you lost me here.  What storage part?

Edit:  The storage reservation?

[SeanKohler]

I made an entitlement for my service account in every business group and put the service account as a support user in each.  The service account can provision directly in the business group, then change owner.

It seems like you have one business group for a service account and you are trying to change owner and move the machine to the other business group?  Do I have that right?

[pizzle85]

No Steve, i actually capture that information in an ASD box that uses the "Field" selection for business group > requestor. Its a box they can populate if they want to submit on behalf of someone else in their business group.

[pizzle85]

Correct, the storage reservation. I see the reservations in the entity framework but i don't see the links that connect them back to the VM object. When i try to expand those fields in the entity database there appears to be nothing there.

[pizzle85]

Yes Sean, thats exactly my scenario. Have you run into any issues by putting the service account as a support user in each business group? In our scenario each business group is a customer within our university. Im not objected to putting him in each BG if I need to. How do you determine which business group the ASD workflow uses when submitting the IaaS blueprint?

DO you also have an entitlement for each business group that only contains your service account that entitles it to the IaaS blueprints and not the normal users?

My thought process was to define the vRA group/entitlement once then through a single piece of code move the object to the correct group and owner rather than adding the service account to each BG and crating a unique entitlement for the IaaS BP's for the service account in each BG.

[SeanKohler]

Re storage reservation...

It isn't ideal... but something to keep in mind.

I am pretty sure the reservation "used" is updated on inventory data collection.  You can refresh the vRA data collection via workflow in vRO.  It runs pretty fast.

I would probably be a little concerned in a large environment like yours with the performance of running a data collection after every build, but maybe there is something you can work out.

[SeanKohler]

>>> Have you run into any issues by putting the service account as a support user in each business group?

No.  I have a business group onboarding ASD Service Blueprint that creates:

1. Active Directory Groups

2. The Business Group

3. BG Custom Properties

4. Seven Entitlements (one dedicated to the service account that has both resource actions and Services/Catalog IaaS Blueprints entitled)

5. The Default Reservation(s) (via REST)

>>> DO you also have an entitlement for each business group that only contains your service account that entitles it to the IaaS blueprints and not the normal users?

Correct.  Multiple entitlements are possible.

>>> My thought process was to define the vRA group/entitlement once then through a single piece of code move the object to the correct group and owner rather than adding the service account to each BG and crating a unique entitlement for the IaaS BP's for the service account in each BG.

It is a good way to solve your problem. Maybe see if a data collection gives you results?

For me, I wanted the vRA plugin service account in vRO to be able to run actions in a business group and see machine/custom resources (aka Catalog Resources).  So we already had the service account in the business group support group to see the resources AND had Resource Actions entitled to the service account.  Adding Catalog Blueprints (via Services) was just the next logical step.

Some things I don't know:

1. If there is an upper bound on the number of business groups or catalog items a user can be entitled to.  If you have 100 business groups and 10 different kinds of catalog requests, you would see a list of 1000 entitled Catalog items in the Library of the plugin  (under Catalog).    Ten for each business group. 100 types of catalog requests.... 10,000 Catalog items the service account would be entitled to.

2. If the product management team is going to take my request for global entitlements seriously.

Edit:

>> How do you determine which business group the ASD workflow uses when submitting the IaaS blueprint?

You have the business group from the requested ASD workflow. (it is entitled to a business group)  Just pass it through.

How are you doing your build? REST or one of the "Request Catalog Item" workflows?  With the REST call, you can just replace the subtenantRef Id and target any business group easily.

[SeanKohler]

More prescriptive for the Business Group for REST call...

Either use...

__asd_subtenantRef

Or...

Use hidden field that has a BG name constraint and pull the ID though an action or whatever.  I made an action that takes a business group name and returns the ID.

[pizzle85]

Thanks Sean, right now im using the "request catalog item" workflow. What im finding is that the machine will be provisioned in the business group that the catalog item i select to use is entitled to. What ive done is grab all catalog items, sift through them for the one whose name matches "Custom Template" then check those results for the one that has its organization set to the business group i want to deploy to. I then request that catalog item. Setting the "provisioningGroupId" property with the workflow sets that property to the correct business group but doesnt actually provision the machine in the correct business group.

Are you saying that if i call the catalog item through REST for "Custom Template" that is entitled to group X and put group Y in using the "__asd_subtenantRef" property it will build the machine in group Y?

[pizzle85 · Accepted solution]

In the event anyone comes looking, here's what i ended up doing.

I added a service account to each of my business groups (the same service account for all groups) and entitled it to all my IaaS blueprints. I removed the IaaS blueprint entitlements from the customers so they are only entitled to the ASD blueprints that call the IaaS blueprints. I configured a vRO workflow for each IaaS blueprint that simply has a custom script to populate the form data and the workflow "Request a catalog item". The inputs for the workflows are mosly relative to your situation however be sure to ask for the owner username and make sure its formatted USER@DOMAIN.

The only secret sauce (which isnt really a secret) was to pass the username as the value of the property "provider-VirtualMachine.Admin.Owner"

What is happening is:

1. The user submits an ASD blueprint
   1. The ASD blueprint includes a hidden text field that has the default value set to Field > Request Info > Business Group > Name
2. The vRO workflow looks up all the catalog items that are entitled to the service account that are named something and checks each match to see if its entitled to the submitter business group and will request this specific catalog item. It then compiles a properties array using the inputs from the ASD form
3. The vRO workflow then submits a request to execute the appropriate IaaS catalog item as the service account.

When the machine gets built, it will be built in the appropriate business group and the user specified in the owner field will be set as the owner. That user will have all their normal entitlements.

Its worth noting that I tried using the service account as a member of a single group which executed the "Request a catalog item on behalf of a user" workflow. I was not able to get that to successfully move the object into the correct business group.There may be a way to do it but I was not able to find it. If you have any luck with that please feel free to comment your success!

Code from number 2 (Inputs: vCACCAFE:VCACHost, everything else is just strings)

var items = vCACCAFEEntitiesFinder.getCatalogItems(host);
for each (var item in items) {
  if (item.name == "Custom Template") {
  if (item.organization.getSubtenantLabel().indexOf(group) > -1) {
  System.log("Found catalog item named Custom Template entitled for " + group + ": " + item);
  break;
  }
  }
}


cpu = cpu.toString();
memory = memory.toString();


inputs = new Array();
var jsObj = {name: "provider-custom.hostname", value: machineName};
inputs.push(jsObj);
var jsObj = {name: "provider-Infoblox.IPAM.defaultDnsSuffix", value: domainName};
inputs.push(jsObj);
var jsObj = {name: "provider-VirtualMachine.Memory.Size", value: memory};
inputs.push(jsObj);
var jsObj = {name: "provider-VirtualMachine.CPU.Count", value: cpu};
inputs.push(jsObj);
var jsObj = {name: "provider-VirtualMachine.Disk0.StorageReservationPolicy", value: storage};
inputs.push(jsObj);
var jsObj = {name: "provider-VirtualMachine.Network0.Name", value: network};
inputs.push(jsObj);
var jsObj = {name: "provider-Vrm.DataCenter.Location", value: location};
inputs.push(jsObj);
var jsObj = {name: "provider-custom.template", value: vm};
inputs.push(jsObj);
var jsObj = {name: "provider-VMware.VirtualCenter.Folder", value: folder};
inputs.push(jsObj);
var jsObj = {name: "provider-VirtualMachine.Admin.Owner", value: user};
inputs.push(jsObj);