date:20120702

On Fri, Jun 29, 2012 at 03:27:25PM -0500, Andrew Bogott wrote:
 On 6/27/12 8:40 AM, Daniel P. Berrange wrote:
 On Wed, Jun 27, 2012 at 03:24:21PM +0200, Vincent Untz wrote:
 Hi,
 
 
 It'd be really great if we could first improve Gerrit to handle the
 patch series workflow in a better way. Without such a change, pushing
 patch series to Gerrit is really no fun for anyone :/
 
 
 Yep, no argument that Gerrit could do with some improvements, but having
 submitted a number of non-trivial patch series to Nova, I don't think
 current Gerrit UI is a complete blocker to adoption. It is not ideal,
 but it isn't too painful if you're aware of what to look for. I think
 the main problem is that since the patch dependancies are not obvious
 in the UI, reviewers tend to miss the fact that they're reviewing a
 patch that's part of a series.
 
 I agree that patchsets are better than monolithic patches.  Today,
 though, I am working on a 3-patch set and the process is driving me
 crazy.
 
 a)  Any time Jenkins has a hiccup, I have to resubmit the entire
 patchset.  This obscures any reviews or votes that might be attached
 to other patches in the set.

Yeah, this is a major PITA. We need an easy way for patch authors
to retrigger Jenkins without re-submitting each time.

 b) Similarly, any time I change a single patch in the set, I have to
 resubmit the whole set, which causes review history to be obscured,
 even for those patches which have not changed at all.

Gerrit will look at the GIT changeset hashes and notice if only
2 out of the 5 patches have actually changed. THe trouble is that
'git review' with no args will always rebase your patch series
against master before pushing. So even if you only modified the
last patch in your series, this will make Gerrit see all the patches
as new :-(

I'm getting into the habit of always running 'git review --no-rebase'
to get around this behaviour.

 Case b) would be entirely solved via a fix to  this:
 http://code.google.com/p/gerrit/issues/detail?id=71.  That would
 also help with a) but not resolve it entirely... the best solution
 to a) would be a 'retrigger' button in Jenkins or a 'prompt Jenkins
 to re-review' button in Gerrit.  The fact that people (including me)
 are submitting trivial edits to patches only in order to nudge
 Jenkins is pretty stupid.

I must say that this has been driving me mad this last week. IIUC, only
members of the core review team have permission to retrigger Jenkins,
but I feel it is putting too much burden on them to have to track every
patch with a bogus Jenkins failure. If we can't get Jenkins to be more
reliable, then can we see about letting patch submitters retrigger
Jenkins builds for their own patches.


Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] How do I stop image-create from using /tmp?

On Sat, Jun 30, 2012 at 09:25:10PM -0400, Lars Kellogg-Stedman wrote:
  So, maybe setting any of this environment variables for nova-compute
  to desired value sholuld help.
 
 Yeah, I was expecting that.
 
 Given that this could easily take out a compute host I'd like to see
 it get an explicit configuration value (or default to instance_dir, I
 guess).

In Fedora 18, /tmp is going to be a RAM filesystem, so we absolutely
must not create any sizeable files on /tmp.

In addition from a security POV, we must aim to *never* use /tmp for
anything at all

  http://danwalsh.livejournal.com/11467.html

It would be good to do a thorough audit of the code to make sure
nothing is using the tmpfile functions without explicitly specifying
a directory path that is private to the OpenStack daemon in question.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Unsubscribe

2012-07-02 Thread Alexey Eromenko

How-to unsubscribe ?

-- 
-Alexey Eromenko Technologov

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack][Nova] Issues with run_tests.sh, no tests are run when import libvirt is present

Thanks, that let me see the real problem now:

 ./tools/with_venv.sh nosetests -svx nova
 nose.config: INFO: Set working dir to /home/gsd/nova/nova/tests
 nose.config: INFO: Working directory /home/gsd/nova/nova/tests is a
 package; adding to sys.path
 nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$']
 nose.plugins.cover: INFO: Coverage report will include only packages:
 ['nova']
 nose.selector: INFO: /home/gsd/nova/nova/auth/opendj.sh is executable;
 skipped
 nose.selector: INFO: /home/gsd/nova/nova/auth/slap.sh is executable;
 skipped
 nose.selector: INFO: /home/gsd/nova/nova/cloudpipe/bootscript.template is
 executable; skipped
 Failure: ImportError (No module named libvirt) ... ERROR
 ==
 ERROR: Failure: ImportError (No module named libvirt)
 --
 Traceback (most recent call last):
   File
 /home/gsd/nova/.venv/local/lib/python2.7/site-packages/nose/loader.py,
 line 390, in loadTestsFromName
 addr.filename, addr.module)
   File
 /home/gsd/nova/.venv/local/lib/python2.7/site-packages/nose/importer.py,
 line 39, in importFromPath
 return self.importFromDir(dir_path, fqname)
   File
 /home/gsd/nova/.venv/local/lib/python2.7/site-packages/nose/importer.py,
 line 86, in importFromDir
 mod = load_module(part_fqname, fh, filename, desc)
   File /home/gsd/nova/nova/test.py, line 41, in module
 from nova.tests import fake_flags
   File /home/gsd/nova/nova/tests/fake_flags.py, line 24, in module
 flags.DECLARE('compute_scheduler_driver', 'nova.scheduler.multi')
   File /home/gsd/nova/nova/flags.py, line 52, in DECLARE
 __import__(module_string, globals(), locals())
   File /home/gsd/nova/nova/scheduler/multi.py, line 27, in module
 from nova.scheduler import driver
   File /home/gsd/nova/nova/scheduler/driver.py, line 53, in module
 flags.DECLARE('libvirt_type', 'nova.virt.libvirt.connection')
   File /home/gsd/nova/nova/flags.py, line 52, in DECLARE
 __import__(module_string, globals(), locals())
   File /home/gsd/nova/nova/virt/libvirt/connection.py, line 73, in
 module
 from nova.virt.libvirt import diagnostics as libvirt_diagnostics
   File /home/gsd/nova/nova/virt/libvirt/diagnostics.py, line 75, in
 module
 import libvirt as virt
 ImportError: No module named libvirt
 --
 Ran 1 test in 0.002s
 FAILED (errors=1)


Libvirt is present on my system, i can import it through the python
interpreter from any location. Yet, it still says it is not present. Could
this have to do with the virtual_env or fakelibvirt?

On Fri, Jun 29, 2012 at 6:54 PM, Jay Pipes jaypi...@gmail.com wrote:

 Hi Leander,

 I've noticed some weirdness with the openstack.nose_plugin (which is used
 by default for the Nova test runner) sometimes either throwing errors
 (particularly errors raised by nosetests) away and/or coming up with a
 different set of skip tests than when running just with nosetests.

 So, I'd recommend running just this:

 ./tools/with_venv.sh nosetests -svx nova

 That will stop at the first error and probably will give you better
 insight into the actual errors that are likely being suppressed by the
 openstack nose plugin.

 best,
 -jay


 On 06/29/2012 09:02 AM, Leander Bessa Beernaert wrote:

 Hello,

 I'm sorry to restart the topic
 (https://lists.launchpad.net/**openstack/msg13621.htmlhttps://lists.launchpad.net/openstack/msg13621.html),
 but
 i accidentally deleted the message in my inbox :S.

 I'm still having the same problem, each time i add import libvirt to
 the file diangostics.py 
 (https://review.openstack.org/**#/c/8839/https://review.openstack.org/#/c/8839/)
 the
 entire test suit won't run.

 *With the import* present i get the following output:


   --**--**
 --
 Ran 0 tests in 0.000s
 OK Running PEP8 and HACKING compliance check...
 2 imports missing in this test environment


 *Without the import *present it get this output:


   --**--**
 --
 Ran 3030 tests in 233.326s
 OK (SKIP=22) Running PEP8 and HACKING compliance check...
 11 imports missing in this test environment



 The problem now is that, according to the OpenStack conventions, the
 import must be present. However, with the import present i can't get any
 of the tests to run.
 I'm no expert in Python, so could someone please help me out here?

 Regards,

 Leander


 __**_
 Mailing list: 
 https://launchpad.net/~**openstackhttps://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : 
 https://launchpad.net/~**openstackhttps://launchpad.net/~openstack
 More help   : 
 https://help.launchpad.net/**ListHelphttps://help.launchpad.net/ListHelp

Re: [Openstack] Unsubscribe

2012-07-02 Thread Juan J. Martinez

On 02/07/12 10:58, Alexey Eromenko wrote:
 How-to unsubscribe ?
 

Go to https://launchpad.net/~openstack , login in your launchpad account
and click on Unsubscribe button in Mailing list section (left bottom).

There are links 4 links in at the end on any mail to the list with
information about the list, including unsubscribe.

Regards,

Juan



___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] PEP8 checks

2012-07-02 Thread John Garbutt

Hi,

I noticed I can now run the pep8 tests like this (taken from Jenkins job):
tox -v -epep8
...
pep8: commands succeeded
congratulations :)

But the old way to run tests seems to fail:
./run-tests.sh -p
...
File 
/home/johngar/openstack/nova/.venv/local/lib/python2.7/site-packages/pep8.py, 
line 1220, in check_logical
for result in self.run_check(check, argument_names):
TypeError: 'NoneType' object is not iterable

Is this expected?
Did I just miss an email about this change?

Cheers,
John

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Nova and asynchronous instance launching

2012-07-02 Thread Day, Phil

Hi Chris,

Thanks for the pointer on the new notification on state change stuff, I'd 
missed that change.

Is there a blueprint or some such which describes the change ?   

 In particular I'm trying to understand how the bandwidth_usage values fit in 
here.  It seems that during a VM creation there would normally be a number of 
fairly rapid state changes, so re-calculating the bandwidth_usage figures might 
be quiet expensive jut to log a change in task_state from say Networking to 
Block Device Mapping. I was kind of expecting that to be more part of the 
compute.exists messages than the update.

Do we have something that catalogues the various notification messages and 
their payloads ?

Thanks,
Phil



-Original Message-
From: Chris Behrens [mailto:cbehr...@codestud.com] 
Sent: 02 July 2012 00:14
To: Day, Phil
Cc: Jay Pipes; Huang Zhiteng; openstack@lists.launchpad.net
Subject: Re: [Openstack] Nova and asynchronous instance launching



On Jul 1, 2012, at 3:04 PM, Day, Phil philip@hp.com wrote:

 Rather than adding debug statements could we please add additional 
 notification events (for example a notification event whenever task_state 
 changes)
 

This has been in trunk for a month or maybe a little longer.

FYI

- Chris

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Nova] How to improve our bug triaging ?

2012-07-02 Thread Alan Pevec

On Thu, Jun 28, 2012 at 11:32 AM, Thierry Carrez thie...@openstack.org wrote:
 The team is now open, anyone familiar with Launchpad and Bug triaging[1]
 is welcome to join at [2]. Let's triage all New/Undecided bugs now !

 [1] http://wiki.openstack.org/BugTriage
 [2] https://launchpad.net/~nova-bugs

What about other projects?
glance/swift/quantum are moderated keystone/horizon are restricted

Cheers,
Alan

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] multi_host not working

Hi.  I am trying to use multi_host to eliminate the controller hosts 
as a single point of failure.


I followed the steps at 
http://docs.openstack.org/essex/openstack-compute/admin/content/existing-ha-networking-options.html 
and added thse options to the end of nova.conf. Now the guests have no 
connectivity to the outside world at all. (Running on ubuntu 12.04 using 
packages.)


Controller:
--multi_host=True
--enabled_apis=ec2,osapi_compute,osapi_volume,metadata

Compute nodes:
--multi_host=True
--enabled_apis=metadata

I also tried changing the routing_source_ip option on each compute node 
to it's own ip address but it makes no difference.

--routing_source_ip=10.10.20.11X

What am I missing?

Tx
Marnus van Niekerk

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Nova] How to improve our bug triaging ?

2012-07-02 Thread Thierry Carrez

Alan Pevec wrote:
 On Thu, Jun 28, 2012 at 11:32 AM, Thierry Carrez thie...@openstack.org 
 wrote:
 The team is now open, anyone familiar with Launchpad and Bug triaging[1]
 is welcome to join at [2]. Let's triage all New/Undecided bugs now !

 [1] http://wiki.openstack.org/BugTriage
 [2] https://launchpad.net/~nova-bugs
 
 What about other projects?
 glance/swift/quantum are moderated keystone/horizon are restricted

I proposed to open all bug teams a couple months ago, but that option
was not universally loved:

https://lists.launchpad.net/openstack/msg11678.html

As much as I'd prefer some consistency here, since most other projects
are well-triaged, it's difficult to argue the system is broken for them
and needs to be fixed...

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Openstack Baremetal Provisioning

2012-07-02 Thread Trinath Somanchi

Hi-

Please help me in understanding and bringing up this kind of setup

Kindly please help me in this regard.

I have checked nova.conf and found bare metal provisioning support options.

Please help me understand on how modifying nova.conf with the respective
options can help bringing up tilera like machines up either from command
line or from GUI.

Thanks in advance..

--
Trinath S

On Mon, Jul 2, 2012 at 12:13 PM, Trinath Somanchi 
trinath.soman...@gmail.com wrote:

 Hi-

 As explained in the email, With respect to the link,

 http://wiki.openstack.org/GeneralBareMetalProvisioningFramework

 Can you kindly guide/brief me on
 https://github.com/usc-isi/essex-baremetal-support (Stable/Essex)

 I mean Install/Config/Testing of the Provisioning support.

 Thanking you,

 --
 Regards,
 --
 Trinath Somanchi,
 +91 9866 235 130




-- 
Regards,
--
Trinath Somanchi,
+91 9866 235 130
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] PEP8 checks

On 07/02/2012 06:46 AM, John Garbutt wrote:
 Hi,
 
 I noticed I can now run the pep8 tests like this (taken from Jenkins job):
   tox -v -epep8
   ...
   pep8: commands succeeded
   congratulations :)
 
 But the old way to run tests seems to fail:
   ./run-tests.sh -p
   ...
   File 
 /home/johngar/openstack/nova/.venv/local/lib/python2.7/site-packages/pep8.py,
  line 1220, in check_logical
   for result in self.run_check(check, argument_names):
   TypeError: 'NoneType' object is not iterable
 
 Is this expected?
 Did I just miss an email about this change?

It's not really expected, and I honestly don't understand why
run_tests.sh -p would have problems running pep8. Although we do not use
run_tests.sh for anything in jenkins, we have not done anything to
disable or change what it's doing.

I'm looking at it right now, lemme see what's up.

Monty

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] RFC: Thoughts on improving OpenStack GIT commit practice/history



On 07/02/2012 05:14 AM, Daniel P. Berrange wrote:

 I must say that this has been driving me mad this last week. IIUC, only
 members of the core review team have permission to retrigger Jenkins,
 but I feel it is putting too much burden on them to have to track every
 patch with a bogus Jenkins failure. If we can't get Jenkins to be more
 reliable, then can we see about letting patch submitters retrigger
 Jenkins builds for their own patches.

There's a whole other thread about this at the moment, which outlines
the problems and what we're doing about it. One of the main issues
should be already solved. The primary goal is to get jenkins to be more
reliable so that hiccups don't happen in the first place.

In any case, if you want all the details, please see James Blair's
recent email to the Jenkins and Transient Failures thread.

Monty

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Jenkins and transient failures

On Sun, Jul 01, 2012 at 08:40:36AM -0700, James E. Blair wrote:
[snip]

 So with all that background, I think we should discuss the following at
 the CI team meeting on Tuesday:

[snip]

 3) Decide on a course of action to mitigate failures from transient
 gerrit errors (but continue to work on eliminating them in the first
 place).
 
 4) Decide how to implement retriggering with Zuul.

Can you expand on what you mean by this 4th point ? Is this a way to
allow individual patch submitters to re-trigger builds on their own
patches ?

IIUC, currently only core reviewers can directly retrigger builds. It
seems patch submitters are working around this restriction by simply
doing no-op rebases  re-uploading their patches again and again until
Jenkins passes.  If there's an easy way to allow re-triggering of failed
builds by any any reviewer, it seems that would mitigate the pain of
these failures, because we won't have to rely on a small pool of
people to notice bogus failures.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack][Nova] Issues with run_tests.sh, no tests are run when import libvirt is present



On 07/02/2012 06:02 AM, Leander Bessa Beernaert wrote:
 Thanks, that let me see the real problem now:
 
 ./tools/with_venv.sh nosetests -svx nova
 nose.config: INFO: Set working dir to /home/gsd/nova/nova/tests
 nose.config: INFO: Working directory /home/gsd/nova/nova/tests is a
 package; adding to sys.path
 nose.config: INFO: Ignoring files matching ['^\\.', '^_',
 '^setup\\.py$']
 nose.plugins.cover: INFO: Coverage report will include only
 packages: ['nova']
 nose.selector: INFO: /home/gsd/nova/nova/auth/opendj.sh is
 executable; skipped
 nose.selector: INFO: /home/gsd/nova/nova/auth/slap.sh is executable;
 skipped
 nose.selector: INFO:
 /home/gsd/nova/nova/cloudpipe/bootscript.template is executable; skipped
 Failure: ImportError (No module named libvirt) ... ERROR
 ==
 ERROR: Failure: ImportError (No module named libvirt)
 --
 Traceback (most recent call last):
   File
 /home/gsd/nova/.venv/local/lib/python2.7/site-packages/nose/loader.py,
 line 390, in loadTestsFromName
 addr.filename, addr.module)
   File
 /home/gsd/nova/.venv/local/lib/python2.7/site-packages/nose/importer.py,
 line 39, in importFromPath
 return self.importFromDir(dir_path, fqname)
   File
 /home/gsd/nova/.venv/local/lib/python2.7/site-packages/nose/importer.py,
 line 86, in importFromDir
 mod = load_module(part_fqname, fh, filename, desc)
   File /home/gsd/nova/nova/test.py, line 41, in module
 from nova.tests import fake_flags
   File /home/gsd/nova/nova/tests/fake_flags.py, line 24, in module
 flags.DECLARE('compute_scheduler_driver', 'nova.scheduler.multi')
   File /home/gsd/nova/nova/flags.py, line 52, in DECLARE
 __import__(module_string, globals(), locals())
   File /home/gsd/nova/nova/scheduler/multi.py, line 27, in module
 from nova.scheduler import driver
   File /home/gsd/nova/nova/scheduler/driver.py, line 53, in module
 flags..DECLARE('libvirt_type', 'nova.virt.libvirt.connection')
   File /home/gsd/nova/nova/flags.py, line 52, in DECLARE
 __import__(module_string, globals(), locals())
   File /home/gsd/nova/nova/virt/libvirt/connection.py, line 73, in
 module
 from nova.virt.libvirt import diagnostics as libvirt_diagnostics
   File /home/gsd/nova/nova/virt/libvirt/diagnostics.py, line 75,
 in module
 import libvirt as virt
 ImportError: No module named libvirt
 --
 Ran 1 test in 0.002s
 FAILED (errors=1)
 
 
 Libvirt is present on my system, i can import it through the python
 interpreter from any location. Yet, it still says it is not present.
 Could this have to do with the virtual_env or fakelibvirt?

Yes. Our virtualenvs are currently configured to not allow system
packages to be used (so that they only use python libs installed into
the virtualenv. However, libvirt is not installable via pip, which is a
problem.

We've recently added a new tox environment to help with this, so try
running:

tox -v -efull

Which is set up to allow system site packages.

However, if you're adding unittests, you should look at the other ones
which test for libvirt existence and skip the tests if they can't find it.

 On Fri, Jun 29, 2012 at 6:54 PM, Jay Pipes jaypi...@gmail.com
 mailto:jaypi...@gmail.com wrote:
 
 Hi Leander,
 
 I've noticed some weirdness with the openstack.nose_plugin (which is
 used by default for the Nova test runner) sometimes either throwing
 errors (particularly errors raised by nosetests) away and/or coming
 up with a different set of skip tests than when running just with
 nosetests.
 
 So, I'd recommend running just this:
 
 ./tools/with_venv.sh nosetests -svx nova
 
 That will stop at the first error and probably will give you better
 insight into the actual errors that are likely being suppressed by
 the openstack nose plugin.
 
 best,
 -jay
 
 
 On 06/29/2012 09:02 AM, Leander Bessa Beernaert wrote:
 
 Hello,
 
 I'm sorry to restart the topic
 (https://lists.launchpad.net/__openstack/msg13621.html
 https://lists.launchpad.net/openstack/msg13621.html), but
 i accidentally deleted the message in my inbox :S.
 
 I'm still having the same problem, each time i add import
 libvirt to
 the file diangostics.py
 (https://review.openstack.org/__#/c/8839/
 https://review.openstack.org/#/c/8839/) the
 entire test suit won't run.
 
 *With the import* present i get the following output:
 
 
  
 
 --__--__--
 Ran 0 tests

Re: [Openstack] PEP8 checks



On 07/02/2012 06:46 AM, John Garbutt wrote:
 Hi,
 
 I noticed I can now run the pep8 tests like this (taken from Jenkins job):
   tox -v -epep8
   ...
   pep8: commands succeeded
   congratulations :)
 
 But the old way to run tests seems to fail:
   ./run-tests.sh -p
   ...
   File 
 /home/johngar/openstack/nova/.venv/local/lib/python2.7/site-packages/pep8.py,
  line 1220, in check_logical
   for result in self.run_check(check, argument_names):
   TypeError: 'NoneType' object is not iterable
 
 Is this expected?
 Did I just miss an email about this change?

I cannot reproduce this on my system. Can you run
bash -x run_tests.sh -p and pastebin the output? Also,
tools/with_venv.sh pep8 --version just to be sure.

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Heterogeneous hardware support

On 07/02/2012 01:23 AM, balaji patnala wrote:
 Hi,
  
 Does open stack [Essex] release support Heterogeneous hardware for
 creating VMs with Security Applications?
 If not, what is the road map for this. Please let me know.

Could you please elaborate on what you mean by creating VMs with
security applications?

Thanks,
-jay

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] multi_host not working

I have managed to get this working by changing the default gateway on 
the guest to the compute node it is running on.


ubuntu@monitor:~$ sudo route del default gw 10.10.11.129
ubuntu@monitor:~$ sudo route add default gw 10.10.11.112

But the default gateway is assigned by DHCP - so how can I change the 
default gateway that nova-network assigns on each compute node?


Tx
M

On 02/07/2012 13:50, Marnus van Niekerk wrote:
Hi.  I am trying to use multi_host to eliminate the controller hosts 
as a single point of failure.


I followed the steps at 
http://docs.openstack.org/essex/openstack-compute/admin/content/existing-ha-networking-options.html 
and added thse options to the end of nova.conf. Now the guests have no 
connectivity to the outside world at all. (Running on ubuntu 12.04 
using packages.)


Controller:
--multi_host=True
--enabled_apis=ec2,osapi_compute,osapi_volume,metadata

Compute nodes:
--multi_host=True
--enabled_apis=metadata

I also tried changing the routing_source_ip option on each compute 
node to it's own ip address but it makes no difference.

--routing_source_ip=10.10.20.11X

What am I missing?

Tx
Marnus van Niekerk



___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack][Nova] Issues with run_tests.sh, no tests are run when import libvirt is present

So, if no system packages can be imported, how do you test the connection
class for the libvirt driver?

How does that particular test case wrap around the fact that it requires
the libvirt module? The only thing i could find are these lines of code in
the driver's __init__ method. Do these somehow detect if this is a unit
test environment and import the fakelibvirt driver instead? I'm no expert
in python so i'm not sure what's happening there :s

 global libvirt
 if libvirt is None:
 libvirt = __import__('libvirt')


Regards,
Leander

On Mon, Jul 2, 2012 at 1:27 PM, Monty Taylor mord...@inaugust.com wrote:



 On 07/02/2012 06:02 AM, Leander Bessa Beernaert wrote:
  Thanks, that let me see the real problem now:
 
  ./tools/with_venv.sh nosetests -svx nova
  nose.config: INFO: Set working dir to /home/gsd/nova/nova/tests
  nose.config: INFO: Working directory /home/gsd/nova/nova/tests is a
  package; adding to sys.path
  nose.config: INFO: Ignoring files matching ['^\\.', '^_',
  '^setup\\.py$']
  nose.plugins.cover: INFO: Coverage report will include only
  packages: ['nova']
  nose.selector: INFO: /home/gsd/nova/nova/auth/opendj.sh is
  executable; skipped
  nose.selector: INFO: /home/gsd/nova/nova/auth/slap.sh is executable;
  skipped
  nose.selector: INFO:
  /home/gsd/nova/nova/cloudpipe/bootscript.template is executable;
 skipped
  Failure: ImportError (No module named libvirt) ... ERROR
 
 ==
  ERROR: Failure: ImportError (No module named libvirt)
 
 --
  Traceback (most recent call last):
File
 
 /home/gsd/nova/.venv/local/lib/python2.7/site-packages/nose/loader.py,
  line 390, in loadTestsFromName
  addr.filename, addr.module)
File
 
 /home/gsd/nova/.venv/local/lib/python2.7/site-packages/nose/importer.py,
  line 39, in importFromPath
  return self.importFromDir(dir_path, fqname)
File
 
 /home/gsd/nova/.venv/local/lib/python2.7/site-packages/nose/importer.py,
  line 86, in importFromDir
  mod = load_module(part_fqname, fh, filename, desc)
File /home/gsd/nova/nova/test.py, line 41, in module
  from nova.tests import fake_flags
File /home/gsd/nova/nova/tests/fake_flags.py, line 24, in
 module
  flags.DECLARE('compute_scheduler_driver', 'nova.scheduler.multi')
File /home/gsd/nova/nova/flags.py, line 52, in DECLARE
  __import__(module_string, globals(), locals())
File /home/gsd/nova/nova/scheduler/multi.py, line 27, in module
  from nova.scheduler import driver
File /home/gsd/nova/nova/scheduler/driver.py, line 53, in
 module
  flags..DECLARE('libvirt_type', 'nova.virt.libvirt.connection')
File /home/gsd/nova/nova/flags.py, line 52, in DECLARE
  __import__(module_string, globals(), locals())
File /home/gsd/nova/nova/virt/libvirt/connection.py, line 73, in
  module
  from nova.virt.libvirt import diagnostics as libvirt_diagnostics
File /home/gsd/nova/nova/virt/libvirt/diagnostics.py, line 75,
  in module
  import libvirt as virt
  ImportError: No module named libvirt
 
 --
  Ran 1 test in 0.002s
  FAILED (errors=1)
 
 
  Libvirt is present on my system, i can import it through the python
  interpreter from any location. Yet, it still says it is not present.
  Could this have to do with the virtual_env or fakelibvirt?

 Yes. Our virtualenvs are currently configured to not allow system
 packages to be used (so that they only use python libs installed into
 the virtualenv. However, libvirt is not installable via pip, which is a
 problem.

 We've recently added a new tox environment to help with this, so try
 running:

 tox -v -efull

 Which is set up to allow system site packages.

 However, if you're adding unittests, you should look at the other ones
 which test for libvirt existence and skip the tests if they can't find it.

  On Fri, Jun 29, 2012 at 6:54 PM, Jay Pipes jaypi...@gmail.com
  mailto:jaypi...@gmail.com wrote:
 
  Hi Leander,
 
  I've noticed some weirdness with the openstack.nose_plugin (which is
  used by default for the Nova test runner) sometimes either throwing
  errors (particularly errors raised by nosetests) away and/or coming
  up with a different set of skip tests than when running just with
  nosetests.
 
  So, I'd recommend running just this:
 
  ./tools/with_venv.sh nosetests -svx nova
 
  That will stop at the first error and probably will give you better
  insight into the actual errors that are likely being suppressed by
  the openstack nose plugin.
 
  best,
  -jay
 
 
  On 06/29/2012 09:02 AM, Leander Bessa Beernaert wrote:
 
  Hello,

Re: [Openstack] [OpenStack][Nova] Issues with run_tests.sh, no tests are run when import libvirt is present



On 07/02/2012 08:43 AM, Leander Bessa Beernaert wrote:
 So, if no system packages can be imported, how do you test the
 connection class for the libvirt driver? 

We're working on that - but as I said, please try running tox -efull
which _should_ run tests with libvirt support enabled.

 How does that particular test case wrap around the fact that it requires
 the libvirt module? The only thing i could find are these lines of code
 in the driver's __init__ method. Do these somehow detect if this is a
 unit test environment and import the fakelibvirt driver instead? I'm no
 expert in python so i'm not sure what's happening there :s
 
 global libvirt
 if libvirt is None:
 libvirt = __import__('libvirt')
 
 
 Regards,
 Leander 
 
 On Mon, Jul 2, 2012 at 1:27 PM, Monty Taylor mord...@inaugust.com
 mailto:mord...@inaugust.com wrote:
 
 
 
 On 07/02/2012 06:02 AM, Leander Bessa Beernaert wrote:
  Thanks, that let me see the real problem now:
 
  ./tools/with_venv.sh nosetests -svx nova
  nose.config: INFO: Set working dir to /home/gsd/nova/nova/tests
  nose.config: INFO: Working directory /home/gsd/nova/nova/tests
 is a
  package; adding to sys.path
  nose.config: INFO: Ignoring files matching ['^\\.', '^_',
  '^setup\\.py$']
  nose.plugins.cover: INFO: Coverage report will include only
  packages: ['nova']
  nose.selector: INFO: /home/gsd/nova/nova/auth/opendj.sh is
  executable; skipped
  nose.selector: INFO: /home/gsd/nova/nova/auth/slap.sh is
 executable;
  skipped
  nose.selector: INFO:
  /home/gsd/nova/nova/cloudpipe/bootscript.template is
 executable; skipped
  Failure: ImportError (No module named libvirt) ... ERROR
 
 ==
  ERROR: Failure: ImportError (No module named libvirt)
 
 --
  Traceback (most recent call last):
File
 
 /home/gsd/nova/.venv/local/lib/python2.7/site-packages/nose/loader.py,
  line 390, in loadTestsFromName
  addr.filename, addr.module)
File
 
 /home/gsd/nova/.venv/local/lib/python2.7/site-packages/nose/importer.py,
  line 39, in importFromPath
  return self.importFromDir(dir_path, fqname)
File
 
 /home/gsd/nova/.venv/local/lib/python2.7/site-packages/nose/importer.py,
  line 86, in importFromDir
  mod = load_module(part_fqname, fh, filename, desc)
File /home/gsd/nova/nova/test.py, line 41, in module
  from nova.tests import fake_flags
File /home/gsd/nova/nova/tests/fake_flags.py, line 24, in
 module
  flags.DECLARE('compute_scheduler_driver',
 'nova.scheduler.multi')
File /home/gsd/nova/nova/flags.py, line 52, in DECLARE
  __import__(module_string, globals(), locals())
File /home/gsd/nova/nova/scheduler/multi.py, line 27, in
 module
  from nova.scheduler import driver
File /home/gsd/nova/nova/scheduler/driver.py, line 53, in
 module
  flags..DECLARE('libvirt_type', 'nova.virt.libvirt.connection')
File /home/gsd/nova/nova/flags.py, line 52, in DECLARE
  __import__(module_string, globals(), locals())
File /home/gsd/nova/nova/virt/libvirt/connection.py, line
 73, in
  module
  from nova.virt.libvirt import diagnostics as
 libvirt_diagnostics
File /home/gsd/nova/nova/virt/libvirt/diagnostics.py, line 75,
  in module
  import libvirt as virt
  ImportError: No module named libvirt
 
 --
  Ran 1 test in 0.002s
  FAILED (errors=1)
 
 
  Libvirt is present on my system, i can import it through the python
  interpreter from any location. Yet, it still says it is not present.
  Could this have to do with the virtual_env or fakelibvirt?
 
 Yes. Our virtualenvs are currently configured to not allow system
 packages to be used (so that they only use python libs installed into
 the virtualenv. However, libvirt is not installable via pip, which is a
 problem.
 
 We've recently added a new tox environment to help with this, so try
 running:
 
 tox -v -efull
 
 Which is set up to allow system site packages.
 
 However, if you're adding unittests, you should look at the other ones
 which test for libvirt existence and skip the tests if they can't
 find it.
 
  On Fri, Jun 29, 2012 at 6:54 PM, Jay Pipes jaypi...@gmail.com
 mailto:jaypi...@gmail.com
  mailto:jaypi...@gmail.com mailto:jaypi...@gmail.com wrote:
 
  Hi Leander,

Re: [Openstack] PEP8 checks

2012-07-02 Thread John Garbutt

I had pep8 v1.2 in my virtual env from this:
https://github.com/openstack/nova/commit/2fa2cd2254a4044aaa584c4fcf5d6c3e1ec60d1f#tools/test-requires

Rebased with trunk and re-creating my virtualenv (i.e. move back to pep8 v1.1) 
seemed to fix things.

Thanks for your help,
John

 -Original Message-
 From: Monty Taylor [mailto:mord...@inaugust.com]
 Sent: 02 July 2012 1:28
 To: John Garbutt
 Cc: openstack@lists.launchpad.net
 Subject: Re: [Openstack] PEP8 checks
 
 
 
 On 07/02/2012 06:46 AM, John Garbutt wrote:
  Hi,
 
  I noticed I can now run the pep8 tests like this (taken from Jenkins job):
  tox -v -epep8
  ...
  pep8: commands succeeded
  congratulations :)
 
  But the old way to run tests seems to fail:
  ./run-tests.sh -p
  ...
  File
 /home/johngar/openstack/nova/.venv/local/lib/python2.7/site-
 packages/pep8.py, line 1220, in check_logical
  for result in self.run_check(check, argument_names):
  TypeError: 'NoneType' object is not iterable
 
  Is this expected?
  Did I just miss an email about this change?
 
 I cannot reproduce this on my system. Can you run bash -x run_tests.sh -p
 and pastebin the output? Also, tools/with_venv.sh pep8 --version just to be
 sure.

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] PEP8 checks

Awesome.

On 07/02/2012 08:46 AM, John Garbutt wrote:
 I had pep8 v1.2 in my virtual env from this:
 https://github.com/openstack/nova/commit/2fa2cd2254a4044aaa584c4fcf5d6c3e1ec60d1f#tools/test-requires
 
 Rebased with trunk and re-creating my virtualenv (i.e. move back to pep8 
 v1..1) seemed to fix things.
 
 Thanks for your help,
 John
 
 -Original Message-
 From: Monty Taylor [mailto:mord...@inaugust.com]
 Sent: 02 July 2012 1:28
 To: John Garbutt
 Cc: openstack@lists.launchpad.net
 Subject: Re: [Openstack] PEP8 checks



 On 07/02/2012 06:46 AM, John Garbutt wrote:
 Hi,

 I noticed I can now run the pep8 tests like this (taken from Jenkins job):
 tox -v -epep8
 ...
 pep8: commands succeeded
 congratulations :)

 But the old way to run tests seems to fail:
 ./run-tests.sh -p
 ...
 File
 /home/johngar/openstack/nova/.venv/local/lib/python2.7/site-
 packages/pep8.py, line 1220, in check_logical
 for result in self.run_check(check, argument_names):
 TypeError: 'NoneType' object is not iterable

 Is this expected?
 Did I just miss an email about this change?

 I cannot reproduce this on my system. Can you run bash -x run_tests.sh -p
 and pastebin the output? Also, tools/with_venv.sh pep8 --version just to be
 sure.
 


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] CY12-Q2 Community Analysis — OpenStack vs OpenNebula vs Eucalyptus vs CloudStack

2012-07-02 Thread Mandar Vaze / मंदार वझे

On 07/02/2012 05:00 AM, Thierry Carrez wrote:
 Qingye Jiang (John) wrote:
 I would like to let you know that I have just finished an analysis on
 the 4 open source projects (OpenStack, OpenNebula, Eucalyptus,
 CloudStack) from a community activity perspective. The analysis report
 could be found from my personal blog at http://www.qyjohn.net/?p=2233
 (with a lot of figures).
 
 Nice work!
 
 However I still think it's a bit difficult/unfair to compare raw email
 numbers like this... For example, the cloudstack-dev mailing-list is
 used for patches and receives automated emails from review requests
 and comments on reviews.apache.org, whereas the openstack ML (and I
 suspect the other projects as well) only use lists for discussions, and
 use other tools for patches and reviews.
 
 So in the end it's interesting to look at trends within a given project
 and on a given setup, but not so much to compare between projects with
 very different setups.

Jiang, I agree with Thierry that your report is a great start and that
it would be useful to exclude from the cloudstack-dev mailing list patch
and review request emails. Those numbers significantly skew the analysis
from a mailing list threads/mails/users sense.

One other thing I'd mention is that although you focus on the marketing
and community-focused impacts in your conclusion for why certain
projects have seemed to gain traction versus others, I would add that
the choice of underlying technology -- and likewise the project
contributor's choice to be agnostic or ideological regarding certain
infrastructure pieces -- may be just as big a contributing factor to the
growth of the developer community of each project.

Keep up the great work,
-jay

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Openstack Baremetal Provisioning


 Please help me understand on how modifying nova.conf with the respective
 options can help bringing up tilera like machines up either from command
 line or from GUI.


http://wiki.openstack.org/HeterogeneousTileraSupport  Seems to have a lot
of information.


 http://wiki.openstack.org/GeneralBareMetalProvisioningFramework


This seems work in progress and may not be completely done.  One for Essex
is also prototype

-Mandar
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack][Nova] Issues with run_tests.sh, no tests are run when import libvirt is present

I'm developing on custom branch and haven't updated the repository for at
least 3 weeks.
Do i fetch the lastest changes like this:

 git remote update
 git checkout master
 git pull origin master

git checkout branch

git pull master

?

On Mon, Jul 2, 2012 at 1:44 PM, Monty Taylor mord...@inaugust.com wrote:



 On 07/02/2012 08:43 AM, Leander Bessa Beernaert wrote:
  So, if no system packages can be imported, how do you test the
  connection class for the libvirt driver?

 We're working on that - but as I said, please try running tox -efull
 which _should_ run tests with libvirt support enabled.

  How does that particular test case wrap around the fact that it requires
  the libvirt module? The only thing i could find are these lines of code
  in the driver's __init__ method. Do these somehow detect if this is a
  unit test environment and import the fakelibvirt driver instead? I'm no
  expert in python so i'm not sure what's happening there :s
 
  global libvirt
  if libvirt is None:
  libvirt = __import__('libvirt')
 
 
  Regards,
  Leander
 
  On Mon, Jul 2, 2012 at 1:27 PM, Monty Taylor mord...@inaugust.com
  mailto:mord...@inaugust.com wrote:
 
 
 
  On 07/02/2012 06:02 AM, Leander Bessa Beernaert wrote:
   Thanks, that let me see the real problem now:
  
   ./tools/with_venv.sh nosetests -svx nova
   nose.config: INFO: Set working dir to /home/gsd/nova/nova/tests
   nose.config: INFO: Working directory /home/gsd/nova/nova/tests
  is a
   package; adding to sys.path
   nose.config: INFO: Ignoring files matching ['^\\.', '^_',
   '^setup\\.py$']
   nose.plugins.cover: INFO: Coverage report will include only
   packages: ['nova']
   nose.selector: INFO: /home/gsd/nova/nova/auth/opendj.sh is
   executable; skipped
   nose.selector: INFO: /home/gsd/nova/nova/auth/slap.sh is
  executable;
   skipped
   nose.selector: INFO:
   /home/gsd/nova/nova/cloudpipe/bootscript.template is
  executable; skipped
   Failure: ImportError (No module named libvirt) ... ERROR
  
 
 ==
   ERROR: Failure: ImportError (No module named libvirt)
  
 
 --
   Traceback (most recent call last):
 File
  
 
 /home/gsd/nova/.venv/local/lib/python2.7/site-packages/nose/loader.py,
   line 390, in loadTestsFromName
   addr.filename, addr.module)
 File
  
 
 /home/gsd/nova/.venv/local/lib/python2.7/site-packages/nose/importer.py,
   line 39, in importFromPath
   return self.importFromDir(dir_path, fqname)
 File
  
 
 /home/gsd/nova/.venv/local/lib/python2.7/site-packages/nose/importer.py,
   line 86, in importFromDir
   mod = load_module(part_fqname, fh, filename, desc)
 File /home/gsd/nova/nova/test.py, line 41, in module
   from nova.tests import fake_flags
 File /home/gsd/nova/nova/tests/fake_flags.py, line 24, in
  module
   flags.DECLARE('compute_scheduler_driver',
  'nova.scheduler.multi')
 File /home/gsd/nova/nova/flags.py, line 52, in DECLARE
   __import__(module_string, globals(), locals())
 File /home/gsd/nova/nova/scheduler/multi.py, line 27, in
  module
   from nova.scheduler import driver
 File /home/gsd/nova/nova/scheduler/driver.py, line 53, in
  module
   flags..DECLARE('libvirt_type',
 'nova.virt.libvirt.connection')
 File /home/gsd/nova/nova/flags.py, line 52, in DECLARE
   __import__(module_string, globals(), locals())
 File /home/gsd/nova/nova/virt/libvirt/connection.py, line
  73, in
   module
   from nova.virt.libvirt import diagnostics as
  libvirt_diagnostics
 File /home/gsd/nova/nova/virt/libvirt/diagnostics.py, line
 75,
   in module
   import libvirt as virt
   ImportError: No module named libvirt
  
 
 --
   Ran 1 test in 0.002s
   FAILED (errors=1)
  
  
   Libvirt is present on my system, i can import it through the python
   interpreter from any location. Yet, it still says it is not
 present.
   Could this have to do with the virtual_env or fakelibvirt?
 
  Yes. Our virtualenvs are currently configured to not allow system
  packages to be used (so that they only use python libs installed into
  the virtualenv. However, libvirt is not installable via pip, which
 is a
  problem.
 
  We've recently added a new tox environment to help with this, so try
  running:
 
  tox -v -efull
 
  Which is set up to allow

Re: [Openstack] [OpenStack][Nova] Issues with run_tests.sh, no tests are run when import libvirt is present

On 07/02/2012 08:57 AM, Leander Bessa Beernaert wrote:
 I'm developing on custom branch and haven't updated the repository for
 at least 3 weeks. 
 Do i fetch the lastest changes like this:
 
 git remote update
 git checkout master
 git pull origin master
 
 git checkout branch 
 
 git pull master

Remember to git stash your current working changes first...

# Ensure you are in your local working git branch
# (not your local master)

git stash --all
git checkout master
git pull
git checkout $WORKINGBRANCH
git rebase master
git stash pop

and then handle any merge conflicts that may pop up.

Best,
-jay


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack][Nova] Issues with run_tests.sh, no tests are run when import libvirt is present

@Jay Thx.

@Monty I'm unable to run tox -efull, it keeps saying the command could
not be located. I'm supposed to run this from the same place i run
run_tests.sh right?

On Mon, Jul 2, 2012 at 2:08 PM, Jay Pipes jaypi...@gmail.com wrote:

 On 07/02/2012 08:57 AM, Leander Bessa Beernaert wrote:
  I'm developing on custom branch and haven't updated the repository for
  at least 3 weeks.
  Do i fetch the lastest changes like this:
 
  git remote update
  git checkout master
  git pull origin master
 
  git checkout branch
 
  git pull master

 Remember to git stash your current working changes first...

 # Ensure you are in your local working git branch
 # (not your local master)

 git stash --all
 git checkout master
 git pull
 git checkout $WORKINGBRANCH
 git rebase master
 git stash pop

 and then handle any merge conflicts that may pop up.

 Best,
 -jay


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] help me with the xenapi test

2012-07-02 Thread Yong Sheng Gong

 hi,In my change at https://review.openstack.org/#/c/8916/, some xenapi tests alway fail:nova.tests.test_xenapi.XenAPIMigrateInstance.test_finish_migrateLoading...10 sec1nova.tests.test_xenapi.XenAPIMigrateInstance.test_finish_migrate_no_local_storageLoading...10 sec1nova.tests.test_xenapi.XenAPIMigrateInstance.test_finish_migrate_no_resize_vdiLoading...10 sec1nova.tests.test_xenapi.XenAPIMigrateInstance.test_revert_migrate Who can help me find the reason?ThanksYong Sheng Gong

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] multi_host not working

2012-07-02 Thread Nathanael Burton

This is actually what multi_host should be doing when enabled.  What
node is that original gateway address from?  Is that a different
compute node?

Nate

On Mon, Jul 2, 2012 at 8:41 AM, Marnus van Niekerk m...@mjvn.net wrote:
 I have managed to get this working by changing the default gateway on the
 guest to the compute node it is running on.

 ubuntu@monitor:~$ sudo route del default gw 10.10.11.129
 ubuntu@monitor:~$ sudo route add default gw 10.10.11.112

 But the default gateway is assigned by DHCP - so how can I change the
 default gateway that nova-network assigns on each compute node?

 Tx
 M


 On 02/07/2012 13:50, Marnus van Niekerk wrote:

 Hi.  I am trying to use multi_host to eliminate the controller hosts as a
 single point of failure.

 I followed the steps at
 http://docs.openstack.org/essex/openstack-compute/admin/content/existing-ha-networking-options.html
 and added thse options to the end of nova.conf. Now the guests have no
 connectivity to the outside world at all. (Running on ubuntu 12.04 using
 packages.)

 Controller:
 --multi_host=True
 --enabled_apis=ec2,osapi_compute,osapi_volume,metadata

 Compute nodes:
 --multi_host=True
 --enabled_apis=metadata

 I also tried changing the routing_source_ip option on each compute node to
 it's own ip address but it makes no difference.
 --routing_source_ip=10.10.20.11X

 What am I missing?

 Tx
 Marnus van Niekerk




 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Openstack and Google Compute Engine

2012-07-02 Thread Simon G.

Noone tested or noone is interested in Google Compute Engine and Openstack?

On Sat, Jun 30, 2012 at 9:59 PM, Simon G. semy...@gmail.com wrote:

 Hello,

 I've heard about Google's cloud recently. What do you think about it? Will
 it be compatible with openstack? Or will openstack be compatible with them?
 Anyone knows something about their solution? it's purely their technology?
 Or maybe they were inspired by openstack or something else.

 What about scalability? Their test app is really impressive - 600.000
 cores. Is it even achievable in openstack? How can I create environment
 with so many cores, in openstack?

 I'm waiting for my invitation to google compute, but maybe someone has
 already tested it.

 Cheers,




-- 
*Semy*
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack][Nova] Issues with run_tests.sh, no tests are run when import libvirt is present

On Mon, Jul 02, 2012 at 01:43:31PM +0100, Leander Bessa Beernaert wrote:
 So, if no system packages can be imported, how do you test the connection
 class for the libvirt driver?
 
 How does that particular test case wrap around the fact that it requires
 the libvirt module? The only thing i could find are these lines of code in
 the driver's __init__ method. Do these somehow detect if this is a unit
 test environment and import the fakelibvirt driver instead? I'm no expert
 in python so i'm not sure what's happening there :s
 
  global libvirt
  if libvirt is None:
  libvirt = __import__('libvirt')

If you have installed all the neccessary python packages on your
local host, then it is entirely possible to run the Nova test
suites without using virtualenv. You just need to pass the '-N'
arg to the run_tests.sh script, eg on my Fedora 17 host, I can
run

   ./run_tests.sh -N nova.tests.test_libvirt

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] [CHEF] Clarification on osops/chef-repo/roles/nova-compute.rb

Hi Ron, cc'ing the openstack ML for extra eyes and opinions...

So, Nati and I are looking to use either the osops chef-repo or
something similar as the basis of the new TryStack zone chef deployment.
I've been going through the recipes and roles and I have a question on
the nova-compute *role*:

https://github.com/osops/chef-repo/blob/master/roles/nova-compute.rb

I'm wondering why the nova-api recipe is in the runlist for nova-compute?

In addition, I was wondering if y'all had considered making more use of
roles instead of recipes to allow most of the attribute assignment and
variation to be in the combination of roles assigned to a host, instead
of recipes combined in a role?

For example, right now, there is a nova-controller role that looks
like this:

name nova-controller
description Nova controller node (vncproxy + rabbit)
run_list(
  role[base],
  recipe[nova::controller]
)

Because most of the special sauce is in the nova::controller recipe, I
have to go into that recipe to see what the role is composed of:

include_recipe mysql::server
include_recipe openssh::default

include_recipe rabbitmq::default
include_recipe keystone::server
include_recipe glance::registry
include_recipe glance::api
include_recipe nova::nova-setup
include_recipe nova::scheduler
include_recipe nova::api

if platform?(%w{fedora})
  # Fedora skipping vncproxy for right now
else
  include_recipe nova::vncproxy
end

But what this recipe really is is an opinionated description of a
controller role. If the role was, instead, structured like so:

name nova-controller
description Nova Controller - All major API services and control
servers like MySQL and Rabbit
run_list(
  role[base],
  recipe[mysql::server],
  recipe[openssh::default],
  recipe[rabbitmq::default],
  recipe[keystone::server],
  recipe[glance::api],
  recipe[glance::registry],
  recipe[nova::scheduler],
  recipe[nova::api],
)

Then the deployer can more easily switch up the way they deploy
OpenStack servers by merely changing the role -- say, removing the
Rabbit service and putting it somewhere else -- WITHOUT having to modify
a recipe in a Git submodule in the upstream cookbooks.

Furthermore, if we broke out more roles -- such as control-services
which might be MySQL and Rabbit only -- than we could make the super
roles ,like the nova-controller role above, more of a put this and
that role together, like so:

name nova-controller
description Nova Controller - All major API services and control
servers like MySQL and Rabbit
run_list(
  role[base],
  role[control_services],
  recipe[keystone::server],
  recipe[glance::api],
  recipe[glance::registry],
  recipe[nova::scheduler],
  recipe[nova::api],
)

Finally, I've noticed that there are aren't any HA options in the osops
recipes -- specifically around MySQL. Are there plans to do so? We use
heartbeat/Pacemaker/DRBD in the original TryStack cookbooks [1] and
environments to get simple HA solutions up and would love to see those
in the upstream.

Thanks and all the best guys,
-jay

[1]
https://github.com/trystack/openstack-chef/tree/stable/diablo/cookbooks/heartbeat

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack][Nova] Issues with run_tests.sh, no tests are run when import libvirt is present

Running with  ./run_tests.sh -N nova.tests.test_libvirt works just fine,
however i don't know if this is enough to get it past jenkins :/

On Mon, Jul 2, 2012 at 3:26 PM, Daniel P. Berrange berra...@redhat.comwrote:

 On Mon, Jul 02, 2012 at 01:43:31PM +0100, Leander Bessa Beernaert wrote:
  So, if no system packages can be imported, how do you test the
 connection
  class for the libvirt driver?
 
  How does that particular test case wrap around the fact that it requires
  the libvirt module? The only thing i could find are these lines of code
 in
  the driver's __init__ method. Do these somehow detect if this is a unit
  test environment and import the fakelibvirt driver instead? I'm no expert
  in python so i'm not sure what's happening there :s
 
   global libvirt
   if libvirt is None:
   libvirt = __import__('libvirt')

 If you have installed all the neccessary python packages on your
 local host, then it is entirely possible to run the Nova test
 suites without using virtualenv. You just need to pass the '-N'
 arg to the run_tests.sh script, eg on my Fedora 17 host, I can
 run

./run_tests.sh -N nova.tests.test_libvirt

 Regards,
 Daniel
 --
 |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/:|
 |: http://libvirt.org  -o- http://virt-manager.org:|
 |: http://autobuild.org   -o- http://search.cpan.org/~danberr/:|
 |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc:|

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] compute_rpcapi ?

2012-07-02 Thread Russell Bryant

On 06/29/2012 12:19 PM, Day, Phil wrote:
 Hi Russell,
 
 I tried to look at the README-versioned-rpc-apis.rst  referenced in some of 
 the mail archives between you and Vish, but it gives a 404.  Can you point me 
 to the current copy please ?

All of the content that was in that README has either turned into code
in the tree or code comments.  I would take a look at these files and
then look at examples of where they are used.

https://github.com/openstack/nova/blob/master/nova/openstack/common/rpc/dispatcher.py

https://github.com/openstack/nova/blob/master/nova/openstack/common/rpc/proxy.py

Here is one of the simpler conversions:

https://github.com/openstack/nova/commit/f50ce35c9cf2e05d205485586da1cb6d5433ba56

-- 
Russell Bryant



___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] multi_host not working

2012-07-02 Thread Razique Mahroua

Hi Marnus,I've put a small section herehttp://docs.openstack.org/diablo/openstack-compute/admin/content/multi-host.htmlI'm thinking about the routing_source_ip configuration option into your nova.conf files
Nuage  Co - Razique Mahrouarazique.mahr...@gmail.com

Le 2 juil. 2012 à 14:41, Marnus van Niekerk a écrit :
  

  
  
I have managed to get this
  working by changing the default gateway on the guest to the
  compute node it is running on.

ubuntu@monitor:~$ sudo route del default gw 10.10.11.129
ubuntu@monitor:~$ sudo route add default gw 10.10.11.112

But the default gateway is assigned by DHCP - so how can I change
the default gateway that nova-network assigns on each compute node?

Tx
M

On 02/07/2012 13:50, Marnus van Niekerk
  wrote:

Hi. I
  am trying to use multi_host to eliminate the "controller" hosts as
  a single point of failure.
  
  
  I followed the steps at
  http://docs.openstack.org/essex/openstack-compute/admin/content/existing-ha-networking-options.html
  and added thse options to the end of nova.conf. Now the guests
  have no connectivity to the outside world at all. (Running on
  ubuntu 12.04 using packages.)
  
  
  Controller:
  
  --multi_host=True
  
  --enabled_apis=ec2,osapi_compute,osapi_volume,metadata
  
  
  Compute nodes:
  
  --multi_host=True
  
  --enabled_apis=metadata
  
  
  I also tried changing the routing_source_ip option on each compute
  node to it's own ip address but it makes no difference.
  
  --routing_source_ip=10.10.20.11X
  
  
  What am I missing?
  
  
  Tx
  
  Marnus van Niekerk
  



  

___Mailing list: https://launchpad.net/~openstackPost to : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore help : https://help.launchpad.net/ListHelp___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] [Docs] new DocImpact notifier flag

2012-07-02 Thread Anne Gentle

Hi all -

Greetings from sunny-with-intermittent-thunderstorms Ohio! I wanted to
let you all know of a new way to integrate docs with the development
process - the DocImpact flag. Thanks to the CI team's diligence, you
can now add DocImpact to your commit messages, anywhere in the
message, and changes with DocImpact in their commit messages
automatically send an email to the openstack-doc-core team with a link
to the review site as soon as the patch set is pushed to Gerrit.

I'd like you to use this flag in these cases:
1. You're pushing a commit with documentation contained in the patch set.
2. You're pushing a commit with a new option or change in the default
option or default behavior.
3. You're pushing a commit with a new feature that requires
documentation. Ideally you'll work with the doc team to figure out a
doc plan.

Sending a commit with this flag doesn't guarantee doc will be written
- but it does enable us to prioritize the incoming changes. Generally,
I don't want this flag to be used to throw a doc task over a wall,
there are no walls here, we're all in this together. :)

Thanks CI team (Clark Boylan especially) for the assist.

Anne

P.S. I'm on vacation this week - but I will add this flag usage to the
HACKING file when I get back (unless someone wants to beat me to it.)
:)

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] multi_host not working



On 02/07/2012 16:33, Razique Mahroua wrote:

I've put a small section here
http://docs.openstack.org/diablo/openstack-compute/admin/content/multi-host.html


If I read this right then it is saying that nova-api should not run on 
every compute node, only nova-network and nova-compute.

Is that right?

Tx
M

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] multi_host not working



On 02/07/2012 16:14, Nathanael Burton wrote:

This is actually what multi_host should be doing when enabled.  What
node is that original gateway address from?  Is that a different
compute node?


Yes, its is the br100 ip of the controller node which is also a compute 
node.


M

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] multi_host not working

2012-07-02 Thread Nathanael Burton

Are the nova.conf files identical across all the nodes?
On Jul 2, 2012 10:47 AM, Marnus van Niekerk m...@mjvn.net wrote:


 On 02/07/2012 16:14, Nathanael Burton wrote:

 This is actually what multi_host should be doing when enabled.  What
 node is that original gateway address from?  Is that a different
 compute node?


 Yes, its is the br100 ip of the controller node which is also a compute
 node.

 M

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] multi_host not working


They are identical except for these options:
--vncserver_proxyclient_address=10.10.20.11X
--vncserver_listen=10.10.20.11X
--routing_source_ip=10.10.20.11X

The ip that gets issues as gateway is the one in this option
--flat_network_dhcp_start=10.10.11.129

The network range for the flat network and the underlying network on the 
2nd NIC is the same 10.10.11.0/24.  Not sure if this should be this way 
or if it is better for the flat network with a different range.


Each of the nodes have two NICs:
eth0 - 10.10.20.11X - public
eth3 - 10.10.11.11X - private - bridged to br100 and assigned 
10.10.11.129 on the controller node
They also have eth1 and eth2 bonded into bond0 with IP 10.10.12.11X, but 
that is not used by OpenStack at all.


Tx
M

On 02/07/2012 17:02, Nathanael Burton wrote:


Are the nova.conf files identical across all the nodes?

On Jul 2, 2012 10:47 AM, Marnus van Niekerk m...@mjvn.net 
mailto:m...@mjvn.net wrote:



On 02/07/2012 16:14, Nathanael Burton wrote:

This is actually what multi_host should be doing when enabled.
 What
node is that original gateway address from?  Is that a different
compute node?


Yes, its is the br100 ip of the controller node which is also a
compute node.

M





___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] How do I stop image-create from using /tmp?

2012-07-02 Thread Johannes Erdfelt

On Mon, Jul 02, 2012, Daniel P. Berrange berra...@redhat.com wrote:
 In Fedora 18, /tmp is going to be a RAM filesystem, so we absolutely
 must not create any sizeable files on /tmp.
 
 In addition from a security POV, we must aim to *never* use /tmp for
 anything at all
 
   http://danwalsh.livejournal.com/11467.html

I take exception to that. Saying *never* is incorrect.

You (and that blog post) say that we should *never* use /tmp for
security reasons, but don't go on to explain why using mkstemp or
mkdtemp is a security problem.

Even the glibc documentation says they are safe wrt to security issues:

http://www.gnu.org/software/libc/manual/html_node/Temporary-Files.html

 It would be good to do a thorough audit of the code to make sure
 nothing is using the tmpfile functions without explicitly specifying
 a directory path that is private to the OpenStack daemon in question.

Not using /tmp for large files is a good reason for practical reasons
(distributions moving to ramfs for /tmp).

But please don't start throwing around warnings that all uses of /tmp
are a security risk without backing that up.

JE


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack][Nova] Issues with run_tests.sh, no tests are run when import libvirt is present

Run:

  sudo pip install tox

And you will get the tox command.

Does ./run_tests.sh -N nova.tests.test_libvirt work fine when you
_don't_ have libvirt? It needs to skip the test if you don't have
libvirt installed, and it needs to run it and pass if you do.

Jenkins is going to run tox -v -epy27 and then eventually also tox -v
-efull - so make sure both of those work and you'll be set.

Monty

On 07/02/2012 10:30 AM, Leander Bessa Beernaert wrote:
 Running with  ./run_tests.sh -N nova.tests.test_libvirt works just
 fine, however i don't know if this is enough to get it past jenkins :/
 
 On Mon, Jul 2, 2012 at 3:26 PM, Daniel P. Berrange berra...@redhat.com
 mailto:berra...@redhat.com wrote:
 
 On Mon, Jul 02, 2012 at 01:43:31PM +0100, Leander Bessa Beernaert wrote:
  So, if no system packages can be imported, how do you test the
 connection
  class for the libvirt driver?
 
  How does that particular test case wrap around the fact that it
 requires
  the libvirt module? The only thing i could find are these lines of
 code in
  the driver's __init__ method. Do these somehow detect if this is a
 unit
  test environment and import the fakelibvirt driver instead? I'm no
 expert
  in python so i'm not sure what's happening there :s
 
   global libvirt
   if libvirt is None:
   libvirt = __import__('libvirt')
 
 If you have installed all the neccessary python packages on your
 local host, then it is entirely possible to run the Nova test
 suites without using virtualenv. You just need to pass the '-N'
 arg to the run_tests.sh script, eg on my Fedora 17 host, I can
 run
 
./run_tests.sh -N nova.tests.test_libvirt
 
 Regards,
 Daniel
 --
 |: http://berrange.com  -o-  
  http://www.flickr.com/photos/dberrange/ :|
 |: http://libvirt.org  -o-
 http://virt-manager.org :|
 |: http://autobuild.org   -o-
 http://search.cpan.org/~danberr/ :|
 |: http://entangle-photo.org   -o-  
 http://live.gnome.org/gtk-vnc :|
 
 


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Openstack Baremetal Provisioning

2012-07-02 Thread John Paul Walters

Hi Trinath,

Our baremetal experts are on vacation for the next week or so, so I'll take a
stab at answering in their absence. First, just to be clear, right now the
baremetal work that's present in Essex supports ONLY the Tilera architecture.
We're working with the NTT folks to add additional support, but it's not in
Essex. We've tested on TILEmpower rack-mountable units. You'll need a
baremetal proxy (x86) machine that will run nova-compute and handle the
provisioning of resources. Most of the nova.conf options are shown at:

http://docs.openstack.org/essex/openstack-compute/admin/content/compute-options-reference.html

But it appears that there's at least one omission: you'll need to set your
--connection_type=baremetal on the proxy node. Probably the most important
options are: --baremetal_driver=tilera,
--tile_monitor=/path/to/tile-monitor/. I would suggest that you have a look
at the link above under the baremetal section to see what other options might
apply to your environment.

http://wiki.openstack.org/HeterogeneousTileraSupport

Note that you'll need to set up tftp so that the Tilera boards can pick up a
boot rom. You'll also need to create a tilera-specific file system.

I hope this helps.

best,
JP

On Jul 2, 2012, at 8:05 AM, Trinath Somanchi wrote:

Hi-

Please help me in understanding and bringing up this kind of setup

Kindly please help me in this regard.

I have checked nova.conf and found bare metal provisioning support options.

Please help me understand on how modifying nova.conf with the respective
options can help bringing up tilera like machines up either from command line
or from GUI.

Thanks in advance..

--
Trinath S

On Mon, Jul 2, 2012 at 12:13 PM, Trinath Somanchi
trinath.soman...@gmail.com wrote:
Hi-

As explained in the email, With respect to the link,

http://wiki.openstack.org/GeneralBareMetalProvisioningFramework

Can you kindly guide/brief me on
https://github.com/usc-isi/essex-baremetal-support (Stable/Essex)

I mean Install/Config/Testing of the Provisioning support.

Thanking you,

--
Regards,
--
Trinath Somanchi,
+91 9866 235 130

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

Re: [Openstack] need help about jenkins

2012-07-02 Thread heut2008

jenkins still can't work correctly. I have recommit more than once.any
one who can help check out what wrong with jenkins ? here is  my
commit   https://review.openstack.org/#/c/9201/.

2012/7/2 heut2008 heut2...@gmail.com:
 push another patch ,jenkins still can't pass through my commit .

 2012/7/2 Monty Taylor mord...@inaugust.com:
 Hi!

 We were doing some maintenance this afternoon on jenkins and gerrit -
 you were unlucky enough to push right in the middle of that.

 Try amending your commit (git commit --amend) and change the commit
 message a little (put a space after the comma here:
 lp:1019348,update and then run git review again. This will cause a new
 changeset to be uploaded and will re-trigger tests.

 Monty


 On 07/01/2012 01:30 PM, heut2008 wrote:
 Hi,all

 recently,I made a commit push to gerrit ,see
 https://review.openstack.org/#/c/9204/. jenkins always show failed
 ,how can I figure out what's wrong with my commit,or some thing wrong
 with jenkins? thanks in advance:)

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp



 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OpenStack][Nova] Issues with run_tests.sh, no tests are run when import libvirt is present

I have never tested it on a machine which doesn't have libvirt, i'll get
back to you on that.

I've ran tox -v -epy27 and it produced this ouput

 --
 Ran 0 tests in 0.001s
 OK
 _
 summary
 _
   py27: commands succeeded
   congratulations :)


and this is the output produced by tox -v -efull:

--
 Ran 3046 tests in 217.842s
 OK (SKIP=5)
 Exception KeyError: KeyError(25433840,) in module 'threading' from
 '/usr/lib/python2.7/threading.pyc' ignored
 _
 summary
 _
   full: commands succeeded
   congratulations :)


I think the problem still remains :S

On Mon, Jul 2, 2012 at 4:48 PM, Monty Taylor mord...@inaugust.com wrote:

 Run:

   sudo pip install tox

 And you will get the tox command.

 Does ./run_tests.sh -N nova.tests.test_libvirt work fine when you
 _don't_ have libvirt? It needs to skip the test if you don't have
 libvirt installed, and it needs to run it and pass if you do.

 Jenkins is going to run tox -v -epy27 and then eventually also tox -v
 -efull - so make sure both of those work and you'll be set.

 Monty

 On 07/02/2012 10:30 AM, Leander Bessa Beernaert wrote:
  Running with  ./run_tests.sh -N nova.tests.test_libvirt works just
  fine, however i don't know if this is enough to get it past jenkins :/
 
  On Mon, Jul 2, 2012 at 3:26 PM, Daniel P. Berrange berra...@redhat.com
  mailto:berra...@redhat.com wrote:
 
  On Mon, Jul 02, 2012 at 01:43:31PM +0100, Leander Bessa Beernaert
 wrote:
   So, if no system packages can be imported, how do you test the
  connection
   class for the libvirt driver?
  
   How does that particular test case wrap around the fact that it
  requires
   the libvirt module? The only thing i could find are these lines of
  code in
   the driver's __init__ method. Do these somehow detect if this is a
  unit
   test environment and import the fakelibvirt driver instead? I'm no
  expert
   in python so i'm not sure what's happening there :s
  
global libvirt
if libvirt is None:
libvirt = __import__('libvirt')
 
  If you have installed all the neccessary python packages on your
  local host, then it is entirely possible to run the Nova test
  suites without using virtualenv. You just need to pass the '-N'
  arg to the run_tests.sh script, eg on my Fedora 17 host, I can
  run
 
 ./run_tests.sh -N nova.tests.test_libvirt
 
  Regards,
  Daniel
  --
  |: http://berrange.com  -o-
   http://www.flickr.com/photos/dberrange/ :|
  |: http://libvirt.org  -o-
  http://virt-manager.org :|
  |: http://autobuild.org   -o-
  http://search.cpan.org/~danberr/ :|
  |: http://entangle-photo.org   -o-
  http://live.gnome.org/gtk-vnc :|
 
 


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Hashing image files

2012-07-02 Thread Alexey Ababilov

Hi, Michael!

I am curious to know: is it necessary for nova to save images in file which
names are sha1 hashes from image IDs (UUIDs)?

Nova saves root image under its sha1 hash:
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/connection.py#L1214
but it saves kernel and ramdisk under their original IDs:
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/connection.py#L1199
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/connection.py#L1206

Is it a security measure?


-- 
Alessio Ababilov
Software Engineer
Grid Dynamics




-- 
Alessio Ababilov
Software Engineer
Grid Dynamics
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Openstack Baremetal Provisioning

2012-07-02 Thread Trinath Somanchi

Hi-

Thanks a lot for the reply JP.

The information provided is of most value for me.

I have a doubt here.

I will install Nova-compute in a server say Essex-1 and another server say
Essex-2.

I have a tilera board too in the setup.

Can you please guide me on how to start this tilera board using
Nova-compute in Essex-1 machine. and How Nova-compute in Essex-2 can be
made as Proxy-Nova-compute. I mean what changes to Nova-compute makes Proxy
nova-compute.

On Mon, Jul 2, 2012 at 9:32 PM, John Paul Walters jwalt...@isi.edu wrote:

Hi Trinath,

Our baremetal experts are on vacation for the next week or so, so I'll
take a stab at answering in their absence. First, just to be clear, right
now the baremetal work that's present in Essex supports ONLY the Tilera
architecture. We're working with the NTT folks to add additional support,
but it's not in Essex. We've tested on TILEmpower rack-mountable units.
You'll need a baremetal proxy (x86) machine that will run nova-compute and
handle the provisioning of resources. Most of the nova.conf options are
shown at:

http://docs.openstack.org/essex/openstack-compute/admin/content/compute-options-reference.html

But it appears that there's at least one omission: you'll need to set
your --connection_type=baremetal on the proxy node. Probably the most
important options are: --baremetal_driver=tilera,
--tile_monitor=/path/to/tile-monitor/. I would suggest that you have a
look at the link above under the baremetal section to see what other
options might apply to your environment.

http://wiki.openstack.org/HeterogeneousTileraSupport

Note that you'll need to set up tftp so that the Tilera boards can pick up
a boot rom. You'll also need to create a tilera-specific file system.

I hope this helps.

best,
JP

On Jul 2, 2012, at 8:05 AM, Trinath Somanchi wrote:

Hi-

Please help me in understanding and bringing up this kind of setup

Kindly please help me in this regard.

I have checked nova.conf and found bare metal provisioning support options.

Please help me understand on how modifying nova.conf with the respective
options can help bringing up tilera like machines up either from command
line or from GUI.

Thanks in advance..

--
Trinath S

On Mon, Jul 2, 2012 at 12:13 PM, Trinath Somanchi
trinath.soman...@gmail.com wrote:

Hi-

As explained in the email, With respect to the link,

http://wiki.openstack.org/GeneralBareMetalProvisioningFramework

Can you kindly guide/brief me on
https://github.com/usc-isi/essex-baremetal-support (Stable/Essex)

I mean Install/Config/Testing of the Provisioning support.

Thanking you,

--
Regards,
--
Trinath Somanchi,
+91 9866 235 130

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

--
Regards,
--
Trinath Somanchi,
+91 9866 235 130
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

Re: [Openstack] Openstack and Google Compute Engine

2012-07-02 Thread Matt Joyce

Semy,

  Google app engine and google compute engine are two different things.
App engine has been around for quite some time.  The compute engine that
they offer as an IaaS solution is based off internal google software that
has also been in use internally for a lengthy amount of time.

   Honestly, most people expected google to enter into the IaaS market much
earlier than this.


Noone tested or noone is interested in Google Compute Engine and Openstack?


I believe most of us are simply interested in ensuring an API compatibility
layer will exist.  But as per planning that is not currently within the
confines of the OpenStack project, but is rather left to the openstack
distribution vendors.  I think that eventually a standard method for
abstracting the various IaaS API layers will arise.

Usability functions are also interesting.  Certainly compute engine
provides a different approach to the user experience in IaaS from what has
been the de facto standard in amazon.  That's interesting as well.

 I've heard about Google's cloud recently. What do you think about it? Will
 it be compatible with openstack? Or will openstack be compatible with them?
 Anyone knows something about their solution? it's purely their technology?
 Or maybe they were inspired by openstack or something else.

 It is purely their technology.  It likely pre-dates openstack.  Eventually
an API compatibility layer will exist.  I am certain that several
organizations are likely working on this as we speak.   As stated earlier
that is not something the OpenStack project has a hand in at the moment.

 What about scalability? Their test app is really impressive - 600.000
 cores. Is it even achievable in openstack? How can I create environment
 with so many cores, in openstack?

 I don't believe anyone has ever approached that number of course in a
single deployment.  I have no doubt that openstack could scale to those
numbers.  However a 600,000 core environment is akin to a 50,000 physical
node deployment of 2 cpu 6 core units.  That is a colossal sum of
hardware.  Very few organizations have that many physical nodes, much less
dedicated to a single IaaS environment.

 I'm waiting for my invitation to google compute, but maybe someone has
 already tested it.

 There are several reviews online already as well as reference
documentation on the offering.

-Matt


-- 
 *Semy*



 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] How do I stop image-create from using /tmp?

2012-07-02 Thread Matt Joyce

I like the idea of making this a flagfile option.

On Mon, Jul 2, 2012 at 2:48 AM, Daniel P. Berrange berra...@redhat.comwrote:

 On Sat, Jun 30, 2012 at 09:25:10PM -0400, Lars Kellogg-Stedman wrote:
   So, maybe setting any of this environment variables for nova-compute
   to desired value sholuld help.
 
  Yeah, I was expecting that.
 
  Given that this could easily take out a compute host I'd like to see
  it get an explicit configuration value (or default to instance_dir, I
  guess).

 In Fedora 18, /tmp is going to be a RAM filesystem, so we absolutely
 must not create any sizeable files on /tmp.

 In addition from a security POV, we must aim to *never* use /tmp for
 anything at all

   http://danwalsh.livejournal.com/11467.html

 It would be good to do a thorough audit of the code to make sure
 nothing is using the tmpfile functions without explicitly specifying
 a directory path that is private to the OpenStack daemon in question.

 Regards,
 Daniel
 --
 |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/:|
 |: http://libvirt.org  -o- http://virt-manager.org:|
 |: http://autobuild.org   -o- http://search.cpan.org/~danberr/:|
 |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc:|

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Openstack and Google Compute Engine

On 07/02/2012 10:25 AM, Simon G. wrote:
 Noone tested or noone is interested in Google Compute Engine and Openstack?

No, I think it's just that nobody has looked into it yet. Also, when you
say their test app is 600,000 cores, I don't think you have any
providers of OpenStack that (yet) have anywhere near that level of cores
to provide to an application... Google has the ability to utilize its
existing hardware infrastructure of hundreds of thousands (millions?) of
servers.

Trying to compare OpenStack to Google's Compute Engine is silly IMHO.
You really should be comparing GCE with grid computing engines and HPC
solutions, not cloud computing operator software like OpenStack.

The two are very different.

Best,
-jay

 On Sat, Jun 30, 2012 at 9:59 PM, Simon G. semy...@gmail.com
 mailto:semy...@gmail.com wrote:
 
 Hello,
 
 I've heard about Google's cloud recently. What do you think about
 it? Will it be compatible with openstack? Or will openstack be
 compatible with them? Anyone knows something about their solution?
 it's purely their technology? Or maybe they were inspired by
 openstack or something else.
 
 What about scalability? Their test app is really impressive -
 600.000 cores. Is it even achievable in openstack? How can I create
 environment with so many cores, in openstack?
 
 I'm waiting for my invitation to google compute, but maybe someone
 has already tested it.
 
 Cheers,
 
 
 
 
 -- 
 /Semy/
 
 
 
 
 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp
 


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Openstack and Google Compute Engine

2012-07-02 Thread Joshua Harlow

I'd be interested in hearing any comparisons, but it seems like it just came 
out so it might take a while...

Knowing how google is very secretive about there internal 'architecture' it 
might be really hard to make any in-depth comparisons.

On 7/2/12 7:25 AM, Simon G. semy...@gmail.com wrote:

Noone tested or noone is interested in Google Compute Engine and Openstack?

On Sat, Jun 30, 2012 at 9:59 PM, Simon G. semy...@gmail.com wrote:

Hello,

I've heard about Google's cloud recently. What do you think about it? Will it 
be compatible with openstack? Or will openstack be compatible with them? Anyone 
knows something about their solution? it's purely their technology? Or maybe 
they were inspired by openstack or something else.

What about scalability? Their test app is really impressive - 600.000 cores. Is 
it even achievable in openstack? How can I create environment with so many 
cores, in openstack?

I'm waiting for my invitation to google compute, but maybe someone has already 
tested it.

Cheers,


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Nova Pacemaker Resource Agents

2012-07-02 Thread Sébastien Han

Hi everyone,

For those of you who want to achieve HA in nova. I wrote some resource
agents according to the OCF specification. The RAs available are:

   - nova-scheduler
   - nova-api
   - novnc
   - nova-consoleauth
   - nova-cert

The how-to is available here:
http://www.sebastien-han.fr/blog/2012/07/02/openstack-nova-components-ha/ and
the RAs on my Github https://github.com/leseb/OpenStack-ra

Those RAs mainly re-use the structure of the resource agent written by
Martin Gerhard Loschwitz from Hastexo.

Hope it helps!

Cheers.

~Seb
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] How do I stop image-create from using /tmp?

On Mon, Jul 02, 2012 at 10:24:02AM -0700, Matt Joyce wrote:
 I like the idea of making this a flagfile option.

In the particular case of the qemu-img command described
in earlier in this thread, I'm not convinced we need a
new option. Instead of using /tmp when extracting a snapshot
from an existing disk image, it could just use the path
where the source image already resides. ie the existing
FLAGS.instances_path directory, which can be assumed to
be a suitably large persistent data store.

Other uses of temporary files should be analysed ona case
by case basis to figure out a suitable storage location.
This might perhaps identify a need for a generic temp
file location for nova, such as /var/run/nova/ or
/var/cache/nova or both (depending on use case).

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] help me with the xenapi test

2012-07-02 Thread Salvatore Orlando

Hi Yong,

I do not see any obvious reason for these failures, especially as they
appear to occur when the vdi is created. If I recall it correctly, that
code is stubbed out for unit tests, and it does not seem your patch
un-stubs it.
Do you see the failures also on your dev machine?

Salvatore

On 2 July 2012 14:30, Yong Sheng Gong gong...@cn.ibm.com wrote:

 hi,

 In my change at https://review.openstack.org/#/c/8916/, some xenapi tests
 alway fail:
  
 nova.tests.test_xenapi.XenAPIMigrateInstance.test_finish_migratehttps://jenkins.openstack.org/job/gate-nova-python26/1386/testReport/nova.tests.test_xenapi/XenAPIMigrateInstance/test_finish_migrate/

 Loading...
 10 sec1 https://jenkins.openstack.org/job/gate-nova-python26/1386/

 nova.tests.test_xenapi.XenAPIMigrateInstance.test_finish_migrate_no_local_storagehttps://jenkins.openstack.org/job/gate-nova-python26/1386/testReport/nova.tests.test_xenapi/XenAPIMigrateInstance/test_finish_migrate_no_local_storage/

 Loading...
 10 sec1 https://jenkins.openstack.org/job/gate-nova-python26/1386/

 nova.tests.test_xenapi.XenAPIMigrateInstance.test_finish_migrate_no_resize_vdihttps://jenkins.openstack.org/job/gate-nova-python26/1386/testReport/nova.tests.test_xenapi/XenAPIMigrateInstance/test_finish_migrate_no_resize_vdi/

 Loading...
 10 sec1 https://jenkins.openstack.org/job/gate-nova-python26/1386/
  
 nova.tests.test_xenapi.XenAPIMigrateInstance.test_revert_migratehttps://jenkins.openstack.org/job/gate-nova-python26/1386/testReport/nova.tests.test_xenapi/XenAPIMigrateInstance/test_revert_migrate/

 Who can help me find the reason?
 Thanks
 Yong Sheng Gong

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Heterogeneous hardware support

On 07/02/2012 12:09 PM, balaji patnala wrote:
 Hi Jay,
 
 As you know that L2 and L3 services could be the next step of offering
 as Services from Cloud providers. Security Applications like
 WAF,IPS,Firewall,VPN etc can be offered as services. These security
 applications can be run in VMs on Heterogeneous hardware like Freescale
 and any other platforms.

I'm not sure if heterogeneous hardware supported is specifically related
to security, but ...

 Open Stack must support for the Heterogeneous hardware to enable
 different hardware platforms apart from x86.

There's nothing about OpenStack, in general, that is specific to x86
hardware. It's Python, so if the Linux distribution of your preference
runs on some other hardware architecture, have at it. The images you
deploy will need to be tailored to the hardware architecture, of course,
but that isn't the realm of what OpenStack services do -- that's up to
the deployer.

 Please share with us if you have any examples of similar deployments in
 Clouds.

ISI is the group most actively working on heterogeneous architecture
support, but I don't believe they are focusing on security-related
things at all.

Best,
-jay

 On Mon, Jul 2, 2012 at 5:59 PM, Jay Pipes jaypi...@gmail.com
 mailto:jaypi...@gmail.com wrote:
 
 On 07/02/2012 01:23 AM, balaji patnala wrote:
  Hi,
 
  Does open stack [Essex] release support Heterogeneous hardware for
  creating VMs with Security Applications?
  If not, what is the road map for this. Please let me know.
 
 Could you please elaborate on what you mean by creating VMs with
 security applications?
 
 Thanks,
 -jay
 
 ___
 Mailing list: https://launchpad.net/~openstack
 https://launchpad.net/%7Eopenstack
 Post to : openstack@lists.launchpad.net
 mailto:openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 https://launchpad.net/%7Eopenstack
 More help   : https://help.launchpad.net/ListHelp
 
 


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] How do I stop image-create from using /tmp?

On Mon, Jul 02, 2012 at 08:17:08AM -0700, Johannes Erdfelt wrote:
 On Mon, Jul 02, 2012, Daniel P. Berrange berra...@redhat.com wrote:
  In Fedora 18, /tmp is going to be a RAM filesystem, so we absolutely
  must not create any sizeable files on /tmp.
  
  In addition from a security POV, we must aim to *never* use /tmp for
  anything at all
  
http://danwalsh.livejournal.com/11467.html
 
 I take exception to that. Saying *never* is incorrect.
 
 You (and that blog post) say that we should *never* use /tmp for
 security reasons, but don't go on to explain why using mkstemp or
 mkdtemp is a security problem.
 
 Even the glibc documentation says they are safe wrt to security issues:
 
 http://www.gnu.org/software/libc/manual/html_node/Temporary-Files.html

NB, I never said that mkstemp/mkdtemp are unsafe. I that that
in general usage of /tmp is a bad idea. It is possible to use
/tmp safely, but historical security records across the entire
software industry shows that developers routinely screw up with
their use of /tmp. Since /tmp is a globally accessible directory,
the consequences of such screw ups can be very severe. The globally
writable nature of /tmp also makes it hard for mandatory access
control systems like SELinux / AppArmour to ensure that a daemon's
temporary files are protected against these screw ups.

As the blog post says, /tmp is a reasonable place for end users
to have temporary files. Daemons needing somewhat to create
their own private temporary files should use a private directory
location accessible only to themslves, so that in the event of
a screw up the damage is mor elimit limited. There are very few
compelling reasons why something like Nova should ever need to
use a globally writable directory for its temp files / directories.

  It would be good to do a thorough audit of the code to make sure
  nothing is using the tmpfile functions without explicitly specifying
  a directory path that is private to the OpenStack daemon in question.
 
 Not using /tmp for large files is a good reason for practical reasons
 (distributions moving to ramfs for /tmp).
 
 But please don't start throwing around warnings that all uses of /tmp
 are a security risk without backing that up.

I stand by my point that in general usage of /tmp is a risk because
for every experianced developer who can get things right, there are
hordes of others who get it wrong  eventually one such bug will
slip through the review net. Since there are rarely compelling reasons
for the use of /tmp, avoiding it by default is a good defensive choice.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] How do I stop image-create from using /tmp?

2012-07-02 Thread Johannes Erdfelt

On Mon, Jul 02, 2012, Daniel P. Berrange berra...@redhat.com wrote:
 On Mon, Jul 02, 2012 at 08:17:08AM -0700, Johannes Erdfelt wrote:
  Not using /tmp for large files is a good reason for practical reasons
  (distributions moving to ramfs for /tmp).
  
  But please don't start throwing around warnings that all uses of /tmp
  are a security risk without backing that up.
 
 I stand by my point that in general usage of /tmp is a risk because
 for every experianced developer who can get things right, there are
 hordes of others who get it wrong  eventually one such bug will
 slip through the review net. Since there are rarely compelling reasons
 for the use of /tmp, avoiding it by default is a good defensive choice.

So your argument isn't that using /tmp is inherently insecure, it's that
using something not shared is safer?

It seems to me that we're just as likely to have a review slip through
that uses /tmp insecurely as a review slipping through that uses /tmp at
all.

Ultimately, the most compelling reason for using /tmp is that it's easy,
it's standard and developers have been trained to use it for a long
time.

There is no well-defined alternative, either in LSB or in practice (or
in either that blog post or your email).

Since we can't trust developers to use /tmp securely, or avoid using
/tmp at all, then why not use filesystem namespaces to setup a process
specific non-shared /tmp?

Nova never shares anything in /tmp (or at least shouldn't), so it should
be safe.

JE


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] best practices for merging common into specific projects

2012-07-02 Thread Andrew Bogott

Having spent some time last week writing code for openstack-common, 
and having spent yet more time trying to get those changes into Nova, I 
think it would be useful to define some best practices when crossing the 
boundary between common and other openstack projects.


Background:

The openstack-common project is subject to a standard code-review 
process (and, soon, will also have Jenkins testing gates.)  Sadly, 
patches that are merged into openstack-common are essentially orphans.  
Bringing those changes into actual use requires yet another step, a 
'merge from common' patch where the code changes in common are copied 
into a specific project (e.g. nova.)
Merge-from-common patches are generated via an automated process.  
Specific projects express dependencies on specific common components via 
a config file, e.g. 'nova/openstack-common.conf'.  The actual file copy 
is performed by 'openstack-common/update.py,' and its behavior is 
governed by the appropriate openstack-common.conf file.


Questions:

When should changes from common be merged into other projects?
What should a 'merge-from-common' patch look like?
What code-review standards should core committers observe when 
reviewing merge-from-common patches?


Proposals:

I.  As soon as a patch drops into common, the patch author should 
submit merge-from-common patches to all affected projects.
A.  (This should really be done by a bot, but that's not going to 
happen overnight)


II. In the event that I. is not observed, merge-from-common patches 
will contain bits from multiple precursor patches.  That is not only OK, 
but encouraged.

A.  Keeping projects in sync with common is important!
B.  Asking producers of merge-from-common patches to understand the 
full diff will discourage the generation of such merges.


III.Merge-from-common patches should be the product of a single 
unedited run of update.py.
A.  If a merge-from-common patch breaks pep8 or a test in nova, 
don't fix the patch; fix the code in common.


IV.Merge-from-common patches are 'presumed justified'.  That means:
A. Reviewers of merge-from-common patches should consider test 
failures and pep8 breakages, and obvious functional problems.
B. Reviewers of merge-from-common patches should not consider the 
usefulness, design, etc. of merge-from-common patches.  Such concerns 
need to be handled within the common review process.
C. Merges from common should get reviewed early and approved 
readily in order to avoid project divergence


V. Changes to openstack-common.conf are a special case.
A. Patches with openstack-common.conf changes should include the 
relevant merge-from-common changes.
B. Such patches should /not/ include any other merge-from-common 
changes.
C. Such patches should not only include the common merges, but 
should also include whatever code changes make use of the new merge.
D. Such patches require the same justification and scrutiny as any 
other standard project patch.


Please discuss!  If we're able to reach general agreement about this 
process, I will document the process in the openstack-common HACKING 
guidelines.


-Andrew




On 7/2/12 11:38 AM, Russell Bryant (Code Review) wrote:

I did that before seeing this patch.  However, I think I prefer what I pushed since it's 
individual updates explaining what they update instead of a blanket update 
everything commit.





___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Openstack Baremetal Provisioning

2012-07-02 Thread John Paul Walters

Hi Trinath,

It's not clear whether the tilera board you're referring to is one of the PCI
versions or a stand-alone board (is it in Essex-1?). We've never setup/tested
anything other than the TILEmpower stand-alone board with our bare-metal
provisioning service. That said, in order to make your nova-compute on
Essex-2, you need to configure nova.conf as I described earlier: set the
connection_type=baremetal, set the baremetal_driver=tilera, and set your path
to tile-monitor appropriately. That's what makes it a proxy node, which is
otherwise run as a regular nova-compute.

On Jul 2, 2012, at 12:42 PM, Trinath Somanchi wrote:

Hi-

Thanks a lot for the reply JP.

The information provided is of most value for me.

I have a doubt here.

I will install Nova-compute in a server say Essex-1 and another server say
Essex-2.

I have a tilera board too in the setup.

Can you please guide me on how to start this tilera board using Nova-compute
in Essex-1 machine. and How Nova-compute in Essex-2 can be made as
Proxy-Nova-compute. I mean what changes to Nova-compute makes Proxy
nova-compute.

On Mon, Jul 2, 2012 at 9:32 PM, John Paul Walters jwalt...@isi.edu wrote:
Hi Trinath,

http://docs.openstack.org/essex/openstack-compute/admin/content/compute-options-reference.html

But it appears that there's at least one omission: you'll need to set your
--connection_type=baremetal on the proxy node. Probably the most important
options are: --baremetal_driver=tilera,
--tile_monitor=/path/to/tile-monitor/. I would suggest that you have a
look at the link above under the baremetal section to see what other options
might apply to your environment.

http://wiki.openstack.org/HeterogeneousTileraSupport

Note that you'll need to set up tftp so that the Tilera boards can pick up a
boot rom. You'll also need to create a tilera-specific file system.

I hope this helps.

best,
JP

On Jul 2, 2012, at 8:05 AM, Trinath Somanchi wrote:

Hi-

Please help me in understanding and bringing up this kind of setup

Kindly please help me in this regard.

I have checked nova.conf and found bare metal provisioning support options.

Please help me understand on how modifying nova.conf with the respective
options can help bringing up tilera like machines up either from command
line or from GUI.

Thanks in advance..

--
Trinath S

On Mon, Jul 2, 2012 at 12:13 PM, Trinath Somanchi
trinath.soman...@gmail.com wrote:
Hi-

As explained in the email, With respect to the link,

http://wiki.openstack.org/GeneralBareMetalProvisioningFramework

Can you kindly guide/brief me on
https://github.com/usc-isi/essex-baremetal-support (Stable/Essex)

I mean Install/Config/Testing of the Provisioning support.

Thanking you,

--
Regards,
--
Trinath Somanchi,
+91 9866 235 130

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

--
Regards,
--
Trinath Somanchi,
+91 9866 235 130

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

Re: [Openstack] best practices for merging common into specific projects

2012-07-02 Thread Russell Bryant

On 07/02/2012 03:16 PM, Andrew Bogott wrote:
 Background:
 
 The openstack-common project is subject to a standard code-review
 process (and, soon, will also have Jenkins testing gates.)  Sadly,
 patches that are merged into openstack-common are essentially orphans. 
 Bringing those changes into actual use requires yet another step, a
 'merge from common' patch where the code changes in common are copied
 into a specific project (e.g. nova.)
 Merge-from-common patches are generated via an automated process. 
 Specific projects express dependencies on specific common components via
 a config file, e.g. 'nova/openstack-common.conf'.  The actual file copy
 is performed by 'openstack-common/update.py,' and its behavior is
 governed by the appropriate openstack-common.conf file.

More background:

http://wiki.openstack.org/CommonLibrary

 Questions:
 
 When should changes from common be merged into other projects?
 What should a 'merge-from-common' patch look like?
 What code-review standards should core committers observe when
 reviewing merge-from-common patches?
 
 Proposals:
 
 I.  As soon as a patch drops into common, the patch author should
 submit merge-from-common patches to all affected projects.
 A.  (This should really be done by a bot, but that's not going to
 happen overnight)

All of the APIs in openstack-common right now are considered to be in
incubation, meaning that breaking changes could be made.  I don't think
automated merges are good for anything in incubation.

Automation would be suitable for stable APIs.  Once an API is no longer
in incubation, we should be looking at how to make releases and treat it
as a proper library.  The copy/paste madness should be limited to APIs
still in incubation.

There are multiple APIs close or at the point where I think we should be
able to commit to them.  I'll leave the specifics for a separate
discussion, but I think moving on this front is key to reducing the pain
we are seeing with code copying.

 II. In the event that I. is not observed, merge-from-common patches
 will contain bits from multiple precursor patches.  That is not only OK,
 but encouraged.
 A.  Keeping projects in sync with common is important!
 B.  Asking producers of merge-from-common patches to understand the
 full diff will discourage the generation of such merges.

I don't see this as much different as any other patches to nova (or
whatever project is using common).  It should be a proper patch series.
 If the person pulling it in doesn't understand the merge well enough to
produce the patch series with proper commit messages, then they are the
wrong person to be doing the merge in the first place.

 III.Merge-from-common patches should be the product of a single
 unedited run of update.py.

Disagree, see above.

 A.  If a merge-from-common patch breaks pep8 or a test in nova,
 don't fix the patch; fix the code in common.

Agreed.

 IV.Merge-from-common patches are 'presumed justified'.  That means:
 A. Reviewers of merge-from-common patches should consider test
 failures and pep8 breakages, and obvious functional problems.
 B. Reviewers of merge-from-common patches should not consider the
 usefulness, design, etc. of merge-from-common patches.  Such concerns
 need to be handled within the common review process.
 C. Merges from common should get reviewed early and approved readily
 in order to avoid project divergence

I think core reviewers of projects using openstack-common are justified
in doing critical review of new code being used by their project.  A
core reviewer of nova for examp[le may have a very good reason why the
code is not suitable for consumption in nova that openstack-common
reviewers didn't think of.

I don't think blind approvals are ever a good idea.

 V. Changes to openstack-common.conf are a special case.
 A. Patches with openstack-common.conf changes should include the
 relevant merge-from-common changes.
 B. Such patches should /not/ include any other merge-from-common
 changes.
 C. Such patches should not only include the common merges, but
 should also include whatever code changes make use of the new merge.
 D. Such patches require the same justification and scrutiny as any
 other standard project patch.

This all seems fine to me.

 Please discuss!  If we're able to reach general agreement about this
 process, I will document the process in the openstack-common HACKING
 guidelines.


-- 
Russell Bryant



___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] How do I stop image-create from using /tmp?

2012-07-02 Thread Boris Filippov

2012/7/1 Lars Kellogg-Stedman l...@seas.harvard.edu:
 So, maybe setting any of this environment variables for nova-compute
 to desired value sholuld help.

 Yeah, I was expecting that.

 Given that this could easily take out a compute host I'd like to see
 it get an explicit configuration value (or default to instance_dir, I
 guess).

 If I can sort out the corporate contributor agreement stuff I may try
 to submit a patch...

 --
 Lars Kellogg-Stedman l...@seas.harvard.edu   |
 Senior Technologist| 
 http://ac.seas.harvard.edu/
 Academic Computing | 
 http://code.seas.harvard.edu/
 Harvard School of Engineering and Applied Sciences |


https://review.openstack.org/#/c/9239/

Wrote patch for it. We had same issue with our OpenStack installation
before and this behavior is quite surprise for people who believe that
nobody will store Big Files in /tmp.

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Openstack and Google Compute Engine

2012-07-02 Thread David Busby

I for one am waiting on my invite to be processed; then I will be looking
at things like aeolus to run hybird cloud setups (I'll be contributing code
to that effect);

That said remember google open compute (as far as I am aware) is not open
source i.e. you can not download the engine and run a private google open
compute cloud.

I am for example using openstack to run internal private clouds; with
multiple end hosting providers (hybird cloud); of which google will be one.

I think the thing to take away is google are a company with vast resources
and the ability to deploy datacentres on a whim (search for their shipping
container dc's); if you have that kind of budget then I cant see any reason
for a similar openstack sized deployment, also if you have that kind of
buget I'll take 2 dc's ... im not greedy ;-)
On Jun 30, 2012 9:05 PM, Simon G. semy...@gmail.com wrote:

 Hello,

 I've heard about Google's cloud recently. What do you think about it? Will
 it be compatible with openstack? Or will openstack be compatible with them?
 Anyone knows something about their solution? it's purely their technology?
 Or maybe they were inspired by openstack or something else.

 What about scalability? Their test app is really impressive - 600.000
 cores. Is it even achievable in openstack? How can I create environment
 with so many cores, in openstack?

 I'm waiting for my invitation to google compute, but maybe someone has
 already tested it.

 Cheers,

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [CHEF] Clarification on osops/chef-repo/roles/nova-compute.rb

2012-07-02 Thread Vishvananda Ishaya


On Jul 2, 2012, at 7:28 AM, Jay Pipes wrote:

 Hi Ron, cc'ing the openstack ML for extra eyes and opinions...
 
 So, Nati and I are looking to use either the osops chef-repo or
 something similar as the basis of the new TryStack zone chef deployment.
 I've been going through the recipes and roles and I have a question on
 the nova-compute *role*:
 
 https://github.com/osops/chef-repo/blob/master/roles/nova-compute.rb
 
 I'm wondering why the nova-api recipe is in the runlist for nova-compute?

Because metadata needs to run on the compute hosts in the default layout. This 
should
be switched to use nova-api-metadata instead of nova-api, but the split out 
hasn't been done yet.
 
 In addition, I was wondering if y'all had considered making more use of
 roles instead of recipes to allow most of the attribute assignment and
 variation to be in the combination of roles assigned to a host, instead
 of recipes combined in a role?
 
 For example, right now, there is a nova-controller role that looks
 like this:
 
 name nova-controller
 description Nova controller node (vncproxy + rabbit)
 run_list(
  role[base],
  recipe[nova::controller]
 )
 
 Because most of the special sauce is in the nova::controller recipe, I
 have to go into that recipe to see what the role is composed of:
 
 include_recipe mysql::server
 include_recipe openssh::default
 
 include_recipe rabbitmq::default
 include_recipe keystone::server
 include_recipe glance::registry
 include_recipe glance::api
 include_recipe nova::nova-setup
 include_recipe nova::scheduler
 include_recipe nova::api
 
 if platform?(%w{fedora})
  # Fedora skipping vncproxy for right now
 else
  include_recipe nova::vncproxy
 end
 
 But what this recipe really is is an opinionated description of a
 controller role. If the role was, instead, structured like so:
 
 name nova-controller
 description Nova Controller - All major API services and control
 servers like MySQL and Rabbit
 run_list(
  role[base],
  recipe[mysql::server],
  recipe[openssh::default],
  recipe[rabbitmq::default],
  recipe[keystone::server],
  recipe[glance::api],
  recipe[glance::registry],
  recipe[nova::scheduler],
  recipe[nova::api],
 )
 
 Then the deployer can more easily switch up the way they deploy
 OpenStack servers by merely changing the role -- say, removing the
 Rabbit service and putting it somewhere else -- WITHOUT having to modify
 a recipe in a Git submodule in the upstream cookbooks.
 
 Furthermore, if we broke out more roles -- such as control-services
 which might be MySQL and Rabbit only -- than we could make the super
 roles ,like the nova-controller role above, more of a put this and
 that role together, like so:
 
 name nova-controller
 description Nova Controller - All major API services and control
 servers like MySQL and Rabbit
 run_list(
  role[base],
  role[control_services],
  recipe[keystone::server],
  recipe[glance::api],
  recipe[glance::registry],
  recipe[nova::scheduler],
  recipe[nova::api],
 )

This all makes sense to me.  Ron?

 
 Finally, I've noticed that there are aren't any HA options in the osops
 recipes -- specifically around MySQL. Are there plans to do so? We use
 heartbeat/Pacemaker/DRBD in the original TryStack cookbooks [1] and
 environments to get simple HA solutions up and would love to see those
 in the upstream.
 
 Thanks and all the best guys,
 -jay
 
 [1]
 https://github.com/trystack/openstack-chef/tree/stable/diablo/cookbooks/heartbeat


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] need help about jenkins

2012-07-02 Thread Clark Boylan

There was a configuration error when creating the openstack-
common test jobs. They were added to zuul (the tool that tells
Jenkins when and what to test), but the test jobs were not properly
added to Jenkins. This has been corrected and the tests have been
run.

The failures you see for the latest patchset are real errors so you will
want to look at the test results. Once you have corrected these
errors your patch should get through Jenkins just fine.

Clark

On Mon, Jul 2, 2012 at 9:05 AM, heut2008 heut2...@gmail.com wrote:
 jenkins still can't work correctly. I have recommit more than once.any
 one who can help check out what wrong with jenkins ? here is  my
 commit   https://review.openstack.org/#/c/9201/.

 2012/7/2 heut2008 heut2...@gmail.com:
 push another patch ,jenkins still can't pass through my commit .

 2012/7/2 Monty Taylor mord...@inaugust.com:
 Hi!

 We were doing some maintenance this afternoon on jenkins and gerrit -
 you were unlucky enough to push right in the middle of that.

 Try amending your commit (git commit --amend) and change the commit
 message a little (put a space after the comma here:
 lp:1019348,update and then run git review again. This will cause a new
 changeset to be uploaded and will re-trigger tests.

 Monty


 On 07/01/2012 01:30 PM, heut2008 wrote:
 Hi,all

 recently,I made a commit push to gerrit ,see
 https://review.openstack.org/#/c/9204/. jenkins always show failed
 ,how can I figure out what's wrong with my commit,or some thing wrong
 with jenkins? thanks in advance:)

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp



 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] How do I stop image-create from using /tmp?

2012-07-02 Thread Nathanael Burton

I agree with Daniel for the qemu-img commands. For other temp file usage, I
know on Fedora/RHEL there's already /var/lib/nova/tmp which is used for
lock files, etc.

Nate
On Jul 2, 2012 4:29 PM, Daniel P. Berrange berra...@redhat.com wrote:

 On Mon, Jul 02, 2012 at 10:24:02AM -0700, Matt Joyce wrote:
  I like the idea of making this a flagfile option.

 In the particular case of the qemu-img command described
 in earlier in this thread, I'm not convinced we need a
 new option. Instead of using /tmp when extracting a snapshot
 from an existing disk image, it could just use the path
 where the source image already resides. ie the existing
 FLAGS.instances_path directory, which can be assumed to
 be a suitably large persistent data store.

 Other uses of temporary files should be analysed ona case
 by case basis to figure out a suitable storage location.
 This might perhaps identify a need for a generic temp
 file location for nova, such as /var/run/nova/ or
 /var/cache/nova or both (depending on use case).

 Regards,
 Daniel
 --
 |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/:|
 |: http://libvirt.org  -o- http://virt-manager.org:|
 |: http://autobuild.org   -o- http://search.cpan.org/~danberr/:|
 |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc:|

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] How do I stop image-create from using /tmp?

2012-07-02 Thread Boris Filippov

2012/7/2 Daniel P. Berrange berra...@redhat.com:
 On Mon, Jul 02, 2012 at 10:24:02AM -0700, Matt Joyce wrote:
 I like the idea of making this a flagfile option.

 In the particular case of the qemu-img command described
 in earlier in this thread, I'm not convinced we need a
 new option. Instead of using /tmp when extracting a snapshot
 from an existing disk image, it could just use the path
 where the source image already resides. ie the existing
 FLAGS.instances_path directory, which can be assumed to
 be a suitably large persistent data store.

 Other uses of temporary files should be analysed ona case
 by case basis to figure out a suitable storage location.
 This might perhaps identify a need for a generic temp
 file location for nova, such as /var/run/nova/ or
 /var/cache/nova or both (depending on use case).

 Regards,
 Daniel
 --
 |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
 |: http://libvirt.org  -o- http://virt-manager.org :|
 |: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
 |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

Sure, we can place snapshots inside instances_path. At least, just
separate them from instances and place them in
%instances_path%/snapshots.

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [metering] resource metadata changes and billing

2012-07-02 Thread Julien Danjou

On Fri, Jun 29 2012, Doug Hellmann wrote:

Hi Doug,

Sorry for the late reply.

 I don't think I've made the problem clear.

 I'm not talking about wanting to calculate the different usage for CPU,
 RAM, etc. The different counters are calculated separately, so we can keep
 the amounts for CPU and RAM completely separate, and the API allows the
 outside user to ask for the amounts for each counter for a resource (or
 globally for a user/project). The problem is in deciding how the metadata
 associated with a meter event might cause the provider to change the rate
 they want to charge for that usage.

It's not metadata of a counter that cause the provider to change the
rate. It's a meter of a resource that can do that.

 That only solves part of the problem, though. As a provider I may want to
 charge different flat rates for the amount of RAM being used. For example,
 1 unit for 1024 MB of RAM but 2 units for 4096 MB. That means when the size
 of the VM changes, we need to produce multiple totals (the length of time
 that the VM had 1024 MB RAM and then the length of time it had 4096 MB RAM).

Yeah, like I said, for the meter 'RAM' of resource 'instance' you can't
request a total amount used, because the type of this meter (I don't
know how to call it, it's the kind I named
if-i-change-you-need-to-split-the-resource-in-several-stuff in my latest
email) don't have this semantic.

 I might also want to change the rate I bill when a VM is migrated between
 hosts or availability zones (I think we said migration caused a new
 instance to be created, but bear with me). The availability zone for an
 instance is clearly metadata and not something we can track via a counter.

Again, that's also a meter that has the same type of 'RAM' for a
resource 'instance'.

 That's an interesting idea, and it might solve the problem. At this point
 in the Folsom schedule though, I would much rather implement a pared down
 API that handles the simple cases but makes the caller do a bit more data
 manipulation for complex cases, in favor of focusing on counting more
 things than we do now. Is that a reasonable approach?

Problem is that we might break the API a bit with this. This would not
be the first time an OpenStack API is broken, but if we can avoid it,
it'd be better.

I am not sure you can really bill anything if you're not able to handle
a simple thing such a VM resize. So currently, it seems that the API is
not designed correctly to handle such a case, and since it's not yet
implemented, maybe it's still time to fix it?

-- 
/*  Julien Danjou
   ╭ Free Software hacker  freelance
   ╰ http://julien.danjou.info  */


pgpBtQSHifQMF.pgp
Description: PGP signature
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] help me with the xenapi test

2012-07-02 Thread Johannes Erdfelt

On Mon, Jul 02, 2012, Salvatore Orlando sorla...@nicira.com wrote:
 I do not see any obvious reason for these failures, especially as they
 appear to occur when the vdi is created. If I recall it correctly, that
 code is stubbed out for unit tests, and it does not seem your patch
 un-stubs it.

It's not when the VDI is created, but when nova does injection of
configuration information to the instance. This should normally only
occur when flat_injected is True. The default is False.

This code path shouldn't happen in this test. The only place that sets
it to True is for the test_spawn_netinject_file test.

I can't reproduce the failure with the same branch on my development
system, so it appears to be a Jenkins problem.

JE


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [metering] resource metadata changes and billing

2012-07-02 Thread Doug Hellmann

On Mon, Jul 2, 2012 at 4:58 PM, Julien Danjou jul...@danjou.info wrote:

 On Fri, Jun 29 2012, Doug Hellmann wrote:

 Hi Doug,

 Sorry for the late reply.

  I don't think I've made the problem clear.
 
  I'm not talking about wanting to calculate the different usage for CPU,
  RAM, etc. The different counters are calculated separately, so we can
 keep
  the amounts for CPU and RAM completely separate, and the API allows the
  outside user to ask for the amounts for each counter for a resource (or
  globally for a user/project). The problem is in deciding how the metadata
  associated with a meter event might cause the provider to change the rate
  they want to charge for that usage.

 It's not metadata of a counter that cause the provider to change the
 rate. It's a meter of a resource that can do that.


No, there are cases where the metadata will affect the rate. For instance,
it costs a different amount to have an instance in each of Amazon's
availability zones (data centers). The counter would still say that the
instance has been running for a certain amount of time, but the *rate* for
charging for that time would depend on where it is. A representative from
HP requested the same thing in ceilometer, and we may use it at DreamHost,
too, eventually.

 That only solves part of the problem, though. As a provider I may want to
  charge different flat rates for the amount of RAM being used. For
 example,
  1 unit for 1024 MB of RAM but 2 units for 4096 MB. That means when the
 size
  of the VM changes, we need to produce multiple totals (the length of time
  that the VM had 1024 MB RAM and then the length of time it had 4096 MB
 RAM).

 Yeah, like I said, for the meter 'RAM' of resource 'instance' you can't
 request a total amount used, because the type of this meter (I don't
 know how to call it, it's the kind I named
 if-i-change-you-need-to-split-the-resource-in-several-stuff in my latest
 email) don't have this semantic.

  I might also want to change the rate I bill when a VM is migrated between
  hosts or availability zones (I think we said migration caused a new
  instance to be created, but bear with me). The availability zone for an
  instance is clearly metadata and not something we can track via a
 counter.

 Again, that's also a meter that has the same type of 'RAM' for a
 resource 'instance'.

  That's an interesting idea, and it might solve the problem. At this point
  in the Folsom schedule though, I would much rather implement a pared down
  API that handles the simple cases but makes the caller do a bit more data
  manipulation for complex cases, in favor of focusing on counting more
  things than we do now. Is that a reasonable approach?

 Problem is that we might break the API a bit with this. This would not
 be the first time an OpenStack API is broken, but if we can avoid it,
 it'd be better.


 I am not sure you can really bill anything if you're not able to handle
 a simple thing such a VM resize. So currently, it seems that the API is
 not designed correctly to handle such a case, and since it's not yet
 implemented, maybe it's still time to fix it?


We probably have time to fix it before the release. On the other hand, it
seems much more important to use work on writing data collectors (new
pollsters, adding notifications to other projects, etc.). I don't think we
can do both things.

Doug
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] best practices for merging common into specific projects

2012-07-02 Thread Joshua Harlow

What about using openstack-common as a library instead of a preprocessor 
'inclusion' system/copy code around system??

Maybe its time for that to happen?

It always seemed sort of silly to me that files are being copied around to 
different projects like this, instead of referring to code in a common library 
package.

On 7/2/12 12:16 PM, Andrew Bogott abog...@wikimedia.org wrote:

Having spent some time last week writing code for openstack-common,
and having spent yet more time trying to get those changes into Nova, I
think it would be useful to define some best practices when crossing the
boundary between common and other openstack projects.

Background:

 The openstack-common project is subject to a standard code-review
process (and, soon, will also have Jenkins testing gates.)  Sadly,
patches that are merged into openstack-common are essentially orphans.
Bringing those changes into actual use requires yet another step, a
'merge from common' patch where the code changes in common are copied
into a specific project (e.g. nova.)
 Merge-from-common patches are generated via an automated process.
Specific projects express dependencies on specific common components via
a config file, e.g. 'nova/openstack-common.conf'.  The actual file copy
is performed by 'openstack-common/update.py,' and its behavior is
governed by the appropriate openstack-common.conf file.

Questions:

 When should changes from common be merged into other projects?
 What should a 'merge-from-common' patch look like?
 What code-review standards should core committers observe when
reviewing merge-from-common patches?

Proposals:

I.  As soon as a patch drops into common, the patch author should
submit merge-from-common patches to all affected projects.
 A.  (This should really be done by a bot, but that's not going to
happen overnight)

II. In the event that I. is not observed, merge-from-common patches
will contain bits from multiple precursor patches.  That is not only OK,
but encouraged.
 A.  Keeping projects in sync with common is important!
 B.  Asking producers of merge-from-common patches to understand the
full diff will discourage the generation of such merges.

III.Merge-from-common patches should be the product of a single
unedited run of update.py.
 A.  If a merge-from-common patch breaks pep8 or a test in nova,
don't fix the patch; fix the code in common.

IV.Merge-from-common patches are 'presumed justified'.  That means:
 A. Reviewers of merge-from-common patches should consider test
failures and pep8 breakages, and obvious functional problems.
 B. Reviewers of merge-from-common patches should not consider the
usefulness, design, etc. of merge-from-common patches.  Such concerns
need to be handled within the common review process.
 C. Merges from common should get reviewed early and approved
readily in order to avoid project divergence

V. Changes to openstack-common.conf are a special case.
 A. Patches with openstack-common.conf changes should include the
relevant merge-from-common changes.
 B. Such patches should /not/ include any other merge-from-common
changes.
 C. Such patches should not only include the common merges, but
should also include whatever code changes make use of the new merge.
 D. Such patches require the same justification and scrutiny as any
other standard project patch.

Please discuss!  If we're able to reach general agreement about this
process, I will document the process in the openstack-common HACKING
guidelines.

-Andrew




On 7/2/12 11:38 AM, Russell Bryant (Code Review) wrote:
 I did that before seeing this patch.  However, I think I prefer what I pushed 
 since it's individual updates explaining what they update instead of a 
 blanket update everything commit.




___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] help me with the xenapi test

2012-07-02 Thread Salvatore Orlando

Hi Yong,

I have been able to reproduce the error on my dev machine - I couldn't
earlier on because I was tesyinh the test_xenapi module only, and no
failure occured.

It seems that test_quantumv2 is the root cause. If you look at gerrit,
Jenkins started complaining when you first added that module.
Indeed, if you rename it to _test_quantumv2, the error disappears.

I guess the problem is that quantum_v2 apparently is the only test modules
whose test cases do not inherit from nova.test. I am trying to understand
what exactly causes then the failure in test_xenapi. My gut says it must
have something to do with mox, but I will let you know soon - unfortunately
each test run takes almost 10 minutes!

Salvatore

On 2 July 2012 19:18, Salvatore Orlando sorla...@nicira.com wrote:

 Hi Yong,

 I do not see any obvious reason for these failures, especially as they
 appear to occur when the vdi is created. If I recall it correctly, that
 code is stubbed out for unit tests, and it does not seem your patch
 un-stubs it.
 Do you see the failures also on your dev machine?

 Salvatore

 On 2 July 2012 14:30, Yong Sheng Gong gong...@cn.ibm.com wrote:

 hi,

 In my change at https://review.openstack.org/#/c/8916/, some xenapi
 tests alway fail:
  
 nova.tests.test_xenapi.XenAPIMigrateInstance.test_finish_migratehttps://jenkins.openstack.org/job/gate-nova-python26/1386/testReport/nova.tests.test_xenapi/XenAPIMigrateInstance/test_finish_migrate/

 Loading...
 10 sec1 https://jenkins.openstack.org/job/gate-nova-python26/1386/
 
 nova.tests.test_xenapi.XenAPIMigrateInstance.test_finish_migrate_no_local_storagehttps://jenkins.openstack.org/job/gate-nova-python26/1386/testReport/nova.tests.test_xenapi/XenAPIMigrateInstance/test_finish_migrate_no_local_storage/

 Loading...
 10 sec1 https://jenkins.openstack.org/job/gate-nova-python26/1386/
 
 nova.tests.test_xenapi.XenAPIMigrateInstance.test_finish_migrate_no_resize_vdihttps://jenkins.openstack.org/job/gate-nova-python26/1386/testReport/nova.tests.test_xenapi/XenAPIMigrateInstance/test_finish_migrate_no_resize_vdi/

 Loading...
 10 sec1 https://jenkins.openstack.org/job/gate-nova-python26/1386/
  
 nova.tests.test_xenapi.XenAPIMigrateInstance.test_revert_migratehttps://jenkins.openstack.org/job/gate-nova-python26/1386/testReport/nova.tests.test_xenapi/XenAPIMigrateInstance/test_revert_migrate/

 Who can help me find the reason?
 Thanks
 Yong Sheng Gong

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [metering] resource metadata changes and billing

2012-07-02 Thread Julien Danjou

On Mon, Jul 02 2012, Doug Hellmann wrote:

 No, there are cases where the metadata will affect the rate. For instance,
 it costs a different amount to have an instance in each of Amazon's
 availability zones (data centers). The counter would still say that the
 instance has been running for a certain amount of time, but the *rate* for
 charging for that time would depend on where it is. A representative from
 HP requested the same thing in ceilometer, and we may use it at DreamHost,
 too, eventually.

I totally agree with you, Doug. I'm just saying that's it's not *only* a
metadata. The zone must be some kind of a meter, even if it's not
numeric. It should be a meter with a type that causes the resource (here
the instance) to be billed differently (and therefore to generate
multiple objects when returning resource usage metering).

Clearly the term meter is probably not the good one, maybe we should
split this, but to me it must be extracted from metadata to become
something more. Something we can rely on to take the decision that this
is something worst splitting the metered resource in different parts
because the billing must change (zone, RAM, flavor, volume size…).

Speaking of volume size, if you take the example of a storage volume,
you likely to have the same issue. You may not charge the same thing if
your volume total size is 1 GB or 10 GB, and if it has been resize you
want (not sure it's possible, but one day) to know when precisely.
Whereas size used is likely to be just a generic absolute meter.

 We probably have time to fix it before the release. On the other hand, it
 seems much more important to use work on writing data collectors (new
 pollsters, adding notifications to other projects, etc.). I don't think we
 can do both things.

Sure. Anyway, we both know that's a do-ocracy. :-)

-- 
/*  Julien Danjou
   ╭ Free Software hacker  freelance
   ╰ http://julien.danjou.info  */


pgpP7E1Rq08GA.pgp
Description: PGP signature
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] best practices for merging common into specific projects

2012-07-02 Thread Joshua Harlow

Maybe its time to break out of that incubation??

Seems like if most projects are depending on these config files for code 
copying that that break out has really already occurred, but it just hasn't 
been written down or made official?

I don't quite understand how a project can be in incubation, but has components 
that are required for other projects to work?

Isn't this the same as having library versions where a project would pull in 
X.Y.Z openstack-common library version (with the features it wants) while the 
openstack-common people work on X.Y.Z + 1?

Then when X.Y.Z + 1 is approved 'stable' they can move to X.Y.Z+1.

On 7/2/12 12:26 PM, Russell Bryant rbry...@redhat.com wrote:

On 07/02/2012 03:16 PM, Andrew Bogott wrote:
 Background:

 The openstack-common project is subject to a standard code-review
 process (and, soon, will also have Jenkins testing gates.)  Sadly,
 patches that are merged into openstack-common are essentially orphans.
 Bringing those changes into actual use requires yet another step, a
 'merge from common' patch where the code changes in common are copied
 into a specific project (e.g. nova.)
 Merge-from-common patches are generated via an automated process.
 Specific projects express dependencies on specific common components via
 a config file, e.g. 'nova/openstack-common.conf'.  The actual file copy
 is performed by 'openstack-common/update.py,' and its behavior is
 governed by the appropriate openstack-common.conf file.

More background:

http://wiki.openstack.org/CommonLibrary

 Questions:

 When should changes from common be merged into other projects?
 What should a 'merge-from-common' patch look like?
 What code-review standards should core committers observe when
 reviewing merge-from-common patches?

 Proposals:

 I.  As soon as a patch drops into common, the patch author should
 submit merge-from-common patches to all affected projects.
 A.  (This should really be done by a bot, but that's not going to
 happen overnight)

All of the APIs in openstack-common right now are considered to be in
incubation, meaning that breaking changes could be made.  I don't think
automated merges are good for anything in incubation.

Automation would be suitable for stable APIs.  Once an API is no longer
in incubation, we should be looking at how to make releases and treat it
as a proper library.  The copy/paste madness should be limited to APIs
still in incubation.

There are multiple APIs close or at the point where I think we should be
able to commit to them.  I'll leave the specifics for a separate
discussion, but I think moving on this front is key to reducing the pain
we are seeing with code copying.

 II. In the event that I. is not observed, merge-from-common patches
 will contain bits from multiple precursor patches.  That is not only OK,
 but encouraged.
 A.  Keeping projects in sync with common is important!
 B.  Asking producers of merge-from-common patches to understand the
 full diff will discourage the generation of such merges.

I don't see this as much different as any other patches to nova (or
whatever project is using common).  It should be a proper patch series.
 If the person pulling it in doesn't understand the merge well enough to
produce the patch series with proper commit messages, then they are the
wrong person to be doing the merge in the first place.

 III.Merge-from-common patches should be the product of a single
 unedited run of update.py.

Disagree, see above.

 A.  If a merge-from-common patch breaks pep8 or a test in nova,
 don't fix the patch; fix the code in common.

Agreed.

 IV.Merge-from-common patches are 'presumed justified'.  That means:
 A. Reviewers of merge-from-common patches should consider test
 failures and pep8 breakages, and obvious functional problems.
 B. Reviewers of merge-from-common patches should not consider the
 usefulness, design, etc. of merge-from-common patches.  Such concerns
 need to be handled within the common review process.
 C. Merges from common should get reviewed early and approved readily
 in order to avoid project divergence

I think core reviewers of projects using openstack-common are justified
in doing critical review of new code being used by their project.  A
core reviewer of nova for examp[le may have a very good reason why the
code is not suitable for consumption in nova that openstack-common
reviewers didn't think of.

I don't think blind approvals are ever a good idea.

 V. Changes to openstack-common.conf are a special case.
 A. Patches with openstack-common.conf changes should include the
 relevant merge-from-common changes.
 B. Such patches should /not/ include any other merge-from-common
 changes.
 C. Such patches should not only include the common merges, but
 should also include whatever code changes make use of the new merge.
 D. Such patches require the same justification and scrutiny as any
 other standard

Re: [Openstack] best practices for merging common into specific projects

2012-07-02 Thread Gabriel Hurley

On a more fundamental level, did I miss some tremendous reason why we have this 
merge from common pattern instead of making OpenStack Common a standard 
python dependency just like anything else? Especially with the work Monty has 
recently done on versioning and packaging the client libs from Jenkins, I can't 
see a reason to keep following this update common and merge to everything 
else pattern at all...

- Gabriel

 -Original Message-
 From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
 [mailto:openstack-
 bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of
 Andrew Bogott
 Sent: Monday, July 02, 2012 12:17 PM
 To: openstack@lists.launchpad.net
 Subject: [Openstack] best practices for merging common into specific
 projects
 
  Having spent some time last week writing code for openstack-common,
 and having spent yet more time trying to get those changes into Nova, I think
 it would be useful to define some best practices when crossing the boundary
 between common and other openstack projects.
 
 Background:
 
  The openstack-common project is subject to a standard code-review
 process (and, soon, will also have Jenkins testing gates.)  Sadly, patches 
 that
 are merged into openstack-common are essentially orphans.
 Bringing those changes into actual use requires yet another step, a 'merge
 from common' patch where the code changes in common are copied into a
 specific project (e.g. nova.)
  Merge-from-common patches are generated via an automated process.
 Specific projects express dependencies on specific common components via
 a config file, e.g. 'nova/openstack-common.conf'.  The actual file copy is
 performed by 'openstack-common/update.py,' and its behavior is governed
 by the appropriate openstack-common.conf file.
 
 Questions:
 
  When should changes from common be merged into other projects?
  What should a 'merge-from-common' patch look like?
  What code-review standards should core committers observe when
 reviewing merge-from-common patches?
 
 Proposals:
 
 I.  As soon as a patch drops into common, the patch author should
 submit merge-from-common patches to all affected projects.
  A.  (This should really be done by a bot, but that's not going to happen
 overnight)
 
 II. In the event that I. is not observed, merge-from-common patches
 will contain bits from multiple precursor patches.  That is not only OK, but
 encouraged.
  A.  Keeping projects in sync with common is important!
  B.  Asking producers of merge-from-common patches to understand the
 full diff will discourage the generation of such merges.
 
 III.Merge-from-common patches should be the product of a single
 unedited run of update.py.
  A.  If a merge-from-common patch breaks pep8 or a test in nova, don't fix
 the patch; fix the code in common.
 
 IV.Merge-from-common patches are 'presumed justified'.  That means:
  A. Reviewers of merge-from-common patches should consider test
 failures and pep8 breakages, and obvious functional problems.
  B. Reviewers of merge-from-common patches should not consider the
 usefulness, design, etc. of merge-from-common patches.  Such concerns
 need to be handled within the common review process.
  C. Merges from common should get reviewed early and approved readily
 in order to avoid project divergence
 
 V. Changes to openstack-common.conf are a special case.
  A. Patches with openstack-common.conf changes should include the
 relevant merge-from-common changes.
  B. Such patches should /not/ include any other merge-from-common
 changes.
  C. Such patches should not only include the common merges, but should
 also include whatever code changes make use of the new merge.
  D. Such patches require the same justification and scrutiny as any other
 standard project patch.
 
 Please discuss!  If we're able to reach general agreement about this process,
 I will document the process in the openstack-common HACKING guidelines.
 
 -Andrew
 
 
 
 
 On 7/2/12 11:38 AM, Russell Bryant (Code Review) wrote:
  I did that before seeing this patch.  However, I think I prefer what I 
  pushed
 since it's individual updates explaining what they update instead of a blanket
 update everything commit.
 
 
 
 
 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] help me with the xenapi test

2012-07-02 Thread Salvatore Orlando

Sincere apologies for cluttering this thread with another post.

I think I probably found the root cause of the test failure. It seems that
a setattr on FLAGS.flat_injected was causing the problem.
I don't know exactly why, and probably that does not even matter, as
setattr globally alters the value of flag, and we probably don't want this
to happen anyway.
The value of the flag can be altered for a single test case using the
following syntax: self.flags(flat_injected=True)

The full diff for test_quantumv2.py - which executes correctly the tests -
is available here: http://paste.openstack.org/show/19204/

Regards,
Salvatore

On 2 July 2012 22:53, Salvatore Orlando sorla...@nicira.com wrote:

 Hi Yong,

 I have been able to reproduce the error on my dev machine - I couldn't
 earlier on because I was tesyinh the test_xenapi module only, and no
 failure occured.

 It seems that test_quantumv2 is the root cause. If you look at gerrit,
 Jenkins started complaining when you first added that module.
 Indeed, if you rename it to _test_quantumv2, the error disappears.

 I guess the problem is that quantum_v2 apparently is the only test modules
 whose test cases do not inherit from nova.test. I am trying to understand
 what exactly causes then the failure in test_xenapi. My gut says it must
 have something to do with mox, but I will let you know soon - unfortunately
 each test run takes almost 10 minutes!

 Salvatore

 On 2 July 2012 19:18, Salvatore Orlando sorla...@nicira.com wrote:

 Hi Yong,

 I do not see any obvious reason for these failures, especially as they
 appear to occur when the vdi is created. If I recall it correctly, that
 code is stubbed out for unit tests, and it does not seem your patch
 un-stubs it.
 Do you see the failures also on your dev machine?

 Salvatore

 On 2 July 2012 14:30, Yong Sheng Gong gong...@cn.ibm.com wrote:

 hi,

 In my change at https://review.openstack.org/#/c/8916/, some xenapi
 tests alway fail:
  
 nova.tests.test_xenapi.XenAPIMigrateInstance.test_finish_migratehttps://jenkins.openstack.org/job/gate-nova-python26/1386/testReport/nova.tests.test_xenapi/XenAPIMigrateInstance/test_finish_migrate/

 Loading...
 10 sec1 https://jenkins.openstack.org/job/gate-nova-python26/1386/
 
 nova.tests.test_xenapi.XenAPIMigrateInstance.test_finish_migrate_no_local_storagehttps://jenkins.openstack.org/job/gate-nova-python26/1386/testReport/nova.tests.test_xenapi/XenAPIMigrateInstance/test_finish_migrate_no_local_storage/

 Loading...
 10 sec1 https://jenkins.openstack.org/job/gate-nova-python26/1386/
 
 nova.tests.test_xenapi.XenAPIMigrateInstance.test_finish_migrate_no_resize_vdihttps://jenkins.openstack.org/job/gate-nova-python26/1386/testReport/nova.tests.test_xenapi/XenAPIMigrateInstance/test_finish_migrate_no_resize_vdi/

 Loading...
 10 sec1 https://jenkins.openstack.org/job/gate-nova-python26/1386/
  
 nova.tests.test_xenapi.XenAPIMigrateInstance.test_revert_migratehttps://jenkins.openstack.org/job/gate-nova-python26/1386/testReport/nova.tests.test_xenapi/XenAPIMigrateInstance/test_revert_migrate/

 Who can help me find the reason?
 Thanks
 Yong Sheng Gong

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp




___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] How do I stop image-create from using /tmp?

On 07/02/2012 01:32 PM, Mark Lehrer wrote:
 just did an ln -s /some/dir/with/space /tmp and that does solve 
 
 I added an option to /etc/init/nova_compute.conf to specify the tmp
 space, so the start line looks like this:
 
 exec su -s /bin/sh -c export TMPDIR=/var/tmp; exec nova-compute
 --flagfile 
 
 Not a great solution either since package updates over-write this setting.

Yeah, that's exactly what we found as well -- Chef would overwrite the
upstart script, and we couldn't for the life of us figure out how to get
Chef to set the TMPDIR environment variable for *user running nova-compute*.

Best,
-jay

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Single global dependency list

Hey all!

One of the tasks from the last ODS was to implement a single global
dependency list. Turns out the more you think about it, the more
important it is... because of the way we use devstack as part of the
gate, we actually _currently_ have a de facto global dependency list,
it's just not declared anywhere. (oops)

Anyway - the original thought was to put the depends in
openstack-common. We'd use update.py to copy the depends in to the
project, so that projects could align on their own timeframe.
Additionally, we'd make the copy only copy in the versions from
openstack-common for package that were already listed in the target
project, so that we wouldn't add django to python-swiftclient, for instance.

The mechanics of that all work and are ready - but then bcwaldon pointed
out that it didn't make a ton of sense for them to go in
openstack-common, since that has its own lifecycle and is a place for
common code to go - not just a catch all place.

To that end, I took the code we had written for the update logic and put
it, along with the depends lists, into its own repo. I think we're ready
to start actually moving forward with it - but we've run up against the
hardest problem we every have:

naming

openstack-depends already got vetoed on IRC because it makes people
think of adult diapers. I'm proposing openstack-requires, since the
files we're talking about are actually python requirements files.

Any objections?

We've also been discussing an idea that we could write some gating tests
that are only run against milestone-proposed branches that would verify
that the requires files in a given project match the versions in
openstack-requires - that way there is some lee-way throughout the
cycle, but the expectation is that by release time the requires files
will be brought in line with the rest of the project. (it's an option if
people find that useful - certainly not required)

Finally, as an added bonus to this approach, once we have the list and
we're even mostly aligned on it, since a library version would need to
be in openstack-requires before it hits a project, we can use it as the
main basis for our pypi mirror and turn off the upstream pypi source
from our jenkins slaves. This would remove the last of the ephemeral
build errors that are due to upstream network timeouts. I'm sure
everyone will be pleased about that.

Anyway - I think general buy in on at _least_ the name
openstack-requires will let us move forward with the next step. After
that point, it'll all be normal code reviews.

Monty

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Openstack and Google Compute Engine

2012-07-02 Thread Paul McMillan

It's KVM on Redhat with a fairly custom guest kernel, including 
optimized drivers for their network encapsulation. Auth is handled using 
their existing OAuth2.0 infrastructure.


As Matt said, their offering is fairly different from EC2 (and 
Openstack), competing more with compute-heavy providers, rather than 
amazon-like application-host offerings.


Their beta is currently only available to customers that they expect 
will run real jobs. Expect a phone call and a conversation about your 
application and current compute use before your organization gets an invite.


One neat thing about their product is that they provide dedicated 
spindles on ephemeral disks for instances with more than 2 cores.


Their user tooling looks very nice. There are probably features worth 
borrowing there.


-Paul


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] new locations for some things

Hey all!

(It must be a busy day - I'm writing you all so many emails...)

A little while ago, after chatting with Anne Gentle, we started
publishing the sphinx documentation to
docs.openstack.org/developer/$project  ... instead of to
$project.openstack.org. That went really well and we're happy about it
... but we didn't put in any redirects from the old locations because we
still had tarballs to content with (which we uploaded to
$project.openstack.org/tarballs)

That's fixed now - we now have tarballs going to
tarballs.openstack.org/$project, docs going to
docs.openstack.org/developer/$project, and redirects from the old
locations to the new locations.

While doing this, we added a couple of features.

First of all - client libs get their own dir, so there should be no
confusion there.

Secondly, in addition to the normal per-commit tarballs, we're now
publishing tarballs of the form $project-$branch.tar.gz which will get
overwritten with each commit - that way, if you need to track trunk from
a pip-requires file, (such as ceilometer, which needs to track nova
trunk) you can simply plop in something like
http://tarballs.openstack.org/nova/nova-master.tar.gz  - and it'll work
for both pip installs AND easy_install/distutils based installs. Yay!

Finally, we've got code landing that will properly publish documentation
for tagged revisions to a subdir ... so when nova gets tagged 2012.2 -
there will be a docs.openstack.org/developer/nova/2012.2 dir with those
docs in it and they will not change over time.

Just wanted to let everyone know.

Monty

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] help me with the xenapi test

2012-07-02 Thread Yong Sheng Gong

Many thanks for the findings.The Jenkins pass now.I removed the setAttr(FLAGS, 'injected', True)-Salvatore Orlando sorla...@nicira.com wrote: -To: Yong Sheng Gong/China/IBM@IBMCNFrom: Salvatore Orlando sorla...@nicira.comDate: 07/03/2012 06:29AMCc: "openstack@lists.launchpad.net" openstack@lists.launchpad.netSubject: Re: [Openstack] help me with the xenapi testSincere apologies for cluttering this thread with another post.I think I probably found the root cause of the test failure.It seems that a setattr on FLAGS.flat_injected was causing the problem.
I don't know exactly why, and probably that does not even matter, as setattr globally alters the value of flag, and we probably don't want this to happen anyway.The value of the flag can be altered for a single test case using the following syntax:self.flags(flat_injected=True)
The full diff for test_quantumv2.py - which executes correctly the tests - is available here:http://paste.openstack.org/show/19204/Regards,
SalvatoreOn 2 July 2012 22:53, Salvatore Orlando sorla...@nicira.com wrote:
Hi Yong,I have been able to reproduce the error on my dev machine - I couldn't earlier on because I was tesyinh the test_xenapi module only, and no failure occured.It seems that test_quantumv2 is the root cause. If you look at gerrit, Jenkins started complaining when you first added that module.

Indeed, if you rename it to _test_quantumv2, the error disappears.I guess the problem is that quantum_v2 apparently is the only test modules whose test cases do not inherit from nova.test. I am trying to understand what exactly causes then the failure in test_xenapi. My gut says it must have something to do with mox, but I will let you know soon - unfortunately each test run takes almost 10 minutes!

SalvatoreOn 2 July 2012 19:18, Salvatore Orlando sorla...@nicira.com wrote:

Hi Yong,I do not see any obvious reason for these failures, especially as they appear to occur when the vdi is created. If I recall it correctly, that code is stubbed out for unit tests, and it does not seem your patch un-stubs it.


Do you see the failures also on your dev machine?SalvatoreOn 2 July 2012 14:30, Yong Sheng Gong gong...@cn.ibm.com wrote:


 hi,
In my change at https://review.openstack.org/#/c/8916/, some xenapi tests alway fail:
nova.tests.test_xenapi.XenAPIMigrateInstance.test_finish_migrate


Loading...10 sec1nova.tests.test_xenapi.XenAPIMigrateInstance.test_finish_migrate_no_local_storage


Loading...10 sec1nova.tests.test_xenapi.XenAPIMigrateInstance.test_finish_migrate_no_resize_vdi


Loading...10 sec1nova.tests.test_xenapi.XenAPIMigrateInstance.test_revert_migrate 


Who can help me find the reason?ThanksYong Sheng Gong

___
Mailing list: https://launchpad.net/~openstack
Post to   : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help  : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] best practices for merging common into specific projects

2012-07-02 Thread John Postlethwait

I agree, I think moving them into one of the package/dependency managers the 
Open Stack projects already use is the proper way to do this.

The current process of copying the latest seemingly un-versionable code 
around into the projects really bothered me when it just happened to Horizon 
for the JSON parser a few weeks ago, I wash;t too keen on approving that review 
and I'd like to get away from it if possible, even if done by a bot of some 
kind...  


John Postlethwait
Nebula, Inc.
206-999-4492


On Monday, July 2, 2012 at 2:41 PM, Joshua Harlow wrote:

 Re: [Openstack] best practices for merging common into specific projects What 
 about using openstack-common as a library instead of a preprocessor 
 ‘inclusion’ system/copy code around system??
  
 Maybe its time for that to happen?  
  
 It always seemed sort of silly to me that files are being copied around to 
 different projects like this, instead of referring to code in a common 
 library package.
  
 On 7/2/12 12:16 PM, Andrew Bogott abog...@wikimedia.org wrote:
  
  Having spent some time last week writing code for openstack-common,
  and having spent yet more time trying to get those changes into Nova, I
  think it would be useful to define some best practices when crossing the
  boundary between common and other openstack projects.
   
  Background:
   
   The openstack-common project is subject to a standard code-review
  process (and, soon, will also have Jenkins testing gates.)  Sadly,
  patches that are merged into openstack-common are essentially orphans.  
  Bringing those changes into actual use requires yet another step, a
  'merge from common' patch where the code changes in common are copied
  into a specific project (e.g. nova.)
   Merge-from-common patches are generated via an automated process.  
  Specific projects express dependencies on specific common components via
  a config file, e.g. 'nova/openstack-common.conf'.  The actual file copy
  is performed by 'openstack-common/update.py,' and its behavior is
  governed by the appropriate openstack-common.conf file.
   
  Questions:
   
   When should changes from common be merged into other projects?
   What should a 'merge-from-common' patch look like?
   What code-review standards should core committers observe when
  reviewing merge-from-common patches?
   
  Proposals:
   
  I.  As soon as a patch drops into common, the patch author should
  submit merge-from-common patches to all affected projects.
   A.  (This should really be done by a bot, but that's not going to
  happen overnight)
   
  II. In the event that I. is not observed, merge-from-common patches
  will contain bits from multiple precursor patches.  That is not only OK,
  but encouraged.
   A.  Keeping projects in sync with common is important!
   B.  Asking producers of merge-from-common patches to understand the
  full diff will discourage the generation of such merges.
   
  III.Merge-from-common patches should be the product of a single
  unedited run of update.py.
   A.  If a merge-from-common patch breaks pep8 or a test in nova,
  don't fix the patch; fix the code in common.
   
  IV.Merge-from-common patches are 'presumed justified'.  That means:
   A. Reviewers of merge-from-common patches should consider test
  failures and pep8 breakages, and obvious functional problems.
   B. Reviewers of merge-from-common patches should not consider the
  usefulness, design, etc. of merge-from-common patches.  Such concerns
  need to be handled within the common review process.
   C. Merges from common should get reviewed early and approved
  readily in order to avoid project divergence
   
  V. Changes to openstack-common.conf are a special case.
   A. Patches with openstack-common.conf changes should include the
  relevant merge-from-common changes.
   B. Such patches should /not/ include any other merge-from-common
  changes.
   C. Such patches should not only include the common merges, but
  should also include whatever code changes make use of the new merge.
   D. Such patches require the same justification and scrutiny as any
  other standard project patch.
   
  Please discuss!  If we're able to reach general agreement about this
  process, I will document the process in the openstack-common HACKING
  guidelines.
   
  -Andrew
   
   
   
   
  On 7/2/12 11:38 AM, Russell Bryant (Code Review) wrote:
   I did that before seeing this patch.  However, I think I prefer what I 
   pushed since it's individual updates explaining what they update instead 
   of a blanket update everything commit.
  
  
   
   
  ___
  Mailing list: https://launchpad.net/~openstack
  Post to : openstack@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~openstack
  More help   : https://help.launchpad.net/ListHelp
   
 ___
 Mailing list:

Re: [Openstack] best practices for merging common into specific projects

2012-07-02 Thread Christopher B Ferris



-openstack-bounces+chrisfer=us.ibm@lists.launchpad.net wrote: -

To: andrewbog...@gmail.com andrewbog...@gmail.com, Andrew Bogott
abog...@wikimedia.org, openstack openstack@lists.launchpad.net
From: Joshua Harlow 
Sent by: openstack-bounces+chrisfer=us.ibm@lists.launchpad.net
Date: 07/02/2012 07:21PM
Subject: Re: [Openstack] best practices for merging common into
specific projects



Re: [Openstack] best practices for merging common into specific
projects


What about using openstack-common as a library instead of a
preprocessor #8216;inclusion#8217; system/copy code around system??



Maybe its time for that to happen? 



It always seemed sort of silly to me that files are being copied around
to different projects like this, instead of referring to code in a
common library package.

+1

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Industry and Cloud Standards
Member, IBM Academy of Technology
IBM Software Group, Standards Strategy
email: chris...@us.ibm.com
Twitter: christo4ferris
phone: +1 508 234 2986


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack-ubuntu-testing-notifications] Build Still Failing: quantal_folsom_quantum_trunk #18

Title: quantal_folsom_quantum_trunk
General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_quantum_trunk/18/Project:quantal_folsom_quantum_trunkDate of build:Mon, 02 Jul 2012 03:31:56 -0400Build duration:2.8 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: 3 out of the last 5 builds failed.40ChangesUse setuptools git plugin for file inclusion.by mordrededitMANIFEST.ineditsetup.pyedittox.iniedittools/install_venv.pyConsole OutputStarted by an SCM changeBuilding remotely on pkg-builderCheckout:quantal_folsom_quantum_trunk / /var/lib/jenkins/slave/workspace/quantal_folsom_quantum_trunk - hudson.remoting.Channel@56c88357:pkg-builderUsing strategy: DefaultLast Built Revision: Revision 4ac32079279347c454f5d9fe22a21dfcbf3ab64f (origin/master)Checkout:quantum / /var/lib/jenkins/slave/workspace/quantal_folsom_quantum_trunk/quantum - hudson.remoting.LocalChannel@42eb0c97Wiping out workspace first.Cloning the remote Git repositoryCloning repository originFetching upstream changes from https://github.com/openstack/quantum.gitCommencing build of Revision 6d9ddf1c3737762fa12ce3b910075ed05da48cd9 (origin/master)Checking out Revision 6d9ddf1c3737762fa12ce3b910075ed05da48cd9 (origin/master)No emails were triggered.[quantal_folsom_quantum_trunk] $ /bin/sh -xe /tmp/hudson3607237816362192995.sh+ /var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package -jINFO:root:Creating tarball using git archiveERROR:root:Error occurred during package creation/buildERROR:root:local variable 'tarball_dst' referenced before assignmentINFO:root:Complete command log:Traceback (most recent call last):  File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 135, in raise eUnboundLocalError: local variable 'tarball_dst' referenced before assignmentBuild step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- 
Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications
Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications
More help   : https://help.launchpad.net/ListHelp

[Openstack-ubuntu-testing-notifications] Build Fixed: quantal_folsom_python-swiftclient_trunk #9

Title: quantal_folsom_python-swiftclient_trunk
General InformationBUILD SUCCESSBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_python-swiftclient_trunk/9/Project:quantal_folsom_python-swiftclient_trunkDate of build:Mon, 02 Jul 2012 13:36:52 -0400Build duration:3 min 2 secBuild cause:Started by user adamBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: 1 out of the last 5 builds failed.80ChangesNo ChangesConsole Output[...truncated 1739 lines...]Space: 896Status: successfulVersion: 1.1.1+git201207021336~quantal-0ubuntu1Finished at 20120702-1339Build needed 00:00:47, 896k disc spaceINFO:root:Uploading package to ppa:openstack-ubuntu-testing/folsom-trunk-testinggpg: Signature made Mon Jul  2 13:38:58 2012 EDT using RSA key ID 9935ACDCgpg: Good signature from "Openstack Ubuntu Testing Bot (Jenkins Key) <ja...@shingle-house.org.uk>"gpg: Signature made Mon Jul  2 13:38:58 2012 EDT using RSA key ID 9935ACDCgpg: Good signature from "Openstack Ubuntu Testing Bot (Jenkins Key) <ja...@shingle-house.org.uk>"Checking signature on .changesGood signature on /tmp/tmpQSaXLU/python-swiftclient_1.1.1+git201207021336~quantal-0ubuntu1_source.changes.Checking signature on .dscGood signature on /tmp/tmpQSaXLU/python-swiftclient_1.1.1+git201207021336~quantal-0ubuntu1.dsc.Uploading to ppa (via ftp to ppa.launchpad.net):  Uploading python-swiftclient_1.1.1+git201207021336~quantal-0ubuntu1.dsc: done.  Uploading python-swiftclient_1.1.1+git201207021336~quantal.orig.tar.gz: done.  Uploading python-swiftclient_1.1.1+git201207021336~quantal-0ubuntu1.debian.tar.gz: done.  Uploading python-swiftclient_1.1.1+git201207021336~quantal-0ubuntu1_source.changes: done.Successfully uploaded packages.INFO:root:Installing build artifacts into /var/lib/jenkins/www/aptSkipping inclusion of 'python-swiftclient' '1.1.1+git201207021336~quantal-0ubuntu1' in 'quantal-folsom|main|amd64', as it has already '2012.2+git201206271601~quantal-0ubuntu1'.Deleting files just added to the pool but not used.(to avoid use --keepunusednewfiles next time)deleting and forgetting pool/main/p/python-swiftclient/python-swiftclient_1.1.1+git201207021336~quantal-0ubuntu1_all.debINFO:root:Pushing changes back to bzr testing branchPushed up to revision 6.INFO:root:Storing current commit for next build: f6c7fec991939e02c78ba8f34069772027eb70b8INFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/python-swiftclient/quantal-folsom-proposed /tmp/tmpQSaXLU/python-swiftclientmk-build-deps -i -r -t apt-get -y /tmp/tmpQSaXLU/python-swiftclient/debian/controlpython setup.py sdistgit log -n1 --no-merges --pretty=format:%Hbzr merge lp:~openstack-ubuntu-testing/python-swiftclient/quantal-folsom --forcedch -b -D quantal --newversion 1.1.1+git201207021336~quantal-0ubuntu1 Automated Ubuntu testing build:dch -b -D quantal --newversion 1.1.1+git201207021336~quantal-0ubuntu1 Automated Ubuntu testing build:debcommitbzr builddeb -S -- -sa -us -ucbzr builddeb -S -- -sa -us -ucdebsign -k9935ACDC python-swiftclient_1.1.1+git201207021336~quantal-0ubuntu1_source.changessbuild -d quantal-folsom -n -A python-swiftclient_1.1.1+git201207021336~quantal-0ubuntu1.dscdput ppa:openstack-ubuntu-testing/folsom-trunk-testing python-swiftclient_1.1.1+git201207021336~quantal-0ubuntu1_source.changesreprepro --waitforlock 10 -Vb /var/lib/jenkins/www/apt include quantal-folsom python-swiftclient_1.1.1+git201207021336~quantal-0ubuntu1_amd64.changesbzr push lp:~openstack-ubuntu-testing/python-swiftclient/quantal-folsomEmail was triggered for: FixedTrigger Success was overridden by another trigger and will not send an email.Sending email for trigger: Fixed-- 
Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications
Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications
More help   : https://help.launchpad.net/ListHelp

[Openstack-ubuntu-testing-notifications] Build Still Failing: quantal_folsom_quantum_trunk #19

Title: quantal_folsom_quantum_trunk
General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_quantum_trunk/19/Project:quantal_folsom_quantum_trunkDate of build:Mon, 02 Jul 2012 13:54:52 -0400Build duration:3 min 30 secBuild cause:Started by user adamBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: 4 out of the last 5 builds failed.20ChangesNo ChangesConsole Output[...truncated 2320 lines...]Build-Time: 46Distribution: quantal-folsomFail-Stage: buildInstall-Time: 23Job: quantum_2012.2+git201207021355~quantal-0ubuntu1.dscPackage: quantumPackage-Time: 86Source-Version: 2012.2+git201207021355~quantal-0ubuntu1Space: 4292Status: attemptedVersion: 2012.2+git201207021355~quantal-0ubuntu1Finished at 20120702-1358Build needed 00:01:26, 4292k disc spaceERROR:root:Error occurred during package creation/buildERROR:root:Command '['sbuild', '-d', 'quantal-folsom', '-n', '-A', 'quantum_2012.2+git201207021355~quantal-0ubuntu1.dsc']' returned non-zero exit status 2INFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/quantum/quantal-folsom-proposed /tmp/tmp_WkqcN/quantummk-build-deps -i -r -t apt-get -y /tmp/tmp_WkqcN/quantum/debian/controlpython setup.py sdistgit log -n1 --no-merges --pretty=format:%Hgit log f54a788cae726b8e1480e27c0a416c66a7afb373..HEAD --no-merges --pretty=format:[%h] %sbzr merge lp:~openstack-ubuntu-testing/quantum/quantal-folsom --forcedch -b -D quantal --newversion 2012.2+git201207021355~quantal-0ubuntu1 Automated Ubuntu testing build:dch -b -D quantal --newversion 2012.2+git201207021355~quantal-0ubuntu1 Automated Ubuntu testing build:debcommitbzr builddeb -S -- -sa -us -ucbzr builddeb -S -- -sa -us -ucdebsign -k9935ACDC quantum_2012.2+git201207021355~quantal-0ubuntu1_source.changessbuild -d quantal-folsom -n -A quantum_2012.2+git201207021355~quantal-0ubuntu1.dscTraceback (most recent call last):  File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 135, in raise esubprocess.CalledProcessError: Command '['sbuild', '-d', 'quantal-folsom', '-n', '-A', 'quantum_2012.2+git201207021355~quantal-0ubuntu1.dsc']' returned non-zero exit status 2Error in sys.excepthook:Traceback (most recent call last):  File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 68, in apport_excepthookbinary = os.path.realpath(os.path.join(os.getcwdu(), sys.argv[0]))OSError: [Errno 2] No such file or directoryOriginal exception was:Traceback (most recent call last):  File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 135, in raise esubprocess.CalledProcessError: Command '['sbuild', '-d', 'quantal-folsom', '-n', '-A', 'quantum_2012.2+git201207021355~quantal-0ubuntu1.dsc']' returned non-zero exit status 2Build step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- 
Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications
Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications
More help   : https://help.launchpad.net/ListHelp

[Openstack-ubuntu-testing-notifications] Build Still Failing: precise_folsom_quantum_trunk #18

Title: precise_folsom_quantum_trunk
General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/precise_folsom_quantum_trunk/18/Project:precise_folsom_quantum_trunkDate of build:Mon, 02 Jul 2012 16:31:55 -0400Build duration:13 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: 4 out of the last 5 builds failed.20ChangesOVS plugin support for v2 Quantum APIby aroseneditquantum/db/models_v2.pyeditetc/quantum/plugins/openvswitch/ovs_quantum_plugin.inieditquantum/plugins/openvswitch/ovs_quantum_plugin.pyeditquantum/plugins/openvswitch/common/config.pyaddquantum/plugins/openvswitch/ovs_models_v2.pyaddquantum/plugins/openvswitch/ovs_db_v2.pyeditquantum/plugins/openvswitch/agent/ovs_quantum_agent.pyeditquantum/db/model_base.pyeditquantum/common/utils.pyConsole OutputStarted by an SCM changeBuilding remotely on pkg-builderCheckout:precise_folsom_quantum_trunk / /var/lib/jenkins/slave/workspace/precise_folsom_quantum_trunk - hudson.remoting.Channel@56c88357:pkg-builderUsing strategy: DefaultLast Built Revision: Revision 6d9ddf1c3737762fa12ce3b910075ed05da48cd9 (origin/master)Checkout:quantum / /var/lib/jenkins/slave/workspace/precise_folsom_quantum_trunk/quantum - hudson.remoting.LocalChannel@42eb0c97Wiping out workspace first.Cloning the remote Git repositoryCloning repository originFetching upstream changes from https://github.com/openstack/quantum.gitCommencing build of Revision 804c936667151cdea9b499dd768adcfd7ae20c1f (origin/master)Checking out Revision 804c936667151cdea9b499dd768adcfd7ae20c1f (origin/master)No emails were triggered.[precise_folsom_quantum_trunk] $ /bin/sh -xe /tmp/hudson2683394877962276377.sh+ /var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package -jINFO:root:Creating tarball using git archiveERROR:root:Error occurred during package creation/buildERROR:root:local variable 'tarball_dst' referenced before assignmentINFO:root:Complete command log:Traceback (most recent call last):  File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 135, in raise eUnboundLocalError: local variable 'tarball_dst' referenced before assignmentBuild step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- 
Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications
Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications
More help   : https://help.launchpad.net/ListHelp

[Openstack-ubuntu-testing-notifications] Build Still Failing: quantal_folsom_quantum_trunk #21

Title: quantal_folsom_quantum_trunk
General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_quantum_trunk/21/Project:quantal_folsom_quantum_trunkDate of build:Mon, 02 Jul 2012 16:31:54 -0400Build duration:3 min 15 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: All recent builds failed.0ChangesOVS plugin support for v2 Quantum APIby arosenaddquantum/plugins/openvswitch/ovs_db_v2.pyeditquantum/db/models_v2.pyeditetc/quantum/plugins/openvswitch/ovs_quantum_plugin.iniaddquantum/plugins/openvswitch/ovs_models_v2.pyeditquantum/plugins/openvswitch/common/config.pyeditquantum/plugins/openvswitch/agent/ovs_quantum_agent.pyeditquantum/plugins/openvswitch/ovs_quantum_plugin.pyeditquantum/db/model_base.pyeditquantum/common/utils.pyConsole Output[...truncated 2328 lines...]Build-Time: 47Distribution: quantal-folsomFail-Stage: buildInstall-Time: 23Job: quantum_2012.2+git201207021632~quantal-0ubuntu1.dscPackage: quantumPackage-Time: 89Source-Version: 2012.2+git201207021632~quantal-0ubuntu1Space: 4300Status: attemptedVersion: 2012.2+git201207021632~quantal-0ubuntu1Finished at 20120702-1635Build needed 00:01:29, 4300k disc spaceERROR:root:Error occurred during package creation/buildERROR:root:Command '['sbuild', '-d', 'quantal-folsom', '-n', '-A', 'quantum_2012.2+git201207021632~quantal-0ubuntu1.dsc']' returned non-zero exit status 2INFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/quantum/quantal-folsom-proposed /tmp/tmp76iH2J/quantummk-build-deps -i -r -t apt-get -y /tmp/tmp76iH2J/quantum/debian/controlpython setup.py sdistgit log -n1 --no-merges --pretty=format:%Hgit log f54a788cae726b8e1480e27c0a416c66a7afb373..HEAD --no-merges --pretty=format:[%h] %sbzr merge lp:~openstack-ubuntu-testing/quantum/quantal-folsom --forcedch -b -D quantal --newversion 2012.2+git201207021632~quantal-0ubuntu1 Automated Ubuntu testing build:dch -b -D quantal --newversion 2012.2+git201207021632~quantal-0ubuntu1 Automated Ubuntu testing build:debcommitbzr builddeb -S -- -sa -us -ucbzr builddeb -S -- -sa -us -ucdebsign -k9935ACDC quantum_2012.2+git201207021632~quantal-0ubuntu1_source.changessbuild -d quantal-folsom -n -A quantum_2012.2+git201207021632~quantal-0ubuntu1.dscTraceback (most recent call last):  File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 135, in raise esubprocess.CalledProcessError: Command '['sbuild', '-d', 'quantal-folsom', '-n', '-A', 'quantum_2012.2+git201207021632~quantal-0ubuntu1.dsc']' returned non-zero exit status 2Error in sys.excepthook:Traceback (most recent call last):  File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 68, in apport_excepthookbinary = os.path.realpath(os.path.join(os.getcwdu(), sys.argv[0]))OSError: [Errno 2] No such file or directoryOriginal exception was:Traceback (most recent call last):  File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 135, in raise esubprocess.CalledProcessError: Command '['sbuild', '-d', 'quantal-folsom', '-n', '-A', 'quantum_2012.2+git201207021632~quantal-0ubuntu1.dsc']' returned non-zero exit status 2Build step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- 
Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications
Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications
More help   : https://help.launchpad.net/ListHelp

[Openstack-ubuntu-testing-notifications] Build Still Failing: precise_folsom_quantum_trunk #19

Title: precise_folsom_quantum_trunk
General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/precise_folsom_quantum_trunk/19/Project:precise_folsom_quantum_trunkDate of build:Mon, 02 Jul 2012 18:01:55 -0400Build duration:5.4 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: All recent builds failed.0ChangesEnsure that subnet_id is on correct network.by gkottoneditquantum/db/db_base_plugin_v2.pyeditquantum/tests/unit/test_db_plugin.pyCheck if interface exists in bridge prior to adding.by gkottoneditquantum/plugins/linuxbridge/agent/linuxbridge_quantum_agent.pyConsole OutputStarted by an SCM changeBuilding remotely on pkg-builderCheckout:precise_folsom_quantum_trunk / /var/lib/jenkins/slave/workspace/precise_folsom_quantum_trunk - hudson.remoting.Channel@56c88357:pkg-builderUsing strategy: DefaultLast Built Revision: Revision 804c936667151cdea9b499dd768adcfd7ae20c1f (origin/master)Checkout:quantum / /var/lib/jenkins/slave/workspace/precise_folsom_quantum_trunk/quantum - hudson.remoting.LocalChannel@42eb0c97Wiping out workspace first.Cloning the remote Git repositoryCloning repository originFetching upstream changes from https://github.com/openstack/quantum.gitCommencing build of Revision 85b0a148c9f0537665bbca7647a058c07ed718e6 (origin/master)Checking out Revision 85b0a148c9f0537665bbca7647a058c07ed718e6 (origin/master)No emails were triggered.[precise_folsom_quantum_trunk] $ /bin/sh -xe /tmp/hudson6463137066157366699.sh+ /var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package -jINFO:root:Creating tarball using git archiveERROR:root:Error occurred during package creation/buildERROR:root:local variable 'tarball_dst' referenced before assignmentINFO:root:Complete command log:Traceback (most recent call last):  File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 135, in raise eUnboundLocalError: local variable 'tarball_dst' referenced before assignmentBuild step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- 
Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications
Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications
More help   : https://help.launchpad.net/ListHelp

[Openstack-ubuntu-testing-notifications] Build Failure: quantal_folsom_horizon_trunk #26

Title: quantal_folsom_horizon_trunk
General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_horizon_trunk/26/Project:quantal_folsom_horizon_trunkDate of build:Mon, 02 Jul 2012 18:31:55 -0400Build duration:9.3 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: 1 out of the last 5 builds failed.80ChangesUse client libs from PyPI (what?)by mordrededittools/pip-requireseditrun_tests.shConsole OutputStarted by an SCM changeBuilding remotely on pkg-builderCheckout:quantal_folsom_horizon_trunk / /var/lib/jenkins/slave/workspace/quantal_folsom_horizon_trunk - hudson.remoting.Channel@56c88357:pkg-builderUsing strategy: DefaultLast Built Revision: Revision 0b50c9606a403b1c7a009ea621dab79f3b2e6db2 (origin/master)Checkout:horizon / /var/lib/jenkins/slave/workspace/quantal_folsom_horizon_trunk/horizon - hudson.remoting.LocalChannel@42eb0c97Wiping out workspace first.Cloning the remote Git repositoryCloning repository originFetching upstream changes from https://github.com/openstack/horizon.gitCommencing build of Revision 8e8d5a75d538ad3300859fc3d59e7bdfd760129c (origin/master)Checking out Revision 8e8d5a75d538ad3300859fc3d59e7bdfd760129c (origin/master)No emails were triggered.[quantal_folsom_horizon_trunk] $ /bin/sh -xe /tmp/hudson3319408167899379944.sh+ /var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package -jINFO:root:Creating tarball using git archiveERROR:root:Error occurred during package creation/buildERROR:root:local variable 'tarball_dst' referenced before assignmentINFO:root:Complete command log:Traceback (most recent call last):  File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 135, in raise eUnboundLocalError: local variable 'tarball_dst' referenced before assignmentBuild step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- 
Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications
Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications
More help   : https://help.launchpad.net/ListHelp

[Openstack-ubuntu-testing-notifications] Build Fixed: precise_folsom_python-swiftclient_trunk #8

Title: precise_folsom_python-swiftclient_trunk
General InformationBUILD SUCCESSBuild URL:https://jenkins.qa.ubuntu.com/job/precise_folsom_python-swiftclient_trunk/8/Project:precise_folsom_python-swiftclient_trunkDate of build:Mon, 02 Jul 2012 19:01:10 -0400Build duration:2 min 56 secBuild cause:Started by user adamBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: 1 out of the last 5 builds failed.80ChangesNo ChangesConsole Output[...truncated 1468 lines...]Space: 896Status: successfulVersion: 1.1.1+git201207021901~precise-0ubuntu1Finished at 20120702-1903Build needed 00:00:58, 896k disc spaceINFO:root:Uploading package to ppa:openstack-ubuntu-testing/folsom-trunk-testinggpg: Signature made Mon Jul  2 19:02:56 2012 EDT using RSA key ID 9935ACDCgpg: Good signature from "Openstack Ubuntu Testing Bot (Jenkins Key) <ja...@shingle-house.org.uk>"gpg: Signature made Mon Jul  2 19:02:56 2012 EDT using RSA key ID 9935ACDCgpg: Good signature from "Openstack Ubuntu Testing Bot (Jenkins Key) <ja...@shingle-house.org.uk>"Checking signature on .changesGood signature on /tmp/tmpSs24hD/python-swiftclient_1.1.1+git201207021901~precise-0ubuntu1_source.changes.Checking signature on .dscGood signature on /tmp/tmpSs24hD/python-swiftclient_1.1.1+git201207021901~precise-0ubuntu1.dsc.Uploading to ppa (via ftp to ppa.launchpad.net):  Uploading python-swiftclient_1.1.1+git201207021901~precise-0ubuntu1.dsc: done.  Uploading python-swiftclient_1.1.1+git201207021901~precise.orig.tar.gz: done.  Uploading python-swiftclient_1.1.1+git201207021901~precise-0ubuntu1.debian.tar.gz: done.  Uploading python-swiftclient_1.1.1+git201207021901~precise-0ubuntu1_source.changes: done.Successfully uploaded packages.INFO:root:Installing build artifacts into /var/lib/jenkins/www/aptSkipping inclusion of 'python-swiftclient' '1.1.1+git201207021901~precise-0ubuntu1' in 'precise-folsom|main|amd64', as it has already '2012.2+git201206271601~precise-0ubuntu1'.Deleting files just added to the pool but not used.(to avoid use --keepunusednewfiles next time)deleting and forgetting pool/main/p/python-swiftclient/python-swiftclient_1.1.1+git201207021901~precise-0ubuntu1_all.debINFO:root:Pushing changes back to bzr testing branchPushed up to revision 5.INFO:root:Storing current commit for next build: f6c7fec991939e02c78ba8f34069772027eb70b8INFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/python-swiftclient/precise-folsom-proposed /tmp/tmpSs24hD/python-swiftclientmk-build-deps -i -r -t apt-get -y /tmp/tmpSs24hD/python-swiftclient/debian/controlpython setup.py sdistgit log -n1 --no-merges --pretty=format:%Hbzr merge lp:~openstack-ubuntu-testing/python-swiftclient/precise-folsom --forcedch -b -D precise --newversion 1.1.1+git201207021901~precise-0ubuntu1 Automated Ubuntu testing build:dch -b -D precise --newversion 1.1.1+git201207021901~precise-0ubuntu1 Automated Ubuntu testing build:debcommitbzr builddeb -S -- -sa -us -ucbzr builddeb -S -- -sa -us -ucdebsign -k9935ACDC python-swiftclient_1.1.1+git201207021901~precise-0ubuntu1_source.changessbuild -d precise-folsom -n -A python-swiftclient_1.1.1+git201207021901~precise-0ubuntu1.dscdput ppa:openstack-ubuntu-testing/folsom-trunk-testing python-swiftclient_1.1.1+git201207021901~precise-0ubuntu1_source.changesreprepro --waitforlock 10 -Vb /var/lib/jenkins/www/apt include precise-folsom python-swiftclient_1.1.1+git201207021901~precise-0ubuntu1_amd64.changesbzr push lp:~openstack-ubuntu-testing/python-swiftclient/precise-folsomEmail was triggered for: FixedTrigger Success was overridden by another trigger and will not send an email.Sending email for trigger: Fixed-- 
Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications
Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications
More help   : https://help.launchpad.net/ListHelp

[Openstack-ubuntu-testing-notifications] Build Fixed: precise_folsom_horizon_trunk #29