Hi Ryan, If you don't mind, I'm adding the openstack-discuss list in the loop, as this topic may be of interest to others. For mailing list readers, I'm trying to implement this: https://review.opendev.org/#/c/669395/ but I'm having some difficulties. I did a bit of investigation with some added LOG.info() in the code. When doing:
openstack subnet create vm-fip \ --subnet-range 10.66.20.0/24 \ --service-type 'network:routed' \ --service-type 'network:floatingip' \ --network multisegment1
Here's where neutron-api crashes. in db/ipam_backend_mixin.py: def _validate_segment(self, context, network_id, segment_id, action=None, old_segment_id=None): # TODO(tidwellr) Create and use a constant for the service type segments = subnet_obj.Subnet.get_subnet_segment_ids( context, network_id, filtered_service_type='network:routed') associated_segments = set(segments) if None in associated_segments and len(associated_segments) > 1: raise segment_exc.SubnetsNotAllAssociatedWithSegments( network_id=network_id) SubnetsNotAllAssociatedWithSegments() is raised, as you must already guessed. Here's the values... associated_segments is an array containing 3 values: 2 being the IDs of the segments I added previously, the 3rd one being None. This test is then matched. Where is that None value coming from? Is this the new subnet I'm trying to add? Maybe the filtered_service_type='network:routed' in the call: subnet_obj.Subnet.get_subnet_segment_ids() isn't working as expected? Printing the SQL query that is checked shows: SELECT subnets.segment_id AS subnets_segment_id FROM subnets WHERE subnets.network_id = %(network_id_1)s AND subnets.id NOT IN (SELECT subnet_service_types.subnet_id AS subnet_service_types_subnet_id FROM subnet_service_types WHERE subnets.network_id = %(network_id_2)s AND subnet_service_types.subnet_id = subnets.id AND subnet_service_types.service_type = %(service_type_1)s) though when doing by hand: SELECT subnets.segment_id AS subnets_segment_id FROM subnets the db has only 2 subnets, so it looks like the floating-ip subnet got added before the check, and is then removed when the above test fails. So I just removed the raise, and could add the subnet I wanted, but that's obviously not a long term solution. Your thoughts? Another problem that I'm having, is that neutron-bgp-dragent is not receiving (or processing) the messages from neutron-rpc-server. I've enabled DEBUG mode for oslo_messaging, and found out that when dr-agent starts and prints "Agent has just been revived. Scheduling full sync", it does send a message to neutron-rpc-server, which is replied, but it doesn't look like dr-agent processes the return message in its reply queue, and then prints in the logs: "imeout in RPC method get_bgp_speakers. Waiting for 17 seconds before next attempt. If the server is not down, consider increasing the rpc_response_timeout option as Neutron server(s) may be overloaded and unable to respond quickly enough.: oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a reply to message ID c1b401c9e10d481bb5e071f2c048e480". What is weird is that a few times (rarely), it worked, and the agent gets the reply. What should I do to investigate further? Cheers, Thomas Goirand (zigo)