Issues with devstack on both Fedora 17 and 18

[Kyle Mestery (kmestery)]

On Feb 8, 2013, at 9:16 AM, "Kyle Mestery (kmestery)" <kmestery at cisco.com>
 wrote:
> On Feb 8, 2013, at 9:13 AM, "Daniel P. Berrange" <berrange at redhat.com>
> wrote:
>> On Fri, Feb 08, 2013 at 03:03:43PM +0000, Kyle Mestery (kmestery) wrote:
>>> On Feb 8, 2013, at 8:55 AM, Dennis Jacobfeuerborn <dennisml at conversis.de>
>>> wrote:
>>>> On 02/08/2013 03:49 PM, Daniel P. Berrange wrote:
>>>>> On Fri, Feb 08, 2013 at 02:35:24PM +0000, Kyle Mestery (kmestery) wrote:
>>>>>> On Feb 8, 2013, at 8:31 AM, Daniel P. Berrange <berrange at redhat.com> wrote:
>>>>>>> On Fri, Feb 08, 2013 at 02:23:07PM +0000, Kyle Mestery (kmestery) wrote:
>>>>>> My localrc looks like the below. Note I am storing things in /opt, and I am using
>>>>>> Quantum with the Ryu plugin as well. I was using rabbitmq, but switched to qpid
>>>>>> recently, though this fails the same way with either one.
>>>>> 
>>>>> I don't see anything particularly wrong with your config here. The only
>>>>> key difference from mine seems to be your use of Quantum+Ryu. So I guess
>>>>> my inclination would be to try taking this out of the equation, by trying
>>>>> todo a setup using just nova-network, and disable Quantum entirely. If
>>>>> that works, then you'll know it is something quantum related, and can then
>>>>> try different plugins to see if it is Ryu related or not.
>>>>> 
>>>>>> 
>>>>>> [kmestery at fedora-mac devstack]$ cat localrc 
>>>>>> LOGFILE=stack.sh.log
>>>>>> #OFFLINE=True
>>>>>> #RECLONE=yes
>>>>>> disable_service n-net
>>>>>> enable_service q-svc
>>>>>> enable_service q-agt
>>>>>> enable_service q-dhcp
>>>>>> enable_service q-l3
>>>>>> enable_service quantum
>>>>>> enable_service ryu
>>>>>> disable_service rabbit
>>>>>> enable_service qpid
>>>>>> 
>>>>>> HOST_NAME=$(hostname)
>>>>>> SERVICE_HOST_NAME=${HOST_NAME}
>>>>>> SERVICE_HOST=192.168.56.101
>>>>>> 
>>>>>> FLOATING_RANGE=192.168.100.0/24
>>>>>> #Q_PLUGIN=openvswitch
>>>>>> Q_PLUGIN=ryu
>>>>>> # ryu
>>>>>> RYU_API_HOST=$SERVICE_HOST
>>>>>> RYU_OFP_HOST=$SERVICE_HOST
>>>>>> RYU_APPS=ryu.app.gre_tunnel,ryu.app.quantum_adapter,ryu.app.rest,ryu.app.rest_conf_switch,ryu.app.rest_tunnel,ryu.app.tunnel_port_updater,ryu.app.rest_quantum
>>>>>> RYU_REPO=${GIT_BASE}/ykaneko/ryu.git
>>>>>> RYU_BRANCH=live-migration
>>>>>> 
>>>>>> Q_HOST=$SERVICE_HOST
>>>>>> MYSQL_HOST=$SERVICE_HOST
>>>>>> RABBIT_HOST=$SERVICE_HOST
>>>>>> GLANCE_HOSTPORT=$SERVICE_HOST:9292
>>>>>> KEYSTONE_AUTH_HOST=$SERVICE_HOST
>>>>>> KEYSTONE_SERVICE_HOST=$SERVICE_HOST
>>>>>> 
>>>>>> MYSQL_PASSWORD=mysql
>>>>>> #RABBIT_PASSWORD=rabbit
>>>>>> SERVICE_TOKEN=service
>>>>>> SERVICE_PASSWORD=admin
>>>>>> ADMIN_PASSWORD=admin
>>>> 
>>>> I've seen something similar and quantum was the culprit. I don't know what
>>>> quantum does that messes this up but when i disabled the quantum services
>>>> the problem went away and when I re-enabled them the problem popped back up.
>>>> 
>>> Thanks Dennis and Daniel, you are both right, it is Quantum causing this
>>> issue. I'll file a bug with the Quantum project and take a look at fixing this.
>>> I'm not sure what's causing it now, but it was getting annoying to constantly
>>> be seeing it. Thanks for helping me debug this!
>> 
>> CC me on the bug you file - I'd be very interested to find out what the
>> cause is. Even if quantum is what's triggering it, it smells like it might
>> actually be a bug in DBus - something like Quantum ought not to be able
>> to crash dbus after all !
>> 
>> My money would be on something namespace related, since IIUC, quantum
>> does some playing around with network namespaces at least ?
>> 
>> Daniel
> 
> Thanks Daniel. I just subscribed you to the bug. I'm trying a run with
> namespaces turned off now to see if that helps or not. I think that may be
> the culprit, I recall running a devstack with Quantum but without namespaces
> and it working a while back. Will let you know how it goes.
> 
> Thanks,
> Kyle
> 
It's definitely namespace related. When I turned namespaces off in my localrc,
DBus stayed up and things worked ok. Now the digging on how they two are
interacting in such a destructive way can begin!

Thanks,
Kyle

> _______________________________________________
> cloud mailing list
> cloud at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud