Open Stack

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 <amuller at redhat.com> wrote:

> On Tue, Nov 24, 2015 at 5:26 PM, Matt Jarvis
> <matt.jarvis at datacentred.co.uk> wrote:
> > Nope, the HA flag is definitely set to false. Here's another example :
> >
> > root at 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 at 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 <amuller at redhat.com> 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
> >> <matt.jarvis at datacentred.co.uk> 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: matt.jarvis at datacentred.co.uk
> >> > Website: http://www.datacentred.co.uk
> >> >
> >> > DataCentred Limited registered in England and Wales no. 05611763
> >> > _______________________________________________
> >> > OpenStack-operators mailing list
> >> > OpenStack-operators at lists.openstack.org
> >> >
> 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: matt.jarvis at datacentred.co.uk
> > 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: matt.jarvis at datacentred.co.uk
Website: http://www.datacentred.co.uk

-- 
DataCentred Limited registered in England and Wales no. 05611763
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20151211/9e9e654c/attachment.html>