Hi All
In the last week or so we've seen a couple of customer issues where a
router is associated with more than one l3 agent, which obviously causes
significant connectivity weirdness.
❯ neutron l3-agent-list-hosting-router 951c8ec9-9a6c-4c6d-9d6d-049b3dee7f6f
+-
The HA routers feature we merged in Juno, and those are scheduled to
multiple agents.
If you source admin credentials and 'neutron router-show
951c8ec9-9a6c-4c6d-9d6d-049b3dee7f6f'
is the 'HA' flag set to True? Otherwise, this is a really weird bug
which I've never seen before.
On Tue, Nov 24, 201
Nope, the HA flag is definitely set to false. Here's another example :
root@osnet0:~# neutron l3-agent-list-hosting-router
be651d53-1dd2-46eb-8d57-7e2aafd6ff57
+--+++---+
| id | host | admin_state
On Tue, Nov 24, 2015 at 5:26 PM, Matt Jarvis
wrote:
> Nope, the HA flag is definitely set to false. Here's another example :
>
> root@osnet0:~# neutron l3-agent-list-hosting-router
> be651d53-1dd2-46eb-8d57-7e2aafd6ff57
>
> +--+++---+
Hi Matt,
> It's also weird that we've only seen this when the environment has been
> built using terraform. This particular customer re-creates the issue every
> time they rebuild.
>
I work on the OpenStack support for Terraform, so I might be able to help
with this. Could you provide an example T
We were hoping that upgrading to Kilo might magically fix this, but we've
still seen it occurring, although it seems to be happening less. Is it a
database constraint that's supposed to stop this being possible ? I'm
wondering if somehow through multiple upgrades we're missing something in
the data
