Unable to change the AWS AMI ID programatically

[invhariharan]

Hello Everyone,

I have a use case for creating an AWS IaaS Blueprint to deploy a vendor provided AMI Image (public from AWS Marketplace). The user would then be presented an option to choose a subnet in a vpc for the image to be deployed. As it is mandatory to specify an AWS AMI Image ID during the IaaS Blueprint creation, the user will not be able to select any subnet outside of the region where the image (that is defined in the blueprint) is available. So for instance if I specify an image that is available in us-west-1 and if the user selects to deploy in a subnet in us-east-2 then the blueprint fails at the "Allocate request" for reservations.

[Infrastructure service provider error: A server error was encountered. Error requesting machine. No reservation is available to allocate within the group AAAAAA. Selected reservation policy was [AWS Res Policy].].

The above error is weird but goes away if I specify the correct AWS AMI ID for the region associated with the reservation policy.

I've tried multiple methods to change the AMI ID programatically but in vain:

• Using EBS (PRE -> BuildingMachine): This does not work as the Allocate for Reservations is executed before the Machine provisioning lifecycle begins.
• Using a XaaS Blueprint to request a catalog Items: I couldn't pass the Amazon Image ID in the JSON payload for the catalog item as it threw the below error... I tried to hack passing the properties "amazon_image" and "__amazon.Image.ID" but resulted in validation errors:
  • The value for the field id amazon_image is fixed and cannot be overridden
  • [Custom property '__amazon.Image.ID' cannot be from predefined custom properties]

Another solution that I was made aware was to have multiple IaaS Blueprints (or catalog items) for each region with respecitve Amazon Image ID... and have a XaaS blueprint wrapper that can invoke the appropriate catalog item based on the user's request. This mean I need to create multiple catalog items for each region which seems bit messy... Is there a better way to handle this use case scenario?. Any thoughts?

My environment: vRA version 7.4.0 (build 8182598), vRO 7.4.0.8071781

thanks, hari

[lukez1985]

I came across this thread trying to do the same thing. I also tried set the "__amazon.Image.ID" property during an event subscription but it didn't work. I was going to try the JSON payload request through API but having seen your thread I am not going to bother if it's not going to work.

The only way I see it working is to use the pre component profiles method introduced in v7.3 which involves creating a blueprint for each required image, then create a XaaS blueprint which will be used to call the required blueprint. Should be able to put another blueprint in front of the XaaS blueprint to benefit from the custom forms introduced in v7.4 thus keeping blueprints standardised.

I will try it out.

[stevedrummond]

Setting the property "__amazon.Image.ID" in EBS in a stage prior to and including PRE.BuildingMachine absolutely works in 7.3+. Make sure you only have one EBS subscription that is updating the machine properties for that lifecycle stage. It's bound by the same rules as the "__cloneFrom" property for vSphere.

Since the allocation to a reservation occurs before this, you can either set the property earlier in the cycle (such as a pre-approval policy) or just configure the blueprint with a standard globally available AMI ID. It doesn't matter what it is as you will always override it with your AMI.

Component Profiles don't support AWS and creating many blueprints for each AWS AMI leads to massive sprawl and inflexible blueprints (e.g., blueprint cannot support 2012R2 OR 2016, at launch time)

[lukez1985]

I have already tried setting "__amazon.Image.ID" on a PRE VMPSMasterWorkflow32.BuildingMachine & PRE VMPSMasterWorkflow32.Requested subscription and it didn't change the image that was deployed. Running vRA v7.5.

[stevedrummond]

It's working in all my instances of vRA 7.4. I also just tested against vRA 7.6 and it worked there too, so I can only assume it will work in vRA 7.5.

How are you setting the property in your EBS workflow? And you're definitely not setting other values in the same lifecycle with a different EBS (e.g., in PRE-Requested you're setting the machine name)? Remember that only one EBS workflow can update values on the machine entity per lifecycle state; whatever runs last takes precedence.

If between the state that you set it (e.g., pre-requested) and the next state (e.g., pre-building) the payload of your EBS workflow has not updated the __amazon.Image.ID value then the way you are setting it is not correct. This value should reflect the updated value which then correspondingly builds the correct AMI in EC2.

Have you tried doing it with a clean slate of EBS, ignoring all your normal provisioning activities? Just one EBS that runs in PRE-Requested which changes the value and one EBS in PRE-Building that validates the value has changed; you can fail the Building EBS to prevent any actual deployment from occurring.