deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lutterkort <>
Subject Re: syslog in DeltaCloud 0.4.0
Date Fri, 09 Sep 2011 18:19:44 GMT
On Wed, 2011-09-07 at 17:09 -0400, Tong Li wrote:
> 2. incorrectly use "lib" in the require path, this causes big problem for
> others to use DC gem. There are two places
> 	base_driver/base_driver.rb
> 	sinatra/rack_syslog.rb
> 	both files have some thing like this
> 	require 'lib/xxxxx'
> 	They should be changed to
> 	require 'xxxxx'

The Deltacloud server is _not_ meant to be used as a library. There is
absolutely no guarantee about any sort of API stability for any of the
ruby code; the stable API for Deltacloud is the RESTful web API.
Therefore, the require above is not an issue.

> 3. In base_driver/features.rb, it still uses ordinalize method from an
> integer, which has been removed in newer active_support package,

We do not depend on active_support. Integer#ordinalize is defined in
lib/deltacloud/core_ext/integer.rb - for some of these core_ext's we do
use names familiar from active_support/Rails, but define them in our own

> 4. i18n is a dependency , but was not stated in the spec.

Where do you see that dependency ? In the public instance I just set up
from scratch, i18n is not installed, and everything works. I can also
not find any reference to i18n in the code.

> 5. nokogiri requires some other dependency which is not available on 64
> bits platform, forgot the name of it, when I tried to gem install, it did a
> local build, then blows up because it was trying to use 32 libraries on
> windows.

I am unfortunately not familiar with the intricacies of multilib on
Windows. Could you dig up what exactly blows up ? Could there be a
problem if you already have 32 bit libxml2/libxslt installed and then
try to build 64 bit nokogiri ?

> 6. syslog is not available on windows platform, both item 5 and 6 really
> hurts. I had to setup an Ubuntu 11.04 machine to do my development.

Yes, that needs to be addressed.

> 7. new RC4 is extremely slow. I run 0.4.0 and 0.3.0 on the same machine,
> 0.4.0 took a lot longer from user point view. not sure if it has anything
> to do with the newer UI or because of the thin server which is now
> required. Any reason why switch it from WEBrick?

When using native ruby, thin has always been the default web server.
WEBrick is generally not meant for production uses since it's very slow,
single-threaded etc.

Is there any way you can quantify the slow down you see in the UI, e.g.
with Firebug's 'Net' view - the jquery UI introduces a good bit of
Javascript; that's also the biggest change that might affect

> is there any way these problems can be fixed? or they have been fixed in
> newer builds? If I can access the source, I do not mind to fix them. I
> think that problems described in 1 to 4 should really be fixed ASAP.

I think none of 1 through 4 are actual issues. Definitely, we need to
address the syslog issue, and the slowness you see. But I think that can
be done in the next release.


View raw message