openstack team mailing list archive

[Filipe Manco <filipe.manco@xxxxxxxxx>]

Ok

I'm using the script (I'm calling it from rc.local) and everything works
fine, even for instances that already exist.

Thanks


2013/3/5 Sylvain Bauza <sylvain.bauza@xxxxxxxxxxxx>

>  This is up to your responsability to hit the script, afaik.
> I haven't deployed the bugfix, I preferred creating my own script called
> by rc.local by convenience (and also because I found the issue and
> mitigated it before talking to the forum)
>
> Once I'll migrate to 2012.2.3, I'll use this .py instead.
>
> -Sylvain
>
> Le 05/03/2013 13:23, Filipe Manco a écrit :
>
>  I read the bug description (
> https://bugs.launchpad.net/quantum/+bug/1091605) and the fix (
> https://review.openstack.org/#/c/18302/). But I don't understand who is
> the responsible to call the script on the startup.
>
>  Should I put it on something like rc.local? Or is quantum plugins'
> responsibility to run the utility?
>
>
> 2013/3/1 Sylvain Bauza <sylvain.bauza@xxxxxxxxxxxx>
>
>>  There is a known bug for the network bridges, when rebooting :
>> https://bugs.launchpad.net/quantum/+bug/1091605
>>
>> Try to delete/recreate your br-int/br-ex and then restart
>> openvswitch_plugin/l3/dhcp agents, it should fix the issue.
>>
>> -Sylvain
>>
>> Le 01/03/2013 15:04, The King in Yellow a écrit :
>>
>>   In my case, it actually appears that my vms aren't up-- the instances
>> panel says they are up, but looking at the console, it appears they aren't
>> getting an IP address.  This is a new instance:
>>
>> Begin: Running /scripts/init-bottom ... done.
>> [    2.849416] EXT4-fs (vda1): re-mounted. Opts: (null)
>> cloud-init start-local running: Thu, 28 Feb 2013 13:29:09 +0000. up 10.41 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:e0:17:f0
>>
>> route_info failed
>>
>> Waiting for network configuration...
>>
>> It looks like it made an OVS port, though.  This is on the compute node,
>> openvswitch-agent.log:
>>
>>
>> 2013-02-28 08:34:19    DEBUG [quantum.agent.linux.utils]
>> Command: ['sudo', '/usr/bin/quantum-rootwrap',
>> '/etc/quantum/rootwrap.conf', 'ovs-vsctl', '--timeout=2', 'get',
>> 'Interface', 'qvo4f36c3ea-5c', 'external_ids']
>> Exit code: 0
>> Stdout: '{attached-mac="fa:16:3e:e0:17:f0",
>> iface-id="4f36c3ea-5c49-4625-a830-0c81f27ba139", iface-status=active,
>> vm-uuid="239d3051-255e-4213-9511-af0a82fcc744"}\n'
>> Stderr: ''
>> 2013-02-28 08:34:19    DEBUG [quantum.agent.linux.utils] Running command:
>> sudo /usr/bin/quantum-rootwrap /etc/quantum/rootwrap.conf ovs-vsctl
>> --timeout=2 get Interface qvo62721ee8-08 external_ids
>> 2013-02-28 08:34:19    DEBUG [quantum.agent.linux.utils]
>> :
>> root@os-compute-01:/var/log/quantum# ovs-vsctl show
>> 3a52a17f-9846-4b32-b309-b49faf91bfc4
>>     Bridge br-int
>>         Port "qvo62721ee8-08"
>>             tag: 1
>>             Interface "qvo62721ee8-08"
>>         Port "qvo1ed73bcc-9d"
>>             tag: 1
>>             Interface "qvo1ed73bcc-9d"
>>         Port "qvoce0c94a9-ef"
>>             tag: 1
>>             Interface "qvoce0c94a9-ef"
>>         Port "qvo135e78dd-8e"
>>             tag: 4095
>>             Interface "qvo135e78dd-8e"
>>         Port "qvof37b7a55-a3"
>>             tag: 1
>>             Interface "qvof37b7a55-a3"
>>
>>         Port br-int
>>             Interface br-int
>>                 type: internal
>>         Port patch-tun
>>             Interface patch-tun
>>                 type: patch
>>                 options: {peer=patch-int}
>>          Port "qvoaed25b41-9c"
>>             tag: 1
>>             Interface "qvoaed25b41-9c"
>>         Port "qvo4f36c3ea-5c"
>>             tag: 1
>>             Interface "qvo4f36c3ea-5c"
>>     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
>>     ovs_version: "1.4.0+build0"
>>  root@os-compute-01:/var/log/quantum#
>>
>>
>>  I supposed it should be getting address via DHCP from quantum-dhcp-agent
>> on the network node?  It was running, nothing regarding this MAC in the
>> logs.  I restarted quantum-dhcp-agent and rebooted, no change.
>>
>>  In fact, I got two CirrOS vms up, logged on the console and manually
>> IPed them (10.5.5.10/24 and 10.5.5.11/24), and they can't ping each
>> other.  I would expect them to, right?  They should both be connected to
>> OVS switch br-int, right?
>>
>> Any pointers?
>>
>>
>>
>>   _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
>  --
> Filipe Manco
> about.me/fmanco
>
>
>


-- 
Filipe Manco
about.me/fmanco