3 Replies Latest reply: Apr 5, 2012 11:09 AM by Vinnie Lima RSS

CLM EC2 SOI Request is failed due to Tag

Giri NameToUpdate

Hi All,

 

I am using CLM RDS stack & I have integrated EC2. I have configure Service Blueprint & did Tag just to identify the resources but unfortunately that didn't worked. So I have removed all the Tags & Policy then onboard new Tenant & created new use for that Tenant. Login to CLM console with Newly created used & mapped EC2 Network container with newly onboarded Tenant and I checked blueprint again to make sure Tag is removed. Then I raise one request to create SOI on EC2 but that request is failed with following error,

 

Error while retrieving com.bmc.cloud.model.beans.ComputePoolPlacementAdvice objects for placement decision from input request.

 

PFA csm.log.

 

 

Thanks in advance.

  • 1. CLM EC2 SOI Request is failed due to Tag
    Vinnie Lima

    How many compute pools do you have defined in CLM?

     

    If you have more than one, you have no choice (AFAIK) but to use Tags, otherwise the service governor won't know what to select.

  • 2. Re: CLM EC2 SOI Request is failed due to Tag
    Giri NameToUpdate

    Hi Vinnie,

     

    There are 2 choices,

    1) If you have multiple Compute pools or Network Container(NC) then use Tag

    2) or Create another Tenant & associate NC with that Tenant

     

    In my case I have selected 1st option but that didn't worked so I have removed all the Tag & chose 2nd option. Now I don't have any Tag and any policy in Service Governor, but still its showing error related Tag. My question is, if we don't have any Tag & Policy defined then how come Tag error is throwing?

  • 3. CLM EC2 SOI Request is failed due to Tag
    Vinnie Lima

    Alright, here's a lesson on what worked for me on using Tags. This has always been a confusing topic.  Below is a representation of option #1 as its the only option I have tried (have not tried what you suggested in #2).

     

    I've scrubbed some of the sensitive information on the screenshots and changed names for Location/Container/etc to protect the innocent, but hopefully the context carries through.

     

    First, its the defined location. For this example, we have two locations, each represent a different data center with separate Virtual Centers and ESX Clusters.  For this example, we are going to use "LocationA".

     

    rm-locations.png

     

    Second, we have our created POD from our BBNA blueprint.  This is the default VCenter Pod definition (a topic for another thread).  For this example, we refer to this pod as "PodA".

    rm-pods.png

     

    Then, we have our network containers.  In this example, we have an alternate site (blanketed out) and Primary, which is what we'll use in this example.

    rm-netcons.png

     

    Now comes the Compute Pools - we are going to focus on the one labeled "vCD" as the representation of the VirtualCluster in the Primary site.

    rm-comppools.png

     

    Now comes the tagging. First you need to create the tags and their appropriate values.  You can do this from editing a resource such as Network Container or Resource Pool, and clicking on the Add Tag icon and then select "Manage Tags" on the bottom corner.

     

    Here, we add two tags and assign appropriate values.  One tag is for the Site (determins which Location you will be provisioning to.  The second tag is for determining which Compute Pool to provision to.  I always thought you could get away with a single tag for both Site (synonimous with Network Container in our case) and Compute Pool, but for our use cases we may have more than one Conpute Pool in each Site. Your use cases may vary.

     

    tags-site.png

    tag-compute_pool.png

     

    Second, you need to ensure correct tag value assignment in the Network Container.  Otherwise, the service governor will not know where to provision to. So in the screenshot below, we edit the Network Container for the "Primary" site.

     

    Note that we specified two tags:

    Site = LocationA

    ComputePool = vCD

     

    The Pod automatically gets associated with PodA as its part of the onboarding of Network Container (again, topic for another thread).

    netcontain-edit.png

     

    The next important item is to edit the ComputePool and assign the appropriate tag value.  Below, you will see we assigned tag:

     

    Compute Pool = vCD.

     

    You will see how this is used later on.

    comppool-edit.png

     

    Now lets configure the Service Governor on which tags it should consider for allocating resources to provisioniong requests.  Below you will see the Service Governor takes into account the "Site" tag value in the Service Blueprints when deciding on which Network Container to provision into.

     

    sg-nc.png

     

    Below you will see that the Service Governor will take into account the Compute Pool tag value in the Service Blueprint when deciding on which Compute Pool to provision into.

    sg-cp.png

     

    Below you will see that we are not making any distinctions on which Virtual Disk Repository Pools to provision into (that's because we only have one onboarded with the Primary POD).

    sg-vdr.png

     

    Now lets look at the blueprint tag assignment. This is critical to ensure the Service Governor can make the right decisions.  The values assigned to the Blueprints are the ones taken into account for provisioning by the Service Governor.

     

    blueprint-general_tags.png

     

     

    We have tags assigned in other places of the Service Blueprint, but none are necessary except in this location for determining the Container and Compute pool to provision into.

     

    Hopefully the above shines some light in the Tag usage from a minimum requirements perspective.

     

    Thanks,

    Vinnie