deployVirtualMachine API call error - Ambiguous Service Offering

September 06, 2013 09:02

deployVirtualMachine API call error - Ambiguous Service Offering

I'm trying to program the deployment of VMs and am running into an issue with certain service offering / template combinations.

I'm specifying serviceofferingid, templateid and zoneid, since these are mandatory parameters to the deployVirtualMachine call, and I'm also specifying networkids since I have more than one isolated network and not doing so throws a different error.

Some combinations of serviceofferingid and templateid work OK, but some throw up an error:

{"deployvirtualmachineresponse":{"errorcode":499,"errortext":"Ambiguous Service Offering, found more than one product bundles that match SO: <id> and template: <id>"}}

I assume therefore that there is another optional parameter I need to specify for these combinations, but am at a loss to work out what it could be.

I've tried "over-specifying" the deployVirtualMachine call by specifying the hypervisor even though I think that's implied in the SO/template combination, but that throws the same error.

Any idea which other parameters might be at fault, or if there's something else wrong?

(If it makes any difference, I'm driving the API from Python using https://github.com/jasonhancock/cloudstack-python-client

using a call like:

cs.deployVirtualMachine({'serviceofferingid': SO_MEDIUM,
'templateid': T_ID,
'zoneid': Z_ID,
'networkids': N_ID,
'hypervisor': 'XenServer',
'ipaddress':'10.20.30.99',
'name':'server001'})

where SO_MEDIUM, T_ID, Z_ID and N_ID are Template, network and zone IDs determined from earlier listServiceOfferings, listTemplates, listZones and listNetworks calls)

mark oakden MEMBERS 06 September 2013 - 09:02 AM

5 comments

Please sign in to leave a comment.

Previous 5 comments

Date Votes

Erik Godin

March 23, 2016 07:21

Bump. I don't see too much talk about API and scripted deployments on this board, hopefully someone from the helpful Citrix team could answer this one :)

Regards,
Erik

Kurt Bachelder

March 23, 2016 07:21

Sounds like that might be something you can fix by modifying your products/bundles in CPBM.

If you have multiple bundles with overlapping template/service offering entitlements, CPBM won't understand which one to subscribe to when you only specify a service offering and template.

For example:

Bundle 1:
- Product: VM Instance - Small
- Entitlement: Unlimited
- Product: Template - CentOS 6.4
- Entitlement: Unlimited

Bundle 2:
- Product: VM Instance - Small
- Entitlement: 10 hours
- Product: Template - CentOS 6.4
- Entitlement: 10 hours

If you simply specify "I want a Small/CentOS 6.4 Instance", how does it know which bundle to subscribe you to? Sounds like that's the issue you're facing. I'm not sure there's a way around that at this point, since the API is just acting (mostly) as a pass-through - it currently doesn't seem to have the intelligence built in to allow you to specify a bundle to choose (at least, not in any documentation that I can find).

HTH

K

Administrator

March 23, 2016 07:21

Thanks Kurt,

That sounds like it might well be the case. I'll do some digging and see if I can confirm it or not.

Looking through the API docs, I think you are also right about there being no (documented) way around it. Looks like the CPBM bundle concept hits a "blind spot" in the CloudStack API.

one thing that puzzles me, though ... is CPBM not using the CloudStack API behind the scenes when VMs are deployed via the web interface? If so, how can it deploy VMs in either bundle?

Cheers,
Mark

mark oakden MEMBERS 09 September 2013 - 21:53 PM

Kurt Bachelder

March 23, 2016 07:21

As far as I know, CPBM is using the CCP (CloudPlatform/CloudStack) standard API behind the scenes.

The key here is that Portal maintains its own database that Platform is not aware of. When operating via the CPBM Web Application, you select a template and compute offering that are used as filters to narrow down your selection in the catalog - however, you may still have multiple options that require you select a specific Bundle.

So if you select a specific bundle in CPBM, that bundle is "known" in the CPBM database, and then an API call is made to CCP to provision the resources (compute, template, volumes, etc.) related to that specific bundle. CCP doesn't care what the CPBM bundle is - it just wants to know what to provision. Meanwhile, CPBM has already set up a subscription specifically for the bundle you chose.

However, if you go "directly" to the CCP API via the CPBM passthrough, CPBM needs to try to match your template/compute selection to a bundle in order to charge you for it. CCP itself doesn't care - your API call is never getting there, because CPBM is preventing you from starting an offering that needs some further filtering.

If CPBM can't use the data you've passed to figure out which bundle to subscribe you to in order to collect usage/charges, you'll get that error.

Until CPBM gets an API of its own that allows you to list bundles, entitlements, or frequencies (or some documentation that clarifies it), I think this will be a recurring issue...

K

Administrator

March 23, 2016 07:21

Thanks Kurt,

That makes a lot of sense now - thanks for taking the time to explain the situation so clearly!

I think I'll need to go back to our CloudPlatform provider to see what I can do about the ambiguity.

I'm thinking that I can perhaps create my own set of templates and make sure that they don't create multiple bundles around those? It's a step I'm going to have to take anyway (at the moment, I'm experimenting with orchestrating environment builds using the API and have just been using the provided templates to do that with).

Thanks again for that excellent explanation.

Cheers,
Mark