)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":3153,"name":"Emilien Macchi","email":"emilien@redhat.com","username":"emilienm"},"change_message_id":"7fec495e0f087939d9ce0d0dc6758792c45716f9","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Spec for network data v2 format"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Change-Id: I868a86722f5899ca9ba456af780cb99526ab6ee3"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"9f560f44_81021e0b","line":9,"updated":"2020-09-21 20:37:50.000000000","message":"please rebase on top of https://review.opendev.org/753139","commit_id":"4690f4edeaf8412f04289d9de3ff1e81abb52b07"}],"specs/victoria/triplo-network-data-v2.rst":[{"author":{"_account_id":18575,"name":"Saravanan KR","email":"krsacme@gmail.com","username":"saravanankr"},"change_message_id":"2b1f006cec766222a79b9b107de2a48c20724e14","unresolved":false,"context_lines":[{"line_number":79,"context_line":"Example network data v2 file for IPv4"},{"line_number":80,"context_line":"^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^"},{"line_number":81,"context_line":""},{"line_number":82,"context_line":".. code-block:: yaml"},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"    - name: Storage"},{"line_number":85,"context_line":"      name_lower: storage                         (optional, default: name.lower())"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9f560f44_17432713","line":82,"updated":"2020-09-17 12:19:18.000000000","message":"given a network_data file, how to identify if it is v1 or v2? is the format validation of v2 will be strict - meaning if there are extra parameters which are specific to v1 added to v2 file, then it should be treated as invalid format.","commit_id":"c713af04eedffe3f765b3d78746169e54278c7ac"},{"author":{"_account_id":24245,"name":"Harald Jensås","email":"hjensas@redhat.com","username":"harald.jensas"},"change_message_id":"dfeafefe51ae107f4bd7b8857905e949deaf0439","unresolved":false,"context_lines":[{"line_number":79,"context_line":"Example network data v2 file for IPv4"},{"line_number":80,"context_line":"^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^"},{"line_number":81,"context_line":""},{"line_number":82,"context_line":".. code-block:: yaml"},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"    - name: Storage"},{"line_number":85,"context_line":"      name_lower: storage                         (optional, default: name.lower())"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9f560f44_b70a361b","line":82,"in_reply_to":"9f560f44_17432713","updated":"2020-09-17 15:09:48.000000000","message":"I\u0027m open to suggestions.\n\nI was thinking some simple validations in the new tooling, i.e fail if v1 only key is present.\n\nBut we add a version key, and move the list of networks under a \u0027networks\u0027 key in the root?","commit_id":"c713af04eedffe3f765b3d78746169e54278c7ac"},{"author":{"_account_id":18575,"name":"Saravanan KR","email":"krsacme@gmail.com","username":"saravanankr"},"change_message_id":"2b1f006cec766222a79b9b107de2a48c20724e14","unresolved":false,"context_lines":[{"line_number":84,"context_line":"    - name: Storage"},{"line_number":85,"context_line":"      name_lower: storage                         (optional, default: name.lower())"},{"line_number":86,"context_line":"      admin_state_up: false                       (optional, default: false)"},{"line_number":87,"context_line":"      dns_domain: storage.localdomain."},{"line_number":88,"context_line":"      mtu: 1442                                   (optional, default: 1500)"},{"line_number":89,"context_line":"      shared: false                               (optional, default: false)"},{"line_number":90,"context_line":"      subnets:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9f560f44_dc6d5404","line":87,"range":{"start_line":87,"start_character":26,"end_line":87,"end_character":37},"updated":"2020-09-17 12:19:18.000000000","message":"is this localdomain as defined in the undercloud.conf? can we not use it from undercloud.conf?","commit_id":"c713af04eedffe3f765b3d78746169e54278c7ac"},{"author":{"_account_id":24245,"name":"Harald Jensås","email":"hjensas@redhat.com","username":"harald.jensas"},"change_message_id":"76c0c1d893085244ef8e323718f80240da4b10b7","unresolved":false,"context_lines":[{"line_number":84,"context_line":"    - name: Storage"},{"line_number":85,"context_line":"      name_lower: storage                         (optional, default: name.lower())"},{"line_number":86,"context_line":"      admin_state_up: false                       (optional, default: false)"},{"line_number":87,"context_line":"      dns_domain: storage.localdomain."},{"line_number":88,"context_line":"      mtu: 1442                                   (optional, default: 1500)"},{"line_number":89,"context_line":"      shared: false                               (optional, default: false)"},{"line_number":90,"context_line":"      subnets:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9f560f44_73a18e95","line":87,"range":{"start_line":87,"start_character":26,"end_line":87,"end_character":37},"in_reply_to":"9f560f44_5492b8fd","updated":"2020-09-22 13:07:33.000000000","message":"Using overcloud_domain_name as defined in undercloud.conf might be a good idea?\n\nThe parameter description says taht CloudDomain must match the overcloud_domain_name configured in undercloud.conf.\n\nWe could then make this optional in network data v2, and set it to:\n  $name_lower + undercloud_conf.get(\u0027overcloud_domain_name\u0027)\n\nShould tripleoclient set CloudDomain in the plan environment based on the undercloud.conf setting, so that the operator only need to set it once in undercloud.conf?\n\n  CloudDomain:\n    default: \u0027localdomain\u0027\n    type: string\n    description: \u003e\n      The DNS domain used for the hosts. This must match the\n      overcloud_domain_name configured on the undercloud.","commit_id":"c713af04eedffe3f765b3d78746169e54278c7ac"},{"author":{"_account_id":24245,"name":"Harald Jensås","email":"hjensas@redhat.com","username":"harald.jensas"},"change_message_id":"dfeafefe51ae107f4bd7b8857905e949deaf0439","unresolved":false,"context_lines":[{"line_number":84,"context_line":"    - name: Storage"},{"line_number":85,"context_line":"      name_lower: storage                         (optional, default: name.lower())"},{"line_number":86,"context_line":"      admin_state_up: false                       (optional, default: false)"},{"line_number":87,"context_line":"      dns_domain: storage.localdomain."},{"line_number":88,"context_line":"      mtu: 1442                                   (optional, default: 1500)"},{"line_number":89,"context_line":"      shared: false                               (optional, default: false)"},{"line_number":90,"context_line":"      subnets:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9f560f44_5492b8fd","line":87,"range":{"start_line":87,"start_character":26,"end_line":87,"end_character":37},"in_reply_to":"9f560f44_dc6d5404","updated":"2020-09-17 15:09:48.000000000","message":"The exporter[1] will put what is in the networks \u0027dns_domain\u0027. For a TripleO deployment this will be \"{{network.name.lower()}} + \u0027.\u0027 + {get_param: CloudDomain} + \u0027.\u0027\" today.\n\nWe don\u0027t use this attribute for anything, so this should be (optional with \u0027null\u0027 as default.)\n\n[1] https://review.opendev.org/#/c/750671/5/tripleo_ansible/ansible_plugins/modules/tripleo_overcloud_network_extract_provisioned.py","commit_id":"c713af04eedffe3f765b3d78746169e54278c7ac"},{"author":{"_account_id":18575,"name":"Saravanan KR","email":"krsacme@gmail.com","username":"saravanankr"},"change_message_id":"2b1f006cec766222a79b9b107de2a48c20724e14","unresolved":false,"context_lines":[{"line_number":87,"context_line":"      dns_domain: storage.localdomain."},{"line_number":88,"context_line":"      mtu: 1442                                   (optional, default: 1500)"},{"line_number":89,"context_line":"      shared: false                               (optional, default: false)"},{"line_number":90,"context_line":"      subnets:"},{"line_number":91,"context_line":"        subnet01:"},{"line_number":92,"context_line":"          ip_subnet: 172.18.1.0/24"},{"line_number":93,"context_line":"          gateway_ip: 172.18.1.254                (optional, default: null)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9f560f44_fc43f86a","line":90,"updated":"2020-09-17 12:19:18.000000000","message":"why it should be a map instead of list?","commit_id":"c713af04eedffe3f765b3d78746169e54278c7ac"},{"author":{"_account_id":24245,"name":"Harald Jensås","email":"hjensas@redhat.com","username":"harald.jensas"},"change_message_id":"dfeafefe51ae107f4bd7b8857905e949deaf0439","unresolved":false,"context_lines":[{"line_number":87,"context_line":"      dns_domain: storage.localdomain."},{"line_number":88,"context_line":"      mtu: 1442                                   (optional, default: 1500)"},{"line_number":89,"context_line":"      shared: false                               (optional, default: false)"},{"line_number":90,"context_line":"      subnets:"},{"line_number":91,"context_line":"        subnet01:"},{"line_number":92,"context_line":"          ip_subnet: 172.18.1.0/24"},{"line_number":93,"context_line":"          gateway_ip: 172.18.1.254                (optional, default: null)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9f560f44_b4f074dc","line":90,"in_reply_to":"9f560f44_fc43f86a","updated":"2020-09-17 15:09:48.000000000","message":"The current network data format uses a map for additional subnets.","commit_id":"c713af04eedffe3f765b3d78746169e54278c7ac"},{"author":{"_account_id":18575,"name":"Saravanan KR","email":"krsacme@gmail.com","username":"saravanankr"},"change_message_id":"2b1f006cec766222a79b9b107de2a48c20724e14","unresolved":false,"context_lines":[{"line_number":124,"context_line":"      dns_domain: storage.localdomain."},{"line_number":125,"context_line":"      mtu: 1442"},{"line_number":126,"context_line":"      shared: false"},{"line_number":127,"context_line":"      subnets:"},{"line_number":128,"context_line":"        subnet01:"},{"line_number":129,"context_line":"          ipv6_subnet: 2001:db8:a::/64"},{"line_number":130,"context_line":"          gateway_ipv6: 2001:db8:a::1"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9f560f44_3710eb4f","line":127,"updated":"2020-09-17 12:19:18.000000000","message":"can subnets be mixed ipv4 and ipv6?","commit_id":"c713af04eedffe3f765b3d78746169e54278c7ac"},{"author":{"_account_id":24245,"name":"Harald Jensås","email":"hjensas@redhat.com","username":"harald.jensas"},"change_message_id":"dfeafefe51ae107f4bd7b8857905e949deaf0439","unresolved":false,"context_lines":[{"line_number":124,"context_line":"      dns_domain: storage.localdomain."},{"line_number":125,"context_line":"      mtu: 1442"},{"line_number":126,"context_line":"      shared: false"},{"line_number":127,"context_line":"      subnets:"},{"line_number":128,"context_line":"        subnet01:"},{"line_number":129,"context_line":"          ipv6_subnet: 2001:db8:a::/64"},{"line_number":130,"context_line":"          gateway_ipv6: 2001:db8:a::1"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9f560f44_74b6dcfb","line":127,"in_reply_to":"9f560f44_3710eb4f","updated":"2020-09-17 15:09:48.000000000","message":"One subnet is either IPv4 or IPv6 in neutron.\nYou can have a network with IPv4 and IPv6 subnets.\nThe current WIP implementation will create two subnets, one IPv4 and one IPv6 info is provided in network_data.","commit_id":"c713af04eedffe3f765b3d78746169e54278c7ac"},{"author":{"_account_id":8833,"name":"Rabi Mishra","email":"ramishra@redhat.com","username":"rabi"},"change_message_id":"fed17dcc82cee6005a90bc751ee6e1caf7cfc3e6","unresolved":false,"context_lines":[{"line_number":189,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"The goal of moving management of the network resources outside of the"},{"line_number":192,"context_line":"overcloud heat stack is to improve performance by reducing the number"},{"line_number":193,"context_line":"of heat resources."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9f560f44_dcb8b476","line":192,"range":{"start_line":192,"start_character":21,"end_line":192,"end_character":46},"updated":"2020-09-17 12:03:12.000000000","message":"This is not really a performance thing. Creating these resources in heat is lightweight. It\u0027s probably our intent of reducing usage of heat, aligned with our end goal of removing it from undercloud. Also, may be providing a better user experience with the new format and new tooling (as mentioned above).","commit_id":"c713af04eedffe3f765b3d78746169e54278c7ac"},{"author":{"_account_id":24245,"name":"Harald Jensås","email":"hjensas@redhat.com","username":"harald.jensas"},"change_message_id":"8b9146f4687f01c3daa09e902ce8ea5b49914a3e","unresolved":false,"context_lines":[{"line_number":189,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"The goal of moving management of the network resources outside of the"},{"line_number":192,"context_line":"overcloud heat stack is to improve performance by reducing the number"},{"line_number":193,"context_line":"of heat resources."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9f560f44_17be87ff","line":192,"range":{"start_line":192,"start_character":21,"end_line":192,"end_character":46},"in_reply_to":"9f560f44_dcb8b476","updated":"2020-09-17 12:18:08.000000000","message":"ack, I removed this text. This does\u0027nt affect performance as such.","commit_id":"c713af04eedffe3f765b3d78746169e54278c7ac"},{"author":{"_account_id":18575,"name":"Saravanan KR","email":"krsacme@gmail.com","username":"saravanankr"},"change_message_id":"2b1f006cec766222a79b9b107de2a48c20724e14","unresolved":false,"context_lines":[{"line_number":200,"context_line":"to export network information from existing deployments as well as"},{"line_number":201,"context_line":"procedures to provision/update/adopt network resources with the non-heat stack"},{"line_number":202,"context_line":"tooling must be provided."},{"line_number":203,"context_line":""},{"line_number":204,"context_line":""},{"line_number":205,"context_line":"Implementation"},{"line_number":206,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9f560f44_979bb7c6","line":203,"updated":"2020-09-17 12:19:18.000000000","message":"Can the list heat parameters which are unified (removed from heat and added to network data) with this approach can be stated here?","commit_id":"c713af04eedffe3f765b3d78746169e54278c7ac"},{"author":{"_account_id":12398,"name":"Dan Sneddon","email":"dsneddon@redhat.com","username":"dsneddon"},"change_message_id":"2f2f7a182eb3d14d06540561ce124895aab2b4b9","unresolved":false,"context_lines":[{"line_number":24,"context_line":"The current schema is somewhat inconsistent, and not as precice as it could"},{"line_number":25,"context_line":"be. For example the ``base`` subnet being at level-0, while additional"},{"line_number":26,"context_line":"subnets are in the ``subnets`` map. It would be more intuitive to define"},{"line_number":27,"context_line":"all subnets in the ``subnets`` map. Other keys such as the ``vip`` boolean"},{"line_number":28,"context_line":"is also at level-0, which means we do not know which subnet the virtual IP"},{"line_number":29,"context_line":"address should be created in."},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"Currently the network resource properties are configured via a mix of"},{"line_number":32,"context_line":"parameters in the heat environment and network data. For example"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9f560f44_7a9fe301","line":29,"range":{"start_line":27,"start_character":36,"end_line":29,"end_character":29},"updated":"2020-09-17 17:58:55.000000000","message":"As explained below, if we make \"vip\" a boolean at the subnet level, it would be possible to set \"vip: true\" on multiple subnets, which is not a valid configuration.","commit_id":"424e2b143f1182b035e835d6b659b26b2103a3cf"},{"author":{"_account_id":12398,"name":"Dan Sneddon","email":"dsneddon@redhat.com","username":"dsneddon"},"change_message_id":"2f2f7a182eb3d14d06540561ce124895aab2b4b9","unresolved":false,"context_lines":[{"line_number":68,"context_line":""},{"line_number":69,"context_line":".. code-block:: shell"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"    openstack overcloud network export provisioned --stack \u003cstack_name\u003e --output \u003cnetwork_data_v2.yaml\u003e"},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"Command to create/update overcloud networks outside of heat."},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9f560f44_fa2653cb","line":71,"range":{"start_line":71,"start_character":0,"end_line":71,"end_character":103},"updated":"2020-09-17 17:58:55.000000000","message":"Do we need both \"export\" and \"provisioned\"? Would there be a case where one would use \"export\" without \"provisioned\" or with a different parameter? This might be sufficient:\n\nopenstack overcloud network export --stack \u003cstack_name\u003e --output \u003cnetwork_data_v2.yaml\u003e","commit_id":"424e2b143f1182b035e835d6b659b26b2103a3cf"},{"author":{"_account_id":24245,"name":"Harald Jensås","email":"hjensas@redhat.com","username":"harald.jensas"},"change_message_id":"f66612ebc5cb032fcaa773e9a0638cf230795a14","unresolved":false,"context_lines":[{"line_number":68,"context_line":""},{"line_number":69,"context_line":".. code-block:: shell"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"    openstack overcloud network export provisioned --stack \u003cstack_name\u003e --output \u003cnetwork_data_v2.yaml\u003e"},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"Command to create/update overcloud networks outside of heat."},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9f560f44_1e4a0d82","line":71,"range":{"start_line":71,"start_character":0,"end_line":71,"end_character":103},"in_reply_to":"9f560f44_fa2653cb","updated":"2020-09-18 11:37:15.000000000","message":"We might need \"export ports\", \"export vips\"?\n\n\"provisioned\" might have been a bad choise. Should we go for\n\n\"openstack network export networks\"\n\n?","commit_id":"424e2b143f1182b035e835d6b659b26b2103a3cf"},{"author":{"_account_id":24245,"name":"Harald Jensås","email":"hjensas@redhat.com","username":"harald.jensas"},"change_message_id":"f66612ebc5cb032fcaa773e9a0638cf230795a14","unresolved":false,"context_lines":[{"line_number":74,"context_line":""},{"line_number":75,"context_line":".. code-block:: shell"},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"    openstack overcloud network provision -networks-file \u003cnetwork_data_v2.yaml\u003e --output \u003cnetwork_environment.yaml\u003e"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"Example network data v2 file for IPv4"},{"line_number":80,"context_line":"^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9f560f44_5e448574","line":77,"range":{"start_line":77,"start_character":4,"end_line":77,"end_character":42},"updated":"2020-09-18 11:37:15.000000000","message":"Do we need opening for provisioning other stuff? \n\n\"openstack network provsion networks\"\n\"openstack network provsion vips\"\n\"openstack network provsion ports\"","commit_id":"424e2b143f1182b035e835d6b659b26b2103a3cf"},{"author":{"_account_id":12398,"name":"Dan Sneddon","email":"dsneddon@redhat.com","username":"dsneddon"},"change_message_id":"2f2f7a182eb3d14d06540561ce124895aab2b4b9","unresolved":false,"context_lines":[{"line_number":98,"context_line":"          routes:                                 (optional, default: [])"},{"line_number":99,"context_line":"            - destination: 172.18.0.0/24"},{"line_number":100,"context_line":"              nexthop: 172.18.1.254"},{"line_number":101,"context_line":"          vip: true                               (optional, default: false)"},{"line_number":102,"context_line":"          vlan: 21                                (optional, default: null)"},{"line_number":103,"context_line":"        subnet02:"},{"line_number":104,"context_line":"          ip_subnet: 172.18.0.0/24"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9f560f44_3af0cb66","line":101,"range":{"start_line":101,"start_character":0,"end_line":101,"end_character":76},"updated":"2020-09-17 17:58:55.000000000","message":"One issue with making \"vip\" a boolean at the subnet level is that this would make it possible to set \"vip: true\" on multiple subnets, which is not a valid configuration.\n\nI wonder if instead we should make \"vip\" a top-level string parameter (perhaps \"vip_subnet\" with a default of None). This way it is only possible to set the VIP on a single subnet.\n\nAnother option is to break this into two top-level parameters, \"vip\" (boolean) and \"vip_subnet\" (string).\n\nOr we keep \"vip\" as a top-level boolean, but resolve the correct subnet automatically based on which subnet the API controller is placed on (which might get complicated).","commit_id":"424e2b143f1182b035e835d6b659b26b2103a3cf"},{"author":{"_account_id":24245,"name":"Harald Jensås","email":"hjensas@redhat.com","username":"harald.jensas"},"change_message_id":"f66612ebc5cb032fcaa773e9a0638cf230795a14","unresolved":false,"context_lines":[{"line_number":98,"context_line":"          routes:                                 (optional, default: [])"},{"line_number":99,"context_line":"            - destination: 172.18.0.0/24"},{"line_number":100,"context_line":"              nexthop: 172.18.1.254"},{"line_number":101,"context_line":"          vip: true                               (optional, default: false)"},{"line_number":102,"context_line":"          vlan: 21                                (optional, default: null)"},{"line_number":103,"context_line":"        subnet02:"},{"line_number":104,"context_line":"          ip_subnet: 172.18.0.0/24"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9f560f44_1e616d12","line":101,"range":{"start_line":101,"start_character":0,"end_line":101,"end_character":76},"in_reply_to":"9f560f44_3af0cb66","updated":"2020-09-18 11:37:15.000000000","message":"Right, I was thinking we could validate it. Or even allow different services to be in different segments with their own vip etc.\n\nResolving the subnet automatically would be better, or even create the VIP only if a service that require a VIP on the network exist. I.e move VIP creation to the services config instead.\n\nLet\u0027s just keep the \u0027vip\u0027 a boolean on the network level.","commit_id":"424e2b143f1182b035e835d6b659b26b2103a3cf"},{"author":{"_account_id":12398,"name":"Dan Sneddon","email":"dsneddon@redhat.com","username":"dsneddon"},"change_message_id":"2f2f7a182eb3d14d06540561ce124895aab2b4b9","unresolved":false,"context_lines":[{"line_number":157,"context_line":"Example network data v2 file for dual stack"},{"line_number":158,"context_line":"^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^"},{"line_number":159,"context_line":""},{"line_number":160,"context_line":".. note:: Dual IPv4/IPv6 with two subnets per-segment, one for IPv4 and the"},{"line_number":161,"context_line":"          other for IPv6. A single neutron port with an IP address in each"},{"line_number":162,"context_line":"          subnet can be created."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"In this case ``ipv6`` key will control weather services are configured to"},{"line_number":165,"context_line":"bind to IPv6 or IPv4. (default ipv6: false)"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9f560f44_a0330ef7","line":162,"range":{"start_line":160,"start_character":0,"end_line":162,"end_character":32},"updated":"2020-09-17 17:58:55.000000000","message":"This model still supports only one IPv4 or IPv6 subnet per segment, but would add the option to have one of each per segment (leaf). I think this limitation is probably necessary to preserve backward-compatibility and reduce complexity. There have been some inquiries from users about whether it is possible to add additional subnets to an existing segment once all available IP addresses have been exhausted. I think the correct approach there is to add additional segments/leaves and additional roles, but we might want to explicitly call out this limitation and the reasons for it.","commit_id":"424e2b143f1182b035e835d6b659b26b2103a3cf"},{"author":{"_account_id":24245,"name":"Harald Jensås","email":"hjensas@redhat.com","username":"harald.jensas"},"change_message_id":"f66612ebc5cb032fcaa773e9a0638cf230795a14","unresolved":false,"context_lines":[{"line_number":157,"context_line":"Example network data v2 file for dual stack"},{"line_number":158,"context_line":"^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^"},{"line_number":159,"context_line":""},{"line_number":160,"context_line":".. note:: Dual IPv4/IPv6 with two subnets per-segment, one for IPv4 and the"},{"line_number":161,"context_line":"          other for IPv6. A single neutron port with an IP address in each"},{"line_number":162,"context_line":"          subnet can be created."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"In this case ``ipv6`` key will control weather services are configured to"},{"line_number":165,"context_line":"bind to IPv6 or IPv4. (default ipv6: false)"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9f560f44_c15c3a1b","line":162,"range":{"start_line":160,"start_character":0,"end_line":162,"end_character":32},"in_reply_to":"9f560f44_a0330ef7","updated":"2020-09-18 11:37:15.000000000","message":"We could use a list?\n\nWe would still have the limitation on the ctlplane, and we would still need one role per subnet.\n\nUsing a list we could also drop the \u0027ipv6\u0027 prefixed/suffixed options?\n\n\n    - name: Storage\n      segments:\n        segment01:\n          vlan: 21\n          subnets:\n            - name:\n              ip_subnet: 172.18.1.0/24\n              gateway_ip: 172.18.1.254\n              allocation_pools:\n                - start: 172.18.1.10\n                  end: 172.18.1.250\n              routes:\n                - destination: 172.18.0.0/24\n                  nexthop: 172.18.1.254\n            - ip_subnet: 2001:db8:a::/64\n              gateway_ip: 2001:db8:a::1\n              allocation_pools:\n                - start: 2001:db8:a::0010\n                  end: 2001:db8:a::fff9\n              routes:\n                - destination: 2001:db8:b::/64\n                  nexthop: 2001:db8:a::1\n        segment02:\n          vlan: 20\n          subnets:\n            - ip_subnet: 172.18.0.0/24\n              gateway_ip: 172.18.0.254\n              allocation_pools:\n                - start: 172.18.0.10\n                  end: 172.18.0.250\n              routes:\n                - destination: 172.18.1.0/24\n                  nexthop: 172.18.0.254\n            - ip_subnet: 2001:db8:b::/64\n              gateway_ip: 2001:db8:b::1\n              allocation_pools:\n                - start: 2001:db8:b::0010\n                  end: 2001:db8:b::fff9\n              routes:\n                - destination: 2001:db8:a::/64\n                  nexthop: 2001:db8:b::1","commit_id":"424e2b143f1182b035e835d6b659b26b2103a3cf"},{"author":{"_account_id":3153,"name":"Emilien Macchi","email":"emilien@redhat.com","username":"emilienm"},"change_message_id":"7fec495e0f087939d9ce0d0dc6758792c45716f9","unresolved":false,"context_lines":[{"line_number":71,"context_line":""},{"line_number":72,"context_line":".. code-block:: shell"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"    openstack overcloud network export networks \\"},{"line_number":75,"context_line":"      --stack \u003cstack_name\u003e \\"},{"line_number":76,"context_line":"      --output \u003cnetwork_data_v2.yaml\u003e"},{"line_number":77,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f560f44_1c467122","line":74,"range":{"start_line":74,"start_character":39,"end_line":74,"end_character":47},"updated":"2020-09-21 20:37:50.000000000","message":"i would remove \"networks\"","commit_id":"4690f4edeaf8412f04289d9de3ff1e81abb52b07"},{"author":{"_account_id":24245,"name":"Harald Jensås","email":"hjensas@redhat.com","username":"harald.jensas"},"change_message_id":"387cfbf65b0a00b0b705e6a5d0ad88404321a154","unresolved":false,"context_lines":[{"line_number":71,"context_line":""},{"line_number":72,"context_line":".. code-block:: shell"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"    openstack overcloud network export networks \\"},{"line_number":75,"context_line":"      --stack \u003cstack_name\u003e \\"},{"line_number":76,"context_line":"      --output \u003cnetwork_data_v2.yaml\u003e"},{"line_number":77,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f560f44_7ca68d56","line":74,"range":{"start_line":74,"start_character":39,"end_line":74,"end_character":47},"in_reply_to":"9f560f44_1c467122","updated":"2020-09-21 20:48:25.000000000","message":"yeah, the commands I find it hard to decide.\n\nI was thinking an opening for \u0027network export ports|vips\u0027 \u0027network provision ports|vips\u0027. But we may just do \u0027overcloud ports|vip export|provison\u0027 if we ever need that.\n\nI will update the spec and patches tomorrow.","commit_id":"4690f4edeaf8412f04289d9de3ff1e81abb52b07"},{"author":{"_account_id":3153,"name":"Emilien Macchi","email":"emilien@redhat.com","username":"emilienm"},"change_message_id":"7fec495e0f087939d9ce0d0dc6758792c45716f9","unresolved":false,"context_lines":[{"line_number":79,"context_line":""},{"line_number":80,"context_line":".. code-block:: shell"},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"    openstack overcloud network provision networks \\"},{"line_number":83,"context_line":"      --networks-file \u003cnetwork_data_v2.yaml\u003e \\"},{"line_number":84,"context_line":"      --output \u003cnetwork_environment.yaml\u003e"},{"line_number":85,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f560f44_9c63a1b1","line":82,"range":{"start_line":82,"start_character":42,"end_line":82,"end_character":50},"updated":"2020-09-21 20:37:50.000000000","message":"i would remove \"networks\", for metalsmith we already have \"openstack overcloud node provision\".","commit_id":"4690f4edeaf8412f04289d9de3ff1e81abb52b07"},{"author":{"_account_id":3153,"name":"Emilien Macchi","email":"emilien@redhat.com","username":"emilienm"},"change_message_id":"7fec495e0f087939d9ce0d0dc6758792c45716f9","unresolved":false,"context_lines":[{"line_number":278,"context_line":"Upgrade Impact"},{"line_number":279,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":280,"context_line":""},{"line_number":281,"context_line":"When (iff) we remove the capability to manage network resources in the"},{"line_number":282,"context_line":"overcloud heat stack, the user must run the export command to generate"},{"line_number":283,"context_line":"a new network data v2 file. Use this file as input to the ``openstack"},{"line_number":284,"context_line":"overcloud network provision`` command, to generate the environment file"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f560f44_bc8dc52b","line":281,"range":{"start_line":281,"start_character":6,"end_line":281,"end_character":9},"updated":"2020-09-21 20:37:50.000000000","message":"if","commit_id":"4690f4edeaf8412f04289d9de3ff1e81abb52b07"},{"author":{"_account_id":3153,"name":"Emilien Macchi","email":"emilien@redhat.com","username":"emilienm"},"change_message_id":"7fec495e0f087939d9ce0d0dc6758792c45716f9","unresolved":false,"context_lines":[{"line_number":345,"context_line":"  https://review.opendev.org/750671, https://review.opendev.org/750672"},{"line_number":346,"context_line":"* New tooling to provision/update/adopt networks"},{"line_number":347,"context_line":"  https://review.opendev.org/751739, https://review.opendev.org/751875"},{"line_number":348,"context_line":"* Deployed networks tempalte in THT - https://review.opendev.org/751876"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f560f44_dc0d1990","line":348,"range":{"start_line":348,"start_character":20,"end_line":348,"end_character":28},"updated":"2020-09-21 20:37:50.000000000","message":"template","commit_id":"4690f4edeaf8412f04289d9de3ff1e81abb52b07"}]}