VMware Cloud Community
carl1
Expert
Expert
Jump to solution

Transfer blueprint properties to components

vRA 7.3

I love the property binding option on Software Components.  I have a need to do that between the top blueprint and the VM subcomponents.  Sooo, I am trying to use vRO to solve that shortfall.  I have the event broker call vRO on the "blueprint requested" event.  However, there is so little information in the payload and no information I can find on how I would alter the property values on VM components.  The only useful information I get is the request ID but it when I do the vCACCAFEEntitiesFinder.getCatalogItemRequest() call, it blows up with a 404 error.

var tenant = payload.get("tenant");

var requestID = payload.get("requestId");

var host = vCACCAFEHostManager.getDefaultHostForTenant(tenant);

var request = vCACCAFEEntitiesFinder.getCatalogItemRequest(host, requestID);

I am assuming that once I get the request, I can then move property values between components.  I know, a BIG assumption.

Any help would be appreciated.

Carl L.

Tags (1)
Reply
0 Kudos
1 Solution

Accepted Solutions
daphnissov
Immortal
Immortal
Jump to solution

I spent quite a bit of time on this today. The TL;DR version is this:  You can't use any EBS state to effect Vrm.DataCenter.Location because it's already too late at that point.

Vrm.DataCenter.Location and ReservationPolicyID are values that take effect during the allocation phase, and this phase runs before even the earliest EBS state fires (Machine Request PRE). Although, yes, you can use vRO logic to manipulate either of these values, it does not have the ability after the allocate phase has run to effect their placement. I attempted this with both of those properties and although I could manipulate the values based on your scenario, it didn't steer the deployments as intended. So, there are basically two options to do this preserving the general design: 1) Wrap the request in XaaS so you can capture and manipulate those properties before submission to the IaaS service; 2) Use custom forms in vRA 7.4 (you said you just upgraded to 7.3 so this doesn't sound feasible in the short term) where you can perform logic inside the request form itself--which is what we want in this case.

View solution in original post

Reply
0 Kudos
14 Replies
daphnissov
Immortal
Immortal
Jump to solution

Why not just use the method that I built and illustrated with that article? That's one of the use cases for it and it avoids having to go through vRO.

Reply
0 Kudos
carl1
Expert
Expert
Jump to solution

Because I need to set some of the properties before vRA starts trying to determine where to place the components.  Specifically, I need to update the Location setting (Vrm.DataCenter.Location) on each component to tell vRA where to put the components .  If I wait until the machine provisioning lifecycle events (VMPSMasterWorkflow32.Requested.PRE), it is too late.  vRA has apparently already decided where to put the component and updating the property does not change where it goes.  I want the user to make a choice about how the cluster is to be spread (all one DC or multiple DC's) and vRO to decide what that exactly looks like in terms of data center locations.   So I am trying to set the component locations in the catalog Item Requested event, hoping that will be before vRA decides what cluster it goes to.

Thanks for the quick response,

Carl L.

Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

But it shouldn't matter. As long as you know the *name* of the custom property (CP) whose value you wish to bind, you can extract the value using that software component I already built. Any summation of CPs that get inherited by the vSphere machine component on which the software component is placed can be extracted, because those all get written to the software agent (and guest agent) log. So if there's a CP on the blueprint--no matter where or how that gets there--if you know the name of it, you can bind on its value. If I'm still not getting what you're saying, feel free to correct me.

Reply
0 Kudos
carl1
Expert
Expert
Jump to solution

Problem with the package is the prereq:  We just spent a lot of $ updating to 7.3.0.  Doing another update to 7.3.1 is not going to happen any time soon.

Carl L.

Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

Not following you there. The software component I provided was built on 7.3 and should otherwise work on just about any version of 7.x.

Reply
0 Kudos
carl1
Expert
Expert
Jump to solution

From your website for "Getting started".

pastedImage_0.png

Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

Well, I guess firstly, that's not my website. Secondly, and more importantly, SovLabs has nothing to do with the software component I built to harvest arbitrary custom property values. There is no interrelationship or requirement there of any kind. If you read my blog post, at the bottom there are links to the relevant pages on VMware {code} that have the software component I built. Just import that, set the name of the custom property from which you want to extract the value, then add whatever your own software component is and bind to the computed property of the one I built. It's pretty simple. If this isn't making sense, let me know and I'll take some screenshots for you.

Reply
0 Kudos
carl1
Expert
Expert
Jump to solution

Sorry about the site mixup.  Must have looked at the wrong post.

OK, I think I understand the confusion. I am not making a clear distinction between a VM component and a Software component.  What I am trying to do is set the Vrm.DataCenter.Location property on a VM component, before it begins provisioning, to direct vRA to provision the VM component to a particular data center.

So for a cluster blueprint, set the location on VM component 1 to go to DC1, and the location on VM component 2 to go to DC2.  After the VMs are provisioned, then the software components for the cluster will be installed and the cluster wake up.  This provides protection that, should DC1 fail, the VM services will still be online from DC2.

  I am not trying to harvest property values during the software component install (which your trick works beautifully for).  I am trying to set a property VERY early in the request state.  And as I said in an earlier post, apparently the location property needs to be set BEFORE the very first event of VM provisioning occurs.  I tried setting it there and the VM does not get provisioned to the new data center.  It still goes to the DC specified on the request form (not the one vRO's property update says to go to).

Hope that helps,

Carl L.

Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

Ooookayyyy, I got it now Smiley Happy I can try and simulate this in my lab to see if the SovLabs Property Toolkit can dynamically set vrm.datacenter.location at that early phase. I believe it can. How are you wanting this to work (vRO logic aside) so I can set up a test bed? Be as specific as you can so I can mirror your scenario.

Reply
0 Kudos
carl1
Expert
Expert
Jump to solution

Smiley Happy

So.  The users are not overly technical so having them go to each sub component and set the appropriate location is not reasonable.  All the questions need to be asked on the first page.  So, for a cluster deployment, we want them to be able to select the primary DC and the distribution model (say multi-dc or local).  Then, when they select those, set the location on the VM components appropriately.  If "multi-dc", set the location on each VM component to a different value (master node to go to the selected DC).  If "local", then set the location on each VM component to the selected DC.

Thanks so very much!

Carl L.

Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

Ok, and for these DCs...Are these separate vSphere endpoints (separate vCenters, then obviously separate clusters) or are these the same vSphere endpoint but different clusters (across different vCenter datacenter constructs)?

Reply
0 Kudos
carl1
Expert
Expert
Jump to solution

Different vCenters in different cities.

Carl L.

Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

I spent quite a bit of time on this today. The TL;DR version is this:  You can't use any EBS state to effect Vrm.DataCenter.Location because it's already too late at that point.

Vrm.DataCenter.Location and ReservationPolicyID are values that take effect during the allocation phase, and this phase runs before even the earliest EBS state fires (Machine Request PRE). Although, yes, you can use vRO logic to manipulate either of these values, it does not have the ability after the allocate phase has run to effect their placement. I attempted this with both of those properties and although I could manipulate the values based on your scenario, it didn't steer the deployments as intended. So, there are basically two options to do this preserving the general design: 1) Wrap the request in XaaS so you can capture and manipulate those properties before submission to the IaaS service; 2) Use custom forms in vRA 7.4 (you said you just upgraded to 7.3 so this doesn't sound feasible in the short term) where you can perform logic inside the request form itself--which is what we want in this case.

Reply
0 Kudos
carl1
Expert
Expert
Jump to solution

Wow, thanks so much for doing all that work!!!!  No wonder you get awards for your activities here Smiley Happy

And thanks for confirming my suspicions. I thought that maybe, just maybe, if I could tie into the "catalog Item Requested" event stream, then I could set the locations.  If I wait for the "Machine Provision" event stream, then it is too late.  Apparently not.  Oh well, back to ASD it is Smiley Happy

Thanks again!

Carl L.

Reply
0 Kudos