vRA 8.1 - Use an updated imageRef value

[emacintosh]

Hi all,

In our blueprint, we supply a specific imageRef to use for cloning, which contains a valid template.  However, during the Compute Allocation phase, we would like to be able to re-assign the imageRef property to a different template -  a copy that we know is in the cluster we're deploying to (for faster cloning).  We do have all of that working and are sending the updated imageRef value back to vRA in a customProperties attribute.

But when the clone actually takes place in vSphere, it uses the original template.  We can verify that the imageRef value is updated as it should be in customProperties, but it seems to be ignored when the cloning.  Does anyone know if this something we should be able to do in 8.1?  Or if there is another way to change the template used for cloning after the request is submitted?

In 7.5, we update the __clonefrom field, which works as expected.

Any insight is appreciated, thanks!

[Lalegre]

I am thinking on another way to do it. What if you add some Capability Tags to your clusters and depending which Cluster you select for the provisioning you can specify a particular imageRef_

[emacintosh]

Thanks for the reply, but I think I may end up in the same spot.  Ultimately, we won't know which cluster the build will wind up in before the request is submitted by the user - it's not something we want them to select, and multiple clusters could match based on the capability tags.  So there's no way for us to have the image we want to use in the blueprint simply because we can't know until placement happens.

So this may be another way to determine the image we want to use during the compute allocation, but we'd still need to find a way to tell vRA to use the updated image we select.  That's the part that doesn't seem to be working.  It's as if the imageRef at request time is set in stone and can't be altered again before provisioning. 

Unless there is a different way to update the imageRef other than through modifying the custom properties?

[emacintosh]

Working with support on this.  It does seem like the imageRef value can be updated successfully during Compute Reservation, but unfortunately I don't think that helps us since we still won't know which cluster we'll be landing in at that phase.  That event does have a placementIds array in its schema, so we may be able to use that to choose a cluster ourselves.....but doesn't look promising as of now.  I've asked support to see if they can identify exactly what those placementIds represent, since it is not documented - no word yet.

[filosmith]

Same issue here. Any updates?

[emacintosh]

I apologize for never following up on this thread.  We did in fact get this working quite a while ago.  However I don't fully recall which version made this possible, but I believe it was 8.2.

We do this during the Compute Allocation (compute.allocation.pre) event.  The workflow takes in inputProperties as normal, we do our logic on that input and the workflow outputs the imageRef property only.

So just to elaborate a bit.  We have:

• A workflow in vRO that updates the imageRef based on some logic
• We have a subscription in vRA for the Compute Allocation event topic
• That subscription points to the vRO workflow
• The vRO workflow outputs the imageRef

Here is the Inputs/Outputs of the workflow

Hope that helps!

[cgaya]

@emacintosh can you share how you were able to determine the target cluster?  Was it to do with the placementIds you mentioned previously?

[emacintosh]

Hi cgaya.  During Compute Allocation, we use the hostSelectionIds property.  As we understand it, that property holds all of the possible clusters that matched our constraint tags.  We choose one of those at random, put it in an array by itself called hostSelectionIds and then output that back to vRA.  And that results in the randomly selected cluster being the one we build to.  And that is how we know which cluster was chosen....because we chose it.   (we do have to use the vra api to look up the id to see which cluster it correpsonds to as well)

The only reason we do that is because we have to know the cluster at the time.  And unfortunately, that info is not available.  In fact, I don't think it's ever available again in later event topics, except maybe as embedded the datastore name.  We're several versions behind now at 8.4.2, so that may have changed (hopefully).  Ideally we would prefer for vRA to choose the cluster and just let us know which it chose.  

With the way we're doing it, we can't rely on soft tags because we can't determine which choice matched which tags.  Obviously all of the hard tags were matched for all of them, but no idea about soft tags.  Although at some point I think they were going to introduce logic to sort them by most tags?  I don't recall exactly how that was going to work or whether it was ever implemented.

[cgaya]

Thanks @emacintosh.. I actually built that same solution you just described earlier today. Was hoping there was an easier way, but it works.  We are on 8.8 and it looks like this is still the only way.

I agree it would be nice if there was a state where the decision was already made and clusterName provided.  Still waiting on a way to set constraints programmatically as well. Holding my breath 😬