Re: [Openstack] Multinode installation (with devstack on the master)

[Frost Dragon]

Hi Anthony,
Thank you very much. That worked like a charm. I can now launch
and access instances running on different nodes. Instances without
disk storage (m1.tiny) work great. But when I try to use flavors with
disk storage, the dashboard displays an 'Error' state after the
'Build' state. Since the console log is empty, I have no idea why it
is going into this state. I'm running nova-volume on both nodes and
I'm not using swift on either of them.

Thanks and regards,
Sagar

On 12/31/11, Anthony Young  wrote:
> Hey Sagar,
>
> I'll take a quick guess here that maybe your servers have host names that
> don't resolve.  So for example, if host1 is 'server1' and host2 is
> 'server2' the vnc proxy may try connect using those hostnames (connecting
> to the latter host would probably fail).  A quick fix could be to add an
> entry in your master /etc/hosts for the second server's hostname.
>
> Anthony
>
> On Fri, Dec 30, 2011 at 2:02 PM, Frost Dragon
> wrote:
>
>> Hi,
>> Thanks for the replies. I tried a clean installation with eth1 as my
>> flat interface and it worked perfectly well. I can now ping and SSH to my
>> VMs on either node from the other. They're also getting their metadata
>> correctly. Only problem is that I can't access VMs on the second node via
>> the console on the dashboard running on the first node. I'm getting a
>> 'Failed to connect to server' message. However, I can view the VMs running
>> on the master node through the vnc console. Is this related to
>> nova-vncproxy? The services I'm running on the second node are
>> n-vol,n-cpu,n-net and n-api.
>>
>> Thanks and regards,
>> Sagar
>>
>

___
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] using tox for virtualenv builds

[Gabriel Hurley]

Big +1 from me on using tox to manage testing across various Python versions. 
Another advantage it has over matrix builds in Jenkins is the fact that an 
ordinary developer can use it locally and verify the tests across versions 
*before* pushing to Jenkins.

Anything we can do to standardize codebases and infrastructure across projects 
is fantastic in my book.

All the best,

- Gabriel

> -Original Message-
> From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
> [mailto:openstack-
> bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Jay
> Pipes
> Sent: Friday, December 30, 2011 2:10 PM
> To: Monty Taylor
> Cc: openstack@lists.launchpad.net
> Subject: Re: [Openstack] using tox for virtualenv builds
> 
> On Fri, Dec 30, 2011 at 5:01 PM, Monty Taylor 
> wrote:
> > Hey all!
> >
> > I've been poking around at a few things over the last week or so, and
> > I thought I'd put some thoughts out there for everyone.
> >
> > There are two issues that have been driving the work:
> >
> > 1) We need to be able to sensibly run unit tests against multiple
> > python versions (specifically 2.6 and 2.7 at the moment)
> >
> > 2) I'd like to reduce the amount of boilerplate or (even worse)
> > modified boiler plate code that we have copied around in all of our
> > repos. (it makes incorporating new projects painful)
> >
> > I could solve (1) with matrix builds in jenkins, but that doesn't help
> > put any tooling in the hands of devs so that they can run those tests
> > locally before submitting.
> >
> > To this end, (and thanks to a config file that was in
> > python-keystoneclient) I've been exploring the tool tox. tox actually
> > addresses both of the above points out of the box. tox allows you to
> > specify multiple virtualenv environments you want to run against, and
> > will happily do the testing in each of them. It's testing tool
> > agnostic (essentially, it does pretty much the same thing that
> > install_venv.py and with_venv.py do, except across multiple
> > environments)
> 
> w00t. Looking forward to simplifying and unifying the various run_tests and
> venv stuff in the core projects...
> 
> > An example tox.ini file for glance looks like this:
> >
> > [tox]
> > envlist = py26,py27
> >
> > [testenv]
> > deps = -r{toxinidir}/tools/pip-requires commands = /bin/bash
> > run_tests.sh -N
> 
> I don't think that the -N makes any sense above, since that indicates to run
> WITHOUT a virtualenv. ;) See my similar comment on the Glance tox merge
> proposal...
> 
> > [testenv:pep8]
> > commands = pep8 --repeat glance
> >
> > If you run:
> >
> > # tox
> >
> > You get run_tests.sh -N run against a python2.6 and a python2.7
> > virtual env. If you run:
> >
> > # tox -e py27
> >
> > You get just tests against 2.7. If you run:
> >
> > # tox -e pep8
> >
> > You get the pep8 run in a venv.
> >
> > Because we can reference our existing pip-requires files, we can add
> > the tox.ini files without really impacting anything else for the
> > purposes of kicking the tires.
> >
> > What I'd like to do going forward is this;
> >
> > - propose some patches to projects which add a tox.ini file and send
> > out some instructions for people to try using it
> >
> > - if we like it, modify the jenkins jobs to start invoking tox instead
> > of run_tests,sh
> >
> > - eventually, if we're happy, make run_tests.sh just a simple wrapper
> > script which calls tox with a few parameters and remove
> > install_venv.sh and with_venv.sh
> >
> > Upstream for tox has been pretty responsive so far - and I'm working
> > on a patch that we would need to land in order for us to be able to do
> > our venv pre-caching in jenkins properly - so any features we might
> > need in it should be easy enough to deal with. However, so far I
> > haven't found anything we currently do that it can't pretty much already
> handle.
> >
> > Any thoughts or feedback? (Most importantly, are there any drastic
> > objections to further investigation of it as a tool to use here?)
> 
> No objections from me.
> 
> Cheers,
> -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



___
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] using tox for virtualenv builds

[Monty Taylor]

On 12/30/2011 02:09 PM, Jay Pipes wrote:
> On Fri, Dec 30, 2011 at 5:01 PM, Monty Taylor  wrote:
>> Hey all!
>>
>> I've been poking around at a few things over the last week or so, and I
>> thought I'd put some thoughts out there for everyone.
>>
>> There are two issues that have been driving the work:
>>
>> 1) We need to be able to sensibly run unit tests against multiple python
>> versions (specifically 2.6 and 2.7 at the moment)
>>
>> 2) I'd like to reduce the amount of boilerplate or (even worse) modified
>> boiler plate code that we have copied around in all of our repos. (it
>> makes incorporating new projects painful)
>>
>> I could solve (1) with matrix builds in jenkins, but that doesn't help
>> put any tooling in the hands of devs so that they can run those tests
>> locally before submitting.
>>
>> To this end, (and thanks to a config file that was in
>> python-keystoneclient) I've been exploring the tool tox. tox actually
>> addresses both of the above points out of the box. tox allows you to
>> specify multiple virtualenv environments you want to run against, and
>> will happily do the testing in each of them. It's testing tool agnostic
>> (essentially, it does pretty much the same thing that install_venv.py
>> and with_venv.py do, except across multiple environments)
> 
> w00t. Looking forward to simplifying and unifying the various
> run_tests and venv stuff in the core projects...
> 
>> An example tox.ini file for glance looks like this:
>>
>> [tox]
>> envlist = py26,py27
>>
>> [testenv]
>> deps = -r{toxinidir}/tools/pip-requires
>> commands = /bin/bash run_tests.sh -N
> 
> I don't think that the -N makes any sense above, since that indicates
> to run WITHOUT a virtualenv. ;) See my similar comment on the Glance
> tox merge proposal...

That will eventually go away ... it's just because we're using tox in
this case to manage the virtualenv, so we don't want run_tests.sh to
create one.

>> [testenv:pep8]
>> commands = pep8 --repeat glance
>>
>> If you run:
>>
>> # tox
>>
>> You get run_tests.sh -N run against a python2.6 and a python2.7 virtual
>> env. If you run:
>>
>> # tox -e py27
>>
>> You get just tests against 2.7. If you run:
>>
>> # tox -e pep8
>>
>> You get the pep8 run in a venv.
>>
>> Because we can reference our existing pip-requires files, we can add the
>> tox.ini files without really impacting anything else for the purposes of
>> kicking the tires.
>>
>> What I'd like to do going forward is this;
>>
>> - propose some patches to projects which add a tox.ini file and send out
>> some instructions for people to try using it
>>
>> - if we like it, modify the jenkins jobs to start invoking tox instead
>> of run_tests,sh
>>
>> - eventually, if we're happy, make run_tests.sh just a simple wrapper
>> script which calls tox with a few parameters and remove install_venv.sh
>> and with_venv.sh
>>
>> Upstream for tox has been pretty responsive so far - and I'm working on
>> a patch that we would need to land in order for us to be able to do our
>> venv pre-caching in jenkins properly - so any features we might need in
>> it should be easy enough to deal with. However, so far I haven't found
>> anything we currently do that it can't pretty much already handle.
>>
>> Any thoughts or feedback? (Most importantly, are there any drastic
>> objections to further investigation of it as a tool to use here?)
> 
> No objections from me.

w00t

___
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] Multinode installation (with devstack on the master)

[Anthony Young]

Hey Sagar,

I'll take a quick guess here that maybe your servers have host names that
don't resolve.  So for example, if host1 is 'server1' and host2 is
'server2' the vnc proxy may try connect using those hostnames (connecting
to the latter host would probably fail).  A quick fix could be to add an
entry in your master /etc/hosts for the second server's hostname.

Anthony

On Fri, Dec 30, 2011 at 2:02 PM, Frost Dragon wrote:

> Hi,
> Thanks for the replies. I tried a clean installation with eth1 as my
> flat interface and it worked perfectly well. I can now ping and SSH to my
> VMs on either node from the other. They're also getting their metadata
> correctly. Only problem is that I can't access VMs on the second node via
> the console on the dashboard running on the first node. I'm getting a
> 'Failed to connect to server' message. However, I can view the VMs running
> on the master node through the vnc console. Is this related to
> nova-vncproxy? The services I'm running on the second node are
> n-vol,n-cpu,n-net and n-api.
>
> Thanks and regards,
> Sagar
>
___
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] using tox for virtualenv builds

[Jay Pipes]

On Fri, Dec 30, 2011 at 5:01 PM, Monty Taylor  wrote:
> Hey all!
>
> I've been poking around at a few things over the last week or so, and I
> thought I'd put some thoughts out there for everyone.
>
> There are two issues that have been driving the work:
>
> 1) We need to be able to sensibly run unit tests against multiple python
> versions (specifically 2.6 and 2.7 at the moment)
>
> 2) I'd like to reduce the amount of boilerplate or (even worse) modified
> boiler plate code that we have copied around in all of our repos. (it
> makes incorporating new projects painful)
>
> I could solve (1) with matrix builds in jenkins, but that doesn't help
> put any tooling in the hands of devs so that they can run those tests
> locally before submitting.
>
> To this end, (and thanks to a config file that was in
> python-keystoneclient) I've been exploring the tool tox. tox actually
> addresses both of the above points out of the box. tox allows you to
> specify multiple virtualenv environments you want to run against, and
> will happily do the testing in each of them. It's testing tool agnostic
> (essentially, it does pretty much the same thing that install_venv.py
> and with_venv.py do, except across multiple environments)

w00t. Looking forward to simplifying and unifying the various
run_tests and venv stuff in the core projects...

> An example tox.ini file for glance looks like this:
>
> [tox]
> envlist = py26,py27
>
> [testenv]
> deps = -r{toxinidir}/tools/pip-requires
> commands = /bin/bash run_tests.sh -N

I don't think that the -N makes any sense above, since that indicates
to run WITHOUT a virtualenv. ;) See my similar comment on the Glance
tox merge proposal...

> [testenv:pep8]
> commands = pep8 --repeat glance
>
> If you run:
>
> # tox
>
> You get run_tests.sh -N run against a python2.6 and a python2.7 virtual
> env. If you run:
>
> # tox -e py27
>
> You get just tests against 2.7. If you run:
>
> # tox -e pep8
>
> You get the pep8 run in a venv.
>
> Because we can reference our existing pip-requires files, we can add the
> tox.ini files without really impacting anything else for the purposes of
> kicking the tires.
>
> What I'd like to do going forward is this;
>
> - propose some patches to projects which add a tox.ini file and send out
> some instructions for people to try using it
>
> - if we like it, modify the jenkins jobs to start invoking tox instead
> of run_tests,sh
>
> - eventually, if we're happy, make run_tests.sh just a simple wrapper
> script which calls tox with a few parameters and remove install_venv.sh
> and with_venv.sh
>
> Upstream for tox has been pretty responsive so far - and I'm working on
> a patch that we would need to land in order for us to be able to do our
> venv pre-caching in jenkins properly - so any features we might need in
> it should be easy enough to deal with. However, so far I haven't found
> anything we currently do that it can't pretty much already handle.
>
> Any thoughts or feedback? (Most importantly, are there any drastic
> objections to further investigation of it as a tool to use here?)

No objections from me.

Cheers,
-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] Multinode installation (with devstack on the master)

[Frost Dragon]

Hi,
Thanks for the replies. I tried a clean installation with eth1 as my
flat interface and it worked perfectly well. I can now ping and SSH to my
VMs on either node from the other. They're also getting their metadata
correctly. Only problem is that I can't access VMs on the second node via
the console on the dashboard running on the first node. I'm getting a
'Failed to connect to server' message. However, I can view the VMs running
on the master node through the vnc console. Is this related to
nova-vncproxy? The services I'm running on the second node are
n-vol,n-cpu,n-net and n-api.

Thanks and regards,
Sagar
___
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] using tox for virtualenv builds

[Monty Taylor]

Hey all!

I've been poking around at a few things over the last week or so, and I
thought I'd put some thoughts out there for everyone.

There are two issues that have been driving the work:

1) We need to be able to sensibly run unit tests against multiple python
versions (specifically 2.6 and 2.7 at the moment)

2) I'd like to reduce the amount of boilerplate or (even worse) modified
boiler plate code that we have copied around in all of our repos. (it
makes incorporating new projects painful)

I could solve (1) with matrix builds in jenkins, but that doesn't help
put any tooling in the hands of devs so that they can run those tests
locally before submitting.

To this end, (and thanks to a config file that was in
python-keystoneclient) I've been exploring the tool tox. tox actually
addresses both of the above points out of the box. tox allows you to
specify multiple virtualenv environments you want to run against, and
will happily do the testing in each of them. It's testing tool agnostic
(essentially, it does pretty much the same thing that install_venv.py
and with_venv.py do, except across multiple environments)

An example tox.ini file for glance looks like this:

[tox]
envlist = py26,py27

[testenv]
deps = -r{toxinidir}/tools/pip-requires
commands = /bin/bash run_tests.sh -N

[testenv:pep8]
commands = pep8 --repeat glance

If you run:

# tox

You get run_tests.sh -N run against a python2.6 and a python2.7 virtual
env. If you run:

# tox -e py27

You get just tests against 2.7. If you run:

# tox -e pep8

You get the pep8 run in a venv.

Because we can reference our existing pip-requires files, we can add the
tox.ini files without really impacting anything else for the purposes of
kicking the tires.

What I'd like to do going forward is this;

- propose some patches to projects which add a tox.ini file and send out
some instructions for people to try using it

- if we like it, modify the jenkins jobs to start invoking tox instead
of run_tests,sh

- eventually, if we're happy, make run_tests.sh just a simple wrapper
script which calls tox with a few parameters and remove install_venv.sh
and with_venv.sh

Upstream for tox has been pretty responsive so far - and I'm working on
a patch that we would need to land in order for us to be able to do our
venv pre-caching in jenkins properly - so any features we might need in
it should be easy enough to deal with. However, so far I haven't found
anything we currently do that it can't pretty much already handle.

Any thoughts or feedback? (Most importantly, are there any drastic
objections to further investigation of it as a tool to use here?)

Thanks!
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] Glance functional tests failing

[Jay Pipes]

Logged a bug:

https://bugs.launchpad.net/glance/+bug/910233

Cheers,
-jay

On Fri, Dec 30, 2011 at 12:32 AM, Ewan Mellor  wrote:
> I’m getting 4 failures with the current Glance functional tests, all of this
> form:
>
>
>
> FAIL: test_glance_cli
> (glance.tests.functional.test_private_images.TestPrivateImagesCli)
>
> --
>
> Traceback (most recent call last):
>
>   File "/home/emellor/openstack/glance/glance/tests/utils.py", line 122, in
> wrapped
>
>     func(*a, **kwargs)
>
>   File
> "/home/emellor/openstack/glance/glance/tests/functional/test_private_images.py",
> line 773, in test_glance_cli
>
>     keystone_utils.pattieblack_id)
>
> AssertionError: 'b0283d1088194c1a8c74ae6d8cb5941c' != '2'
>
>
>
>
>
> This is a clean venv, using the latest glance code from master.
>
>
>
> It looks like the image owner is being recorded as a UUID, when the unit
> tests are expecting it to be a small integer.
>
>
>
> Does this ring any bells for anyone?
>
>
>
> Thanks,
>
>
>
> Ewan.
>
>
>
>
> ___
> 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 + XCP (both on SID): XenAPI python script failing

[Johannes Erdfelt]

On Sat, Dec 31, 2011, Thomas Goirand  wrote:
> Here's the output (reformatted by hand to fit in this mail):
> 
> root@GPLHost:os>_ # glance index
> ID  Name  Disk Format  Size
>  lucid_ami ami  524288000
>  kernelaki  4099360
>  ramdisk   ari  7988037

That's good, so glance appears to be fine.

I'm trying to figure out a good next step to troubleshoot this. It'll
have to be on dom0, but it doesn't look like many messages are created
during the download phase that are useful for debugging.

Can you search for 'download_vhd' in /var/log/user.log on the dom0? It
should exit with code 0.

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] Configure Rate limits on OS API

[Diego Parrilla Santamaría]

Wow! Didn't know about it. Really valuable information. I have been looking
for that information for ages.

Happy New Year folks,
Diego
-- 
Diego Parrilla
*CEO*
*www.stackops.com | * diego.parri...@stackops.com** | +34 649 94 43 29 |
skype:diegoparrilla*
* 
*

*

 ADVERTENCIA LEGAL 
Le informamos, como destinatario de este mensaje, que el correo electrónico
y las comunicaciones por medio de Internet no permiten asegurar ni
garantizar la confidencialidad de los mensajes transmitidos, así como
tampoco su integridad o su correcta recepción, por lo que STACKOPS
TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias.
Si no consintiese en la utilización del correo electrónico o de las
comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro
conocimiento de manera inmediata. Este mensaje va dirigido, de manera
exclusiva, a su destinatario y contiene información confidencial y sujeta
al secreto profesional, cuya divulgación no está permitida por la ley. En
caso de haber recibido este mensaje por error, le rogamos que, de forma
inmediata, nos lo comunique mediante correo electrónico remitido a nuestra
atención y proceda a su eliminación, así como a la de cualquier documento
adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o
utilización de este mensaje, o de cualquier documento adjunto al mismo,
cualquiera que fuera su finalidad, están prohibidas por la ley.

* PRIVILEGED AND CONFIDENTIAL 
We hereby inform you, as addressee of this message, that e-mail and
Internet do not guarantee the confidentiality, nor the completeness or
proper reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L.
does not assume any liability for those circumstances. Should you not agree
to the use of e-mail or to communications via Internet, you are kindly
requested to notify us immediately. This message is intended exclusively
for the person to whom it is addressed and contains privileged and
confidential information protected from disclosure by law. If you are not
the addressee indicated in this message, you should immediately delete it
and any attachments and notify the sender by reply e-mail. In such case,
you are hereby notified that any dissemination, distribution, copying or
use of this message or any attachments, for any purpose, is strictly
prohibited by law.




On Tue, Dec 27, 2011 at 9:33 PM, Nirmal Ranganathan wrote:

> You can configure those values thru the paste conf.
>
> [filter:ratelimit]
> paste.filter_factory =
> nova.api.openstack.limits:RateLimitingMiddleware.factory
> limits =("POST", "*", ".*", 10, MINUTE);("POST", "*/servers", "^/servers",
> 50, DAY);("PUT", "*", ".*", 10, MINUTE);("GET", "*changes-since*",
> ".*changes-since.*", 3, MINUTE);("DELETE", "*", ".*", 100, MINUTE)
>
>
> On Mon, Dec 19, 2011 at 1:28 PM, Day, Phil  wrote:
>
>> Hi Folks,
>>
>> ** **
>>
>> Is there a file that can be used to configure the API rate limits for the
>> OS API on a per user basis ?
>>
>> ** **
>>
>> I can see where the default values are set in the code, but it looks as
>> if there should be a less brutal configuration mechanism to go along with
>> this ?
>>
>> ** **
>>
>> Thanks
>>
>> Phil 
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> Nirmal
> 
> http://rnirmal.com
>
> ___
> 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] Problems with run_tests.sh on 11.10

[Jay Pipes]

That is what I suspected... :)

Here is the bug you are looking for:

https://bugs.launchpad.net/nova/+bug/892271

Cheerio,

-jay

On Fri, Dec 30, 2011 at 2:30 PM, John Griffith
 wrote:
> Oops, sorry about that.  Forgot to check it in the venv, which reveals the
> issue:
>
>  % tools/with_venv.sh
> jdg@grumpy ~/Projects/OpenStack/nova
>  % python
> Python 2.7.2+ (default, Oct  4 2011, 20:06:09)
> [GCC 4.6.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
 import M2Crypto
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/local/lib/python2.7/dist-packages/M2Crypto/__init__.py", line
> 22, in 
>     import __m2crypto
> ImportError: /usr/local/lib/python2.7/dist-packages/M2Crypto/__m2crypto.so:
> undefined symbol: SSLv2_method

>
>
> Looking in .venv M2Crypto was NOT installed, I ran things on a clean 11.10
> install last night and the results were the same.  Repeat on a clean 11.04
> and everything is fine. Looking at the venv setup script to see if I can
> figure out why this failed.  Seems odd I've reproduced on multiple machines
> but nobody else has seen this?  Maybe there's a step I'm missing still?
>
> John
>
>
>
> On Fri, Dec 30, 2011 at 12:13 PM, Jay Pipes  wrote:
>>
>> On Thu, Dec 29, 2011 at 11:27 AM, John Griffith
>>  wrote:
>> > jdg@grumpy /tmp % python
>> > Python 2.7.2+ (default, Oct  4 2011, 20:06:09)
>> > [GCC 4.6.1] on linux2
>> > Type "help", "copyright", "credits" or "license" for more information.
>>  import M2Crypto
>>
>> What does this result in, though?
>>
>> $> tools/with_venv.sh python
>>  import M2Crypto
>>
>> -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] Problems with run_tests.sh on 11.10

[Kevin L. Mitchell]

On Fri, 2011-12-30 at 12:30 -0700, John Griffith wrote:
> Looking in .venv M2Crypto was NOT installed, I ran things on a clean
> 11.10 install last night and the results were the same.  Repeat on a
> clean 11.04 and everything is fine. Looking at the venv setup script
> to see if I can figure out why this failed.  Seems odd I've reproduced
> on multiple machines but nobody else has seen this?  Maybe there's a
> step I'm missing still?

I believe M2Crypto is a C extension, which means that it has to be
compiled.  One of its compilation dependencies is likely SSL, given the
name of the undefined symbol.  So, my best guess at the best way to
resolve your problem is to ensure you have the openssl-dev package
installed (or whatever name it really has on 11.10).
-- 
Kevin L. Mitchell 


___
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] Configure Rate limits on OS API

[Jay Pipes]

I struggled to figure out how to change this ratelimiting stuff for
ages while working on Tempest. Eventually, I just removed the
ratelimit middleware entirely from the pipeline since I could find no
documentation whatsoever on how to change the limits.

It would be awesome if this was documented in the Nova docs.

I've added a bug to remind about it:

https://bugs.launchpad.net/nova/+bug/910193

Cheers,
-jay

On Tue, Dec 27, 2011 at 3:33 PM, Nirmal Ranganathan  wrote:
> You can configure those values thru the paste conf.
>
> [filter:ratelimit]
> paste.filter_factory =
> nova.api.openstack.limits:RateLimitingMiddleware.factory
> limits =("POST", "*", ".*", 10, MINUTE);("POST", "*/servers", "^/servers",
> 50, DAY);("PUT", "*", ".*", 10, MINUTE);("GET", "*changes-since*",
> ".*changes-since.*", 3, MINUTE);("DELETE", "*", ".*", 100, MINUTE)
>
>
> On Mon, Dec 19, 2011 at 1:28 PM, Day, Phil  wrote:
>>
>> Hi Folks,
>>
>>
>>
>> Is there a file that can be used to configure the API rate limits for the
>> OS API on a per user basis ?
>>
>>
>>
>> I can see where the default values are set in the code, but it looks as if
>> there should be a less brutal configuration mechanism to go along with this
>> ?
>>
>>
>>
>> Thanks
>>
>> Phil
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
> --
> Nirmal
> 
> http://rnirmal.com
>
> ___
> 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] Problems with run_tests.sh on 11.10

[John Griffith]

Oops, sorry about that.  Forgot to check it in the venv, which reveals the
issue:

 % tools/with_venv.sh
jdg@grumpy ~/Projects/OpenStack/nova
 % python
Python 2.7.2+ (default, Oct  4 2011, 20:06:09)
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import M2Crypto
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python2.7/dist-packages/M2Crypto/__init__.py", line
22, in 
import __m2crypto
ImportError: /usr/local/lib/python2.7/dist-packages/M2Crypto/__m2crypto.so:
undefined symbol: SSLv2_method
>>>


Looking in .venv M2Crypto was NOT installed, I ran things on a clean 11.10
install last night and the results were the same.  Repeat on a clean 11.04
and everything is fine. Looking at the venv setup script to see if I can
figure out why this failed.  Seems odd I've reproduced on multiple machines
but nobody else has seen this?  Maybe there's a step I'm missing still?

John



On Fri, Dec 30, 2011 at 12:13 PM, Jay Pipes  wrote:

> On Thu, Dec 29, 2011 at 11:27 AM, John Griffith
>  wrote:
> > jdg@grumpy /tmp % python
> > Python 2.7.2+ (default, Oct  4 2011, 20:06:09)
> > [GCC 4.6.1] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
>  import M2Crypto
>
> What does this result in, though?
>
> $> tools/with_venv.sh python
>  import M2Crypto
>
> -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 + XCP (both on SID): XenAPI python script failing

[Thomas Goirand]

On 12/31/2011 02:47 AM, Johannes Erdfelt wrote:
> On Sat, Dec 31, 2011, Thomas Goirand  wrote:
>> On 12/31/2011 02:03 AM, Johannes Erdfelt wrote:
>>> On Sat, Dec 31, 2011, Thomas Goirand  wrote:
 2011-12-30 17:38:59,348 DEBUG nova.virt.xenapi.vmops [-] Resizing up VDI
 1aacb195-9301-410b-989f-49bdce3a4813 from 0GB to 20GB from (pid=14409)
 _resize_instance /usr/lib/python2.7/dist-packages/nova/virt/xe
>>>
>>> This is likely the problem. The initial VDI is 0GB (probably 0 bytes).
>>>
>>> Can you confirm the image you are trying to boot is > 0 bytes?
>>
>> The image is about 500 MB (it's a lucid image). I'm following the guide
>> here:
>>
>> http://wiki.openstack.org/XenServerDevelopment
> 
> That's a pretty good guide. Can you confirm that glance actually thinks
> the image is larger than 0 bytes?
> 
> You can do that using the 'glance index' command.

Here's the output (reformatted by hand to fit in this mail):

root@GPLHost:os>_ # glance index
ID  Name  Disk Format  Size
 lucid_ami ami  524288000
 kernelaki  4099360
 ramdisk   ari  7988037

>> The EC2 API doesn't seem to work on my domU by the way (euca2ools says
>> "connection refused"). Is there something I should enable for it?
> 
> It should be enabled automatically, unless you have disabled it via the
> enabled_apis option.

It seems that the issue was the addition of this in my nova.conf:
--enabled_apis=osapi

If I remove it, then all APIs ports are listening, and euca2ools are
working. Unsurprisingly, I got the same issue with the EC2 as I have
with the nova API.

Thomas

___
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] Problems with run_tests.sh on 11.10

[Jay Pipes]

On Thu, Dec 29, 2011 at 11:27 AM, John Griffith
 wrote:
> jdg@grumpy /tmp % python
> Python 2.7.2+ (default, Oct  4 2011, 20:06:09)
> [GCC 4.6.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
 import M2Crypto

What does this result in, though?

$> tools/with_venv.sh python
 import M2Crypto

-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 + XCP (both on SID): XenAPI python script failing

[Johannes Erdfelt]

On Sat, Dec 31, 2011, Thomas Goirand  wrote:
> On 12/31/2011 02:03 AM, Johannes Erdfelt wrote:
> > On Sat, Dec 31, 2011, Thomas Goirand  wrote:
> >> 2011-12-30 17:38:59,348 DEBUG nova.virt.xenapi.vmops [-] Resizing up VDI
> >> 1aacb195-9301-410b-989f-49bdce3a4813 from 0GB to 20GB from (pid=14409)
> >> _resize_instance /usr/lib/python2.7/dist-packages/nova/virt/xe
> > 
> > This is likely the problem. The initial VDI is 0GB (probably 0 bytes).
> > 
> > Can you confirm the image you are trying to boot is > 0 bytes?
> 
> The image is about 500 MB (it's a lucid image). I'm following the guide
> here:
> 
> http://wiki.openstack.org/XenServerDevelopment

That's a pretty good guide. Can you confirm that glance actually thinks
the image is larger than 0 bytes?

You can do that using the 'glance index' command.

> The EC2 API doesn't seem to work on my domU by the way (euca2ools says
> "connection refused"). Is there something I should enable for it?

It should be enabled automatically, unless you have disabled it via the
enabled_apis option.

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 + XCP (both on SID): XenAPI python script failing

[Thomas Goirand]

On 12/31/2011 02:03 AM, Johannes Erdfelt wrote:
> On Sat, Dec 31, 2011, Thomas Goirand  wrote:
>> 2011-12-30 17:38:59,348 DEBUG nova.virt.xenapi.vmops [-] Resizing up VDI
>> 1aacb195-9301-410b-989f-49bdce3a4813 from 0GB to 20GB from (pid=14409)
>> _resize_instance /usr/lib/python2.7/dist-packages/nova/virt/xe
> 
> This is likely the problem. The initial VDI is 0GB (probably 0 bytes).
> 
> Can you confirm the image you are trying to boot is > 0 bytes?
> 
> JE

Hi Johannes,

The image is about 500 MB (it's a lucid image). I'm following the guide
here:

http://wiki.openstack.org/XenServerDevelopment

The EC2 API doesn't seem to work on my domU by the way (euca2ools says
"connection refused"). Is there something I should enable for it?

Cheers,

Thomas

___
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 + XCP (both on SID): XenAPI python script failing

[Johannes Erdfelt]

On Sat, Dec 31, 2011, Thomas Goirand  wrote:
> 2011-12-30 17:38:59,348 DEBUG nova.virt.xenapi.vmops [-] Resizing up VDI
> 1aacb195-9301-410b-989f-49bdce3a4813 from 0GB to 20GB from (pid=14409)
> _resize_instance /usr/lib/python2.7/dist-packages/nova/virt/xe

This is likely the problem. The initial VDI is 0GB (probably 0 bytes).

Can you confirm the image you are trying to boot is > 0 bytes?

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] Openstack + XCP (both on SID): XenAPI python script failing

[Thomas Goirand]

Hi,

When I did:

nova boot test --flavor  --image 

then I have the following python dump in nova-compute.log:

2011-12-30 17:38:59,348 DEBUG nova.virt.xenapi.vmops [-] Resizing up VDI
1aacb195-9301-410b-989f-49bdce3a4813 from 0GB to 20GB from (pid=14409)
_resize_instance /usr/lib/python2.7/dist-packages/nova/virt/xe
2011-12-30 17:38:59,362 ERROR nova.virt.xenapi.vmops [-] instance 1:
Failed to spawn
(nova.virt.xenapi.vmops): TRACE: Traceback (most recent call last):
(nova.virt.xenapi.vmops): TRACE:   File
"/usr/lib/python2.7/dist-packages/nova/virt/xenapi/vmops.py", line 199,
in spawn
(nova.virt.xenapi.vmops): TRACE: vdis = self._create_disks(context,
instance, image_meta)
(nova.virt.xenapi.vmops): TRACE:   File
"/usr/lib/python2.7/dist-packages/nova/virt/xenapi/vmops.py", line 180,
in _create_disks
(nova.virt.xenapi.vmops): TRACE: self._resize_instance(instance,
vdi["vdi_uuid"])
(nova.virt.xenapi.vmops): TRACE:   File
"/usr/lib/python2.7/dist-packages/nova/virt/xenapi/vmops.py", line 826,
in _resize_instance
(nova.virt.xenapi.vmops): TRACE: str(new_disk_size))
(nova.virt.xenapi.vmops): TRACE:   File
"/usr/lib/python2.7/dist-packages/nova/virt/xenapi_conn.py", line 500,
in call_xenapi
(nova.virt.xenapi.vmops): TRACE: return tpool.execute(f, *args)
(nova.virt.xenapi.vmops): TRACE:   File
"/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 76, in tworker
(nova.virt.xenapi.vmops): TRACE: rv = meth(*args,**kwargs)
(nova.virt.xenapi.vmops): TRACE:   File
"/usr/lib/python2.7/dist-packages/XenAPI.py", line 235, in __call__
(nova.virt.xenapi.vmops): TRACE: return self.__send(self.__name, args)
(nova.virt.xenapi.vmops): TRACE:   File
"/usr/lib/python2.7/dist-packages/XenAPI.py", line 138, in xenapi_request
(nova.virt.xenapi.vmops): TRACE: result =
_parse_result(getattr(self, methodname)(*full_params))
(nova.virt.xenapi.vmops): TRACE:   File
"/usr/lib/python2.7/dist-packages/XenAPI.py", line 209, in _parse_result
(nova.virt.xenapi.vmops): TRACE: raise
Failure(result['ErrorDescription'])
(nova.virt.xenapi.vmops): TRACE: Failure: ['SR_OPERATION_NOT_SUPPORTED',
'OpaqueRef:476adb81-e7a6-d286-f459-35772aeb4411']

What's happening? What kind of operation Openstack is trying to do on
the SR (eg: what's the "xe" equivalent?)? Why could it fail?

Cheers,

Thomas

___
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] Using Gerrit to verify the CLA

[James E. Blair]

Hi,

We've gotten some requests from core reviewers to automate verification
that people submitting changes have agreed to the CLA.  Right now, the
expectation is that core reviewers will only approve changes submitted
by people who have agreed.  That's silly because we have computers that
can do that.

Gerrit has a CLA system built in.  While we could use it to replace the
data collection and signature portion of the CLA process, that isn't the
most important thing for either us or the lawyers to be working on right
now.  Instead, we can adopt a hybrid approach where we still use the
same signature process, but use Gerrit to make sure people have
completed it.

The current process involves people adding their Launchpad IDs and
Echosign signature transaction codes to a wiki page.  To that, we'll add
the step of requesting membership in the "openstack-cla" group on
Launchpad.  When someone has verified the listing for that person on the
wiki page, they will be added to the group.  Membership in that group
will be required to upload changes to Gerrit.

If we implement this technically as a CLA in Gerrit, albeit one that
simply says something like "Follow the CLA process described in the
wiki," we get a couple of benefits.  We can tell Gerrit that anyone in a
specific group (openstack-cla) has signed that CLA, and they will be
able to upload changes.  If someone attempts to upload a change without
being a member of that group (ie, without having signed the CLA), they
will receive a helpful error message:

==
fatal:  A Contributor Agreement must be completed before uploading:

  https://review.openstack.org/#settings,agreements
==

That page (which will be present once the CLA is enabled) will show the
pseudo-CLA in Gerrit, with a pointer to the wiki page with instructions
on the real OpenStack CLA process.

Even though it's not the way the Gerrit CLA system was intended to be
used, I think this is a reasonable hybrid approach, at least until the
next time we feel like overhauling the project CLA process.  It's fairly
simple, and we get an expressive error message from Gerrit if someone
hasn't signed.

In short, the process for new developers will be:

1) Sign CLA via Echosign
2) Record signature in wiki
3) Apply for membership in openstack-cla
4) Contribute!

With only step 3 being added by this change.

I'd like to enable this check on Thursday, January 5th.  Please make
sure you have signed the CLA and entered your name on the wiki page by
then:

  http://wiki.openstack.org/HowToContribute
  http://wiki.openstack.org/Contributors

-Jim

___
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] git-review ready for general use

[Monty Taylor]

On 12/30/2011 08:20 AM, Jay Pipes wrote:
> I'd like to thank you and Jim for your excellent work on this and all
> the continuous development/deployment tooling. You're both doing a
> fantastic job of working with a diverse group of contributors with
> different needs and agendas.

Thanks Jay! Just wait until you see what's coming next. :)

> On Tue, Dec 27, 2011 at 10:54 AM, Monty Taylor  wrote:
>> Hey guys,
>>
>> We've been having various people test the new git-review tool for a
>> while now, and believe that it is ready for prime time as a replacement
>> for the git review alias and tools/rfc.sh. We've also sent an email to
>> our fine friends at glusterfs (from whom we got rfc.sh in the first
>> place) and at gerrit to announce the tool to them.
>>
>> We're going to start a phased approach of rolling this out.
>>
>> Phase 1 - Get everyone to install git-review.
>> Phase 2 - Add a deprecation warning message to tools/rfc.sh to catch
>> stragglers.
>> Phase 3 - Remove tools/rfc.sh from the repos.
>>
>> The only phase there that you need to really worry with is Phase 1 -
>> because that's the one in which you install the tool.
>>
>> It's really quite easy. It works like this:
>>
>> 'sudo pip install git-review'
>>
>> And just go on about your day. When you run 'git review' to submit
>> changes to gerrit, the git-review program will take precedence and do
>> all of the appropriate things. There is a README file at
>> https://github.com/openstack-ci/git-review with more information for
>> those who care. However, notable features which were lacking with rfc.sh:
>>
>> git review -v prints out all of the git commands that are being run, for
>> those who are interested in that sort of thing
>>
>> git review $branch_name will submit reviews to branches that are not master
>>
>> git review -d $review_number will download the code for a gerrit review
>> into a local branch
>>
>> Enjoy!
>>
>> Monty
>>
>> PS. Not that there are any bugs, but git-review is managed via the same
>> process as all other openstack code - so bugs can be filed at
>> bugs.launchpad.net/git-review and patches are accepted via gerrit. You
>> can submit them using git review. :)
>>
>> PPS. If you want, after installing git-review, you can remove the review
>> alias from ~/.gitconfig. It's not necessary, as the git-review
>> executable does take precedence.
>>
>> ___
>> 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] git-review ready for general use

[Jay Pipes]

I'd like to thank you and Jim for your excellent work on this and all
the continuous development/deployment tooling. You're both doing a
fantastic job of working with a diverse group of contributors with
different needs and agendas.

Thank you!
-jay

On Tue, Dec 27, 2011 at 10:54 AM, Monty Taylor  wrote:
> Hey guys,
>
> We've been having various people test the new git-review tool for a
> while now, and believe that it is ready for prime time as a replacement
> for the git review alias and tools/rfc.sh. We've also sent an email to
> our fine friends at glusterfs (from whom we got rfc.sh in the first
> place) and at gerrit to announce the tool to them.
>
> We're going to start a phased approach of rolling this out.
>
> Phase 1 - Get everyone to install git-review.
> Phase 2 - Add a deprecation warning message to tools/rfc.sh to catch
> stragglers.
> Phase 3 - Remove tools/rfc.sh from the repos.
>
> The only phase there that you need to really worry with is Phase 1 -
> because that's the one in which you install the tool.
>
> It's really quite easy. It works like this:
>
> 'sudo pip install git-review'
>
> And just go on about your day. When you run 'git review' to submit
> changes to gerrit, the git-review program will take precedence and do
> all of the appropriate things. There is a README file at
> https://github.com/openstack-ci/git-review with more information for
> those who care. However, notable features which were lacking with rfc.sh:
>
> git review -v prints out all of the git commands that are being run, for
> those who are interested in that sort of thing
>
> git review $branch_name will submit reviews to branches that are not master
>
> git review -d $review_number will download the code for a gerrit review
> into a local branch
>
> Enjoy!
>
> Monty
>
> PS. Not that there are any bugs, but git-review is managed via the same
> process as all other openstack code - so bugs can be filed at
> bugs.launchpad.net/git-review and patches are accepted via gerrit. You
> can submit them using git review. :)
>
> PPS. If you want, after installing git-review, you can remove the review
> alias from ~/.gitconfig. It's not necessary, as the git-review
> executable does take precedence.
>
> ___
> 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

[Openstack] First Melange Milestone Release

[Troy Toman]

I am pleased to announce that the first Melange milestone release is now 
available. This release has been vetted with the E2 releases of Quantum and 
Nova. You can find the release tarball along with more information about the 
Melange project at:

http://launchpad.net/melange

Melange is an incubated OpenStack project that is primarily focused on 
providing robust and flexible IP address management for OpenStack services. We 
have also expanded to handle additional network information such as MAC address 
allocation and static route tracking as. Our initial target has been on 
Nova/Quantum integration. Melange can currently be used with Nova through the 
QuantumManager network option. 

Our near term focus is to improve the packaging by separating the Melange 
client code into a separate repo, enhancing our documentation and improving the 
scalability of the system. We are interested in getting more feedback and 
requirements for future development work. So, fire away!

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