incubator-deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tong Li <liton...@us.ibm.com>
Subject Re: syslog in DeltaCloud 0.4.0
Date Mon, 12 Sep 2011 12:34:45 GMT

I do not think using "lib" to reference anything is a good practice. It
just causes problems. if not using lib, DC artifacts can be used by other
gems. when some reference lib, then it actually won't work,  problem
described in item 2 is very easy to fix, simply remove "lib/", then it will
work just fine. If it is not an issue for DC, but it is not even a good
practice beside the point of reuse.

for item3, when I used dc as a gem, used in my own gem, it did not work,
the method is undefined, even though integer.rb was required already, not
sure what went wrong.

for item4, the singularize method actually require i18n, can you check if
your env actually has i18n, if you do, then you are probably using it
without knowing you are.

item 1 described in previous email was a bug. Please take a look.

for the slow performance, I can not be sure what is causing it. please take
a look at this firebug capture, not sure why the API GET instances took
25.07s, not sure why it references include.js from tb.adurr.com. I am very
sure that 0.3.0 won't take that long. Can not say it was because of thin or
webrick, or browser version, when I took the snap shot of firebug, I was
using latest firebug and firefox.

this is to get all the instances.


Another one for rendering a particular instance.




Tong Li
Emerging Technologies & Standards
B062/K317
litong01@us.ibm.com



From:	David Lutterkort <lutter@redhat.com>
To:	deltacloud-dev@incubator.apache.org
Date:	09/09/2011 02:22 PM
Subject:	Re: syslog in DeltaCloud 0.4.0



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
code.

> 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
performance.

> 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.

David



Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message