)]}'
{"doc/source/index.rst":[{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"fb379fd7da02a2af2bb2cb4e52038f9eea1f8fe7","unresolved":true,"context_lines":[{"line_number":10,"context_line":".. toctree::"},{"line_number":11,"context_line":"   :maxdepth: 2"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"   specs/wallaby/index"},{"line_number":14,"context_line":"   specs/victoria/index"},{"line_number":15,"context_line":"   specs/ussuri/index"},{"line_number":16,"context_line":"   specs/train/index"}],"source_content_type":"text/x-rst","patch_set":2,"id":"558424d6_3c21cd96","line":13,"range":{"start_line":13,"start_character":0,"end_line":13,"end_character":22},"updated":"2021-01-12 09:16:41.000000000","message":"You may rebase the master branch, all these works had been done.","commit_id":"ea28e692df01a68a3128fc4f2b792d2c845d54bd"}],"specs/wallaby/index.rst":[{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"fb379fd7da02a2af2bb2cb4e52038f9eea1f8fe7","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"e3fe42e7_17219061","line":10,"updated":"2021-01-12 09:16:41.000000000","message":"You may rebase the master branch, all these works had been done.","commit_id":"ea28e692df01a68a3128fc4f2b792d2c845d54bd"}],"specs/wallaby/vpnaas-ovn.rst":[{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"9fade2fef0acbff25f2f9655cd066f1c13256372","unresolved":true,"context_lines":[{"line_number":8,"context_line":"VPNaaS for OVN Networking"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"This specification covers the support for VPNaaS with OVN networking by adding"},{"line_number":12,"context_line":"a stand-alone VPN agent. This new agent will create a namespace on the node,"},{"line_number":13,"context_line":"connect it with the OVN distributed logical router and run the Swan process in"},{"line_number":14,"context_line":"the namespace."},{"line_number":15,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7e6377dc_48ea8b4f","line":12,"range":{"start_line":11,"start_character":54,"end_line":12,"end_character":24},"updated":"2021-01-11 15:03:08.000000000","message":"This is for project neutron-vpnaas, right? A new type of agent with different L2/L3 driver, but reuse the \u0027swan\u0027 VPN drivers [1].\n\n[1] https://github.com/openstack/neutron-vpnaas/tree/master/neutron_vpnaas/services/vpn/device_drivers","commit_id":"ea28e692df01a68a3128fc4f2b792d2c845d54bd"},{"author":{"_account_id":31976,"name":"Bodo Petermann","email":"b.petermann@syseleven.de","username":"bpetermann"},"change_message_id":"08c887ef94ef626846de7a3b8f5a7e42ad8b3eb0","unresolved":true,"context_lines":[{"line_number":8,"context_line":"VPNaaS for OVN Networking"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"This specification covers the support for VPNaaS with OVN networking by adding"},{"line_number":12,"context_line":"a stand-alone VPN agent. This new agent will create a namespace on the node,"},{"line_number":13,"context_line":"connect it with the OVN distributed logical router and run the Swan process in"},{"line_number":14,"context_line":"the namespace."},{"line_number":15,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"528d2ffa_eaaf3093","line":12,"range":{"start_line":11,"start_character":54,"end_line":12,"end_character":24},"in_reply_to":"7e6377dc_48ea8b4f","updated":"2021-01-11 16:23:46.000000000","message":"Yes, for neutron-vpnaas. The new agent does not provide L2/L3 driver functions, it\u0027s only there to start the *swan process and manage a namespace for it. There will be separate swan drivers to do that, derived from the existing ones.","commit_id":"ea28e692df01a68a3128fc4f2b792d2c845d54bd"},{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"0020f9ad535081ffb4607f45d6432e904b0477ee","unresolved":true,"context_lines":[{"line_number":40,"context_line":"driver is part of the L3 agent. In OVN the L3 router scheduler and L3 agents"},{"line_number":41,"context_line":"are not used anymore, so a replacement is required."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"A new type of agent is introduced: one that only deals with VPN processes."},{"line_number":44,"context_line":"We also add a corresponding VPN agent scheduler. Using the OVN-related"},{"line_number":45,"context_line":"scheduler for the router gateway port was ruled out because the VPN agent"},{"line_number":46,"context_line":"scheduler should also keep track whether the VPN agent(s) are still alive."}],"source_content_type":"text/x-rst","patch_set":2,"id":"4dd32a82_43771318","line":43,"range":{"start_line":43,"start_character":0,"end_line":43,"end_character":74},"updated":"2021-01-11 13:40:42.000000000","message":"nit: this is not related to the \"neutron server\", right? It\u0027s been already introduced on L26","commit_id":"ea28e692df01a68a3128fc4f2b792d2c845d54bd"},{"author":{"_account_id":31976,"name":"Bodo Petermann","email":"b.petermann@syseleven.de","username":"bpetermann"},"change_message_id":"4ab36cb5a9ea9696771cc6e4a9c2e65f7d33e0ef","unresolved":true,"context_lines":[{"line_number":40,"context_line":"driver is part of the L3 agent. In OVN the L3 router scheduler and L3 agents"},{"line_number":41,"context_line":"are not used anymore, so a replacement is required."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"A new type of agent is introduced: one that only deals with VPN processes."},{"line_number":44,"context_line":"We also add a corresponding VPN agent scheduler. Using the OVN-related"},{"line_number":45,"context_line":"scheduler for the router gateway port was ruled out because the VPN agent"},{"line_number":46,"context_line":"scheduler should also keep track whether the VPN agent(s) are still alive."}],"source_content_type":"text/x-rst","patch_set":2,"id":"67488d9e_d2db2d1c","line":43,"range":{"start_line":43,"start_character":0,"end_line":43,"end_character":74},"in_reply_to":"4dd32a82_43771318","updated":"2021-01-12 14:14:20.000000000","message":"I changed the wording. This sentence was meant to introduce the following one.","commit_id":"ea28e692df01a68a3128fc4f2b792d2c845d54bd"},{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"0020f9ad535081ffb4607f45d6432e904b0477ee","unresolved":true,"context_lines":[{"line_number":41,"context_line":"are not used anymore, so a replacement is required."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"A new type of agent is introduced: one that only deals with VPN processes."},{"line_number":44,"context_line":"We also add a corresponding VPN agent scheduler. Using the OVN-related"},{"line_number":45,"context_line":"scheduler for the router gateway port was ruled out because the VPN agent"},{"line_number":46,"context_line":"scheduler should also keep track whether the VPN agent(s) are still alive."},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"The new VPN agent scheduler will work on a per-router basis to have all IPSec"},{"line_number":49,"context_line":"site connections of a router processed by the same agent."}],"source_content_type":"text/x-rst","patch_set":2,"id":"747595a6_a6b3c849","line":46,"range":{"start_line":44,"start_character":48,"end_line":46,"end_character":74},"updated":"2021-01-11 13:40:42.000000000","message":"What happens when VPN agent dies but the gateway port is still bound to the same node. Is it the VPN scheduler responsibility to change the GW port binding location?","commit_id":"ea28e692df01a68a3128fc4f2b792d2c845d54bd"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"015da72e582be268b313e92a6555ccc521be9fe7","unresolved":true,"context_lines":[{"line_number":65,"context_line":"- destination CIDR: peer CIDR"},{"line_number":66,"context_line":"- next hop: IP address of a port in the transit network (169.254.0.2)"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"The new ports and the transit network and subnet are managed using the API of"},{"line_number":69,"context_line":"the Neutron core plugin and L3 plugin, not \"under the hood\" with OVN functions,"},{"line_number":70,"context_line":"to avoid inconsistencies between the Neutron database and OVN Northbound."},{"line_number":71,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7e85c78c_3b89c951","line":68,"range":{"start_line":68,"start_character":42,"end_line":68,"end_character":48},"updated":"2021-01-11 10:52:41.000000000","message":"Why this transit network needs to be managed by Neutron API? Can You elaborate more on that?","commit_id":"ea28e692df01a68a3128fc4f2b792d2c845d54bd"},{"author":{"_account_id":841,"name":"Akihiro Motoki","email":"amotoki@gmail.com","username":"amotoki"},"change_message_id":"7cddea3d75e893f990f302950a9647bd3291ea33","unresolved":true,"context_lines":[{"line_number":65,"context_line":"- destination CIDR: peer CIDR"},{"line_number":66,"context_line":"- next hop: IP address of a port in the transit network (169.254.0.2)"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"The new ports and the transit network and subnet are managed using the API of"},{"line_number":69,"context_line":"the Neutron core plugin and L3 plugin, not \"under the hood\" with OVN functions,"},{"line_number":70,"context_line":"to avoid inconsistencies between the Neutron database and OVN Northbound."},{"line_number":71,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"e6737855_93b26a76","line":68,"range":{"start_line":68,"start_character":42,"end_line":68,"end_character":48},"in_reply_to":"652dde6d_13f1e3dc","updated":"2021-01-14 07:16:25.000000000","message":"In my understanding, it is mainly to simplify the maintenance. If we create transit network in neutron, all resources in the OVN side would be a mirror of neutron resources. This would be simpler and I think it is a good  compromise.","commit_id":"ea28e692df01a68a3128fc4f2b792d2c845d54bd"},{"author":{"_account_id":31976,"name":"Bodo Petermann","email":"b.petermann@syseleven.de","username":"bpetermann"},"change_message_id":"08c887ef94ef626846de7a3b8f5a7e42ad8b3eb0","unresolved":true,"context_lines":[{"line_number":65,"context_line":"- destination CIDR: peer CIDR"},{"line_number":66,"context_line":"- next hop: IP address of a port in the transit network (169.254.0.2)"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"The new ports and the transit network and subnet are managed using the API of"},{"line_number":69,"context_line":"the Neutron core plugin and L3 plugin, not \"under the hood\" with OVN functions,"},{"line_number":70,"context_line":"to avoid inconsistencies between the Neutron database and OVN Northbound."},{"line_number":71,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"652dde6d_13f1e3dc","line":68,"range":{"start_line":68,"start_character":42,"end_line":68,"end_character":48},"in_reply_to":"7e85c78c_3b89c951","updated":"2021-01-11 16:23:46.000000000","message":"If the lswitch for the transit network is created directly in the OVN Northbound DB, sync scripts like neutron-ovn-db-sync-util will detect inconsistencies with the Neutron DB and might delete the seemingly unwanted lswitches. On the other hand, if the transit network is created via Neutron the Neutron DB and OVN NB are kept in sync and one could use neutron-ovn-db-sync-util to re-generate the OVN DB if necessary.","commit_id":"ea28e692df01a68a3128fc4f2b792d2c845d54bd"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"015da72e582be268b313e92a6555ccc521be9fe7","unresolved":true,"context_lines":[{"line_number":66,"context_line":"- next hop: IP address of a port in the transit network (169.254.0.2)"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"The new ports and the transit network and subnet are managed using the API of"},{"line_number":69,"context_line":"the Neutron core plugin and L3 plugin, not \"under the hood\" with OVN functions,"},{"line_number":70,"context_line":"to avoid inconsistencies between the Neutron database and OVN Northbound."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"The IDs of the newly added ports, transit network and subnet are stored in a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"a683312b_1beb064c","line":69,"range":{"start_line":69,"start_character":28,"end_line":69,"end_character":37},"updated":"2021-01-11 10:52:41.000000000","message":"Do You mean L3 service plugin or \"ovn-l3\" service plugin?","commit_id":"ea28e692df01a68a3128fc4f2b792d2c845d54bd"},{"author":{"_account_id":31976,"name":"Bodo Petermann","email":"b.petermann@syseleven.de","username":"bpetermann"},"change_message_id":"08c887ef94ef626846de7a3b8f5a7e42ad8b3eb0","unresolved":true,"context_lines":[{"line_number":66,"context_line":"- next hop: IP address of a port in the transit network (169.254.0.2)"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"The new ports and the transit network and subnet are managed using the API of"},{"line_number":69,"context_line":"the Neutron core plugin and L3 plugin, not \"under the hood\" with OVN functions,"},{"line_number":70,"context_line":"to avoid inconsistencies between the Neutron database and OVN Northbound."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"The IDs of the newly added ports, transit network and subnet are stored in a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9d75a34e_f73fade4","line":69,"range":{"start_line":69,"start_character":28,"end_line":69,"end_character":37},"in_reply_to":"a683312b_1beb064c","updated":"2021-01-11 16:23:46.000000000","message":"\"L3 plugin\" refers to the OVN L3 router service plugin (which provides the get_router, add/remove_router_interface, add/remove_extraroutes functions)","commit_id":"ea28e692df01a68a3128fc4f2b792d2c845d54bd"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"015da72e582be268b313e92a6555ccc521be9fe7","unresolved":true,"context_lines":[{"line_number":134,"context_line":"Heartbeat of the VPN agent"},{"line_number":135,"context_line":"++++++++++++++++++++++++++"},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"The VPN agent periodically reports its state (\"report_state\" RPC). The server"},{"line_number":138,"context_line":"side plugin utilizes the AgentSchedulerDbMixin functionality to keep track of"},{"line_number":139,"context_line":"alive agents and will potentially reschedule VPN services if an agent is down."},{"line_number":140,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"6e5cd3ed_0d421a12","line":137,"range":{"start_line":137,"start_character":45,"end_line":137,"end_character":65},"updated":"2021-01-11 10:52:41.000000000","message":"does that mean that we will again need to use rabbitmq for communication in Neutron?","commit_id":"ea28e692df01a68a3128fc4f2b792d2c845d54bd"},{"author":{"_account_id":841,"name":"Akihiro Motoki","email":"amotoki@gmail.com","username":"amotoki"},"change_message_id":"b2906025bfdbbae2e958e143e7543b5646581d54","unresolved":true,"context_lines":[{"line_number":134,"context_line":"Heartbeat of the VPN agent"},{"line_number":135,"context_line":"++++++++++++++++++++++++++"},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"The VPN agent periodically reports its state (\"report_state\" RPC). The server"},{"line_number":138,"context_line":"side plugin utilizes the AgentSchedulerDbMixin functionality to keep track of"},{"line_number":139,"context_line":"alive agents and will potentially reschedule VPN services if an agent is down."},{"line_number":140,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"6907ccd6_9b1e1464","line":137,"range":{"start_line":137,"start_character":45,"end_line":137,"end_character":65},"in_reply_to":"2e53921a_c1ab587d","updated":"2021-02-12 07:36:45.000000000","message":"Thanks for updating it. The proposal sounds reasnable to me. While neutron OVN deployment does not use rabbitmq, other OpenStack components like nova still require rabbitmq, so I don\u0027t think using rabbitmq is so much extra thing.","commit_id":"ea28e692df01a68a3128fc4f2b792d2c845d54bd"},{"author":{"_account_id":31976,"name":"Bodo Petermann","email":"b.petermann@syseleven.de","username":"bpetermann"},"change_message_id":"84034c86a05026f78aacc1bcc38a197e0a7c0ff2","unresolved":true,"context_lines":[{"line_number":134,"context_line":"Heartbeat of the VPN agent"},{"line_number":135,"context_line":"++++++++++++++++++++++++++"},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"The VPN agent periodically reports its state (\"report_state\" RPC). The server"},{"line_number":138,"context_line":"side plugin utilizes the AgentSchedulerDbMixin functionality to keep track of"},{"line_number":139,"context_line":"alive agents and will potentially reschedule VPN services if an agent is down."},{"line_number":140,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"2e53921a_c1ab587d","line":137,"range":{"start_line":137,"start_character":45,"end_line":137,"end_character":65},"in_reply_to":"5cd6ae07_798f997c","updated":"2021-02-09 17:36:31.000000000","message":"I added more text to explain the choices. Since OVN does not support VPN configuration itself the configuration needs to be communicated outside of OVN north/southbound databases. The existing VPNaaS plugin used rabbitmq, so it would be the least complex change if we keep it.\nFor the liveness checks there is an alternative though: to use the same mechanism as the OVN metadata agent via an additional Chassis_Private external_id.\nMy current proposal is to keep using rabbitmq for configuration updates and status updates, and don\u0027t use rabbitmq for the liveness check (instead use the algorithm of other OVN agents).","commit_id":"ea28e692df01a68a3128fc4f2b792d2c845d54bd"},{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"fb379fd7da02a2af2bb2cb4e52038f9eea1f8fe7","unresolved":true,"context_lines":[{"line_number":134,"context_line":"Heartbeat of the VPN agent"},{"line_number":135,"context_line":"++++++++++++++++++++++++++"},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"The VPN agent periodically reports its state (\"report_state\" RPC). The server"},{"line_number":138,"context_line":"side plugin utilizes the AgentSchedulerDbMixin functionality to keep track of"},{"line_number":139,"context_line":"alive agents and will potentially reschedule VPN services if an agent is down."},{"line_number":140,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9594bee8_f628541f","line":137,"range":{"start_line":137,"start_character":45,"end_line":137,"end_character":65},"in_reply_to":"6e5cd3ed_0d421a12","updated":"2021-01-12 09:16:41.000000000","message":"Looks it is true, there will be a new python agent for Neutron in OVN cluster. Something like ovn-metadata-agent I guess.","commit_id":"ea28e692df01a68a3128fc4f2b792d2c845d54bd"},{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"86e655f385e1f9a8cceacbd1b5661d113522c580","unresolved":true,"context_lines":[{"line_number":134,"context_line":"Heartbeat of the VPN agent"},{"line_number":135,"context_line":"++++++++++++++++++++++++++"},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"The VPN agent periodically reports its state (\"report_state\" RPC). The server"},{"line_number":138,"context_line":"side plugin utilizes the AgentSchedulerDbMixin functionality to keep track of"},{"line_number":139,"context_line":"alive agents and will potentially reschedule VPN services if an agent is down."},{"line_number":140,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"39db8a6a_9839e37f","line":137,"range":{"start_line":137,"start_character":45,"end_line":137,"end_character":65},"in_reply_to":"9594bee8_f628541f","updated":"2021-01-12 09:24:38.000000000","message":"Just note that ovn-metadata-agent doesn\u0027t use RPC but OVN databases to report liveness.","commit_id":"ea28e692df01a68a3128fc4f2b792d2c845d54bd"},{"author":{"_account_id":31976,"name":"Bodo Petermann","email":"b.petermann@syseleven.de","username":"bpetermann"},"change_message_id":"a5ede9f91aaab3dd76f4fd9f55fe8aa10d8dc731","unresolved":true,"context_lines":[{"line_number":134,"context_line":"Heartbeat of the VPN agent"},{"line_number":135,"context_line":"++++++++++++++++++++++++++"},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"The VPN agent periodically reports its state (\"report_state\" RPC). The server"},{"line_number":138,"context_line":"side plugin utilizes the AgentSchedulerDbMixin functionality to keep track of"},{"line_number":139,"context_line":"alive agents and will potentially reschedule VPN services if an agent is down."},{"line_number":140,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"b8721059_794df5ec","line":137,"range":{"start_line":137,"start_character":45,"end_line":137,"end_character":65},"in_reply_to":"9594bee8_f628541f","updated":"2021-01-12 09:34:05.000000000","message":"Yes, the current design of the VPN agent uses rabbitmq for aliveness updates. That part could be changed to the way the OVN metadata agent works for aliveness.\nBut there\u0027s more rabbitmq: The existing vpnaas plugin used rabbitmq for syncing the VPN configuration as well and the new OVN vpnaas drivers don\u0027t change that.","commit_id":"ea28e692df01a68a3128fc4f2b792d2c845d54bd"},{"author":{"_account_id":31976,"name":"Bodo Petermann","email":"b.petermann@syseleven.de","username":"bpetermann"},"change_message_id":"8e14ec0a41fd9827307da332e4ca5ce477cc569d","unresolved":true,"context_lines":[{"line_number":134,"context_line":"Heartbeat of the VPN agent"},{"line_number":135,"context_line":"++++++++++++++++++++++++++"},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"The VPN agent periodically reports its state (\"report_state\" RPC). The server"},{"line_number":138,"context_line":"side plugin utilizes the AgentSchedulerDbMixin functionality to keep track of"},{"line_number":139,"context_line":"alive agents and will potentially reschedule VPN services if an agent is down."},{"line_number":140,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"5cd6ae07_798f997c","line":137,"range":{"start_line":137,"start_character":45,"end_line":137,"end_character":65},"in_reply_to":"b8721059_794df5ec","updated":"2021-01-26 14:40:29.000000000","message":"I added a short paragraph to the spec to document that rabbitmq is still used for communication between neutron server and VPN agent to sync the VPN configuration. Will that be acceptable?","commit_id":"ea28e692df01a68a3128fc4f2b792d2c845d54bd"},{"author":{"_account_id":841,"name":"Akihiro Motoki","email":"amotoki@gmail.com","username":"amotoki"},"change_message_id":"7cddea3d75e893f990f302950a9647bd3291ea33","unresolved":true,"context_lines":[{"line_number":54,"context_line":"In the existing implementation for ML2/OVS the VPNaaS shares the router gateway"},{"line_number":55,"context_line":"IP address with router SNAT, but for OVN the gateway public IP address (SNAT)"},{"line_number":56,"context_line":"can\u0027t be shared with the VPN because SNAT is not in the namespace context."},{"line_number":57,"context_line":"A new public IP address is needed for the VPNaaS namespace, so a VPN gateway"},{"line_number":58,"context_line":"port is created in the external network of the router."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"To connect the router with the namespace a \"Transit network\" (169.254.0.0/30)"}],"source_content_type":"text/x-rst","patch_set":4,"id":"064c4de6_87c98824","line":57,"range":{"start_line":57,"start_character":0,"end_line":57,"end_character":59},"updated":"2021-01-14 07:16:25.000000000","message":"Is this public IP address on the external network automatically allocated when a VPN service is created?\nThe spec says there is no API change so I guess the allocated public IP address will be visible to a user via \"external_v4_ip\" or \"external_v6_ip\". Is my understanding correct?\nAnyway it would be nice to mention it in the \"REST API impact\" section.\n\n[1] https://docs.openstack.org/api-ref/network/v2/index.html?expanded\u003dcreate-vpn-endpoint-group-detail,create-vpn-service-detail#vpnaas-2-0-vpn-vpnservices-ikepolicies-ipsecpolicies-endpoint-groups-ipsec-site-connections","commit_id":"baf3b055abf005b6f40b41193959f190fc432a44"},{"author":{"_account_id":31976,"name":"Bodo Petermann","email":"b.petermann@syseleven.de","username":"bpetermann"},"change_message_id":"acee484cb2e13ef4648a3201dd71333608429719","unresolved":true,"context_lines":[{"line_number":54,"context_line":"In the existing implementation for ML2/OVS the VPNaaS shares the router gateway"},{"line_number":55,"context_line":"IP address with router SNAT, but for OVN the gateway public IP address (SNAT)"},{"line_number":56,"context_line":"can\u0027t be shared with the VPN because SNAT is not in the namespace context."},{"line_number":57,"context_line":"A new public IP address is needed for the VPNaaS namespace, so a VPN gateway"},{"line_number":58,"context_line":"port is created in the external network of the router."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"To connect the router with the namespace a \"Transit network\" (169.254.0.0/30)"}],"source_content_type":"text/x-rst","patch_set":4,"id":"46570628_7af6211a","line":57,"range":{"start_line":57,"start_character":0,"end_line":57,"end_character":59},"in_reply_to":"064c4de6_87c98824","updated":"2021-01-14 15:42:35.000000000","message":"Right, the external IP of the VPN service appears in external_v4_ip/external_v6_ip. I added that note to the spec, also in the REST API impact section.","commit_id":"baf3b055abf005b6f40b41193959f190fc432a44"},{"author":{"_account_id":841,"name":"Akihiro Motoki","email":"amotoki@gmail.com","username":"amotoki"},"change_message_id":"7cddea3d75e893f990f302950a9647bd3291ea33","unresolved":true,"context_lines":[{"line_number":57,"context_line":"A new public IP address is needed for the VPNaaS namespace, so a VPN gateway"},{"line_number":58,"context_line":"port is created in the external network of the router."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"To connect the router with the namespace a \"Transit network\" (169.254.0.0/30)"},{"line_number":61,"context_line":"is created and attached to the router. It is used to route traffic between"},{"line_number":62,"context_line":"virtual machine network(s) and the VPN process namespace. The respective routes"},{"line_number":63,"context_line":"added to the router are (per peer CIDR):"},{"line_number":64,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"2097b1eb_c540f3a4","line":61,"range":{"start_line":60,"start_character":0,"end_line":61,"end_character":39},"updated":"2021-01-14 07:16:25.000000000","message":"Who will be the owner of this \"transit network\"? My question is whther it is visible to REST API user or it is only visible to admin. IMHO it should be visible only to admin (as we do for L3-HA network)","commit_id":"baf3b055abf005b6f40b41193959f190fc432a44"},{"author":{"_account_id":31976,"name":"Bodo Petermann","email":"b.petermann@syseleven.de","username":"bpetermann"},"change_message_id":"acee484cb2e13ef4648a3201dd71333608429719","unresolved":true,"context_lines":[{"line_number":57,"context_line":"A new public IP address is needed for the VPNaaS namespace, so a VPN gateway"},{"line_number":58,"context_line":"port is created in the external network of the router."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"To connect the router with the namespace a \"Transit network\" (169.254.0.0/30)"},{"line_number":61,"context_line":"is created and attached to the router. It is used to route traffic between"},{"line_number":62,"context_line":"virtual machine network(s) and the VPN process namespace. The respective routes"},{"line_number":63,"context_line":"added to the router are (per peer CIDR):"},{"line_number":64,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"97840bc9_65f4bb5c","line":61,"range":{"start_line":60,"start_character":0,"end_line":61,"end_character":39},"in_reply_to":"2097b1eb_c540f3a4","updated":"2021-01-14 15:42:35.000000000","message":"In our current proposed implementation the transit network and the extra gateway port are only visible to admin. The extra routes added to the router will be visible to the user. That\u0027s why the \"transit subnet\" is put into the user project too. I understand this may be debatable, but we thought to make it visible to somehow explain the extra routes, which we cannot hide.","commit_id":"baf3b055abf005b6f40b41193959f190fc432a44"},{"author":{"_account_id":841,"name":"Akihiro Motoki","email":"amotoki@gmail.com","username":"amotoki"},"change_message_id":"8433599d3d8e464d33cd15d4c23983f50fa6ad9b","unresolved":true,"context_lines":[{"line_number":57,"context_line":"A new public IP address is needed for the VPNaaS namespace, so a VPN gateway"},{"line_number":58,"context_line":"port is created in the external network of the router."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"To connect the router with the namespace a \"Transit network\" (169.254.0.0/30)"},{"line_number":61,"context_line":"is created and attached to the router. It is used to route traffic between"},{"line_number":62,"context_line":"virtual machine network(s) and the VPN process namespace. The respective routes"},{"line_number":63,"context_line":"added to the router are (per peer CIDR):"},{"line_number":64,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"c9e43c25_ad4fd6e3","line":61,"range":{"start_line":60,"start_character":0,"end_line":61,"end_character":39},"in_reply_to":"97840bc9_65f4bb5c","updated":"2021-01-14 18:08:38.000000000","message":"I am not sure which is better to make \"transit subnet\" visible to users. From user perspective, users will see at least \"transit subnet\" OR \"extra routes\" in a router. Users do not create both of them, so they could be confused. \n\nIf \"transit subnet\" is visible to users, users potentialy specifies it for other use cases (for example, a subnet when creating a port, a subnet for a router interface) as it is included in a subnet list.\n\nI am not sure which is better: (a) to make \"transit subnet\" visible to users, or (b) to make \"extra routes to a peer CIDR in a router\" without exposign \"transit subnet\", or (c) any other options.\n\nAt the moment my vote is (b) but I would like to hear more opinions from the author and other reviews.","commit_id":"baf3b055abf005b6f40b41193959f190fc432a44"},{"author":{"_account_id":841,"name":"Akihiro Motoki","email":"amotoki@gmail.com","username":"amotoki"},"change_message_id":"7cddea3d75e893f990f302950a9647bd3291ea33","unresolved":true,"context_lines":[{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Naming of Neutron objects"},{"line_number":83,"context_line":"+++++++++++++++++++++++++"},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"- External gateway port for VPN: \"vpn-gw-{router_id}\" (with device owner"},{"line_number":86,"context_line":"  \"vpn_router_gateway\", device ID is the router ID)"},{"line_number":87,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"ce090902_88eb42cc","line":84,"updated":"2021-01-14 07:16:25.000000000","message":"All device_owner used by neutron internally have \"network:\" prefix.\nIt is better to add \"network:\" prefix.\n\n(Note: \"neutron:\" prefix is also defined in neutron-lib, but according to my search result it is (was) only used by neutron-lbaas and I think it can be dropped now as neutron-lbaas was retired.)","commit_id":"baf3b055abf005b6f40b41193959f190fc432a44"},{"author":{"_account_id":31976,"name":"Bodo Petermann","email":"b.petermann@syseleven.de","username":"bpetermann"},"change_message_id":"acee484cb2e13ef4648a3201dd71333608429719","unresolved":true,"context_lines":[{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Naming of Neutron objects"},{"line_number":83,"context_line":"+++++++++++++++++++++++++"},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"- External gateway port for VPN: \"vpn-gw-{router_id}\" (with device owner"},{"line_number":86,"context_line":"  \"vpn_router_gateway\", device ID is the router ID)"},{"line_number":87,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"47258371_7436bd69","line":84,"in_reply_to":"ce090902_88eb42cc","updated":"2021-01-14 15:42:35.000000000","message":"I updated the spec to use the correct \"network:\" prefix.","commit_id":"baf3b055abf005b6f40b41193959f190fc432a44"},{"author":{"_account_id":841,"name":"Akihiro Motoki","email":"amotoki@gmail.com","username":"amotoki"},"change_message_id":"7cddea3d75e893f990f302950a9647bd3291ea33","unresolved":true,"context_lines":[{"line_number":85,"context_line":"- External gateway port for VPN: \"vpn-gw-{router_id}\" (with device owner"},{"line_number":86,"context_line":"  \"vpn_router_gateway\", device ID is the router ID)"},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"- VPN transit network: \"transit-network4vpn-{router_id}\""},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"- VPN transit subnet: \"transit-subnet4vpn-{router_id}\""},{"line_number":91,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"a6a3b78f_42bc3639","line":88,"range":{"start_line":88,"start_character":32,"end_line":88,"end_character":43},"updated":"2021-01-14 07:16:25.000000000","message":"In our existing device owner naming, we don\u0027t use abbrevs like \"4\". How about using \"-for-\" instead or just \"-network-vpn-\"?\n\n[1] https://opendev.org/openstack/neutron-lib/src/branch/master/neutron_lib/constants.py#L43-L82","commit_id":"baf3b055abf005b6f40b41193959f190fc432a44"},{"author":{"_account_id":31976,"name":"Bodo Petermann","email":"b.petermann@syseleven.de","username":"bpetermann"},"change_message_id":"acee484cb2e13ef4648a3201dd71333608429719","unresolved":true,"context_lines":[{"line_number":85,"context_line":"- External gateway port for VPN: \"vpn-gw-{router_id}\" (with device owner"},{"line_number":86,"context_line":"  \"vpn_router_gateway\", device ID is the router ID)"},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"- VPN transit network: \"transit-network4vpn-{router_id}\""},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"- VPN transit subnet: \"transit-subnet4vpn-{router_id}\""},{"line_number":91,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"ab7ed3b1_0795c4e4","line":88,"range":{"start_line":88,"start_character":32,"end_line":88,"end_character":43},"in_reply_to":"a6a3b78f_42bc3639","updated":"2021-01-14 15:42:35.000000000","message":"I updated the spec (and the proposed implementation) to use the name \"vpn-transit-network-{router_id}\". Similarly for the subnet too.","commit_id":"baf3b055abf005b6f40b41193959f190fc432a44"},{"author":{"_account_id":841,"name":"Akihiro Motoki","email":"amotoki@gmail.com","username":"amotoki"},"change_message_id":"7cddea3d75e893f990f302950a9647bd3291ea33","unresolved":true,"context_lines":[{"line_number":115,"context_line":""},{"line_number":116,"context_line":"VPN namespaces are created by the VPN agent / device driver when the first"},{"line_number":117,"context_line":"IPSec site connection of a router is created and are deleted if all IPSec site"},{"line_number":118,"context_line":"connections of the router were deleted."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Routes are configured in the namespace to route incoming traffic to the local"},{"line_number":121,"context_line":"subnets (destination: local CIDR, next hop: router port of the transit network,"}],"source_content_type":"text/x-rst","patch_set":4,"id":"db9004ba_7ca62589","line":118,"updated":"2021-01-14 07:16:25.000000000","message":"L.78-80 says a (extra) gateway port and a transit network are created when the first VPN service is created, but a VPN namespace is created when the first ipsec site connection is created. Is there any reason we cannot do them at the same timing?\n\n(I didn\u0027t check if only one VPN service can be assigned to one router, but the spec uses a specific CIDR for a transit network for a router, so I assume the relationship between a router and a VPN serivce is 1:1 mapping.)","commit_id":"baf3b055abf005b6f40b41193959f190fc432a44"},{"author":{"_account_id":841,"name":"Akihiro Motoki","email":"amotoki@gmail.com","username":"amotoki"},"change_message_id":"8433599d3d8e464d33cd15d4c23983f50fa6ad9b","unresolved":true,"context_lines":[{"line_number":115,"context_line":""},{"line_number":116,"context_line":"VPN namespaces are created by the VPN agent / device driver when the first"},{"line_number":117,"context_line":"IPSec site connection of a router is created and are deleted if all IPSec site"},{"line_number":118,"context_line":"connections of the router were deleted."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Routes are configured in the namespace to route incoming traffic to the local"},{"line_number":121,"context_line":"subnets (destination: local CIDR, next hop: router port of the transit network,"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5f190c60_0c8c2ec3","line":118,"in_reply_to":"3e412c8d_2096f342","updated":"2021-01-14 18:08:38.000000000","message":"Thanks for the clarification. My memory is ambiguous in several points. Your reply clarifies the situation and it totally sounds reasonable to me.","commit_id":"baf3b055abf005b6f40b41193959f190fc432a44"},{"author":{"_account_id":31976,"name":"Bodo Petermann","email":"b.petermann@syseleven.de","username":"bpetermann"},"change_message_id":"acee484cb2e13ef4648a3201dd71333608429719","unresolved":true,"context_lines":[{"line_number":115,"context_line":""},{"line_number":116,"context_line":"VPN namespaces are created by the VPN agent / device driver when the first"},{"line_number":117,"context_line":"IPSec site connection of a router is created and are deleted if all IPSec site"},{"line_number":118,"context_line":"connections of the router were deleted."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Routes are configured in the namespace to route incoming traffic to the local"},{"line_number":121,"context_line":"subnets (destination: local CIDR, next hop: router port of the transit network,"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3e412c8d_2096f342","line":118,"in_reply_to":"db9004ba_7ca62589","updated":"2021-01-14 15:42:35.000000000","message":"The gateway port and transit network are created with the VPN service to be able to include the external_v4_ip/external_v6_ip when the creation finishes.\nOn the other hand the agent is only notified on site connection changes. That\u0027s an approach we kept from the original VPNaaS plugin. The Swan process will only be created if there is some ipsec site connection. We only add the namespace creation.\n\nOn the relationship router / VPN service(s): The original VPNaaS implementation only supports a 1:1 mapping (max 1 VPN service per router). Changes to allow an 1:n relationship are not covered by this spec now. We would like to allow that in the future too, but might address that in a separate RFE. But even multiple VPN services on the same router could share the transit network and the extra gateway port. That\u0027s why the specific CIDR should be fine.","commit_id":"baf3b055abf005b6f40b41193959f190fc432a44"},{"author":{"_account_id":841,"name":"Akihiro Motoki","email":"amotoki@gmail.com","username":"amotoki"},"change_message_id":"7cddea3d75e893f990f302950a9647bd3291ea33","unresolved":true,"context_lines":[{"line_number":130,"context_line":"    - vgxxxxxxxx-xxx, where xxxxxxxx-xxx is the prefix of the port UUID of the"},{"line_number":131,"context_line":"      VPN external gateway port (IP address in the external network)"},{"line_number":132,"context_line":"    - vrxxxxxxxx-xxx, where xxxxxxxx-xxx is the prefix of the port UUID of the"},{"line_number":133,"context_line":"      VPN transit network port (169.254.0.2)"},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"3. plug the two interfaces"},{"line_number":136,"context_line":"4. add routes"}],"source_content_type":"text/x-rst","patch_set":4,"id":"4bd1f9cf_ca4b2e12","line":133,"updated":"2021-01-14 07:16:25.000000000","message":"nit: The indent of L.130-133 needs to align with \"create\" at L.128. Otherwise, we will see unnecessary vertical line [1].\n\n[1] https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_708/767292/4/check/openstack-tox-docs/708e1f4/docs/specs/wallaby/vpnaas-ovn.html#vpn-namespace-management","commit_id":"baf3b055abf005b6f40b41193959f190fc432a44"},{"author":{"_account_id":31976,"name":"Bodo Petermann","email":"b.petermann@syseleven.de","username":"bpetermann"},"change_message_id":"acee484cb2e13ef4648a3201dd71333608429719","unresolved":true,"context_lines":[{"line_number":130,"context_line":"    - vgxxxxxxxx-xxx, where xxxxxxxx-xxx is the prefix of the port UUID of the"},{"line_number":131,"context_line":"      VPN external gateway port (IP address in the external network)"},{"line_number":132,"context_line":"    - vrxxxxxxxx-xxx, where xxxxxxxx-xxx is the prefix of the port UUID of the"},{"line_number":133,"context_line":"      VPN transit network port (169.254.0.2)"},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"3. plug the two interfaces"},{"line_number":136,"context_line":"4. add routes"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fed96e5d_b2a53ffb","line":133,"in_reply_to":"4bd1f9cf_ca4b2e12","updated":"2021-01-14 15:42:35.000000000","message":"I fixed it","commit_id":"baf3b055abf005b6f40b41193959f190fc432a44"}]}