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 database.
On 25 November 2015 at 00:21, Assaf Muller <[email protected]> wrote: > On Tue, Nov 24, 2015 at 5:26 PM, Matt Jarvis > <[email protected]> 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 > > > > > +--------------------------------------+--------+----------------+-------+ > > > > | id | host | admin_state_up | alive > | > > > > > +--------------------------------------+--------+----------------+-------+ > > > > | 1be0209b-4750-4c8f-ade5-3a9dba640de3 | osnet2 | True | :-) > | > > > > | c821a370-b301-40c5-8b7b-25d147ffc904 | osnet1 | True | :-) > | > > > > > +--------------------------------------+--------+----------------+-------+ > > > > root@osnet0:~# neutron router-show be651d53-1dd2-46eb-8d57-7e2aafd6ff57 > > > > > +-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ > > > > | Field | Value > > | > > > > > +-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ > > > > | admin_state_up | True > > | > > > > | distributed | False > > | > > > > | external_gateway_info | {"network_id": > > "6751cb30-0aef-4d7e-94c3-ee2a09e705eb", "enable_snat": true, > > "external_fixed_ips": [{"subnet_id": > "2af591ca-48ac-42b7-afc6-e691b3aa4c8a", > > "ip_address": "185.98.148.134"}]} | > > > > | ha | False > > | > > > > | id | be651d53-1dd2-46eb-8d57-7e2aafd6ff57 > > | > > > > | name | dpcbe-core > > | > > > > | routes | > > | > > > > | status | ACTIVE > > | > > > > | tenant_id | b28a8ac5bd7446adacfb60e1a3a3e723 > > | > > > > > +-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ > > > > 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 don't know anything about Terraform so I can't help you there. I don't > imagine > there's any interesting errors/traces in the neutron-server logs? > > > > > > > On 24 November 2015 at 21:03, Assaf Muller <[email protected]> wrote: > >> > >> 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, 2015 at 11:25 AM, Matt Jarvis > >> <[email protected]> wrote: > >> > 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 > >> > > >> > > >> > > +--------------------------------------+--------+----------------+-------+ > >> > > >> > | id | host | admin_state_up | > alive > >> > | > >> > > >> > > >> > > +--------------------------------------+--------+----------------+-------+ > >> > > >> > | 48132c36-b6b1-40fa-b9d9-5474f4f27c3a | osnet0 | True | :-) > >> > | > >> > > >> > | c821a370-b301-40c5-8b7b-25d147ffc904 | osnet1 | True | :-) > >> > | > >> > > >> > +--------------------------------------+--------+----------------+———+ > >> > > >> > > >> > We've been unable to recreate it in testing, and the API doesn't let > you > >> > do > >> > that. We think both customers are using Terraform, although that may > be > >> > irrelevant. Anyone seen this behaviour before ? We are running Juno > BTW. > >> > > >> > > >> > Matt > >> > > >> > -- > >> > Matt Jarvis > >> > Head of Cloud Computing > >> > DataCentred > >> > Office: (+44)0161 8703985 > >> > Mobile: (+44)07983 725372 > >> > Email: [email protected] > >> > Website: http://www.datacentred.co.uk > >> > > >> > DataCentred Limited registered in England and Wales no. 05611763 > >> > _______________________________________________ > >> > OpenStack-operators mailing list > >> > [email protected] > >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > >> > > > > > > > > > > > -- > > Matt Jarvis > > Head of Cloud Computing > > DataCentred > > Office: (+44)0161 8703985 > > Mobile: (+44)07983 725372 > > Email: [email protected] > > Website: http://www.datacentred.co.uk > > > > DataCentred Limited registered in England and Wales no. 05611763 > -- Matt Jarvis Head of Cloud Computing DataCentred Office: (+44)0161 8703985 Mobile: (+44)07983 725372 Email: [email protected] Website: http://www.datacentred.co.uk -- DataCentred Limited registered in England and Wales no. 05611763
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
