Tim integration fixes #275

jprovaznik · 2012-12-19T13:16:10Z

No description provided.

After creating new target or provider image we want go back to base image show page. If we want to avoid overriding whole controller action we have to change default respond behavior - this is done in custom RedirResponder which is used only for UI create/destroy actions for Tim. This responder only sets any error into flash message and redirect to specified URL.

This backtrace was just informative, but it can be confusing to print this excpetion in log because this happens for all imported images.

This is hotfix for aeolus-incubator/tim#69 issue.

Proper button is displayed based on current status of target/provider image. If build or push is in progress, no button is displayed, only status label if progress.

Wrong scope (global) was used for defined constants, to avoid this full path is used in decorators.

Imagefactory requires additional parameters when pushing openstack image. it's possible that similar problem will be for other provider types (rhevm, vsphere).

This field is required by imagefactory when pushing an image.

There can be multiple builds for an image version, in such case grab first *completed*.

n1zyy · 2012-12-19T23:40:44Z

If I run this against standard Deltacloud (deltacloud-core-1.0.5-1.fc17.noarch + deltacloud-core-openstack-1.0.5-1.fc17.noarch), adding a ProviderAccount fails with this Deltacloud error:

E, [2012-12-19T18:37:24.038254 #8088] ERROR -- 500: [Deltacloud::Exceptions::BackendError] Unhandled exception or status code (Must supply an :auth_url)

/usr/share/gems/gems/openstack-1.0.6/lib/openstack/connection.rb:76:in `initialize'
/usr/share/gems/gems/openstack-1.0.6/lib/openstack/connection.rb:60:in `new'
/usr/share/gems/gems/openstack-1.0.6/lib/openstack/connection.rb:60:in `create'
/usr/share/deltacloud-core/lib/deltacloud/drivers/openstack/openstack_driver.rb:373:in `block in new_client'
/usr/share/deltacloud-core/lib/deltacloud/drivers/exceptions.rb:212:in `call'
/usr/share/deltacloud-core/lib/deltacloud/drivers/exceptions.rb:212:in `safely'
/usr/share/deltacloud-core/lib/deltacloud/drivers/openstack/openstack_driver.rb:368:in `new_client'
/usr/share/deltacloud-core/lib/deltacloud/drivers/openstack/openstack_driver.rb:49:in `supported_collections'
/usr/share/deltacloud-core/lib/deltacloud/server.rb:52:in `block in <class:API>'
/usr/share/gems/gems/sinatra-1.3.2/lib/sinatra/base.rb:1212:in `call'
/usr/share/gems/gems/sinatra-1.3.2/lib/sinatra/base.rb:1212:in `block in compile!'

However, if I start Deltacloud with the -P http://openstack.local:5000/v2.0/ flag, it does work. I reproduced this on a clean setup; it seems as is the parameter on the Provider is just not getting passed through (?). I haven't debugged this extensively yet.

n1zyy · 2012-12-19T23:52:33Z

Attempting to import an image, or create a new image, with the provided Gemfile appears to always leave me with this error:

undefined method `pool_family' for #<Tim::BaseImage:0x00000007bc7d28>
/usr/local/rvm/gems/ruby-1.9.3-p194@conductor/gems/activemodel-3.2.8/lib/active_model/attribute_methods.rb:407:in `method_missing'
 /usr/local/rvm/gems/ruby-1.9.3-p194@conductor/gems/activerecord-3.2.8/lib/active_record/attribute_methods.rb:149:in `method_missing'
 /root/aeolus/conductor/src/app/views/tim/base_images/_new.html.haml:5:in `_app_views_tim_base_images__new_html_haml__2878789138283108405_49254200'
 /usr/local/rvm/gems/ruby-1.9.3-p194@conductor/gems/actionpack-3.2.8/lib/action_view/template.rb:145:in `block in render'
 /usr/local/rvm/gems/ruby-1.9.3-p194@conductor/gems/activesupport-3.2.8/lib/active_support/notifications.rb:125:in `instrument'
 /usr/local/rvm/gems/ruby-1.9.3-p194@conductor/gems/actionpack-3.2.8/lib/action_view/template.rb:143:in `render'
 /usr/local/rvm/gems/ruby-1.9.3-p194@conductor/gems/actionpack-3.2.8/lib/action_view/renderer/partial_renderer.rb:265:in `render_partial'
 /usr/local/rvm/gems/ruby-1.9.3-p194@conductor/gems/actionpack-3.2.8/lib/action_view/renderer/partial_renderer.rb:238:in `block in render'
 /usr/local/rvm/gems/ruby-1.9.3-p194@conductor/gems/actionpack-3.2.8/lib/action_view/renderer/abstract_renderer.rb:38:in `block in instrument'
 /usr/local/rvm/gems/ruby-1.9.3-p194@conductor/gems/activesupport-3.2.8/lib/active_support/notifications.rb:123:in `block in instrument'
 /usr/local/rvm/gems/ruby-1.9.3-p194@conductor/gems/activesupport-3.2.8/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
 /usr/local/rvm/gems/ruby-1.9.3-p194@conductor/gems/activesupport-3.2.8/lib/active_support/notifications.rb:123:in `instrument'
 /usr/local/rvm/gems/ruby-1.9.3-p194@conductor/gems/actionpack-3.2.8/lib/action_view/renderer/abstract_renderer.rb:38:in `instrument'
 /usr/local/rvm/gems/ruby-1.9.3-p194@conductor/gems/actionpack-3.2.8/lib/action_view/renderer/partial_renderer.rb:237:in `render'
 /usr/local/rvm/gems/ruby-1.9.3-p194@conductor/gems/actionpack-3.2.8/lib/action_view/renderer/renderer.rb:41:in `render_partial'
 /usr/local/rvm/gems/ruby-1.9.3-p194@conductor/gems/actionpack-3.2.8/lib/action_view/renderer/renderer.rb:15:in `render'
 /usr/local/rvm/gems/ruby-1.9.3-p194@conductor/gems/actionpack-3.2.8/lib/action_view/helpers/rendering_helper.rb:24:in `render'
 /usr/local/rvm/gems/ruby-1.9.3-p194@conductor/gems/haml-3.1.6/lib/haml/helpers/action_view_mods.rb:11:in `block in render_with_haml'
 /usr/local/rvm/gems/ruby-1.9.3-p194@conductor/gems/haml-3.1.6/lib/haml/helpers.rb:90:in `non_haml'
 /usr/local/rvm/gems/ruby-1.9.3-p194@conductor/gems/haml-3.1.6/lib/haml/helpers/action_view_mods.rb:11:in `render_with_haml'
 /root/aeolus/conductor/src/app/views/tim/base_images/new.html.haml:3:in `_app_views_tim_base_images_new_html_haml__2625153905699485504_48878800'

I initially thought this was a transient problem with thin in development mode, but it happens non-stop here. Note that this is running from source, very recently checked-out and run through bundle install. However, a bundle update fixes the issue. I think what is happening is that Gemfile.lock is specifying an older build of tim -- I go from d8c193a to 2eba454 when running bundle update, even if immediately after bundle install. (Full diff here: https://gist.github.com/4341814)

n1zyy · 2012-12-19T23:57:13Z

This Travis failure (1.8 Cucumber, though fine on 1.9) actually sounds potentially relevant to what we're working on:

Scenario: Edit an invalid XML when creating an image # features/image.feature:17

I think it was broken in a previous commit, not here, so it's not a blocker for this -- but it's something we may want to look at before merging to master.

n1zyy · 2012-12-20T00:19:16Z

The status PUT upon completion from Factory causes a 500 in Conductor:

Started PUT "/tim/target_images//2" for 127.0.0.1 at 2012-12-19 19:02:13 -0500
Processing by Tim::TargetImagesController#update as HTML
  Parameters: {"base_image"=>{"status"=>"COMPLETE", "_type"=>"BaseImage", "parameters"=>{"callbacks"=>["http://localhost:3000/tim/target_images//2"], "libvirt_xml"=>"<?xml version=\"1.0\"?>\n<domain type=\"kvm\">\n  <name>factory-build-59e17694-a28b-4f13-999e-2376abe826c9</name>\n  <memory>1048576</memory>\n  <currentMemory>1048576</currentMemory>\n  <uuid>d3d12b64-8ab0-47ff-93f6-c7974ea90912</uuid>\n  <clock offset=\"utc\"/>\n  <vcpu>1</vcpu>\n  <features>\n    <acpi/>\n    <apic/>\n    <pae/>\n  </features>\n  <os>\n    <type>hvm</type>\n    <boot dev=\"hd\"/>\n  </os>\n  <on_poweroff>destroy</on_poweroff>\n  <on_reboot>destroy</on_reboot>\n  <on_crash>destroy</on_crash>\n  <devices>\n    <graphics port=\"-1\" type=\"vnc\"/>\n    <interface type=\"bridge\">\n      <source bridge=\"virbr0\"/>\n      <mac address=\"52:54:00:bf:7f:82\"/>\n      <model type=\"virtio\"/>\n    </interface>\n    <input bus=\"ps2\" type=\"mouse\"/>\n    <console type=\"pty\">\n      <target port=\"0\"/>\n    </console>\n    <serial type=\"tcp\">\n      <source mode=\"bind\" host=\"127.0.0.1\" service=\"33561\"/>\n      <protocol type=\"raw\"/>\n      <target port=\"1\"/>\n    </serial>\n    <disk device=\"disk\" type=\"file\">\n      <target dev=\"vda\" bus=\"virtio\"/>\n      <source file=\"/var/lib/imagefactory/storage/59e17694-a28b-4f13-999e-2376abe826c9.body\"/>\n    </disk>\n  </devices>\n</domain>\n"}, "icicle"=>nil, "status_detail"=>{"error"=>nil, "activity"=>"Cleaning up install artifacts"}, "template"=>"<template>\r\n                    <name>f16jeos</name>\r\n                    <os>\r\n                      <name>Fedora</name>\r\n                      <version>16</version>\r\n                      <arch>x86_64</arch>\r\n                      <install type='url'>\r\n                        <url>http://download.devel.redhat.com/released/F-16/GOLD/Fedora/x86_64/os/</url>\r\n                      </install>\r\n                      <rootpw>test</rootpw>\r\n                    </os>\r\n                    <description>Fedora 16</description>\r\n                  </template>\r\n                  ", "percent_complete"=>0, "id"=>"59e17694-a28b-4f13-999e-2376abe826c9"}, "id"=>"2"}
undefined method `[]' for nil:NilClass
/usr/local/rvm/gems/ruby-1.9.3-p194@conductor/bundler/gems/tim-2eba45410354/app/controllers/tim/target_images_controller.rb:55:in `factory_keys'
 /usr/local/rvm/gems/ruby-1.9.3-p194@conductor/gems/activesupport-3.2.9/lib/active_support/callbacks.rb:462:in `_run__1488957595793464466__process_action__2874241485652287634__callbacks'
 /usr/local/rvm/gems/ruby-1.9.3-p194@conductor/gems/activesupport-3.2.9/lib/active_support/callbacks.rb:405:in `__run_callback'
 /usr/local/rvm/gems/ruby-1.9.3-p194@conductor/gems/activesupport-3.2.9/lib/active_support/callbacks.rb:385:in `_run_process_action_callbacks'

I think this may be a bug with us having Factory call back to the wrong place, or Factory passing the wrong data... The offending method in Tim -- in the factory_keys method of TargetImagesController -- is all about params[:target_image], but what gets passed in is all under a "base_image" AFAICT.

So there are two bugs -- one is that Factory is POSTing the wrong data to the wrong place, and the other is that Tim should probably not begin by calling params[:target_image][:percent_complete] without first ensuring that params[:target_image] actually exists. (I filed that one here: aeolus-incubator/tim#93 )

n1zyy · 2012-12-20T00:36:01Z

Hi Jan,

Code-wise, this all looks good. (With an inline nit that might not belong here -- and also an inline compliment!) There's a handful of odd behavior I'm hitting, noted above, that we should probably discuss further in the morning.

jprovaznik · 2013-01-10T13:42:17Z

sent reviside pull request, closing this

jprovaznik added 12 commits December 19, 2012 14:16

Removed logging of exception backtrace if architecture can't be found

4bc7589

This backtrace was just informative, but it can be confusing to print this excpetion in log because this happens for all imported images.

Temporary fix for duplicit error messages on image import page

948988f

This is hotfix for aeolus-incubator/tim#69 issue.

Updated displaying of build/push/delete buttons for image

fa231b5

Proper button is displayed based on current status of target/provider image. If build or push is in progress, no button is displayed, only status label if progress.

Added new Tim migrations

8ec7ab0

Fixed const definitions in decorators

265fa3d

Wrong scope (global) was used for defined constants, to avoid this full path is used in decorators.

Fixed displaying of status on deployable show page

97958a7

Fixed setting of target image's target if provider_type is nil

db57a02

Fixed passing of provider parameter to imagefactory

c4e3383

Imagefactory requires additional parameters when pushing openstack image. it's possible that similar problem will be for other provider types (rhevm, vsphere).

Added auth_url credential field to openstack provider type

3c5e43a

This field is required by imagefactory when pushing an image.

Fixed checking of last build

a3a2d2d

There can be multiple builds for an image version, in such case grab first *completed*.

Fixed forgotten call to iwhd

9329d34

jprovaznik closed this Jan 10, 2013

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tim integration fixes #275

Tim integration fixes #275

jprovaznik commented Dec 19, 2012

n1zyy commented Dec 19, 2012

n1zyy commented Dec 19, 2012

n1zyy commented Dec 19, 2012

n1zyy commented Dec 20, 2012

n1zyy commented Dec 20, 2012

jprovaznik commented Jan 10, 2013

Tim integration fixes #275

Tim integration fixes #275

Conversation

jprovaznik commented Dec 19, 2012

n1zyy commented Dec 19, 2012

n1zyy commented Dec 19, 2012

n1zyy commented Dec 19, 2012

n1zyy commented Dec 20, 2012

n1zyy commented Dec 20, 2012

jprovaznik commented Jan 10, 2013