The neutron service is running on the physical host within the compute
nodes, as well as the l3 agent containers. You should be able to do
`service neutron-linuxbridge-agent restart` on the compute node to start
the service. If its failing to run, there should be something within the
logs to indicate what the failure is. Check your neutron logs in
/var/log/neutron to see what's happening within the service as there
should be more data on what is causing it to fail. You might also be
able to active the venv `source
/openstack/venvs/${SERVICENAME_VERSION}/bin/activate` and run the
service in the foreground which may help shine some more light on the
issues.
If you can jump into the IRC (#openstack-ansible) channel we might be
able to work faster on getting this resolved for the deployment feel
free to ping me anytime.
--
Kevin Carter
IRC: cloudnull
On 12/14/2015 11:22 AM, Mark Korondi wrote:
> I am using the liberty branch. Unfortunately this did not help, I get
> the same error.
>
> I also don't understand where the neutron service should run. This is
> the output on my compute node:
>
> root@os-compute-1:~# ps aux | grep neutron
> root 18782 0.0 0.0 11748 2232 pts/0 S+ 17:56 0:00 grep
> --color=auto neutron
> root@os-compute-1:~# ip netns list
> root@os-compute-1:~#
>
> Is there a step-by step guide that shows how to set up a simple flat
> networking with OSA? I guess this whole thing is optimized around vlan
> provider networking which I don't have on my playground environment.
>
>
>
> On Mon, Dec 14, 2015 at 4:46 PM, Kevin Carter
> <kevin.car...@rackspace.com> wrote:
>> The port binding issues are usually related to a neutron physical interface
>> mapping issue however based on your previous config I don't think that was
>> the problem. If you're deploying Liberty/Master(Mitaka) there was was a fix
>> that went in that resolved an issue within neutron and the use of
>> L2/multicast groups [0] and if your on the stable tag the fix has not been
>> released yet and will be there for the 12.0.3 tag, coming soon. To resolve
>> the issue the fix is to simply to add the following to your
>> `user_variables.yml` file:
>>
>> == If you don't want to use l2 population add the following ==
>> neutron_l2_population: "False"
>> neutron_vxlan_group: "239.1.1.1"
>>
>> == If you want to use l2 population add the following ==
>> neutron_l2_population: "True"
>>
>> As for the neutron services on your compute nodes, they should be running
>> within the host namespace. In liberty/Master the python bits will be within
>> a vent using an upstart init script to control the service. If your not
>> seeing the neutron service running its likely due to this bug [2] which is
>> resolve by dropping the previously mentioned user variable options.
>>
>> I hope this helps and let me know how it goes.
>>
>> [0] https://review.openstack.org/#/c/255624
>> [1] https://github.com/openstack/openstack-ansible/commits/liberty
>> [2] https://bugs.launchpad.net/neutron/+bug/1470584
>>
>> --
>>
>> Kevin Carter
>> IRC: cloudnull
>>
>>
>> ________________________________________
>> From: Mark Korondi <korondi.m...@gmail.com>
>> Sent: Sunday, December 13, 2015 9:10 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [ansible] One or more undefined variables:
>> 'dict object' has no attribute 'bridge'
>>
>> Thanks cloudnull,
>>
>> This solved the installation issue. I commented out all non-flat
>> related networks before, to investigate my main problem, which is
>>
>>> PortBindingFailed: Binding failed for port
>>> fe67a2d5-6d6a-4440-80d0-acbe2ff5c27f, please check neutron logs for more
>>> information.
>>
>> I still have this problem; I created the flat external network with no
>> errors, still I get this when trying to launch an instance. What's
>> really interesting to me, is that no neutron microservices are
>> deployed and running on the compute node.
>>
>> Mark (kmARC)
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
