BZ #105104 7
When you shut down a neutron-l3-agent (or it dies) and you start
another neutron-l3-agent in a different node, OpenStack
Networking will not reschedule virtual routers from an L3 agent to
the second one. The routing or metadata remain tied to the
initial L3 agent ID. As a result, you cannot have an HA
environment when you have several nodes with L3 agents, with
different IDs either in Active/Active or Active/Passive states.
Workaround:
You can use the 'host=' field in the agent configuration file for
both L3 agents to keep the same logical ID towards neutron-server.
Two hosts should never run the neutron-l3-agent at the same time
with the same 'host=' parameter. And, when one L3 agent is
brought down (service stop) the 'neutron-netns-cleanup --forced'
script should be used to clean any namespaces and running settings
left by the neutron-l3-agent.
Using this workaround, you can have virtual routers rescheduled to
a different neutron-l3-agent, as long as they have the same
'host=' logical ID. When you use neutron agent-list, the host
field of the neutron-l3-agent will match the 'host=' field from
configuration regardless of the actual agent hostname.
BZ #1052336
For GlusterFS to accept libgfapi connections, "allow-insecure
ports" must be set.
As a result, when accessing a cinder volume from OpenStack node,
it may fail with error 0-glusterd: Request received from non-
privileg ed port. Failing request.
Perform the following to avoid this issue:
Set the following volume option:
1. # volume set volName server.allow-insecure on
2. Add the following line in /etc/glusterfs/glusterd.vol: file
option rpc-auth-allow-insecure on
3. Restart the glusterd service.
With this fix, GlusterFS will be able to accept libgfapi
connections.
BZ #1056 89 0
When upgrading from Red Hat Enterprise Linux OpenStack Platform
version 3 to version 4, if the LoadBalancer plugin is used, there
is an attempt to drop the servicedefinitions and servicetypes
tables. These tables do not drop if quantum-server in version 3
was started prior to running the command "quantum-db-manage
upgrade head".
As a result, dropping tables fails because they do not exist.
Kommentare zu diesen Handbüchern