)]}'
{"specs/mitaka/approved/trunk-port.rst":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"33a7eae021dc15360cae6a1f45b35ec33cf4a10d","unresolved":false,"context_lines":[{"line_number":38,"context_line":"* legacy VLAN-using applications"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"Project Priority"},{"line_number":41,"context_line":"-----------------"},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"FIXME"},{"line_number":44,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa80f949_0a808845","line":41,"updated":"2015-11-04 20:38:07.000000000","message":"Remove this section.","commit_id":"b7346abaa113a61935a804a84f62d2bd3678fb24"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"e996d1d276505816a824af6e43d78c5ed36c024f","unresolved":false,"context_lines":[{"line_number":51,"context_line":"The neutron blueprint introduces two new \"port types\". One is a new"},{"line_number":52,"context_line":"first class API resource called *trunk port*, which is independent of"},{"line_number":53,"context_line":"the *port* resource. The other is a subtype of the *port* resource,"},{"line_number":54,"context_line":"extending that with new attributes. Here we will refer to it as *subport*."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"From nova\u0027s perspective the trunk port is similar to a plain old port, at"},{"line_number":57,"context_line":"instance boot one vNIC is created for each trunk port of an instance. The"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba8a016a_882a562b","line":54,"updated":"2015-11-23 02:21:01.000000000","message":"Note that it seems to be still undecided whether a trunk port will actually be a new first class API resource or whether it should/will be simply the regular port API resource with some extended attributes on it.","commit_id":"b7346abaa113a61935a804a84f62d2bd3678fb24"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"33a7eae021dc15360cae6a1f45b35ec33cf4a10d","unresolved":false,"context_lines":[{"line_number":91,"context_line":""},{"line_number":92,"context_line":"We foresee the following changes needed:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"* ``nova boot --nic trunk-port-id``"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"We intend to omit support analogous to ``nova boot --nic net-id``,"},{"line_number":97,"context_line":"because we see it needs overly complicated syntax and also unnecessary."}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa80f949_aad29cfe","line":94,"updated":"2015-11-04 20:38:07.000000000","message":"Given we don\u0027t want to proxy more things to other services, couldn\u0027t we assume that if it comes in from the API we query neutron for the port details and that tells us if it\u0027s an old style port or a trunk port and do whatever as needed?  If a port id isn\u0027t provided, nova only creates an old style port as it does today - so people have to opt into using the new trunk port stuff by doing it in neutron first and providing it to nova API on boot as needed.  People that like nova orchestrating things though might balk at that idea.","commit_id":"b7346abaa113a61935a804a84f62d2bd3678fb24"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"e996d1d276505816a824af6e43d78c5ed36c024f","unresolved":false,"context_lines":[{"line_number":91,"context_line":""},{"line_number":92,"context_line":"We foresee the following changes needed:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"* ``nova boot --nic trunk-port-id``"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"We intend to omit support analogous to ``nova boot --nic net-id``,"},{"line_number":97,"context_line":"because we see it needs overly complicated syntax and also unnecessary."}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba8a016a_c8a5beb5","line":94,"updated":"2015-11-23 02:21:01.000000000","message":"This should be:\n\n `nova boot --nic port_id\u003d$port_uuid`\n\nand that would require ZERO changes to the existing user-facing interface.\n\ndocs.openstack.org/cli-reference/content/novaclient_commands.html#novaclient_subcommand_boot","commit_id":"b7346abaa113a61935a804a84f62d2bd3678fb24"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"e996d1d276505816a824af6e43d78c5ed36c024f","unresolved":false,"context_lines":[{"line_number":94,"context_line":"* ``nova boot --nic trunk-port-id``"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"We intend to omit support analogous to ``nova boot --nic net-id``,"},{"line_number":97,"context_line":"because we see it needs overly complicated syntax and also unnecessary."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"Since the trunk port is a new resource, nova (nova-compute) must know to"},{"line_number":100,"context_line":"either query a port or query a trunk port from neutron. Unfortunately"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba8a016a_88afb693","line":97,"updated":"2015-11-23 02:21:01.000000000","message":"Please remove the above paragraph. It is not relevant to this particular blueprint, plus there is no way you can just remove this support without both a separate discussion as well as a deprecation period.","commit_id":"b7346abaa113a61935a804a84f62d2bd3678fb24"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"33a7eae021dc15360cae6a1f45b35ec33cf4a10d","unresolved":false,"context_lines":[{"line_number":100,"context_line":"either query a port or query a trunk port from neutron. Unfortunately"},{"line_number":101,"context_line":"this information (kind of a \"port type\") must come from the API"},{"line_number":102,"context_line":"end-user, because there\u0027s no way to discover this information from"},{"line_number":103,"context_line":"neutron. Therefore nova-api and python-novaclient must be modified to"},{"line_number":104,"context_line":"support booting on a trunk port. nova-compute must be modified to be able"},{"line_number":105,"context_line":"to boot an instance with a trunk port. The only way to get the necessary"},{"line_number":106,"context_line":"information from nova-api to nova-compute is to channel it through. We"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa80f949_ea0f44df","line":103,"updated":"2015-11-04 20:38:07.000000000","message":"Doesn\u0027t the API need to take a port_type field also to tell nova if it\u0027s a \u0027plain old port\u0027 or a trunk_port?\n\nI also see in the neutron changes for this there is debate about whether a new resource model is needed for this or if it can be encapsulated/extended from the existing port resource model, I think that\u0027s going to have to be settled before we can take this spec very seriously.","commit_id":"b7346abaa113a61935a804a84f62d2bd3678fb24"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"e996d1d276505816a824af6e43d78c5ed36c024f","unresolved":false,"context_lines":[{"line_number":105,"context_line":"to boot an instance with a trunk port. The only way to get the necessary"},{"line_number":106,"context_line":"information from nova-api to nova-compute is to channel it through. We"},{"line_number":107,"context_line":"believe nova-scheduler is not affected. All information present at boot"},{"line_number":108,"context_line":"time about trunk ports, must be persisted in nova DB."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"FIXME nova-conductor: Any changes needed?"},{"line_number":111,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba8a016a_28956a3f","line":108,"updated":"2015-11-23 02:21:01.000000000","message":"If Neutron\u0027s GET /ports/{port} call returned information on whether the port had child/subports on it, then there would be no need for either a separate Neutron REST API resource for trunk ports nor would the statement above \"must know to\t either query a port or query a trunk port from neutron\" be necessary.","commit_id":"b7346abaa113a61935a804a84f62d2bd3678fb24"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"e996d1d276505816a824af6e43d78c5ed36c024f","unresolved":false,"context_lines":[{"line_number":107,"context_line":"believe nova-scheduler is not affected. All information present at boot"},{"line_number":108,"context_line":"time about trunk ports, must be persisted in nova DB."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"FIXME nova-conductor: Any changes needed?"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"We want to minimize the changes needed by limiting where \"port type\""},{"line_number":113,"context_line":"is used. It must be used in nova-compute when querying neutron. But we"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba8a016a_48922e59","line":110,"updated":"2015-11-23 02:21:01.000000000","message":"No.","commit_id":"b7346abaa113a61935a804a84f62d2bd3678fb24"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"e996d1d276505816a824af6e43d78c5ed36c024f","unresolved":false,"context_lines":[{"line_number":109,"context_line":""},{"line_number":110,"context_line":"FIXME nova-conductor: Any changes needed?"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"We want to minimize the changes needed by limiting where \"port type\""},{"line_number":113,"context_line":"is used. It must be used in nova-compute when querying neutron. But we"},{"line_number":114,"context_line":"hope its use can be avoided in nova\u0027s virt driver. We hope to keep ports"},{"line_number":115,"context_line":"and trunk ports similar enough (from nova\u0027s perspective), so that nova\u0027s"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba8a016a_c8937e4e","line":112,"updated":"2015-11-23 02:21:01.000000000","message":"There really is no need for a \"port type\", IMHO. Just return something like the following from Neutron main GET /ports/{port} call:\n\n \"port:subports\": {\n   \"has_children\": true,\n   \"_links\": {\n     \"subports\": {\n       \"href\": \"http://example.com/ports/{port_uuid}/subports\",\n       \"templated\": true\n   }\n }\n\nThe above uses JSON+HAL notation to return a mapping (_links) of hyperlinks that further describe the subports subresource. The neutronclient would follow this link if information was needed about the subports collection, but the main piece of information needed by Nova -- \"is this a port that has child ports on it and is not connected to a network itself\" -- is already in the returned block of information about the port.","commit_id":"b7346abaa113a61935a804a84f62d2bd3678fb24"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"e996d1d276505816a824af6e43d78c5ed36c024f","unresolved":false,"context_lines":[{"line_number":113,"context_line":"is used. It must be used in nova-compute when querying neutron. But we"},{"line_number":114,"context_line":"hope its use can be avoided in nova\u0027s virt driver. We hope to keep ports"},{"line_number":115,"context_line":"and trunk ports similar enough (from nova\u0027s perspective), so that nova\u0027s"},{"line_number":116,"context_line":"virt driver need not know the difference."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"FIXME Is this hope realistic?"},{"line_number":119,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba8a016a_e8ac428e","line":116,"updated":"2015-11-23 02:21:01.000000000","message":"Well, right now, Nova would need to construct the nova.network.models.VIF object with information that would be passed on to the VIF plugging mechanism to alert the VIF plug to wire up the VIF appropriately for a trunk port. Eventually, an os_vif.objects.VIF object would be constructed (either by Nova or Neutron, we haven\u0027t yet decided), but either way, the host needs *some* information about which networks (or tags) need to be established for a particular port, right?\n\nIf this information about the port was attainable by Nova or os_vif in a single call to Neutron, that would be preferred.","commit_id":"b7346abaa113a61935a804a84f62d2bd3678fb24"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"e996d1d276505816a824af6e43d78c5ed36c024f","unresolved":false,"context_lines":[{"line_number":118,"context_line":"FIXME Is this hope realistic?"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"One reason for nova not to know about subports, is that they may get"},{"line_number":121,"context_line":"created or deleted after an instance was booted."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"* New vif driver: ``ovs_trunk_port``"},{"line_number":124,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba8a016a_99bb8675","line":121,"updated":"2015-11-23 02:21:01.000000000","message":"See https://review.openstack.org/#/c/139910/10/specs/mitaka/approved/sriov-interface-attach-detach.rst.\n\nI think Nova should probably know about subports -- at least eventually, when I\u0027m sure the attach/detach (subport to) interface will be feature-requested.","commit_id":"b7346abaa113a61935a804a84f62d2bd3678fb24"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"33a7eae021dc15360cae6a1f45b35ec33cf4a10d","unresolved":false,"context_lines":[{"line_number":148,"context_line":""},{"line_number":149,"context_line":"We see the following alternatives of the new vif driver:"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"1) Make the user responsible to pass trunk port uuids to nova, only after"},{"line_number":152,"context_line":"   the trunk port reached the ``ACTIVE`` state."},{"line_number":153,"context_line":"2) Make neutron-server synchronously call into neutron-ovs-agent to create"},{"line_number":154,"context_line":"   the trunk port bridge."}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa80f949_ca3b6037","line":151,"updated":"2015-11-04 20:38:07.000000000","message":"Couldn\u0027t nova be waiting for the trunk port to be ACTIVE?  But this also goes back to my question above about the user passing trunk ports only to nova, nova not creating them automatically (nova doesn\u0027t handle that orchestration for the new port type in other words).","commit_id":"b7346abaa113a61935a804a84f62d2bd3678fb24"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"33a7eae021dc15360cae6a1f45b35ec33cf4a10d","unresolved":false,"context_lines":[{"line_number":152,"context_line":"   the trunk port reached the ``ACTIVE`` state."},{"line_number":153,"context_line":"2) Make neutron-server synchronously call into neutron-ovs-agent to create"},{"line_number":154,"context_line":"   the trunk port bridge."},{"line_number":155,"context_line":"3) Introduce new nova-neutron communication mechanism so neutron can delay"},{"line_number":156,"context_line":"   nova\u0027s vif plugging action."},{"line_number":157,"context_line":"4) Make nova create the trunk port bridge (that is a new vif driver)."},{"line_number":158,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa80f949_ca692027","line":155,"updated":"2015-11-04 20:38:07.000000000","message":"nova/neutron already has the server events API where nova does the vif plugging in the virt layer and then waits for an event callback from neutron that the plugging is complete before we consider the network ready to go and set the instance to ACTIVE.  I\u0027m assuming something could be built on top of that.\n\nIt also makes me wonder what kind of port lifecycle event changes would come about because of this spec (via alternatives or not).","commit_id":"b7346abaa113a61935a804a84f62d2bd3678fb24"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"33a7eae021dc15360cae6a1f45b35ec33cf4a10d","unresolved":false,"context_lines":[{"line_number":173,"context_line":"REST API impact"},{"line_number":174,"context_line":"---------------"},{"line_number":175,"context_line":""},{"line_number":176,"context_line":"The JSON body of POST requests to the /instance resource need to be"},{"line_number":177,"context_line":"extended with a trunk_ports field. Microversion bump is needed."},{"line_number":178,"context_line":""},{"line_number":179,"context_line":"FIXME Add details."}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa80f949_0a5e4876","line":176,"updated":"2015-11-04 20:38:07.000000000","message":"s/instance/server/","commit_id":"b7346abaa113a61935a804a84f62d2bd3678fb24"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"33a7eae021dc15360cae6a1f45b35ec33cf4a10d","unresolved":false,"context_lines":[{"line_number":176,"context_line":"The JSON body of POST requests to the /instance resource need to be"},{"line_number":177,"context_line":"extended with a trunk_ports field. Microversion bump is needed."},{"line_number":178,"context_line":""},{"line_number":179,"context_line":"FIXME Add details."},{"line_number":180,"context_line":""},{"line_number":181,"context_line":"Security impact"},{"line_number":182,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa80f949_8ae1d89c","line":179,"updated":"2015-11-04 20:38:07.000000000","message":"Again, if the trunk ports are modeled as normal ports and use the same neutron API, I don\u0027t see why nova couldn\u0027t just determine what the type is based on the details of the port when nova is given the port uuid at boot time.","commit_id":"b7346abaa113a61935a804a84f62d2bd3678fb24"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"33a7eae021dc15360cae6a1f45b35ec33cf4a10d","unresolved":false,"context_lines":[{"line_number":196,"context_line":"Performance Impact"},{"line_number":197,"context_line":"------------------"},{"line_number":198,"context_line":""},{"line_number":199,"context_line":"No significant performance impact expected."},{"line_number":200,"context_line":""},{"line_number":201,"context_line":"Other deployer impact"},{"line_number":202,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa80f949_cafe0038","line":199,"updated":"2015-11-04 20:38:07.000000000","message":"If nova has to make new additional calls to neutron API to determine details on the type of port, that is a performance issue - also referred to commonly as nova being super \u0027chatty\u0027 with neutron API during network allocation at server boot time.","commit_id":"b7346abaa113a61935a804a84f62d2bd3678fb24"}]}