Scheduling router without external network results in unclear error

[James Denton]

When attempting to schedule a router to an L3 agent without an external network set, the following error is observed:

root@infra01_neutron_server_container-96ae0d98:~# neutron l3-agent-router-add 7ec8336e-3d82-46f5-8e15-2f2477090021 TestRouter
Agent 7ec8336e-3d82-46f5-8e15-2f2477090021 is not a L3 Agent or has been disabled

The error could lead users to believe the L3 agent(s) are not alive when the agent-list clearly shows otherwise:

root@infra01_neutron_server_container-96ae0d98:~# neutron agent-list | grep l3
| 7ec8336e-3d82-46f5-8e15-2f2477090021 | L3 agent | infra01_neutron_agents_container-4bbf1e68 | :-) | True | neutron-l3-agent |
| b5d7be19-3143-431e-ac8b-1c8237acaace | L3 agent | infra02_neutron_agents_container-fb552892 | :-) | True | neutron-l3-agent |
| e8bed137-6ec3-41d1-a524-3e5e3a884fcd | L3 agent | infra03_neutron_agents_container-ad2973dd | :-) | True | neutron-l3-agent |

The test case in get_l3_agent_candidates function in l3_agentschedulers_db.py tests to see if external_gateway_info is set and when it isn't, returns zero candidates. As a result, the presented agent is considered invalid.

The proper workflow appears to be that a gateway must be set before a router can be scheduled. However, already scheduled routers can have their gateway cleared with no observed issues and remain scheduled.

It may help to create a new error to represent this failed test case rather than lumping tests together, or provide additional pointers in the error message to reflect possible issues other than a disabled or non-L3 agent.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/311208

[James Denton (james-denton)]

Further examination shows this condition is seen when handle_internal_only_routers is set to False. When set to True, the router can be scheduled without an external network set. If anything, the request here is to clarify the error message presented to the user in case of the former.

[Assaf Muller (amuller)]

Out of curiosity, can you expand on the use case, why are you setting handle_internal_only_routers to False?

[James Denton (james-denton)]

It wasn't intentional on my part. I'm using openstack-ansible, and from Liberty onward it appears to be hard-coded to False in the l3_agent.ini template. I will file a bug for that.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Trevor McCasland (<email address hidden>) on branch: master
Review: https://review.openstack.org/311208
Reason: Abandoning because of lack of value added to the project pointed out by garyk.

[Brian Haley (brian-haley)]

Closing as patch was abandoned due to lack of value. If someone intends to work on this further please re-open. Thanks.