Created attachment 534296 [details]
GetVMTemplate

Deployable.xml used to produce this bug:


<!-- a deployable represents a set of instances to launch and configure at the
     same time -->
<deployable name="application_stack">
  <description>Deployable For JBoss Application Stack</description>
  <assemblies>
    <!-- when a deployable is launched, each assembly defition in this file
         will map to a launched instance -->
    <assembly name="Proxy Server" hwp="hwp1">
      <!-- this image element references an image that exists in the image
           warehouse
           images get into the image warehouse either by building the
           image from a template XML file, or by importing from an
           external source (such as an Amazon AMI) -->
      <image id="046069e0-5579-4ac1-b9ed-8ceacde33be8"/>
      <services>
        <service name="proxy1">
          <!-- - this is a URL that the Audrey Configuration Server must be
               able to access, and points to a script that is meant to
               setup the proxy
               - the user will be responsible for authoring and providing
               this script -->
          <executable url="https://www.aeolusproject.org/redmine/attachments/download/169/start_simple"/>
          <!-- - the parameters that are fed into the "proxy_setup_script"
               above are identified here in the "services" section
               - this is a bit clunky and will likely change -->
          <parameters>
            <!-- only scalar parameter types are going to be supported
                 initially -->
            <parameter name="proxy_server_1_param_1" type="scalar"/>
            <parameter name="proxy_server_1_param_2" type="scalar"/>
            <parameter name="proxy_server_1_param_3" type="scalar">
            </parameter>
          </parameters>
        </service>
        <service name="proxy2">
          <!-- - this is a URL that the Audrey Configuration Server must be
               able to access, and points to a script that is meant to
               setup the proxy
               - the user will be responsible for authoring and providing
               this script -->
          <executable url="https://www.aeolusproject.org/redmine/attachments/download/169/start_simple"/>
          <!-- - the parameters that are fed into the "proxy_setup_script"
               above are identified here in the "services" section
               - this is a bit clunky and will likely change -->
          <parameters>
            <!-- only scalar parameter types are going to be supported
                 initially -->
            <parameter name="proxy_server_1_param_1" type="scalar"/>
            <parameter name="proxy_server_1_param_2" type="scalar"/>
          </parameters>
        </service>
      </services>
      <!-- the items listed under the "returns" element are values that
           are collected by the launched guest and returned to the
           configuration server
           the values that are returned to the configuration server can be
           shared with other launched instances in this deployable -->
      <returns>
        <return name="hostname"/>
      </returns>
    </assembly>
  </assemblies>
</deployable>

Created attachment 534323 [details]
same but different error message deploying imported rhevm image


I am getting the same error with a slightly different manifestation while trying to deploy a import rhevm template.  If you compare the screenshots, notice the same error in two different error messages.


Entity not found: GetVmTemplate
/usr/lib/ruby/gems/1.8/gems/deltacloud-client-0.4.0/lib/deltacloud.rb:403:in `handle_backend_error'
    /usr/lib/ruby/gems/1.8/gems/deltacloud-client-0.4.0/lib/deltacloud.rb:361:in `request'
    /usr/lib/ruby/gems/1.8/gems/rest-client-1.6.1/lib/restclient/request.rb:218:in `call'
    /usr/lib/ruby/gems/1.8/gems/rest-client-1.6.1/lib/restclient/request.rb:218:in `process_result'
    /usr/lib/ruby/gems/1.8/gems/rest-client-1.6.1/lib/restclient/request.rb:169:in `transmit'
    /usr/lib/ruby/1.8/net/http.rb:543:in `start'
    /usr/lib/ruby/gems/1.8/gems/rest-client-1.6.1/lib/restclient/request.rb:166:in `transmit'
    /usr/lib/ruby/gems/1.8/gems/rest-client-1.6.1/lib/restclient/request.rb:60:in `execute'
    /usr/lib/ruby/gems/1.8/gems/rest-client-1.6.1/lib/restclient/request.rb:31:in `execute'
    /usr/lib/ruby/gems/1.8/gems/rest-client-1.6.1/lib/restclient/resource.rb:63:in `post'
    /usr/lib/ruby/gems/1.8/gems/deltacloud-client-0.4.0/lib/deltacloud.rb:360:in `send'
    /usr/lib/ruby/gems/1.8/gems/deltacloud-client-0.4.0/lib/deltacloud.rb:360:in `request'
    /usr/lib/ruby/gems/1.8/gems/deltacloud-client-0.4.0/lib/deltacloud.rb:306:in `method_missing'
    /usr/share/aeolus-conductor/app/util/taskomatic.rb:162:in `create_dcloud_instance'
    /usr/share/aeolus-conductor/app/util/taskomatic.rb:32:in `create_instance'
    /usr/share/aeolus-conductor/app/models/deployment.rb:262:in `launch'
    /usr/share/aeolus-conductor/app/models/deployment.rb:243:in `each'
    /usr/share/aeolus-conductor/app/models/deployment.rb:243:in `launch'
    /usr/share/aeolus-conductor/app/controllers/deployments_controller.rb:127:in `create'
    /usr/lib/ruby/gems/1.8/gems/actionpack-3.0.10/lib/action_controller/metal/mime_responds.rb:264:in `call'
    /usr/lib/ruby/gems/1.8/gems/actionpack-3.0.10/lib/action_controller/metal/mime_responds.rb:264:in `retrieve_response_from_mimes'
    /usr/lib/ruby/gems/1.8/gems/actionpack-3.0.10/lib/action_controller/metal/mime_responds.rb:191:in `respond_to'
    /usr/share/aeolus-conductor/app/contro

Guys two things to verify before dropping this error on Deltacloud API:

1. Please check the RHEV-M API log, it should reveal that the requested Template is not imported correctly/pending/not_found.

2. Make sure that the DC Image you want to start from Conductor is available in "/api/images" and have 'OK' state. 

My guess is that the image was not imported to RHEV-M or the registration failed somehow. Another reason could be that the image was not imported as Template but as Virtual Machine (Ian told me a while ago that all images are imported as Templates in RHEV-M).

Once it appear in "/api/images" listing and it has 'OK' state and throw this Exception it's 100% sure Deltacloud API bug.

Dave can you please try out the two items Michal is suggesting.. thank you!!

So #1, not sure which is RHEV-V API log but the template is already in rhevm.  We are importing it into aeolus with the aeolus-cli import command which I assume puts some pointers in iwhd to find the imported template.

The template I used does work.  I pushed it with a previous install of conductor along with deploying a instance of it.

#2 doesn;t really make sense as an image hasn't been created yet, its during the create (deploy) instance which the stack trace is produced.

For my understanding it seems that deltacloud expects the vm to already be created on the import which is not the case.  The import is pointed at a rhevm template of a vm, the actual vm for deployment still needs to be created from that template and then started.

I check your setup and there is one weird thing:

https://[censored].redhat.com:8443/api/templates

<template id="2a0af504-c120-425e-a227-b3eae7f11f37" href="/api/templates/2a0af504-c120-425e-a227-b3eae7f11f37">...</template>
<template id="fd5f1738-cc5d-439b-989f-2feab0dcfc77" href="/api/templates/fd5f1738-cc5d-439b-989f-2feab0dcfc77">...</template>
<template id="aeee6211-ce01-4f43-8ccb-b1ced6f95f35" href="/api/templates/aeee6211-ce01-4f43-8ccb-b1ced6f95f35">...</template>
<template id="d239ffec-8bbf-476e-bf39-ee68b92fe70b" href="/api/templates/d239ffec-8bbf-476e-bf39-ee68b92fe70b">...</template>
<template id="02ecf08e-cd25-436a-b9a8-22eb39a71745" href="/api/templates/02ecf08e-cd25-436a-b9a8-22eb39a71745">...</template>
<template id="bc710516-9333-4061-8023-bfb09eb5665e" href="/api/templates/bc710516-9333-4061-8023-bfb09eb5665e">...</template>
<template id="00000000-0000-0000-0000-000000000000" href="/api/templates/00000000-0000-0000-0000-000000000000">...</template>
<template id="8cdfd432-1e28-4f55-b80d-fc2eccacd731" href="/api/templates/8cdfd432-1e28-4f55-b80d-fc2eccacd731">...</template>
<template id="b19c6d98-59b6-4d63-be34-8f7c9bfa6764" href="/api/templates/b19c6d98-59b6-4d63-be34-8f7c9bfa6764">...</template>
<template id="e719d51c-aafe-4b92-94cf-50364b3ce91f" href="/api/templates/e719d51c-aafe-4b92-94cf-50364b3ce91f">...</template>
<template id="5f2d9312-7a73-43f9-b4ef-ee8a725c358e" href="/api/templates/5f2d9312-7a73-43f9-b4ef-ee8a725c358e">...</template>

There is no template with id 'cc2056a7-20d8-4f6f-83a3-ad088573066b' (the one you're trying to launch).

Created attachment 534437 [details]
rhevm_instance_working

I'm verifying this bug as the original issue w/ deploying an instance w/ audrey bit is working. (See screenshot)

Entity not found: GetVmTemplate is no longer encountered when deltacloud gpt updated and the floppydisk hook is put into RHEVM.


[root@intel-s3ea2-03 ~]# rpm -qa | egrep "deltacloud"
deltacloud-core-ec2-0.4.1-8.el6.noarch
rubygem-deltacloud-client-0.4.0-3.el6.noarch
deltacloud-core-vsphere-0.4.1-8.el6.noarch
deltacloud-core-0.4.1-8.el6.noarch
deltacloud-core-rhevm-0.4.1-8.el6.noarch

removing bugs from ce-sprint from the tracker.. you can find these bugs by querying the "qa whiteboard" for ce-sprint-60