date:20120328

Hmm, just to add to this - I thought I'd just blindly try an IP address...
just in case... and I could connect...

$ ssh 172.29.1.4
... snip
ubuntu@dev1:~$ logout
Connection to 172.29.1.4 closed.

But looking at nova list - it doesn't show this IP... something is being
quite lazy in getting some updated information...

$ nova list
+--+-++--+
|  ID  |   Name  | Status |
Networks |
+--+-++--+
| b3606cf9-77af-4178-a16f-e92bc458d2db | dev1| ACTIVE |
development=10.2.0.5 |
+--+-++--+

Cheers,

Kev


On 28 March 2012 12:49, Kevin Jackson ke...@linuxservices.co.uk wrote:

 Hi all,
 I've got the following set in my nova.conf:

 --auto_assign_floating_ip

 and I fire up an instance.
 Everything works, a private IP is assigned... the instance is running...
 but it can take an inordinate amount of time (anywhere upwards of 2 mins,
 sometimes a lot longer) to associate a floating IP automatically.

 Anybody else experienced this?  Any clues on what I can do to troubleshoot
 this?  What is the condition when a Floating IP is assigned?  I've seen it
 assign Floating IPs very quickly when it is still Booting, not Active, say.
 Is it dependent on anything within the Instance itself?

 Cheers,

 Kev
 --
 Kevin Jackson
 @itarchitectkev




-- 
Kevin Jackson
@itarchitectkev
___
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] Auto Assigned Floating IPs take a long time to associate

2012-03-28 Thread Day, Phil

Are you sure that its Nova that is taking the time to associate the IP, and not 
an ARP issue in your network ?

I've seen this behaviour when quickly reusing floating IP addresses - Nova does 
the assignment and sends out an unsolicited ARP response (assuming you have the 
send_arp_for_ha flag set) - this is in network/linux_net.bind_floating_ip().  
 However  sometimes an unsolicited APR response can get dropped in the network, 
ad so if the switch doesn't see this message and it already has a previous ARP 
mapping in its cache then it will continue to try and send traffic to the 
previous user of that address until the cache times out.

Note that some network failover systems send multiple requests to get more 
certainty around this (for example I've seen a VPN solution use 6 messages).

There are a couple of things you could try:


-  Add a flag to be able to increase the number of arp_responses sent

-  Change the allocation of floating_ips so that instead of picking the 
first free one in the DB you pick the one which has been unused for the longest 
time (reduces the risk of reusing an address before the switch times out the 
entry in its cache).

Phil

From: openstack-bounces+philip.day=hp@lists.launchpad.net 
[mailto:openstack-bounces+philip.day=hp@lists.launchpad.net] On Behalf Of 
Kevin Jackson
Sent: 28 March 2012 12:49
To: openstack@lists.launchpad.net
Subject: [Openstack] Auto Assigned Floating IPs take a long time to associate

Hi all,
I've got the following set in my nova.conf:

--auto_assign_floating_ip

and I fire up an instance.
Everything works, a private IP is assigned... the instance is running... but it 
can take an inordinate amount of time (anywhere upwards of 2 mins, sometimes a 
lot longer) to associate a floating IP automatically.

Anybody else experienced this?  Any clues on what I can do to troubleshoot 
this?  What is the condition when a Floating IP is assigned?  I've seen it 
assign Floating IPs very quickly when it is still Booting, not Active, say.
Is it dependent on anything within the Instance itself?

Cheers,

Kev
--
Kevin Jackson
@itarchitectkev
___
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] melange_ipam : get_tenant_id_by_net_id - possible bug (and fix)

2012-03-28 Thread Mandar Vaze

Troy,

I've setup nova+quantum+mélange using devstack.
devstack creates networks using tenant_id =default (This in itself looks 
incorrect, since it should be valid UUID for one of the tenant from keystone DB 
- but I can imagine that stack.sh can't get UUID for demo or admin tenants 
easily)

So I updated nova.networks, quantum.networks and mélange.ip_blocks tables 
manually and put tenant_id to use UUID of the demo tenant.
Question : What is the right way to create network entries for demo tenant, 
that are used by nova/quantum as well as mélange DB ?
(I tried mélange ip-block create for 10.0.0.0/24 but I got an error that that 
cidr is already being used (by tenant_id=default) - so I updated the DB 
manually. Also this would work only take care of mélange DB - what about nova 
and quantum DB ?)

Once I did these changes, my instances could not launch, they would get stuck 
in Networking/Error state - with NetworkNotFound error in the logs for 
network UUID which I know is valid for tenant demo

Tracing this further, I came across the following code which tries to 
get_allocated_ips for default tenant, before user specified project_id
In my opinion, this is incorrect.
Once I switched the order i.e. try project_id before default everything 
started working.

Please comment whether the following code change makes sense (I'm not even 
sure, if I were to submit this code change - what would I write in the bug 
description - hence need comments from you)

diff --git a/nova/network/quantum/melange_ipam_lib.py 
b/nova/network/quantum/melange_ipam_lib.py
index c68d83c..ea39f60 100644
--- a/nova/network/quantum/melange_ipam_lib.py
+++ b/nova/network/quantum/melange_ipam_lib.py
@@ -152,7 +152,8 @@ class QuantumMelangeIPAMLib(object):

 def get_tenant_id_by_net_id(self, context, net_id, vif_id, project_id):
 ipam_tenant_id = None
-tenant_ids = [FLAGS.quantum_default_tenant_id, project_id, None]
+#tenant_ids = [FLAGS.quantum_default_tenant_id, project_id, None]
+tenant_ids = [project_id,FLAGS.quantum_default_tenant_id, None]
 # This is confusing, if there are IPs for the given net, vif,
 # tenant trifecta we assume that is the tenant for that network
 for tid in tenant_ids:


Regards,
-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] Auto Assigned Floating IPs take a long time to associate

Cheers Phil,
It's not that I can't get to the instances - I'd assume it was an ARP issue
at that point - its the fact that Nova hasn't notified me that it has
assigned an IP address: see my additional note where I guessed an IP
address it would've assigned and I could access it... but management tools
were still blissfully unaware.
I used to have a working Diablo set up with pretty much this same set up
(this is under Essex RC1 / Ubuntu 12.04) and never had an issue.

This just looks like it has assigned the IP to the instance, but hasn't
notified the management underbelly of MySQL so any client tools
interrogating the instance doesn't see that nova has done this work already.

Kev

On 28 March 2012 13:04, Day, Phil philip@hp.com wrote:

 Are you sure that its Nova that is taking the time to associate the IP,
 and not an ARP issue in your network ?

 ** **

 I’ve seen this behaviour when quickly reusing floating IP addresses – Nova
 does the assignment and sends out an unsolicited ARP response (assuming you
 have the “send_arp_for_ha” flag set) – this is in
 network/linux_net.bind_floating_ip().   However  sometimes an unsolicited
 APR response can get dropped in the network, ad so if the switch doesn’t
 see this message and it already has a previous ARP mapping in its cache
 then it will continue to try and send traffic to the previous user of that
 address until the cache times out. 

 ** **

 Note that some network failover systems send multiple requests to get more
 certainty around this (for example I’ve seen a VPN solution use 6 messages).
 

 ** **

 There are a couple of things you could try:

 ** **

 **-  **Add a flag to be able to increase the number of
 arp_responses sent

 **-  **Change the allocation of floating_ips so that instead of
 picking the first free one in the DB you pick the one which has been unused
 for the longest time (reduces the risk of reusing an address before the
 switch times out the entry in its cache).

 ** **

 Phil

 ** **

 *From:* openstack-bounces+philip.day=hp@lists.launchpad.net [mailto:
 openstack-bounces+philip.day=hp@lists.launchpad.net] *On Behalf Of *Kevin
 Jackson
 *Sent:* 28 March 2012 12:49
 *To:* openstack@lists.launchpad.net
 *Subject:* [Openstack] Auto Assigned Floating IPs take a long time to
 associate

 ** **

 Hi all,

 I've got the following set in my nova.conf:

 ** **

 --auto_assign_floating_ip

 ** **

 and I fire up an instance.

 Everything works, a private IP is assigned... the instance is running...
 but it can take an inordinate amount of time (anywhere upwards of 2 mins,
 sometimes a lot longer) to associate a floating IP automatically.

 ** **

 Anybody else experienced this?  Any clues on what I can do to troubleshoot
 this?  What is the condition when a Floating IP is assigned?  I've seen it
 assign Floating IPs very quickly when it is still Booting, not Active, say.
 

 Is it dependent on anything within the Instance itself?

 ** **

 Cheers,

 ** **

 Kev

 --
 Kevin Jackson
 @itarchitectkev




-- 
Kevin Jackson
@itarchitectkev
___
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] KVM crash.

2012-03-28 Thread Guilherme Birk

No one is having this issue?

From: guib...@hotmail.com
To: openstack@lists.launchpad.net
Date: Fri, 23 Mar 2012 19:48:04 +
Subject: [Openstack] KVM crash.

I'm having problems with KVM on a single node installation. My problem is like 
these ones: 

https://bugzilla.kernel.org/show_bug.cgi?id=42703
http://www.spinics.net/lists/kvm/msg67635.html

The KVM normally crashes when I'm doing a load test with a large number of 
connections on the VM's.

This appears to not happen using a dual node installation, with the 
nova-compute running with a dedicated machine.

___
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] Auto Assigned Floating IPs take a long time to associate

I launched a new instance:


I ssh'd to 172.29.1.4 and my instance was running but nova list shows no
floating IP assigned.

nova list
+--+--++--+
|  ID  | Name | Status |
  Networks |
+--+--++--+
| ff796bfa-0582-4ccb-8af0-b112b0c15326 | test1| ACTIVE |
development=10.2.0.5 |
+--+--++--+

The database says this is assigned

mysql select * from floating_ips where address=172.29.1.4\G;
*** 1. row ***
   created_at: 2012-03-26 08:32:20
   updated_at: 2012-03-28 13:01:31
   deleted_at: NULL
  deleted: 0
   id: 4
  address: 172.29.1.4
  fixed_ip_id: 1030
   project_id: 01b1e8df305b49998e6ecbac02cb9f70
 host: openstack1
auto_assigned: 1
 pool: nova
interface: eth5
1 row in set (0.00 sec)

Cheers,

Kev

On 28 March 2012 14:00, Day, Phil philip@hp.com wrote:

 Hum – very odd.   Have you looked in the DB tables to see if its assigned
 properly in there ? If its not getting assigned in the DB then there’s
 a risk that it could be used again by the next instance.

 ** **

 *From:* uksysad...@gmail.com [mailto:uksysad...@gmail.com] *On Behalf Of 
 *Kevin
 Jackson
 *Sent:* 28 March 2012 13:58
 *To:* Day, Phil
 *Cc:* openstack@lists.launchpad.net
 *Subject:* Re: [Openstack] Auto Assigned Floating IPs take a long time to
 associate

 ** **

 Cheers Phil,

 It's not that I can't get to the instances - I'd assume it was an ARP
 issue at that point - its the fact that Nova hasn't notified me that it has
 assigned an IP address: see my additional note where I guessed an IP
 address it would've assigned and I could access it... but management tools
 were still blissfully unaware.

 I used to have a working Diablo set up with pretty much this same set up
 (this is under Essex RC1 / Ubuntu 12.04) and never had an issue.

 ** **

 This just looks like it has assigned the IP to the instance, but hasn't
 notified the management underbelly of MySQL so any client tools
 interrogating the instance doesn't see that nova has done this work already.
 

 ** **

 Kev

 On 28 March 2012 13:04, Day, Phil philip@hp.com wrote:

 Are you sure that its Nova that is taking the time to associate the IP,
 and not an ARP issue in your network ?

  

 I’ve seen this behaviour when quickly reusing floating IP addresses – Nova
 does the assignment and sends out an unsolicited ARP response (assuming you
 have the “send_arp_for_ha” flag set) – this is in
 network/linux_net.bind_floating_ip().   However  sometimes an unsolicited
 APR response can get dropped in the network, ad so if the switch doesn’t
 see this message and it already has a previous ARP mapping in its cache
 then it will continue to try and send traffic to the previous user of that
 address until the cache times out. 

  

 Note that some network failover systems send multiple requests to get more
 certainty around this (for example I’ve seen a VPN solution use 6 messages).
 

  

 There are a couple of things you could try:

  

 -  Add a flag to be able to increase the number of arp_responses
 sent

 -  Change the allocation of floating_ips so that instead of
 picking the first free one in the DB you pick the one which has been unused
 for the longest time (reduces the risk of reusing an address before the
 switch times out the entry in its cache).

  

 Phil

  

 *From:* openstack-bounces+philip.day=hp@lists.launchpad.net [mailto:
 openstack-bounces+philip.day=hp@lists.launchpad.net] *On Behalf Of *Kevin
 Jackson
 *Sent:* 28 March 2012 12:49
 *To:* openstack@lists.launchpad.net
 *Subject:* [Openstack] Auto Assigned Floating IPs take a long time to
 associate

  

 Hi all,

 I've got the following set in my nova.conf:

  

 --auto_assign_floating_ip

  

 and I fire up an instance.

 Everything works, a private IP is assigned... the instance is running...
 but it can take an inordinate amount of time (anywhere upwards of 2 mins,
 sometimes a lot longer) to associate a floating IP automatically.

  

 Anybody else experienced this?  Any clues on what I can do to troubleshoot
 this?  What is the condition when a Floating IP is assigned?  I've seen it
 assign Floating IPs very quickly when it is still Booting, not Active, say.
 

 Is it dependent on anything within the Instance itself?

  

 Cheers,

  

 Kev

 --
 Kevin Jackson
 @itarchitectkev



 

 ** **

 --
 Kevin Jackson
 @itarchitectkev




-- 
Kevin Jackson
@itarchitectkev
___

Re: [Openstack] Auto Assigned Floating IPs take a long time to associate

2012-03-28 Thread Kiall Mac Innes

stab in the dark
Have you kept an eye on the mysql table itself, rather than relying on the
cli tools / dashboard that may very well cache the data?
/stab in the dark

Thanks,
Kiall


On Wed, Mar 28, 2012 at 1:58 PM, Kevin Jackson ke...@linuxservices.co.ukwrote:

 Cheers Phil,
 It's not that I can't get to the instances - I'd assume it was an ARP
 issue at that point - its the fact that Nova hasn't notified me that it has
 assigned an IP address: see my additional note where I guessed an IP
 address it would've assigned and I could access it... but management tools
 were still blissfully unaware.
 I used to have a working Diablo set up with pretty much this same set up
 (this is under Essex RC1 / Ubuntu 12.04) and never had an issue.

 This just looks like it has assigned the IP to the instance, but hasn't
 notified the management underbelly of MySQL so any client tools
 interrogating the instance doesn't see that nova has done this work already.

 Kev


 On 28 March 2012 13:04, Day, Phil philip@hp.com wrote:

 Are you sure that its Nova that is taking the time to associate the IP,
 and not an ARP issue in your network ?

 ** **

 I’ve seen this behaviour when quickly reusing floating IP addresses –
 Nova does the assignment and sends out an unsolicited ARP response
 (assuming you have the “send_arp_for_ha” flag set) – this is in
 network/linux_net.bind_floating_ip().   However  sometimes an unsolicited
 APR response can get dropped in the network, ad so if the switch doesn’t
 see this message and it already has a previous ARP mapping in its cache
 then it will continue to try and send traffic to the previous user of that
 address until the cache times out. 

 ** **

 Note that some network failover systems send multiple requests to get
 more certainty around this (for example I’ve seen a VPN solution use 6
 messages).

 ** **

 There are a couple of things you could try:

 ** **

 **-  **Add a flag to be able to increase the number of
 arp_responses sent

 **-  **Change the allocation of floating_ips so that instead of
 picking the first free one in the DB you pick the one which has been unused
 for the longest time (reduces the risk of reusing an address before the
 switch times out the entry in its cache).

 ** **

 Phil

 ** **

 *From:* openstack-bounces+philip.day=hp@lists.launchpad.net [mailto:
 openstack-bounces+philip.day=hp@lists.launchpad.net] *On Behalf Of *Kevin
 Jackson
 *Sent:* 28 March 2012 12:49
 *To:* openstack@lists.launchpad.net
 *Subject:* [Openstack] Auto Assigned Floating IPs take a long time to
 associate

 ** **

 Hi all,

 I've got the following set in my nova.conf:

 ** **

 --auto_assign_floating_ip

 ** **

 and I fire up an instance.

 Everything works, a private IP is assigned... the instance is running...
 but it can take an inordinate amount of time (anywhere upwards of 2 mins,
 sometimes a lot longer) to associate a floating IP automatically.

 ** **

 Anybody else experienced this?  Any clues on what I can do to
 troubleshoot this?  What is the condition when a Floating IP is assigned?
  I've seen it assign Floating IPs very quickly when it is still Booting,
 not Active, say.

 Is it dependent on anything within the Instance itself?

 ** **

 Cheers,

 ** **

 Kev

 --
 Kevin Jackson
 @itarchitectkev




 --
 Kevin Jackson
 @itarchitectkev

 ___
 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] Auto Assigned Floating IPs take a long time to associate

It does appear that the database is updated (see a reply a few moments ago)
at the correct point... an explanation of what the tool is/isn't doing will
go a long way in helping me work out what I should be using the tools for /
configuration.
To an end user - it appears to take anywhere between a few minutes and 10
mins before an instance is accessible - but looking at what is happening
the instance is ready within seconds - so something is amiss with the
supplied tools.

Cheers,

Kev

On 28 March 2012 14:11, Kiall Mac Innes ki...@managedit.ie wrote:

 stab in the dark
 Have you kept an eye on the mysql table itself, rather than relying on the
 cli tools / dashboard that may very well cache the data?
 /stab in the dark

 Thanks,
 Kiall


 On Wed, Mar 28, 2012 at 1:58 PM, Kevin Jackson 
 ke...@linuxservices.co.ukwrote:

 Cheers Phil,
 It's not that I can't get to the instances - I'd assume it was an ARP
 issue at that point - its the fact that Nova hasn't notified me that it has
 assigned an IP address: see my additional note where I guessed an IP
 address it would've assigned and I could access it... but management tools
 were still blissfully unaware.
 I used to have a working Diablo set up with pretty much this same set up
 (this is under Essex RC1 / Ubuntu 12.04) and never had an issue.

 This just looks like it has assigned the IP to the instance, but hasn't
 notified the management underbelly of MySQL so any client tools
 interrogating the instance doesn't see that nova has done this work already.

 Kev


 On 28 March 2012 13:04, Day, Phil philip@hp.com wrote:

 Are you sure that its Nova that is taking the time to associate the IP,
 and not an ARP issue in your network ?

 ** **

 I’ve seen this behaviour when quickly reusing floating IP addresses –
 Nova does the assignment and sends out an unsolicited ARP response
 (assuming you have the “send_arp_for_ha” flag set) – this is in
 network/linux_net.bind_floating_ip().   However  sometimes an unsolicited
 APR response can get dropped in the network, ad so if the switch doesn’t
 see this message and it already has a previous ARP mapping in its cache
 then it will continue to try and send traffic to the previous user of that
 address until the cache times out. 

 ** **

 Note that some network failover systems send multiple requests to get
 more certainty around this (for example I’ve seen a VPN solution use 6
 messages).

 ** **

 There are a couple of things you could try:

 ** **

 **-  **Add a flag to be able to increase the number of
 arp_responses sent

 **-  **Change the allocation of floating_ips so that instead of
 picking the first free one in the DB you pick the one which has been unused
 for the longest time (reduces the risk of reusing an address before the
 switch times out the entry in its cache).

 ** **

 Phil

 ** **

 *From:* openstack-bounces+philip.day=hp@lists.launchpad.net [mailto:
 openstack-bounces+philip.day=hp@lists.launchpad.net] *On Behalf Of 
 *Kevin
 Jackson
 *Sent:* 28 March 2012 12:49
 *To:* openstack@lists.launchpad.net
 *Subject:* [Openstack] Auto Assigned Floating IPs take a long time to
 associate

 ** **

 Hi all,

 I've got the following set in my nova.conf:

 ** **

 --auto_assign_floating_ip

 ** **

 and I fire up an instance.

 Everything works, a private IP is assigned... the instance is running...
 but it can take an inordinate amount of time (anywhere upwards of 2 mins,
 sometimes a lot longer) to associate a floating IP automatically.

 ** **

 Anybody else experienced this?  Any clues on what I can do to
 troubleshoot this?  What is the condition when a Floating IP is assigned?
  I've seen it assign Floating IPs very quickly when it is still Booting,
 not Active, say.

 Is it dependent on anything within the Instance itself?

 ** **

 Cheers,

 ** **

 Kev

 --
 Kevin Jackson
 @itarchitectkev




 --
 Kevin Jackson
 @itarchitectkev

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





-- 
Kevin Jackson
@itarchitectkev
___
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] problem ssh-ing into vms

2012-03-28 Thread Pierre Amadio

Hi there !

I'm puzzled with a ssh issue. Things used to work before, and now, i
cannot access my vms anymore.

I experience the same problem on both diablo (on ubuntu oneiric) and
essex (ubuntu precise).

I generate a ssh key:

euca-add-keypair mykey  ~/creds/testkey.priv
chmod 0600 ~/creds/testkey.priv

It looks like the following:

ubuntu@manager-node:~/creds$ cat testkey.priv
KEYPAIR testkey d5:47:1e:61:53:3d:36:61:1a:08:e9:00:a1:80:8d:a9
-BEGIN RSA PRIVATE KEY-
MIICXAIBAAKBgQDS7d774T5M7kQR1ExJBD2+19Bf2GbYgwM9d/LZMmVVf3VpYWCq
PXMAelR2nupAxpq68aWHiR4aL//8KZ6FomIxbLGbbzJpyYHowUe8qNlHSrcQrow2
XAu27w7GElfmq22nU/454oavSWu50pk8xLMwyRVh7/9+0ErxIoKmQxlvqwIDAQAB
AoGAX7h9Idc0+5qBH4o1WElpb+rmcCh3e7fwx3tgpLpfDC68bKc5Q+iBAO2C2RYC
/oRigYXZ9aj/FSlFRPzqKIDph+tMRZqWtG+1U49+iTRo5mzwG3xCgmDgtOhfM54Q
ywJSZAuxZbBSNKOgZ0+iB48pZevGqWhcMviK6Wg5uyl746kCQQDyyD4PVKmELwSs
mBfxqd02FS7oDKT5ZWg0o21ShiRkg0LTZ2rXFZYWUkBnH7ZXmtR3myj/mFSUH4HR
qOniOWktAkEA3mmuBU1xk33rEl6sg7pRP7nrYNv5XvkzdWBfPLZ41ek1zhsSEPXP
vBtnJ3IPhLtsU7Xc+8BR8/PY2l12xDuTNwJACUW6kQ1TuBevnwPkDjfFmhYvB2/M
MTY9R51iRH+ZDjmxKK/Pdc1+QPX9PbMJXMkuCi9j3ncr68hURfSkkh5NNQJAHXXw
KCGm/rt6LNe/kD9YzdEpvY3FzW/DAjQ+yUL+ZI9coi1xyi9VUfxrQI1aQuG0qq33
VJ2X/XF6cwpYVgvyJwJBAM5nHXhK2vBwsDc3nPByVG4mOjCC+i3I+Q6Du171QpNH
Jj5H9deWAF9i5dQcrdRO7uHp8NVxTt2z9GHh8fNp2qM=
-END RSA PRIVATE KEY-

The key seems to be known by euca-tools.

ubuntu@manager-node:~/creds$ euca-describe-keypairs
KEYPAIR testkey d5:47:1e:61:53:3d:36:61:1a:08:e9:00:a1:80:8d:a9

I launch a vm with:


euca-run-instances -k testkey ami-0005

The vms itself is an instance of

http://cloud-images.ubuntu.com/oneiric/current/oneiric-server-cloudimg-amd64.tar.gz

Now, when i try to connect to the vm, i have the following error message:

ubuntu@manager-node:~/creds$ ssh - -i testkey.priv ubuntu@192.168.123.5
OpenSSH_5.9p1 Debian-4ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.123.5 [192.168.123.5] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load testkey.priv as a RSA1 public key
debug3: key_read: missing whitespace
debug1: identity file testkey.priv type -1
debug1: identity file testkey.priv-cert type -1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_5.8p1 Debian-7ubuntu1
debug1: match: OpenSSH_5.8p1 Debian-7ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-4ubuntu1
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer

Why is it mentionning the following ?

debug3: Could not load testkey.priv as a RSA1 public key

Is not testkey.priv supposed to be a _private_ key instead ?

euca-get-console-output i-0003 for the involved node is attached.

ubuntu@manager-node:~/creds$ euca-describe-instances
RESERVATION r-nu11r90h  2252de9d285c4400a2ef87845f971ef7
default
INSTANCEi-0003  ami-0005192.168.123.5   server-3
   running testkey (2252de9d285c4400a2ef87845f971ef7, compute-a)   0
  m1.small2012-03-28T13:08:35.000Znova
aki-0004ari-0003monitoring-disabled
192.168.123.5   10.0.0.3instance-store

Any idea what i could do wrong ?









ubuntu@manager-node:~/creds$ euca-get-console-output i-0003
i-0003
2012-03-28T13:19:50.482Z
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.0.0-16-virtual (buildd@roseapple) (gcc version 
4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) ) #29-Ubuntu SMP Tue Feb 14 13:27:41 UTC 
2012 (Ubuntu 3.0.0-16.29-virtual 3.0.20)
[0.00] Command line: root=/dev/vda console=ttyS0
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   Centaur CentaurHauls
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 0009bc00 (usable)
[0.00]  BIOS-e820: 0009bc00 - 000a (reserved)
[0.00]  BIOS-e820: 000f - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - 7fffd000 (usable)
[0.00]  BIOS-e820: 7fffd000 - 8000 (reserved)
[0.00]  BIOS-e820: fffc - 0001 (reserved)
[0.00] NX (Execute Disable) protection: active
[0.00] DMI 2.4 present.
[0.00] No AGP bridge found
[0.00] last_pfn = 0x7fffd max_arch_pfn = 0x4
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] found SMP MP-table at [880fdae0] fdae0
[0.00] init_memory_mapping: -7fffd000
[0.00] RAMDISK: 7ffd9000 - 7fff
[

Re: [Openstack] Auto Assigned Floating IPs take a long time to associate

I've raised https://bugs.launchpad.net/nova/+bug/967166 to track this issue.

Kev

On 28 March 2012 14:16, Kevin Jackson ke...@linuxservices.co.uk wrote:

 It does appear that the database is updated (see a reply a few moments
 ago) at the correct point... an explanation of what the tool is/isn't doing
 will go a long way in helping me work out what I should be using the tools
 for / configuration.
 To an end user - it appears to take anywhere between a few minutes and 10
 mins before an instance is accessible - but looking at what is happening
 the instance is ready within seconds - so something is amiss with the
 supplied tools.

 Cheers,

 Kev


 On 28 March 2012 14:11, Kiall Mac Innes ki...@managedit.ie wrote:

 stab in the dark
 Have you kept an eye on the mysql table itself, rather than relying on
 the cli tools / dashboard that may very well cache the data?
 /stab in the dark

 Thanks,
 Kiall


 On Wed, Mar 28, 2012 at 1:58 PM, Kevin Jackson ke...@linuxservices.co.uk
  wrote:

 Cheers Phil,
 It's not that I can't get to the instances - I'd assume it was an ARP
 issue at that point - its the fact that Nova hasn't notified me that it has
 assigned an IP address: see my additional note where I guessed an IP
 address it would've assigned and I could access it... but management tools
 were still blissfully unaware.
 I used to have a working Diablo set up with pretty much this same set up
 (this is under Essex RC1 / Ubuntu 12.04) and never had an issue.

 This just looks like it has assigned the IP to the instance, but hasn't
 notified the management underbelly of MySQL so any client tools
 interrogating the instance doesn't see that nova has done this work already.

 Kev


 On 28 March 2012 13:04, Day, Phil philip@hp.com wrote:

 Are you sure that its Nova that is taking the time to associate the IP,
 and not an ARP issue in your network ?

 ** **

 I’ve seen this behaviour when quickly reusing floating IP addresses –
 Nova does the assignment and sends out an unsolicited ARP response
 (assuming you have the “send_arp_for_ha” flag set) – this is in
 network/linux_net.bind_floating_ip().   However  sometimes an unsolicited
 APR response can get dropped in the network, ad so if the switch doesn’t
 see this message and it already has a previous ARP mapping in its cache
 then it will continue to try and send traffic to the previous user of that
 address until the cache times out. 

 ** **

 Note that some network failover systems send multiple requests to get
 more certainty around this (for example I’ve seen a VPN solution use 6
 messages).

 ** **

 There are a couple of things you could try:

 ** **

 **-  **Add a flag to be able to increase the number of
 arp_responses sent

 **-  **Change the allocation of floating_ips so that instead
 of picking the first free one in the DB you pick the one which has been
 unused for the longest time (reduces the risk of reusing an address before
 the switch times out the entry in its cache).

 ** **

 Phil

 ** **

 *From:* openstack-bounces+philip.day=hp@lists.launchpad.net[mailto:
 openstack-bounces+philip.day=hp@lists.launchpad.net] *On Behalf Of
 *Kevin Jackson
 *Sent:* 28 March 2012 12:49
 *To:* openstack@lists.launchpad.net
 *Subject:* [Openstack] Auto Assigned Floating IPs take a long time to
 associate

 ** **

 Hi all,

 I've got the following set in my nova.conf:

 ** **

 --auto_assign_floating_ip

 ** **

 and I fire up an instance.

 Everything works, a private IP is assigned... the instance is
 running... but it can take an inordinate amount of time (anywhere upwards
 of 2 mins, sometimes a lot longer) to associate a floating IP 
 automatically.
 

 ** **

 Anybody else experienced this?  Any clues on what I can do to
 troubleshoot this?  What is the condition when a Floating IP is assigned?
  I've seen it assign Floating IPs very quickly when it is still Booting,
 not Active, say.

 Is it dependent on anything within the Instance itself?

 ** **

 Cheers,

 ** **

 Kev

 --
 Kevin Jackson
 @itarchitectkev




 --
 Kevin Jackson
 @itarchitectkev

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





 --
 Kevin Jackson
 @itarchitectkev




-- 
Kevin Jackson
@itarchitectkev
___
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] problem ssh-ing into vms

2012-03-28 Thread Scott Moser

On Wed, 28 Mar 2012, Pierre Amadio wrote:

 Hi there !

 I'm puzzled with a ssh issue. Things used to work before, and now, i
 cannot access my vms anymore.

Thank you for attaching euca-get-console-output.  That provides the real
hint here.

| cloud-init start-local running: Wed, 28 Mar 2012 13:09:35 +. up 43.07 
seconds
| no instance data found in start-local
| ci-info: lo: 1 127.0.0.1   255.0.0.0
| ci-info: eth0  : 1 10.0.0.3255.255.255.0   fa:16:3e:59:63:1b
| ci-info: route-0: 0.0.0.0 10.0.0.10.0.0.0 eth0   UG
| ci-info: route-1: 10.0.0.00.0.0.0 255.255.255.0   eth0   U
| cloud-init start running: Wed, 28 Mar 2012 13:09:48 +. up 56.41 seconds
| 2012-03-28 13:09:49,331 - DataSourceEc2.py[WARNING]: 'http://169.254.169.254' 
failed: url error [[Errno 111] Connection refused]
| 2012-03-28 13:09:50,349 - DataSourceEc2.py[WARNING]: 'http://169.254.169.254' 
failed: url error [[Errno 111] Connection refused]
| ...
| 2012-03-28 13:11:29,162 - DataSourceEc2.py[WARNING]: 'http://169.254.169.254' 
failed: url error [[Errno 111] Connection refused]
| 2012-03-28 13:11:35,174 - DataSourceEc2.py[CRITICAL]: giving up on md after 
105 seconds

The instance was unable to connect to the metadata service to get your
public keys and put them into the instance.  The Ubuntu images have an
annoyance, in that if it can't get to the MD it doesn't even generate ssh
server keys, so the ssh server just drops you immediately.

But your real problem is that the guests can't see the host.

You could potentially debug some more by using a cirros image, which will
let you do password auth in after it fails to reach the data source.

___
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] problem ssh-ing into vms

2012-03-28 Thread Yong Sheng Gong

It seems iptables or some other similar software are no running on your host. openstack relies on it to translate 169.254.169.254 to host address.-openstack-bounces+gongysh=cn.ibm@lists.launchpad.net wrote: -To: Pierre Amadio pierre.ama...@canonical.comFrom: Scott Moser smo...@ubuntu.comSent by: openstack-bounces+gongysh=cn.ibm@lists.launchpad.netDate: 03/28/2012 10:16PMCc: openstack openstack@lists.launchpad.netSubject: Re: [Openstack] problem  ssh-ing into vmsOn Wed, 28 Mar 2012, Pierre Amadio wrote: Hi there ! I'm puzzled with a ssh issue. Things used to work "before", and now, i cannot access my vms anymore.Thank you for attaching euca-get-console-output. That provides the realhint here.| cloud-init start-local running: Wed, 28 Mar 2012 13:09:35 +. up 43.07 seconds| no instance data found in start-local| ci-info: lo  : 1 127.0.0.1255.0.0.0| ci-info: eth0 : 1 10.0.0.3255.255.255.0  fa:16:3e:59:63:1b| ci-info: route-0: 0.0.0.0 10.0.0.10.0.0.0 eth0  UG| ci-info: route-1: 10.0.0.00.0.0.0 255.255.255.0  eth0  U| cloud-init start running: Wed, 28 Mar 2012 13:09:48 +. up 56.41 seconds| 2012-03-28 13:09:49,331 - DataSourceEc2.py[WARNING]: 'http://169.254.169.254' failed: url error [[Errno 111] Connection refused]| 2012-03-28 13:09:50,349 - DataSourceEc2.py[WARNING]: 'http://169.254.169.254' failed: url error [[Errno 111] Connection refused]| ...| 2012-03-28 13:11:29,162 - DataSourceEc2.py[WARNING]: 'http://169.254.169.254' failed: url error [[Errno 111] Connection refused]| 2012-03-28 13:11:35,174 - DataSourceEc2.py[CRITICAL]: giving up on md after 105 secondsThe instance was unable to connect to the metadata service to get yourpublic keys and put them into the instance. The Ubuntu images have anannoyance, in that if it can't get to the MD it doesn't even generate sshserver keys, so the ssh server just drops you immediately.But your real problem is that the guests can't see the host.You could potentially debug some more by using a cirros image, which willlet you do password auth in after it fails to reach the data source.___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

Re: [Openstack] problem ssh-ing into vms

2012-03-28 Thread Pierre Amadio

Hi there !

 | 2012-03-28 13:11:29,162 - DataSourceEc2.py[WARNING]: 
 'http://169.254.169.254' failed: url error [[Errno 111] Connection refused]
 | 2012-03-28 13:11:35,174 - DataSourceEc2.py[CRITICAL]: giving up on md after 
 105 seconds
 
 The instance was unable to connect to the metadata service to get your
 public keys and put them into the instance.  The Ubuntu images have an
 annoyance, in that if it can't get to the MD it doesn't even generate ssh
 server keys, so the ssh server just drops you immediately.
 
 But your real problem is that the guests can't see the host.
 

Thanks, this helped a lot.

The vm was on a node running nova-compute and nova-network only.

Turned out the metadata service was available after i have started
nova-api on top of that.

I though nova-api was not needed on boxes running nova-compute ? (i have
it running on a manager node that do not launch vms).

Was my assumption wrong or is there something special to do to have the
metadata service available without running nova-api ?




___
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] wrong IP given by flat network dhcp

2012-03-28 Thread Michaël Van de Borne


Hello,

I installed Essex on Ubuntu 12.04 Server, and I had a problem with VM IP.

The IP given to the VM (10.18.9.2) isn't in the fixed_range. Here's a 
portion of nova.conf:


# cat /etc/nova/nova.conf
[...]
--network_manager=nova.network.manager.FlatDHCPManager
--public_interface=eth0
--flat_interface=eth1
--flat_network_bridge=br100
--fixed_range=10.18.9.32/27
--floating_range=172.22.22.32/27
--network_size=32
--flat_network_dhcp_start=10.18.9.33

and here's the host network config:

# cat /etc/network/interfaces
auto eth0
iface eth0 inet static
address 172.22.22.1
gateway 172.22.0.1
netmask 255.255.0.0
network 172.22.0.0
broadcast 172.22.255.255

auto eth1
iface eth1 inet static
address 10.18.9.1
netmask 255.255.0.0
network 10.18.0.0
broadcast 10.18.255.255

Then I deployed another VM, and I was given IP 10.18.9.3. Here's an 
excerpt of /var/log/nova/nova-network.log when I deployed this machine:


2012-03-28 17:29:16 DEBUG nova.rpc.amqp [-] received {u'_context_roles': 
[u'admin'], u'_context_request_id': 
u'req-aa77b53c-be43-4b4e-bf82-98f62bff7f52', u'_context_read_deleted': 
u'no', u'args': {u'address': u'10.18.9.3'}, u'_context_auth_token': 
None, u'_context_is_admin': True, u'_context_project_id': None, 
u'_context_timestamp': u'2012-03-28T15:29:16.569136', 
u'_context_user_id': None, u'method': u'lease_fixed_ip', 
u'_context_remote_address': None} from (pid=17249) _safe_log 
/usr/lib/python2.7/dist-packages/nova/rpc/common.py:144
2012-03-28 17:29:16 DEBUG nova.rpc.amqp 
[req-aa77b53c-be43-4b4e-bf82-98f62bff7f52 None None] unpacked context: 
{'request_id': u'req-aa77b53c-be43-4b4e-bf82-98f62bff7f52', 'user_id': 
None, 'roles': [u'admin'], 'timestamp': '2012-03-28T15:29:16.569136', 
'is_admin': True, 'auth_token': None, 'project_id': None, 
'remote_address': None, 'read_deleted': u'no'} from (pid=17249) 
unpack_context /usr/lib/python2.7/dist-packages/nova/rpc/amqp.py:188
2012-03-28 17:29:16 DEBUG nova.network.manager 
[req-aa77b53c-be43-4b4e-bf82-98f62bff7f52 None None] Leased IP 
|10.18.9.3| from (pid=17249) lease_fixed_ip 
/usr/lib/python2.7/dist-packages/nova/network/manager.py:1222
2012-03-28 17:29:16 DEBUG nova.rpc.amqp [-] received {u'_context_roles': 
[u'admin'], u'_msg_id': u'ba410b9f98c04023b68f6ea6e95d775e', 
u'_context_read_deleted': u'no', u'_context_request_id': 
u'req-11a728d5-d7f5-4c65-a2ce-6d958585e574', u'args': {u'address': 
u'10.18.9.3'}, u'_context_auth_token': None, u'_context_is_admin': True, 
u'_context_project_id': None, u'_context_timestamp': 
u'2012-03-28T15:29:16.820602', u'_context_user_id': None, u'method': 
u'get_fixed_ip_by_address', u'_context_remote_address': None} from 
(pid=17249) _safe_log 
/usr/lib/python2.7/dist-packages/nova/rpc/common.py:144
2012-03-28 17:29:16 DEBUG nova.rpc.amqp 
[req-11a728d5-d7f5-4c65-a2ce-6d958585e574 None None] unpacked context: 
{'request_id': u'req-11a728d5-d7f5-4c65-a2ce-6d958585e574', 'user_id': 
None, 'roles': [u'admin'], 'timestamp': '2012-03-28T15:29:16.820602', 
'is_admin': True, 'auth_token': None, 'project_id': None, 
'remote_address': None, 'read_deleted': u'no'} from (pid=17249) 
unpack_context /usr/lib/python2.7/dist-packages/nova/rpc/amqp.py:188
2012-03-28 17:29:40 DEBUG nova.rpc.amqp [-] received {u'_context_roles': 
[u'admin'], u'_msg_id': u'50999ff995cd4f7e8e441885d3ada543', 
u'_context_read_deleted': u'no', u'_context_request_id': 
u'req-563547e8-6f6f-43b1-9449-681ff43dad33', u'args': {u'instance_id': 
3, u'instance_uuid': u'b7ec8623-e002-4682-a37b-50e1d047c134', u'host': 
u'openstack1', u'project_id': u'0a9e24ccc1ac46eea75154c85bb4052e', 
u'rxtx_factor': 1.0}, u'_context_auth_token': None, 
u'_context_is_admin': True, u'_context_project_id': None, 
u'_context_timestamp': u'2012-03-28T15:29:31.151885', 
u'_context_user_id': None, u'method': u'get_instance_nw_info', 
u'_context_remote_address': None} from (pid=17249) _safe_log 
/usr/lib/python2.7/dist-packages/nova/rpc/common.py:144



what am I doing wrong?


--
Michaël Van de Borne
RD Engineer, SOA team, CETIC
Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli
www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi


___
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] problem ssh-ing into vms

2012-03-28 Thread Yong Sheng Gong

http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-openstack-compute-basics.html#configuring-multiple-compute-nodes:If you want to use the 10.04 Ubuntu Enterprise Cloud images that are readily available at http://uec-images.ubuntu.com/releases/10.04/release/, you may run into delays with booting. Any server that does not have nova-api running on it needs this iptables entry so that UEC images can get metadata info. On compute nodes, configure the iptables with this next step:# iptables -t nat -A PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination $NOVA_API_IP:8773-openstack-bounces+gongysh=cn.ibm@lists.launchpad.net wrote: -To: openstack openstack@lists.launchpad.netFrom: Pierre Amadio pierre.ama...@canonical.comSent by: openstack-bounces+gongysh=cn.ibm@lists.launchpad.netDate: 03/28/2012 11:01PMSubject: Re: [Openstack] problem  ssh-ing into vmsHi there ! | 2012-03-28 13:11:29,162 - DataSourceEc2.py[WARNING]: 'http://169.254.169.254' failed: url error [[Errno 111] Connection refused] | 2012-03-28 13:11:35,174 - DataSourceEc2.py[CRITICAL]: giving up on md after 105 seconds  The instance was unable to connect to the metadata service to get your public keys and put them into the instance. The Ubuntu images have an annoyance, in that if it can't get to the MD it doesn't even generate ssh server keys, so the ssh server just drops you immediately.  But your real problem is that the guests can't see the host. Thanks, this helped a lot.The vm was on a node running nova-compute and nova-network only.Turned out the metadata service was available after i have startednova-api on top of that.I though nova-api was not needed on boxes running nova-compute ? (i haveit running on a "manager" node that do not launch vms).Was my assumption wrong or is there something special to do to have themetadata service available without running nova-api ?___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

Re: [Openstack] melange_ipam : get_tenant_id_by_net_id - possible bug (and fix)

2012-03-28 Thread Jason Kölker

Hi Mandar,

Thanks for taking the time to look into Melange! Currently Nova +
Quantum + Melange is in a huge state of development flux. The current
code gets us enough to play with some features and be backwards
compatible with all the features in the legacy network managers. In
the Folsom development cycle many things in regards to QuantumManager
will be changing. See below for (some) specifics.

On Wed, 2012-03-28 at 05:20 -0700, Mandar Vaze wrote:
 I've setup nova+quantum+mélange using devstack.
 devstack creates networks using tenant_id =default (This in itself
 looks incorrect, since it should be valid UUID for one of the tenant
 from keystone DB - but I can imagine that stack.sh can't get UUID for
 demo or admin tenants easily)

Since nova-manage doesn't do any auth, the project_id in the call to
create the initial network is None, this triggers the QuantumManager to
fall back to using the value of FLAGS.quantum_default_tenant_id which
defaults to the value 'default'.

There really isn't a good way to get around this right now (without
manually specifying the project_id as mentioned below). Since some data
is stored in the Nova networks table, some in melange and some
(possibly) by whatever quantum plugin is running.

In the next iteration, using nova-manage to create Quantum/Melange
blocks magically in the background will be removed, and will require
that each service be setup through their native tools/apis.

 So I updated nova.networks, quantum.networks and mélange.ip_blocks
 tables manually and put tenant_id to use UUID of the demo tenant.
 Question : What is the right way to create network entries for demo
 tenant, that are used by nova/quantum as well as mélange DB ?

I think (although never tried) you can pass --project_id to nova-manage
and it should create it with the right tentat_id.

 (I tried mélange ip-block create for 10.0.0.0/24 but I got an error
 that that cidr is already being used (by tenant_id=default) - so I
 updated the DB manually. Also this would work only take care of
 mélange DB - what about nova and quantum DB ?)

You can pass the -t flag to the melange cli to switch the tenant name.
The quantum and nova db's will need to be updated manually at the
moment.

 Once I did these changes, my instances could not launch, they would
 get stuck in Networking/Error state - with NetworkNotFound error in
 the logs for network UUID which I know is valid for tenant demo

So depending on where the error was poping up at, it might have been
that it was getting a UUID where the code was expecting the network id
from the nova table.

This is part of the problem of having 3 masters of information, and work
has begin to reduce this to 2 and eventually just 1 with melange merging
with quantum.

 Tracing this further, I came across the following code which tries to
 get_allocated_ips for default tenant, before user specified
 project_id
 In my opinion, this is incorrect.
 Once I switched the order i.e. try project_id before default
 everything started working.
 
 Please comment whether the following code change makes sense (I'm not
 even sure, if I were to submit this code change - what would I write
 in the bug description - hence need comments from you)
 
 diff --git a/nova/network/quantum/melange_ipam_lib.py 
 b/nova/network/quantum/melange_ipam_lib.py
 index c68d83c..ea39f60 100644
 --- a/nova/network/quantum/melange_ipam_lib.py
 +++ b/nova/network/quantum/melange_ipam_lib.py
 @@ -152,7 +152,8 @@ class QuantumMelangeIPAMLib(object):
 
  def get_tenant_id_by_net_id(self, context, net_id, vif_id, project_id):
  ipam_tenant_id = None
 -tenant_ids = [FLAGS.quantum_default_tenant_id, project_id, None]
 +#tenant_ids = [FLAGS.quantum_default_tenant_id, project_id, None]
 +tenant_ids = [project_id,FLAGS.quantum_default_tenant_id, None]
  # This is confusing, if there are IPs for the given net, vif,
  # tenant trifecta we assume that is the tenant for that network
  for tid in tenant_ids:

The order shouldn't matter since the idea is to match the first block
that the network exists in. The problem is that its triggering moving on
to the next block in the list via a KeyError which won't be caught if
the default_tenant_id lookup throws a 404 (which it will if the block
doesn't exist ;).

If you change the `except KeyError` to `except Exception` since the
melange_connection raises a bare Exception when the response is  400.

I filed bug 967261 at https://bugs.launchpad.net/nova/+bug/967261 and
submitted the fix at https://review.openstack.org/5912 .

The current QuantumManger tries (much like nova) to be very flexible and
make no assumptions about how things are setup. I've been playing with a
new network manager that I would like to see as the next iteration of
Quantum + Melange + Nova that is very opinionated and stripped down. It
assumes you are using melange and quantum only, it only communicates
with nova over rpc (no nova db tables are

Re: [Openstack] KVM crash.

This was discussed on the mailing list earlier I believe:

http://www.mail-archive.com/openstack@lists.launchpad.net/msg08475.html

The solution appears to be to upgrade to a newer libvirt.

Vish

On Mar 28, 2012, at 6:01 AM, Guilherme Birk wrote:

 No one is having this issue?
 
 From: guib...@hotmail.com
 To: openstack@lists.launchpad.net
 Date: Fri, 23 Mar 2012 19:48:04 +
 Subject: [Openstack] KVM crash.
 
 I'm having problems with KVM on a single node installation. My problem is 
 like these ones: 
 
 https://bugzilla.kernel.org/show_bug.cgi?id=42703
 http://www.spinics.net/lists/kvm/msg67635.html
 
 The KVM normally crashes when I'm doing a load test with a large number of 
 connections on the VM's.
 
 This appears to not happen using a dual node installation, with the 
 nova-compute running with a dedicated machine.
 
 ___ 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] wrong IP given by flat network dhcp

You have to create your network with the same range
it looks like you created with something like 10.18.9.0/24

On Mar 28, 2012, at 8:33 AM, Michaël Van de Borne wrote:

 Hello,
 
 I installed Essex on Ubuntu 12.04 Server, and I had a problem with VM IP.
 
 The IP given to the VM (10.18.9.2) isn't in the fixed_range. Here's a portion 
 of nova.conf:
 
 # cat /etc/nova/nova.conf
 [...]
 --network_manager=nova.network.manager.FlatDHCPManager
 --public_interface=eth0
 --flat_interface=eth1
 --flat_network_bridge=br100
 --fixed_range=10.18.9.32/27
 --floating_range=172.22.22.32/27
 --network_size=32
 --flat_network_dhcp_start=10.18.9.33
 
 and here's the host network config:
 
 # cat /etc/network/interfaces
 auto eth0
 iface eth0 inet static
 address 172.22.22.1
 gateway 172.22.0.1
 netmask 255.255.0.0
 network 172.22.0.0
 broadcast 172.22.255.255
 
 auto eth1
 iface eth1 inet static
 address 10.18.9.1
 netmask 255.255.0.0
 network 10.18.0.0
 broadcast 10.18.255.255
 
 Then I deployed another VM, and I was given IP 10.18.9.3. Here's an excerpt 
 of /var/log/nova/nova-network.log when I deployed this machine:
 
 2012-03-28 17:29:16 DEBUG nova.rpc.amqp [-] received {u'_context_roles': 
 [u'admin'], u'_context_request_id': 
 u'req-aa77b53c-be43-4b4e-bf82-98f62bff7f52', u'_context_read_deleted': u'no', 
 u'args': {u'address': u'10.18.9.3'}, u'_context_auth_token': None, 
 u'_context_is_admin': True, u'_context_project_id': None, 
 u'_context_timestamp': u'2012-03-28T15:29:16.569136', u'_context_user_id': 
 None, u'method': u'lease_fixed_ip', u'_context_remote_address': None} from 
 (pid=17249) _safe_log /usr/lib/python2.7/dist-packages/nova/rpc/common.py:144
 2012-03-28 17:29:16 DEBUG nova.rpc.amqp 
 [req-aa77b53c-be43-4b4e-bf82-98f62bff7f52 None None] unpacked context: 
 {'request_id': u'req-aa77b53c-be43-4b4e-bf82-98f62bff7f52', 'user_id': None, 
 'roles': [u'admin'], 'timestamp': '2012-03-28T15:29:16.569136', 'is_admin': 
 True, 'auth_token': None, 'project_id': None, 'remote_address': None, 
 'read_deleted': u'no'} from (pid=17249) unpack_context 
 /usr/lib/python2.7/dist-packages/nova/rpc/amqp.py:188
 2012-03-28 17:29:16 DEBUG nova.network.manager 
 [req-aa77b53c-be43-4b4e-bf82-98f62bff7f52 None None] Leased IP |10.18.9.3| 
 from (pid=17249) lease_fixed_ip 
 /usr/lib/python2.7/dist-packages/nova/network/manager.py:1222
 2012-03-28 17:29:16 DEBUG nova.rpc.amqp [-] received {u'_context_roles': 
 [u'admin'], u'_msg_id': u'ba410b9f98c04023b68f6ea6e95d775e', 
 u'_context_read_deleted': u'no', u'_context_request_id': 
 u'req-11a728d5-d7f5-4c65-a2ce-6d958585e574', u'args': {u'address': 
 u'10.18.9.3'}, u'_context_auth_token': None, u'_context_is_admin': True, 
 u'_context_project_id': None, u'_context_timestamp': 
 u'2012-03-28T15:29:16.820602', u'_context_user_id': None, u'method': 
 u'get_fixed_ip_by_address', u'_context_remote_address': None} from 
 (pid=17249) _safe_log /usr/lib/python2.7/dist-packages/nova/rpc/common.py:144
 2012-03-28 17:29:16 DEBUG nova.rpc.amqp 
 [req-11a728d5-d7f5-4c65-a2ce-6d958585e574 None None] unpacked context: 
 {'request_id': u'req-11a728d5-d7f5-4c65-a2ce-6d958585e574', 'user_id': None, 
 'roles': [u'admin'], 'timestamp': '2012-03-28T15:29:16.820602', 'is_admin': 
 True, 'auth_token': None, 'project_id': None, 'remote_address': None, 
 'read_deleted': u'no'} from (pid=17249) unpack_context 
 /usr/lib/python2.7/dist-packages/nova/rpc/amqp.py:188
 2012-03-28 17:29:40 DEBUG nova.rpc.amqp [-] received {u'_context_roles': 
 [u'admin'], u'_msg_id': u'50999ff995cd4f7e8e441885d3ada543', 
 u'_context_read_deleted': u'no', u'_context_request_id': 
 u'req-563547e8-6f6f-43b1-9449-681ff43dad33', u'args': {u'instance_id': 3, 
 u'instance_uuid': u'b7ec8623-e002-4682-a37b-50e1d047c134', u'host': 
 u'openstack1', u'project_id': u'0a9e24ccc1ac46eea75154c85bb4052e', 
 u'rxtx_factor': 1.0}, u'_context_auth_token': None, u'_context_is_admin': 
 True, u'_context_project_id': None, u'_context_timestamp': 
 u'2012-03-28T15:29:31.151885', u'_context_user_id': None, u'method': 
 u'get_instance_nw_info', u'_context_remote_address': None} from (pid=17249) 
 _safe_log /usr/lib/python2.7/dist-packages/nova/rpc/common.py:144
 
 
 what am I doing wrong?
 
 
 -- 
 Michaël Van de Borne
 RD Engineer, SOA team, CETIC
 Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli
 www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi
 
 
 ___
 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] Programming OpenStack Compute API - 1.1 Mistake

2012-03-28 Thread Dolph Mathews

Nicolas,

It looks like that guide was written for the diablo (or perhaps pre-diablo)
keystone API. The corrections you're suggesting are accurate to bring the
guide forward to essex.

However, you might find the following a bit easier, as we now have a real
auth client https://github.com/openstack/python-keystoneclient!

Start by using the keystoneclient to create an initial tenant and user to
work with http://paste.openstack.org/raw/12219/. I'm using the default
admin_token defined in keystone.conf and the default management endpoint
(on port 35357).

Then, import the client in python:

 from keystoneclient.v2_0 import client


Initialize an instance with your credentials and the URL to your keystone
endpoint:

 c = client.Client(username='my-user', password='my-pass',
tenant_name='my-tenant', auth_url='http://localhost:5000/v2.0/')


That's it! You now have an token (i.e. X-Auth-Token) you can use to make
requests to other OpenStack services:

 print c.auth_token
3f52de2c8bcf46a8917bde1209a0448a


There are also additional operations the client can perform, such as:

 c.tenants.list()
[Tenant {u'id': u'61133986e465492cb7214778432608cd', u'enabled': True,
u'description': None, u'name': u'my-tenant'}]


... as well as full CRUD on tenants, users, roles, services, endpoints, etc
(assuming you're using the keystone management endpoint  appropriate admin
credentials).

Hope this is useful,

-Dolph

On Wed, Mar 28, 2012 at 2:10 AM, Nicolas Odermatt oderma...@gmail.comwrote:

 Hello Anne

 I am playing with the OpenStack API on my StackOps environment to get an
 idea of how to use it for scripts to programm some little scripts.
 I read the documentation Programming OpenStack Compute API - 1.1 and
 tried the code examples but at one specific script the machine threw me an
 error. The mentioned script is found in Chapter 2. The Basics in the
 section Using Python to Obtain the Authentication Token. If you
 copy-paste the script in a file, adjust the variables like username,
 password, etc. and then execute the file, you will receive a parse error
 from python:

 root@nova-controller:~# ./gettoken.py
 {badRequest: {message: Cannot parse auth, code: 400, details:
 Expecting object: line 1 column 43 (char 43)}}
 Traceback (most recent call last):
   File ./gettoken.py, line 41, in module
 apitoken = dd['auth']['token']['id']
 KeyError: 'auth'

 This is due to the fact that line 39 tries to extract the api token from
 the response ['auth']['token']['id'], which rather ought to be
 ['access']['token']['id']

 old: apitoken = dd['auth']['token']['id']
 new: apitoken = dd['access']['token']['id']

 As you might have noticed you receive an answer, which states
 badRequest. From former experience with the API, I remembered that this
 means that there is something wrong with the credentials provided to
 keystone. I checked the params variable and realized that there was no
 information about the tenantid. Therefore I edited the line like this:

 old:params = '{passwordCredentials:{username:osuser,
 password:ospassword}}'
 new: params = '{auth:{passwordCredentials:{username: osuser,
 password:ospassword}, tenantId:ostenant}}'

 After that the script worked like a charm. Could it be that this error
 only occurs on StackOps environments or is it a spelling error?

 PS: I learned a lot from the Programming OpenStack Compute API
 documentation. Thank you very much for this superb how to!

 Best regards,
 Nicolas

 --
 Freundliche Grüsse,
 Nicolas Odermatt


 ___
 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] Installion guide for OpenStack Essex on Ubuntu 12.04

2012-03-28 Thread Guilherme Souza

I got more one problem :(

i installed the Openstack, and up VM's and go into this VM's, but when i
try to access the IP by browser it doesn't works! :(

Em 27 de março de 2012 16:14, Guilherme Souza
souza.guilherm...@gmail.comescreveu:

 my templates directory was bad configured, then the keystone was stopped,
 i just fix the directory and restart keystone.

 Em 27 de março de 2012 15:58, Martin Gerhard Loschwitz 
 martin.loschw...@hastexo.com escreveu:

 Am 27.03.12 20:53, schrieb Guilherme Souza:
  I got this, just ignore my messages! =D
 

 What was wrong? Maybe others stumble across the same problems and would
 be happy to find the solution :) Or maybe we should make a note in the
 document if something in there needs clarification ...

 Best regards
 Martin

 --
 Martin Gerhard Loschwitz
 Chief Brand Officer, Principal Consultant
 hastexo Professional Services

 CONFIDENTIALITY NOTICE: This e-mail and/or the accompanying documents
 are privileged and confidential under applicable law. The person who
 receives this message and who is not the addressee, one of his employees
 or an agent entitled to hand it over to the addressee, is informed that
 he may not use, disclose or reproduce the contents thereof. Should you
 have received this e-mail (or any copy thereof) in error, please let us
 know by telephone or e-mail without delay and delete the message from
 your system. Thank you.




 --
 Atenciosamente,

 Guilherme Santos Souza
 Sistemas de Informação - PUCRS
 Fone: (51) 9695-1070




-- 
Atenciosamente,

Guilherme Santos Souza
Sistemas de Informação - PUCRS
Fone: (51) 9695-1070
___
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] problem ssh-ing into vms


On Mar 28, 2012, at 8:01 AM, Pierre Amadio wrote:

 Was my assumption wrong or is there something special to do to have the
 metadata service available without running nova-api ?

You can run the metadata service by itself using bin/nova-api-metadata.  For 
performance reasons, I prefer this option.

Alternatively you can leave it running on the api node but you have to make 
sure config is set on your compute and network hosts to tell the system where 
to forward to.  You do this via a config option in nova.conf

## (StrOpt) the ip for the metadata api server
# metadata_host=$my_ip

Also you have to make sure that packets  are not snatted when they leave the 
network host if they are going to the metadata server. You can do this via a 
config option as well:

## (StrOpt) dmz range that should be accepted
# dmz_cidr=10.128.0.0/24

So setting the following:
metadata_host=api_ip
dmz_cidr=api_ip/32

should work with nova-api running separately







___
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] [Netstack] melange_ipam : get_tenant_id_by_net_id - possible bug (and fix)

2012-03-28 Thread Dan Wendlandt

Thanks Jason,

Not to discourage adventurous people from playing with Melange, but the
most reliable and tested way of using Quantum + Nova in terms of the Essex
release is to use the built in Nova IPAM (which is the default when using
QuantumManager).

We'll be shifting over to using a merged Quantum + Melange in Folsom, but
in the mean time, I wouldn't suggest that end users should deploy Melange
unless they are already familiar with Melange and/or willing to get their
hands dirty.

Dan

p.s.  For those who DO want to get your hands dirty, two things I've
noticed from playing around with Quantum + Melange in devstack:

1) I seem to have to turn off the firewall driver to avoid an exception in
the virt layer when using melange and libvirt.  This can be done by setting
firewall_driver = nova.virt.firewall.NoopFirewallDriver in nova.conf .

2) DHCP with Melange + Nova is not well tested.  I believe I saw a bug
filed on it in the past with networks that are owned by the default
tenant.  I don't think this has been fixed.


On Wed, Mar 28, 2012 at 9:29 AM, Jason Kölker jkoel...@rackspace.comwrote:

 Hi Mandar,

 Thanks for taking the time to look into Melange! Currently Nova +
 Quantum + Melange is in a huge state of development flux. The current
 code gets us enough to play with some features and be backwards
 compatible with all the features in the legacy network managers. In
 the Folsom development cycle many things in regards to QuantumManager
 will be changing. See below for (some) specifics.

 On Wed, 2012-03-28 at 05:20 -0700, Mandar Vaze wrote:
  I've setup nova+quantum+mélange using devstack.
  devstack creates networks using tenant_id =default (This in itself
  looks incorrect, since it should be valid UUID for one of the tenant
  from keystone DB - but I can imagine that stack.sh can't get UUID for
  demo or admin tenants easily)

 Since nova-manage doesn't do any auth, the project_id in the call to
 create the initial network is None, this triggers the QuantumManager to
 fall back to using the value of FLAGS.quantum_default_tenant_id which
 defaults to the value 'default'.

 There really isn't a good way to get around this right now (without
 manually specifying the project_id as mentioned below). Since some data
 is stored in the Nova networks table, some in melange and some
 (possibly) by whatever quantum plugin is running.

 In the next iteration, using nova-manage to create Quantum/Melange
 blocks magically in the background will be removed, and will require
 that each service be setup through their native tools/apis.

  So I updated nova.networks, quantum.networks and mélange.ip_blocks
  tables manually and put tenant_id to use UUID of the demo tenant.
  Question : What is the right way to create network entries for demo
  tenant, that are used by nova/quantum as well as mélange DB ?

 I think (although never tried) you can pass --project_id to nova-manage
 and it should create it with the right tentat_id.

  (I tried mélange ip-block create for 10.0.0.0/24 but I got an error
  that that cidr is already being used (by tenant_id=default) - so I
  updated the DB manually. Also this would work only take care of
  mélange DB - what about nova and quantum DB ?)

 You can pass the -t flag to the melange cli to switch the tenant name.
 The quantum and nova db's will need to be updated manually at the
 moment.

  Once I did these changes, my instances could not launch, they would
  get stuck in Networking/Error state - with NetworkNotFound error in
  the logs for network UUID which I know is valid for tenant demo

 So depending on where the error was poping up at, it might have been
 that it was getting a UUID where the code was expecting the network id
 from the nova table.

 This is part of the problem of having 3 masters of information, and work
 has begin to reduce this to 2 and eventually just 1 with melange merging
 with quantum.

  Tracing this further, I came across the following code which tries to
  get_allocated_ips for default tenant, before user specified
  project_id
  In my opinion, this is incorrect.
  Once I switched the order i.e. try project_id before default
  everything started working.
 
  Please comment whether the following code change makes sense (I'm not
  even sure, if I were to submit this code change - what would I write
  in the bug description - hence need comments from you)
 
  diff --git a/nova/network/quantum/melange_ipam_lib.py
 b/nova/network/quantum/melange_ipam_lib.py
  index c68d83c..ea39f60 100644
  --- a/nova/network/quantum/melange_ipam_lib.py
  +++ b/nova/network/quantum/melange_ipam_lib.py
  @@ -152,7 +152,8 @@ class QuantumMelangeIPAMLib(object):
 
   def get_tenant_id_by_net_id(self, context, net_id, vif_id,
 project_id):
   ipam_tenant_id = None
  -tenant_ids = [FLAGS.quantum_default_tenant_id, project_id, None]
  +#tenant_ids = [FLAGS.quantum_default_tenant_id, project_id,
 None]
  +tenant_ids =

Re: [Openstack] KVM crash.

2012-03-28 Thread Justin Santa Barbara

The libvirt hang was a threading deadlock within libvirt, whereas this is a
kernel crash.  I'd be surprised if they are the same issue.

The current theory on the kernel bugzilla is that it might be related to
bridge + netfilter.  That does tally with the observation of it happening
under a network load test.

Guilherme: I've never seen the issue personally, but I haven't run network
stress tests, I run Debian, I prefer FlatManager etc.  Is it fairly easy to
reproduce e.g. by running ab against a guest?  I suspect this will be
outside of anything we can fix in OpenStack itself though; the final
outcome will likely be e.g. you must use a kernel with patch X.  You can
either go straight to the latest versions, or if you provide a simple
procedure I'm sure a number of the big clouds will want to try it on their
own configurations.

Justin



On Wed, Mar 28, 2012 at 9:45 AM, Vishvananda Ishaya
vishvana...@gmail.comwrote:

 This was discussed on the mailing list earlier I believe:

 http://www.mail-archive.com/openstack@lists.launchpad.net/msg08475.html

 The solution appears to be to upgrade to a newer libvirt.

 Vish

 On Mar 28, 2012, at 6:01 AM, Guilherme Birk wrote:

 No one is having this issue?

 --
 From: guib...@hotmail.com
 To: openstack@lists.launchpad.net
 Date: Fri, 23 Mar 2012 19:48:04 +
 Subject: [Openstack] KVM crash.

 I'm having problems with KVM on a single node installation. My problem is
 like these ones:

 https://bugzilla.kernel.org/show_bug.cgi?id=42703
 http://www.spinics.net/lists/kvm/msg67635.html

 The KVM normally crashes when I'm doing a load test with a large number of
 connections on the VM's.

 This appears to not happen using a dual node installation, with the
 nova-compute running with a dedicated machine.

 ___ Mailing list:
 https://launchpad.net/~openstack Post to : 
 openstack@lists.launchpad.netUnsubscribe :
 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] Installion guide for OpenStack Essex on Ubuntu 12.04

2012-03-28 Thread Guilherme Souza

I'm so stupid, i was accessing the wrong IP, but i got another error:

i launch a new VM and try to access the VNC i got this stack:



 Using the URLconf defined in openstack_dashboard.urls, Django tried these
URL patterns, in this order:

   1. ^$ [name='splash']
   2. ^qunit/$ [name='qunit_tests']
   3. home/$ [name='user_home']
   4. auth/login/$ [name='auth_login']
   5. auth/logout/$ [name='auth_logout']
   6. auth/switch/(?Ptenant_id[^/]+)/$ [name='auth_switch']
   7. ^i18n/setlang/$ [name='set_language']
   8. ^i18n/
   9. ^syspanel/
   10. ^settings/
   11. ^nova/ ^instances_and_volumes/ ^$ [name='index']
   12. ^nova/ ^instances_and_volumes/ ^instances/
   ^(?Pinstance_id[^/]+)/detail$ [name='detail']
   13. ^nova/ ^instances_and_volumes/ ^instances/
   ^(?Pinstance_id[^/]+)/console$ [name='console']
   14. ^nova/ ^instances_and_volumes/ ^instances/
   ^(?Pinstance_id[^/]+)/vnc$ [name='vnc']
   15. ^nova/ ^instances_and_volumes/ ^instances/
   ^(?Pinstance_id[^/]+)/update$ [name='update']
   16. ^nova/ ^instances_and_volumes/ ^volumes/
   17. ^nova/ ^containers/
   18. ^nova/ ^access_and_security/
   19. ^nova/ ^images_and_snapshots/
   20. ^nova/ ^$ [name='index']
   21. ^static\/(?Ppath.*)$
   22. ^media\/(?Ppath.*)$



The current URL,
nova/instances_and_volumes/instances/72cc9f91-1d95-43c0-b48b-62e4dad9a420/None,
didn't match any of these.


Em 28 de março de 2012 13:59, Guilherme Souza
souza.guilherm...@gmail.comescreveu:

 I got more one problem :(

 i installed the Openstack, and up VM's and go into this VM's, but when i
 try to access the IP by browser it doesn't works! :(

 Em 27 de março de 2012 16:14, Guilherme Souza souza.guilherm...@gmail.com
  escreveu:

 my templates directory was bad configured, then the keystone was stopped,
 i just fix the directory and restart keystone.

 Em 27 de março de 2012 15:58, Martin Gerhard Loschwitz 
 martin.loschw...@hastexo.com escreveu:

 Am 27.03.12 20:53, schrieb Guilherme Souza:
  I got this, just ignore my messages! =D
 

 What was wrong? Maybe others stumble across the same problems and would
 be happy to find the solution :) Or maybe we should make a note in the
 document if something in there needs clarification ...

 Best regards
 Martin

 --
 Martin Gerhard Loschwitz
 Chief Brand Officer, Principal Consultant
 hastexo Professional Services

 CONFIDENTIALITY NOTICE: This e-mail and/or the accompanying documents
 are privileged and confidential under applicable law. The person who
 receives this message and who is not the addressee, one of his employees
 or an agent entitled to hand it over to the addressee, is informed that
 he may not use, disclose or reproduce the contents thereof. Should you
 have received this e-mail (or any copy thereof) in error, please let us
 know by telephone or e-mail without delay and delete the message from
 your system. Thank you.




 --
 Atenciosamente,

 Guilherme Santos Souza
 Sistemas de Informação - PUCRS
 Fone: (51) 9695-1070




 --
 Atenciosamente,

 Guilherme Santos Souza
 Sistemas de Informação - PUCRS
 Fone: (51) 9695-1070




-- 
Atenciosamente,

Guilherme Santos Souza
Sistemas de Informação - PUCRS
Fone: (51) 9695-1070
___
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] Programming OpenStack Compute API - 1.1 Mistake

2012-03-28 Thread Anne Gentle

Hi Nicolas -
Glad you like the book! Jacek Artymiak gets all the credit for it, and
he wrote and tested it against TryStack. So for now, it uses old-style
Keystone requests as those will work against TryStack.

TryStack plans an upgrade in April, not to steal thunder or anything
from them, but I'd expect we can do updates to the guide after that.

If you wouldn't mind, could you log a doc bug to track that effort,
basically requesting Auth content updates to go with Keystone
light/redux? Log it in http://bugs.launchpad.net/openstack-manuals.

Thanks,
Anne

On Wed, Mar 28, 2012 at 4:10 AM, Nicolas Odermatt oderma...@gmail.com wrote:
 Hello Anne

 I am playing with the OpenStack API on my StackOps environment to get an
 idea of how to use it for scripts to programm some little scripts.
 I read the documentation Programming OpenStack Compute API - 1.1 and tried
 the code examples but at one specific script the machine threw me an error.
 The mentioned script is found in Chapter 2. The Basics in the section
 Using Python to Obtain the Authentication Token. If you copy-paste the
 script in a file, adjust the variables like username, password, etc. and
 then execute the file, you will receive a parse error from python:

 root@nova-controller:~# ./gettoken.py
 {badRequest: {message: Cannot parse auth, code: 400, details:
 Expecting object: line 1 column 43 (char 43)}}
 Traceback (most recent call last):
   File ./gettoken.py, line 41, in module
     apitoken = dd['auth']['token']['id']
 KeyError: 'auth'

 This is due to the fact that line 39 tries to extract the api token from the
 response ['auth']['token']['id'], which rather ought to be
 ['access']['token']['id']

 old: apitoken = dd['auth']['token']['id']
 new: apitoken = dd['access']['token']['id']

 As you might have noticed you receive an answer, which states badRequest.
 From former experience with the API, I remembered that this means that there
 is something wrong with the credentials provided to keystone. I checked the
 params variable and realized that there was no information about the
 tenantid. Therefore I edited the line like this:

 old:params = '{passwordCredentials:{username:osuser,
 password:ospassword}}'
 new: params = '{auth:{passwordCredentials:{username: osuser,
 password:ospassword}, tenantId:ostenant}}'

 After that the script worked like a charm. Could it be that this error only
 occurs on StackOps environments or is it a spelling error?

 PS: I learned a lot from the Programming OpenStack Compute API
 documentation. Thank you very much for this superb how to!

 Best regards,
 Nicolas

 --
 Freundliche Grüsse,
 Nicolas Odermatt


___
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] problem with quantum

2012-03-28 Thread Sumit Naiksatam (snaiksat)

Hi William,

 

From the looks of it, you seem to be trying to use the Quantum
LinuxBridge plugin and facing the issue. The error you mention below
suggests that you might not be pointing to the right
linuxnet_interface_driver (you should be seeing bridge names starting
with a brq- and then first 11 characters of the network uuid, not the
entire uuid). In the snippet of the nova.conf that you have below, I see
that the option names for the drivers are spelt incorrectly as *_drive
as opposed to *_driver; you should be having:

 

libvirt_vif_driver=nova.virt.libvirt.vif.QuantumLinuxBridgeVIFDriver

linuxnet_interface_driver=nova.network.linux_net.QuantumLinuxBridgeInter
faceDriver

 

Also, in case you are using devstack for your installation, you might
want to look at the changes in this patch for getting the Quantum Linux
Bridge plugin to work:

https://review.openstack.org/#change,5667

 

Thanks,

~Sumit.

 

From: openstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:openstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of William Herry
Sent: Tuesday, March 27, 2012 10:00 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] problem with quantum

 

Hi
I am try quantum on my test environment, without quantum it works fine,
when I try to use quantum, I can't make it work, I notice that in
nova-network.log there some thing like this

2012-03-28 10:38:28 DEBUG nova.utils [-] Running cmd (subprocess): sudo
brctl addbr 332a1a19-d6da-4bee-9836-42d4228a786b from (pid=7105) execute
/opt/stack/nova/nova/utils.py:217

332a1a19-d6da-4bee-9836-42d4228a786b if my network's uuid, and it can
not success because it is too long 

(nova.rpc.amqp): TRACE: Stderr: iptables-restore v1.4.12: interface
name `332a1a19-d6da-4bee-9836-42d4228a786b' must be shorter than
IFNAMSIZ (15)\nError occurred at line: 31\nTry `iptables-restore -h' or
'iptables-restore --help' for more information.\n

why this happen, can any one point out where is my problem

here is the line i add to nova.conf
network_manager=nova.network.quantum.manager.QuantumManager
libvirt_vif_type=ethernet
libvirt_vif_drive=nova.virt.libvirt.vif.QuantumLinuxBridgeVIFDriver
linuxnet_interface_drive=nova.network.linux_net.QuantumLinuxBridgeInterf
aceDriver
quantum_use_dhcp=true
multi_host=true

quantum is already configured according to Quantum Admin Guide and
/opt/stack/quantum/quantum/plugins/linuxbridge/README

Thanks

-- 
Where there is a will, there is a way.

williamherrych...@gmail.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

[Openstack] EC2 metadata

2012-03-28 Thread Joshua Harlow

Hi all,

I was wondering if this was documented anywhere or if it was just a look in 
code kind of thing.

I am looking at how compatible the instance metadata api is with amazon, 
http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/AESDG-chapter-instancedata.html

And I was wondering if that was documented anywhere?

It might be useful in general to have the known compatibility with EC2 
documented in general, maybe another topic at the conference...

Possibly with validation tests also that attempt to ensure/check this 
compatibility against a known golden set of responses/calls. I've done this 
before internally here and it seems useful for OS.

-Josh

___
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] regarding this Message #09165 (VNC error with latest version of Firefox)

2012-03-28 Thread Anthony Young

In diablo, nova shipped its own websocket proxy, which had some browser
compatibility issues due to eventlet's out-dated websocket implementation.
 For this reason, in essex we replaced nova-vncproxy with one more directly
based on noVNC's websocket proxy.  Docs for the current proxy may be found
here:
https://github.com/openstack/nova/blob/master/doc/source/runnova/vncconsole.rst

At the time of diablo release, I had an early version of the current proxy
working against stable/diablo here:
https://github.com/cloudbuilders/noVNC/branches/diablo - devstack's
stable/diablo shows how to use that branch.

I just ran the branch mentioned above against diablo + Firefox 11 - seems
to work.  I would expect the 'official' diablo vnc proxy to have browser
compat issues, though I have not tried your exact configuration.

Anthony

On Wed, Mar 28, 2012 at 6:09 AM, Staicu Gabriel gabriel_sta...@yahoo.comwrote:

 Hi Diego,

 I observed the same behavior as you.
 I am using the latest packages from http://ops.rcb.me/packages.
 Everything works fine except the connection to vnc console from the latest
 firefox (11.0) on linux. I tried also with firefox 11.0 from win7 and the
 error is the same.
 What workaround I found till now is to use firefox (10.0.3) which works ok.

 Regards,
 Gabriel

 ___
 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] [Docs] how are we doing for Essex release?

2012-03-28 Thread Anne Gentle

Hi all,
I'm still hearing that the docs are outdated and would like a gut
check. We are fixing bugs all the time, but the backlog of confirmed
doc bugs remains over 100. If you are still seeing errors or
omissions, can you please help by reviewing docs and filling in the
gaps?

Here are the yet-unfilled areas that I consider high priority for Essex:

1. Image management - a portion of this chapter is shared with the
book sourced in the Launchpad openstackbook project, and looking at
the project source, that hasn't been updated recently. There are
several doc bugs to fix here:
https://bugs.launchpad.net/openstack-manuals/+bug/967101
https://bugs.launchpad.net/openstack-manuals/+bug/957618
https://bugs.launchpad.net/openstack-manuals/+bug/967094
If anyone has a nice set of instructions on making images and
uploading them we could use them.

2. Migration from Diablo to Essex: I've logged
https://bugs.launchpad.net/openstack-manuals/+bug/967402 and asked
Razique to write this section as he did a great job with the Cactus to
Diablo topic.

3. RBAC and policy.json - Joshua, any interest?
https://bugs.launchpad.net/openstack-manuals/+bug/953129

4. Metadata configuration -
https://bugs.launchpad.net/openstack-manuals/+bug/953148

5. EC2 compatibility - https://bugs.launchpad.net/openstack-manuals/+bug/953137

6. Network configuration -
https://bugs.launchpad.net/openstack-manuals/+bug/953151

Thanks all for the updates so far. I welcome the work ethic folks have
brought to the doc!

Anne

___
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] Running code on instance start/terminate

2012-03-28 Thread Rogério Vinhal Nunes

I'm trying to find out information to make an application that consumes the
compute info, but I'm having some trouble. Is there a better documentation
I could follow and the precise details of the queue/exchange/routing_key
needed to take information at the end of each run-instance and
terminate-instance?

Also, I'm using amqplib and I saw that Openstack uses an internal library
named Carrot that uses amqplib. Would it be better to use it instead?

Em 27 de março de 2012 12:42, Sandy Walsh sandy.wa...@rackspace.comescreveu:

 I believe '.exists' is sent via a periodic update in compute.manager.



 On 03/27/2012 12:08 PM, Leander Bessa wrote:
  Hello,
 
  I've been following this topic and i've been trying to receive the
  notifications directly from rabbitmq with python+pika. So i far
  i've managed to receive the start/terminate events and everything in
  between. What i am unable to find though is the topic regarding
  _compute.instance.exists_
  from http://wiki.openstack.org/SystemUsageData. Does this even exist, or
  is there some extra configuration required with nova?
 
  Regards,
 
  Leander
 
  On Mon, Mar 26, 2012 at 4:54 PM, Russell Bryant rbry...@redhat.com
  mailto:rbry...@redhat.com wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  On 03/26/2012 11:48 AM, Russell Bryant wrote:
   On 03/26/2012 10:15 AM, Rogério Vinhal Nunes wrote:
   Hello,
  
   I'm developing a application to work along with openstack. My
   application needs to keep track of all instances being started
   or terminated such as feeding it information about the location,
   status and other information about launched and terminated
   instances. The current version makes timed queries to OpenStack
   database, but this is showing to be a little consuming and
   inefficient, so I would like to add a portion of code to make
   OpenStack actively feed my application information whenever an
   instance changes its status or location.
  
   What is the least intrusive way to do that? It would be very nice
   if OpenStack provided a way to run code on these situations
   without actually changing any code, such as defining a directory
   of scripts to run in every instance status change.
  
   Check out the notifications system:
  
   http://wiki.openstack.org/NotificationSystem
  
 
  That wasn't the page I thought it was ... I meant:
 
 http://wiki.openstack.org/SystemUsageData
 
  You can consume these events via AMQP if you configure nova to use
 the
  rabbit notifier.
 
  - --
  Russell Bryant
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1.4.12 (GNU/Linux)
  Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
  iEYEARECAAYFAk9wkSgACgkQFg9ft4s9SAYFuACfUu23qtxiH6WLCJNyd9gBf8i1
  FwQAnifjwWkFHYxo+KhYt8TAWEzTaMYZ
  =UWlH
  -END PGP SIGNATURE-
 
  ___
  Mailing list: https://launchpad.net/~openstack
  Post to : openstack@lists.launchpad.net
  mailto: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] Running code on instance start/terminate

2012-03-28 Thread Leander Bessa

From what i have figured out so far, the exchange queue is nova and the
routing key in your case is notifications.info.

On Wed, Mar 28, 2012 at 9:05 PM, Rogério Vinhal Nunes
roge...@dcc.ufmg.brwrote:

 I'm trying to find out information to make an application that consumes
 the compute info, but I'm having some trouble. Is there a better
 documentation I could follow and the precise details of the
 queue/exchange/routing_key needed to take information at the end of each
 run-instance and terminate-instance?

 Also, I'm using amqplib and I saw that Openstack uses an internal library
 named Carrot that uses amqplib. Would it be better to use it instead?

 Em 27 de março de 2012 12:42, Sandy Walsh sandy.wa...@rackspace.comescreveu:

 I believe '.exists' is sent via a periodic update in compute.manager.



 On 03/27/2012 12:08 PM, Leander Bessa wrote:
  Hello,
 
  I've been following this topic and i've been trying to receive the
  notifications directly from rabbitmq with python+pika. So i far
  i've managed to receive the start/terminate events and everything in
  between. What i am unable to find though is the topic regarding
  _compute.instance.exists_
  from http://wiki.openstack.org/SystemUsageData. Does this even exist,
 or
  is there some extra configuration required with nova?
 
  Regards,
 
  Leander
 
  On Mon, Mar 26, 2012 at 4:54 PM, Russell Bryant rbry...@redhat.com
  mailto:rbry...@redhat.com wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  On 03/26/2012 11:48 AM, Russell Bryant wrote:
   On 03/26/2012 10:15 AM, Rogério Vinhal Nunes wrote:
   Hello,
  
   I'm developing a application to work along with openstack. My
   application needs to keep track of all instances being started
   or terminated such as feeding it information about the location,
   status and other information about launched and terminated
   instances. The current version makes timed queries to OpenStack
   database, but this is showing to be a little consuming and
   inefficient, so I would like to add a portion of code to make
   OpenStack actively feed my application information whenever an
   instance changes its status or location.
  
   What is the least intrusive way to do that? It would be very nice
   if OpenStack provided a way to run code on these situations
   without actually changing any code, such as defining a directory
   of scripts to run in every instance status change.
  
   Check out the notifications system:
  
   http://wiki.openstack.org/NotificationSystem
  
 
  That wasn't the page I thought it was ... I meant:
 
 http://wiki.openstack.org/SystemUsageData
 
  You can consume these events via AMQP if you configure nova to use
 the
  rabbit notifier.
 
  - --
  Russell Bryant
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1.4.12 (GNU/Linux)
  Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
  iEYEARECAAYFAk9wkSgACgkQFg9ft4s9SAYFuACfUu23qtxiH6WLCJNyd9gBf8i1
  FwQAnifjwWkFHYxo+KhYt8TAWEzTaMYZ
  =UWlH
  -END PGP SIGNATURE-
 
  ___
  Mailing list: https://launchpad.net/~openstack
  Post to : openstack@lists.launchpad.net
  mailto: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


___
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] OVF vs. bare container formats for qcow2 images

2012-03-28 Thread Lorin Hochstein

All:

Given that I have a qcow2 image from somewhere (e.g., downloaded it from a 
uec-images.ubuntu.com, created one from a raw image using qemu-img) that i want 
to add to glance:

1. How can I tell whether it's an ovf or bare container format?
2. Why does it matter?

Whenever I add a qcow2 image to glance, I always choose ovf, even though it's 
probably bare, because I saw an example somewhere, and it just works, so I 
keep doing it. But I don't know how to inspect a binary file to determine what 
its container is (if file image.qcow2 says it's a QEMU QCOW2 Image (v2), does 
that mean it's bare?). In particular, why does the user need to specify this 
information?

Also, are there any Linux command-line tools for inspecting/manipulating OVF 
containers?

Take care,

Lorin
--
Lorin Hochstein
Lead Architect - Cloud Services
Nimbis Services, Inc.
www.nimbisservices.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

Re: [Openstack] Running code on instance start/terminate

2012-03-28 Thread Sandy Walsh

Look at
https://github.com/rackspace/stacktach/blob/master/worker.py
(ignore the _process() call, just look at how the queue listeners are
set up)

my worker_conf.py looks something like
DEPLOYMENTS = [
dict(
tenant_id=1,
url='http://stacktach.example.com',
rabbit_host=10.0.0.1,
rabbit_port=5672,
rabbit_userid=nova-staging,
rabbit_password=password,
rabbit_virtual_host=staging),
dict(
tenant_id=2,
url='http://stacktach.example.com',
rabbit_host=10.99.0.1,
rabbit_port=5672,
rabbit_userid=nova,
rabbit_password=password,
rabbit_virtual_host=production),
   ]


Or the queue listeners in
https://github.com/Cerberus98/yagi

Hope it helps!
-Sandy


On 03/28/2012 05:27 PM, Leander Bessa wrote:
From what i have figured out so far, the exchange queue is nova and
 the routing key in your case is notifications.info
 http://notifications.info.
 
 On Wed, Mar 28, 2012 at 9:05 PM, Rogério Vinhal Nunes
 roge...@dcc.ufmg.br mailto:roge...@dcc.ufmg.br wrote:
 
 I'm trying to find out information to make an application that
 consumes the compute info, but I'm having some trouble. Is there a
 better documentation I could follow and the precise details of the
 queue/exchange/routing_key needed to take information at the end of
 each run-instance and terminate-instance?
 
 Also, I'm using amqplib and I saw that Openstack uses an internal
 library named Carrot that uses amqplib. Would it be better to use it
 instead?
 
 Em 27 de março de 2012 12:42, Sandy Walsh sandy.wa...@rackspace.com
 mailto:sandy.wa...@rackspace.com escreveu:
 
 I believe '.exists' is sent via a periodic update in
 compute.manager.
 
 
 
 On 03/27/2012 12:08 PM, Leander Bessa wrote:
  Hello,
 
  I've been following this topic and i've been trying to receive the
  notifications directly from rabbitmq with python+pika. So i far
  i've managed to receive the start/terminate events and
 everything in
  between. What i am unable to find though is the topic regarding
  _compute.instance.exists_
  from http://wiki.openstack.org/SystemUsageData. Does this even
 exist, or
  is there some extra configuration required with nova?
 
  Regards,
 
  Leander
 
  On Mon, Mar 26, 2012 at 4:54 PM, Russell Bryant
 rbry...@redhat.com mailto:rbry...@redhat.com
  mailto:rbry...@redhat.com mailto:rbry...@redhat.com wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  On 03/26/2012 11:48 AM, Russell Bryant wrote:
   On 03/26/2012 10:15 AM, Rogério Vinhal Nunes wrote:
   Hello,
  
   I'm developing a application to work along with
 openstack. My
   application needs to keep track of all instances being
 started
   or terminated such as feeding it information about the
 location,
   status and other information about launched and terminated
   instances. The current version makes timed queries to
 OpenStack
   database, but this is showing to be a little consuming and
   inefficient, so I would like to add a portion of code
 to make
   OpenStack actively feed my application information
 whenever an
   instance changes its status or location.
  
   What is the least intrusive way to do that? It would be
 very nice
   if OpenStack provided a way to run code on these situations
   without actually changing any code, such as defining a
 directory
   of scripts to run in every instance status change.
  
   Check out the notifications system:
  
   http://wiki.openstack.org/NotificationSystem
  
 
  That wasn't the page I thought it was ... I meant:
 
 http://wiki.openstack.org/SystemUsageData
 
  You can consume these events via AMQP if you configure
 nova to use the
  rabbit notifier.
 
  - --
  Russell Bryant
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1.4.12 (GNU/Linux)
  Comment: Using GnuPG with Mozilla -
 http://enigmail.mozdev.org/
 
 
 iEYEARECAAYFAk9wkSgACgkQFg9ft4s9SAYFuACfUu23qtxiH6WLCJNyd9gBf8i1
  FwQAnifjwWkFHYxo+KhYt8TAWEzTaMYZ
  =UWlH
  -END PGP SIGNATURE-
 
  ___
  Mailing list: https://launchpad.net/~openstack

Re: [Openstack] Validation of floating IP opertaions in Essex codebase ?


On Mar 28, 2012, at 10:04 AM, Day, Phil wrote:

 Hi Folks,
  
 At the risk of looking lazy in my first question by following up with a 
 second:
  
 So I tracked this down in the code and can see that the validation has moved 
 into network/manager.py, and what was a validation/cast in network/api.py has 
 been replaced with a call – but that seems to make the system more tightly 
 coupled across components (i.e. if my there is a problem getting the message 
 to the Network Manager then even an invalid request will be blocked until the 
 call returns or times out).

This is a side effect of trying to decouple compute and network, see the 
explanation below.

  
 It also looks as if the validation for disassociate_floating_ip has also been 
 moved to the manager, but this is still a cast from the api layer – so those 
 error messages never get back to the user.

Good point.  This probably needs to be a call with the current model.

  
 Coming from Diablo it all feels kind of odd to me – I thought we were trying 
 to validate what we could of requests in the API server and return immediate 
 errors at that stage and then cast into the system (so that only internal 
 errors can stop something from working at this stage). Was there a 
 deliberate design policy around this at some stage ?

There are a few things going on here.

First we have spent a lot of time decoupling network and compute.  Ultimately 
network will be an external service, so we can't depend on having access to the 
network database on the compute api side. We can do a some checks in 
compute_api to make sure that it isn't attached to another instance that we 
know about, but ultimately the network service has to be responsible for saying 
what can happen with the ip address.

So the second part is about why it is happening in network_manager vs 
network_api.  This is a side-effect of the decision to plug in 
quantum/melange/etc. at the manager layer instead of the api layer.  The api 
layer is therefore being very dumb, just passing requests on to the manager.

So that explains where we are.  Here is the plan (as I understand) for the 
future:

a) move the quantum plugin to the api layer
(At this point we could move validation into the api if necessary.)

b) define a more complete network api which includes all of the necessary 
features that are currently compute extensions

c) make a client to talk to the api

d) make compute talk through the client to the api instead of using rabbit 
messages
(this decouples network completely, allowing us to deploy and run network as a 
completely separate service if need be.  At this point the quantum-api-plugin 
could be part of quantum or a new shared NaaS project.  More to decide at the 
summit here)

In general, we are hoping to switch to quantum as the default by Folsom, and 
not have to touch the legacy network code very much.  If there are serious 
performance issues we could make some optimizations by doing checks in 
network-api, but these will quickly become moot if we are moving towards using 
a client and talking through a rest interface.

So Looks like the following could be done in the meantime:

a) switch disassociate from a cast to a call - i would consider this one a a 
bug and would appreciate someone verifying that it fails and reporting it

b) add some validation in compute api - I'm not sure what we can assert here.  
Perhaps we could use the network_info cache and check for duplicates etc.

c) if we have serious performance issues, we could add another layer of checks 
in the compute_api, but we may have to make sure that we make sure it is 
ignored for quantum.___
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] Validation of floating IP opertaions in Essex codebase ?

2012-03-28 Thread Dan Wendlandt

On Wed, Mar 28, 2012 at 3:25 PM, Vishvananda Ishaya
vishvana...@gmail.comwrote:



 So that explains where we are.  Here is the plan (as I understand) for the
 future:

 a) move the quantum plugin to the api layer
 (At this point we could move validation into the api if necessary.)

 b) define a more complete network api which includes all of the necessary
 features that are currently compute extensions

 c) make a client to talk to the api

 d) make compute talk through the client to the api instead of using rabbit
 messages


Agreed, this is what I've been thinking as well. Moving forward,
configuration of floating IPs would be done using the Quantum API. For
people who want to drive network config via Nova (e.g., using euca-api, or
using os-api extensions for backward compat), these calls would effectively
be proxied to Quantum.  If someone using the proxied APIs make a request
that results in an error, the Quantum API would generate an error, and the
proxy would essentially pass this error on to the user.



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




-- 
~~~
Dan Wendlandt
Nicira Networks: www.nicira.com
twitter: danwendlandt
~~~
___
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] Validation of floating IP opertaions in Essex codebase ?

2012-03-28 Thread Leandro Reox

+1 to Dash (Dan + Vish) :p

Lean@mercadolibre
On Mar 28, 2012 7:50 PM, Dan Wendlandt d...@nicira.com wrote:



 On Wed, Mar 28, 2012 at 3:25 PM, Vishvananda Ishaya vishvana...@gmail.com
  wrote:



 So that explains where we are.  Here is the plan (as I understand) for
 the future:

 a) move the quantum plugin to the api layer
 (At this point we could move validation into the api if necessary.)

 b) define a more complete network api which includes all of the necessary
 features that are currently compute extensions

 c) make a client to talk to the api

 d) make compute talk through the client to the api instead of using
 rabbit messages


 Agreed, this is what I've been thinking as well. Moving forward,
 configuration of floating IPs would be done using the Quantum API. For
 people who want to drive network config via Nova (e.g., using euca-api, or
 using os-api extensions for backward compat), these calls would effectively
 be proxied to Quantum.  If someone using the proxied APIs make a request
 that results in an error, the Quantum API would generate an error, and the
 proxy would essentially pass this error on to the user.



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




 --
 ~~~
 Dan Wendlandt
 Nicira Networks: www.nicira.com
 twitter: danwendlandt
 ~~~


 ___
 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] [Docs] Glossary (was nova zone and availability_zone)

2012-03-28 Thread Anne Gentle

All,

I've added a doc review for a glossary at
https://review.openstack.org/#change,5847. It came from the Repose
project, and is Apache 2 licensed, so I guess it makes sense to edit
and bring it into the OpenStack umbrella.

I haven't yet added zones or availability zones to the glossary, nor
have I incorporated it further into a guide. There is also a method to
have definitions as pop-ups within other pages. These would be next
steps for glossary work. Hint: glossary work is not my favorite so
anyone can be owner of this. :)

I'd like review for the current definitions as well as suggestions for
additions (and definitions) before investing more effort into
incorporation, so feel free to take a look and give feedback.

Thanks,
Anne

On Tue, Mar 20, 2012 at 6:21 AM, Tim Bell tim.b...@cern.ch wrote:

It would be useful if there was a glossary of terms related to Openstack. It
is easy to get confused as many words are overloaded or slightly different
between different parts of Openstack.

There is also the page on identity at
http://docs.openstack.org/diablo/openstack-identity/admin/content/Identity-Service-Concepts-e1362.html
which defines some concepts.

From http://wiki.openstack.org/Glossary, there is a pointer to
http://cloudglossary.com/ but the openstack terms are not in there.

There is also
http://docs.openstack.org/incubation/openstack-network/developer/quantum-api-1.0/content/Glossary.html
for networking.

Tim

From: openstack-bounces+tim.bell=cern...@lists.launchpad.net
[mailto:openstack-bounces+tim.bell=cern...@lists.launchpad.net] On Behalf Of
Sandy Walsh
Sent: 20 March 2012 12:07
To: Nicolae Paladi; openstack@lists.launchpad.net
Subject: Re: [Openstack] nova zone and availability_zone

Availability Zone is an EC2 concept. Zones were a sharding scheme for Nova.
Zones are being renamed to Cells to avoid further confusion. Availability
Zones will remain the same.

Hope it helps!

-S

From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf
of Nicolae Paladi [n.pal...@gmail.com]
Sent: Tuesday, March 20, 2012 6:55 AM
To: openstack@lists.launchpad.net
Subject: [Openstack] nova zone and availability_zone

Hi all,

What is the difference between nova zone(s) and availability_zone?

In a new deployment, the *services* table in the nova db contains an
availability_zone

column (which is 'nova', but default).

If that is not the same as nova zones (which are logical deployments, as
far as I understood), where is information

about zones stored?

The only documentation about zones in openstack that I could find is here:

http://nova.openstack.org/devref/zone.html

is there anything on availability zones?

Cheers,

/Nicolae.

___
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] what's the default usernamepassword for the instance in devstack?

2012-03-28 Thread Felix


they are in the log, thanks very much!

于 2012年03月28日 19:54, Mandar Vaze 写道:


I create my instance using cirros-0.3.0-x86_64-blank image

Default username/password for the instance is listed on the very last 
line in “View Log”


-Mandar

*From:*openstack-bounces+mandar.vaze=vertex.co...@lists.launchpad.net 
[mailto:openstack-bounces+mandar.vaze=vertex.co...@lists.launchpad.net] *On 
Behalf Of *Yong Sheng Gong

*Sent:* Wednesday, March 28, 2012 4:31 PM
*To:* Andy Chong
*Cc:* Chmouel Boudjnah; openstack@lists.launchpad.net s
*Subject:* Re: [Openstack] what's the default usernamepassword for 
the instance in devstack?


go to the instance's vnc console, it is printed there just before the 
login: prompt.


if you don't know how to get to the console on dashboard UI, just use 
the virt-manager to access the vnc console of the instance.


-openstack-bounces+gongysh=cn.ibm@lists.launchpad.net 
mailto:-openstack-bounces+gongysh=cn.ibm@lists.launchpad.net 
wrote: -


To: Chmouel Boudjnah chmo...@chmouel.com mailto:chmo...@chmouel.com
From: Andy Chong andy...@gmail.com mailto:andy...@gmail.com
Sent by: openstack-bounces+gongysh=cn.ibm@lists.launchpad.net 
mailto:openstack-bounces+gongysh=cn.ibm@lists.launchpad.net

Date: 03/28/2012 06:38PM
Cc: \openstack@lists.launchpad.net\ 
mailto:openstack@lists.launchpad.net%5C s 
openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net
Subject: Re: [Openstack] what's the default usernamepassword for the 
instance in devstack?


He asked for the username/password for instance, not horizon dashboard

On Wed, Mar 28, 2012 at 6:33 PM, Chmouel Boudjnah chmo...@chmouel.com 
mailto:chmo...@chmouel.com wrote:


On Wed, Mar 28, 2012 at 10:56 AM, Felix f...@tnsoft.com.cn 
mailto:f...@tnsoft.com.cn wrote:
 I tried to install openstack by devstack and succeeded, but where can 
i find

 the default username and password for the launched instance?

This should be mentioned (on your screen) when stack.sh is finished or
it should be stored in the value ADMIN_PASSWORD in the localrc file.

Chmouel.

PS: default username is admin


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

[Openstack] horizon on windows server

2012-03-28 Thread Mahdi Njim

Hi
I would to know if I can install horizon on windows server, I know python
is portable but I would like to be sure that I can run horizon under
windows server.
Thanks
___
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] horizon on windows server

2012-03-28 Thread Mahdi Njim

Thank you I will try to build it on windows and I will tell you the result

2012/3/29 Andy Chong andy...@gmail.com

 I believe it is doable, but why?
 I checked through the pip-requires, most of them are runnable on windows,
 except xattr which I am not sure about.

 On Thu, Mar 29, 2012 at 12:20 PM, Mahdi Njim njimma...@gmail.com wrote:

 Hi
 I would to know if I can install horizon on windows server, I know python
 is portable but I would like to be sure that I can run horizon under
 windows server.
 Thanks

 ___
 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-poc] [Bug 965563] Re: Usability issue: is_public=yes sets Public: No

2012-03-28 Thread Sean Dague

** Also affects: openstack-common
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/965563

Title:
  Usability issue: is_public=yes sets Public: No

Status in OpenStack Image Registry and Delivery Service (Glance):
  Fix Committed
Status in openstack-common:
  New

Bug description:
  There is a usability with Glance around the use of booleans. The
  is_public metadata for an image is displayed via glance show in
  Yes/No terms. i.e.

  Id: 7b1ee878-131b-4c1e-bd14-dc8cb0e48ace
  Public: Yes
  Protected: No
  Name: oneiric-11.10-2
  Status: active
  Size: 10486808576

  However the bool_from_string function (common/utils.py) doesn't define
  'yes' as true.

  This results in the flag is_public=yes actually setting Public: No in
  the image.

  I suggest that 'yes' is added to the list of values considered true.
  There is a proposed change for it here -
  https://review.openstack.org/#change,5712 that would go into common,
  then we could propogate it out to glance proper.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/965563/+subscriptions

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

[Openstack-poc] [Bug 967400] [NEW] iniparser needs absolute import

2012-03-28 Thread Rick Harris

Public bug reported:

The use of a relative import for 'iniparser' is causing:

http://paste.openstack.org/show/12224/

Changing this to:

from openstack.common import iniparser fixes it.

** Affects: openstack-common
 Importance: Undecided
 Assignee: Rick Harris (rconradharris)
 Status: In Progress

** Changed in: openstack-common
 Assignee: (unassigned) = Rick Harris (rconradharris)

** Changed in: openstack-common
   Status: New = In Progress

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/967400

Title:
  iniparser needs absolute import

Status in openstack-common:
  In Progress

Bug description:
  The use of a relative import for 'iniparser' is causing:

  http://paste.openstack.org/show/12224/

  Changing this to:

  from openstack.common import iniparser fixes it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/967400/+subscriptions

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

[Openstack-poc] [Bug 967400] Fix proposed to openstack-common (master)

2012-03-28 Thread OpenStack Hudson

Fix proposed to branch: master
Review: https://review.openstack.org/5922

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/967400

Title:
  iniparser needs absolute import

Status in openstack-common:
  In Progress

Bug description:
  The use of a relative import for 'iniparser' is causing:

  http://paste.openstack.org/show/12224/

  Changing this to:

  from openstack.common import iniparser fixes it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/967400/+subscriptions

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

[Openstack-poc] [Bug 967400] Re: iniparser needs absolute import

2012-03-28 Thread OpenStack Hudson

Reviewed:  https://review.openstack.org/5922
Committed: 
http://github.com/openstack/openstack-common/commit/8c0f7dc0702f3e9a0e198a6206ecd2f0f8cc6d62
Submitter: Jenkins
Branch:master

commit 8c0f7dc0702f3e9a0e198a6206ecd2f0f8cc6d62
Author: Rick Harris rconradhar...@gmail.com
Date:   Wed Mar 28 18:37:16 2012 +

Use absolute import for iniparser.

Fixes bug 967400

Change-Id: I0c028f6b5285cd641dedbcea3132224e404b004e


** Changed in: openstack-common
   Status: In Progress = Fix Committed

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/967400

Title:
  iniparser needs absolute import

Status in openstack-common:
  Fix Committed

Bug description:
  The use of a relative import for 'iniparser' is causing:

  http://paste.openstack.org/show/12224/

  Changing this to:

  from openstack.common import iniparser fixes it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/967400/+subscriptions

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

[Openstack-poc] [Bug 967808] Fix proposed to openstack-common (master)

2012-03-28 Thread OpenStack Hudson

Fix proposed to branch: master
Review: https://review.openstack.org/5936

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/967808

Title:
  Create common __init__

Status in openstack-common:
  In Progress

Bug description:
  openstack/common/__init__.py needs to be created when we copy over the
  modules.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/967808/+subscriptions

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

[Openstack-ubuntu-testing-notifications] Build Still Failing: precise-openstack-essex-nova-trunk #666

 text/html; charset=UTF-8: Unrecognized 
-- 
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-openstack-essex-nova-trunk #667

Title: precise-openstack-essex-nova-trunk
General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/precise-openstack-essex-nova-trunk/667/Project:precise-openstack-essex-nova-trunkDate of build:Wed, 28 Mar 2012 10:27:23 -0400Build duration:3 min 42 secBuild cause:Started by user zulBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: All recent builds failed.0ChangesNo ChangesConsole Output[...truncated 2224 lines...]hard linking tools/clean-vlans -> nova-2012.1/toolshard linking tools/clean_file_locks.py -> nova-2012.1/toolshard linking tools/enable-pre-commit-hook.sh -> nova-2012.1/toolshard linking tools/hacking.py -> nova-2012.1/toolshard linking tools/install_venv.py -> nova-2012.1/toolshard linking tools/nova-debug -> nova-2012.1/toolshard linking tools/pip-requires -> nova-2012.1/toolshard linking tools/rfc.sh -> nova-2012.1/toolshard linking tools/test-requires -> nova-2012.1/toolshard linking tools/with_venv.sh -> nova-2012.1/toolshard linking tools/conf/create_conf.py -> nova-2012.1/tools/confhard linking tools/conf/generate_sample.sh -> nova-2012.1/tools/confhard linking tools/esx/guest_tool.py -> nova-2012.1/tools/esxhard linking tools/xenserver/vdi_chain_cleanup.py -> nova-2012.1/tools/xenserverhard linking tools/xenserver/vm_vdi_cleaner.py -> nova-2012.1/tools/xenservercopying setup.cfg -> nova-2012.1Writing nova-2012.1/setup.cfgcreating distCreating tar archiveremoving 'nova-2012.1' (and everything under it)INFO:root:Building package using /tmp/tmpKptk7k/nova_2012.1+git201203281028.orig.tar.gzINFO:root:Generating git changelog entries for this packageDEBUG:root:['git', 'log', '-n1', '--no-merges', '--pretty=format:%H']DEBUG:root:61a7ae8de318da052addffab0cd3340ad3e345c8INFO:root:Detected previous commit - readingDEBUG:root:['git', 'log', '050d23f88b54521a38cf2e41fe23aefc500f9787..HEAD', '--no-merges', '--pretty=format:[%h] %s']INFO:root:Merging testing branch from launchpadDEBUG:root:['bzr', 'merge', 'lp:~openstack-ubuntu-testing/nova/essex', '--force']dpkg-mergechangelogs: warning: /tmp/tmp6TrdMcdeb_changelog_merge/changelog.base(l120): badly formatted trailer lineLINE:  -- Chuck Short  Fri, 17 Feb 2012 11:02:12 -0500dpkg-mergechangelogs: warning: /tmp/tmp6TrdMcdeb_changelog_merge/changelog.this(l145): badly formatted trailer lineLINE:  -- Chuck Short  Fri, 17 Feb 2012 11:02:12 -0500dpkg-mergechangelogs: warning: /tmp/tmp6TrdMcdeb_changelog_merge/changelog.other(l3624): badly formatted trailer lineLINE:  -- Chuck Short  Fri, 17 Feb 2012 11:02:12 -0500 M  debian/changelog M  debian/rulesText conflict in debian/rules1 conflicts encountered.ERROR:root:Error occurred during package creation/buildERROR:root:Command '['bzr', 'merge', 'lp:~openstack-ubuntu-testing/nova/essex', '--force']' returned non-zero exit status 1INFO:root:Destroying schroot session: precise-amd64-a8a294d4-a427-438a-af22-0c0622356c62Traceback (most recent call last):  File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 72, in raise esubprocess.CalledProcessError: Command '['bzr', 'merge', 'lp:~openstack-ubuntu-testing/nova/essex', '--force']' returned non-zero exit status 1Build 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-openstack-essex-nova-trunk #669

Title: precise-openstack-essex-nova-trunk
General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/precise-openstack-essex-nova-trunk/669/Project:precise-openstack-essex-nova-trunkDate of build:Wed, 28 Mar 2012 13:01:02 -0400Build duration:10 minBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: All recent builds failed.0ChangesTweak security port validation for ICMPby vishvanandaeditnova/tests/test_api.pyeditAuthorseditnova/api/openstack/compute/contrib/security_groups.pyeditnova/tests/api/ec2/test_cloud.pyeditnova/api/ec2/cloud.pyeditnova/tests/api/openstack/compute/contrib/test_security_groups.pyConsole Output[...truncated 11139 lines...]make[1]: *** [override_dh_auto_test] Error 1make[1]: Leaving directory `/��BUILDDIR��/nova-2012.1+git201203281302'make: *** [build] Error 2dpkg-buildpackage: error: debian/rules build gave error exit status 2Build finished at 20120328-1311FinishedE: Build failure (dpkg-buildpackage died)��� Cleanup  ���Purging /��BUILDDIR��Not cleaning session: cloned chroot in use��� Summary  ���Architecture: amd64Build-Space: 68568Build-Time: 344Distribution: preciseFail-Stage: buildInstall-Time: 45Job: nova_2012.1+git201203281302-0ubuntu1.dscPackage: novaPackage-Time: 414Source-Version: 2012.1+git201203281302-0ubuntu1Space: 68568Status: attemptedVersion: 2012.1+git201203281302-0ubuntu1Finished at 20120328-1311Build needed 00:06:54, 68568k disc spaceERROR:root:Error occurred during package creation/buildERROR:root:Command '['sbuild', '-d', 'precise', '-n', '-A', 'nova_2012.1+git201203281302-0ubuntu1.dsc']' returned non-zero exit status 2INFO:root:Destroying schroot session: precise-amd64-b658b703-536b-46e0-b93d-074655a3f1b3Traceback (most recent call last):  File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 72, in raise esubprocess.CalledProcessError: Command '['sbuild', '-d', 'precise', '-n', '-A', 'nova_2012.1+git201203281302-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 Failure: precise-openstack-essex-deploy #18278

Title: precise-openstack-essex-deploy
General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/precise-openstack-essex-deploy/18278/Project:precise-openstack-essex-deployDate of build:Wed, 28 Mar 2012 14:28:18 -0400Build duration:46 minBuild cause:Started by user adamBuilt on:masterHealth ReportWDescriptionScoreBuild stability: 1 out of the last 5 builds failed.80ChangesNo ChangesBuild Artifactslogs/syslog.tar.gzlogs/test-03.os.magners.qa.lexington-log.tar.gzlogs/test-04.os.magners.qa.lexington-log.tar.gzlogs/test-05.os.magners.qa.lexington-log.tar.gzlogs/test-06.os.magners.qa.lexington-log.tar.gzlogs/test-07.os.magners.qa.lexington-log.tar.gzlogs/test-08.os.magners.qa.lexington-log.tar.gzlogs/test-09.os.magners.qa.lexington-log.tar.gzlogs/test-10.os.magners.qa.lexington-log.tar.gzlogs/test-11.os.magners.qa.lexington-log.tar.gzlogs/test-12.os.magners.qa.lexington-log.tar.gzConsole Output[...truncated 11866 lines...]INFO:root:Setting up connection to test-07.os.magners.qa.lexingtonINFO:paramiko.transport:Connected (version 2.0, client OpenSSH_5.9p1)INFO:paramiko.transport:Authentication (publickey) successful!INFO:paramiko.transport:Secsh channel 1 opened.INFO:paramiko.transport.sftp:[chan 1] Opened sftp connection (server version 3)INFO:root:Setting up connection to test-08.os.magners.qa.lexingtonINFO:paramiko.transport:Connected (version 2.0, client OpenSSH_5.9p1)INFO:paramiko.transport:Authentication (publickey) successful!INFO:paramiko.transport:Secsh channel 1 opened.INFO:paramiko.transport.sftp:[chan 1] Opened sftp connection (server version 3)INFO:root:Archiving logs on test-07.os.magners.qa.lexingtonINFO:paramiko.transport:Secsh channel 2 opened.INFO:root:Archiving logs on test-08.os.magners.qa.lexingtonINFO:paramiko.transport:Secsh channel 2 opened.INFO:root:Archiving logs on test-09.os.magners.qa.lexingtonINFO:paramiko.transport:Secsh channel 2 opened.INFO:root:Archiving logs on test-04.os.magners.qa.lexingtonERROR:root:Coult not create tarball of logs on test-04.os.magners.qa.lexingtonINFO:root:Archiving logs on test-05.os.magners.qa.lexingtonERROR:root:Coult not create tarball of logs on test-05.os.magners.qa.lexingtonINFO:root:Archiving logs on test-03.os.magners.qa.lexingtonINFO:paramiko.transport:Secsh channel 2 opened.INFO:root:Archiving logs on test-06.os.magners.qa.lexingtonINFO:paramiko.transport:Secsh channel 2 opened.INFO:root:Archiving logs on test-02.os.magners.qa.lexingtonINFO:paramiko.transport:Secsh channel 2 opened.INFO:root:Grabbing information from test-07.os.magners.qa.lexingtonINFO:root:Grabbing information from test-08.os.magners.qa.lexingtonINFO:root:Grabbing information from test-09.os.magners.qa.lexingtonINFO:root:Grabbing information from test-04.os.magners.qa.lexingtonERROR:root:Unable to get information from test-04.os.magners.qa.lexingtonINFO:root:Grabbing information from test-05.os.magners.qa.lexingtonERROR:root:Unable to get information from test-05.os.magners.qa.lexingtonINFO:root:Grabbing information from test-03.os.magners.qa.lexingtonINFO:root:Grabbing information from test-06.os.magners.qa.lexingtonINFO:root:Grabbing information from test-02.os.magners.qa.lexingtonERROR:root:Unable to get information from test-02.os.magners.qa.lexingtonINFO:paramiko.transport.sftp:[chan 1] sftp session closed.INFO:paramiko.transport.sftp:[chan 1] sftp session closed.INFO:paramiko.transport.sftp:[chan 1] sftp session closed.Traceback (most recent call last):  File "/var/lib/jenkins/tools/jenkins-scripts/collate-test-logs.py", line 91, in connections[host]["sftp"].close()KeyError: 'sftp'+ exit 1Build step 'Execute shell' marked build as failureArchiving artifactsEmail 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-openstack-essex-deploy #18279

Title: precise-openstack-essex-deploy
General InformationBUILD SUCCESSBuild URL:https://jenkins.qa.ubuntu.com/job/precise-openstack-essex-deploy/18279/Project:precise-openstack-essex-deployDate of build:Wed, 28 Mar 2012 15:25:44 -0400Build duration:14 minBuild cause:Started by user adamBuilt on:masterHealth ReportWDescriptionScoreBuild stability: 1 out of the last 5 builds failed.80ChangesNo ChangesBuild Artifactslogs/syslog.tar.gzlogs/test-03.os.magners.qa.lexington-log.tar.gzlogs/test-04.os.magners.qa.lexington-log.tar.gzlogs/test-05.os.magners.qa.lexington-log.tar.gzlogs/test-06.os.magners.qa.lexington-log.tar.gzlogs/test-07.os.magners.qa.lexington-log.tar.gzlogs/test-08.os.magners.qa.lexington-log.tar.gzlogs/test-09.os.magners.qa.lexington-log.tar.gzlogs/test-10.os.magners.qa.lexington-log.tar.gzlogs/test-11.os.magners.qa.lexington-log.tar.gzlogs/test-12.os.magners.qa.lexington-log.tar.gzConsole Output[...truncated 2489 lines...]  -> Relation: nova-compute:shared-db <-> mysql:shared-db[DEBUG] Calling: juju add-relation nova-compute:shared-db mysql:shared-db[DEBUG] Found interface for relation '(u'nova-compute', u'rabbitmq')': amqp  -> Relation: nova-compute:amqp <-> rabbitmq:amqp[DEBUG] Calling: juju add-relation nova-compute:amqp rabbitmq:amqp[DEBUG] Found interface for relation '(u'nova-compute', u'glance')': image-service  -> Relation: nova-compute:image-service <-> glance:image-service[DEBUG] Calling: juju add-relation nova-compute:image-service glance:image-service  -> Relation: nova-compute:network-manager <-> nova-cloud-controller:network-manager[DEBUG] Calling: juju add-relation nova-compute:network-manager nova-cloud-controller:network-manager[DEBUG] Found interface for relation '(u'nova-compute', u'keystone')': identity-service  -> Relation: nova-compute:identity-service <-> keystone:identity-service[DEBUG] Calling: juju add-relation nova-compute:identity-service keystone:identity-service- Ensuring relation state[DEBUG] Calling 'juju status'...- Deployment complete in 811 seconds.- Juju command log:juju deploy --config=/tmp/tmpQF7HJo --repository=/var/lib/jenkins/jobs/precise-openstack-essex-deploy/workspace local:nova-computejuju deploy --config=/tmp/tmpQF7HJo --repository=/var/lib/jenkins/jobs/precise-openstack-essex-deploy/workspace local:nova-volumejuju deploy --config=/tmp/tmpQF7HJo --repository=/var/lib/jenkins/jobs/precise-openstack-essex-deploy/workspace local:nova-cloud-controllerjuju deploy --config=/tmp/tmpQF7HJo --repository=/var/lib/jenkins/jobs/precise-openstack-essex-deploy/workspace local:keystonejuju deploy --repository=/var/lib/jenkins/jobs/precise-openstack-essex-deploy/workspace local:rabbitmqjuju deploy --config=/tmp/tmpQF7HJo --repository=/var/lib/jenkins/jobs/precise-openstack-essex-deploy/workspace local:glancejuju add-relation keystone:shared-db mysql:shared-dbjuju add-relation nova-cloud-controller:shared-db mysql:shared-dbjuju add-relation nova-cloud-controller:amqp rabbitmq:amqpjuju add-relation nova-cloud-controller:image-service glance:image-servicejuju add-relation nova-cloud-controller:identity-service keystone:identity-servicejuju add-relation glance:shared-db mysql:shared-dbjuju add-relation glance:identity-service keystone:identity-servicejuju add-relation nova-volume:shared-db mysql:shared-dbjuju add-relation nova-volume:amqp rabbitmq:amqpjuju add-relation nova-compute:shared-db mysql:shared-dbjuju add-relation nova-compute:amqp rabbitmq:amqpjuju add-relation nova-compute:image-service glance:image-servicejuju add-relation nova-compute:network-manager nova-cloud-controller:network-managerjuju add-relation nova-compute:identity-service keystone:identity-service+ rc=0+ echo 'Deployer returned: 0'Deployer returned: 0+ [[ 0 != 0 ]]+ jenkins-cli build precise-openstack-essex-test+ exit 0Archiving artifactsEmail 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 Failure: precise-openstack-essex-test #512

Title: precise-openstack-essex-test
General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/precise-openstack-essex-test/512/Project:precise-openstack-essex-testDate of build:Wed, 28 Mar 2012 15:40:18 -0400Build duration:5 min 7 secBuild cause:Started by command lineBuilt on:masterHealth ReportWDescriptionScoreBuild stability: 1 out of the last 5 builds failed.80ChangesNo ChangesConsole Output[...truncated 842 lines...]++---+---+--+---+--+---+-+| 1  | m1.tiny   | 512   | 0| 0 |  | 1 | || 2  | m1.small  | 2048  | 20   | 0 |  | 1 | || 3  | m1.medium | 4096  | 40   | 0 |  | 2 | || 4  | m1.large  | 8192  | 80   | 0 |  | 4 | || 5  | m1.xlarge | 16384 | 160  | 0 |  | 8 | |++---+---+--+---+--+---+-+++ nova flavor-list++ grep m1.tiny++ get_field 1++ read data++ '[' 1 -lt 0 ']'++ field='$2'++ echo '| 1  | m1.tiny   | 512   | 0| 0 |  | 1 | |'++ awk '-F[ \t]*\\|[ \t]*' '{print $2}'++ read data+ INSTANCE_TYPE=1+ [[ -z 1 ]]+ NAME=ex-vol++ nova boot --flavor 1 --image f8af6946-02e9-444f-b173-d508728bd36e ex-vol --security_groups=++ grep ' id '++ get_field 2++ read data++ '[' 2 -lt 0 ']'++ field='$3'++ echo '| id  | 5aecba67-3a53-4cff-808b-555facf6c24b |'++ awk '-F[ \t]*\\|[ \t]*' '{print $3}'++ read data+ VM_UUID=5aecba67-3a53-4cff-808b-555facf6c24b+ die_if_not_set VM_UUID 'Failure launching ex-vol'+ local exitcode=0+ set +o xtrace+ timeout 60 sh -c 'while ! nova show 5aecba67-3a53-4cff-808b-555facf6c24b | grep status | grep -q ACTIVE; do sleep 1; done'+ echo 'server didn'\''t become active!'server didn't become active!+ exit 1=SKIP boot_from_volumeSKIP client-argsSKIP client-envSKIP swiftPASS bundleFAILED eucaFAILED floating_ipsFAILED volumes=Build 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-openstack-essex-test #515