Re: [Openstack] [Nova] Deprecation of nova-network deferred to Icehouse

[Gary Kotton]

Hi,
There was also talk of having neutron as the default network setting. Do we 
still want to move towards this in devstack? I know that Yong is working on a 
solution for having the multi node support for the floating IP's.
At the last summit I was going to look into the option of doing a live 
migration from a traditional nova network to a neutron network. I have not made 
much progress with this due to not having enough cycles. My humble apologies. 
Would anyone else be willing to look into this?
Thanks
Gary

-Original Message-
From: Openstack 
[mailto:openstack-bounces+gkotton=vmware@lists.launchpad.net] On Behalf Of 
Russell Bryant
Sent: Friday, July 26, 2013 4:36 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] [Nova] Deprecation of nova-network deferred to Icehouse

Greetings,

One of the goals we had for the Havana release was to be able to deprecate 
nova-network in favor of Neutron [1].  Since this was a high priority item that 
has a significant impact on others' future plans, I wanted to provide an update 
on it.

Completing this in Havana depended on a couple of things.

1) Neutron reaching feature parity with nova-network.

2) Ensuring that there is a smooth migration path from nova-network to Neutron 
for existing deployments.

As far as I know, #1 is still on track for Havana.  Unfortunately, #2 has not 
seen much progress.  As a result, the deprecation of nova-network has now been 
deferred to the Icehouse release.

Also note that deprecation does not mean immediate removal.  Removal will come 
at least one release cycle after it has been marked deprecated, which means 
that nova-network may be removed in the J release at the earliest at this point.

Thanks,

[1] https://blueprints.launchpad.net/nova/+spec/deprecate-nova-network

--
Russell Bryant
Nova PTL

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

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

Re: [Openstack] How to Install OpenStack ???????????

[Gary Kotton]

Hi,
There are a number of ways of going about this:

1.   You can run devstack (www.devstack.orghttp://www.devstack.org). This 
is from the sources.

2.   You can do installation via the manuals

3.   RDO also has a very nice and easy way of going about things - it make 
use of packstack - http://openstack.redhat.com/Quickstart
Hope that this helps
Thanks
Gary

From: Openstack 
[mailto:openstack-bounces+gkotton=vmware@lists.launchpad.net] On Behalf Of 
Jake G.
Sent: Friday, July 12, 2013 9:59 AM
To: openstack@lists.launchpad.net
Subject: [Openstack] How to Install OpenStack ???

Hi All, I have been struggling with installing Openstack for the past 2 weeks 
and I am about to rip my own hair out.

rant
Does anyone have installation instructions that a human being can actually 
understand and follow? I am usually pretty good at installing new tech but 
OpenStack is the most convoluted environment (even worse documentation) I have 
ever come in contact with (Worse than IBM software). The advanced install and 
config of CloudStack 4.1 is a breeze compare to Openstack. Was this made to 
purposely line the pockets of Openstack deployment consulting companies? 
Openstack might be great but no one will know because its impossible to deploy.
/rant

I`m sure I am not the only one who feels this way. I would appreciate any help 
anyone can give. Someones blog, other installation methods, anything

Thank you very much


___
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] Quantum is changing its name to...

[Gary Kotton]

On 06/19/2013 07:13 PM, Mark McClain wrote:

All-

The OpenStack Networking team is happy to announce that the Quantum project 
will be changing its name to Neutron. You'll soon see Neutron in lots of places 
as we work to implement the name change within OpenStack.


I hope that Nickelodeon does not get upset with us - 
http://en.wikipedia.org/wiki/Jimmy_Neutron_%28character%29





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



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

Re: [Openstack] [openstack][quantum] How to understand 'ovs-vsctl show'?

[Gary Kotton]

On 05/21/2013 07:04 AM, Qinglong.Meng wrote:

Hi all,
Here is output of cmd 'ovs-vsctl show'. But how to explain it. Can 
anybody help me?


Please look at the following diagram to see how the VM connects to the 
OVS when using the Hybrid driver:


https://docs.google.com/drawings/d/1wax2Nlk-LRJeOXwF_6X9L05cAf9HKl2FI_0B51rG4XE/edit?usp=sharing

I still need to add in some extras to provide a better picture.

A luta continua
Gary


root@compute01:~# ovs-vsctl show
e98109dd-eb2d-43b0-82f8-e2c733db49d7
Bridge qbr876fed87-40
Port tap876fed87-40
Interface tap876fed87-40
Port qvb876fed87-40
Interface qvb876fed87-40
Port qbr876fed87-40
Interface qbr876fed87-40
type: internal
Bridge br-int
Port br-int
Interface br-int
type: internal
Port qvo876fed87-40
tag: 1
Interface qvo876fed87-40
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Port qvoeeba05d1-fb
tag: 1
Interface qvoeeba05d1-fb
Port tapa27f848c-27
tag: 1
Interface tapa27f848c-27
Port tapb55a3af4-29
tag: 1
Interface tapb55a3af4-29
Bridge br-tun
Port gre-2
Interface gre-2
type: gre
options: {in_key=flow, out_key=flow, 
remote_ip=10.10.10.73}

Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port gre-1
Interface gre-1
type: gre
options: {in_key=flow, out_key=flow, 
remote_ip=10.10.10.72}

Port br-tun
Interface br-tun
type: internal
Bridge virbr0
Port virbr0
Interface virbr0
type: internal
Bridge br-ex
Port eth3
Interface eth3
Port tap15ee53c7-1d
Interface tap15ee53c7-1d
Port br-ex
Interface br-ex
type: internal
Bridge qbreeba05d1-fb
Port tapeeba05d1-fb
Interface tapeeba05d1-fb
Port qvbeeba05d1-fb
Interface qvbeeba05d1-fb
Port qbreeba05d1-fb
Interface qbreeba05d1-fb
type: internal
ovs_version: 1.4.0+build0

Best Regards,
Tks

--

Lawrency Meng
mail: mengql112...@gmail.com mailto:mengql112...@gmail.com
___
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


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

Re: [Openstack] [openstack][quantum] nova-compute DOWN with 'brctl addif' cmd

[Gary Kotton]

On 05/21/2013 06:34 AM, Qinglong.Meng wrote:

Hi friends,
the nova-compute log say 'brctl addif qbr876fed87-40 
qvb876fed87-40' error, when I reboot the server by 'init 6', and the 
nova-compute service


Can you please clarify which server you reboot?

Please loot at 
https://docs.google.com/drawings/d/1wax2Nlk-LRJeOXwF_6X9L05cAf9HKl2FI_0B51rG4XE/edit?usp=sharing 
to see how the VM connects to the OVS. The error that you see is when 
the compute node is tring to add an interface to the bridge qbr. Maybe 
in the case the bridge already exists and there is an interface attached.


This certainly needs to be investigated.

Would it be possible that you provide steps on how you reproduce this 
and I can investigate further.


Thanks in advance
Gary


down.
But it's Ok when I restart nova-compute service. so it's strange 
for me.

Here are some usefully info, maybe helpfully.

nova-compute.log:http://paste.openstack.org/show/37508/
ovs-vsctl: http://paste.openstack.org/show/37509/

And body help me..

Best regards,

Tks

--

Lawrency Meng
mail: mengql112...@gmail.com mailto:mengql112...@gmail.com
___
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


___
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] [Grizzly] VMs not authorized by metadata server

[Gary Kotton]

On 04/27/2013 12:44 PM, Michaël Van de Borne wrote:
Anybody has an idea about why the nova metadata server rejects the VM 
requests?


Hi,
Just a few questions:-
1. Can you please check /etc/quantum/metadata_agent.ini to see that you 
have the correct quantum keystone credential configured?

2. Can you please make sure that you are running the quantum metadata proxy.
3. In nova.conf can you please see that service_quantum_metadata_proxy 
= True is set.

Thanks
Gary





Le 26/04/2013 15:58, Michaël Van de Borne a écrit :

Hi there,

I've installed Grizzly on 3 servers:
compute (howard)
controller (leonard)
network (rajesh)).

Namespaces are ON
Overlapping IPs are ON

When booting, my VMs can reach the metadata server (on the controller 
node), but it responds a 500 Internal Server Error


*Here is the error from the log of nova-api:*
2013-04-26 15:35:28.149 19902 INFO nova.metadata.wsgi.server [-] 
(19902) accepted ('192.168.202.105', 54871)


2013-04-26 15:35:28.346 ERROR nova.network.quantumv2 
[req-52ffc3ae-a15e-4bf4-813c-6596618eb430 None None] 
_get_auth_token() failed
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2 Traceback 
(most recent call last):
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2   File 
/usr/lib/python2.7/dist-packages/nova/network/quantumv2/__init__.py, line 
40, in _get_auth_token
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2 
httpclient.authenticate()
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2   File 
/usr/lib/python2.7/dist-packages/quantumclient/client.py, line 193, 
in authenticate
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2 
content_type=application/json)
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2   File 
/usr/lib/python2.7/dist-packages/quantumclient/client.py, line 131, 
in _cs_request
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2 raise 
exceptions.Unauthorized(message=body)
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2 
Unauthorized: {error: {message: The request you have made 
requires authentication., code: 401, title: Not Authorized}}

2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2
2013-04-26 15:35:28.347 ERROR nova.api.metadata.handler 
[req-52ffc3ae-a15e-4bf4-813c-6596618eb430 None None] Failed to get 
metadata for instance id: 05141f81-04cc-4493-86da-d2c05fd8a2f9
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler 
Traceback (most recent call last):
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler   File 
/usr/lib/python2.7/dist-packages/nova/api/metadata/handler.py, line 
179, in _handle_instance_id_request
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler 
remote_address)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler   File 
/usr/lib/python2.7/dist-packages/nova/api/metadata/handler.py, line 
90, in get_metadata_by_instance_id
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler 
instance_id, address)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler   File 
/usr/lib/python2.7/dist-packages/nova/api/metadata/base.py, line 
417, in get_metadata_by_instance_id
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler 
return InstanceMetadata(instance, address)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler   File 
/usr/lib/python2.7/dist-packages/nova/api/metadata/base.py, line 
143, in __init__
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler 
conductor_api=capi)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler   File 
/usr/lib/python2.7/dist-packages/nova/network/quantumv2/api.py, 
line 359, in get_instance_nw_info
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler 
result = self._get_instance_nw_info(context, instance, networks)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler   File 
/usr/lib/python2.7/dist-packages/nova/network/quantumv2/api.py, 
line 367, in _get_instance_nw_info
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler 
nw_info = self._build_network_info_model(context, instance, networks)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler   File 
/usr/lib/python2.7/dist-packages/nova/network/quantumv2/api.py, 
line 777, in _build_network_info_model
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler 
client = quantumv2.get_client(context, admin=True)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler   File 
/usr/lib/python2.7/dist-packages/nova/network/quantumv2/__init__.py, line 
67, in get_client
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler 
return _get_client(token=token)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler   File 
/usr/lib/python2.7/dist-packages/nova/network/quantumv2/__init__.py, line 
49, in _get_client
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler 
token = _get_auth_token()
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler  

Re: [Openstack] [quantum][folsom] error with dhcp agent

[Gary Kotton]

On 04/11/2013 01:59 PM, Arindam Choudhury wrote:

Hi,

I am trying to install openstack folsom on fedora 18. while installing 
quantum I am having this problem:


# cat dhcp-agent.log
2013-04-11 12:53:31 INFO [quantum.common.config] Logging enabled!
2013-04-11 12:55:39ERROR [quantum.openstack.common.rpc.impl_qpid] 
Unable to connect to AMQP server: [Errno 110] ETIMEDOUT. Sleeping 1 
seconds


Did you run the script - quantum-dhcp-setup? If so you would be prompted 
to indicate the IP address of the message broker (QPID in this case).




# cat openvswitch-agent.log
2013-04-11 12:53:22 INFO [quantum.common.config] Logging enabled!
2013-04-11 12:53:22 INFO 
[quantum.plugins.openvswitch.agent.ovs_quantum_agent] Bridge mappings: {}
2013-04-11 12:53:22ERROR [quantum.agent.linux.ovs_lib] Unable to 
execute ['ovs-vsctl', '--timeout=2', '--', '--if-exists', 'del-port', 
'br-int', 'patch-tun']. Exception:
Command: ['sudo', 'quantum-rootwrap', '/etc/quantum/rootwrap.conf', 
'ovs-vsctl', '--timeout=2', '--', '--if-exists', 'del-port', 'br-int', 
'patch-tun']

Exit code: 1
Stdout: ''


Are you using the Grizzly packages? This issue was fixed a few days ago.

Stderr: 'Traceback (most recent call last):\n  File 
/usr/bin/quantum-rootwrap, line 95, in module\n
env=filtermatch.get_environment(userargs))\n  File 
/usr/lib64/python2.7/subprocess.py, line 679, in __init__\n
errread, errwrite)\n  File /usr/lib64/python2.7/subprocess.py, line 
1249, in _execute_child\nraise child_exception\nOSError: [Errno 
13] Permission denied\n'
2013-04-11 12:53:22ERROR [quantum.agent.linux.ovs_lib] Unable to 
execute ['ovs-ofctl', 'del-flows', 'br-int']. Exception:
Command: ['sudo', 'quantum-rootwrap', '/etc/quantum/rootwrap.conf', 
'ovs-ofctl', 'del-flows', 'br-int']

Exit code: 1
Stdout: ''
Stderr: 'ovs-ofctl: br-int is not a bridge or a socket\n'
2013-04-11 12:53:23ERROR [quantum.agent.linux.ovs_lib] Unable to 
execute ['ovs-ofctl', 'add-flow', 'br-int', 
'hard_timeout=0,idle_timeout=0,priority=1,actions=normal']. Exception:
Command: ['sudo', 'quantum-rootwrap', '/etc/quantum/rootwrap.conf', 
'ovs-ofctl', 'add-flow', 'br-int', 
'hard_timeout=0,idle_timeout=0,priority=1,actions=normal']

Exit code: 1
Stdout: ''
Stderr: 'ovs-ofctl: br-int is not a bridge or a socket\n'
2013-04-11 12:55:30ERROR [quantum.openstack.common.rpc.impl_qpid] 
Unable to connect to AMQP server: [Errno 110] ETIMEDOUT. Sleeping 1 
seconds




I have followed these instructions:
[(keystone_admin)]$ keystone service-create --name openstack_network 
--type network --description Openstack Networking Service

+-+--+
| Property | Value |
+-+--+
| description | Openstack Networking Service |
| id | cdc15413851341e7a1a827672b81c8e8 |
| name | openstack_network |
| type | network |
+-+--+
[(keystone_admin)]$ keystone endpoint-create --region RegionOne 
--service-id cdc15413851341e7a1a827672b81c8e8 --publicurl 
'http://109.158.65.21:9696' --adminurl 'http://109.158.65.21:9696' 
--internalurl 'http://109.158.65.21:9696'

+-+--+
| Property | Value |
+-+--+
| adminurl | http://109.158.65.21:9696 |
| id | 16668a90ff0445068b8e9fc01d568b89 |
| internalurl | http://109.158.65.21:9696 |
| publicurl | http://109.158.65.21:9696 |
| region | RegionOne |
| service_id | cdc15413851341e7a1a827672b81c8e8 |
+-+--+
[(keystone_admin)]$ keystone tenant-create --name openstack_network 
--description OpenStack network tenant

+-+--+
| Property | Value |
+-+--+
| description | OpenStack network tenant |
| enabled | True |
| id | c8274f56a1cd4b2a968ba81a47278476 |
| name | openstack_network |
+-+--+
[(keystone_admin)]$ keystone user-create --name openstack_network 
--pass openstack_network --tenant-id c8274f56a1cd4b2a968ba81a47278476

+--+-+
| Property | Value |
+--+-+
| email | |
| enabled | True |
| id | e2ba6a8d3c1b4758844972b1d1df3d6b |
| name | openstack_network |
| password | 
$6$rounds=4$h7GvK.VDbEUrikf4$UP.KDuvz8VBhALEm75ZSOFpEdj1z2MecQhPYyyliyJn3Q.oxCmU/PWxPsD8cJ33z.YqtvhMI7RKXQEulceFok0 
|

| tenantId | c8274f56a1cd4b2a968ba81a47278476 |
+--+-+
[(keystone_admin)]$ keystone role-list
+--+---+
| id | name |

Re: [Openstack] multi-host mode in quantum

[Gary Kotton]

On 04/04/2013 10:04 PM, Xin Zhao wrote:

Hello,

As Grizzly is released today, can anybody confirm that the multi-host 
network mode is supported by Quantum in this new release?


Sadly not. Yong (gongysh) did great work here and made some huge strides 
but sadly we did not managed to get the last part in - the HA support 
for the L3 agent. I am hoping that we can get this reviewed and tested 
in the near future so that we can consider backporting this very 
valuable feature to stable grizzly.




Thanks,
Xin

On 12/13/2012 6:04 AM, Heiko Krämer wrote:

Hey Guys,

it's a good point. I hope this option will include in Grizzly. We get 
now (since the switch to Quantum) network I/O bottlenecks without 
using all NIC's of our nodes.

So I'm looking forward to Grizzly 

Greetings
Heiko

Am 12.12.2012 17:11, schrieb Gary Kotton:

On 12/12/2012 05:58 PM, Xin Zhao wrote:

Hello,

If I understand it correctly, multi-host network mode is not 
supported (yet) in quantum in Folsom.
I wonder what's the recommended way of running multiple network 
nodes (for load balancing and
bandwidth concerns) in quantum?  Any documentation links will be 
appreciated.


At the moment this is in discussion upstream. It is currently not 
supported but we are hoping to have support for this in grizzly.


Thanks,
Xin



___
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


___
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] Could s/o clarify if DHCP and L3 agents *must* be on different hosts if namespaces are disabled ?

[Gary Kotton]

On 03/20/2013 06:16 PM, Sylvain Bauza wrote:

Hi,

As per https://bugs.launchpad.net/quantum/+bug/1155050 and also other 
litterature, I do see doc alerts saying that Quantum L3 and DHCP 
agents must be on different hosts.
Let me be honest, I successfully installed and configured both on the 
same physical machine, using GRE tunnels and use_namespaces = False, 
and everything is running smoothly : my VMs are getting leases and do 
have floating IPs without trouble.


Yes, this works. The problem is ensuring the network isolation. That is, 
someone can make changes in the routing table on the host which will 
enable one to gain access to the quantum networks. That is why we 
suggest that they run on different hosts. We have a review that is open 
to enable one to enforce this when the agents starts (this is disabled 
by default to ensure backward compatability and to enable one to run an 
all in one setup - for proof of concepts and testing)





So, am I wrong ? What is the terrible thing which could happe in a 
next few days if still keeping my environment as it is ?


No, it is not terrible at all.



Thanks for clarifying me,
-Sylvain

___
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] quantum g3-rc1

[Gary Kotton]

On 03/18/2013 05:14 AM, tommy(??) wrote:

more:

means we can not command : quantum component-list


This command was replaced by quantum agent-list. Please note that you 
need to an admin user to be able to invoke this.

Thanks
Gary



Thanks,
Tommy Bao


2013/3/18 tommy(??) bychya...@gmail.com mailto:bychya...@gmail.com

Greetings all,



 in quantum g3-rc1
https://launchpad.net/quantum/grizzly/grizzly-rc1

 i find not python-quantumclient suuport the multiple l3 and
dhcp agents for Quantum
https://blueprints.launchpad.net/quantum/+spec/quantum-scheduler

 in my test: autor's fetch support, why,
   Quanutm:
git clone https://review.openstack.org/openstack/quantum

https://mail.jd.com/owa/redir.aspx?C=95634959168048578b2e0eab88520712URL=https%3a%2f%2freview.openstack.org%2fopenstack%2fquantum
git fetch https://review.openstack.org/openstack/quantum

https://mail.jd.com/owa/redir.aspx?C=95634959168048578b2e0eab88520712URL=https%3a%2f%2freview.openstack.org%2fopenstack%2fquantum
 refs/changes/16/18216/17
 git checkout FETCH_HEAD

Quantumclient:
git clone git://github.com/openstack/python-quantumclient.git
http://github.com/openstack/python-quantumclient.git
git fetch
https://review.openstack.org/openstack/python-quantumclient

https://mail.jd.com/owa/redir.aspx?C=95634959168048578b2e0eab88520712URL=https%3a%2f%2freview.openstack.org%2fopenstack%2fpython-quantumclient
 refs/changes/17/18217/4
 git checkout FETCH_HEAD



Thanks,
Tommy Bao

-- 
!





--
!


___
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] TC candidacy

[Gary Kotton]

Hi,

I'd like to run for the Technical Committee in the up and coming elections.

I am a Principle Software Engineer at Red Hat. I have been actively 
developing OpenStack since the Essex release. I am currently a Quantum 
core developer. In addition to this I am also core on the Stable 
Maintenance team. I also have contribute to Nova, OSLO, documentation 
and devstack. In Nova the work was mainly focused on the Quantum 
integrations. My latest contribution was the VM ensembles, part of 
which was added in Grizzly release and hopefully will be completed in 
the up and coming Havana release. I spend most of my days reviewing, 
testing, debugging, documenting and developing with the goal of making 
OpenStack better. I am thankful to my employer Red Hat to have the 
opportunity and time to work on such and amazing project.


I have close to 18 years of experience in the industry. Over that course 
of time I have strived to produce quality, usable, robust and optimal 
solutions. I would like to bring all that experience to the table to 
ensure that we have a better product. We are working in a very healthy, 
dynamic and vibrant community. A few things that I would like to improve 
are the following:

- cross project interaction
- growth of the community
- sharing of ideas and information

In my spare time I run.

Thanks
Gary




___
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] Agent out of sync with plugin!

[Gary Kotton]

On 03/12/2013 12:13 AM, Greg Chavez wrote:


So I'm setting up Folsom on Ubuntu 12.10, using the Github Folsom 
Install Guide:


https://github.com/mseknibilel/OpenStack-Folsom-Install-guide/blob/master/OpenStack_Folsom_Install_Guide_WebVersion.rst

After following the steps to instantiate the network node, I'm left 
with 3 new but downed OVS bridges, and three error-filled logs for 
ovs-plugin, dhcp-agent, and l3-agent.  I rectify it with this:


http://pastebin.com/L43d9q8a

When I restart the networking and then restart the plugin and agents, 
everything seems to work, but I'm getting this strange INFO message in 
/var/log/quantum/openvswitch-agent.log:


2013-03-11 17:48:02 INFO 
[quantum.plugins.openvswitch.agent.ovs_quantum_agent] Agent out of 
sync with plugin!


I traced it to this .py file:

https://github.com/openstack/quantum/blob/master/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py

Now I realize that this is and INFO message, not an error.  But I 
would still like to know what this means.  Thanks!


The Quantum agents need to retrieve the port data from the Quantum 
service. When the agents start this is done automatically (hence the 
message that you have seen). This can also happen if there is an 
exception in the agent or if the agent is unable to communicate with the 
service - for example there is a problem with the connection between the 
agent and the service (link down, etc).




--
\*..+.-
--Greg Chavez
+//..;};


___
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] Agent out of sync with plugin!

[Gary Kotton]

On 03/12/2013 01:35 PM, Greg Chavez wrote:
Logan, thanks for your reply.  I've been very conscientious of NTP, so 
I'm very confident that that is not an issue.


Gary: so in this case the agent= quantum-plugin-openvswitch-agent


agent== quantum-plugin-openvswitch-agent - yes


, and plugin = quantum-server.


plugin == quantum-server - yes. The quantum service runs the plugin.

 That's confusing.  And what you're saying is that the ovs 
plugin/agent - whatever it is - is simply stating that it assumes it's 
out of sync since it's starting up, and it's going to phone home.  Is 
that right?  Thanks!


Yes, that is correct. Even the first time that it starts it is out of 
sync :)



On Tue, Mar 12, 2013 at 3:18 AM, Gary Kotton gkot...@redhat.com 
mailto:gkot...@redhat.com wrote:


On 03/12/2013 12:13 AM, Greg Chavez wrote:


So I'm setting up Folsom on Ubuntu 12.10, using the Github Folsom
Install Guide:


https://github.com/mseknibilel/OpenStack-Folsom-Install-guide/blob/master/OpenStack_Folsom_Install_Guide_WebVersion.rst

After following the steps to instantiate the network node, I'm
left with 3 new but downed OVS bridges, and three error-filled
logs for ovs-plugin, dhcp-agent, and l3-agent.  I rectify it with
this:

http://pastebin.com/L43d9q8a

When I restart the networking and then restart the plugin and
agents, everything seems to work, but I'm getting this strange
INFO message in /var/log/quantum/openvswitch-agent.log:

2013-03-11 17:48:02 INFO
[quantum.plugins.openvswitch.agent.ovs_quantum_agent] Agent out
of sync with plugin!

I traced it to this .py file:


https://github.com/openstack/quantum/blob/master/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py

Now I realize that this is and INFO message, not an error.  But I
would still like to know what this means.  Thanks!


The Quantum agents need to retrieve the port data from the Quantum
service. When the agents start this is done automatically (hence
the message that you have seen). This can also happen if there is
an exception in the agent or if the agent is unable to communicate
with the service - for example there is a problem with the
connection between the agent and the service (link down, etc).



-- 
\*..+.-

--Greg Chavez
+//..;};


___
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





--
\*..+.-
--Greg Chavez
+//..;};


___
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] Doubt quantum script

[Gary Kotton]

On 03/04/2013 05:45 PM, Guilherme Russi wrote:
Found the problem, when I did the step: ovs-vsctl add-port br-ex eth2, 
it stopped my lan communication.


The l3 agent makes changes to the routing table. This may cause a 
conflict with the default gateway. I would suggest having a static route 
for the management traffic (I guess that your could have been received 
via DHCP).

Thanks
Gary



Any idea?



2013/3/4 Guilherme Russi luisguilherme...@gmail.com 
mailto:luisguilherme...@gmail.com


Hello guys,

 I'm installing the openstack folsom again, but now I have a
controller node in a proper physical machine and the network node
in another one, but which of them I execute the quantum-networking
script? I'm following this manual

http://docs.openstack.org/folsom/basic-install/content/basic-install_network.html
and I'm trying to execute at the network node, but I got error
when execute it. When I type keystone tenant-list and quantum
net-list I got the error [Errno 111] Unable to communicate with
identity service.
 My novarc is configured at the network node too.

Thanks.

Guilherme.




___
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] Initial quantum network state broken

[Gary Kotton]

Hi Greg,
Sorry to hear you woes. I agree with you that setting things up is 
challeniging and sometimes problematic. I would suggest a number of things:
1. Give devstack a bash. This is very helpful and useful to try and 
understand how everything fits and works together. www.devstack.org
2. A few months ago we did a test day with Fedora for folsom. There are 
Quantum commands and setup details (you can use these on other 
distributions too) - 
https://fedoraproject.org/wiki/QA:Testcase_Quantum_V2#Setup

Hope that that helps.
Thanks
Gary


On 02/19/2013 01:55 AM, Greg Chavez wrote:
Third time I'm replying to my own message.  It seems like the initial 
network state is a problem for many first time openstackers.  Surely 
somewhere would be well to assist me.  I'm running out of time to make 
this work.  Thanks.



On Sun, Feb 17, 2013 at 3:08 AM, Greg Chavez greg.cha...@gmail.com 
mailto:greg.cha...@gmail.com wrote:


I'm replying to my own message because I'm desperate.  My network
situation is a mess.  I need to add this as well: my bridge
interfaces are all down.  On my compute node:

root@kvm-cs-sn-10i:/var/lib/nova/instances/instance-0005# ip
addr show | grep ^[0-9]
1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN
2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc mq state
UP qlen 1000
3: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc mq state
UP qlen 1000
4: eth2: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN qlen
1000
5: eth3: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN qlen
1000
9: br-int: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN
10: br-eth1: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN
13: phy-br-eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc
pfifo_fast state UP qlen 1000
14: int-br-eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc
pfifo_fast state UP qlen 1000
15: qbre56c5d9e-b6: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500
qdisc noqueue state UP
16: qvoe56c5d9e-b6: BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP mtu
1500 qdisc pfifo_fast state UP qlen 1000
17: qvbe56c5d9e-b6: BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP mtu
1500 qdisc pfifo_fast master qbre56c5d9e-b6 state UP qlen 1000
19: qbrb805a9c9-11: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500
qdisc noqueue state UP
20: qvob805a9c9-11: BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP mtu
1500 qdisc pfifo_fast state UP qlen 1000
21: qvbb805a9c9-11: BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP mtu
1500 qdisc pfifo_fast master qbrb805a9c9-11 state UP qlen 1000
34: qbr2b23c51f-02: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500
qdisc noqueue state UP
35: qvo2b23c51f-02: BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP mtu
1500 qdisc pfifo_fast state UP qlen 1000
36: qvb2b23c51f-02: BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP mtu
1500 qdisc pfifo_fast master qbr2b23c51f-02 state UP qlen 1000
37: vnet0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc
pfifo_fast master qbr2b23c51f-02 state UNKNOWN qlen 500

And on my network node:

root@knet-cs-gen-01i:~# ip addr show | grep ^[0-9]
1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN
2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc mq state
UP qlen 1000
3: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc mq state
UP qlen 1000
4: eth2: BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP mtu 1500 qdisc
mq state UP qlen 1000
5: eth3: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN qlen
1000
6: br-int: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN
7: br-eth1: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN
8: br-ex: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue
state UNKNOWN
22: phy-br-eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc
pfifo_fast state UP qlen 1000
23: int-br-eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc
pfifo_fast state UP qlen 1000

I gave br-ex an IP and UP'ed it manually.  I assume this is
correct.  By I honestly don't know.

Thanks.




On Fri, Feb 15, 2013 at 6:54 PM, Greg Chavez
greg.cha...@gmail.com mailto:greg.cha...@gmail.com wrote:


Sigh.  So I abandoned RHEL 6.3, rekicked my systems and set up
the scale-ready installation described in these instructions:


https://github.com/mseknibilel/OpenStack-Folsom-Install-guide/blob/master/OpenStack_Folsom_Install_Guide_WebVersion.rst

Basically:

(o) controller node on a mgmt and public net
(o) network node (quantum and openvs) on a mgmt, net-config,
and public net
(o) compute node is on a mgmt and net-config net

Took me just over an hour and ran into only a few easily-fixed
speed bumps.  But the VM networks are totally non-functioning.
 VMs launch but no network traffic can go in or out.

I'm particularly befuddled by these 

Re: [Openstack] [Quantum/OVS] Br-int not responsive after network node reboot

[Gary Kotton]

On 02/19/2013 01:57 PM, Sylvain Bauza wrote:

Hi,

I progressed in investigating the bug. I forgot to mention I was 
following Provided Router/single tenancy setup.

So, at reboot, my tap/qg/qr network interfaces were down :
7: qg-c39e5df4-7f: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN
link/ether fe:10:8c:d8:d8:ca brd ff:ff:ff:ff:ff:ff
inet 192.168.10.1/16 brd 192.168.255.255 scope global qg-c39e5df4-7f
inet 192.168.10.2/32 brd 192.168.10.2 scope global qg-c39e5df4-7f
8: qr-f76e4668-fa: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN
link/ether 52:93:35:8b:11:ff brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 brd 10.0.0.255 scope global qr-f76e4668-fa
9: tap2ed3cd8a-03: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN
link/ether 0e:3e:e0:61:5e:b0 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.2/24 brd 10.0.0.255 scope global tap2ed3cd8a-03

So, a short 'ip link set dev up' for the three above fixed my issue. 
Other terms, GRE tunneling is fine at reboot, only interface status is 
wrong.
Do you have any idea how to fix it ? I can't issue a 'post-up' 
statement in /etc/network/interfaces and /etc/rc.local is quite a ugly 
patch I think.


The problem is as follows:
When you reboot the host the openvswitch will create the interfaces on 
restart. this causes problems with the dhcp and the l3 agents.
the solution to this is to run the quantum-ovs-cleanup utility on reboot 
prior to the dhcp and the l3 agents.


thanks
Gary



Thanks,
-Sylvain



Le 18/02/2013 18:06, Sylvain Bauza a écrit :

Hi,

I'll try to be clear. I do follow a classic setup for Quantum with 2 
NICs and a GRE tunnel in between nodes with br-int/br-tun.


Everything is fine at first install, but when rebooting the network 
node (including quantum-ovs-plugin-agent, quantum-l3-agent and 
quantum-dhcp-agent), I notice that DHCP assignation is failing for my 
VMs.
A tcpdump shows at physical level that GRE packets are arriving on 
eth0 (mgmt NIC) on network node (for DHCP request) but no reply is 
done by the network node.


The workaround I found is to delete br-int and br-tun on network 
node, create only br-int and restart both services 
(quantum-{ovs-plugin,l3,dhcp} ) to get things done.


This is quite brutal. Do you know if it's a known bug, or something 
bad with my setup ?


Thanks,
-Sylvain



___
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] [Quantum/OVS] Br-int not responsive after network node reboot

[Gary Kotton]

On 02/19/2013 03:47 PM, Sylvain Bauza wrote:

Le 19/02/2013 13:31, Gary Kotton a écrit :

On 02/19/2013 01:57 PM, Sylvain Bauza wrote:

Hi,

I progressed in investigating the bug. I forgot to mention I was 
following Provided Router/single tenancy setup.

So, at reboot, my tap/qg/qr network interfaces were down :
7: qg-c39e5df4-7f: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN
link/ether fe:10:8c:d8:d8:ca brd ff:ff:ff:ff:ff:ff
inet 192.168.10.1/16 brd 192.168.255.255 scope global 
qg-c39e5df4-7f

inet 192.168.10.2/32 brd 192.168.10.2 scope global qg-c39e5df4-7f
8: qr-f76e4668-fa: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN
link/ether 52:93:35:8b:11:ff brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 brd 10.0.0.255 scope global qr-f76e4668-fa
9: tap2ed3cd8a-03: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN
link/ether 0e:3e:e0:61:5e:b0 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.2/24 brd 10.0.0.255 scope global tap2ed3cd8a-03

So, a short 'ip link set dev up' for the three above fixed my 
issue. Other terms, GRE tunneling is fine at reboot, only interface 
status is wrong.
Do you have any idea how to fix it ? I can't issue a 'post-up' 
statement in /etc/network/interfaces and /etc/rc.local is quite a 
ugly patch I think.


The problem is as follows:
When you reboot the host the openvswitch will create the interfaces 
on restart. this causes problems with the dhcp and the l3 agents.
the solution to this is to run the quantum-ovs-cleanup utility on 
reboot prior to the dhcp and the l3 agents.


thanks
Gary




Thanks, got the bug# : https://bugs.launchpad.net/quantum/+bug/1091605
As the fix is released in 2012.2.3, I have to patch manually or keep 
my method (pref.) of deleting/creating bridges (as only Quantum is 
using these bridges).


I am not sure. I know that in Fedora and in RHEL we ensure that the 
utility is run on boot (if the plugin os openvswitch). Not sure if the 
Ubuntu/Debian packagers have done the same. It is worthwhile notifying 
them about this. I think that Dan may know the relevant people (I do not 
know their names off hand)


Thanks
Gary



Thanks for the quick answer.
-Sylvain



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

Re: [Openstack] openstack brctl addbr not supported on RHEL 6.3

[Gary Kotton]

On 02/11/2013 06:58 PM, Pádraig Brady wrote:

A quick search suggests that kernel has CONFIG_BRIDGE=n set.
So I presume there another method is possible through config.
Gary any ideas?


Please look at https://bugzilla.redhat.com/show_bug.cgi?id=877704. For 
some reason the the bridge module is not loaded. I hope that if you 
follow what is listed in the bug then it will all work and the 
experience will improve.


Thanks
Gary



On 02/11/2013 04:33 PM, Greg Chavez wrote:


Running latest EPEL Folsom packages on RHEL 6.3.  Three nodes right 
now, one controller, one network node, one compute node.  The network 
node has three NICs, one for external net, one for management net, 
one for VM network traffic.  It has been a miserable journey so far.


The lastest calamity began with a failed spawn of the Cirros test 
image.  I booted it like this:


# nova --os-username demo --os-password demo --os-tenant-name 
demoProject boot --image aefa581f-47b0-4d46-8dbc-1a1f7f02dfa0 
--flavor 2  --nic net-id=3de1e780-07d1-42af-89cc-0feaf1ece6e9 server-01


This succeeded but went directly into an ERROR state.  The compute 
node's /var/log/nova/compute.log showed this:


ProcessExecutionError: Unexpected error while running command.
Command: sudo nova-rootwrap /etc/nova/rootwrap.conf brctl addbr 
qbr2218b8c4-7d

Exit code: 1
Stdout: ''
Stderr: 'add bridge failed: Package not installed\n'

Hrm.  So then I ran this:

# brctl show
bridge namebridge idSTP enabledinterfaces
br-eth1/sys/class/net/br-eth1/bridge: No such file or directory
/sys/class/net/br-eth1/bridge: No such file or directory
/sys/class/net/br-eth1/bridge: No such file or directory
/sys/class/net/br-eth1/bridge: No such file or directory
/sys/class/net/br-eth1/bridge: No such file or directory
/sys/class/net/br-eth1/bridge: No such file or directory
/sys/class/net/br-eth1/bridge: No such file or directory
/sys/class/net/br-eth1/bridge: No such file or directory
/sys/class/net/br-eth1/bridge: No such file or directory
/sys/class/net/br-eth1/bridge: No such file or directory
/sys/class/net/br-eth1/bridge: No such file or directory
/sys/class/net/br-eth1/bridge: No such file or directory
.bc305befedd1no
br-int/sys/class/net/br-int/bridge: No such file or directory
/sys/class/net/br-int/bridge: No such file or directory
/sys/class/net/br-int/bridge: No such file or directory
/sys/class/net/br-int/bridge: No such file or directory
/sys/class/net/br-int/bridge: No such file or directory
/sys/class/net/br-int/bridge: No such file or directory
/sys/class/net/br-int/bridge: No such file or directory
/sys/class/net/br-int/bridge: No such file or directory
/sys/class/net/br-int/bridge: No such file or directory
/sys/class/net/br-int/bridge: No such file or directory
/sys/class/net/br-int/bridge: No such file or directory
/sys/class/net/br-int/bridge: No such file or directory
.7e1636f42c4bno

GAH!   What!!! First of all, bridge capability is set by default in 
the RHEL 6.3 kernel.  Secondly, nova knows that it's supposed to be 
using openvswitch.  The ProcessExecutionError's trace showed that the 
offending code came from 
/usr/lib/python2.6/site-packages/nova/virt/libvirt/vif.py line 216 
which has this comment:


 def plug(self, instance, vif):
 Plug using hybrid strategy

 Create a per-VIF linux bridge, then link that bridge to the OVS
 integration bridge via a veth device, setting up the other end
 of the veth device just like a normal OVS port.  Then boot the
 VIF on the linux bridge using standard libvirt mechanisms
 

Thirdly, ovs-vsctrl is happy:

# ovs-vsctl show
44435595-8cc8-469c-ace4-ded76a7b864d
 Bridge br-eth1
 Port br-eth1
 Interface br-eth1
 type: internal
 Port phy-br-eth1
 Interface phy-br-eth1
 Port eth1
 Interface eth1
 Bridge br-int
 Port int-br-eth1
 Interface int-br-eth1
 Port br-int
 Interface br-int
 type: internal
 ovs_version: 1.7.3

Final note, my network node fails the same way, but the controller 
does not.


I hope so much that somebody knows what is going on here.  This is 
very terrible for me as I am struggling to achieve minimal 
functionality.  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] brctl meltdown on RHEL 6.3

[Gary Kotton]

On 02/11/2013 07:26 PM, Greg Chavez wrote:

Solution:

[root@kvm-cs-sn-10i nova]# modprobe -r brcompat
[root@kvm-cs-sn-10i nova]# modprobe bridge
[root@kvm-cs-sn-10i nova]# brctl show
bridge namebridge idSTP enabledinterfaces

Still can't boot a VM... looking into the reasons now.


Could this be related to SELinux. Can you please look at the 
nova-compute logfile - /var/log/nova/compute.log.

Thanks
Gary




On Mon, Feb 11, 2013 at 11:33 AM, Greg Chavez greg.cha...@gmail.com 
mailto:greg.cha...@gmail.com wrote:



Running latest EPEL Folsom packages on RHEL 6.3.  Three nodes
right now, one controller, one network node, one compute node.
 The network node has three NICs, one for external net, one for
management net, one for VM network traffic.  It has been a
miserable journey so far.

The lastest calamity began with a failed spawn of the Cirros test
image.  I booted it like this:

# nova --os-username demo --os-password demo --os-tenant-name
demoProject boot --image aefa581f-47b0-4d46-8dbc-1a1f7f02dfa0
--flavor 2  --nic net-id=3de1e780-07d1-42af-89cc-0feaf1ece6e9
server-01

This succeeded but went directly into an ERROR state.  The compute
node's /var/log/nova/compute.log showed this:

ProcessExecutionError: Unexpected error while running command.
Command: sudo nova-rootwrap /etc/nova/rootwrap.conf brctl addbr
qbr2218b8c4-7d
Exit code: 1
Stdout: ''
Stderr: 'add bridge failed: Package not installed\n'

Hrm.  So then I ran this:

# brctl show
bridge namebridge idSTP enabledinterfaces
br-eth1/sys/class/net/br-eth1/bridge: No such file or directory
/sys/class/net/br-eth1/bridge: No such file or directory
/sys/class/net/br-eth1/bridge: No such file or directory
/sys/class/net/br-eth1/bridge: No such file or directory
/sys/class/net/br-eth1/bridge: No such file or directory
/sys/class/net/br-eth1/bridge: No such file or directory
/sys/class/net/br-eth1/bridge: No such file or directory
/sys/class/net/br-eth1/bridge: No such file or directory
/sys/class/net/br-eth1/bridge: No such file or directory
/sys/class/net/br-eth1/bridge: No such file or directory
/sys/class/net/br-eth1/bridge: No such file or directory
/sys/class/net/br-eth1/bridge: No such file or directory
.bc305befedd1no
br-int/sys/class/net/br-int/bridge: No such file or directory
/sys/class/net/br-int/bridge: No such file or directory
/sys/class/net/br-int/bridge: No such file or directory
/sys/class/net/br-int/bridge: No such file or directory
/sys/class/net/br-int/bridge: No such file or directory
/sys/class/net/br-int/bridge: No such file or directory
/sys/class/net/br-int/bridge: No such file or directory
/sys/class/net/br-int/bridge: No such file or directory
/sys/class/net/br-int/bridge: No such file or directory
/sys/class/net/br-int/bridge: No such file or directory
/sys/class/net/br-int/bridge: No such file or directory
/sys/class/net/br-int/bridge: No such file or directory
.7e1636f42c4bno

GAH!   What!!! First of all, bridge capability is set by default
in the RHEL 6.3 kernel.  Secondly, nova knows that it's supposed
to be using openvswitch.  The ProcessExecutionError's trace showed
that the offending code came
from /usr/lib/python2.6/site-packages/nova/virt/libvirt/vif.py
line 216 which has this comment:

def plug(self, instance, vif):
Plug using hybrid strategy

Create a per-VIF linux bridge, then link that bridge to
the OVS
integration bridge via a veth device, setting up the other end
of the veth device just like a normal OVS port.  Then boot the
VIF on the linux bridge using standard libvirt mechanisms


Thirdly, ovs-vsctrl is happy:

# ovs-vsctl show
44435595-8cc8-469c-ace4-ded76a7b864d
Bridge br-eth1
Port br-eth1
Interface br-eth1
type: internal
Port phy-br-eth1
Interface phy-br-eth1
Port eth1
Interface eth1
Bridge br-int
Port int-br-eth1
Interface int-br-eth1
Port br-int
Interface br-int
type: internal
ovs_version: 1.7.3

Final note, my network node fails the same way, but the controller
does not.

I hope so much that somebody knows what is going on here.  This is
very terrible for me as I am struggling to achieve
minimal functionality.  Thanks.

-- 
\*..+.-

--Greg Chavez
+//..;};




--
\*..+.-
--Greg Chavez
+//..;};


___
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] Reinstating Trey Morris for Nova Core

[Gary Kotton]

+1

On 01/23/2013 05:51 PM, Joe Gordon wrote:

+1

On Wed, Jan 23, 2013 at 7:58 AM, Chris Behrens cbehr...@codestud.com 
mailto:cbehr...@codestud.com wrote:


+1

On Jan 22, 2013, at 5:38 PM, Matt Dietz matt.di...@rackspace.com
mailto:matt.di...@rackspace.com wrote:

 All,

I think Trey Morris has been doing really well on reviews
again, so I'd
 like to propose him to be reinstated for Nova core. Thoughts?

 -Dietz



 ___
 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


___
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] Is the Quantum a network bottleneck

[Gary Kotton]

On 01/23/2013 11:32 AM, Staicu Gabriel wrote:

These are great news Gary.
Do you happen to know if the patch will be also available for folsom?


I think that we will have to wait and see. I do not think that the 
chances are great as it is a major change and could cause instability in 
the stable version.




Thanks,
Gabriel


*From:* Gary Kotton gkot...@redhat.com
*To:* jian@canonical.com
*Cc:* openstack@lists.launchpad.net
*Sent:* Wednesday, January 23, 2013 10:08 AM
*Subject:* Re: [Openstack] Is the Quantum a network bottleneck

On 01/22/2013 07:02 PM, Jian Wen wrote:

On 2013年01月22日 10:56, Balamurugan V G wrote:

Hi,

In an Openstack deployment using Quantum, the compute nodes access 
the public/external network via the network node (as per the diagram 
http://docs.openstack.org/trunk/openstack-network/admin/content/connectivity.html).


So if I have a hundred compute nodes each running hundred instances, 
wouldn't the link to the network node choke? Also wouldnt the 
network node's resources be a bottleneck?


Regards,
Balu


___
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

 Quantum Multi-host DHCP and L3
https://blueprints.launchpad.net/quantum/+spec/quantum-multihost


Yes. At the moment the network node is the bottleneck. There is a 
patch upstream in review that will solve this issue:

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

Hopefully this will be ready in the Grizzly cycle.

In addition to this it also provides HA for the L3 and DHCP agents.
Thanks
Gary



--
Jian Wen


___
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

Re: [Openstack] Is the Quantum a network bottleneck

[Gary Kotton]

On 01/22/2013 07:02 PM, Jian Wen wrote:

On 2013?01?22? 10:56, Balamurugan V G wrote:

Hi,

In an Openstack deployment using Quantum, the compute nodes access 
the public/external network via the network node (as per the diagram 
http://docs.openstack.org/trunk/openstack-network/admin/content/connectivity.html).


So if I have a hundred compute nodes each running hundred instances, 
wouldn't the link to the network node choke? Also wouldnt the network 
node's resources be a bottleneck?


Regards,
Balu


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

 Quantum Multi-host DHCP and L3
https://blueprints.launchpad.net/quantum/+spec/quantum-multihost


Yes. At the moment the network node is the bottleneck. There is a patch 
upstream in review that will solve this issue:

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

Hopefully this will be ready in the Grizzly cycle.

In addition to this it also provides HA for the L3 and DHCP agents.
Thanks
Gary



--
Jian Wen


___
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] Folsom with Quantum on RHEL6.3

[Gary Kotton]

On 01/24/2013 12:02 AM, mohammad kashif wrote:


Hi

I have a running Essex OpenStack cluster on Ubuntu with multi host 
network set up. Floating IP etc is working. I am planning to install  
same kind  of setup with  Folsom on RHEL 6.3 and quantum. I have some 
questions


Most of the documents are mentioning quantum server with other nova 
services and a separate network server running dhcp agent and L2/L3 
agents. Considering that I have a decent server, is it OK to merge all 
the services except compute node on same machine?


There are a number of different deployment options. The ideal setup 
would be something like:

http://docs.openstack.org/trunk/openstack-network/admin/content/connectivity.html



If I want to support floating IP, do I have to install L3 agent on 
controller/network node?


I would suggest having this on a network node. At the moment there is 
not support to run multiple L3 agents on compute nodes. We are currently 
working on a solution for this. Please note that there is no multi host 
support for Quantum at the moment.


Is it necessary to have a separate data and management network ? I am 
not expecting a lot of data crossing the network initially.


This is totally up to you. I would suggest having two different networks.



I am planning to use RHEL6.3, any thought about it.


RHEL6.3 could be supported by EPEL or through the preview at 
redhat.com/openstack




Thanks for any help.

Cheers
Kashif



___
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] Instance doesn't get an IP (Folsom / Quantum)

[Gary Kotton]

Hi,
In order to be able to help can you please provide the following 
information:
1. Which plugin are you using? I assume that it is OpenvSwitch from the 
link :)

2. Are all of the Quantum services running:
- quantum-server
- quantum-openvswitch-agent
- quantum-dhcp-agent
3. Can you please check if there are any messages in quantum log files?
4. Can you also please provide the ovs-vsctl show results (this shows 
the tap device attached to the ovs)

Thanks
Gary

On 01/03/2013 10:26 AM, Martinx - ? wrote:

Hello!

 I'm following this guide: 
http://docs.openstack.org/folsom/basic-install/content/basic-install_intro.html


 And I'm getting this from my Instance Log:

--
cloud-init start-local running: Thu, 03 Jan 2013 04:20:52 +. up 
8.53 seconds


no instance data found in start-local

cloud-init-nonet waiting 120 seconds for a network device.

cloud-init-nonet gave up waiting for a network device.

ci-info: lo : 1 127.0.0.1 255.0.0.0 .

ci-info: eth0 : 1 . . fa:16:3e:83:06:4f

route_info failed

Waiting for network configuration...

Waiting up to 60 more seconds for network configuration...

Booting system without full network configuration...
--

 I already tried this guide more than 10 times, always from scratch 
and everytime I hit this problem.


 I'm using Ubuntu 12.04 with Ubuntu Cloud Archives enabled.

 What can I do?

Thanks!
Thiago


___
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] Instance doesn't get an IP (Folsom / Quantum)

[Gary Kotton]

On 01/03/2013 10:57 AM, Martinx - ジェームズ wrote:

Hi Gary!

 Thank you for your fast answer!

 1. The plugin described on that guide;

 2.
   quantum-server running on folsom-controller;
   quantum-plugin-openvswitch / quantum-plugin-openvswitch-agent 
installed and/or running within the three nodes;

   quantum-dhcp-agent running on folsom-network;
   quantum-l3-agent running on folsom-network.

 3. Can't find any errors on quantum log files, debug enabled on all 
nodes. What kind of message can I look for?


 4. ovs-vsctl show output (no Instance running right now):


Can you please look at http://wiki.openstack.org/ConfigureOpenvswitch. 
From what I see below in the ovs output is that it does not look like 
you have connected the interfaces to the bridge.

Is the tunneling enabled on purpose?

Thanks
Gary


---
root@folsom-controller:~# ovs-vsctl show
218d7774-104c-4d2d-ae9e-9a8dd9ca2450
Bridge br-tun
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port br-tun
Interface br-tun
type: internal
ovs_version: 1.4.0+build0


root@folsom-network:~# ovs-vsctl show
b8b94a53-3294-44ba-855e-002af8fa80ba
Bridge br-tun
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port gre-2
Interface gre-2
type: gre
options: {in_key=flow, out_key=flow, remote_ip=10.0.0.2}
Port br-tun
Interface br-tun
type: internal
Bridge br-ex
Port eth2
Interface eth2
Port br-ex
Interface br-ex
type: internal
Port qg-168da5ed-dd
Interface qg-168da5ed-dd
type: internal
Bridge br-int
Port tapa0f18fc7-bc
tag: 1
Interface tapa0f18fc7-bc
type: internal
Port br-int
Interface br-int
type: internal
Port qr-a8d8fda3-d7
tag: 1
Interface qr-a8d8fda3-d7
type: internal
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
ovs_version: 1.4.0+build0


root@folsom-compute:~# ovs-vsctl show
86ff13f6-960d-48c5-8e03-e8d688364dd0
Bridge br-tun
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port gre-1
Interface gre-1
type: gre
options: {in_key=flow, out_key=flow, 
remote_ip=10.10.10.1}

Port br-tun
Interface br-tun
type: internal
Bridge br-int
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Port br-int
Interface br-int
type: internal
ovs_version: 1.4.0+build0
---

 I followed that guide word by word. With a few changes (because I 
found errors and missing informations on that guide) between the 
tries... Always with the same result.


 BTW, I made a lots of comments on that guide webpage (I am Thiago 
Martins)...


Thank you!
Thiago

On 3 January 2013 06:38, Gary Kotton gkot...@redhat.com 
mailto:gkot...@redhat.com wrote:


Hi,
In order to be able to help can you please provide the following
information:
1. Which plugin are you using? I assume that it is OpenvSwitch
from the link :)
2. Are all of the Quantum services running:
- quantum-server
- quantum-openvswitch-agent
- quantum-dhcp-agent
3. Can you please check if there are any messages in quantum log
files?
4. Can you also please provide the ovs-vsctl show results (this
shows the tap device attached to the ovs)
Thanks
Gary


On 01/03/2013 10:26 AM, Martinx - ジェームズ wrote:

Hello!

 I'm following this guide:

http://docs.openstack.org/folsom/basic-install/content/basic-install_intro.html

 And I'm getting this from my Instance Log:

--
cloud-init start-local running: Thu, 03 Jan 2013 04:20:52 +.
up 8.53 seconds

no instance data found in start-local

cloud-init-nonet waiting 120 seconds for a network device.

cloud-init-nonet gave up waiting for a network device.

ci-info: lo : 1 127.0.0.1 255.0.0.0 .

ci-info: eth0 : 1 . . fa:16:3e:83:06:4f

route_info failed

Waiting for network configuration...

Waiting up to 60 more seconds for network configuration...

Booting system without full network configuration...
--

 I already tried this guide more than 10 times, always from
scratch and everytime I hit this problem.

 I'm using Ubuntu 12.04 with Ubuntu Cloud Archives enabled.

 What can I do?

Thanks!
Thiago

Re: [Openstack] Cannot reach external IPs

[Gary Kotton]

On 12/29/2012 06:16 AM, Dennis Jacobfeuerborn wrote:

Hi,
I've successfully setup a single machine openstack environment including
quantum with a provider router configuration (openvswitch). The Problem is
that I cannot reach the internet from the VMs.

The reason apparently is that the default quantum network type is local
which doesn't allow that. I tried switching this to flat but when I try
to create a provider network for the tenant I get:

[dennis@localhost ~]$ quantum net-create --tenant-id
fcd3e4ddcf264bd39bce043bea12aaf0 net1 --provider:network_type flat
--provider:physical_network physnet1

Invalid input for operation: unknown provider:physical_network physnet1.


Can you please take a look at http://wiki.openstack.org/ConfigureOpenvswitch
Thanks
Gary


In the ovs plugin ini I put bridge_mappings = physnet1:br-ex and the
br-ex bridge exists and has the physical port as a member.

According to this documentation a network type of flat should be possible?
http://docs.openstack.org/folsom/openstack-network/admin/content/provider_attributes.html

Regards,
   Dennis

___
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] bug of quantum-server

[Gary Kotton]

Hi,
Thanks for looking into this.
I'll file a bug and fix.
Thank you
Gary

On 12/17/2012 10:38 AM, Liu Wenmao wrote:

the local vairable *physical_network* should be *alloc.physical_network*

I suggest to add some error output to the logger

root@controller:~# quantum-server --config-file 
/etc/quantum/quantum.conf --log-file /var/log/quantum/server.log 
--config-file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini 
--config-file /etc/quantum/plugins/restproxy/restproxy.ini

Traceback (most recent call last):
  File /usr/bin/quantum-server, line 26, in module
server()
  File /usr/lib/python2.7/dist-packages/quantum/server/__init__.py, 
line 40, in main

quantum_service = service.serve_wsgi(service.QuantumApiService)
  File /usr/lib/python2.7/dist-packages/quantum/service.py, line 83, 
in serve_wsgi

service.start()
  File /usr/lib/python2.7/dist-packages/quantum/service.py, line 42, 
in start

self.wsgi_app = _run_wsgi(self.app_name)
  File /usr/lib/python2.7/dist-packages/quantum/service.py, line 89, 
in _run_wsgi

app = config.load_paste_app(app_name)
  File /usr/lib/python2.7/dist-packages/quantum/common/config.py, 
line 133, in load_paste_app

app = deploy.loadapp(config:%s % config_path, name=app_name)
  File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, 
line 247, in loadapp

return loadobj(APP, uri, name=name, **kw)
  File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, 
line 272, in loadobj

return context.create()
  File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, 
line 710, in create

return self.object_type.invoke(self)
  File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, 
line 144, in invoke

**context.local_conf)
  File /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 
56, in fix_call

val = callable(*args, **kw)
  File /usr/lib/python2.7/dist-packages/paste/urlmap.py, line 25, in 
urlmap_factory

app = loader.get_app(app_name, global_conf=global_conf)
  File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, 
line 350, in get_app

name=name, global_conf=global_conf).create()
  File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, 
line 710, in create

return self.object_type.invoke(self)
  File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, 
line 144, in invoke

**context.local_conf)
  File /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 
56, in fix_call

val = callable(*args, **kw)
  File /usr/lib/python2.7/dist-packages/quantum/auth.py, line 61, in 
pipeline_factory

app = loader.get_app(pipeline[-1])
  File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, 
line 350, in get_app

name=name, global_conf=global_conf).create()
  File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, 
line 710, in create

return self.object_type.invoke(self)
  File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, 
line 146, in invoke
return fix_call(context.object, context.global_conf, 
**context.local_conf)
  File /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 
56, in fix_call

val = callable(*args, **kw)
  File /usr/lib/python2.7/dist-packages/quantum/api/v2/router.py, 
line 67, in factory

return cls(**local_config)
  File /usr/lib/python2.7/dist-packages/quantum/api/v2/router.py, 
line 71, in __init__

plugin = manager.QuantumManager.get_plugin()
  File /usr/lib/python2.7/dist-packages/quantum/manager.py, line 65, 
in get_plugin

cls._instance = cls()
  File /usr/lib/python2.7/dist-packages/quantum/manager.py, line 60, 
in __init__

self.plugin = plugin_klass()
  File 
/usr/lib/python2.7/dist-packages/quantum/plugins/openvswitch/ovs_quantum_plugin.py, 
line 197, in __init__

ovs_db_v2.sync_vlan_allocations(self.network_vlan_ranges)
  File 
/usr/lib/python2.7/dist-packages/quantum/plugins/openvswitch/ovs_db_v2.py, 
line 112, in sync_vlan_allocations

(alloc.vlan_id, physical_network))
UnboundLocalError: local variable 'physical_network' referenced before 
assignment


___
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] instance cannot access external network (folsom quantum)

[Gary Kotton]

On 12/13/2012 12:07 PM, ZhiQiang Fan wrote:

i can ping and ssh into instance with private ip and floating ip
instance can ping the control node ip, but cannot ping the compute 
node and any external network


In order to be able to help would it be possible that you provide IP 
addresses and maybe a bit of understanding about your topology.


Basically is there a route from the VM ip address to the IP address of 
the compute node?


In addition to this can you please let us know which plugin you are using?

Thanks
Gary


i have installed quantum in the control node host, and it only got 1 
nic (same as compute node), and use eth0:0 and eth0:1 to vitualize 2 
other nic (eth0:0 on compute node)


i use tcpdump on control node and compute node to monitor package from 
instance, actually compute node will reply the icmp package but with 
destination of instance private ip, since compute node has no route to 
that network, it failed and no package receive on control node nic. 
but when i add route via control node, it can reply to insance as expected
then i use tcpdump on control node and instance to monitor package to 
the floating ip, instance got nothing but control node captured the 
package and reply it instead of instance


so i think the problem may be that the control node will not modify 
the source ip when forwad the icmp package, more exactly, the nat 
functionality is not enabled?


and i try some other command such as iptables -t nat -A POSTROUTING 
-o eth0 -j MASQUERADE but it is not working


i'll paste some output if anyone needs
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

Re: [Openstack] multi-host mode in quantum

[Gary Kotton]

On 12/12/2012 05:58 PM, Xin Zhao wrote:

Hello,

If I understand it correctly, multi-host network mode is not supported 
(yet) in quantum in Folsom.
I wonder what's the recommended way of running multiple network nodes 
(for load balancing and
bandwidth concerns) in quantum?  Any documentation links will be 
appreciated.


At the moment this is in discussion upstream. It is currently not 
supported but we are hoping to have support for this in grizzly.


Thanks,
Xin



___
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] Understanding the Folsom-Quantum

[Gary Kotton]

On 12/11/2012 09:50 AM, Trinath Somanchi wrote:

Hi-

I have the following first set of doubts regarding the Folsom Quantum

[1] With regard of Quantum Plug-in, How does the RPC communication 
take place between the Agent and the plug-n ? In the source code, 
ovs_quantum_plugin.py, I find the setup_rpc method and AgentRPCAPI 
class what does the reverse RPC tasks. Can any one guide me on 
understanding this.


When the OVS detects that a new interface has been added it will query 
the plugin for the interface details. This will enable it to create the 
relevant networking for the specific interface, for example tags etc. 
The agent requests information from the plugin when it detects that 
there is a new resources.
In addition to this there are cases when the plugin will notify the 
agent - for example if the admin status of a port has changed.




[2] What is the significance of the file quantum/db/dhcp_rpc_base.py? 
Many plugins in the quantum/plugins directory use the methods in the 
class.


This enables the DHCP agent to request information from the plugin.



[3] With core_plugin configuration being in place, can we have some 
other plugin too existing in Quantum? Can any one guide me on how to 
achieve the same, like a Fake plugin?


In V2 there is no fake plugin. There are a number of different plugins 
that make sue of the base DB plugin - for example the linuxbridge, 
openvswitch, NEC, RYU etc.




[4] Why OVS quantum Plug-in doesn't support create/update/delete of 
port and subnets?


The OVS plugin inherits the base plugin. If it does not need to make any 
additions then it will use the base methods implementation. If you look 
at https://review.openstack.org/#/c/16210/ you will see that in some 
cases changes need to be made - for example extending the ports to 
support security groups.





Kindly help me understand these ...


It is all pretty complicated. My suggestion would be to get a evstack 
installation up and running and playing around with the configurations 
and the agents. Once you start to understand how all of the components 
interact it will be easier to follow.




Thanks in advance



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



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


___
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] [Quantum] Quantum OVS Plugin doubt

[Gary Kotton]

On 12/11/2012 06:56 AM, Trinath Somanchi wrote:

Hi-

Thanks for the reply Gary..

But with respect to the Quantum_plugin_base_v2.py code, which is the 
base class for the plugins, We can see the create/update/delete 
network methods only in the quantum plugin. But then How about 
create/update/delete ports and subnet  methods. These methods do 
exists in the ryu/nec/nicira plugins.


The OVS inherits the base plugin:

class OVSQuantumPluginV2(db_base_plugin_v2.QuantumDbPluginV2,
 l3_db.L3_NAT_db_mixin):

This means that if it does not need to make changes to the methods then 
the base classes methods will be invoked.

Thanks
Gary



Will ovs plugin will not consider the implementation of port and 
subnet? If it considers, where these are happening?


Kindly help me understand the same.

Thanks in advance

-
Trinath


On Sun, Dec 9, 2012 at 5:19 PM, Gary Kotton gkot...@redhat.com 
mailto:gkot...@redhat.com wrote:


Hi Trina,
I am not really sure that I understand your question. The Quantum
service marshals the API's to a plugin. The plugin is responsible
for providing the virtual network service. In the case of the OVS
plugin the ovs_quantum_plugin.py will treat the API calls. That
means that it will enable the user to perform CRUD operations on
the following: networks, subnets and ports. In order to do this it
stores the values in a persistent database.
The plugin has a layer 2 agent that performs the actual network
configuration.
Hope that this help.
Thanks
Gary


On 12/07/2012 09:10 AM, Trinath Somanchi wrote:

Hi Stackers-

I have a doubt with respect to the Quantum OVS Plugin.

[1] Do all the APIs of Quantum use the Quantum OVS plugin to get
the data from the database. or they directly contact the database.

Since, I have seen ovs_quantum_plugin.py code, it has
create_network, update_network methods which use the db api.

Is that the OVS Quantum Plugin APIs are partially used by the
Quantum APIs for getting data from database?

Kindly help me understand these areas of Quantum.

Thanks in advance

-- 
Regards,

--
Trinath Somanchi,
+91 9866 235 130 tel:%2B91%209866%20235%20130



___
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




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



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

Re: [Openstack] Understanding the Folsom-Quantum

[Gary Kotton]

On 12/11/2012 11:38 AM, Trinath Somanchi wrote:

Hi-

Thanks for the reply. I still have some more doubts ... please find 
then inline.


Kindly help me understand these...


On Tue, Dec 11, 2012 at 2:59 PM, Gary Kotton gkot...@redhat.com 
mailto:gkot...@redhat.com wrote:


On 12/11/2012 09:50 AM, Trinath Somanchi wrote:

Hi-

I have the following first set of doubts regarding the Folsom Quantum

[1] With regard of Quantum Plug-in, How does the RPC
communication take place between the Agent and the plug-n ? In
the source code, ovs_quantum_plugin.py, I find the setup_rpc
method and AgentRPCAPI class what does the reverse RPC tasks. Can
any one guide me on understanding this.


When the OVS detects that a new interface has been added it will
query the plugin for the interface details. This will enable it to
create the relevant networking for the specific interface, for
example tags etc. The agent requests information from the plugin
when it detects that there is a new resources.
In addition to this there are cases when the plugin will notify
the agent - for example if the admin status of a port has changed.




[2] What is the significance of the file
quantum/db/dhcp_rpc_base.py? Many plugins in the quantum/plugins
directory use the methods in the class.


This enables the DHCP agent to request information from the plugin.

Trinath But then dhcp-agent has to use this api. But why the plugins 
are using this api? I see in the source code that, ryu, nec and ovs 
plugins use this dhcp_rpc_base for redirected processing of data.


The DHCP agent makes use of RPC call to access the information. The 
plugin needs to treat these calls. Each plugin is responsible for the 
persistent data hence the code that you have mentioned.







[3] With core_plugin configuration being in place, can we have
some other plugin too existing in Quantum? Can any one guide me
on how to achieve the same, like a Fake plugin?


In V2 there is no fake plugin. There are a number of different
plugins that make sue of the base DB plugin - for example the
linuxbridge, openvswitch, NEC, RYU etc.




[4] Why OVS quantum Plug-in doesn't support create/update/delete
of port and subnets?


The OVS plugin inherits the base plugin. If it does not need to
make any additions then it will use the base methods
implementation. If you look at
https://review.openstack.org/#/c/16210/ you will see that in some
cases changes need to be made - for example extending the ports to
support security groups.





Kindly help me understand these ...


It is all pretty complicated. My suggestion would be to get a
evstack installation up and running and playing around with the
configurations and the agents. Once you start to understand how
all of the components interact it will be easier to follow.



Thanks in advance



-- 
Regards,

--
Trinath Somanchi,
+91 9866 235 130 tel:%2B91%209866%20235%20130



___
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




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



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

Re: [Openstack] [Quantum] Quantum OVS Plugin doubt

[Gary Kotton]

Hi Trina,
I am not really sure that I understand your question. The Quantum 
service marshals the API's to a plugin. The plugin is responsible for 
providing the virtual network service. In the case of the OVS plugin the 
ovs_quantum_plugin.py will treat the API calls. That means that it will 
enable the user to perform CRUD operations on the following: networks, 
subnets and ports. In order to do this it stores the values in a 
persistent database.
The plugin has a layer 2 agent that performs the actual network 
configuration.

Hope that this help.
Thanks
Gary

On 12/07/2012 09:10 AM, Trinath Somanchi wrote:

Hi Stackers-

I have a doubt with respect to the Quantum OVS Plugin.

[1] Do all the APIs of Quantum use the Quantum OVS plugin to get the 
data from the database. or they directly contact the database.


Since, I have seen ovs_quantum_plugin.py code, it has create_network, 
update_network methods which use the db api.


Is that the OVS Quantum Plugin APIs are partially used by the Quantum 
APIs for getting data from database?


Kindly help me understand these areas of Quantum.

Thanks in advance

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



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


___
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 ipv6 floating ip's?

[Gary Kotton]

On 11/25/2012 07:24 PM, Lance Haig wrote:

Hi,

I want to build an OpenStack all in one server with devstack or by 
hand I don't mind.


I want to host some VM's with persistant storage and some without.

I also can only get ipv6 /64 address range for my server so need to 
know if OpenStack supports that.


This is planned for Grizzly in Quantum 
(https://blueprints.launchpad.net/quantum/+spec/ipv6-feature-parity)


It has been a long time since I did my class at RackSpace in the UK 
and so my memory is rusty.


I would appreciate any help.

Thanks

Lance

___
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] Quantum can not auto assign floating ip to vm

[Gary Kotton]

On 11/23/2012 05:15 PM, Jian Hua Geng wrote:


Hi,

I am using the Quantum on Folsom release, does it still support auto 
assign floating ip to a vm just list the nova-network did?

If the answer is yes, how to implement it?



Hi,
I am not familiar with the auto assign feature. At the moment the 
assignement of a floating IP is done manually.
Can you please look at 
http://docs.openstack.org/trunk/openstack-network/admin/content/app_demo.html 
for an example on how this is done.


Thanks
Gary



--
Best regard,
David Geng
--


___
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] folsom quantum network issue

[Gary Kotton]

On 11/21/2012 10:28 PM, Paras pradhan wrote:

Hi all

I am following this tutorial
https://github.com/mseknibilel/OpenStack-Folsom-Install-guide/blob/master/OpenStack_Folsom_Install_Guide_WebVersion.rst

When I start the instance, it starts well but it doesnot get the IP
however I can see the ip assigned at Horizon. I am seeing this on
compute node's openvswitch-agent.log

-
Stdout: '{attached-mac=fa:16:3e:95:5f:5d,
iface-id=ac212e78-765f-4364-8aee-4f2b6014f61f, iface-status=active,
vm-uuid=dfba5e8b-d494-420c-bb03-44aeb94bd93d}\n'
Stderr: ''
2012-11-21 14:26:46DEBUG [quantum.agent.linux.utils] Running
command: sudo /usr/bin/quantum-rootwrap /etc/quantum/rootwrap.conf
ovs-vsctl --timeout=2 get Interface qvod71668d6-7d external_ids
2012-11-21 14:26:46DEBUG [quantum.agent.linux.utils]
Command: ['sudo', '/usr/bin/quantum-rootwrap',
'/etc/quantum/rootwrap.conf', 'ovs-vsctl', '--timeout=2', 'get',
'Interface', 'qvod71668d6-7d', 'external_ids']
Exit code: 0
Stdout: '{attached-mac=fa:16:3e:72:c7:c2,
iface-id=d71668d6-7d43-481c-837d-f6d42200c5b9, iface-status=active,
vm-uuid=5ec875b2-be06-456c-ac00-c6eb055280e1}\n'
--

What did i miss here? and where do i start to diagnose the issue?


Can you please check to see if the DHCP agent is running. If so is there 
anything in its log files?


Thanks
Gary


Thanks,
Paras.

___
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] Looking for a good Folsom + Quantum guide

[Gary Kotton]

  
  
Hi,
A considerable effort has been made to close a number of problems in
the Folsom release.
The list of issues addressed can be seen at
https://review.openstack.org/#/q/status:merged+project:openstack/quantum+branch:stable/folsom,n,z
There are still a few bug fixes in review. If I understand correctly
around the 22nd of November there will be a stable release (maybe
give or take a day).
My two cents is to wait a couple of days for the reviews to go
through and the various distributions to build the packages.
If there is a painful issue that you have then please let us know.
Thanks
Gary

On 11/15/2012 05:10 PM, Skible OpenStack wrote:

  
  Are you talking about this l3 bug ?


https://github.com/mseknibilel/OpenStack-Folsom-Install-guide/blob/stable/GRE/Tricks%26Ideas/modify_iptables_manager.rst

Le 15/11/2012 16:06, Razique Mahroua a crit:
  
  

Hi Sam,
here is an official guide to start with
http://docs.openstack.org/trunk/openstack-compute/install/apt/content/ap_installingfolsomubuntuprecise.html
Note that at the moment, the official quantum packages
  contain bugs - I'm thinking about the l3 agent for instance.
Let us know how it's going
Best regards,
Razique

   Nuage
 Co - Razique Mahroua
  razique.mahr...@gmail.com

 
  
  
Le 15 nov. 2012  15:30, Samuel Winchenbach swinc...@gmail.com

  a crit :

Hi All,
  
  
  I am looking for a good guide to help me get started with
  Folsom and
  Quantum for either 12.04 or 12.10.
  
  I have been attempting to use: goo.gl/vIdcr but when I get
  to section
  5 (openvswitch) I get an error (SIOCADDRT: no such
  process) when
  trying to set the interface for the default gateway to the
  bridge
  created in the previous step. I have tried a number of
  different
  things, including installing 12.10 on a virtual machine
  and trying it
  there instead of bare metal. Same outcome.
  
  Doe anyone have any recommendations for a good guide to
  follow? Or
  if you have any suggestions on fixing the above error,
  that would be
  great too!
  
  Thanks,
  Sam
  
  ___
  Mailing list: https://launchpad.net/~openstack
  Post to : openstack@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~openstack
  More help : https://help.launchpad.net/ListHelp

  
  




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

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



  

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

Re: [Openstack] Looking for a good Folsom + Quantum guide

[Gary Kotton]

On 11/15/2012 04:30 PM, Samuel Winchenbach wrote:

Hi All,


I am looking for a good guide to help me get started with Folsom and
Quantum for either 12.04 or 12.10.


Please look at 
http://docs.openstack.org/trunk/openstack-network/admin/content/index.html. 
There is a demo section.


You can see example from the Fedora test day - 
https://fedoraproject.org/wiki/Test_Day:2012-09-18_OpenStack. There is a 
specific Quantum section.


Thanks
Gary


I have been attempting to use: goo.gl/vIdcr but when I get to section
5 (openvswitch) I get an error (SIOCADDRT: no such process) when
trying to set the interface for the default gateway to the bridge
created in the previous step.  I have tried a number of different
things, including installing 12.10 on a virtual machine and trying it
there instead of bare metal.  Same outcome.

Doe anyone have any recommendations for a good guide to follow?   Or
if you have any suggestions on fixing the above error, that would be
great too!

Thanks,
Sam

___
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] Looking for a good Folsom + Quantum guide

[Gary Kotton]

On 11/15/2012 05:22 PM, Skible OpenStack wrote:
Can you please tell me what type of networking are you using ? VLAN or 
GRE ?


In the examples we are using VLAN.



Le 15/11/2012 16:16, Gary Kotton a écrit :

On 11/15/2012 04:30 PM, Samuel Winchenbach wrote:

Hi All,


I am looking for a good guide to help me get started with Folsom and
Quantum for either 12.04 or 12.10.


Please look at 
http://docs.openstack.org/trunk/openstack-network/admin/content/index.html. 
There is a demo section.


You can see example from the Fedora test day - 
https://fedoraproject.org/wiki/Test_Day:2012-09-18_OpenStack. There 
is a specific Quantum section.


Thanks
Gary


I have been attempting to use: goo.gl/vIdcr but when I get to section
5 (openvswitch) I get an error (SIOCADDRT: no such process) when
trying to set the interface for the default gateway to the bridge
created in the previous step.  I have tried a number of different
things, including installing 12.10 on a virtual machine and trying it
there instead of bare metal.  Same outcome.

Doe anyone have any recommendations for a good guide to follow?   Or
if you have any suggestions on fixing the above error, that would be
great too!

Thanks,
Sam

___
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] Looking for a good Folsom + Quantum guide

[Gary Kotton]

  
  
On 11/15/2012 05:17 PM, Skible OpenStack wrote:

  
  I believe that the biggest problem is
not bug fixes, we are able to fix them out by our selves.
Instead, we do need that Dashboard able to communicate with
  the quantum to allocate floating IP 

Does anyone have an idea about the date ?
  


I am not sure if anyone is working on this. You are welome to add
the support. It would be great.

   
Le 15/11/2012 16:14, Gary Kotton a crit:
  
  

Hi,
A considerable effort has been made to close a number of
problems in the Folsom release.
The list of issues addressed can be seen at https://review.openstack.org/#/q/status:merged+project:openstack/quantum+branch:stable/folsom,n,z
There are still a few bug fixes in review. If I understand
correctly around the 22nd of November there will be a stable
release (maybe give or take a day).
My two cents is to wait a couple of days for the reviews to go
through and the various distributions to build the packages.
If there is a painful issue that you have then please let us
know.
Thanks
Gary

On 11/15/2012 05:10 PM, Skible OpenStack wrote:

  
  Are you talking about this l3 bug
?


https://github.com/mseknibilel/OpenStack-Folsom-Install-guide/blob/stable/GRE/Tricks%26Ideas/modify_iptables_manager.rst

Le 15/11/2012 16:06, Razique Mahroua a crit:
  
  

Hi Sam,
here is an official guide to start with
http://docs.openstack.org/trunk/openstack-compute/install/apt/content/ap_installingfolsomubuntuprecise.html
Note that at the moment, the official quantum packages
  contain bugs - I'm thinking about the l3 agent for
  instance.
Let us know how it's going
Best regards,
Razique

   Nuage


 Co - Razique Mahroua
  razique.mahr...@gmail.com

 
  
  
Le 15 nov. 2012  15:30, Samuel Winchenbach swinc...@gmail.com



  a crit :

Hi All,
  
  
  I am looking for a good guide to help me get started
  with Folsom and
  Quantum for either 12.04 or 12.10.
  
  I have been attempting to use: goo.gl/vIdcr but when I
  get to section
  5 (openvswitch) I get an error (SIOCADDRT: no such
  process) when
  trying to set the interface for the default gateway to
  the bridge
  created in the previous step. I have tried a number
  of different
  things, including installing 12.10 on a virtual
  machine and trying it
  there instead of bare metal. Same outcome.
  
  Doe anyone have any recommendations for a good guide
  to follow? Or
  if you have any suggestions on fixing the above error,
  that would be
  great too!
  
  Thanks,
  Sam
  
  ___
  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

  
  


  

___
Mailing list: https://launchpad.net/~openstack
Post

Re: [Openstack] Openstack networking failure after server reboot

[Gary Kotton]

On 11/07/2012 11:47 AM, Aniruddha Khadkikar wrote:

Hi Stackers,

We have a small Openstack lab using three servers. The components are
distributed as:
1. Network controller - Quantum L3  DHCP, L2 agent, Nova, Openvswitch
2. Cloud controller - Quantum server, L2 agent, Nova, Openvswitch,
Dashboard, API, MySQL, Rabbitmq
3. Compute node - Nova, Openvswitch, L2 agent

The network is setup in the following way:
1. Each server has 4 nics. We are using only one public IP and one
private IP for the openstack setup. We have a private switch for
inter-vm communication
2. We are using gre tunnelling and openvswitch
3. br-int is assigned an IP address
4. br-ex is configured for floating IP allocation

Everything works perfectly when we are setting it up from scratch

Each vm is able to get the private IP's assigned and the NAT based
floating IP is also assigned and we are able to SSH into it.
The VM's also get created on all the three hosts.

So we are confident that we have the right configurations in place as
we have fully operational Openstack implementation using gre-tunnels.

In order to test the resilience of the setup, we decided to reboot the
servers to see if everything comes up again. We faced some dependency
of services errors and after server reboot we restarted the services
in the proper order i.e. on cloud controller we have mysql, rabbitmq,
keystone, openvswitch and quantum-server started. This was followed by
starting openvswitch, L3, dhcp and L2 agent. After which we started L2
agents on all the remaining servers and followed by nova. There is
some confusion on how to orchestrate the right order of services. This
could possibly be something we will need to work upon in future.

After this, we have nova working properly i.e. we are able to create
vm's and the pre-existing ones are also started (virsh list also shows
the vm's). ovsctl shows all the interfaces as earlier. However we are
unable to access the vm's. On logging into the vm we do not see any IP
address being assigned as the VM is unable to contact the dhcp server.

The questions that come up are:
* What could change after a reboot that would compromise a running
network configuration?
* Could there be issues with the TAP interfaces created? What is the
best way to troubleshoot such a situation?
* Has anyone seen a similar behaviour and is it specific to when we
use gre-tunnels? Is it then specific to openvswitch which we are
using?
* On reboot of the network controller are any steps required to ensure
that Openstack continues to function properly?


Can you please look in the log files for Quantum and see if there are 
any errors?


There is an open issue with Quantum and QPID after rebooting - the 
Quantum service hangs? On the host for Quantum is you do netstat -an 
|grep 9696 do you see anything?




The setup has failed twice on reboot. For the second iteration we are
assigning the IP on startup to br-int so that openvswitch does not
give errors.

Regards
Aniruddha

___
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] Error in l3_agent

[Gary Kotton]

Hi,
The bug has been fixed upstream and is merged into the stable folsom 
branch. Please note that this may not have been packaged by the various 
linux distributions.
If you need to fix this locally then please look at 
https://github.com/openstack/quantum/commit/84d60f5fd477237bd856b97b9970dd796b10647e 
for the change.

Thanks
Gary

On 11/05/2012 12:11 PM, Atul Jha wrote:

Skible,

Looks to me like a reported bug.

https://bugs.launchpad.net/quantum/+bug/1069966


From: openstack-bounces+atul.jha=csscorp@lists.launchpad.net 
[openstack-bounces+atul.jha=csscorp@lists.launchpad.net] on behalf of 
Skible OpenStack [skible.openst...@gmail.com]
Sent: Monday, November 05, 2012 3:22 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] Error in l3_agent

Hello Stackers !

i am finding a weird error in my l3_agent.log file:



Stderr: ''
2012-11-05 10:22:59ERROR [quantum.agent.l3_agent] Error running
l3_nat daemon_loop
Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/quantum/agent/l3_agent.py,
line 170, in daemon_loop
  self.do_single_loop()
File /usr/lib/python2.7/dist-packages/quantum/agent/l3_agent.py,
line 227, in do_single_loop
  self.process_router(ri)
File /usr/lib/python2.7/dist-packages/quantum/agent/l3_agent.py,
line 300, in process_router
  self.external_gateway_added(ri, ex_gw_port, internal_cidrs)
File /usr/lib/python2.7/dist-packages/quantum/agent/l3_agent.py,
line 398, in external_gateway_added
  ri.iptables_manager.apply()
File
/usr/lib/python2.7/dist-packages/quantum/agent/linux/iptables_manager.py,
line 282, in apply
  root_helper=self.root_helper))
File /usr/lib/python2.7/dist-packages/quantum/agent/linux/utils.py,
line 55, in execute
  raise RuntimeError(m)
RuntimeError:
Command: ['sudo', '/usr/bin/quantum-rootwrap',
'/etc/quantum/rootwrap.conf', '/sbin/iptables-save', '-t', 'filter']
Exit code: 99
Stdout: 'Unauthorized command: /sbin/iptables-save -t filter\n'
Stderr: ''

==

I can't seem to find any documentation about this problem.

Can anyone please shed some light on this ?

Best regards,
Bilel

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp
http://www.csscorp.com/common/email-disclaimer.php

___
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] Distributed configuration database

[Gary Kotton]

It would also be nice if one could change configuration settings at run 
time instead of having to restart a process.


___
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] Distributed configuration database

[Gary Kotton]

On 11/04/2012 04:45 PM, Nah, Zhongyue wrote:

https://blueprints.launchpad.net/nova/+spec/deployer-friendly-confs

This blueprint seems to be planning to implement what is being discussed for 
Nova.


Great.

I assume that this will be done in OpenStack Common so that all of the 
users of the common configuration module can consume and benefit.


Thanks
Gary


-zhongyue

Sent from my iPhone

On Nov 4, 2012, at 3:26 PM, Gary 
Kottongkot...@redhat.commailto:gkot...@redhat.com  wrote:


It would also be nice if one could change configuration settings at run time 
instead of having to restart a process.

___
Mailing list: https://launchpad.net/~openstack
Post to : 
openstack@lists.launchpad.netmailto: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] new mailing list for bare-metal provisioning

[Gary Kotton]

On 10/29/2012 02:59 AM, Asher Newcomer wrote:

+1

On Sun, Oct 28, 2012 at 8:39 PM, Russell Bryant rbry...@redhat.com 
mailto:rbry...@redhat.com wrote:


On 10/28/2012 08:19 PM, David Kang wrote:

  I agree that subject prefix is a way.
 There are pros and cons of either approach.
 However, when I asked a few of the people who showed interest in
bare-metal discussion,
 a new mailing list was preferred by them.
 And we thought a separate mailing list makes people easier to
participate and to manage the discussion.

  We can discuss this issue again among the people who signed up
the new mailing list.

There are quite a few people, like myself, who are interested in *all*
nova development.  Signing up for a new mailing list for every new
development effort would be a nightmare to keep up with.  I *really,
really* think the list should be dropped and all discussions should be
on openstack-dev.



I agree.



--
Russell Bryant

___
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


___
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] MAC address uniqueness in folsom

[Gary Kotton]

On 10/26/2012 03:56 PM, Gurjar, Unmesh wrote:


Hi,

I can think of two alternative  solutions for maintaining uniqueness:

1.DB look up: After generating a new MAC address, checking uniqueness 
by doing  a DB look up.




The Quantum code ensure that the MAC address generated is unqiue. This 
is done by checking against MAC addresses already allocated.


2.Having a 'unique' constraint on the 'mac_address' column and handle 
the DB IntegrityError and retry generating a new MAC address.


I also think, initializing the 'random.seed' in start-up process of 
Quantum server (with a different value -- configurable one; on each 
server) could help in reducing conflicts.


I think either of the above solutions could be used for fixing LP bug 
#1050924.


Thanks  Regards,

*Unmesh Gurjar*| Lead Engineer | NTT DATA Global Technology Services 
Private Limited | *w.* +91.20.6604.1500 x 379 | *m.* +91.982.324.7631 
| unmesh.gur...@nttdata.com mailto:unmesh.gur...@nttdata.com | Learn 
more at nttdata.com/americas**


*From:*openstack-bounces+unmesh.gurjar=nttdata@lists.launchpad.net 
[mailto:openstack-bounces+unmesh.gurjar=nttdata@lists.launchpad.net] 
*On Behalf Of *Neelakantam Gaddam

*Sent:* Friday, October 26, 2012 11:37 AM
*To:* mth...@mthode.org
*Cc:* openstack@lists.launchpad.net
*Subject:* Re: [Openstack] MAC address uniqueness in folsom

Hi,

We want unique MAC addresses in our environment only but across 
multiple tenants.


Thanks for quick reply.

---
Neelakantam

On Fri, Oct 26, 2012 at 9:38 AM, Matthew Thode mth...@mthode.org 
mailto:mth...@mthode.org wrote:


On 10/25/2012 11:02 PM, Neelakantam Gaddam wrote:
 Hi All,

 Does the MAC address generated in quantum is unique across tenants in
 folsom?
 I am developing an application that requires unique MAC address. If not
 unique, is there any way to make MAC address unique?

 Please help me. Thanks in advance.





 ___
 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

Do you need it to be globally unique (amongst all macs on earth) or
simply unique in your environment?

--
-- Matthew Thode


___
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




--
Thanks  Regards
Neelakantam Gaddam


__
Disclaimer:This email and any attachments are sent in strictest 
confidence for the sole use of the addressee and may contain legally 
privileged, confidential, and proprietary data. If you are not the 
intended recipient, please advise the sender by replying promptly to 
this email and then delete and destroy this email and any attachments 
without any further use, copying or forwarding



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


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

Re: [Openstack] How to commucation vms in multi nodes using quantum?

[Gary Kotton]

Hi,
In addition to Dan's comments you can also take a look at the following 
link http://wiki.openstack.org/ConfigureOpenvswitch.

Thanks
Gary

On 10/24/2012 08:21 AM, livemoon wrote:

Thanks Dan

On Wed, Oct 24, 2012 at 2:15 PM, Dan Wendlandt d...@nicira.com 
mailto:d...@nicira.com wrote:


On Tue, Oct 23, 2012 at 10:56 PM, livemoon mwjpi...@gmail.com
mailto:mwjpi...@gmail.com wrote:
 Dan:
 Thank you for your help.
 If the server have three nics, which one will be used as port of
br-int. I
 must know how br-int work between two machines, and then I can
make the
 physical interface which br-int use to one switch

If you are using tunneling, the traffic will exit out the NIC based on
your physical server's routing table and the destination IP of the
tunnel.  For example, if your physical server is tunneling a packet to
a VM on a physical server with IP W.X.Y.Z, the packet will leave
whatever NIC has the route to reach W.X.Y.Z .

Dan





 On Wed, Oct 24, 2012 at 11:52 AM, Dan Wendlandt d...@nicira.com
mailto:d...@nicira.com wrote:

 all you need to do is create a bridge named br-int, which is what
 the linux devices representing the vm nics will be plugged into.

 since you are using tunneling, there is no need to create a br-ethX
 and add a physical interface to it.

 dan

 p.s. btw, your config looks like its using database polling,
which is
 not preferred.  I'd suggest you use the default config, which
uses RPC
 communication between agents and the main quantum-server process


 On Tue, Oct 23, 2012 at 8:44 PM, livemoon mwjpi...@gmail.com
mailto:mwjpi...@gmail.com wrote:
  I know in one node,vm can work well.
  I want to know in multi nodes, do I need to create a br-ethX,
and port
  the
  physical interface to it? how to do that in configuration?
 
  On Wed, Oct 24, 2012 at 11:36 AM, ??? iam...@gmail.com
mailto:iam...@gmail.com wrote:
 
  you just need to create one or more networks and specify
which network
  to
  use when booting vm.
 
  2012/10/24 livemoon mwjpi...@gmail.com
mailto:mwjpi...@gmail.com
 
  Hi, I use quantum as network. A question is if there are
multi nodes,
  how
  to config to make vms communicate with each other in the
same subnet.
 
  I use openvswitch as my plugin. And my setting is blow:
 
  [DATABASE]
  sql_connection =
mysql://quantum:openstack@172.16.1.1:3306/quantum
http://quantum:openstack@172.16.1.1:3306/quantum
  reconnect_interval = 2
 
  [OVS]
 
  tenant_network_type = gre
  tunnel_id_ranges = 1:1000
  integration_bridge = br-int
  tunnel_bridge = br-tun
  local_ip = 172.16.1.2
 
  enable_tunneling = True
 
 
  [AGENT]
  polling_interval = 2
  root_helper = sudo /usr/bin/quantum-rootwrap
  /etc/quantum/rootwrap.conf
 
  --
  ???,???
 
  ___
  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
 
 
 
 
  --
  ???@ljjjustin
 
 
 
 
  --
  ???,???
 
  ___
  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
 



 --
 ~~~
 Dan Wendlandt
 Nicira, Inc: www.nicira.com http://www.nicira.com
 twitter: danwendlandt
 ~~~




 --
 ???,???



--
~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com http://www.nicira.com
twitter: danwendlandt
~~~




--
Blog Site: livemoon.org http://livemoon.org
Twitter: mwjpiero
???,???



___
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] dnsmasq stops talking to instances?

[Gary Kotton]

On 10/18/2012 05:42 PM, Lars Kellogg-Stedman wrote:

The good news is that since replacing qpid with rabbitmq our
environment seems to have stabilized to the point that it's *almost*
useful.


Can you please explain the problems that you had with qpid?



The last remaining issue is that dnsmasq will occasionally stop
responding to instances.  Killing dnsmasq and restarting
openstack-nova-network makes things work again, but I haven't been
able to figure out why dnsmasq stops responding in the first place.

Has anyone seen this behavior before?  Any pointers would be greatly
appreciated.


Are you using the traditional nova networking or Quantum?
Thanks
Gary





___
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] Creating networks with same subnet across Tenants

[Gary Kotton]

On 10/12/2012 03:37 PM, Srikanth Kumar Lingala wrote:

*/overlaps with another subnet/*

HI,
There is a configuration variable that allows you to do this: 
allow_overlapping_ips. By default this is False. Can you please try 
setting it to True.

Thanks
Gary
___
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] Use of MAC addresses in Openstack VMs

[Gary Kotton]

On 10/20/2012 07:23 PM, Tim Bell wrote:


If we purchase an OUI, is there a mechanism within Quantum to only 
allocate Mac addresses with that prefix ?




At the moment Quantum enables the user to define a base MAC address. 
That is the user can update the configuration file. The user selects a 
base MAC and the MAC's are allocated in that range. I think that this 
gives us a lot of flexibility.


Please see below for the configuration options.

# Base MAC address. The first 3 octets will remain unchanged. If the
# 4h octet is not 00, it will also used. The others will be
# randomly generated.
# 3 octet
# base_mac = fa:16:3e:00:00:00
# 4 octet
# base_mac = fa:16:3e:4f:00:00

If I recall correctly this is hard coded in nova networking.

Thanks
Gary


Tim

*From:*openstack-bounces+tim.bell=cern...@lists.launchpad.net 
[mailto:openstack-bounces+tim.bell=cern...@lists.launchpad.net] *On 
Behalf Of *Salvatore Orlando

*Sent:* 20 October 2012 10:20
*To:* Vinay Bannai
*Cc:* openstack@lists.launchpad.net
*Subject:* Re: [Openstack] Use of MAC addresses in Openstack VMs

Hi Vinay,

I understand your concerns about conflicts with already assigned OUIs.

It is however my opinion that it is not up to the Openstack 
Foundation, but to entities deploying Openstack, to buy MAC OUIs.


As regards Quantum, we should ensure the default MAC range we use is 
locally assigned; unfortunately I do not know enough about nova-network.


Also, it is my opinion that a locally-assigned OUI would be sufficient 
for many use cases, without the need for a globally assigned one.


Regards,

Salvatore

On 20 October 2012 04:05, Vinay Bannai vban...@gmail.com 
mailto:vban...@gmail.com wrote:


I was talking to Nachi and Gary during the Quantum design session 
about the need to have a proper MAC OUI allocation scheme for 
Openstack development folks. They suggested that I send it out for 
wider discussion on the mailing list.


It turns out that it would be useful for the Openstack foundation to 
apply for a MAC OUI from IEEE that can be used for development 
purposes and testing. This way we don't unwittingly use someone else 
MAC allocation. Here are the details


http://standards.ieee.org/develop/regauth/oui/index.html

The cost to get a OUI allocation is around $2000 dollars. Remember if 
we use random MAC OUI,  the actual owners can assert their legal claim 
on the MAC address in the event of a conflict now that we have support 
for more sophisticated tunnels that allow connections from public and 
private clouds.


Comments welcome.

Vinay


___
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


___
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] Quantum PTL candidacy

[Gary Kotton]

___
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] Quantum PTL candidacy

[Gary Kotton]

___
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] Quantum PTL candidacy

[Gary Kotton]

Hi,

I am writing to announce my candidacy for the PTL for Quantum for the 
Grizzly release.  A quantum leap has been made with the up and coming 
Folsom release. Dan and the guys have done a tremendous job. More 
challenges await us in Grizzly. I started working on Quantum towards the 
end of the Essex release cycle. Since becoming involved in the project I 
have been completely focused on Quantum. My first contributions were in 
F-1 and in F-2 I was elected core (my wife would like me to spend a 
little more time with the family). I also had the privilege of hacking 
Quantum into oVirt [1].


For the Grizzly release I'd like us to be able to focus on the following:
- growing the Quantum community
- improve and complete the integration with nova
- focus on quality and documentation
- address architectural and performance issues
- incorporate new technologies and features into the project
- ensure that we maintain a stable Folsom release
- start to think towards version upgrades and backward compatibility

I am very lucky to have been given the opportunity by Red Hat to work on 
the project and be involved in OpenStack. When I am not working on 
Quantum I run.


Thanks
Gary

[1] https://fedoraproject.org/wiki/Quantum_and_oVirt#Proof_of_Concept

___
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] Quantum vs. Nova-network in Folsom

[Gary Kotton]

On 09/03/2012 08:47 PM, rob_hirschf...@dell.com wrote:

Dan,

The challenge here is how to wean off one code base (Nova Net) and into another 
(Quantum).

My thinking was that we'd be able to have more shared components and possibly 
shared code.   This could ease the transition by having operators gain 
experience with Open vSwitch.  Unfortunately, it is likely to also slow the 
transition because it would be investing more development effort in Nova 
Networking.


At the moment Quantum supports a number of different technologies, one 
of them is Open vSwitch. I think that if the focus is taken to integrate 
OVS directly into nova networking this would hinder both Nova Networking 
and Quantum. If the resources can be focused on Quantum then we can have 
one solution that supports a variety of networking technologies.


I think that if we focus our resources then hopefully by G-1 we can have 
Quantum replacing the traditional nova networking. I am not sure if a 
session is planned for the summit around this but it would be very good 
to discuss.




Note: I'm sorry about the delay in replying.  I off so I could include some 
perspective from investigation.  It showed that some of the simplest Nova 
networking modes could use vSwitch but the popular ones would require 
duplicating/porting Quantum code back to Nova.


You can do this if you want to very basic bridging. But when you want to 
expose OpenFlow and other technologies you will most probably take a 
approach similar to that of Quantum.


That is my two cents.
Thanks
Gary


Once of the things that I believe could help migration is getting Quantum API 
integrates into abstractions like Fog.  In fact, I've proposed a Summit topic 
about exactly that.


This sounds interesting. It seems that there is also some overlapping - 
for example the address management and DHCP handing by Quantum and FOG


Thanks,

Rob

-Original Message-
From: Dan Wendlandt [mailto:d...@nicira.com]
Sent: Monday, August 27, 2012 12:57 PM
To: Hirschfeld, Rob
Cc: openstack@lists.launchpad.net; openstack-...@lists.openstack.org
Subject: Re: [Openstack] Quantum vs. Nova-network in Folsom

On Sun, Aug 26, 2012 at 12:39 PM,rob_hirschf...@dell.com  wrote:

Stackers,

I think this is a reasonable approach and appreciate the clarification of 
use-cases.

We've been discussing using Open vSwitch as the basis for non-Quantum Nova 
Networking deployments in Folsom.  While not Quantum, it feels like we're 
bringing Nova Networking a step closer to some of the core technologies that 
Quantum uses.

I'm interested in hearing what other's in the community think about this 
approach.

One of the main reasons we introduced Quantum was to support alternative 
switching technologies like Open vSwitch.  I'd like to hear more about your 
thoughts, but at first glance, I'm not sure there's a good way to leverage Open 
vSwitch in a meaningful way with existing nova-network managers, since those 
network managers are so tightly tied to using the basic linux bridge + vlans.

Dan


Rob

-Original Message-
From: openstack-bounces+rob_hirschfeld=dell@lists.launchpad.net
[mailto:openstack-bounces+rob_hirschfeld=dell@lists.launchpad.net]
On Behalf Of Dan Wendlandt
Sent: Friday, August 24, 2012 5:39 PM
To: openstack@lists.launchpad.net; OpenStack Development Mailing List
Subject: [Openstack] Quantum vs. Nova-network in Folsom

tl;dr  both Quantum and nova-network will be core and fully supported in Folsom.

Hi folks,

Thierry, Vish and I have been spending some talking about OpenStack networking 
in Folsom, and in particular the availability of nova-network now that Quantum 
is a core project.  We wanted to share our current thinking with the community 
to avoid confusion.

With a project like OpenStack, there's a fundamental trade-off between the rate 
of introducing new capabilities and the desire for stability and backward 
compatibility.  We agreed that OpenStack is a point in its growth cycle where 
the cost of disruptive changes is high.  As a result, we've decided that even 
with Quantum being core in Folsom, we will also continue to support 
nova-network as it currently exists in Folsom.  There is, of couse, overhead to 
this approach, but we think it is worth it.

With this in mind, a key question becomes: how do we direct users to
the networking option that is right for them.  We have the following
guidelines:

1) For users who require only very basic networking (e.g., nova-network Flat, 
FlatDHCP) there's little difference between Quantum and nova-network is such 
basic use cases, so using nova's built-in networking for these basic use cases 
makes sense.

2) There are many use cases (e.g., tenant API for defined topologies and 
addresses) and advanced network technologies (e.g., tunneling rather than 
VLANs) that Quantum enables that are simply not possible with nova-network, so 
if these advanced capabilities are important to someone deploying OpenStack, 
they clearly 

Re: [Openstack] Quantum DHCP support.

[Gary Kotton]

On 09/04/2012 12:03 PM, Takaaki Suzuki wrote:

Hi

Currently, I see that DHCP instance is created per network, at least
from looking at the Dnsmasq implementation.

I'm curious to know how a DHCP instance can provide services to a VM
attached to a port on a network that has multiple subnets.

It doesn't seem possible to me that a VM can get two IP addresses on
an interface from this DHCP server. Is this feature supported in
Quantum?

I ran a quick test using Devstack + QuantumV2 + OVS plugin.  I created
one network called test04, and two subnets for tor the network,
192.168.10.0/24 and 192.168.30.0/24.
When a Quantum port is allocated an IP address is selected from one of 
the subnets configured on the network (unless the user has requested 
more than one IP address). The DHCP agent will learn this IP address and 
update the hosts file.


Can you please provide the following information:
1. can you please do quantum port-list?
2. Is the DHCP agent running (q-dhcp in stackrc)?
3. How did you launch the VM's? Did you use nova boot --nic 
net-id=quantum network ID?
4. Can you please check that the host files has the MAC address and IP 
address of your VM - this is under /opt/stack/data/dhcp/network id/..


Thanks
Gary

With Dnsmasq running as the DHCP server, I launched a VM, and as
suspected, it did not receive any IP address.  I checked the Dnsmasq
log and it looked like it did receive DHCPDISCOVER message but it did
not offer anything back.

I would love to know there is actually a way to get this to work, or
if I'm missing some critical steps here.

Thanks!
Suzuki

___
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] Quantum DHCP support.

[Gary Kotton]

On 09/04/2012 12:48 PM, Takaaki Suzuki wrote:

Hi Gary

Thank you for your support.
I share with you information.


Can you also please provide sudo ovs-vsctl show?

Thanks
Gary



1. can you please do quantum port-list?

quantum --os_token f095d7163a564456b60bf47b078537a7 --os_url
http://localhost:9696/ port-list

- VM port
admin_state_up : True
device_id  : d6f9eb16-fb54-4c6c-8c1f-dd7859696910
device_owner:
fixed_ips   :{subnet_id:
2c6e941e-cf21-40c9-8f1a-37db0e2e9a46, ip_address: 192.168.30.3}
id : 0118eb34-424f-460e-8e12-42ecffb2dad8
mac_address: fa:16:3e:0d:e6:31
name:
network_id: 069f4cfc-3f97-4018-b08e-4a4868f3ca94
status   : ACTIVE
tenant_id   :cf67ba5e70e346b9a080fb349b5e1125

- DHCP agent port
admin_state_up : True
device_id  :
dhcp72aca792-f411-52a0-a641-defa1b398574-069f4cfc-3f97-4018-b08e-4a4868f3ca94
device_owner: network:dhcp
fixed_ips   : {subnet_id:
bf07d0cd-7abb-4bf0-83a2-dfc1f3c21f8e, ip_address: 192.168.10.2},
{subnet_id: 2c6e941e-cf21-40c9-8f1a-37db0e2e9a46, ip_address:
192.168.30.2}
id : bd10a19b-a679-4b65-b36b-7beffcdae1ba
mac_address: fa:16:3e:6c:f0:b5
name: DHCP Agent
network_id: 069f4cfc-3f97-4018-b08e-4a4868f3ca94
status   : ACTIVE
tenant_id   :cf67ba5e70e346b9a080fb349b5e1125



2. Is the DHCP agent running (q-dhcp in stackrc)?

Yes, DHCP agent running. I added enable_service q-dhcp.


3. How did you launch the VM's? Did you use nova boot --nic net-id=quantum
network ID?

I use Horizon for Quantum V2 (https://github.com/amotoki/horizon).


4. Can you please check that the host files has the MAC address and IP
address of your VM - this is under /opt/stack/data/dhcp/network id/..

midokura16:/opt/stack/data/dhcp/069f4cfc-3f97-4018-b08e-4a4868f3ca94# cat host
fa:16:3e:0d:e6:31,192-168-30-3.openstacklocal,192.168.30.3
fa:16:3e:6c:f0:b5,192-168-10-2.openstacklocal,192.168.10.2
fa:16:3e:6c:f0:b5,192-168-30-2.openstacklocal,192.168.30.2

- dnsmasq syslog when launch VM.
dnsmasq-dhcp[12592]: DHCPDISCOVER(tapbd10a19b-a6) fa:16:3e:0d:e6:31 no
address available
dnsmasq-dhcp[12592]: last message repeated 2 times
dnsmasq-dhcp[12592]: DHCPDISCOVER(tapbd10a19b-a6) fa:16:3e:15:62:6a no
address available
dnsmasq-dhcp[12592]: last message repeated 2 times

- sudo ip netns exec 069f4cfc-3f97-4018-b08e-4a4868f3ca94 ip link
104: tapbd10a19b-a6:BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP  mtu
1500 qdisc noqueue state UNKNOWN
 link/ether fa:16:3e:6c:f0:b5 brd ff:ff:ff:ff:ff:ff

- sudo ip netns exec 069f4cfc-3f97-4018-b08e-4a4868f3ca94 ip route
192.168.10.0/24 dev tapbd10a19b-a6  proto kernel  scope link  src 192.168.10.2
192.168.30.0/24 dev tapbd10a19b-a6  proto kernel  scope link  src 192.168.30.2

- quantum-dhcp agent spawn dnsmasq for test04 network
dnsmasq --no-hosts --no-resolv --strict-order --bind-interfaces
--interface=tapbd10a19b-a6 --except-interface=lo
--domain=openstacklocal
--pid-file=/opt/stack/data/dhcp/069f4cfc-3f97-4018-b08e-4a4868f3ca94/pid
--dhcp-hostsfile=/opt/stack/data/dhcp/069f4cfc-3f97-4018-b08e-4a4868f3ca94/host
--dhcp-optsfile=/opt/stack/data/dhcp/069f4cfc-3f97-4018-b08e-4a4868f3ca94/opts
--leasefile-ro --dhcp-range=set:tag0,192.168.10.0,static,120s

Hope that helped.
Thanks!

Suzuki

On Tue, Sep 4, 2012 at 6:13 PM, Gary Kottongkot...@redhat.com  wrote:

On 09/04/2012 12:03 PM, Takaaki Suzuki wrote:

Hi

Currently, I see that DHCP instance is created per network, at least
from looking at the Dnsmasq implementation.

I'm curious to know how a DHCP instance can provide services to a VM
attached to a port on a network that has multiple subnets.

It doesn't seem possible to me that a VM can get two IP addresses on
an interface from this DHCP server. Is this feature supported in
Quantum?

I ran a quick test using Devstack + QuantumV2 + OVS plugin.  I created
one network called test04, and two subnets for tor the network,
192.168.10.0/24 and 192.168.30.0/24.

When a Quantum port is allocated an IP address is selected from one of the
subnets configured on the network (unless the user has requested more than
one IP address). The DHCP agent will learn this IP address and update the
hosts file.

Can you please provide the following information:
1. can you please do quantum port-list?
2. Is the DHCP agent running (q-dhcp in stackrc)?
3. How did you launch the VM's? Did you use nova boot --nic net-id=quantum
network ID?
4. Can you please check that the host files has the MAC address and IP
address of your VM - this is under /opt/stack/data/dhcp/network id/..

Thanks
Gary

With Dnsmasq running as the DHCP server, I launched a VM, and as
suspected, it did not receive any IP address.  I checked the Dnsmasq
log and it looked like it did receive DHCPDISCOVER message but it did
not offer anything back.

I would love to know there is actually a way to get this to work, or
if I'm missing some critical steps here.

Re: [Openstack] Quantum DHCP support.

[Gary Kotton]

On 09/04/2012 12:56 PM, Takaaki Suzuki wrote:

Can you also please provide sudo ovs-vsctl show?

sure.


It looks like a bug. I'll investigate further and let you know.

Thanks
Gary



midokura16:~/devstack# ovs-vsctl show
d699f1f2-792c-4eb9-8306-32a622316389
 Bridge br-tun
 Port br-tun
 Interface br-tun
 type: internal
 Port patch-int
 Interface patch-int
 type: patch
 options: {peer=patch-tun}
 Bridge br-int
 Port tapee78cf13-65
 tag: 4
 Interface tapee78cf13-65
 type: internal
 Port tap0e74b599-a1
 tag: 3
 Interface tap0e74b599-a1
 Port tapc2df9bdf-da
 tag: 1
 Interface tapc2df9bdf-da
 type: internal
 Port tapda44c6f5-b4
 tag: 3
 Interface tapda44c6f5-b4
 type: internal
 Port br-int
 Interface br-int
 type: internal
 Port patch-tun
 Interface patch-tun
 type: patch
 options: {peer=patch-int}
 Port tap0fb10fc2-62
 tag: 2
 Interface tap0fb10fc2-62
 Port tap0118eb34-42
 tag: 2
 Interface tap0118eb34-42
 Port tapbd10a19b-a6
 tag: 2
 Interface tapbd10a19b-a6
 type: internal
 Port tap38bea316-b0
 tag: 3
 Interface tap38bea316-b0
 ovs_version: 1.6.1

Thanks!
Suzuki

On Tue, Sep 4, 2012 at 6:52 PM, Gary Kottongkot...@redhat.com  wrote:

On 09/04/2012 12:48 PM, Takaaki Suzuki wrote:

Hi Gary

Thank you for your support.
I share with you information.


Can you also please provide sudo ovs-vsctl show?

Thanks
Gary


1. can you please do quantum port-list?

quantum --os_token f095d7163a564456b60bf47b078537a7 --os_url
http://localhost:9696/ port-list

- VM port
admin_state_up : True
device_id  : d6f9eb16-fb54-4c6c-8c1f-dd7859696910
device_owner:
fixed_ips   :{subnet_id:
2c6e941e-cf21-40c9-8f1a-37db0e2e9a46, ip_address: 192.168.30.3}
id : 0118eb34-424f-460e-8e12-42ecffb2dad8
mac_address: fa:16:3e:0d:e6:31
name:
network_id: 069f4cfc-3f97-4018-b08e-4a4868f3ca94
status   : ACTIVE
tenant_id   :cf67ba5e70e346b9a080fb349b5e1125

- DHCP agent port
admin_state_up : True
device_id  :

dhcp72aca792-f411-52a0-a641-defa1b398574-069f4cfc-3f97-4018-b08e-4a4868f3ca94
device_owner: network:dhcp
fixed_ips   : {subnet_id:
bf07d0cd-7abb-4bf0-83a2-dfc1f3c21f8e, ip_address: 192.168.10.2},
{subnet_id: 2c6e941e-cf21-40c9-8f1a-37db0e2e9a46, ip_address:
192.168.30.2}
id : bd10a19b-a679-4b65-b36b-7beffcdae1ba
mac_address: fa:16:3e:6c:f0:b5
name: DHCP Agent
network_id: 069f4cfc-3f97-4018-b08e-4a4868f3ca94
status   : ACTIVE
tenant_id   :cf67ba5e70e346b9a080fb349b5e1125



2. Is the DHCP agent running (q-dhcp in stackrc)?

Yes, DHCP agent running. I added enable_service q-dhcp.


3. How did you launch the VM's? Did you use nova boot --nic
net-id=quantum
network ID?

I use Horizon for Quantum V2 (https://github.com/amotoki/horizon).


4. Can you please check that the host files has the MAC address and IP
address of your VM - this is under /opt/stack/data/dhcp/network id/..

midokura16:/opt/stack/data/dhcp/069f4cfc-3f97-4018-b08e-4a4868f3ca94# cat
host
fa:16:3e:0d:e6:31,192-168-30-3.openstacklocal,192.168.30.3
fa:16:3e:6c:f0:b5,192-168-10-2.openstacklocal,192.168.10.2
fa:16:3e:6c:f0:b5,192-168-30-2.openstacklocal,192.168.30.2

- dnsmasq syslog when launch VM.
dnsmasq-dhcp[12592]: DHCPDISCOVER(tapbd10a19b-a6) fa:16:3e:0d:e6:31 no
address available
dnsmasq-dhcp[12592]: last message repeated 2 times
dnsmasq-dhcp[12592]: DHCPDISCOVER(tapbd10a19b-a6) fa:16:3e:15:62:6a no
address available
dnsmasq-dhcp[12592]: last message repeated 2 times

- sudo ip netns exec 069f4cfc-3f97-4018-b08e-4a4868f3ca94 ip link
104: tapbd10a19b-a6:BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP   mtu
1500 qdisc noqueue state UNKNOWN
  link/ether fa:16:3e:6c:f0:b5 brd ff:ff:ff:ff:ff:ff

- sudo ip netns exec 069f4cfc-3f97-4018-b08e-4a4868f3ca94 ip route
192.168.10.0/24 dev tapbd10a19b-a6  proto kernel  scope link  src
192.168.10.2
192.168.30.0/24 dev tapbd10a19b-a6  proto kernel  scope link  src
192.168.30.2

- quantum-dhcp agent spawn dnsmasq for test04 network
dnsmasq --no-hosts --no-resolv --strict-order --bind-interfaces
--interface=tapbd10a19b-a6 --except-interface=lo
--domain=openstacklocal
--pid-file=/opt/stack/data/dhcp/069f4cfc-3f97-4018-b08e-4a4868f3ca94/pid

--dhcp-hostsfile=/opt/stack/data/dhcp/069f4cfc-3f97-4018-b08e-4a4868f3ca94/host

--dhcp-optsfile=/opt/stack/data/dhcp/069f4cfc-3f97-4018-b08e-4a4868f3ca94/opts
--leasefile-ro --dhcp-range=set:tag0,192.168.10.0,static,120s

Hope that helped.

Re: [Openstack] Quantum DHCP support.

[Gary Kotton]

Hi,
Just a few more questions:
1. Can you send me the results of ps aux |grep dnsmasq
2. Can you also please send the ifconfig. The tap devices for also ip 
address. Can you please send me ip addr. (my gut feeling is that we do 
not configure 192.168.30.2 but rather 192.168.10.2.

Thanks
Gary

On 09/04/2012 12:56 PM, Takaaki Suzuki wrote:

Can you also please provide sudo ovs-vsctl show?

sure.

midokura16:~/devstack# ovs-vsctl show
d699f1f2-792c-4eb9-8306-32a622316389
 Bridge br-tun
 Port br-tun
 Interface br-tun
 type: internal
 Port patch-int
 Interface patch-int
 type: patch
 options: {peer=patch-tun}
 Bridge br-int
 Port tapee78cf13-65
 tag: 4
 Interface tapee78cf13-65
 type: internal
 Port tap0e74b599-a1
 tag: 3
 Interface tap0e74b599-a1
 Port tapc2df9bdf-da
 tag: 1
 Interface tapc2df9bdf-da
 type: internal
 Port tapda44c6f5-b4
 tag: 3
 Interface tapda44c6f5-b4
 type: internal
 Port br-int
 Interface br-int
 type: internal
 Port patch-tun
 Interface patch-tun
 type: patch
 options: {peer=patch-int}
 Port tap0fb10fc2-62
 tag: 2
 Interface tap0fb10fc2-62
 Port tap0118eb34-42
 tag: 2
 Interface tap0118eb34-42
 Port tapbd10a19b-a6
 tag: 2
 Interface tapbd10a19b-a6
 type: internal
 Port tap38bea316-b0
 tag: 3
 Interface tap38bea316-b0
 ovs_version: 1.6.1

Thanks!
Suzuki

On Tue, Sep 4, 2012 at 6:52 PM, Gary Kottongkot...@redhat.com  wrote:

On 09/04/2012 12:48 PM, Takaaki Suzuki wrote:

Hi Gary

Thank you for your support.
I share with you information.


Can you also please provide sudo ovs-vsctl show?

Thanks
Gary


1. can you please do quantum port-list?

quantum --os_token f095d7163a564456b60bf47b078537a7 --os_url
http://localhost:9696/ port-list

- VM port
admin_state_up : True
device_id  : d6f9eb16-fb54-4c6c-8c1f-dd7859696910
device_owner:
fixed_ips   :{subnet_id:
2c6e941e-cf21-40c9-8f1a-37db0e2e9a46, ip_address: 192.168.30.3}
id : 0118eb34-424f-460e-8e12-42ecffb2dad8
mac_address: fa:16:3e:0d:e6:31
name:
network_id: 069f4cfc-3f97-4018-b08e-4a4868f3ca94
status   : ACTIVE
tenant_id   :cf67ba5e70e346b9a080fb349b5e1125

- DHCP agent port
admin_state_up : True
device_id  :

dhcp72aca792-f411-52a0-a641-defa1b398574-069f4cfc-3f97-4018-b08e-4a4868f3ca94
device_owner: network:dhcp
fixed_ips   : {subnet_id:
bf07d0cd-7abb-4bf0-83a2-dfc1f3c21f8e, ip_address: 192.168.10.2},
{subnet_id: 2c6e941e-cf21-40c9-8f1a-37db0e2e9a46, ip_address:
192.168.30.2}
id : bd10a19b-a679-4b65-b36b-7beffcdae1ba
mac_address: fa:16:3e:6c:f0:b5
name: DHCP Agent
network_id: 069f4cfc-3f97-4018-b08e-4a4868f3ca94
status   : ACTIVE
tenant_id   :cf67ba5e70e346b9a080fb349b5e1125



2. Is the DHCP agent running (q-dhcp in stackrc)?

Yes, DHCP agent running. I added enable_service q-dhcp.


3. How did you launch the VM's? Did you use nova boot --nic
net-id=quantum
network ID?

I use Horizon for Quantum V2 (https://github.com/amotoki/horizon).


4. Can you please check that the host files has the MAC address and IP
address of your VM - this is under /opt/stack/data/dhcp/network id/..

midokura16:/opt/stack/data/dhcp/069f4cfc-3f97-4018-b08e-4a4868f3ca94# cat
host
fa:16:3e:0d:e6:31,192-168-30-3.openstacklocal,192.168.30.3
fa:16:3e:6c:f0:b5,192-168-10-2.openstacklocal,192.168.10.2
fa:16:3e:6c:f0:b5,192-168-30-2.openstacklocal,192.168.30.2

- dnsmasq syslog when launch VM.
dnsmasq-dhcp[12592]: DHCPDISCOVER(tapbd10a19b-a6) fa:16:3e:0d:e6:31 no
address available
dnsmasq-dhcp[12592]: last message repeated 2 times
dnsmasq-dhcp[12592]: DHCPDISCOVER(tapbd10a19b-a6) fa:16:3e:15:62:6a no
address available
dnsmasq-dhcp[12592]: last message repeated 2 times

- sudo ip netns exec 069f4cfc-3f97-4018-b08e-4a4868f3ca94 ip link
104: tapbd10a19b-a6:BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP   mtu
1500 qdisc noqueue state UNKNOWN
  link/ether fa:16:3e:6c:f0:b5 brd ff:ff:ff:ff:ff:ff

- sudo ip netns exec 069f4cfc-3f97-4018-b08e-4a4868f3ca94 ip route
192.168.10.0/24 dev tapbd10a19b-a6  proto kernel  scope link  src
192.168.10.2
192.168.30.0/24 dev tapbd10a19b-a6  proto kernel  scope link  src
192.168.30.2

- quantum-dhcp agent spawn dnsmasq for test04 network
dnsmasq --no-hosts --no-resolv --strict-order --bind-interfaces
--interface=tapbd10a19b-a6 --except-interface=lo
--domain=openstacklocal
--pid-file=/opt/stack/data/dhcp/069f4cfc-3f97-4018-b08e-4a4868f3ca94/pid

Re: [Openstack] quantum-openvswitch-agent needs a restart to bind the vlan-ID

[Gary Kotton]

Hi,
I have managed to find the problem :). I have spent the whole day on 
this :(.
I was running devstack and the code executes ovs_quantum_agent.py. 
Whilst going through the mailing mails I came upon this mail and saw 
that you are calling quantum-openvswitch-agent.

I'll post a fix soon.
Thanks!
Gary

On 08/31/2012 06:19 AM, Naveen Joy (najoy) wrote:

Hi Dan,

This issue happens only when rpc = True and it happens consistently. When rpc 
=False,  everything is fine. Thanks for this pointer!.  Also, I am just 
spinning up a single VM though the horizon interface without using any scripts.

Naveen

-Original Message-
From: Dan Wendlandt [mailto:d...@nicira.com]
Sent: Thursday, August 30, 2012 5:42 PM
To: Naveen Joy (najoy)
Cc: Aaron Rosen; openstack list (openstack@lists.launchpad.net)
Subject: Re: [Openstack] quantum-openvswitch-agent needs a restart to bind the 
vlan-ID

Hi Naveen,

Was noticing something like this while testing last night, but hadn't gotten 
around to determining if it was in master or just the branch I was testing.

Are you seeing this even if rpc = False?   I noticed this only when my
settings got reset to make rpc = True, though I haven't investigated it enough 
to know if that is the rpc flag is just a coincidence.

Another possible correlation I've noticed is that it occurs when I use a script 
to spin up multiple VMs in succession, possibly suggesting some kind of 
race/timing issue.  Does that match your use case?

It looks like there's a bug on this, so I'll post my questions there as well, 
so that we can keep all info on the bug in one place:
https://bugs.launchpad.net/bugs/1044135

Thanks,

Dan




On Thu, Aug 30, 2012 at 4:16 PM, Naveen Joy (najoy)na...@cisco.com  wrote:

Hi Aaron,



The agent has not crashed.

#sudo status quantum-openvswitch-agent

quantum-openvswitch-agent start/running, process 20208



However, the agent is not  binding the port to the vlan unless I restart it.
The log_file setting in the ovs_quantum_plugin.ini file also doesn't
seem to work.



Thanks,

Naveen



From: Aaron Rosen [mailto:aro...@nicira.com]
Sent: Thursday, August 30, 2012 3:02 PM
To: Naveen Joy (najoy)
Cc: openstack list (openstack@lists.launchpad.net)
Subject: Re: [Openstack] quantum-openvswitch-agent needs a restart to
bind the vlan-ID



Hi Joy,



I did noticed a bug in ovs_lib.py but it would cause q-agt to crash.
Did the agent crash?



Aaron

On Thu, Aug 30, 2012 at 2:48 PM, Naveen Joy (najoy)na...@cisco.com  wrote:

Hi All,



I am running the latest quantum code base. I am seeing an issue in
which the openvswitch agent is not automatically assigning the vlans
to the tap interfaces of my new instances. If I restart the agent, it
fixes the problem. Has anyone seen this issue?.



#quantum port-list

| True   | b74ebe64-4a25-462b-b022-e1c6c42b7e9e
| compute:N| {subnet_id: a44f49dd-cc71-4da6-998c-f0842687d4b0,
ip_address: 192.168.119.86} | 7e6e1373-5ddd-410c-807f-cdf50893be55 |
fa:16:3e:82:ba:43 || acab3c27-2a5d-4a62-8dbe-e7f856f83978 |
ACTIVE | 244be8af89624b1e94c0136d5d557a9d |



#sudo ovs-vsctl list port

_uuid   : 2eec7692-4e1b-40a8-a428-ee8956516406

bond_downdelay  : 0

bond_fake_iface : false

bond_mode   : []

bond_updelay: 0

external_ids: {}

fake_bridge : false

interfaces  : [8dfee46d-e752-4c84-a738-5a63cf4c9c09]

lacp: []

mac : []

name: tap7e6e1373-5d

other_config: {}

qos : []

statistics  : {}

status  : {}

tag : []

trunks  : []

vlan_mode   : []



#sudo restart quantum-openvswitch-agent

#sudo ovs-vsctl list port

_uuid   : 2eec7692-4e1b-40a8-a428-ee8956516406

bond_downdelay  : 0

bond_fake_iface : false

bond_mode   : []

bond_updelay: 0

external_ids: {}

fake_bridge : false

interfaces  : [8dfee46d-e752-4c84-a738-5a63cf4c9c09]

lacp: []

mac : []

name: tap7e6e1373-5d

other_config: {}

qos : []

statistics  : {}

status  : {}

tag : 622

trunks  : []

vlan_mode   : []



Thanks,

Naveen




___
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




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

___
Mailing list: 

Re: [Openstack] [Netstack] Openstack Folsom - 3 Installation

[Gary Kotton]

On 08/23/2012 10:16 AM, Trinath Somanchi wrote:

Hi -

Rather than using this installation for every different package can I 
use devstack's stack.sh script to install the Openstack latest 
milestone release?


devstack does not use the installation packages. This uses the git 
repositories. By looking at devstack you can see how to invoke and run 
the various openstack services.




Can any one comment on  this.

Thanking you,

-
Trinath




On Thu, Aug 23, 2012 at 11:45 AM, Aaron Rosen aro...@nicira.com 
mailto:aro...@nicira.com wrote:


inline

On Thu, Aug 23, 2012 at 1:34 AM, Trinath Somanchi
trinath.soman...@gmail.com mailto:trinath.soman...@gmail.com
wrote:

Hi-

Any inputs for understanding and resolving the issue...


Kindly help me in this regard.

--
Trinath


On Wed, Aug 22, 2012 at 4:43 PM, Trinath Somanchi
trinath.soman...@gmail.com
mailto:trinath.soman...@gmail.com wrote:

Hi All-

I'm installing Openstack Components of Folsom-3 milestone
from the Tar files available from launchpad.

Can any one guide me on the installation of the these
components like the Essex component installation and
configuration.

I'm upto this level of Installation.

For instance, Keystone component,

I have untar the file and executed the following commands.

*Keystone $* python setup.py build
*Keystone $* python setup.py install.

Will these two steps install the respective component and
all its necessary components.

Probably only need sudo python setup.py install

With this type of Install can I use the Openstack
components as I use them in the 'apt-get' based Essex
installation.

Yes, this is just a different method of installation.

Kindly guide me on this...

Thanking you all.




-- 
Regards,

--
Trinath Somanchi,
+91 9866 235 130 tel:%2B91%209866%20235%20130




-- 
Regards,

--
Trinath Somanchi,
+91 9866 235 130 tel:%2B91%209866%20235%20130


--
Mailing list: https://launchpad.net/~netstack
https://launchpad.net/%7Enetstack
Post to : netst...@lists.launchpad.net
mailto:netst...@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
https://launchpad.net/%7Enetstack
More help   : https://help.launchpad.net/ListHelp





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



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


___
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] [Quantum] Removing quantum-rootwrap

[Gary Kotton]

On 08/13/2012 08:42 AM, balaji patnala wrote:

Hello Thierry,

Can we download Folsom branch codebase for understanding Quantum and 
other changes in Folsom release?


You can get the code at git://github.com/openstack/quantum.git.
If you would like to see the status of things regarding F-3 then please 
look at https://launchpad.net/quantum/.


The guys in the community have done some great work over the last few weeks!


Please give us your comments,experience and known issues.

Thanks in advance.

-balaji

On Wed, Aug 8, 2012 at 7:01 PM, Thierry Carrez thie...@openstack.org 
mailto:thie...@openstack.org wrote:


Hi everyone,

Quantum currently contains bin/quantum-rootwrap, a copy of
nova-rootwrap
supposed to control its privilege escalation to run commands as root.

However quantum-rootwrap is currently non-functional, missing a lot of
filter definitions that are necessary for it to work correctly.
Quantum
is generally run with root_helper=sudo and a wildcard sudoers
file. That
means Quantum is not ready to deprecate in Folsom (and remove in
Grizzly) its ability to run with root_helper=sudo, like Nova and
Cinder do.

I discussed this with Dan, and it appears that the sanest approach
would
be to remove quantum-rootwrap from Quantum and only support
root_helper=sudo (the only option that works). I suspect nobody is
actually using quantum-rootwrap right now anyway, given how broken it
seems to be. For the first official release of Quantum as an OpenStack
core project, I would prefer not to ship half-working options :)

Quantum would then wait for rootwrap to move to openstack-common
(should
be done in Grizzly) to reconsider using it.

Let me know if any of you see issues with that approach.
(posted to the general list to get the widest feedback).

--
Thierry Carrez (ttx)
Release Manager, OpenStack

___
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


___
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] [Quantum] Scalable agents

[Gary Kotton]

On 07/23/2012 11:02 AM, Dan Wendlandt wrote:



On Sun, Jul 22, 2012 at 5:51 AM, Gary Kotton gkot...@redhat.com 
mailto:gkot...@redhat.com wrote:




This is an interesting idea. In addition to the creation we will
also need the update. I would prefer that the agents would have
one topic - that is for all updates. When an agent connects to the
plugin it will register the type of operations that are supported
on the specific agent. The agent operations can be specific as bit
masks.

I have implemented something similar in
https://review.openstack.org/#/c/9591

This can certainly be improved and optimized. What are your thoughts?


Based on your follow-up emails, I think we're now thinking similarly 
about this.  Just to be clear though, for updates I was talking about 
a different topic for each entity that has its own UUID (e.g., topic 
port-update-f01c8dcb-d9c1-4bd6-9101-1924790b4b45)


Printout from the rabbit queues (this is for linux bridge where at the 
moment the port update and network deletion are of interest (unless we 
decide to change the way in which the agent is implemented))


openstack@openstack:~/devstack$ sudo rabbitmqctl list_queues
Listing queues ...
q-agent-network-update0
q-agent-network-update.10351797001a4a2312790
q-plugin0
q-agent-port-update.10351797001a4a2312790

10351797001a4a231279 == IP and MAC of the host



In addition to this we have a number of issues where the plugin
does not expose the information via the standard API's - for
example the VLAN tag (this is being addressed via extensions in
the provider networks feature)


Agreed.  There are a couple options here: direct DB access (no 
polling, just direct fetching), admin API extensions, or custom RPC 
calls.  Each has pluses and minuses.  Perhaps my real goal here would 
be better described as if there's an existing plugin agnostic way to 
doing X, our strong bias should be to use it until presented with 
concrete  evidence to the contrary.   For example, should a DHCP 
client create a port for the DHCP server via the standard API, or via 
a custom API or direct DB access?  My strong bias would be toward 
using the standard API.


Good question. I think that if the standard API's can be used then we 
should go for it. Problem is that these require additional configurations.



3. Logging. At the moment the agents do not have a decent logging
mechanism. This makes debugging the RPC code terribly difficult.
This was scheduled for F-3. I'll be happy to add this if there are
no objections.


That sounds valuable.


Hopefully I'll be able to find some time for this.


4. We need to discuss the notifications that Yong added and how
these two methods can interact together. More specifically I think
that we need to address the configuration files.


Agreed.  I think we need to decide on this at monday's IRC meeting, so 
we can move forward.  Given F-3 deadlines, I'm well aware that I'll 
have to be pragmatic here :)



The RPC code requires that the eventlet monkey patch be set. This
cause havoc when I was using the events from pyudev for new device
creation. At the moment I have moved the event driven support to
polling (if anyone who reads this is familiar with the issue or
has an idea on how to address it any help will be great)


Sorry, wish I could help, but I'm probably in the same boat as you on 
this one.


I have a solution that works. In the long term it would be better if 
this was event driven. This all depends on how the discussions above 
play out.
I'm going to make sure we have a good chunk of time to discuss this 
during the IRC meeting on monday (sorry, I know that's late night for 
you...).


:). Tomorrow is jet lag day!


Dan



Thanks
Gary


Dan


~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com http://www.nicira.com
twitter: danwendlandt
~~~






--
~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com http://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] [Quantum] Scalable agents

[Gary Kotton]

On 07/19/2012 07:11 PM, Dan Wendlandt wrote:



On Wed, Jul 18, 2012 at 5:17 AM, Gary Kotton gkot...@redhat.com 
mailto:gkot...@redhat.com wrote:


On 07/18/2012 04:23 AM, Dan Wendlandt wrote:




Hi Gary,

Removing much of the thread history, as I think we agree on the 
high-level goals.  Now just focusing on the differences.





For example, a DHCP agent handling all DHCP for a deployment
might register for create/update/delete operations on subnets +
ports, whereas a plugin agent might only register for updates
from the ports that it sees locally on the hypervisor.
 Conceptually, you could think of there being a 'topic' per port
in this case, though we may need to implement it differently in
practice.


The agent ID is currently stored in the database (this is for the
configuration sync mechanism). I think that adding an extra column
indicating the capabilities enables the service to notify the
agents. The issue is how refined can the updates be - we want to
ensure that we have a scalable architecture.


I think either we can implement the filtering ourselves using a 
mechanism like this, or we can rely on the message bus to do it for 
us.  I'm not really familiar with the scalability of various message 
bus implementations, but a simple model would be that there's a topic 
for:

- port creation
- net creation
- subnet creation


This is an interesting idea. In addition to the creation we will also 
need the update. I would prefer that the agents would have one topic - 
that is for all updates. When an agent connects to the plugin it will 
register the type of operations that are supported on the specific 
agent. The agent operations can be specific as bit masks.


I have implemented something similar in 
https://review.openstack.org/#/c/9591


This can certainly be improved and optimized. What are your thoughts?

In addition to this we have a number of issues where the plugin does not 
expose the information via the standard API's - for example the VLAN tag 
(this is being addressed via extensions in the provider networks feature)


There are a number of things that we need to address:
1. Support for different plugins - if acceptable then the model above 
needs to be more generic and a common interface should be defined.
2. Support for different agents. This is pretty simple - for example the 
DHCP agent. It has to do the following:
i. use the health check mechanism (this registers the mask for the 
notification updates)
ii. add in support for port creation (I guess that I can add this 
as part of this patch)
3. Logging. At the moment the agents do not have a decent logging 
mechanism. This makes debugging the RPC code terribly difficult. This 
was scheduled for F-3. I'll be happy to add this if there are no objections.
4. We need to discuss the notifications that Yong added and how these 
two methods can interact together. More specifically I think that we 
need to address the configuration files.


The RPC code requires that the eventlet monkey patch be set. This cause 
havoc when I was using the events from pyudev for new device creation. 
At the moment I have moved the event driven support to polling (if 
anyone who reads this is familiar with the issue or has an idea on how 
to address it any help will be great)


and a specific topic for each entity after its created to learn about 
updates and deletes.


I prefer having a cast to a specific topic than a broadcast all. (please 
look at 
https://review.openstack.org/#/c/9591/3/quantum/plugins/linuxbridge/lb_quantum_plugin.py 
- method update_port - line 174).




as I said, we may need to implement this logic ourselves is using many 
such topics would not be scalable, but this seems like the kind of 
think a message bus should be good at..



In general, I think it is ideal if these external agents can use
standard mechanisms and formats as much as possible.  For
example, after learning that port X was created, the DHCP agent
can actually use a standard webservice GET to learn about the
configuration of the port (or if people feel that such
information should be included in the notification itself, this
notification data uses the same format as the webservice API).


I am not sure that I agree here. If the service is notifying the
agent then why not have the information being passed in the
message (IP + mac etc.) There is no need for the GET operation.


My general bias here is that if there are now two ways to fetch every 
type of information (one via the standard public interface and 
another via the internal interface with a different implementation) 
that is twice the testing, updating, documenting that we have to do. 
 Perhaps the two problems we're trying to solve are sufficiently 
different that they require two different mechanisms, but in my use 
cases I haven't seen that yet.


This is a tough one. On one hand I agree with you

Re: [Openstack] [Quantum] Scalable agents

[Gary Kotton]

On 07/18/2012 04:23 AM, Dan Wendlandt wrote:



On Mon, Jul 16, 2012 at 3:30 AM, Gary Kotton gkot...@redhat.com 
mailto:gkot...@redhat.com wrote:


Hi,
The patch https://review.openstack.org/#/c/9591/ contains the
initial support for the scalable agents (this is currently
implemented on the linux bridge). At the moment this does not
support a network or port update, that is, the user can set
'admin_status_up' to 0. This means that either the network or the
port should stop handling traffic.
The network/port update is challenging in a number of respects.
First and foremost the quantum plugin is not aware of the agent on
which the port may have been allocated (this is where the VM has
been deployed). In addition to this there may be a number of
agents running.
There are a number of options to perform the port update. They are
listed below:
1. Make use of the openstack-common notifier support. This would
have the plugin notify all of the agents. I have yet to look at
the code but guess that it is similar to the next item.
2. Make use of the RPC mechanism to have the plugin notify the
agents. At the moment the plugin has the topic of all of the
agents (this is used for a health check to ensure that the
configuration on the agent is in sync with that of the plugin). It
is described in detail in

https://docs.google.com/document/d/1MbcBA2Os4b98ybdgAw2qe_68R1NG6KMh8zdZKgOlpvg/edit?pli=1

If I understand correctly then both of the above would require
that the agents are also RPC consumers. In both of the above the
when there is a update to either a network or port then there will
be a lot of traffic broadcast on the network.


Hi Gary,

Yes, I think either way, to eliminate the polling, we need to have 
some mechanism to inform the agents that they need to update state. 
 My goal would be to build a standard mechanism for this that to the 
degree possible leverages existing APIs and data formats, so that we 
can avoid having multiple formats for the same data and avoid any 
RPC-call sprawl.


I agree with you wholeheartedly here. In my opinion this is what I have 
started with the RPC inclusion and initial support. At the moment this 
lacks the update from the service side (which essentially is what this 
mail is about :))




I agree that we don't want to broadcast all data everyone.  At the 
same time, I'd like to avoid having to make the the core plugin code 
running within quantum-server be aware of all of the different agents. 
 What I think would be idea is that we have a fine-grained 
notification mechanism for when objects (networks, subnets, ports) are 
updated, and that agents could choose to register for updates on 
particular objects.


This is along the sames lines that I was thinking. In the current 
implementation the agent connects to the service to sync with the 
configuration. I was thinking of having the agent publicize it what 
information it would like to receive, for example:
- quantum agent - needs port and network updates (port creation and 
deletion are treated in the current implementation)

- dhcp-agent - port creation, deletion and updates
- firewall agent - ...

When the service performs an operation and one of the agents supports 
the operation type then that agent should be updated. These are not 
real time opertaions and for the first phase we can use the broadcast 
mechnism. I do think that we should optimize for very large scale 
environments.


For example, a DHCP agent handling all DHCP for a deployment might 
register for create/update/delete operations on subnets + ports, 
whereas a plugin agent might only register for updates from the ports 
that it sees locally on the hypervisor.  Conceptually, you could think 
of there being a 'topic' per port in this case, though we may need to 
implement it differently in practice.


The agent ID is currently stored in the database (this is for the 
configuration sync mechanism). I think that adding an extra column 
indicating the capabilities enables the service to notify the agents. 
The issue is how refined can the updates be - we want to ensure that we 
have a scalable architecture.




In general, I think it is ideal if these external agents can use 
standard mechanisms and formats as much as possible.  For example, 
after learning that port X was created, the DHCP agent can actually 
use a standard webservice GET to learn about the configuration of the 
port (or if people feel that such information should be included in 
the notification itself, this notification data uses the same format 
as the webservice API).


I am not sure that I agree here. If the service is notifying the agent 
then why not have the information being passed in the message (IP + mac 
etc.) There is no need for the GET operation.




So in sum, I'm hoping that we can take an approach to this problem 
that build a base framework

Re: [Openstack] [Quantum] Network, Subnet and Port names

[Gary Kotton]

On 07/17/2012 10:39 AM, Salvatore Orlando wrote:
I don't think either of you is wrong. I too think that in cases where 
it's not easy to find a majority, it might make sense to just do what 
the other projects are doing.
Unfortunately for us, Keystone adopts the name is unique phylosophy, 
whereas nova adopts name is a label.


Is it worth considering renaming the attribute to 'name-label' and let 
it be non-unique and non-mandatory?


This works for me.


Salvatore

On 16 July 2012 22:27, Dan Wendlandt d...@nicira.com 
mailto:d...@nicira.com wrote:


Hi Gary, this is an example of when I wish openstack APIs had a
style-guide to try to ensure some consistency across projects.

For those new to the conversation, the original topic of
discussion is whether names for API objects should be forced to
be unique (presumably within a tenant?) or allowed to be
duplicated.  The general feeling from the meeting was that since
UUIDs are unique, the API itself would not enforce name
uniqueness.  That also led to the point that names should then be
optional, since they are really for informational/display purposes
only.

Personally, I tend to think that description tends to imply a
sentence private network for tenant1, rather than a simple name
tenant1-net.  There's also the fact that other openstack
services like nova and glance use the term name with the similar
(I believe) model that a name need not be unique.

Would be curious to hear what others think.  The only thing I'm
quite sure about is that there would be value in creating some
notion of openstack API consistency best practices to give a
more cohesive feel to APIs across different projects in the
openstack family.

Dan


On Mon, Jul 16, 2012 at 10:05 PM, Gary Kotton gkot...@redhat.com
mailto:gkot...@redhat.com wrote:

Hi,
If the name is intended to be a description then how about the
idea of calling the field description instead. This is far
more descriptive and does not lend the user to think that this
should be unique.
Thanks
Gary

___
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




-- 
~~~

Dan Wendlandt
Nicira, Inc: www.nicira.com http://www.nicira.com
twitter: danwendlandt
~~~


___
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] [Quantum] Scalable agents

[Gary Kotton]

Hi,
The patch https://review.openstack.org/#/c/9591/ contains the initial 
support for the scalable agents (this is currently implemented on the 
linux bridge). At the moment this does not support a network or port 
update, that is, the user can set 'admin_status_up' to 0. This means 
that either the network or the port should stop handling traffic.
The network/port update is challenging in a number of respects. First 
and foremost the quantum plugin is not aware of the agent on which the 
port may have been allocated (this is where the VM has been deployed). 
In addition to this there may be a number of agents running.
There are a number of options to perform the port update. They are 
listed below:
1. Make use of the openstack-common notifier support. This would have 
the plugin notify all of the agents. I have yet to look at the code 
but guess that it is similar to the next item.
2. Make use of the RPC mechanism to have the plugin notify the agents. 
At the moment the plugin has the topic of all of the agents (this is 
used for a health check to ensure that the configuration on the agent is 
in sync with that of the plugin). It is described in detail in 
https://docs.google.com/document/d/1MbcBA2Os4b98ybdgAw2qe_68R1NG6KMh8zdZKgOlpvg/edit?pli=1


If I understand correctly then both of the above would require that the 
agents are also RPC consumers. In both of the above the when there is a 
update to either a network or port then there will be a lot of traffic 
broadcast on the network.


Another alternative is to piggy back onto the health check message. This 
will contain the ID's of the networks/ports that were updated prior to 
the last check. When an agent receives these, if they are using the the 
network or port then they will request the details from the plugin. This 
will certainly have less traffic on the network.


If anyone has any ideas then it would be great to hear them.
Hopefully we can discuss this in tonight's meeting.
Thanks
Gary


___
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] [Quantum] Network, Subnet and Port names

[Gary Kotton]

Hi,
If the name is intended to be a description then how about the idea of 
calling the field description instead. This is far more descriptive 
and does not lend the user to think that this should be unique.

Thanks
Gary

___
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] Fwd: [Quantum] Public Network spec proposal

[Gary Kotton]

On 07/12/2012 06:39 PM, Salvatore Orlando wrote:

Thank you again for your feedback.

On the discussion about two or three-way logic, I understand Yong's 
point of being able to fetch public and private networks in one call, 
but I also I agree with Endre that using a boolean flag for something 
which is actually Yes/No/Whatever sounds confusing and is different by 
what the Openstack CLI usually does.


Hence, if we have a large agreement on the need of being able to 
specify whether we want public networks, private networks or both, I'd 
go for the approach #3 in the design proposal, as suggested by Gary, 
and the CLI option would became something like 
--network_type={public|private|both}.


On the agent issue raised by Gary - I'm afraid I don't understand. 
Gary, could you please elaborate more?


The current implementation of the open source agents makes use of one 
network interface with the network isolation being done by vlan tagging. 
It may be required that a agent can connect to a public non secure 
network and a private secure network. The first layer of network 
isolation may be done by the physical network interfaces. The API that 
you are proposing enables the quantum service to provide the support, 
but what about the agents? Will the agents be able to differentiate 
between a private and public network. Taking this further will the 
agents be able to assign these networks to different network interfaces. 
Maybe it is not in the scope of the work that you are proposing.


Thanks
Gary




Regards,
Salvatore

On 12 July 2012 05:37, Yong Sheng Gong gong...@cn.ibm.com 
mailto:gong...@cn.ibm.com wrote:



If we just use one flag, it can represent just two values True or
False. If we want to represent three values True, False or not
specified, we have to use --public True or --public False or
nothing at all.

So it is a three-values logic.


-openstack-bounces+gongysh=cn.ibm@lists.launchpad.net
mailto:cn.ibm@lists.launchpad.net wrote: -
To: openstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net
From: Endre Karlson
Sent by: openstack-bounces+gongysh=cn.ibm@lists.launchpad.net
mailto:openstack-bounces+gongysh=cn.ibm@lists.launchpad.net
Date: 07/12/2012 07:53PM
Subject: [Openstack] Fwd: [Quantum] Public Network spec proposal


Why not just --public or not ? Why do you need --public True ?
That just adds confusion...

Endre.


2012/7/12 Gary Kotton gkot...@redhat.com mailto:gkot...@redhat.com

Hi,
1. Is this also applicable to the agents? Say for example a
user wants to ensure that a public network is attached to
network interface em1 and the private network attached to em2.
Is this something that will be addressed by the blueprint?
2. I prefer option #3. This seems to be a cleaner approach for
the user interface.
Thanks
Gary


On 07/12/2012 01:52 AM, Salvatore Orlando wrote:

Hi,

A proposal for the implementation of the public networks
feature has been published.
It can be reached from the quantum-v2-public-networks
blueprint page [1].
Feedback is more than welcome!

Regards,
Salvatore

[1]:

https://blueprints.launchpad.net/quantum/+spec/quantum-v2-public-networks


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

Re: [Openstack] [Quantum] Public Network spec proposal

[Gary Kotton]

Hi,
1. Is this also applicable to the agents? Say for example a user wants 
to ensure that a public network is attached to network interface em1 and 
the private network attached to em2. Is this something that will be 
addressed by the blueprint?
2. I prefer option #3. This seems to be a cleaner approach for the user 
interface.

Thanks
Gary

On 07/12/2012 01:52 AM, Salvatore Orlando wrote:

Hi,

A proposal for the implementation of the public networks feature has 
been published.

It can be reached from the quantum-v2-public-networks blueprint page [1].
Feedback is more than welcome!

Regards,
Salvatore

[1]: 
https://blueprints.launchpad.net/quantum/+spec/quantum-v2-public-networks



___
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] Fwd: Re: [Quantum] Public Network spec proposal

[Gary Kotton]

Fowarding to the list

 Original Message 
Subject:Re: [Openstack] [Quantum] Public Network spec proposal
Date:   Thu, 12 Jul 2012 13:47:13 +0200
From:   Endre Karlson endre.karl...@gmail.com
To: gkot...@redhat.com



Why not just --public or not ? Why do you need --public True ? That just 
adds confusion...


Endre.

2012/7/12 Gary Kotton gkot...@redhat.com mailto:gkot...@redhat.com

   Hi,
   1. Is this also applicable to the agents? Say for example a user
   wants to ensure that a public network is attached to network
   interface em1 and the private network attached to em2. Is this
   something that will be addressed by the blueprint?
   2. I prefer option #3. This seems to be a cleaner approach for the
   user interface.
   Thanks
   Gary


   On 07/12/2012 01:52 AM, Salvatore Orlando wrote:

Hi,

A proposal for the implementation of the public networks feature
has been published.
It can be reached from the quantum-v2-public-networks blueprint
page [1].
Feedback is more than welcome!

Regards,
Salvatore

[1]:
https://blueprints.launchpad.net/quantum/+spec/quantum-v2-public-networks


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

[Gary Kotton]

Hi,
Anyone having problems with gerrit?
Thanks
Gary

___
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] [Quantum] Stable Essex Version

[Gary Kotton]

Hi,
Following the Quantum IRC meeting last night below is an update of the 
stable essex additions:


Cherry picks approved and integrated:
https://github.com/openstack/quantum/commit/b226e0c7e91e7089286e0977f7e0f185afe2964f
https://github.com/openstack/quantum/commit/ba72f9c7358850e8d4c5339c329094f08eb0204d
https://github.com/openstack/quantum/commit/718c6f1c2981496a715881772185ce9486df23a1
https://github.com/openstack/quantum/commit/2dc269cb170bcb88f0727b01877bcef74fecddc3
https://github.com/openstack/quantum/commit/3b52fd3cba48b1ff95d514937c0fdcbc7c53add7
https://github.com/openstack/quantum/commit/18c043c0ae73a915946a770eda2a4b88877b4ede
https://github.com/openstack/quantum/commit/e54bc743a8e38bf845fd8144c6ea757311cff1f2
https://github.com/openstack/quantum/commit/217434c60c0f5e263cebec7526eac25c5ae97c48
https://github.com/openstack/quantum/commit/7906def09dfbd32d190e6a33d8102b5b560511cd
https://github.com/openstack/quantum/commit/44e85a6aa6465d02fea10514e15cceffcd030723

Cherry picks pending approval:
https://review.openstack.org/#/c/8650/

Cherry picks queued for stable essex integration:
https://github.com/openstack/quantum/commit/438eda895c7e24113f116e503f36930c176ebe4d

If there are any other fixes that you think should be added then please 
let me know. Any input on how we can create a tarball with the above 
will be great.


Thanks in advance
Gary

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

[Openstack] [Openstack-Common] RPC

[Gary Kotton]

Hi,
I am in the process of integrating the RPC code from OpenStack common 
into Quantum. I initially started working with qpid as the backend 
implementation. I ran into problems due to the fact that 
control_exchange is defined as 'nova'. This is in 
quantum/openstack/common/rpc/__init__.py where the following is defined.

cfg.StrOpt('control_exchange',
   default='nova',
   help='AMQP exchange to connect to if using RabbitMQ or 
Qpid'),
When I changed this to 'quantum' it worked. My topic was defined as 
'quantum'.


In addition to this I have a few additional questions and or concerns:
1. When we import code from openstack common the test cases for the 
modules are not imported (maybe I missed something with running setup). 
When the code is copied the imports are updated. It would be nice to 
know that the auto tests are also run in the context of the project 
importing the code.
2. I based my integration on the patch 
https://review.openstack.org/#/c/9166/. A number of files were missing. 
Should this have specifically mentioned the missing files or should the 
rpc part have taken care of this?


Thanks
Gary


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

Re: [Openstack] [Openstack-Common] RPC

[Gary Kotton]

On 07/10/2012 06:29 PM, Eric Windisch wrote:

In addition to this I have a few additional questions and or concerns:
1. When we import code from openstack common the test cases for the
modules are not imported (maybe I missed something with running setup).
When the code is copied the imports are updated. It would be nice to
know that the auto tests are also run in the context of the project
importing the code.


As Russell said, the tests inside common are intended to ensure independent 
functionality of the features within common. There should be tests in your own 
project that test your project's use of RPC. There has been some discussion on 
having integration tests for common test official openstack projects for 
compatibility/breakages.

You might also want to look at and contribute to the thread best practices for 
merging common into specific projects.

2. I based my integration on the patch
https://review.openstack.org/#/c/9166/. A number of files were missing.
Should this have specifically mentioned the missing files or should the
rpc part have taken care of this?


Are you concerned that the RPC module itself has dependencies on 
openstack-common which are not being automatically resolved and included when 
you run update.py?


Thanks, I was reviewing a patch that did the update. There were some 
files missing. I'll try and check.

Thanks
Gary

Regards,
Eric Windisch




___
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] [common] Common config and Quantum configuration files

[Gary Kotton]

Hi,
In Quantum we make use of a number of different configuration files. A 
quantum plugin may have one or more configuration files. An example of 
the configuration files is below.

/etc/quantum/quantum.conf
/etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini
When the quantum service starts it creates and populates cfg.CONF from 
the configuration file. At a later point in the flow the plugin is 
detected and started. This in turn requires that the plugin 
configuration be read. In addition to this the quantum agent also makes 
use of the plugin configuration file (this is a separate process). In 
order for Quantum to make use of openstack common code, for example the 
RPC module, the plugin information needs to be read into the cfg.CONF 
structure on the service.


Originally I implemented the code below. This was invoked on the plugin 
(would append to the existing structure) and the agent (would create a 
new structure).


defparse(config_file):
conf =cfg.CONF
if'default_config_files'inconf:
conf.default_config_files.append(config_file)
else:
   conf.default_config_files=[config_file]
conf(args=[],default_config_files=conf.default_config_files)

This code is problematic in the sense that if the plugin configuration 
overrides a entry in the quantum.conf (for example log file).


The ideal solution would be to have one common configuration file. The 
problem is that this is not really suited to the Quantum model and the 
consensus of the community is to continue with the separate files.


Done anyone have an elegant and fail safe way to append a configuration 
file?


Any ideas will be greatly appreciated.
Thanks
Gary

___
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] Jenkins failure

[Gary Kotton]

Hi,
Does anyone know what can cause the failure below:

Started by userOpenStack Hudson  
https://jenkins.openstack.org/user/hudson-openstack
[EnvInject] - Preparing an environment for the build.
Building remotely onprecise6  https://jenkins.openstack.org/computer/precise6 
 in workspace /home/jenkins/workspace/gate-quantum-merge
[gate-quantum-merge] $ /bin/bash -xe /tmp/hudson8164016237338935417.sh
+ /usr/local/jenkins/slave_scripts/gerrit-git-prep.sh review.openstack.org
Triggered by:https://review.openstack.org/9203
+ [[ ! -e .git ]]
+ git remote update
Fetching origin
+ git reset --hard
HEAD is now at c18822a OVS plugin support for v2 Quantum API
+ git clean -x -f -d -q
+ '[' -z '' ']'
+ git checkout master
Already on 'master'
Your branch is ahead of 'origin/master' by 1 commit.
+ git reset --hard remotes/origin/master
HEAD is now at 4ac3207 Cisco's unplug_iface refers to non existing exception
+ git clean -x -f -d -q
+ '[' '!' -z '' ']'
+ merge_changes
+ set +x
+ merge_change openstack/quantum refs/changes/03/9203/1
+ PROJECT=openstack/quantum
+ REFSPEC=refs/changes/03/9203/1
+ git fetchhttps://review.openstack.org/p/openstack/quantum  
refs/changes/03/9203/1
error: The requested URL returned error: 403 while 
accessinghttps://review.openstack.org/p/openstack/quantum/info/refs
fatal: HTTP request failed
Build step 'Execute shell' marked build as failure
Notifying upstream projects of job completion
Finished: FAILURE


Thanks in advance
Gary
___
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] Jenkins/Gerrit

[Gary Kotton]

Hi,
Anyone encountered any problems. When I try to access the server 
(https://review.openstack.org/) I get:



 Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request /GET / 
https://review.openstack.org//.


Reason: *Error reading from remote server*


Apache/2.2.20 (Ubuntu) Server at review.openstack.org Port 443

Thanks
Gary


___
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] Review email notifications

[Gary Kotton]

Hi,
It seems that this has stopped working today. Any ideas?
Thanks
Gary

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

[Gary Kotton]

Hi,
Is anyone aware of a problem with Jenkins?
Thanks
Gary

___
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] [devstack] Quantum support

[Gary Kotton]

Hi,
Quantum has moved to openstack common configuration (the plugin.ini file 
no longer exists). Support has been added to devstack to ensure that 
quantum and devstack will work irrespective of the version running. 
Would it be possible to review this so that we can move forward with the 
approval of the common config task. https://review.openstack.org/#/c/8176/

Thanks in advance
Gary

___
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] Quantum integration with Horizon

[Gary Kotton]

On 06/07/2012 11:39 AM, Neelakantam Gaddam wrote:


Hi All,

Currently, I don't see any Quantum UI in Horizon in Essex. Does the 
Horizon support Quantum UI in the current release? If so, please share 
the configuration steps. If not, When can I expect the Quantum UI 
integration with Horizon ?
This is not supported for Essex. There is a blueprint for Folsom-2 for 
horizon support 
(https://blueprints.launchpad.net/quantum/+spec/quantum-horizon).


Can you please give me the list of features for the next release of 
Essex and the timelines.?
Please look at https://launchpad.net/quantum/folsom for the release 
dates of Folsom (this is the version after Essex). We are currently 
porting back bug fixes from Folsom-1 to the stable Essex version. This 
may take some time.

Thanks
Gary


--
Thanks  Regards
Neelakantam Gaddam


___
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] quantumclient=2012.1

[Gary Kotton]

Hi Monty and Dan,
Background: A short while ago I started to port bug fixes for Quantum 
from Folsom-1 to Stable Essex. Jenkins did not accept the patches due to 
the fact that the automatic tests did not pass. The failures are due to 
2 reasons:

1. pep8 checks (addressed in the tox.ini)
2. missing files for automatic tests
A fix for this issue was proposed - 
https://review.openstack.org/#/c/8023. Mark McLoughlin rightly pointed 
out that the fix was risky by adding a considerable amount of code and 
suggested adding quantumclient==2012.1 to the pip-requires. The problem 
with this is that the quantumclient does not exist in pypi 
(http://pypi.python.org/pypi/python-quantumclient).

How do you suggest that we proceed?
Thanks
Gary


___
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] quantumclient=2012.1

[Gary Kotton]

On 06/05/2012 04:29 PM, Monty Taylor wrote:

On 06/05/2012 07:54 AM, Gary Kotton wrote:

Hi Monty and Dan,
Background: A short while ago I started to port bug fixes for Quantum
from Folsom-1 to Stable Essex. Jenkins did not accept the patches due to
the fact that the automatic tests did not pass. The failures are due to
2 reasons:
1. pep8 checks (addressed in the tox.ini)
2. missing files for automatic tests
A fix for this issue was proposed -
https://review.openstack.org/#/c/8023. Mark McLoughlin rightly pointed
out that the fix was risky by adding a considerable amount of code and
suggested adding quantumclient==2012.1 to the pip-requires. The problem
with this is that the quantumclient does not exist in pypi
(http://pypi.python.org/pypi/python-quantumclient).
How do you suggest that we proceed?

For now, add:

https://github.com/openstack/python-quantumclient/zipball/2012.1#egg=python-quantumclient

Thanks! I'll let you know if it works.

to the quantum stable/essex pip-requires

We're really close to figuring out the client lib upload issue overall
(there are about 100 requirement from about 100 different people - but I
think we've almost got it sorted) but until we can get it done properly,
just do the github zipball bit.



___
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] cfg usage - option registration, global objects

[Gary Kotton]

On 06/01/2012 12:47 AM, Russell Bryant wrote:

On 05/31/2012 04:21 PM, Mark McLoughlin wrote:

I expect to do a pretty detailed review of the patch to add rpc to
openstack-common and make some API design recommendations. But I think
we'll have to balance some of those design ideas between stuff we
really should fix before it goes into openstack-common vs stuff that
would need to be fixed before the API comes out of incubation.

  I've been pushing the code with a goal that the submission to
openstack-common is *only* a matter of changing the imports.  Up to this
point, it has mostly been a matter of removing dependencies on other
parts of nova.  We are actually at that point now ... unless there are
other changes that are going to block it.

I'd rather just work on improvements people would like to see while the
code is in incubation in openstack-common.  People are already copying
it (in a feature branch for Quantum, Cinder, the Heat project, at
least), so moving it as is will leave us in a better spot than we are now.
I agree with Russell. On the Quantum side we are waiting for the code so 
that we can move ahead with a number of blueprints. I understand that 
there is also a solution for versioning.

Thanks
Gary

___
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] Instance Networking Issue

[Gary Kotton]

On 05/16/2012 12:24 AM, Salman Malik wrote:

Hi Guys,

I am having trouble with launching instances. The launch fails on 
networking task with status error. Here is the output (at nova-compute 
screen session) on launching instance :


2012-05-02 06:41:52 TRACE nova.rpc.amqp RemoteError: Remote error: 
QuantumNotFoundException (u'Quantum entity not found: %s', 
'{QuantumError: {message: Unable to find a network with the 
specified identifier., type: NetworkNotFound, detail: Network 
5f227bba-eb3b-4dba-ad4c-b47c80aaffd7 could not be found}}')



Here is the output when I terminated the instance:
2012-05-02 06:44:04 TRACE nova.rpc.amqp Command: sudo 
/usr/local/bin/nova-rootwrap ovs-vsctl get Interface tap772ad8ff-89 ofport

2012-05-02 06:44:04 TRACE nova.rpc.amqp Exit code: 1
2012-05-02 06:44:04 TRACE nova.rpc.amqp Stdout: ''
2012-05-02 06:44:04 TRACE nova.rpc.amqp Stderr: 'ovs-vsctl: no row 
tap772ad8ff-89 in table Interface\n'



Question/Problems:

1. Network with uuid 5f227bba-eb3b-4dba-ad4c-b47c80aaffd7 is not a 
Quantum network (or may be its a quantum network but it doesn't belong 
to any tenant) . This network got created automatically when I ran 
stack.sh script and is associated with the fixed_range=10.0.0.0/24 in 
the nova.conf file. So problem here is that I wanted to launch this 
instance on a quantum network managed by a tenant/use (that I created 
before launching instance), how can I fix this?
Did you update the stackrc file to include quantum? When you run 
stack.sh it should reset the relevant databases.


2. Before running stack.sh, I could see gw-** port in my br-int 
bridge. Now it doesn't show up anywhere. Can you tell me what is the 
purpose of this port and how can I get it back in my br-int ?


3. Would answer to 1 and 2 help in succesful launch of instances ? If 
not, what else do I need to do ?



Thanks,
Salman


___
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] [devstack/quantum] Configuration issue

[Gary Kotton]

Hi,
This morning I encountered a problem (which did not happen a few days 
ago :)). When devstack is launched, with quantum configured, the gateway 
and bridge devices are created. This causes problems with quantum.


For example when devstack is up and running prior to deploying an 
instance we have:


brq744ec2f4-c0 Link encap:Ethernet  HWaddr fa:16:3e:03:a6:55
  inet addr:10.0.0.1  Bcast:0.0.0.0  Mask:255.255.255.0
  UP BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

gw-744ec2f4-c0 Link encap:Ethernet  HWaddr fa:16:3e:03:a6:55
  inet addr:10.0.0.1  Bcast:10.0.0.255  Mask:255.255.255.0
  UP BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:500
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

When an instance is deployed the following happens:

2012-05-15 01:59:18 DEBUG nova.utils 
[req-4d50ed10-46e1-406c-9074-dc45da860365 
df07eec326434b25800f3ebc17202fb3 2cafe0be4d7740098a89be39ffd1b72e] 
Running cmd (subprocess): sudo /usr/local/bin/nova-rootwrap ip address 
add 10.0.0.1/24 dev brq744ec2f4-c0 from (pid=4234) execute 
/opt/stack/nova/nova/utils.py:178
2012-05-15 01:59:18 DEBUG nova.utils 
[req-4d50ed10-46e1-406c-9074-dc45da860365 
df07eec326434b25800f3ebc17202fb3 2cafe0be4d7740098a89be39ffd1b72e] 
Result was 254 from (pid=4234) execute /opt/stack/nova/nova/utils.py:194
2012-05-15 01:59:18 ERROR nova.rpc.amqp 
[req-4d50ed10-46e1-406c-9074-dc45da860365 
df07eec326434b25800f3ebc17202fb3 2cafe0be4d7740098a89be39ffd1b72e] 
Exception during message handling

2012-05-15 01:59:18 TRACE nova.rpc.amqp Traceback (most recent call last):
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File 
/opt/stack/nova/nova/rpc/amqp.py, line 263, in _process_data
2012-05-15 01:59:18 TRACE nova.rpc.amqp rval = 
node_func(context=ctxt, **node_args)
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File 
/opt/stack/nova/nova/network/quantum/manager.py, line 390, in 
allocate_for_instance
2012-05-15 01:59:18 TRACE nova.rpc.amqp network, vif_rec, 
network['net_tenant_id'])
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File 
/opt/stack/nova/nova/utils.py, line 880, in inner

2012-05-15 01:59:18 TRACE nova.rpc.amqp retval = f(*args, **kwargs)
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File 
/opt/stack/nova/nova/network/quantum/manager.py, line 501, in enable_dhcp
2012-05-15 01:59:18 TRACE nova.rpc.amqp 
self.l3driver.initialize_gateway(network_ref)
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File 
/opt/stack/nova/nova/network/l3.py, line 98, in initialize_gateway
2012-05-15 01:59:18 TRACE nova.rpc.amqp 
gateway=(network_ref['gateway'] is not None))
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File 
/opt/stack/nova/nova/network/linux_net.py, line 900, in plug
2012-05-15 01:59:18 TRACE nova.rpc.amqp return 
_get_interface_driver().plug(network, mac_address, gateway)
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File 
/opt/stack/nova/nova/network/linux_net.py, line 1160, in plug

2012-05-15 01:59:18 TRACE nova.rpc.amqp run_as_root=True)
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File 
/opt/stack/nova/nova/utils.py, line 201, in execute

2012-05-15 01:59:18 TRACE nova.rpc.amqp cmd=' '.join(cmd))
2012-05-15 01:59:18 TRACE nova.rpc.amqp ProcessExecutionError: 
Unexpected error while running command.
2012-05-15 01:59:18 TRACE nova.rpc.amqp Command: sudo 
/usr/local/bin/nova-rootwrap ip address add 10.0.0.1/24 dev brq744ec2f4-c0

2012-05-15 01:59:18 TRACE nova.rpc.amqp Exit code: 254
2012-05-15 01:59:18 TRACE nova.rpc.amqp Stdout: ''
2012-05-15 01:59:18 TRACE nova.rpc.amqp Stderr: 'RTNETLINK answers: File 
exists\n'

2012-05-15 01:59:18 TRACE nova.rpc.amqp
2012-05-15 01:59:18 ERROR nova.rpc.common 
[req-4d50ed10-46e1-406c-9074-dc45da860365 
df07eec326434b25800f3ebc17202fb3 2cafe0be4d7740098a89be39ffd1b72e] 
Returning exception Unexpected error while running command.
Command: sudo /usr/local/bin/nova-rootwrap ip address add 10.0.0.1/24 
dev brq744ec2f4-c0

Exit code: 254
Stdout: ''
Stderr: 'RTNETLINK answers: File exists\n' to caller
2012-05-15 01:59:18 ERROR nova.rpc.common 
[req-4d50ed10-46e1-406c-9074-dc45da860365 
df07eec326434b25800f3ebc17202fb3 2cafe0be4d7740098a89be39ffd1b72e] 
['Traceback (most recent call last):\n', '  File 
/opt/stack/nova/nova/rpc/amqp.py, line 263, in _process_data\nrval 
= node_func(context=ctxt, **node_args)\n', '  File 
/opt/stack/nova/nova/network/quantum/manager.py, line 390, in 
allocate_for_instance\nnetwork, vif_rec, 
network[\'net_tenant_id\'])\n', '  File /opt/stack/nova/nova/utils.py, 
line 880, in inner\nretval = f(*args, **kwargs)\n', '  File 
/opt/stack/nova/nova/network/quantum/manager.py, line 501, in 

Re: [Openstack] [devstack/quantum] Configuration issue

[Gary Kotton]

Hi,
Thanks. The Quantum DB is empty. The script for devstack ensures that it 
is clean prior to running.

Thanks
Gary

On 05/15/2012 09:46 AM, Edgar Magana (eperdomo) wrote:

BTW. I also restart the network service to be sure that any previous
configuration is completely removed.

Edgar

-Original Message-
From: openstack-bounces+eperdomo=cisco@lists.launchpad.net
[mailto:openstack-bounces+eperdomo=cisco@lists.launchpad.net] On
Behalf Of Gary Kotton
Sent: Monday, May 14, 2012 11:01 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] [devstack/quantum] Configuration issue

Hi,
This morning I encountered a problem (which did not happen a few days
ago :)). When devstack is launched, with quantum configured, the gateway

and bridge devices are created. This causes problems with quantum.

For example when devstack is up and running prior to deploying an
instance we have:

brq744ec2f4-c0 Link encap:Ethernet  HWaddr fa:16:3e:03:a6:55
inet addr:10.0.0.1  Bcast:0.0.0.0  Mask:255.255.255.0
UP BROADCAST MULTICAST  MTU:1500  Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

gw-744ec2f4-c0 Link encap:Ethernet  HWaddr fa:16:3e:03:a6:55
inet addr:10.0.0.1  Bcast:10.0.0.255  Mask:255.255.255.0
UP BROADCAST MULTICAST  MTU:1500  Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

When an instance is deployed the following happens:

2012-05-15 01:59:18 DEBUG nova.utils
[req-4d50ed10-46e1-406c-9074-dc45da860365
df07eec326434b25800f3ebc17202fb3 2cafe0be4d7740098a89be39ffd1b72e]
Running cmd (subprocess): sudo /usr/local/bin/nova-rootwrap ip address
add 10.0.0.1/24 dev brq744ec2f4-c0 from (pid=4234) execute
/opt/stack/nova/nova/utils.py:178
2012-05-15 01:59:18 DEBUG nova.utils
[req-4d50ed10-46e1-406c-9074-dc45da860365
df07eec326434b25800f3ebc17202fb3 2cafe0be4d7740098a89be39ffd1b72e]
Result was 254 from (pid=4234) execute /opt/stack/nova/nova/utils.py:194
2012-05-15 01:59:18 ERROR nova.rpc.amqp
[req-4d50ed10-46e1-406c-9074-dc45da860365
df07eec326434b25800f3ebc17202fb3 2cafe0be4d7740098a89be39ffd1b72e]
Exception during message handling
2012-05-15 01:59:18 TRACE nova.rpc.amqp Traceback (most recent call
last):
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File
/opt/stack/nova/nova/rpc/amqp.py, line 263, in _process_data
2012-05-15 01:59:18 TRACE nova.rpc.amqp rval =
node_func(context=ctxt, **node_args)
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File
/opt/stack/nova/nova/network/quantum/manager.py, line 390, in
allocate_for_instance
2012-05-15 01:59:18 TRACE nova.rpc.amqp network, vif_rec,
network['net_tenant_id'])
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File
/opt/stack/nova/nova/utils.py, line 880, in inner
2012-05-15 01:59:18 TRACE nova.rpc.amqp retval = f(*args, **kwargs)
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File
/opt/stack/nova/nova/network/quantum/manager.py, line 501, in
enable_dhcp
2012-05-15 01:59:18 TRACE nova.rpc.amqp
self.l3driver.initialize_gateway(network_ref)
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File
/opt/stack/nova/nova/network/l3.py, line 98, in initialize_gateway
2012-05-15 01:59:18 TRACE nova.rpc.amqp
gateway=(network_ref['gateway'] is not None))
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File
/opt/stack/nova/nova/network/linux_net.py, line 900, in plug
2012-05-15 01:59:18 TRACE nova.rpc.amqp return
_get_interface_driver().plug(network, mac_address, gateway)
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File
/opt/stack/nova/nova/network/linux_net.py, line 1160, in plug
2012-05-15 01:59:18 TRACE nova.rpc.amqp run_as_root=True)
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File
/opt/stack/nova/nova/utils.py, line 201, in execute
2012-05-15 01:59:18 TRACE nova.rpc.amqp cmd=' '.join(cmd))
2012-05-15 01:59:18 TRACE nova.rpc.amqp ProcessExecutionError:
Unexpected error while running command.
2012-05-15 01:59:18 TRACE nova.rpc.amqp Command: sudo
/usr/local/bin/nova-rootwrap ip address add 10.0.0.1/24 dev
brq744ec2f4-c0
2012-05-15 01:59:18 TRACE nova.rpc.amqp Exit code: 254
2012-05-15 01:59:18 TRACE nova.rpc.amqp Stdout: ''
2012-05-15 01:59:18 TRACE nova.rpc.amqp Stderr: 'RTNETLINK answers: File

exists\n'
2012-05-15 01:59:18 TRACE nova.rpc.amqp
2012-05-15 01:59:18 ERROR nova.rpc.common
[req-4d50ed10-46e1-406c-9074-dc45da860365
df07eec326434b25800f3ebc17202fb3 2cafe0be4d7740098a89be39ffd1b72e]
Returning exception Unexpected error while running command.
Command: sudo /usr/local/bin/nova-rootwrap ip address add 10.0.0.1/24
dev brq744ec2f4-c0
Exit code: 254
Stdout: ''
Stderr: 'RTNETLINK answers: File exists\n' to caller
2012-05-15 01:59:18 ERROR nova.rpc.common
[req-4d50ed10-46e1-406c

[Openstack] [devstack] Quantum support

[Gary Kotton]

Hi,
https://review.openstack.org/#/c/7169/ ensures that all of the open 
source agents have uniform database access. This requires a minor change 
to the devstack code.
In addition to this I have added in some minor chnages which ensure that 
the devstack user is able to run Quantum Plugins and agents on separate 
hosts. The original code would not work if they were on different hosts 
- both need to access the data connection. This is addressed in 
https://review.openstack.org/7300.

Can someone please review.
Thanks
Gary

___
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] Install Your Own OpenStack Cloud - Essex Edition

[Gary Kotton]

Hi,
Great document. Would it be possible to add in other flavours of Linux 
that support Open Stack?

Thanks
Gary

On 05/07/2012 03:23 PM, Eric Dodemont wrote:
I have written a 50 pages document: Install Your Own OpenStack Cloud 
- Essex Edition.


The PDF file can be downloaded here: http://tiny.cc/qstxdw

In the document, I describe in detail the installation, configuration 
and use of my OpenStack cloud. I try to not use scripts to show 
clearly all the steps to follow.


Installation is made on two physical servers and explanations are 
given to add more compute nodes.


I added a lot of information, especially about the VLAN networking mode.

Software Versions:

- Operating System: Linux Ubuntu Server version 12.04 (Precise), 64 bits.
- Cloud Computing: OpenStack version 2012.1 (Essex) including Nova, 
Glance, Keystone, and Horizon.


Best regards,

Eric

___
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] Proposal for new devstack (v2?)

[Gary Kotton]

Brilliant!

 

From: openstack-bounces+garyk=radware@lists.launchpad.net
[mailto:openstack-bounces+garyk=radware@lists.launchpad.net] On
Behalf Of Joshua Harlow
Sent: Wednesday, January 18, 2012 9:21 PM
To: Mark McLoughlin
Cc: Andy Smith; openstack
Subject: Re: [Openstack] Proposal for new devstack (v2?)

 

Sweet, we are working on getting functionality for rhel and ubuntu up
and going and then hopefully some docs (and code comments) can be added
in so other people can know exactly what is going on (without the
typical go read the code response). But the idea is the following:

Have a set of json files (+ I added the ability to have simple comments)
that specify the needed dependencies + versions (+ other metadata) for
each distribution.

https://github.com/yahoo/Openstack-Devstack2/blob/master/conf/pkgs/gener
al.json

Have those different sections be handled by a class specific to a
distribution (or possibly shared, ie fedora and rhel).

https://github.com/yahoo/Openstack-Devstack2/tree/master/devstack/packag
ing (WIP as we work with the rhel peoples to get the dependencies
flushed out)

Similar with pip installs (if any):

https://github.com/yahoo/Openstack-Devstack2/tree/master/conf/pips

Then this information can be updated as needed  for each release of
openstack (with exact dependencies, y a win for everyone!) so that
this whole pkg process becomes better for everyone.

Of course also we are allowing other types of running besides screen (I
like just having it in the background via a fork with output going to
files...)

That's whats going on so far :-)

Thx,

-Josh

On 1/18/12 3:45 AM, Mark McLoughlin mar...@redhat.com wrote:

On Tue, 2012-01-17 at 11:20 -0800, Joshua Harlow wrote:
 My goals were/are/(may continue to be, haha) the following:
...
  3.  Have the ability to have pkg/pip installation (and definition
 separate from the main code, already starting to be done), in more
 than 1 distro.
 *   This allows others to easily know what versions of packages
 work for a given openstack release for more than one distro (yes
 that's right, more than ubuntu)

Serious kudos to you guys on this part. IMHO, having a devstack that
supports multiple distros is a massive win for OpenStack generally.

Hopefully we can dig in and help with Fedora support soonish

Cheers,
Mark.




___
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] Devstack/Dashboard Issue

[Gary Kotton]

Hi,

When I connect to the dashboard after a devstack installation I get the
following error:

Unable to get service info: This error may be caused by a misconfigured
Nova url in keystone's service catalog, or by missing openstackx
extensions in Nova. See the Horizon README.

A little investigation has provided the following details:

1.   wget -q -O- http://127.0.0.1:8774 returns {versions:
[{status: CURRENT, updated: 2011-01-21T11:33:21Z, id: v2.0,
links: [{href: http://127.0.0.1:8774/v2/;, rel: self}]}]}

2.   A capture on the loopback has the following request - GET
/v1.1/1/admin/services?fresh=1326787272.2 HTTP/1.1 which in turn
receives a HTTP 404.

The devstack scripts have references to v1.1 and the nova has osapi_path
using v1.1

Any idea when and why the version upgraded from 1.1 to 2?

Thanks

Gary

 

___
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] Can't pimg

[Gary Kotton]

Hi,

I too have encountered the problem in the past. Maybe the attached mail
may help.

Thanks

Gary

 

From: openstack-bounces+garyk=radware@lists.launchpad.net
[mailto:openstack-bounces+garyk=radware@lists.launchpad.net] On
Behalf Of Leander Bessa
Sent: Tuesday, January 10, 2012 6:22 PM
To: Brebner, Gavin
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Can't pimg

 

I have already given permissions to ping and ssh.

 

output from euca-describe-group:

GROUP  myprojectdefault default

PERMISSIONmyprojectdefault ALLOWS   tcp   22
22FROM CIDR  0.0.0.0/0

PERMISSIONmyprojectdefault ALLOWS   icmp-1
-1 FROM CIDR  0.0.0.0/0

 

On Tue, Jan 10, 2012 at 4:17 PM, Brebner, Gavin gavin.breb...@hp.com
wrote:

 

In my experience this usually this means you have forgotten to set up a
security group - you need to run euca-authorize / nova secgroup
commands. By default

there is no network access.

 

Gavin

 

From: openstack-bounces+gavin.brebner=hp@lists.launchpad.net
[mailto:openstack-bounces+gavin.brebner
mailto:openstack-bounces%2Bgavin.brebner =hp@lists.launchpad.net]
On Behalf Of Leander Bessa
Sent: Tuesday, January 10, 2012 5:08 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] Can't pimg

 

Hello, 

I'm having trouble accessing the instances that are being launched. I
have two nodes a controller and a compute. They are both running Ubuntu
11.10 (64bits) and using KVM as hypervisor. When i launch an instance, i
can see the instances is launched with the command
euca-describe-instances, however i can neither ping or ssh into it
through the controller node.  I've checked the nova-network and
nova-manage logs and didn't find anything out of the ordinary. I've also
check the libvirt logs in the compute node and can't seem to find
anything wrong with it.

 

Previously i had a single node with qemu and everything worked fine. Now
that i switched to a multi-node environment with KVM things stopped
working. The controller has the ip 192.168.82.24 and the compute
192.168.111.220. Floating range for public IPs is 192.168.111.236-240.

 

Any ideas?

 

The controller the following nova.conf file:

--daemonize=1

--dhcpbridge_flagfile=/etc/nova/nova.conf

--dhcpbridge=/usr/bin/nova-dhcpbridge

--logdir=/var/log/nova

--state_path=/var/lib/nova

--verbose

--libvirt_type=kvm

--sql_connection=mysql://root:nova@192.168.82.24/nova

--s3_host=192.168.82.24

--rabbit_host=192.168.82.24

--ec2_host=192.168.82.24

--ec2_dmz_host=192.168.82.24

--ec2_url=http://192.168.82.24:8773/services/Cloud

--fixed_range=10.1.1.0/24

--network_size=64

--num_networks=1

--FAKE_subdomain=ec2

--public_interface=eth0

--state_path=/var/lib/nova

--lock_path=/var/lock/nova

--glance_host=192.168.82.24

--image_service=nova.image.glance.GlanceImageService

--glance_api_servers=192.168.82.24:9292

--vlan_start=100

--vlan_interface=eth1

--iscsi_ip_prefix=192.168.

 

 

The controller has this config file.

--daemonize=1

--dhcpbridge_flagfile=/etc/nova/nova.conf

--dhcpbridge=/usr/bin/nova-dhcpbridge

--logdir=/var/log/nova

--state_path=/var/lib/nova

--verbose

--libvirt_type=kvm

--sql_connection=mysql://root:nova@192.168.82.24/nova

--s3_host=192.168.82.24

--rabbit_host=192.168.82.24

--ec2_host=192.168.82.24

--ec2_dmz_host=192.168.82.24

--ec2_url=http://192.168.82.24:8773/services/Cloud

--fixed_range=10.1.1.0/24

--network_size=64

--num_networks=1

--FAKE_subdomain=ec2

--public_interface=eth0

--state_path=/var/lib/nova

--lock_path=/var/lock/nova

--glance_host=192.168.82.24

--image_service=nova.image.glance.GlanceImageService

--glance_api_servers=192.168.82.24:9292

--vlan_start=100

--vlan_interface=eth1

 

Regards,


Leander

 

---BeginMessage---
In some cases when everything is on one interface you need to set your main 
bridge to promisc mode to get it to forward properly.

Try:
ip link set promisc on br100

Vish

On Dec 28, 2011, at 2:39 AM, Lucio Cossio wrote:


Hello Guys, I'm testing a dual node installation of OpenStack Nova with Glance, 
and i really hope someone can help me with my current problem.

My setup is like that:
- First Node : All nova components plus Glance
- Second Node : nova-compute

I'm using diablo version  that was installed from the ubuntu repository, which 
i suppose is the nova 2011.3+git2017-0ubuntu1 oneiric version.

For what a read, the second node only needs nova-compute ,but sometimes i see 
others saying about using nova-network together. I'm using machines that have 
just one network interface, so they are in the same network with other 
non-OpenStack computers (this network uses dhcp).
At the network configuration i'm using flatDHCP. The nova.conf file can be see 
here (the ip is not exactly what im using, is just a template): 
http://paste.openstack.org/show/3978/

So, i'm able to install and run virtual machines in both nodes. My problem is, 

Re: [Openstack] [RFC] Common config options module

[Gary Kotton]

Hi,
Will this module sync the configurations between the different nodes in
the system? That is, if the cloud has a number of Compute modules
running. Will the updated configuration on one of them be replicated to
the additional nodes? If so then this is great, if not, would it be
possible to address this?
Thanks
Gary

-Original Message-
From: openstack-bounces+garyk=radware@lists.launchpad.net
[mailto:openstack-bounces+garyk=radware@lists.launchpad.net] On
Behalf Of Vishvananda Ishaya
Sent: Tuesday, December 06, 2011 1:36 AM
To: Mark McLoughlin; John Dickinson
Cc: openstack@lists.launchpad.net (openstack@lists.launchpad.net)
Subject: Re: [Openstack] [RFC] Common config options module

Just read through the description and the code.  I don't have any issues
with the way it is implemented, although others may have some
suggestions/tweaks.  I think it is most important to get the common code
established, so I'm up for implementing you changes in Nova.  I think it
is important to get buy in from Jay and the Glance team ASAP as well.

It would also be great if the Swift team could do a quick review and at
least give us a heads up on whether there are any blockers to moving to
this eventually.  They have a huge install base, so changing their
config files could be significantly more difficult, but it doesn't look
too diffferent from what they are doing.  John, thoughts?

Vish

On Nov 28, 2011, at 7:09 AM, Mark McLoughlin wrote:

 Hey,
 
 I've just posted this blueprint:
 
  https://blueprints.launchpad.net/openstack-common/+spec/common-config
  http://wiki.openstack.org/CommonConfigModule
 
 The idea is to unify option handling across projects with this new
API.
 The module would eventually (soon?) live in openstack-common.
 
 Code and unit tests here:
 
  https://github.com/markmc/nova/blob/common-config/nova/common/cfg.py

https://github.com/markmc/nova/blob/common-config/nova/tests/test_cfg.py
 
 And patches to make both Glance and Nova use it are on the
 'common-config' branches of my github forks:
 
  https://github.com/markmc/nova/commits/common-config
  https://github.com/markmc/glance/commits/common-config
 
 Glance and (especially) Nova still need a bunch of work to be fully
 switched over to the new model, but both trees do actually appear to
 work fine and could be merged now.
 
 Lots of detail in there, but all comments are welcome :)
 
 Thanks,
 Mark.
 
 
 ___
 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