)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"a404aed0e1a5b150e47a3276e9bd867744cc9f62","unresolved":false,"context_lines":[{"line_number":13,"context_line":"I have attempted to capture it in updates to the spec itself.  In short"},{"line_number":14,"context_line":"though, it seems to me that using the existing port resource is"},{"line_number":15,"context_line":"sufficient.  I believe it will result in a simpler implementation (though"},{"line_number":16,"context_line":"that will have to be proven with code).  Finally, it doesn\u0027t require any"},{"line_number":17,"context_line":"changes to projects that interface with Neutron and handle VIF port"},{"line_number":18,"context_line":"binding (like Nova, but also Kuryr or anything similar)."},{"line_number":19,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"da85f559_2fdbd8ed","line":16,"updated":"2015-11-11 01:22:03.000000000","message":"I wonder if we should made the proviso of seeing the code before we approve this ;)","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":105,"name":"Kyle Mestery","email":"mestery@mestery.com","username":"mestery"},"change_message_id":"3c528e01a6ae03b5dca701a99b057038a258827a","unresolved":false,"context_lines":[{"line_number":13,"context_line":"I have attempted to capture it in updates to the spec itself.  In short"},{"line_number":14,"context_line":"though, it seems to me that using the existing port resource is"},{"line_number":15,"context_line":"sufficient.  I believe it will result in a simpler implementation (though"},{"line_number":16,"context_line":"that will have to be proven with code).  Finally, it doesn\u0027t require any"},{"line_number":17,"context_line":"changes to projects that interface with Neutron and handle VIF port"},{"line_number":18,"context_line":"binding (like Nova, but also Kuryr or anything similar)."},{"line_number":19,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"da85f559_cbcc5f6c","line":16,"in_reply_to":"da85f559_2fdbd8ed","updated":"2015-11-11 16:09:24.000000000","message":"Is this because we\u0027ve seen the code from the previous approach?","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"11548866fd59cabf69edbbb3f70abea531111ebc","unresolved":false,"context_lines":[{"line_number":13,"context_line":"I have attempted to capture it in updates to the spec itself.  In short"},{"line_number":14,"context_line":"though, it seems to me that using the existing port resource is"},{"line_number":15,"context_line":"sufficient.  I believe it will result in a simpler implementation (though"},{"line_number":16,"context_line":"that will have to be proven with code).  Finally, it doesn\u0027t require any"},{"line_number":17,"context_line":"changes to projects that interface with Neutron and handle VIF port"},{"line_number":18,"context_line":"binding (like Nova, but also Kuryr or anything similar)."},{"line_number":19,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"da85f559_859160f3","line":16,"in_reply_to":"da85f559_cbcc5f6c","updated":"2015-11-11 17:53:06.000000000","message":"That\u0027s fine.  I\u0027d be OK with a \"resolution\" of \"this seems like it might be OK, but we\u0027d like to see the corresponding code to compare against the existing work to know for sure\".","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"a404aed0e1a5b150e47a3276e9bd867744cc9f62","unresolved":false,"context_lines":[{"line_number":15,"context_line":"sufficient.  I believe it will result in a simpler implementation (though"},{"line_number":16,"context_line":"that will have to be proven with code).  Finally, it doesn\u0027t require any"},{"line_number":17,"context_line":"changes to projects that interface with Neutron and handle VIF port"},{"line_number":18,"context_line":"binding (like Nova, but also Kuryr or anything similar)."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Change-Id: I8563e54cc984b60f2be2eb7cc2e3c6fc60e6de20"},{"line_number":21,"context_line":"Signed-off-by: Russell Bryant \u003crbryant@redhat.com\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"da85f559_8fbe8463","line":18,"updated":"2015-11-11 01:22:03.000000000","message":"This gain is shallow IMO; we gotta acknowledge that to address certain NFV use cases a certain amount of coordination between the various project must happen. Just like the vif library (not NFV specific), or get-me-a network; these may require help from either side and the list goes on and on.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"11548866fd59cabf69edbbb3f70abea531111ebc","unresolved":false,"context_lines":[{"line_number":15,"context_line":"sufficient.  I believe it will result in a simpler implementation (though"},{"line_number":16,"context_line":"that will have to be proven with code).  Finally, it doesn\u0027t require any"},{"line_number":17,"context_line":"changes to projects that interface with Neutron and handle VIF port"},{"line_number":18,"context_line":"binding (like Nova, but also Kuryr or anything similar)."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Change-Id: I8563e54cc984b60f2be2eb7cc2e3c6fc60e6de20"},{"line_number":21,"context_line":"Signed-off-by: Russell Bryant \u003crbryant@redhat.com\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"da85f559_05425068","line":18,"in_reply_to":"da85f559_0be587da","updated":"2015-11-11 17:53:06.000000000","message":"You can consider this gain shallow if you\u0027d like.  That\u0027s fine.  It\u0027s non-zero though.  Just consider the proposal on all other merits.  It shouldn\u0027t come down to this point.  It doesn\u0027t for me.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":105,"name":"Kyle Mestery","email":"mestery@mestery.com","username":"mestery"},"change_message_id":"3c528e01a6ae03b5dca701a99b057038a258827a","unresolved":false,"context_lines":[{"line_number":15,"context_line":"sufficient.  I believe it will result in a simpler implementation (though"},{"line_number":16,"context_line":"that will have to be proven with code).  Finally, it doesn\u0027t require any"},{"line_number":17,"context_line":"changes to projects that interface with Neutron and handle VIF port"},{"line_number":18,"context_line":"binding (like Nova, but also Kuryr or anything similar)."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Change-Id: I8563e54cc984b60f2be2eb7cc2e3c6fc60e6de20"},{"line_number":21,"context_line":"Signed-off-by: Russell Bryant \u003crbryant@redhat.com\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"da85f559_0be587da","line":18,"in_reply_to":"da85f559_8fbe8463","updated":"2015-11-11 16:09:24.000000000","message":"Why is this approach and the gain vs. the prior approach shallow?","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"04461e97052279d96e1f1fb0999dc866fa90b2c5","unresolved":false,"context_lines":[{"line_number":4,"context_line":"Commit:     Russell Bryant \u003crbryant@redhat.com\u003e"},{"line_number":5,"context_line":"CommitDate: 2015-11-11 13:56:04 -0500"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Proposed changes to vlan-aware-vms."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This patch includes some proposed changers to the vlan-aware-vms spec."},{"line_number":10,"context_line":"I\u0027d like to propose that we revisit the idea of using only the existing"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"da85f559_2b54b5c8","line":7,"updated":"2015-11-12 21:40:49.000000000","message":"\u0027Trunk port\u0027 is a Cisco term. :)","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"d432d1cead24657cba1ec3fec42b1a7a9d7de277","unresolved":false,"context_lines":[{"line_number":4,"context_line":"Commit:     Russell Bryant \u003crbryant@redhat.com\u003e"},{"line_number":5,"context_line":"CommitDate: 2015-11-11 13:56:04 -0500"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Proposed changes to vlan-aware-vms."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This patch includes some proposed changers to the vlan-aware-vms spec."},{"line_number":10,"context_line":"I\u0027d like to propose that we revisit the idea of using only the existing"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"da85f559_bc2edf89","line":7,"updated":"2015-11-12 09:19:35.000000000","message":"I suggest using the name \u0027trunk port\u0027 instead of \u0027vlan aware vms\u0027, because it\u0027s not vlan specific and I believe it refers to something that people actually know what it is.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"7509912250b1a126386331909bebc1bf5c83a954","unresolved":false,"context_lines":[{"line_number":4,"context_line":"Commit:     Russell Bryant \u003crbryant@redhat.com\u003e"},{"line_number":5,"context_line":"CommitDate: 2015-11-11 13:56:04 -0500"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Proposed changes to vlan-aware-vms."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This patch includes some proposed changers to the vlan-aware-vms spec."},{"line_number":10,"context_line":"I\u0027d like to propose that we revisit the idea of using only the existing"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"da85f559_34197e7a","line":7,"in_reply_to":"da85f559_bc2edf89","updated":"2015-11-12 20:15:53.000000000","message":"I could rename it, but I think it\u0027s beneficial to try to minimize changes where possible.  The spec/blueprint/effort has been called vlan-aware-vms for a long time, so I don\u0027t think it\u0027s worth changing.  The scope is indeed limited to VLANs, even though the implementation happens to leave room for other encapsulation types in the future.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"d432d1cead24657cba1ec3fec42b1a7a9d7de277","unresolved":false,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This patch includes some proposed changers to the vlan-aware-vms spec."},{"line_number":10,"context_line":"I\u0027d like to propose that we revisit the idea of using only the existing"},{"line_number":11,"context_line":"Neutron port resource instead of creating a new trunk-port resource."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"I have attempted to capture it in updates to the spec itself.  In short"},{"line_number":14,"context_line":"though, it seems to me that using the existing port resource is"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"da85f559_bc4fbf32","line":11,"updated":"2015-11-12 09:19:35.000000000","message":"I\u0027d like to point out that we have come full circle on this. Patch set 1 of bp/vlan-aware-vms originally proposed no new trunk port resource, but modifying the existing port resource. There was even an implementation under review. That was rejected (and abandoned since) and the spec was changed to having a new trunk port resource in patch set 12. See here:\n\nI015762abe197b91916374143410b1f182908909e\n\nWhichever conclusion we come to, it\u0027d would be really important to settle this oscillation, otherwise there\u0027s no chance of making progress.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15361,"name":"Peter V. Saveliev","email":"peter@svinota.eu","username":"svinota"},"change_message_id":"0eac3c188028e0fbe93b8aa14a885070f12a5d09","unresolved":false,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This patch includes some proposed changers to the vlan-aware-vms spec."},{"line_number":10,"context_line":"I\u0027d like to propose that we revisit the idea of using only the existing"},{"line_number":11,"context_line":"Neutron port resource instead of creating a new trunk-port resource."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"I have attempted to capture it in updates to the spec itself.  In short"},{"line_number":14,"context_line":"though, it seems to me that using the existing port resource is"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"da85f559_be53f26b","line":11,"in_reply_to":"da85f559_9455cafb","updated":"2015-11-13 09:05:01.000000000","message":"The best abstraction would be to have a generic «port» resource, a generic «net» resource and some ways to associate them — only if it is needed. And a good plugin mech to implement particular types of the resources, such as IPSec, MPLS L2/L3, ordinary broadcasting domains etc. The trunkport and BGPVPN extensions highlight this issue in the Neutron model.\n\nAs for now, having what do we have in the Neutron, I believe that it would be more productive to focus on the user\u0027s perspective, not on what\u0027s easier to wichever team, be it Nova or Neutron.\n\nAnother issue is neither in the code nor in the architecture. We started with a proposal and a solution, and after quite a long time and a lot of efforts we returned almost to the initial state. By itself the return is not an issue, but the issue is what in the process caused that cycle. I believe, it should be solved somehow, or Neutron can miss more important features.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"7509912250b1a126386331909bebc1bf5c83a954","unresolved":false,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This patch includes some proposed changers to the vlan-aware-vms spec."},{"line_number":10,"context_line":"I\u0027d like to propose that we revisit the idea of using only the existing"},{"line_number":11,"context_line":"Neutron port resource instead of creating a new trunk-port resource."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"I have attempted to capture it in updates to the spec itself.  In short"},{"line_number":14,"context_line":"though, it seems to me that using the existing port resource is"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"da85f559_9455cafb","line":11,"in_reply_to":"da85f559_bc4fbf32","updated":"2015-11-12 20:15:53.000000000","message":"Yes, that point is well known.  I decided to be difficult and propose a switch back to that because I think in hindsight it was the right thing to do.  I do apologize for the churn.  I know it\u0027s painful.  I still think it\u0027s worth it to find the best abstraction before committing to anything for the long term.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"}],"specs/mitaka/vlan-aware-vms.rst":[{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"a404aed0e1a5b150e47a3276e9bd867744cc9f62","unresolved":false,"context_lines":[{"line_number":66,"context_line":"Proposed Change"},{"line_number":67,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"The proposal is to add a subport API extension.  The best way to think about"},{"line_number":70,"context_line":"this is that Neutron needs a method to describe a logical topology such that you"},{"line_number":71,"context_line":"have a regular VIF port (the parent) and that parent may also have child ports."},{"line_number":72,"context_line":"These child ports are used to describe logical entities that reside behind the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_af3828f0","line":69,"updated":"2015-11-11 01:22:03.000000000","message":"I think that at this point we would have to have some serious look at the problem statement too.\n\nThis initially was proposed as a way to overcome the QinQ support (or lack thereof) of the OVS agent implementation. This can actually be addressed as a bug fix of the existing implementation (quite a complex one, but nonetheless one that doesn\u0027t require an invasive API change). Another use case can be container networking.\n\nI am starting to think that we can\u0027t possibly address both with the same abstraction. The resulting proposal is awkward to say the least.\n\nTo provide an explicit way to control VLAN restrictions, then the most natural proposal would be to extend the neutron object with a list of VLAN\u0027s that the agent should allow through.\n\nIf we did that, then we could look at the nested networking case without clobbering it with implementation details like encap_type and encap_info, whose presence I find hard to justify in the nested container networking case, especially if these are tenant facing API changes.\n\nI\u0027d personally rather have them seamlessly figured out by the backend of choice; all the user cares about is to spin up a container and connect it to the neutron network. Why would he have to go through so much hassle?\n\nCan we elaborate more the container networking case? Do we split the spec in half a this point, one that addresses QinQ support, and the other that addresses the container needs? Why do they have to be the same?","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"c37d02852357137db96bf2d94a7d619aa3b2ae53","unresolved":false,"context_lines":[{"line_number":66,"context_line":"Proposed Change"},{"line_number":67,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"The proposal is to add a subport API extension.  The best way to think about"},{"line_number":70,"context_line":"this is that Neutron needs a method to describe a logical topology such that you"},{"line_number":71,"context_line":"have a regular VIF port (the parent) and that parent may also have child ports."},{"line_number":72,"context_line":"These child ports are used to describe logical entities that reside behind the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_b115804a","line":69,"in_reply_to":"da85f559_23f4f458","updated":"2015-11-12 19:39:45.000000000","message":"The way this blueprint is defined, it is definitely about connecting a VM to multiple networks over a single VIF.  That is exactly how this works (before and after my proposal).  There are multiple use cases for why that may be useful, but that\u0027s all this is and I don\u0027t think QinQ is related to that.\n\nI consider VLAN tagged traffic over tenant networks to be something separate.  That\u0027s what \"vlan_transparent\" was about.  It may be worth noting as a constraint here that an OVS based driver today can not support connecting a subport to a vlan transparent network.  That would indeed require QinQ support.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"11548866fd59cabf69edbbb3f70abea531111ebc","unresolved":false,"context_lines":[{"line_number":66,"context_line":"Proposed Change"},{"line_number":67,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"The proposal is to add a subport API extension.  The best way to think about"},{"line_number":70,"context_line":"this is that Neutron needs a method to describe a logical topology such that you"},{"line_number":71,"context_line":"have a regular VIF port (the parent) and that parent may also have child ports."},{"line_number":72,"context_line":"These child ports are used to describe logical entities that reside behind the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_80bcee06","line":69,"in_reply_to":"da85f559_4ba38fb2","updated":"2015-11-11 17:53:06.000000000","message":"I think the mention of QinQ in this spec is awkward and confusing, but I tried to not modify the spec more than I had to so we could focus on the key changes to the proposal.\n\nIf I were to boil down what this is proposing, it has absolutely nothing to do with QinQ.  It\u0027s letting a VM connect to more than one Neutron network over a single VIF, using VLANs to differentiate the traffic for each network.  That\u0027s it.\n\nThis is related to container networking, but only a very targeted use case.  It\u0027s when you\u0027re creating VMs with containers in them on an OpenStack cloud.  You want to attach those containers to independent networks managed by the underlying Neutron.  This provides the primitives necessary to do that without create a VIF in the VM per container, which isn\u0027t terribly practical for many cases.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"ef9ec0a01f62c40db33c2024c67a8c39f6587fd2","unresolved":false,"context_lines":[{"line_number":66,"context_line":"Proposed Change"},{"line_number":67,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"The proposal is to add a subport API extension.  The best way to think about"},{"line_number":70,"context_line":"this is that Neutron needs a method to describe a logical topology such that you"},{"line_number":71,"context_line":"have a regular VIF port (the parent) and that parent may also have child ports."},{"line_number":72,"context_line":"These child ports are used to describe logical entities that reside behind the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_23f4f458","line":69,"in_reply_to":"da85f559_80bcee06","updated":"2015-11-12 15:03:52.000000000","message":"Russell in the original blueprint letting a VM connect to more than one Neutron network over on VIF was only one use case. \nThere are other use cases that can be assimilated to QinQ: 1) the possibility to transmit VLAN tagged traffic over tenant network to be able to use old legacy application in the cloud (line 31) and to tag the traffic meant for an external network with a specific VLAN (line 48).\nIf you leave the QinQ part aside, then you agree with Armando that we should have 2 separate blueprints one for the QinQ case and the other for container networking or VM connected to multiple networks through one VIF :)","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"6d049fe56e3a641a8d339af290eec781366cb92d","unresolved":false,"context_lines":[{"line_number":66,"context_line":"Proposed Change"},{"line_number":67,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"The proposal is to add a subport API extension.  The best way to think about"},{"line_number":70,"context_line":"this is that Neutron needs a method to describe a logical topology such that you"},{"line_number":71,"context_line":"have a regular VIF port (the parent) and that parent may also have child ports."},{"line_number":72,"context_line":"These child ports are used to describe logical entities that reside behind the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_4ba38fb2","line":69,"in_reply_to":"da85f559_aba8fc8c","updated":"2015-11-11 16:03:41.000000000","message":"I realized I omitted an important detail: I meant the \u003cstrike\u003eneutron\u003c/strike\u003e *network* object","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"8ac7eda7db6d4499a4729ef2f9bb847c055fda4c","unresolved":false,"context_lines":[{"line_number":66,"context_line":"Proposed Change"},{"line_number":67,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"The proposal is to add a subport API extension.  The best way to think about"},{"line_number":70,"context_line":"this is that Neutron needs a method to describe a logical topology such that you"},{"line_number":71,"context_line":"have a regular VIF port (the parent) and that parent may also have child ports."},{"line_number":72,"context_line":"These child ports are used to describe logical entities that reside behind the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_aba8fc8c","line":69,"in_reply_to":"da85f559_af3828f0","updated":"2015-11-11 15:56:06.000000000","message":"I like your proposal to extend the Neutron port object with a list of VLAN IDs to allow through. It\u0027s simple and effective.\nI also agree that it would be better to deal with the container networking use case separately. For that more discussions are needed and other projects need to be involved (Kuryr, Magnum? ) . QinQ and the container network are similar but still different. QinQ is about the existence of another level of isolation (vlan) that Neutron is not aware of and should not touch. Container networking is about modifying the existing isolation mechanism in Neutron to work not only with VMs but also with containers. So I think it  makes sense to use different models for these use cases.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":6598,"name":"Berezovsky Irena","email":"irenab.dev@gmail.com","username":"irenab"},"change_message_id":"b752e98e95550eff17da5a3423cd9691bba39d8c","unresolved":false,"context_lines":[{"line_number":79,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":80,"context_line":"strictly necessary, but is included for convenience, both in the API and for"},{"line_number":81,"context_line":"backend implementations.  This must be specified at port creation time and may"},{"line_number":82,"context_line":"not be changed."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"Note that all example command lines are for demonstrating the concepts.  The"},{"line_number":85,"context_line":"exact syntax is subject to change."}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_f0ddbee0","line":82,"updated":"2015-11-10 20:12:34.000000000","message":"Why this cannot be changed? As long as no child ports are defined it should be harmless.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"274a3540abe71a901e6d0da26e78e603071396bd","unresolved":false,"context_lines":[{"line_number":79,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":80,"context_line":"strictly necessary, but is included for convenience, both in the API and for"},{"line_number":81,"context_line":"backend implementations.  This must be specified at port creation time and may"},{"line_number":82,"context_line":"not be changed."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"Note that all example command lines are for demonstrating the concepts.  The"},{"line_number":85,"context_line":"exact syntax is subject to change."}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_f6fb76bf","line":82,"in_reply_to":"da85f559_567fe265","updated":"2015-11-10 20:27:10.000000000","message":"Right, and at least with this attribute it gives the backend the opportunity to allow, deny, or otherwise change its behavior at port creation time.  It may not be strictly necessary, but it does seem potentially useful, and I don\u0027t think it hurts anything.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":6598,"name":"Berezovsky Irena","email":"irenab.dev@gmail.com","username":"irenab"},"change_message_id":"bd65b2a453d3db558fb4577e57f6ee0df8ed36a0","unresolved":false,"context_lines":[{"line_number":79,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":80,"context_line":"strictly necessary, but is included for convenience, both in the API and for"},{"line_number":81,"context_line":"backend implementations.  This must be specified at port creation time and may"},{"line_number":82,"context_line":"not be changed."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"Note that all example command lines are for demonstrating the concepts.  The"},{"line_number":85,"context_line":"exact syntax is subject to change."}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_567fe265","line":82,"in_reply_to":"da85f559_9bc333ed","updated":"2015-11-10 20:23:41.000000000","message":"Indeed, it looks like backend dependent behaviour. It probably can be plugin decision to allow/decline this parent role assignment.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"856353ca00541fc18c146d8043068c540587ef8e","unresolved":false,"context_lines":[{"line_number":79,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":80,"context_line":"strictly necessary, but is included for convenience, both in the API and for"},{"line_number":81,"context_line":"backend implementations.  This must be specified at port creation time and may"},{"line_number":82,"context_line":"not be changed."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"Note that all example command lines are for demonstrating the concepts.  The"},{"line_number":85,"context_line":"exact syntax is subject to change."}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_b6916ef3","line":82,"in_reply_to":"da85f559_d6d672f0","updated":"2015-11-10 20:42:15.000000000","message":"Well, it\u0027s at least easier to make this more flexible later (allow updating it after port create) than the other way around (define it as flexible, but try to make it more restrictive later).","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"bad65155b3b3960fb45ca02cf5c0c9531cd4eb72","unresolved":false,"context_lines":[{"line_number":79,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":80,"context_line":"strictly necessary, but is included for convenience, both in the API and for"},{"line_number":81,"context_line":"backend implementations.  This must be specified at port creation time and may"},{"line_number":82,"context_line":"not be changed."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"Note that all example command lines are for demonstrating the concepts.  The"},{"line_number":85,"context_line":"exact syntax is subject to change."}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_9bc333ed","line":82,"in_reply_to":"da85f559_f0ddbee0","updated":"2015-11-10 20:17:24.000000000","message":"I agree.  My instinct was to actually not have \"subport:is_parent\" at all, as it seems it shouldn\u0027t be necessary.\n\nIt\u0027s basically inspired by the possibility that a backend *might* want to set up a port that may have children differently than it would a regular port.  In OVN, there is no difference.  From talking to Kevin Benton, he seemed to think that for ML2+OVS, they may need to set up a parent port differently, so this restriction accommodates that possibility.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":6598,"name":"Berezovsky Irena","email":"irenab.dev@gmail.com","username":"irenab"},"change_message_id":"5bee5221fc0bac9241308985744376b731bd24e9","unresolved":false,"context_lines":[{"line_number":79,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":80,"context_line":"strictly necessary, but is included for convenience, both in the API and for"},{"line_number":81,"context_line":"backend implementations.  This must be specified at port creation time and may"},{"line_number":82,"context_line":"not be changed."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"Note that all example command lines are for demonstrating the concepts.  The"},{"line_number":85,"context_line":"exact syntax is subject to change."}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_d6d672f0","line":82,"in_reply_to":"da85f559_f6fb76bf","updated":"2015-11-10 20:37:17.000000000","message":"I am still wondering if it should be required to fix this attribute during the port creation time. But I guess it simplifies user experience.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"c9621d729638165d57167681cb8a377f5df0f571","unresolved":false,"context_lines":[{"line_number":86,"context_line":""},{"line_number":87,"context_line":"::"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"    $ neutron port-create --subport:is_parent NETWORK"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Note that if a given plugin does not implement support for the subport API"},{"line_number":92,"context_line":"extension, it is completely safe to ignore this and implement the port as you"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_ad2d9896","line":89,"updated":"2015-11-10 22:01:24.000000000","message":"I just think that explicitly declaring a port as a parent port is tantamount to have distinct trunkport and port - the thing you\u0027re trying to get rid of.\n\nAs I was however in favour of describing a trunkport as a distinct resource, I can\u0027t object, works for me (even if as rightly argued in comments seems pointless)","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"27204c8803b2f582ecb7a2f1909067052978efb5","unresolved":false,"context_lines":[{"line_number":86,"context_line":""},{"line_number":87,"context_line":"::"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"    $ neutron port-create --subport:is_parent NETWORK"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Note that if a given plugin does not implement support for the subport API"},{"line_number":92,"context_line":"extension, it is completely safe to ignore this and implement the port as you"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_43f15d00","line":89,"in_reply_to":"da85f559_ad2d9896","updated":"2015-11-10 22:30:45.000000000","message":"I think the difference is that everything about the port is expected to behave the same.  This just says \"and btw, I intend to add some sub-ports to this later, so go ahead and reject this if that\u0027s not going to work for some reason\".","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"c9621d729638165d57167681cb8a377f5df0f571","unresolved":false,"context_lines":[{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Note that if a given plugin does not implement support for the subport API"},{"line_number":92,"context_line":"extension, it is completely safe to ignore this and implement the port as you"},{"line_number":93,"context_line":"normally would.  The port handles untagged traffic and should behave as usual."},{"line_number":94,"context_line":"We could also update Neutron such that it rejects the request if the plugin does"},{"line_number":95,"context_line":"not indicate that it supports the subport API extension."},{"line_number":96,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_2ddd286f","line":93,"updated":"2015-11-10 22:01:24.000000000","message":"My personal opinion is that that is it not ok to ignore and implement the port as you normally would.\n\nIf the client requested port with --subport:is_parent set to True then it is quite like it\u0027s asking for a port to which subports should be attached. If the server ignores its request and creates a regular port it\u0027s not doing what the client asked for, but since the server returns a success response the client is authorized to think he got a \"parent port\".\n\nif the server is not able to create it, it should not ignore the parameter but actively refuse to create that port, as you indicate in the next paragraph.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"27204c8803b2f582ecb7a2f1909067052978efb5","unresolved":false,"context_lines":[{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Note that if a given plugin does not implement support for the subport API"},{"line_number":92,"context_line":"extension, it is completely safe to ignore this and implement the port as you"},{"line_number":93,"context_line":"normally would.  The port handles untagged traffic and should behave as usual."},{"line_number":94,"context_line":"We could also update Neutron such that it rejects the request if the plugin does"},{"line_number":95,"context_line":"not indicate that it supports the subport API extension."},{"line_number":96,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_e3e2d12e","line":93,"in_reply_to":"da85f559_2ddd286f","updated":"2015-11-10 22:30:45.000000000","message":"OK, good point.  I\u0027ll update this to say that it *will* reject the request if a plugin does not support this.  The rest of the discussion is just noise at that point.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"11548866fd59cabf69edbbb3f70abea531111ebc","unresolved":false,"context_lines":[{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Note that if a given plugin does not implement support for the subport API"},{"line_number":92,"context_line":"extension, it is completely safe to ignore this and implement the port as you"},{"line_number":93,"context_line":"normally would.  The port handles untagged traffic and should behave as usual."},{"line_number":94,"context_line":"We could also update Neutron such that it rejects the request if the plugin does"},{"line_number":95,"context_line":"not indicate that it supports the subport API extension."},{"line_number":96,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_403926a3","line":93,"in_reply_to":"da85f559_34e7b112","updated":"2015-11-11 17:53:06.000000000","message":"Nope, you didn\u0027t seem upset.  It was a good point.  To be clear, I meant that the rest of the text I had included in the spec is just noise if we clarify that we *will* reject the request.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"e041a853a153918abd89892c2e26dc58bb6e63be","unresolved":false,"context_lines":[{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Note that if a given plugin does not implement support for the subport API"},{"line_number":92,"context_line":"extension, it is completely safe to ignore this and implement the port as you"},{"line_number":93,"context_line":"normally would.  The port handles untagged traffic and should behave as usual."},{"line_number":94,"context_line":"We could also update Neutron such that it rejects the request if the plugin does"},{"line_number":95,"context_line":"not indicate that it supports the subport API extension."},{"line_number":96,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_34e7b112","line":93,"in_reply_to":"da85f559_e3e2d12e","updated":"2015-11-11 00:19:16.000000000","message":"Sorry if it appeared as if I was upset about this.\nAs you surely know, nothing bothers me.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"c9621d729638165d57167681cb8a377f5df0f571","unresolved":false,"context_lines":[{"line_number":107,"context_line":"doesn\u0027t support this API extension, these ports will never be bound and will"},{"line_number":108,"context_line":"effectively be a NO-OP.  Of course, a better solution would be to just make"},{"line_number":109,"context_line":"Neutron reject the port creation if the plugin does not indicate that it"},{"line_number":110,"context_line":"supports the subport API extension."},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"In addition to the logical topology piece, we need to define the type of"},{"line_number":113,"context_line":"encapsulation used between the hypervisor and VM for targeting packets to a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_2d72087c","line":110,"updated":"2015-11-10 22:01:24.000000000","message":"And the latter makes sense if you put yourself in the position of somebody writing scripts or client apps using this API","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"27204c8803b2f582ecb7a2f1909067052978efb5","unresolved":false,"context_lines":[{"line_number":107,"context_line":"doesn\u0027t support this API extension, these ports will never be bound and will"},{"line_number":108,"context_line":"effectively be a NO-OP.  Of course, a better solution would be to just make"},{"line_number":109,"context_line":"Neutron reject the port creation if the plugin does not indicate that it"},{"line_number":110,"context_line":"supports the subport API extension."},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"In addition to the logical topology piece, we need to define the type of"},{"line_number":113,"context_line":"encapsulation used between the hypervisor and VM for targeting packets to a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_03c7d596","line":110,"in_reply_to":"da85f559_2d72087c","updated":"2015-11-10 22:30:45.000000000","message":"Agreed.  I\u0027ll remove this discussion and simply clarify that the request will be rejected if the plugin doesn\u0027t support it.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"c9621d729638165d57167681cb8a377f5df0f571","unresolved":false,"context_lines":[{"line_number":116,"context_line":"cases where other encapsulation types may be used.  For example, in the SFC"},{"line_number":117,"context_line":"world there is talk of using several different encapsulation types as methods"},{"line_number":118,"context_line":"for targeting logical service chain endpoints inside of a VM.  This API could"},{"line_number":119,"context_line":"support modeling that."},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"A subport has both an encapsulation type, as well as some encapsulation info."},{"line_number":122,"context_line":"If the type is vlan, then the info is just an integer that represents a valid"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_6db7b0f5","line":119,"updated":"2015-11-10 22:01:24.000000000","message":"Frankly this paragraph seems a bit vague. You might want to expand it, but as it does not seem an integrating part of this spec (beyond expressing the need for multiple encaps) you might also consider removing it.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"e041a853a153918abd89892c2e26dc58bb6e63be","unresolved":false,"context_lines":[{"line_number":116,"context_line":"cases where other encapsulation types may be used.  For example, in the SFC"},{"line_number":117,"context_line":"world there is talk of using several different encapsulation types as methods"},{"line_number":118,"context_line":"for targeting logical service chain endpoints inside of a VM.  This API could"},{"line_number":119,"context_line":"support modeling that."},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"A subport has both an encapsulation type, as well as some encapsulation info."},{"line_number":122,"context_line":"If the type is vlan, then the info is just an integer that represents a valid"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_54a9158f","line":119,"in_reply_to":"da85f559_234bf92b","updated":"2015-11-11 00:19:16.000000000","message":"that\u0027s cool by me. Don\u0027t spend too much time trying to simplify/rephrase. From my standpoint, I think we need a few more details about the SFC use case.\n\nBut as we\u0027re writing a spec and not a constitutional bill, this probably does not matter at all.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"11548866fd59cabf69edbbb3f70abea531111ebc","unresolved":false,"context_lines":[{"line_number":116,"context_line":"cases where other encapsulation types may be used.  For example, in the SFC"},{"line_number":117,"context_line":"world there is talk of using several different encapsulation types as methods"},{"line_number":118,"context_line":"for targeting logical service chain endpoints inside of a VM.  This API could"},{"line_number":119,"context_line":"support modeling that."},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"A subport has both an encapsulation type, as well as some encapsulation info."},{"line_number":122,"context_line":"If the type is vlan, then the info is just an integer that represents a valid"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_c0743669","line":119,"in_reply_to":"da85f559_54a9158f","updated":"2015-11-11 17:53:06.000000000","message":"I think I\u0027ll at least drop the SFC mention.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"68558428beaf72df2137408b489f38909306b1f2","unresolved":false,"context_lines":[{"line_number":116,"context_line":"cases where other encapsulation types may be used.  For example, in the SFC"},{"line_number":117,"context_line":"world there is talk of using several different encapsulation types as methods"},{"line_number":118,"context_line":"for targeting logical service chain endpoints inside of a VM.  This API could"},{"line_number":119,"context_line":"support modeling that."},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"A subport has both an encapsulation type, as well as some encapsulation info."},{"line_number":122,"context_line":"If the type is vlan, then the info is just an integer that represents a valid"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_a365a9b5","line":119,"in_reply_to":"da85f559_6db7b0f5","updated":"2015-11-10 22:25:45.000000000","message":"I think it makes sense and that it should stay, although clearing  up whatever you find confusing would be good of course.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"27204c8803b2f582ecb7a2f1909067052978efb5","unresolved":false,"context_lines":[{"line_number":116,"context_line":"cases where other encapsulation types may be used.  For example, in the SFC"},{"line_number":117,"context_line":"world there is talk of using several different encapsulation types as methods"},{"line_number":118,"context_line":"for targeting logical service chain endpoints inside of a VM.  This API could"},{"line_number":119,"context_line":"support modeling that."},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"A subport has both an encapsulation type, as well as some encapsulation info."},{"line_number":122,"context_line":"If the type is vlan, then the info is just an integer that represents a valid"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_234bf92b","line":119,"in_reply_to":"da85f559_6db7b0f5","updated":"2015-11-10 22:30:45.000000000","message":"OK, I\u0027ll see about trying to simplify this and just leave the possibility for other encaps open in the way the API is defined.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"c9621d729638165d57167681cb8a377f5df0f571","unresolved":false,"context_lines":[{"line_number":127,"context_line":"    \u003e --subport:encap_type vlan --subport:encap_info 101 NETWORK"},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"For the purposes of this proposal, \"vlan\" is the only accepted encap_type at"},{"line_number":130,"context_line":"this time.  Later proposals could define new encap types and associated"},{"line_number":131,"context_line":"encapsulation info."},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"Just to reiterate, the encapsulation is a local encapsulation used between the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_ade4b8e0","line":130,"updated":"2015-11-10 22:01:24.000000000","message":"Yay! make it default then so that people won\u0027t have to specify it at all ;)","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"27204c8803b2f582ecb7a2f1909067052978efb5","unresolved":false,"context_lines":[{"line_number":127,"context_line":"    \u003e --subport:encap_type vlan --subport:encap_info 101 NETWORK"},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"For the purposes of this proposal, \"vlan\" is the only accepted encap_type at"},{"line_number":130,"context_line":"this time.  Later proposals could define new encap types and associated"},{"line_number":131,"context_line":"encapsulation info."},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"Just to reiterate, the encapsulation is a local encapsulation used between the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_2372197c","line":130,"in_reply_to":"da85f559_ade4b8e0","updated":"2015-11-10 22:30:45.000000000","message":"Sure, I\u0027ll add an example that shows that you don\u0027t have to specify it since vlan is the default.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"c9621d729638165d57167681cb8a377f5df0f571","unresolved":false,"context_lines":[{"line_number":130,"context_line":"this time.  Later proposals could define new encap types and associated"},{"line_number":131,"context_line":"encapsulation info."},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"Just to reiterate, the encapsulation is a local encapsulation used between the"},{"line_number":134,"context_line":"VM and hypervisor only.  It has nothing to do with how the Neutron network the"},{"line_number":135,"context_line":"port is attached to is implemented.  It is only used to identify the source or"},{"line_number":136,"context_line":"destination logical port over a single VIF."}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_8d069484","line":133,"updated":"2015-11-10 22:01:24.000000000","message":"repetita iuvant","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"27204c8803b2f582ecb7a2f1909067052978efb5","unresolved":false,"context_lines":[{"line_number":130,"context_line":"this time.  Later proposals could define new encap types and associated"},{"line_number":131,"context_line":"encapsulation info."},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"Just to reiterate, the encapsulation is a local encapsulation used between the"},{"line_number":134,"context_line":"VM and hypervisor only.  It has nothing to do with how the Neutron network the"},{"line_number":135,"context_line":"port is attached to is implemented.  It is only used to identify the source or"},{"line_number":136,"context_line":"destination logical port over a single VIF."}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_2320d947","line":133,"in_reply_to":"da85f559_8d069484","updated":"2015-11-10 22:30:45.000000000","message":"I had to google this.  :-p\n\nIt did seem like a pretty critical piece of how this works and worth making sure was clear.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"68558428beaf72df2137408b489f38909306b1f2","unresolved":false,"context_lines":[{"line_number":133,"context_line":"Just to reiterate, the encapsulation is a local encapsulation used between the"},{"line_number":134,"context_line":"VM and hypervisor only.  It has nothing to do with how the Neutron network the"},{"line_number":135,"context_line":"port is attached to is implemented.  It is only used to identify the source or"},{"line_number":136,"context_line":"destination logical port over a single VIF."},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"Example logical model::"},{"line_number":139,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_a3da894a","line":136,"updated":"2015-11-10 22:25:45.000000000","message":"This doesn\u0027t seem repetitive as I didn\u0027t quite grasp this until it was \"reiterated.\" I might\u0027ve missed or forgotten it from the first iteration of this spec, being focused on the other issue.\n\nPresumably this encapsulation property is exposed to the guest so that the cloud-init or whatever else can setup interfaces properly with the subport information for addressing?","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"e041a853a153918abd89892c2e26dc58bb6e63be","unresolved":false,"context_lines":[{"line_number":133,"context_line":"Just to reiterate, the encapsulation is a local encapsulation used between the"},{"line_number":134,"context_line":"VM and hypervisor only.  It has nothing to do with how the Neutron network the"},{"line_number":135,"context_line":"port is attached to is implemented.  It is only used to identify the source or"},{"line_number":136,"context_line":"destination logical port over a single VIF."},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"Example logical model::"},{"line_number":139,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_d4742537","line":136,"in_reply_to":"da85f559_a3da894a","updated":"2015-11-11 00:19:16.000000000","message":"For some reason it seems a reiteration to me. But this is probably because we\u0027ve been hearing about this for ages now.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"3008454b68ab457d26ceeaadc2f738d0d4a37a82","unresolved":false,"context_lines":[{"line_number":133,"context_line":"Just to reiterate, the encapsulation is a local encapsulation used between the"},{"line_number":134,"context_line":"VM and hypervisor only.  It has nothing to do with how the Neutron network the"},{"line_number":135,"context_line":"port is attached to is implemented.  It is only used to identify the source or"},{"line_number":136,"context_line":"destination logical port over a single VIF."},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"Example logical model::"},{"line_number":139,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_debc4408","line":136,"in_reply_to":"da85f559_a3da894a","updated":"2015-11-10 22:42:42.000000000","message":"Maybe I didn\u0027t cover it before and it was just repeated in my head over and over.  I\u0027ll remove the \"Just to reiterate\" part.  \n\nI\u0027m not sure if this is exposed to the guest via any metadata other than the Neutron API.  I guess I was just expecting that whatever application was creating subports knows it needs to go update the VM, as well.  For example, if Kubernetes was creating subports for containers it\u0027s spinning up, it would know it has to update the networking in the VM for that subport at the same time it creates the container itself.\n\nIf you create some subports but don\u0027t update your VM config, I imagine the VM will just drop all packets directed at subports.  There\u0027s several different ways you could do the subport networking in the guest, so it\u0027s probably not something cloud-init or similar would automate.  That\u0027s a really interesting area to explore further, though.  At least exposing the subport info via metadata so custom init code can use it sounds valuable.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"11548866fd59cabf69edbbb3f70abea531111ebc","unresolved":false,"context_lines":[{"line_number":133,"context_line":"Just to reiterate, the encapsulation is a local encapsulation used between the"},{"line_number":134,"context_line":"VM and hypervisor only.  It has nothing to do with how the Neutron network the"},{"line_number":135,"context_line":"port is attached to is implemented.  It is only used to identify the source or"},{"line_number":136,"context_line":"destination logical port over a single VIF."},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"Example logical model::"},{"line_number":139,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_00247e5d","line":136,"in_reply_to":"da85f559_cf756cfa","updated":"2015-11-11 17:53:06.000000000","message":"Good points.  I honestly don\u0027t have the details of what the metadata should look like exactly yet in my head, but I\u0027ll include as a work item getting this exposed in metadata, because I\u0027m convinced it\u0027s valuable.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f8cdd1a447d6eae8006e557117a4a592348bed29","unresolved":false,"context_lines":[{"line_number":133,"context_line":"Just to reiterate, the encapsulation is a local encapsulation used between the"},{"line_number":134,"context_line":"VM and hypervisor only.  It has nothing to do with how the Neutron network the"},{"line_number":135,"context_line":"port is attached to is implemented.  It is only used to identify the source or"},{"line_number":136,"context_line":"destination logical port over a single VIF."},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"Example logical model::"},{"line_number":139,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_cf756cfa","line":136,"in_reply_to":"da85f559_debc4408","updated":"2015-11-11 00:57:06.000000000","message":"I guess I would think that most people will want the OS in the guest to come up with networking on all the attached (even virtually) networks. Given that we\u0027re dumping a bunch of neutron network details into metadata these days, I guess I\u0027m not sure why we wouldn\u0027t expose this to them. Wasn\u0027t one of the points of that neutron blob work so that we could expose VLANs to the guests?","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"c9621d729638165d57167681cb8a377f5df0f571","unresolved":false,"context_lines":[{"line_number":147,"context_line":"   |  VM  ||    P0    |---| S2      |------------ N2"},{"line_number":148,"context_line":"   |      || Untagged |\\  | VID: 20 |"},{"line_number":149,"context_line":"   |      |+----------+ \\ +---------+"},{"line_number":150,"context_line":"   |      |     |        \\"},{"line_number":151,"context_line":"   +------+     |         +---------+"},{"line_number":152,"context_line":"                |         | S3      |------------ N3"},{"line_number":153,"context_line":"                N0        | VLAN 30 |"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_6d0fb088","line":150,"updated":"2015-11-10 22:01:24.000000000","message":"P0 really looks like a bridge..... have you considered that?","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"27204c8803b2f582ecb7a2f1909067052978efb5","unresolved":false,"context_lines":[{"line_number":147,"context_line":"   |  VM  ||    P0    |---| S2      |------------ N2"},{"line_number":148,"context_line":"   |      || Untagged |\\  | VID: 20 |"},{"line_number":149,"context_line":"   |      |+----------+ \\ +---------+"},{"line_number":150,"context_line":"   |      |     |        \\"},{"line_number":151,"context_line":"   +------+     |         +---------+"},{"line_number":152,"context_line":"                |         | S3      |------------ N3"},{"line_number":153,"context_line":"                N0        | VLAN 30 |"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_e3ec11f5","line":150,"in_reply_to":"da85f559_6d0fb088","updated":"2015-11-10 22:30:45.000000000","message":"Do you have a suggestion for how else to draw it.\n\nIt\u0027s very much NOT a bridge, of course.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"e041a853a153918abd89892c2e26dc58bb6e63be","unresolved":false,"context_lines":[{"line_number":147,"context_line":"   |  VM  ||    P0    |---| S2      |------------ N2"},{"line_number":148,"context_line":"   |      || Untagged |\\  | VID: 20 |"},{"line_number":149,"context_line":"   |      |+----------+ \\ +---------+"},{"line_number":150,"context_line":"   |      |     |        \\"},{"line_number":151,"context_line":"   +------+     |         +---------+"},{"line_number":152,"context_line":"                |         | S3      |------------ N3"},{"line_number":153,"context_line":"                N0        | VLAN 30 |"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_94b8ddc9","line":150,"in_reply_to":"da85f559_e3ec11f5","updated":"2015-11-11 00:19:16.000000000","message":"Indeed, I was just pointing out that it appears to behave like a bridge, even if it\u0027s a collection of ports. I\u0027ve tried an alternative diagram where P0 is represented like just another port, and the parent child relationship is expressed as arrows from P0 to P1...Pn, but it renders terribly.\n\nThe rendering of this diagram can be re-addressed at a later stage.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"c9621d729638165d57167681cb8a377f5df0f571","unresolved":false,"context_lines":[{"line_number":153,"context_line":"                N0        | VLAN 30 |"},{"line_number":154,"context_line":"                          +---------+"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"* PO \u003d Regular VIF port"},{"line_number":157,"context_line":"* S1-S3 \u003d Sub-ports"},{"line_number":158,"context_line":"* N0-N3 \u003d Networks"},{"line_number":159,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_ad32785d","line":156,"updated":"2015-11-10 22:01:24.000000000","message":"typo!!!! s/o/0/","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"27204c8803b2f582ecb7a2f1909067052978efb5","unresolved":false,"context_lines":[{"line_number":153,"context_line":"                N0        | VLAN 30 |"},{"line_number":154,"context_line":"                          +---------+"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"* PO \u003d Regular VIF port"},{"line_number":157,"context_line":"* S1-S3 \u003d Sub-ports"},{"line_number":158,"context_line":"* N0-N3 \u003d Networks"},{"line_number":159,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_83bc25dd","line":156,"in_reply_to":"da85f559_ad32785d","updated":"2015-11-10 22:30:45.000000000","message":"ha, nice catch.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"c9621d729638165d57167681cb8a377f5df0f571","unresolved":false,"context_lines":[{"line_number":168,"context_line":"+---------+--------------+"},{"line_number":169,"context_line":"|VM sends |Frame goes to |"},{"line_number":170,"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+"},{"line_number":171,"context_line":"|Untagged | N0           |"},{"line_number":172,"context_line":"+---------+--------------+"},{"line_number":173,"context_line":"|VID 10   | N1           |"},{"line_number":174,"context_line":"+---------+--------------+"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_809dfbbd","line":171,"updated":"2015-11-10 22:01:24.000000000","message":"Can you provide a use case for having the parent port acting as a regular port as well for untagged traffic? Is it for a sort of \"backward compatibility\"?\n\nYou explain what how this \"special case\" works below, but there\u0027s no indication concerning where it would be useful.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"27204c8803b2f582ecb7a2f1909067052978efb5","unresolved":false,"context_lines":[{"line_number":168,"context_line":"+---------+--------------+"},{"line_number":169,"context_line":"|VM sends |Frame goes to |"},{"line_number":170,"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+"},{"line_number":171,"context_line":"|Untagged | N0           |"},{"line_number":172,"context_line":"+---------+--------------+"},{"line_number":173,"context_line":"|VID 10   | N1           |"},{"line_number":174,"context_line":"+---------+--------------+"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_a3e4c9e0","line":171,"in_reply_to":"da85f559_809dfbbd","updated":"2015-11-10 22:30:45.000000000","message":"It\u0027s mostly because that\u0027s how a port behaves today.  This proposal is mainly based around trying to leave the parent port alone as much as possible and just defining child ports behind it.\n\nIt seems like making the parent port behave any other way would be much more disruptive to Neutron\u0027s existing model.\n\nIt\u0027s fairly convenient to have it defined this way though for some use cases.  The \"containers in a VM\" use case is a good example.  The parent Neutron port would be for the VM, and the untagged traffic would behave just like a Neutron port on a VM today.  Containers created inside that VM would then be mapped to the sub-ports so that the containers\u0027 traffic can all go over the single VIF, but be attached to different Neutron networks.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"68558428beaf72df2137408b489f38909306b1f2","unresolved":false,"context_lines":[{"line_number":168,"context_line":"+---------+--------------+"},{"line_number":169,"context_line":"|VM sends |Frame goes to |"},{"line_number":170,"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+"},{"line_number":171,"context_line":"|Untagged | N0           |"},{"line_number":172,"context_line":"+---------+--------------+"},{"line_number":173,"context_line":"|VID 10   | N1           |"},{"line_number":174,"context_line":"+---------+--------------+"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_83c98528","line":171,"in_reply_to":"da85f559_809dfbbd","updated":"2015-11-10 22:25:45.000000000","message":"The use case I see is needing to dhcp for an address without any vlan configuration so we can talk to the metadata server to find out we need to configure vlans :)","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"e041a853a153918abd89892c2e26dc58bb6e63be","unresolved":false,"context_lines":[{"line_number":168,"context_line":"+---------+--------------+"},{"line_number":169,"context_line":"|VM sends |Frame goes to |"},{"line_number":170,"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+"},{"line_number":171,"context_line":"|Untagged | N0           |"},{"line_number":172,"context_line":"+---------+--------------+"},{"line_number":173,"context_line":"|VID 10   | N1           |"},{"line_number":174,"context_line":"+---------+--------------+"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_74b3f9e9","line":171,"in_reply_to":"da85f559_83c98528","updated":"2015-11-11 00:19:16.000000000","message":"sounds reasonable to me, and this could be added to the document for the other pedant readers like me.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"e041a853a153918abd89892c2e26dc58bb6e63be","unresolved":false,"context_lines":[{"line_number":168,"context_line":"+---------+--------------+"},{"line_number":169,"context_line":"|VM sends |Frame goes to |"},{"line_number":170,"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+"},{"line_number":171,"context_line":"|Untagged | N0           |"},{"line_number":172,"context_line":"+---------+--------------+"},{"line_number":173,"context_line":"|VID 10   | N1           |"},{"line_number":174,"context_line":"+---------+--------------+"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_f444c9b7","line":171,"in_reply_to":"da85f559_a3e4c9e0","updated":"2015-11-11 00:19:16.000000000","message":"I think Dan provided a compelling use case which makes sense both for the containers and NFV use case under the assumption that the metadata server is used for storing VLAN configuration info for subports.\n\nI agree on your statement about ensuring that parent ports were exactly neutron ports.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"c9621d729638165d57167681cb8a377f5df0f571","unresolved":false,"context_lines":[{"line_number":178,"context_line":"+---------+--------------+"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Constraints"},{"line_number":181,"context_line":"-----------"},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"* A subport must have exactly one parent, a port marked as being a parent."},{"line_number":184,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_802e5b41","line":181,"updated":"2015-11-10 22:01:24.000000000","message":"can a subport be also a parent port? I think not.\nI know this is probably trivial. It\u0027s up to you whether you wish to include this or not in constraints.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"68558428beaf72df2137408b489f38909306b1f2","unresolved":false,"context_lines":[{"line_number":178,"context_line":"+---------+--------------+"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Constraints"},{"line_number":181,"context_line":"-----------"},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"* A subport must have exactly one parent, a port marked as being a parent."},{"line_number":184,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_c3e30da3","line":181,"in_reply_to":"da85f559_802e5b41","updated":"2015-11-10 22:25:45.000000000","message":"I assume no nesting, right? Not sure nova will need to know or care, but limiting it to single-level seems reasonable.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"27204c8803b2f582ecb7a2f1909067052978efb5","unresolved":false,"context_lines":[{"line_number":178,"context_line":"+---------+--------------+"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Constraints"},{"line_number":181,"context_line":"-----------"},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"* A subport must have exactly one parent, a port marked as being a parent."},{"line_number":184,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_c3f0ed93","line":181,"in_reply_to":"da85f559_802e5b41","updated":"2015-11-10 22:30:45.000000000","message":"It can not.  I\u0027ll list that as a constraint.  It doesn\u0027t hurt to be explicit about it.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"3008454b68ab457d26ceeaadc2f738d0d4a37a82","unresolved":false,"context_lines":[{"line_number":178,"context_line":"+---------+--------------+"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Constraints"},{"line_number":181,"context_line":"-----------"},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"* A subport must have exactly one parent, a port marked as being a parent."},{"line_number":184,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_febfc8a7","line":181,"in_reply_to":"da85f559_c3e30da3","updated":"2015-11-10 22:42:42.000000000","message":"no nesting, indeed.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"4cc74360ce49831451751ce55be845a587eaf42d","unresolved":false,"context_lines":[{"line_number":201,"context_line":""},{"line_number":202,"context_line":"* A normal user can only connect subports to its own parent ports. Admin"},{"line_number":203,"context_line":"  user can connect subports to parent ports with different owners."},{"line_number":204,"context_line":""},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"Nova changes"},{"line_number":207,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_deb76438","line":204,"updated":"2015-11-10 22:32:38.000000000","message":"I\u0027ve probably missed it, but what happens in a situation where someone passes a subport ID as the port ID on a \u0027nova boot\u0027 call (just an example)?  Is it just assumed to be user error?  If so, how does the user get that feedback? What can/should Neutron do (if anything) in this scenario?  Should we disallow explicit binding on subports and rely on the parent port binding to fill in the binding details for subports?","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"2137153cdf7e191e434c2a6b3da1ead1bb9be0db","unresolved":false,"context_lines":[{"line_number":201,"context_line":""},{"line_number":202,"context_line":"* A normal user can only connect subports to its own parent ports. Admin"},{"line_number":203,"context_line":"  user can connect subports to parent ports with different owners."},{"line_number":204,"context_line":""},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"Nova changes"},{"line_number":207,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_fe44a8b7","line":204,"in_reply_to":"da85f559_deb76438","updated":"2015-11-10 22:46:30.000000000","message":"That\u0027s a great question.  It\u0027s actually discussed just below this in the comments after the \"Nova changes\" section.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"570e8592d389c3d4ed5abf89066ffa9f699154c1","unresolved":false,"context_lines":[{"line_number":201,"context_line":""},{"line_number":202,"context_line":"* A normal user can only connect subports to its own parent ports. Admin"},{"line_number":203,"context_line":"  user can connect subports to parent ports with different owners."},{"line_number":204,"context_line":""},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"Nova changes"},{"line_number":207,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_bec380ec","line":204,"in_reply_to":"da85f559_fe44a8b7","updated":"2015-11-10 23:02:36.000000000","message":"Lots of review activity while I was digesting and adding comments!","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"c9621d729638165d57167681cb8a377f5df0f571","unresolved":false,"context_lines":[{"line_number":206,"context_line":"Nova changes"},{"line_number":207,"context_line":"------------"},{"line_number":208,"context_line":""},{"line_number":209,"context_line":"No changes are required in Nova as a parent port is a regular Neutron port."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Alternatives"},{"line_number":212,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_00758b62","line":209,"updated":"2015-11-10 22:01:24.000000000","message":"Since also a subport is a regular neutron port, can I boot an instance on a subport as well? It seems you were stating above that this should not be possible, and in that case an amendement to the nova workflow should be required.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"27204c8803b2f582ecb7a2f1909067052978efb5","unresolved":false,"context_lines":[{"line_number":206,"context_line":"Nova changes"},{"line_number":207,"context_line":"------------"},{"line_number":208,"context_line":""},{"line_number":209,"context_line":"No changes are required in Nova as a parent port is a regular Neutron port."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Alternatives"},{"line_number":212,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_63eb4179","line":209,"in_reply_to":"da85f559_00758b62","updated":"2015-11-10 22:30:45.000000000","message":"A VM can not be booted with a sub-port as its port.  I think we can make this error out without any changes to Nova (or whatever project).\n\nI should write somewhere in here that a project that integrates with Neutron can *not* update the binding:host_id field of a subport.  The subport binding is handled exclusively by Neutron, as its automatically bound to wherever its parent is bound to.  That\u0027s where the Nova case would fail here.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"68558428beaf72df2137408b489f38909306b1f2","unresolved":false,"context_lines":[{"line_number":206,"context_line":"Nova changes"},{"line_number":207,"context_line":"------------"},{"line_number":208,"context_line":""},{"line_number":209,"context_line":"No changes are required in Nova as a parent port is a regular Neutron port."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Alternatives"},{"line_number":212,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_a36a89ec","line":209,"in_reply_to":"da85f559_00758b62","updated":"2015-11-10 22:25:45.000000000","message":"What would the amendment be? That we check to see that the port we were given is_parent? That will break our ability to work with older neutrons once we introduce that change.\n\nMaybe we should flip this and instead of is_parent, include an is_virtual_sub_child_port thing? If nova is given a child we can reject it, but otherwise we assume it\u0027s a parent?\n\nOr, we could just assume that anything we\u0027re given with a parent_id should be rejected, and we can ignore the parent-ness of the port we are given.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f8cdd1a447d6eae8006e557117a4a592348bed29","unresolved":false,"context_lines":[{"line_number":206,"context_line":"Nova changes"},{"line_number":207,"context_line":"------------"},{"line_number":208,"context_line":""},{"line_number":209,"context_line":"No changes are required in Nova as a parent port is a regular Neutron port."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Alternatives"},{"line_number":212,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_8fc9a428","line":209,"in_reply_to":"da85f559_3ee79012","updated":"2015-11-11 00:57:06.000000000","message":"Yep, this makes sense to me.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"570e8592d389c3d4ed5abf89066ffa9f699154c1","unresolved":false,"context_lines":[{"line_number":206,"context_line":"Nova changes"},{"line_number":207,"context_line":"------------"},{"line_number":208,"context_line":""},{"line_number":209,"context_line":"No changes are required in Nova as a parent port is a regular Neutron port."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Alternatives"},{"line_number":212,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_fea58846","line":209,"in_reply_to":"da85f559_63eb4179","updated":"2015-11-10 23:02:36.000000000","message":"Thanks for the clarification.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"3008454b68ab457d26ceeaadc2f738d0d4a37a82","unresolved":false,"context_lines":[{"line_number":206,"context_line":"Nova changes"},{"line_number":207,"context_line":"------------"},{"line_number":208,"context_line":""},{"line_number":209,"context_line":"No changes are required in Nova as a parent port is a regular Neutron port."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Alternatives"},{"line_number":212,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_3ee79012","line":209,"in_reply_to":"da85f559_a36a89ec","updated":"2015-11-10 22:42:42.000000000","message":"Dan, sorry, I replied to Salv before I saw your comments.\n\nIndeed, we could make Nova reject a port that has a parent_id.  I think that\u0027d be the right semantics here.  Otherwise, Nova should treat is_parent True vs. False as the same.  That\u0027s the key to this (a \"trunk\" port and regular port are actually the same to Nova).\n\nEven if we don\u0027t reject based on parent_id, I think Nova\u0027s attempt to update binding:host_id is going to get rejected for a subport.  We\u0027d have to look to see if a failure at that point is clean enough, though.  It probably won\u0027t be as obvious in debugging as rejecting based on parent_id, though.\n\nI\u0027ll see if I can update this text about the impact to Nova more clearly.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":162,"name":"Bob Melander","email":"bob.melander@gmail.com","username":"bob-melander"},"change_message_id":"03baab929e07309e5af63dc55e80a4a06fc68469","unresolved":false,"context_lines":[{"line_number":212,"context_line":"------------"},{"line_number":213,"context_line":""},{"line_number":214,"context_line":"A previous version of this proposal included a new first class resource called a"},{"line_number":215,"context_line":"\"trunk port\" instead of using a regular Neutron port as the parent.  The major"},{"line_number":216,"context_line":"functional difference between the two is that in this proposal, the parent port"},{"line_number":217,"context_line":"handles untagged traffic.  This is discussed in a bit more detail in the"},{"line_number":218,"context_line":"\"Constraints\" section.  Some benefits of going with the existing port resources"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_b47ba18b","line":215,"updated":"2015-11-11 00:22:18.000000000","message":"Have you looked the first iterations of that proposal you refer to? It seems like this draft is the pretty much a return to that original proposal.\n\nThere were several review iterations while that proposal was still focusing on extending the port resource. If it has not been done I think it could be useful to go through those comments/revisions too, given the similartity.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"11548866fd59cabf69edbbb3f70abea531111ebc","unresolved":false,"context_lines":[{"line_number":212,"context_line":"------------"},{"line_number":213,"context_line":""},{"line_number":214,"context_line":"A previous version of this proposal included a new first class resource called a"},{"line_number":215,"context_line":"\"trunk port\" instead of using a regular Neutron port as the parent.  The major"},{"line_number":216,"context_line":"functional difference between the two is that in this proposal, the parent port"},{"line_number":217,"context_line":"handles untagged traffic.  This is discussed in a bit more detail in the"},{"line_number":218,"context_line":"\"Constraints\" section.  Some benefits of going with the existing port resources"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_a0c33256","line":215,"in_reply_to":"da85f559_b47ba18b","updated":"2015-11-11 17:53:06.000000000","message":"I have, yes.  I realize we\u0027re revisiting the original proposal here.  I decided to be really difficult and bring it back up again, because I wasn\u0027t convinced the switch was best.  Sorry for the noise.  Sometimes landing on the best abstraction is really hard.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"c9621d729638165d57167681cb8a377f5df0f571","unresolved":false,"context_lines":[{"line_number":220,"context_line":""},{"line_number":221,"context_line":"* It is my gut feeling that this proposal will result in a simpler"},{"line_number":222,"context_line":"  implementation that requires less code, though that will have to be proven"},{"line_number":223,"context_line":"  with code, which I\u0027d like to help with to help move things along."},{"line_number":224,"context_line":"* No changes are required to any project that handles VIF port"},{"line_number":225,"context_line":"  bindings, such as Nova or Kuryr, since a parent port is just a regular Neutron"},{"line_number":226,"context_line":"  port resource."}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_c018e320","line":223,"updated":"2015-11-10 22:01:24.000000000","message":"We have different guts, but that\u0027s ok!","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"27204c8803b2f582ecb7a2f1909067052978efb5","unresolved":false,"context_lines":[{"line_number":220,"context_line":""},{"line_number":221,"context_line":"* It is my gut feeling that this proposal will result in a simpler"},{"line_number":222,"context_line":"  implementation that requires less code, though that will have to be proven"},{"line_number":223,"context_line":"  with code, which I\u0027d like to help with to help move things along."},{"line_number":224,"context_line":"* No changes are required to any project that handles VIF port"},{"line_number":225,"context_line":"  bindings, such as Nova or Kuryr, since a parent port is just a regular Neutron"},{"line_number":226,"context_line":"  port resource."}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_63b90179","line":223,"in_reply_to":"da85f559_c018e320","updated":"2015-11-10 22:30:45.000000000","message":"Don\u0027t we all?\n\nMaybe I shouldn\u0027t put this here, but it\u0027s pretty important.  I don\u0027t see how we\u0027ll get consensus on this point without some code, though.\n\nOne way to proceed here would be to not actually approve this but say \"OK, pending how much we like or hate the implementation\" and then let me go off and work on an implementation with the understanding that people might hate it.  We have the start of the \"trunk port\" approach up for review, so I could put up the alternative.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"c9621d729638165d57167681cb8a377f5df0f571","unresolved":false,"context_lines":[{"line_number":223,"context_line":"  with code, which I\u0027d like to help with to help move things along."},{"line_number":224,"context_line":"* No changes are required to any project that handles VIF port"},{"line_number":225,"context_line":"  bindings, such as Nova or Kuryr, since a parent port is just a regular Neutron"},{"line_number":226,"context_line":"  port resource."},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"One alternative is to extend the port so that it can be connected to"},{"line_number":229,"context_line":"multiple networks directly. The main disadvantage with that is that it"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_a0a83f8e","line":226,"updated":"2015-11-10 22:01:24.000000000","message":"This is agreeable. But on the other hand the cases for nova and kuryr are different, as the former must boot instance with trunkport for NFV/container purposes whereas the latter should probably create subports for containers (I assume the vm where the containers run should be booted by nova)","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"27204c8803b2f582ecb7a2f1909067052978efb5","unresolved":false,"context_lines":[{"line_number":223,"context_line":"  with code, which I\u0027d like to help with to help move things along."},{"line_number":224,"context_line":"* No changes are required to any project that handles VIF port"},{"line_number":225,"context_line":"  bindings, such as Nova or Kuryr, since a parent port is just a regular Neutron"},{"line_number":226,"context_line":"  port resource."},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"One alternative is to extend the port so that it can be connected to"},{"line_number":229,"context_line":"multiple networks directly. The main disadvantage with that is that it"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_03611505","line":226,"in_reply_to":"da85f559_a0a83f8e","updated":"2015-11-10 22:30:45.000000000","message":"Yeah, I\u0027m not totally clear how the workflow will end up in the Kuryr case.  It could be something like Magnum creating the VMs / neutron parent ports and its container orchestration system (say, Kubernetes) having a plugin which is calling the Neutron API to create subports for Kuryr.\n\nmaybe I should limit this to \"such as Nova\".  I just like pointing out that Nova isn\u0027t the *only* project affected.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"c9621d729638165d57167681cb8a377f5df0f571","unresolved":false,"context_lines":[{"line_number":224,"context_line":"* No changes are required to any project that handles VIF port"},{"line_number":225,"context_line":"  bindings, such as Nova or Kuryr, since a parent port is just a regular Neutron"},{"line_number":226,"context_line":"  port resource."},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"One alternative is to extend the port so that it can be connected to"},{"line_number":229,"context_line":"multiple networks directly. The main disadvantage with that is that it"},{"line_number":230,"context_line":"would change the port in such way that it affected other services in"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_a067df4b","line":227,"updated":"2015-11-10 22:01:24.000000000","message":"While the benefits in terms of simpler implementation might be true (but have to be proved nonetheless), it is worth noting in my opinion that the parent/child relationship creates a port which, as stated in another comment, actually behaves more like a bridge, as it forwards tagged traffic to other ports.\n\nOn the other the concept of trunk port was merely a construct that represented a grouping of ports. Please note that it is not my intention to start a holy war on this, at the end of the day it\u0027s just an opinion vs another opinion and until we feed this to the users we won\u0027t never know if we got it right or not.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"570e8592d389c3d4ed5abf89066ffa9f699154c1","unresolved":false,"context_lines":[{"line_number":224,"context_line":"* No changes are required to any project that handles VIF port"},{"line_number":225,"context_line":"  bindings, such as Nova or Kuryr, since a parent port is just a regular Neutron"},{"line_number":226,"context_line":"  port resource."},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"One alternative is to extend the port so that it can be connected to"},{"line_number":229,"context_line":"multiple networks directly. The main disadvantage with that is that it"},{"line_number":230,"context_line":"would change the port in such way that it affected other services in"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_797f7266","line":227,"in_reply_to":"da85f559_230c5940","updated":"2015-11-10 23:02:36.000000000","message":"Not that I think it matters (joining Salvatore in being pedantic :) ), but the analogy here may be that of a tunnel endpoint/gateway.  Packets hit the parent port, are encapsulated, and sent on their way to the appropriate subport.  I think the model being proposed is sufficient.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":162,"name":"Bob Melander","email":"bob.melander@gmail.com","username":"bob-melander"},"change_message_id":"03baab929e07309e5af63dc55e80a4a06fc68469","unresolved":false,"context_lines":[{"line_number":224,"context_line":"* No changes are required to any project that handles VIF port"},{"line_number":225,"context_line":"  bindings, such as Nova or Kuryr, since a parent port is just a regular Neutron"},{"line_number":226,"context_line":"  port resource."},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"One alternative is to extend the port so that it can be connected to"},{"line_number":229,"context_line":"multiple networks directly. The main disadvantage with that is that it"},{"line_number":230,"context_line":"would change the port in such way that it affected other services in"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_549d9508","line":227,"in_reply_to":"da85f559_797f7266","updated":"2015-11-11 00:22:18.000000000","message":"I\u0027ve always felt that the extending the port resource was more natural (probably cuz of my networking background). But I\u0027ve also felt that, regardless if the port resource is extended or if its a new resource is introduced, I would have no problem understanding how to use them. And I\u0027m no Einstein so my guess is that most devs wouldn\u0027t have problems either.\n\nBut that extended port approach was quite heavily opposed by some cores after the kilo/liberty summit. As I recall the message was pretty much \"to get this merged you should introduce a new trunkport resource\". I also recall someone, perhaps HenryG, suggesting that a new resouce would be more in line with openstack api guidelines.\n\nThat\u0027s why the earlier proposal made that 90 degree turn.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"e041a853a153918abd89892c2e26dc58bb6e63be","unresolved":false,"context_lines":[{"line_number":224,"context_line":"* No changes are required to any project that handles VIF port"},{"line_number":225,"context_line":"  bindings, such as Nova or Kuryr, since a parent port is just a regular Neutron"},{"line_number":226,"context_line":"  port resource."},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"One alternative is to extend the port so that it can be connected to"},{"line_number":229,"context_line":"multiple networks directly. The main disadvantage with that is that it"},{"line_number":230,"context_line":"would change the port in such way that it affected other services in"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_f4a5a946","line":227,"in_reply_to":"da85f559_797f7266","updated":"2015-11-11 00:19:16.000000000","message":"this is how it could be implemented. In the logical model we assume the encap fairy will somehow do all the conversion that we need.\n\nBut on the other hand this is probably the first time we attempt to do data path modeling in neutron logical model, so it is right to speculate about what this thing look like.\n\nI get Russell\u0027s point that it is not a bridge because ports do not communicate each other. But on the other hand it forwards traffic, and could be implemented with a bridge (what do we do in OVN, at the end of the day?). However, in the logical model it CANNOT be a bridge - agreed, because if nothing else we need to preserve our current workflow, which prescribes us to attach VMs to this thing, and we can do this only on ports.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"27204c8803b2f582ecb7a2f1909067052978efb5","unresolved":false,"context_lines":[{"line_number":224,"context_line":"* No changes are required to any project that handles VIF port"},{"line_number":225,"context_line":"  bindings, such as Nova or Kuryr, since a parent port is just a regular Neutron"},{"line_number":226,"context_line":"  port resource."},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"One alternative is to extend the port so that it can be connected to"},{"line_number":229,"context_line":"multiple networks directly. The main disadvantage with that is that it"},{"line_number":230,"context_line":"would change the port in such way that it affected other services in"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_230c5940","line":227,"in_reply_to":"da85f559_a067df4b","updated":"2015-11-10 22:30:45.000000000","message":"I don\u0027t think it\u0027s like a bridge, though.  The parent and subports can\u0027t talk to each other at all.  It seems more like we needed a way to do some data path modeling in Neutron.  The ports are logically separate (on different networks entirely), but the packets flow through a common point (the VM\u0027s VIF).  It\u0027s hard to express this effectively.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"c9621d729638165d57167681cb8a377f5df0f571","unresolved":false,"context_lines":[{"line_number":226,"context_line":"  port resource."},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"One alternative is to extend the port so that it can be connected to"},{"line_number":229,"context_line":"multiple networks directly. The main disadvantage with that is that it"},{"line_number":230,"context_line":"would change the port in such way that it affected other services in"},{"line_number":231,"context_line":"neutron that uses port information from ports connected to VMs. An example"},{"line_number":232,"context_line":"of this is the DHCP agent. Another benefit of using solution with parent"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_00982b77","line":229,"updated":"2015-11-10 22:01:24.000000000","message":"I think this is more a threat than an alternative ;)","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"27204c8803b2f582ecb7a2f1909067052978efb5","unresolved":false,"context_lines":[{"line_number":226,"context_line":"  port resource."},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"One alternative is to extend the port so that it can be connected to"},{"line_number":229,"context_line":"multiple networks directly. The main disadvantage with that is that it"},{"line_number":230,"context_line":"would change the port in such way that it affected other services in"},{"line_number":231,"context_line":"neutron that uses port information from ports connected to VMs. An example"},{"line_number":232,"context_line":"of this is the DHCP agent. Another benefit of using solution with parent"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_be06201b","line":229,"in_reply_to":"da85f559_00982b77","updated":"2015-11-10 22:30:45.000000000","message":"ha.  :)","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"c9621d729638165d57167681cb8a377f5df0f571","unresolved":false,"context_lines":[{"line_number":301,"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\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\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":302,"context_line":"|subport:  |bool   |CR, all  |false    |bool        |Indicate that a port |"},{"line_number":303,"context_line":"|is_parent |       |         |         |            |may have child       |"},{"line_number":304,"context_line":"|          |       |         |         |            |subports.            |"},{"line_number":305,"context_line":"+----------+-------+---------+---------+------------+---------------------+"},{"line_number":306,"context_line":"|subport:  |string |CR, all  |\u0027\u0027       |uuid of     |ID of the parent     |"},{"line_number":307,"context_line":"|parent_id |(UUID) |         |         |parent      |port that subport is |"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_20dbefed","line":304,"updated":"2015-11-10 22:01:24.000000000","message":"if this is set to True it seems to me that the other attributes should be left unspecified.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"68558428beaf72df2137408b489f38909306b1f2","unresolved":false,"context_lines":[{"line_number":301,"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\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\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":302,"context_line":"|subport:  |bool   |CR, all  |false    |bool        |Indicate that a port |"},{"line_number":303,"context_line":"|is_parent |       |         |         |            |may have child       |"},{"line_number":304,"context_line":"|          |       |         |         |            |subports.            |"},{"line_number":305,"context_line":"+----------+-------+---------+---------+------------+---------------------+"},{"line_number":306,"context_line":"|subport:  |string |CR, all  |\u0027\u0027       |uuid of     |ID of the parent     |"},{"line_number":307,"context_line":"|parent_id |(UUID) |         |         |parent      |port that subport is |"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_235e9944","line":304,"in_reply_to":"da85f559_20dbefed","updated":"2015-11-10 22:25:45.000000000","message":"Also, is a normal port right now not already a parent port with no children?\n\nThinking about it from the \"parent is untagged\" point of view, it seems hard for me to grok that is_parent\u003dTrue makes a port different than it is now, from nova\u0027s perspective (and the user\u0027s as well). Should we not be considering the new virtual-only child thing to be the \"new\" thing being added here?","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"27204c8803b2f582ecb7a2f1909067052978efb5","unresolved":false,"context_lines":[{"line_number":301,"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\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\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":302,"context_line":"|subport:  |bool   |CR, all  |false    |bool        |Indicate that a port |"},{"line_number":303,"context_line":"|is_parent |       |         |         |            |may have child       |"},{"line_number":304,"context_line":"|          |       |         |         |            |subports.            |"},{"line_number":305,"context_line":"+----------+-------+---------+---------+------------+---------------------+"},{"line_number":306,"context_line":"|subport:  |string |CR, all  |\u0027\u0027       |uuid of     |ID of the parent     |"},{"line_number":307,"context_line":"|parent_id |(UUID) |         |         |parent      |port that subport is |"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_de1be471","line":304,"in_reply_to":"da85f559_20dbefed","updated":"2015-11-10 22:30:45.000000000","message":"agreed","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"3008454b68ab457d26ceeaadc2f738d0d4a37a82","unresolved":false,"context_lines":[{"line_number":301,"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\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\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":302,"context_line":"|subport:  |bool   |CR, all  |false    |bool        |Indicate that a port |"},{"line_number":303,"context_line":"|is_parent |       |         |         |            |may have child       |"},{"line_number":304,"context_line":"|          |       |         |         |            |subports.            |"},{"line_number":305,"context_line":"+----------+-------+---------+---------+------------+---------------------+"},{"line_number":306,"context_line":"|subport:  |string |CR, all  |\u0027\u0027       |uuid of     |ID of the parent     |"},{"line_number":307,"context_line":"|parent_id |(UUID) |         |         |parent      |port that subport is |"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_deabe473","line":304,"in_reply_to":"da85f559_235e9944","updated":"2015-11-10 22:42:42.000000000","message":"Dan, a normal port right now is indeed a parent port with no children.  From nova\u0027s perspective it shouldn\u0027t care.\n\nOne option is to remove \"is_parent\" completely.  I\u0027d actually be fine with that.  The biggest benefit to keeping it is that it allows Neutron to reject the port creation request if the Neutron backend doesn\u0027t support it.  \n\nIt could also be helpful in some backend implementation details, but I don\u0027t think that alone would be enough to justify it.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"11548866fd59cabf69edbbb3f70abea531111ebc","unresolved":false,"context_lines":[{"line_number":301,"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\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\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":302,"context_line":"|subport:  |bool   |CR, all  |false    |bool        |Indicate that a port |"},{"line_number":303,"context_line":"|is_parent |       |         |         |            |may have child       |"},{"line_number":304,"context_line":"|          |       |         |         |            |subports.            |"},{"line_number":305,"context_line":"+----------+-------+---------+---------+------------+---------------------+"},{"line_number":306,"context_line":"|subport:  |string |CR, all  |\u0027\u0027       |uuid of     |ID of the parent     |"},{"line_number":307,"context_line":"|parent_id |(UUID) |         |         |parent      |port that subport is |"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_8074ee35","line":304,"in_reply_to":"da85f559_af9ca80f","updated":"2015-11-11 17:53:06.000000000","message":"Yeah, is_parent\u003dFalse would be on all normal ports as they exist today.  Nova should be able to ignore is_parent completely.\n\nI think the only value is_parent provides is to let Neutron reject the port create with is_parent\u003dTrue if subports aren\u0027t supported instead of rejecting the subports later or something.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f8cdd1a447d6eae8006e557117a4a592348bed29","unresolved":false,"context_lines":[{"line_number":301,"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\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\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":302,"context_line":"|subport:  |bool   |CR, all  |false    |bool        |Indicate that a port |"},{"line_number":303,"context_line":"|is_parent |       |         |         |            |may have child       |"},{"line_number":304,"context_line":"|          |       |         |         |            |subports.            |"},{"line_number":305,"context_line":"+----------+-------+---------+---------+------------+---------------------+"},{"line_number":306,"context_line":"|subport:  |string |CR, all  |\u0027\u0027       |uuid of     |ID of the parent     |"},{"line_number":307,"context_line":"|parent_id |(UUID) |         |         |parent      |port that subport is |"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_af9ca80f","line":304,"in_reply_to":"da85f559_deabe473","updated":"2015-11-11 00:57:06.000000000","message":"So when would is_parent\u003dFalse? If this isn\u0027t a trunk port and we want to make damned sure everyone knows it?\n\nIf it\u0027s just to communicate to networky things that you can\u0027t attach a subport to this thing, then I guess that\u0027s cool. Either way, sounds like Nova doesn\u0027t need to care about this, regardless of the decision.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"4cc74360ce49831451751ce55be845a587eaf42d","unresolved":false,"context_lines":[{"line_number":318,"context_line":"|          |       |         |         |            |the subport as they  |"},{"line_number":319,"context_line":"|          |       |         |         |            |pass through the     |"},{"line_number":320,"context_line":"|          |       |         |         |            |parent port.         |"},{"line_number":321,"context_line":"+----------+-------+---------+---------+------------+---------------------+"},{"line_number":322,"context_line":""},{"line_number":323,"context_line":"(*) As the blueprint is focused on VLAN tagging, only \u0027vlan\u0027 encap_type"},{"line_number":324,"context_line":"is defined here. Any extension is a subject of further separate blueprints."}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_03fb557a","line":321,"updated":"2015-11-10 22:32:38.000000000","message":"Just want to make sure I\u0027m reading this correctly, a child port shares a MAC address with its parent?","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"2137153cdf7e191e434c2a6b3da1ead1bb9be0db","unresolved":false,"context_lines":[{"line_number":318,"context_line":"|          |       |         |         |            |the subport as they  |"},{"line_number":319,"context_line":"|          |       |         |         |            |pass through the     |"},{"line_number":320,"context_line":"|          |       |         |         |            |parent port.         |"},{"line_number":321,"context_line":"+----------+-------+---------+---------+------------+---------------------+"},{"line_number":322,"context_line":""},{"line_number":323,"context_line":"(*) As the blueprint is focused on VLAN tagging, only \u0027vlan\u0027 encap_type"},{"line_number":324,"context_line":"is defined here. Any extension is a subject of further separate blueprints."}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_9e7b1cf5","line":321,"in_reply_to":"da85f559_03fb557a","updated":"2015-11-10 22:46:30.000000000","message":"No, it has an independent MAC address, just like any other Neutron port.  Logically, a subport is just another port on a Neutron network, it just so happens that in the datapath, the bits for several subports go through a single VM\u0027s VIF with an encapsulation (VLAN ID in this case) so that there is a way to differentiate the difference between packets to/from each subport.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"570e8592d389c3d4ed5abf89066ffa9f699154c1","unresolved":false,"context_lines":[{"line_number":318,"context_line":"|          |       |         |         |            |the subport as they  |"},{"line_number":319,"context_line":"|          |       |         |         |            |pass through the     |"},{"line_number":320,"context_line":"|          |       |         |         |            |parent port.         |"},{"line_number":321,"context_line":"+----------+-------+---------+---------+------------+---------------------+"},{"line_number":322,"context_line":""},{"line_number":323,"context_line":"(*) As the blueprint is focused on VLAN tagging, only \u0027vlan\u0027 encap_type"},{"line_number":324,"context_line":"is defined here. Any extension is a subject of further separate blueprints."}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_be514038","line":321,"in_reply_to":"da85f559_9e7b1cf5","updated":"2015-11-10 23:02:36.000000000","message":"Got it.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"c9621d729638165d57167681cb8a377f5df0f571","unresolved":false,"context_lines":[{"line_number":349,"context_line":"In some cases, this change may improve performance.  Without this change,"},{"line_number":350,"context_line":"connecting a VM to many Neutron networks required a VIF per network.  With this"},{"line_number":351,"context_line":"change, you could connect to 1000 Neutron networks with very little overhead vs."},{"line_number":352,"context_line":"having to attach 1000 virtual interfaces to your VM before."},{"line_number":353,"context_line":""},{"line_number":354,"context_line":"IPv6 Impact"},{"line_number":355,"context_line":"-----------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_80973beb","line":352,"updated":"2015-11-10 22:01:24.000000000","message":"as long as you have a solution to do segmentation in the VM you\u0027re right.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"27204c8803b2f582ecb7a2f1909067052978efb5","unresolved":false,"context_lines":[{"line_number":349,"context_line":"In some cases, this change may improve performance.  Without this change,"},{"line_number":350,"context_line":"connecting a VM to many Neutron networks required a VIF per network.  With this"},{"line_number":351,"context_line":"change, you could connect to 1000 Neutron networks with very little overhead vs."},{"line_number":352,"context_line":"having to attach 1000 virtual interfaces to your VM before."},{"line_number":353,"context_line":""},{"line_number":354,"context_line":"IPv6 Impact"},{"line_number":355,"context_line":"-----------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_de3204f2","line":352,"in_reply_to":"da85f559_80973beb","updated":"2015-11-10 22:30:45.000000000","message":"indeed, I can add a note to that effect","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"c9621d729638165d57167681cb8a377f5df0f571","unresolved":false,"context_lines":[{"line_number":392,"context_line":"* Neutron Plugin support."},{"line_number":393,"context_line":"  * networking-ovn (OVN supports this model already)"},{"line_number":394,"context_line":"  * ml2+ovs"},{"line_number":395,"context_line":""},{"line_number":396,"context_line":"Dependencies"},{"line_number":397,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":398,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_8065fb1e","line":395,"updated":"2015-11-10 22:01:24.000000000","message":"Kuryr will need to explicitly leverage this imho.\nAre the relevant changes to kuryr in the scope of this spec?","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"27204c8803b2f582ecb7a2f1909067052978efb5","unresolved":false,"context_lines":[{"line_number":392,"context_line":"* Neutron Plugin support."},{"line_number":393,"context_line":"  * networking-ovn (OVN supports this model already)"},{"line_number":394,"context_line":"  * ml2+ovs"},{"line_number":395,"context_line":""},{"line_number":396,"context_line":"Dependencies"},{"line_number":397,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":398,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"da85f559_7e7198a7","line":395,"in_reply_to":"da85f559_8065fb1e","updated":"2015-11-10 22:30:45.000000000","message":"I think it\u0027s in scope to some degree.  I wouldn\u0027t say the Kuryr changes are in scope, but it\u0027s certainly useful and important to make sure that whatever is proposed here seems to support what we want to do there.  Hopefully some review can help figure that out, without having to fully spec it out.\n\nIn terms of modeling containers in a VM, I think this provides the important constructs needed, but I\u0027d love to hear any feedback on what might be missing.","commit_id":"889b8e6a2b402cb533d4cd317bbece947d04ed0a"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"d432d1cead24657cba1ec3fec42b1a7a9d7de277","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":" https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms"},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"This blueprint proposes how to incorporate VLAN aware VMs into"},{"line_number":16,"context_line":"OpenStack. In this document a VLAN aware VM is a VM that sends and receives"},{"line_number":17,"context_line":"VLAN tagged frames over its vNIC. Pros are better scalability and more"},{"line_number":18,"context_line":"dynamic handling of Neutron networks connected to VMs."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_5cd6d328","line":15,"updated":"2015-11-12 09:19:35.000000000","message":"Let\u0027s finally get rid of any vlan specific stuff and talk generically about encapsulated traffic.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"7509912250b1a126386331909bebc1bf5c83a954","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":" https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms"},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"This blueprint proposes how to incorporate VLAN aware VMs into"},{"line_number":16,"context_line":"OpenStack. In this document a VLAN aware VM is a VM that sends and receives"},{"line_number":17,"context_line":"VLAN tagged frames over its vNIC. Pros are better scalability and more"},{"line_number":18,"context_line":"dynamic handling of Neutron networks connected to VMs."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_d47272b0","line":15,"in_reply_to":"da85f559_5cd6d328","updated":"2015-11-12 20:15:53.000000000","message":"The scope of this spec is limited to only implementing VLAN support, even though the API leaves room for other encap types in the future, so I think it\u0027s fine to describe the overall goal here as \"VLAN aware VMs\" because that\u0027s what you get when this is completed, as defined.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"2cb3e7b3d3790c4b671e382032045463c4eea077","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":" https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms"},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"This blueprint proposes how to incorporate VLAN aware VMs into"},{"line_number":16,"context_line":"OpenStack. In this document a VLAN aware VM is a VM that sends and receives"},{"line_number":17,"context_line":"VLAN tagged frames over its vNIC. Pros are better scalability and more"},{"line_number":18,"context_line":"dynamic handling of Neutron networks connected to VMs."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_7454d020","line":15,"in_reply_to":"da85f559_d47272b0","updated":"2015-11-13 09:00:01.000000000","message":"Ok.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"d432d1cead24657cba1ec3fec42b1a7a9d7de277","unresolved":false,"context_lines":[{"line_number":21,"context_line":"Problem Description"},{"line_number":22,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"Currently VLANs in VMs are not integrated with Neutron.  There are various use"},{"line_number":25,"context_line":"cases where it would be useful to allow a VM to be attached to multiple Neutron"},{"line_number":26,"context_line":"networks using VLANs as a local encapsulation to differentiate the traffic for"},{"line_number":27,"context_line":"each network as it goes in/out of the single VIF."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_dcd403ed","line":24,"updated":"2015-11-12 09:19:35.000000000","message":"Suggested clarification: Currently it\u0027s practically impossible to access more than a few dozen networks from an instance, because each port comes with a vNIC. There are various use cases where accessing hundreds or thousands of networks from a single instance is needed. Encapsulated traffic over a single (or a few) vNIC allows access to any number of networks. It also makes possible joining and leaving networks while an instance is already running.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"2cb3e7b3d3790c4b671e382032045463c4eea077","unresolved":false,"context_lines":[{"line_number":21,"context_line":"Problem Description"},{"line_number":22,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"Currently VLANs in VMs are not integrated with Neutron.  There are various use"},{"line_number":25,"context_line":"cases where it would be useful to allow a VM to be attached to multiple Neutron"},{"line_number":26,"context_line":"networks using VLANs as a local encapsulation to differentiate the traffic for"},{"line_number":27,"context_line":"each network as it goes in/out of the single VIF."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_28390842","line":24,"in_reply_to":"da85f559_b4a80edd","updated":"2015-11-13 09:00:01.000000000","message":"I agree that most of this is covered and I can accept the current text. I think there\u0027s no error in it. However in the past I had to explain what vlan-aware-vms are and the difference between nfv-vlan-trunk and vlan-aware-vms. After repeating the explanation a dozen times I started to change my terminology and explanation a bit, that was the main reason for my original suggestion here.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"7509912250b1a126386331909bebc1bf5c83a954","unresolved":false,"context_lines":[{"line_number":21,"context_line":"Problem Description"},{"line_number":22,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"Currently VLANs in VMs are not integrated with Neutron.  There are various use"},{"line_number":25,"context_line":"cases where it would be useful to allow a VM to be attached to multiple Neutron"},{"line_number":26,"context_line":"networks using VLANs as a local encapsulation to differentiate the traffic for"},{"line_number":27,"context_line":"each network as it goes in/out of the single VIF."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_b4a80edd","line":24,"in_reply_to":"da85f559_dcd403ed","updated":"2015-11-12 20:15:53.000000000","message":"I think all of this is covered in the bullet points below already.  Let me know what you think is missing.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"d432d1cead24657cba1ec3fec42b1a7a9d7de277","unresolved":false,"context_lines":[{"line_number":53,"context_line":"by the VM (or an appliance inside a VM)."},{"line_number":54,"context_line":""},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"Proposed Change"},{"line_number":57,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"The proposal is to add a subport API extension.  The best way to think about"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_3039b3d7","line":56,"updated":"2015-11-12 09:19:35.000000000","message":"Before we get into proposed solutions, I\u0027d like to sum up my understanding of the underlying problem. Before cloud existed people needed to access lots of networks. They realized it\u0027s impossible to have one NIC per network, so they started virtualizing their networks like introducing VLANs and other encapsulations. As soon as this was given, a real switchport or a real NIC was attached to multiple (0, 1, many) networks.\n\nHowever neutron started with an API model where a port:\n - must belong to exactly one network\n - at port creation time\n - and this cannot be changed later.\n\nI believe every one of these points is a limitation to what neutron can do. If I were designing a network API today, I\u0027d have a port resource (independently existing of any nets), a net resource (independent of any ports) and a port-net relations resource (just like relational db schema design 101). Then extending the API to support more than one networks per port would be equivalent to removing a uniqueness constraint.\n\nIn my mind this is the ideal API we should be approximating here, by limiting backwards incompatible breakage and keeping the magnitude of the implementation effort in mind.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"04461e97052279d96e1f1fb0999dc866fa90b2c5","unresolved":false,"context_lines":[{"line_number":53,"context_line":"by the VM (or an appliance inside a VM)."},{"line_number":54,"context_line":""},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"Proposed Change"},{"line_number":57,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"The proposal is to add a subport API extension.  The best way to think about"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_4b51f9d7","line":56,"updated":"2015-11-12 21:40:49.000000000","message":"The issue is that current implementations bind the VIF and the Port in a 1:1 relationship. What you said is true about VIFs, but is incorrect with regard to Neutron ports. Nothing in the Neutron logical model precludes many Neutron ports from being realized on a single VIF. I\u0027m just not aware of any backends that have chosen to do it that way.\n\n\u003eI\u0027d have a port resource (independently existing of any nets), a net resource (independent of any ports) and a port-net relations resource (just like relational db schema design 101).\n\nThe current neutron port resource an entry in the port-net relations table you are talking about. The thing you are calling a \u0027port\u0027 is the VIF, which Neutron doesn\u0027t really model right now.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"2cb3e7b3d3790c4b671e382032045463c4eea077","unresolved":false,"context_lines":[{"line_number":53,"context_line":"by the VM (or an appliance inside a VM)."},{"line_number":54,"context_line":""},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"Proposed Change"},{"line_number":57,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"The proposal is to add a subport API extension.  The best way to think about"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_08b5247d","line":56,"in_reply_to":"da85f559_4b51f9d7","updated":"2015-11-13 09:00:01.000000000","message":"Sorry for the confusing terminology. My point is that as soon as we have trunk ports and subports (regardless of them being a new resource or an extended port resource) they naturally tend to become a representation of the vif and the port-net relation, respectively. By the tendency I mean what attributes actually make sense for them.\n\nBut maybe all this is too abstract to be useful here.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"04461e97052279d96e1f1fb0999dc866fa90b2c5","unresolved":false,"context_lines":[{"line_number":68,"context_line":"The first part of the API extension is the logical topology portion.  First, we"},{"line_number":69,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":70,"context_line":"strictly necessary, but is included for convenience.  It allows Neutron to go"},{"line_number":71,"context_line":"ahead and reject the port creation if subports aren\u0027t supported by the backend."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"This must be specified at port creation time and may not be changed.  This is"},{"line_number":74,"context_line":"mostly for simplicity.  It\u0027s easier to relax this restriction later than the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_eb5c6df2","line":71,"updated":"2015-11-12 21:40:49.000000000","message":"\u003eI didn\u0027t have to choose between one network capable NICs and many network capable NICs while buying one.\n\nThen you clearly have never purchased cheap NICs. ;) I\u0027ve lost plenty of time dealing with MTU issues and NICs that couldn\u0027t handle 802.1q correctly.\n\n@Russell, I\u0027m fine with dropping this. We can always disrupt traffic if necessary during the wiring of the first sub-port for a port in the current reference.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"d432d1cead24657cba1ec3fec42b1a7a9d7de277","unresolved":false,"context_lines":[{"line_number":68,"context_line":"The first part of the API extension is the logical topology portion.  First, we"},{"line_number":69,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":70,"context_line":"strictly necessary, but is included for convenience.  It allows Neutron to go"},{"line_number":71,"context_line":"ahead and reject the port creation if subports aren\u0027t supported by the backend."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"This must be specified at port creation time and may not be changed.  This is"},{"line_number":74,"context_line":"mostly for simplicity.  It\u0027s easier to relax this restriction later than the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_1024af5b","line":71,"updated":"2015-11-12 09:19:35.000000000","message":"From the API user\u0027s perspective this is awkward. If I were a user of openstack, not interested in the difficulty of implementation, I\u0027d want a port, which can be attached to any number of networks without being forced to making a decision at port creation time, how many networks I will want later. I didn\u0027t have to choose between one network capable NICs and many network capable NICs while buying one.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"7509912250b1a126386331909bebc1bf5c83a954","unresolved":false,"context_lines":[{"line_number":68,"context_line":"The first part of the API extension is the logical topology portion.  First, we"},{"line_number":69,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":70,"context_line":"strictly necessary, but is included for convenience.  It allows Neutron to go"},{"line_number":71,"context_line":"ahead and reject the port creation if subports aren\u0027t supported by the backend."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"This must be specified at port creation time and may not be changed.  This is"},{"line_number":74,"context_line":"mostly for simplicity.  It\u0027s easier to relax this restriction later than the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_34c41e5e","line":71,"in_reply_to":"da85f559_1024af5b","updated":"2015-11-12 20:15:53.000000000","message":"Honestly, I\u0027m happy to remove is_parent.  I don\u0027t care much.  The only value it provides is an earlier failure to an end user.  Without it, creating the subport later would just fail instead.  I\u0027ll drop it from the spec and see who gets upset.  :-)","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"d8c04cb329ce636678872cd905f98921a4e2d6d0","unresolved":false,"context_lines":[{"line_number":68,"context_line":"The first part of the API extension is the logical topology portion.  First, we"},{"line_number":69,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":70,"context_line":"strictly necessary, but is included for convenience.  It allows Neutron to go"},{"line_number":71,"context_line":"ahead and reject the port creation if subports aren\u0027t supported by the backend."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"This must be specified at port creation time and may not be changed.  This is"},{"line_number":74,"context_line":"mostly for simplicity.  It\u0027s easier to relax this restriction later than the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_ec7302e6","line":71,"in_reply_to":"da85f559_eb5c6df2","updated":"2015-11-13 14:38:51.000000000","message":"OK, thanks Kevin.  I was curious what you thought here since this was inspired by our discussion.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"d432d1cead24657cba1ec3fec42b1a7a9d7de277","unresolved":false,"context_lines":[{"line_number":71,"context_line":"ahead and reject the port creation if subports aren\u0027t supported by the backend."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"This must be specified at port creation time and may not be changed.  This is"},{"line_number":74,"context_line":"mostly for simplicity.  It\u0027s easier to relax this restriction later than the"},{"line_number":75,"context_line":"other way around."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"Note that all example command lines are for demonstrating the concepts.  The"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_30cd3385","line":74,"updated":"2015-11-12 09:19:35.000000000","message":"I\u0027m wary of \u0027simplicity\u0027 without qualifiers. Because this is simple for neutron agent maintainers and complex for openstack API users.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"7509912250b1a126386331909bebc1bf5c83a954","unresolved":false,"context_lines":[{"line_number":71,"context_line":"ahead and reject the port creation if subports aren\u0027t supported by the backend."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"This must be specified at port creation time and may not be changed.  This is"},{"line_number":74,"context_line":"mostly for simplicity.  It\u0027s easier to relax this restriction later than the"},{"line_number":75,"context_line":"other way around."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"Note that all example command lines are for demonstrating the concepts.  The"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_f43a1698","line":74,"in_reply_to":"da85f559_30cd3385","updated":"2015-11-12 20:15:53.000000000","message":"The simplicity comment is about having to specify it at port create time only.  I\u0027ll just remove the simplicity comment because it doesn\u0027t really matter.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"d432d1cead24657cba1ec3fec42b1a7a9d7de277","unresolved":false,"context_lines":[{"line_number":79,"context_line":""},{"line_number":80,"context_line":"::"},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"    $ neutron port-create --subport:is_parent NETWORK"},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"Note that if a given plugin does not implement support for the subport API"},{"line_number":85,"context_line":"extension, this request will be rejected."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_d04867ce","line":82,"updated":"2015-11-12 09:19:35.000000000","message":"I consider it a good idea _not_ to introduce a new resource for trunk ports, but reusing the port resource.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"d432d1cead24657cba1ec3fec42b1a7a9d7de277","unresolved":false,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":"::"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"    $ neutron port-create --subport:parent_id PARENT-PORT-ID NETWORK"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"If the Neutron backend does not support the subport API extension, this request"},{"line_number":95,"context_line":"will be rejected."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_90665f28","line":92,"updated":"2015-11-12 09:19:35.000000000","message":"Maybe we want to introduce a new resource to minimize the effect of the trunk port feature on already existing code. But I believe introducing a new resource for the subports makes more sense than introducing one for trunk ports. So my question is:  Do we need a resource for subports or can we reuse the port resource for subports?\n\nThe answer to this is deeply dependent of the complexity of the implementation.\n\nI have a hope that a subport resource would not mandate changes in any other openstack components, but neutron. Correct me if this is wrong.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"04461e97052279d96e1f1fb0999dc866fa90b2c5","unresolved":false,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":"::"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"    $ neutron port-create --subport:parent_id PARENT-PORT-ID NETWORK"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"If the Neutron backend does not support the subport API extension, this request"},{"line_number":95,"context_line":"will be rejected."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_0b6211ae","line":92,"updated":"2015-11-12 21:40:49.000000000","message":"Yes, using a regular neutron port for the sub-port is fine. That was never in question. The only thing it affects is how the port is \u0027bound\u0027 so to speak.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"2cb3e7b3d3790c4b671e382032045463c4eea077","unresolved":false,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":"::"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"    $ neutron port-create --subport:parent_id PARENT-PORT-ID NETWORK"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"If the Neutron backend does not support the subport API extension, this request"},{"line_number":95,"context_line":"will be rejected."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_54f18c94","line":92,"in_reply_to":"da85f559_0b6211ae","updated":"2015-11-13 09:00:01.000000000","message":"Because we went back to the design board I wanted to raise this question too as Armando suggested a complete rehaul. Reusing neutron port for a subport is okay for me.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"7509912250b1a126386331909bebc1bf5c83a954","unresolved":false,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":"::"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"    $ neutron port-create --subport:parent_id PARENT-PORT-ID NETWORK"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"If the Neutron backend does not support the subport API extension, this request"},{"line_number":95,"context_line":"will be rejected."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_b4856e08","line":92,"in_reply_to":"da85f559_90665f28","updated":"2015-11-12 20:15:53.000000000","message":"I prefer using the existing port resource.  It\u0027s just another logical port on a logical network.  It has *all* of the same attributes as a port does today.  We\u0027d duplicate almost everything on a port for a new resource.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"2cb3e7b3d3790c4b671e382032045463c4eea077","unresolved":false,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"::"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"    $ neutron port-create --subport:parent_id PARENT-PORT-ID \\"},{"line_number":117,"context_line":"    \u003e --subport:encap_info 101 NETWORK"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"The encapsulation here is a local encapsulation used between the VM and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_de36f6e6","line":116,"updated":"2015-11-13 09:00:01.000000000","message":"In previous rounds we were thinking about reusing the device_owner/device_id fields to express the parent relation. They seem to be a perfect fit. What do you think about something like this? EXT is whatever extension name we come up with, like \u0027trunk\u0027 or \u0027subport\u0027...\n\n $ neutron port-create --device_owner network:EXT --device_id PARENT_PORT_ID --EXT:encap_info 101 NET","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"d8c04cb329ce636678872cd905f98921a4e2d6d0","unresolved":false,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"::"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"    $ neutron port-create --subport:parent_id PARENT-PORT-ID \\"},{"line_number":117,"context_line":"    \u003e --subport:encap_info 101 NETWORK"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"The encapsulation here is a local encapsulation used between the VM and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_2f5b3c30","line":116,"in_reply_to":"da85f559_de36f6e6","updated":"2015-11-13 14:38:51.000000000","message":"interesting idea.  I\u0027m leaning toward the more explicit \"parent_id\" idea still, but am open if there\u0027s interest from others in this approach.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"d432d1cead24657cba1ec3fec42b1a7a9d7de277","unresolved":false,"context_lines":[{"line_number":121,"context_line":"attached to is implemented.  It is only used to identify the source or"},{"line_number":122,"context_line":"destination logical port over a single VIF."},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"Subport details are also expected to be exposed to VMs via the Nova metadata"},{"line_number":125,"context_line":"service."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Example logical model::"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_70141b4c","line":124,"updated":"2015-11-12 09:19:35.000000000","message":"Very good point, but IMHO this is big enough to make it into another spec that follows this work.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"7509912250b1a126386331909bebc1bf5c83a954","unresolved":false,"context_lines":[{"line_number":121,"context_line":"attached to is implemented.  It is only used to identify the source or"},{"line_number":122,"context_line":"destination logical port over a single VIF."},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"Subport details are also expected to be exposed to VMs via the Nova metadata"},{"line_number":125,"context_line":"service."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Example logical model::"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_54a2029c","line":124,"in_reply_to":"da85f559_70141b4c","updated":"2015-11-12 20:15:53.000000000","message":"agree, I didn\u0027t try to define it here.  I\u0027ll try to clarify that a bit.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"d432d1cead24657cba1ec3fec42b1a7a9d7de277","unresolved":false,"context_lines":[{"line_number":190,"context_line":"  port not yet attached to a network, though it\u0027s unclear how valuable that"},{"line_number":191,"context_line":"  actually is."},{"line_number":192,"context_line":""},{"line_number":193,"context_line":"* When the parent port is bound, all the subports are marked as bound."},{"line_number":194,"context_line":"  This is handled by the Neutron plugin implementing subport support."},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"* A normal user can only connect subports to its own parent ports. Admin"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_53a48106","line":193,"updated":"2015-11-12 09:19:35.000000000","message":"I believe changes to port binding are more complicated than this. The checks and decisions made during port binding today must be split into two parts. Stuff like deciding about binding:vif_type, vif_details, vnic_type can be done during binding the trunk port. Checking if a network segment is available can be done only during binding subports.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"7509912250b1a126386331909bebc1bf5c83a954","unresolved":false,"context_lines":[{"line_number":190,"context_line":"  port not yet attached to a network, though it\u0027s unclear how valuable that"},{"line_number":191,"context_line":"  actually is."},{"line_number":192,"context_line":""},{"line_number":193,"context_line":"* When the parent port is bound, all the subports are marked as bound."},{"line_number":194,"context_line":"  This is handled by the Neutron plugin implementing subport support."},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"* A normal user can only connect subports to its own parent ports. Admin"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_54c9a259","line":193,"in_reply_to":"da85f559_53a48106","updated":"2015-11-12 20:15:53.000000000","message":"OK, let me try to rephrase this.  It\u0027s really only the binding:host_id that subports inherit from their parent.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"2cb3e7b3d3790c4b671e382032045463c4eea077","unresolved":false,"context_lines":[{"line_number":190,"context_line":"  port not yet attached to a network, though it\u0027s unclear how valuable that"},{"line_number":191,"context_line":"  actually is."},{"line_number":192,"context_line":""},{"line_number":193,"context_line":"* When the parent port is bound, all the subports are marked as bound."},{"line_number":194,"context_line":"  This is handled by the Neutron plugin implementing subport support."},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"* A normal user can only connect subports to its own parent ports. Admin"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_7e758a30","line":193,"in_reply_to":"da85f559_54c9a259","updated":"2015-11-13 09:00:01.000000000","message":"By inheriting which one we mean?\n\n1) we have a special attribute getter for the binding:host_id which for a subport returns the binding:host_id of the parent port, so the binding:host_id of a subport is reported to be the same as its parent, but without being stored twice\n\n2) or setting binding:host_id to a special value with a special meaning, that the API user should follow the parent reference\n\n3) something else\n\nOption (1) sounds better to me.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"d8c04cb329ce636678872cd905f98921a4e2d6d0","unresolved":false,"context_lines":[{"line_number":190,"context_line":"  port not yet attached to a network, though it\u0027s unclear how valuable that"},{"line_number":191,"context_line":"  actually is."},{"line_number":192,"context_line":""},{"line_number":193,"context_line":"* When the parent port is bound, all the subports are marked as bound."},{"line_number":194,"context_line":"  This is handled by the Neutron plugin implementing subport support."},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"* A normal user can only connect subports to its own parent ports. Admin"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_af5e4c10","line":193,"in_reply_to":"da85f559_7e758a30","updated":"2015-11-13 14:38:51.000000000","message":"Yeah (1) sounds good to me","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"5ff5ec606957655d0096c01b79a23d724d78a114","unresolved":false,"context_lines":[{"line_number":224,"context_line":""},{"line_number":225,"context_line":"I would expect a similar 400 response with a message like \"Port \u003cfoo\u003e must not"},{"line_number":226,"context_line":"be a subport.\"."},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"Alternatives"},{"line_number":229,"context_line":"------------"},{"line_number":230,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_4634bd48","line":227,"updated":"2015-11-12 09:27:50.000000000","message":"Even if we don\u0027t have a new resource for trunk port, I believe we still need a new vif driver (be it in nova, or later in the new os vif lib). The reason is that neutron-ovs-agent uses ovs in a mac learning mode (last action is NORMAL). And if we want to keep that (and not change it to fully openflow mode) then we are forced to create a new ovs bridge per trunk port. And neutron cannot create the per-port bridge without really ugly hacks, because nova may plug the vif really early (right after neutron returned 200 ok on a port update, ignoring port status). So we either make nova wait for neutron to create the bridge, or nova has to create the bridge.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15361,"name":"Peter V. Saveliev","email":"peter@svinota.eu","username":"svinota"},"change_message_id":"c9aac9935b0dc452047da0fab97bba325bfec382","unresolved":false,"context_lines":[{"line_number":224,"context_line":""},{"line_number":225,"context_line":"I would expect a similar 400 response with a message like \"Port \u003cfoo\u003e must not"},{"line_number":226,"context_line":"be a subport.\"."},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"Alternatives"},{"line_number":229,"context_line":"------------"},{"line_number":230,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_e68db1d3","line":227,"in_reply_to":"da85f559_4634bd48","updated":"2015-11-12 09:31:55.000000000","message":"Just to clarify, why it\u0027s important. Having Nova waiting for Neutron in that case implies a serious performance bottleneck in the case of multiple VM start.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"2cb3e7b3d3790c4b671e382032045463c4eea077","unresolved":false,"context_lines":[{"line_number":224,"context_line":""},{"line_number":225,"context_line":"I would expect a similar 400 response with a message like \"Port \u003cfoo\u003e must not"},{"line_number":226,"context_line":"be a subport.\"."},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"Alternatives"},{"line_number":229,"context_line":"------------"},{"line_number":230,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_2beb42b2","line":227,"in_reply_to":"da85f559_b4d48ebd","updated":"2015-11-13 09:00:01.000000000","message":"Got it, let\u0027s keep this topic outside of this spec. On the other hand I\u0027d be welcoming further comments hoping somebody sees a better solution than I see.\n\nI have listed all options I\u0027m aware of in nova bp/trunk-port. The part regarding this question I believe is still relevant. None of those alternatives are optimal, but I perceive the new vif type as the least painful.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"7509912250b1a126386331909bebc1bf5c83a954","unresolved":false,"context_lines":[{"line_number":224,"context_line":""},{"line_number":225,"context_line":"I would expect a similar 400 response with a message like \"Port \u003cfoo\u003e must not"},{"line_number":226,"context_line":"be a subport.\"."},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"Alternatives"},{"line_number":229,"context_line":"------------"},{"line_number":230,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_b4d48ebd","line":227,"in_reply_to":"da85f559_e68db1d3","updated":"2015-11-12 20:15:53.000000000","message":"I don\u0027t want to get too far into any backend implementation details.  From a pure OVS perspective, it\u0027s possible like you say that the existing OVS VIF type should be fine.  In fact, that\u0027s how it work for OVN without any changes.\n\nPerhaps we could use a combination of OpenFlow and the normal action to do what\u0027s needed here without a new VIF type.  In any case, I\u0027d like to tackle those details separately from the core API proposal.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"2cb3e7b3d3790c4b671e382032045463c4eea077","unresolved":false,"context_lines":[{"line_number":318,"context_line":"|Name      |       |         |Value    |Conversion  |                     |"},{"line_number":319,"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\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\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":320,"context_line":"|subport:  |bool   |CR, all  |false    |bool        |Indicate that a port |"},{"line_number":321,"context_line":"|is_parent |       |         |         |            |may have child       |"},{"line_number":322,"context_line":"|          |       |         |         |            |subports.            |"},{"line_number":323,"context_line":"+----------+-------+---------+---------+------------+---------------------+"},{"line_number":324,"context_line":"|subport:  |string |CR, all  |\u0027\u0027       |uuid of     |ID of the parent     |"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_ab45f2b3","line":321,"updated":"2015-11-13 09:00:01.000000000","message":"Let\u0027s delete this as we said before.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"2cb3e7b3d3790c4b671e382032045463c4eea077","unresolved":false,"context_lines":[{"line_number":326,"context_line":"|          |       |         |         |            |connected to.        |"},{"line_number":327,"context_line":"+----------+-------+---------+---------+------------+---------------------+"},{"line_number":328,"context_line":"|subport:  |integer|CR, all  |\u0027\u0027       |uint or     |For encap_type of    |"},{"line_number":329,"context_line":"|encap_info|       |         |         |\u0027\u0027          |vlan, this is the    |"},{"line_number":330,"context_line":"|          |       |         |         |            |VLAN id used for     |"},{"line_number":331,"context_line":"|          |       |         |         |            |packets to and from  |"},{"line_number":332,"context_line":"|          |       |         |         |            |this subport.        |"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_4b7806f9","line":329,"updated":"2015-11-13 09:00:01.000000000","message":"Maybe for the sake of consistent naming we could call this encap_id? Or even segmentation_type/id? For example the provider extension uses the names segmentation_type and segmentation_id.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"d8c04cb329ce636678872cd905f98921a4e2d6d0","unresolved":false,"context_lines":[{"line_number":326,"context_line":"|          |       |         |         |            |connected to.        |"},{"line_number":327,"context_line":"+----------+-------+---------+---------+------------+---------------------+"},{"line_number":328,"context_line":"|subport:  |integer|CR, all  |\u0027\u0027       |uint or     |For encap_type of    |"},{"line_number":329,"context_line":"|encap_info|       |         |         |\u0027\u0027          |vlan, this is the    |"},{"line_number":330,"context_line":"|          |       |         |         |            |VLAN id used for     |"},{"line_number":331,"context_line":"|          |       |         |         |            |packets to and from  |"},{"line_number":332,"context_line":"|          |       |         |         |            |this subport.        |"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_efd9b484","line":329,"in_reply_to":"da85f559_4b7806f9","updated":"2015-11-13 14:38:51.000000000","message":"Good point re: consistency with the provider network naming scheme.  I think switching to match makes sense here.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"2cb3e7b3d3790c4b671e382032045463c4eea077","unresolved":false,"context_lines":[{"line_number":340,"context_line":""},{"line_number":341,"context_line":"(*) As the blueprint is focused on VLAN tagging, only \u0027vlan\u0027 encap_type"},{"line_number":342,"context_line":"is defined here. Any extension is a subject of further separate blueprints."},{"line_number":343,"context_line":""},{"line_number":344,"context_line":"Security Impact"},{"line_number":345,"context_line":"---------------"},{"line_number":346,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_abee52b2","line":343,"updated":"2015-11-13 09:00:01.000000000","message":"A missing note: the delete of a parent port cascades to deleting all of its subports.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"d8c04cb329ce636678872cd905f98921a4e2d6d0","unresolved":false,"context_lines":[{"line_number":340,"context_line":""},{"line_number":341,"context_line":"(*) As the blueprint is focused on VLAN tagging, only \u0027vlan\u0027 encap_type"},{"line_number":342,"context_line":"is defined here. Any extension is a subject of further separate blueprints."},{"line_number":343,"context_line":""},{"line_number":344,"context_line":"Security Impact"},{"line_number":345,"context_line":"---------------"},{"line_number":346,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_4fcfa0b3","line":343,"in_reply_to":"da85f559_abee52b2","updated":"2015-11-13 14:38:51.000000000","message":"Very good point.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"d432d1cead24657cba1ec3fec42b1a7a9d7de277","unresolved":false,"context_lines":[{"line_number":384,"context_line":""},{"line_number":385,"context_line":"Developer Impact"},{"line_number":386,"context_line":"----------------"},{"line_number":387,"context_line":""},{"line_number":388,"context_line":"* Extented attributes on the Neutron port are to be used."},{"line_number":389,"context_line":"* Requires modifications to Neutron plugins to support this model"},{"line_number":390,"context_line":"* Requires development of new tests."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_f37b35bc","line":387,"updated":"2015-11-12 09:19:35.000000000","message":"One missing piece about MAC addresses. (Maybe not the right section.)\n\nThe later patch sets of bp/vlan-aware-vms were asking for the subports\u0027 mac addresses to be arbitrary, but I don\u0027t think that\u0027s possible. I believe (at least at the beginning) subports must use their trunk port\u0027s mac address, because there\u0027s no generic way to tell the guest OS, or guest application what mac addresses to use for the subports. Telling it can be perceived as a violation of the independence of the host layer and virtualized layer.\n\nIn the long term we may expose such details over metadata service, but I think even then we shouldn\u0027t make the use of the metadata service necessary.\n\nWill we have mac collisions then? Hopefully not, because frames with the same mac address from different networks may appear on one trunk vNIC, but always encapsulated in different tags and by default they will not be bridged to other networks.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"2cb3e7b3d3790c4b671e382032045463c4eea077","unresolved":false,"context_lines":[{"line_number":384,"context_line":""},{"line_number":385,"context_line":"Developer Impact"},{"line_number":386,"context_line":"----------------"},{"line_number":387,"context_line":""},{"line_number":388,"context_line":"* Extented attributes on the Neutron port are to be used."},{"line_number":389,"context_line":"* Requires modifications to Neutron plugins to support this model"},{"line_number":390,"context_line":"* Requires development of new tests."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_ab4ad2aa","line":387,"in_reply_to":"da85f559_7764e8e4","updated":"2015-11-13 09:00:01.000000000","message":"Makes sense.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"7509912250b1a126386331909bebc1bf5c83a954","unresolved":false,"context_lines":[{"line_number":384,"context_line":""},{"line_number":385,"context_line":"Developer Impact"},{"line_number":386,"context_line":"----------------"},{"line_number":387,"context_line":""},{"line_number":388,"context_line":"* Extented attributes on the Neutron port are to be used."},{"line_number":389,"context_line":"* Requires modifications to Neutron plugins to support this model"},{"line_number":390,"context_line":"* Requires development of new tests."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_7764e8e4","line":387,"in_reply_to":"da85f559_f37b35bc","updated":"2015-11-12 20:15:53.000000000","message":"I think I\u0027d prefer is to retain default port behavior (an arbitrary, randomly assigned MAC address).  If the VM requires subports using the parent port\u0027s MAC address, the subports can be created that way.  The port create API allows specifying the MAC address.  So, I think we\u0027re covered with how the API works today.  I\u0027ll add a note about this.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"d432d1cead24657cba1ec3fec42b1a7a9d7de277","unresolved":false,"context_lines":[{"line_number":400,"context_line":""},{"line_number":401,"context_line":"Kevin Benton"},{"line_number":402,"context_line":"Peter V. Saveliev"},{"line_number":403,"context_line":"Russell Bryant"},{"line_number":404,"context_line":""},{"line_number":405,"context_line":"Work Items"},{"line_number":406,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_134fd937","line":403,"updated":"2015-11-12 09:19:35.000000000","message":"Feel free to add me (Bence Romsics) here.","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"7509912250b1a126386331909bebc1bf5c83a954","unresolved":false,"context_lines":[{"line_number":400,"context_line":""},{"line_number":401,"context_line":"Kevin Benton"},{"line_number":402,"context_line":"Peter V. Saveliev"},{"line_number":403,"context_line":"Russell Bryant"},{"line_number":404,"context_line":""},{"line_number":405,"context_line":"Work Items"},{"line_number":406,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da85f559_1480fa8a","line":403,"in_reply_to":"da85f559_134fd937","updated":"2015-11-12 20:15:53.000000000","message":"Will do, thanks!","commit_id":"c154eec3e170f41a3bbe94875c9605293b6bd0b5"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"ab58c6801cb08aac8a3d8a61765852fbf416fc59","unresolved":false,"context_lines":[{"line_number":158,"context_line":"Constraints"},{"line_number":159,"context_line":"-----------"},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"* A port may have 0 or 1 parents.  The parent MUST not also have a parent."},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"* Every subport of a given parent should have unique VID among its"},{"line_number":164,"context_line":"  siblings.  Otherwise, it\u0027s not possible to properly differentiate"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_c65ac02a","line":161,"updated":"2015-11-12 21:59:24.000000000","message":"This restriction doesn\u0027t seem necessary to me. In the VLAN case we can bail when someone tries to create a subport with a parent subport and say we don\u0027t support QinQ in this fashion, but I don\u0027t actually see a reason why it isn\u0027t feasible when it comes to other encap types that can easily be nested. In other words, let\u0027s not restrict this as a requirement of the API, but allow the implementation to decide.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"a25627ca1ae8d94379d3a57cd62033043a306698","unresolved":false,"context_lines":[{"line_number":158,"context_line":"Constraints"},{"line_number":159,"context_line":"-----------"},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"* A port may have 0 or 1 parents.  The parent MUST not also have a parent."},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"* Every subport of a given parent should have unique VID among its"},{"line_number":164,"context_line":"  siblings.  Otherwise, it\u0027s not possible to properly differentiate"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_aa1cfa6a","line":161,"in_reply_to":"da85f559_c65ac02a","updated":"2015-11-13 15:36:42.000000000","message":"OK, that sounds good.  I\u0027ll update this to clarify that there may be implementation specific restrictions on nesting.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"b71f3d065edcad92d2b97c51c5d38d9ce926614f","unresolved":false,"context_lines":[{"line_number":174,"context_line":"  port not yet attached to a network, though it\u0027s unclear how valuable that"},{"line_number":175,"context_line":"  actually is."},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"* A port with a parent inherits its binding:host_id from its parent."},{"line_number":178,"context_line":""},{"line_number":179,"context_line":"* A normal user can only connect subports to its own parent ports. Admin"},{"line_number":180,"context_line":"  user can connect subports to parent ports with different owners."}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_6b1aba70","line":177,"updated":"2015-11-16 13:14:20.000000000","message":"Still one more note on this, just to bring out the foreseeable problems. Even if the subports inherit binding:host_id from their parent (regardless of the different ways mentioned in comments before) I don\u0027t think we can spare a cascaded update. An update to the parent\u0027s binding:host_id must call update() on all of its subports.\n\nAssume an update_port() call is processed in 0.1 sec and a trunk port has 1000 subports and we have a parent port update performance problem.\n\nI don\u0027t see a way to efficiently (that is faster than a for loop) batch  update_port(). My previous comment about the possibility of turning the subport into a new resource (with efficient batch operations mandated), actually tried to half-heartedly address this problem.\n\nA simpler solution could be to accept that an udate to a parent port may be a long running operation (we have no change in updates to plain old ports!) and maybe express the status of the long running update operation by introducing an \u0027update_status\u0027 attribute?","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"6a44284182659f6ab86b010a61fcf44dc3798d52","unresolved":false,"context_lines":[{"line_number":174,"context_line":"  port not yet attached to a network, though it\u0027s unclear how valuable that"},{"line_number":175,"context_line":"  actually is."},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"* A port with a parent inherits its binding:host_id from its parent."},{"line_number":178,"context_line":""},{"line_number":179,"context_line":"* A normal user can only connect subports to its own parent ports. Admin"},{"line_number":180,"context_line":"  user can connect subports to parent ports with different owners."}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_73a57602","line":177,"in_reply_to":"ba8a016a_5dddf56e","updated":"2015-11-23 17:55:03.000000000","message":"On second thought, maybe inheriting is a bad idea anyway.  Maybe it should just remain blank in the subport case.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"fc73a86d99c568425722eb82e6ebfbfd25cc70fd","unresolved":false,"context_lines":[{"line_number":174,"context_line":"  port not yet attached to a network, though it\u0027s unclear how valuable that"},{"line_number":175,"context_line":"  actually is."},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"* A port with a parent inherits its binding:host_id from its parent."},{"line_number":178,"context_line":""},{"line_number":179,"context_line":"* A normal user can only connect subports to its own parent ports. Admin"},{"line_number":180,"context_line":"  user can connect subports to parent ports with different owners."}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_d3c0297f","line":177,"in_reply_to":"ba8a016a_6b1aba70","updated":"2015-11-20 20:15:32.000000000","message":"I think this is probably an implementation detail not worth covering in detail in the spec.  It seems like something that can either be done by a single db transaction, or like we discussed in a previous comment thread, we could just not store it for child ports at all.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"9c1c4e4f80eb2e5c40b8842936fab71062493364","unresolved":false,"context_lines":[{"line_number":174,"context_line":"  port not yet attached to a network, though it\u0027s unclear how valuable that"},{"line_number":175,"context_line":"  actually is."},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"* A port with a parent inherits its binding:host_id from its parent."},{"line_number":178,"context_line":""},{"line_number":179,"context_line":"* A normal user can only connect subports to its own parent ports. Admin"},{"line_number":180,"context_line":"  user can connect subports to parent ports with different owners."}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_5dddf56e","line":177,"in_reply_to":"ba8a016a_d3c0297f","updated":"2015-11-23 13:05:29.000000000","message":"Even if don\u0027t want to include these comments in the spec itself, let me mention that the \"single db transaction\" approach probably won\u0027t work. I believe we can\u0027t start batching certain sub-operations of a port update in ML2 (like the DB update), because we can\u0027t tell what else is being done in the mechanism driver\u0027s update_port(). And theoretically anything can be done there.\n\nIMO if we want to batch port updates efficiently they must be batched from the mechanism driver. One option is to add a a batch_port_update() / update_portS() method to the mechanism driver interface. But if we\u0027d like to go that way, that\u0027s probably better kept in the spec.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"ab58c6801cb08aac8a3d8a61765852fbf416fc59","unresolved":false,"context_lines":[{"line_number":189,"context_line":""},{"line_number":190,"context_line":"Ideally, Nova should reject a request when given a port ID where the port"},{"line_number":191,"context_line":"details include subport:parent_id, meaning that the port is a subport.  Nova"},{"line_number":192,"context_line":"should never attempt to attach a subport to a VM."},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"If Nova ignores subport:parent_id and attempts to use a subport, it will still"},{"line_number":195,"context_line":"fail.  Neutron will reject the port update request to set binding:host_id, as"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_6640b436","line":192,"updated":"2015-11-12 21:59:24.000000000","message":"I disagree with this for two reasons. First, it\u0027s none of Nova\u0027s business. :)\n\nSecond, just like normal ports can be rebound, I think it should be fine to allow a port to be taken out of sub-port mode and bound like a normal port when it\u0027s binding details change (as would happen if nova tried to use it).","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"6a44284182659f6ab86b010a61fcf44dc3798d52","unresolved":false,"context_lines":[{"line_number":189,"context_line":""},{"line_number":190,"context_line":"Ideally, Nova should reject a request when given a port ID where the port"},{"line_number":191,"context_line":"details include subport:parent_id, meaning that the port is a subport.  Nova"},{"line_number":192,"context_line":"should never attempt to attach a subport to a VM."},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"If Nova ignores subport:parent_id and attempts to use a subport, it will still"},{"line_number":195,"context_line":"fail.  Neutron will reject the port update request to set binding:host_id, as"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_33de0e6e","line":192,"in_reply_to":"ba8a016a_613f20d7","updated":"2015-11-23 17:55:03.000000000","message":"I actually think the change discussed here is much less invasive, but in any case all of this is gone in the next revision for now.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"a25627ca1ae8d94379d3a57cd62033043a306698","unresolved":false,"context_lines":[{"line_number":189,"context_line":""},{"line_number":190,"context_line":"Ideally, Nova should reject a request when given a port ID where the port"},{"line_number":191,"context_line":"details include subport:parent_id, meaning that the port is a subport.  Nova"},{"line_number":192,"context_line":"should never attempt to attach a subport to a VM."},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"If Nova ignores subport:parent_id and attempts to use a subport, it will still"},{"line_number":195,"context_line":"fail.  Neutron will reject the port update request to set binding:host_id, as"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_6adcd218","line":192,"in_reply_to":"da85f559_6640b436","updated":"2015-11-13 15:36:42.000000000","message":"The way I thought about this, a subport is by definition not something Nova could use.  I want to make sure I understand your suggestion, so let me see if I can restate it as something that would go into the \"proposed change\" section to describe subport behavior.\n\n    If a subport\u0027s binding details are updated, for example if\n    Nova updates a subport with a binding:host_id, the subport\n    is automatically taken out of subport mode and the \n    subport:parent_id field is set to empty.\n\nI think that makes sense and indeed makes this way simpler.  It means most of this \"nova changes\" section would be dropped as it turns into no impact at all (except the possible new VIF type).","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"b6a00f10e9f711d8e636b2ccd1a9b8b2d4bc715f","unresolved":false,"context_lines":[{"line_number":189,"context_line":""},{"line_number":190,"context_line":"Ideally, Nova should reject a request when given a port ID where the port"},{"line_number":191,"context_line":"details include subport:parent_id, meaning that the port is a subport.  Nova"},{"line_number":192,"context_line":"should never attempt to attach a subport to a VM."},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"If Nova ignores subport:parent_id and attempts to use a subport, it will still"},{"line_number":195,"context_line":"fail.  Neutron will reject the port update request to set binding:host_id, as"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_f533bef4","line":192,"in_reply_to":"da85f559_6adcd218","updated":"2015-11-13 17:43:53.000000000","message":"I would personally prefer these objects to be immutable, repurposing ports can lead to quite a few surprises down the road if we do not take into account all the possible conditions and states a port can be in. It\u0027s much easier to write correct code if they are considered disposable.\n\nThat said, I think that Nova should not silently fail if one attempts to boot a vm on a sub-port, which IMO makes the whole - I don\u0027t want Nova to change - argument sort of moot.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"b71f3d065edcad92d2b97c51c5d38d9ce926614f","unresolved":false,"context_lines":[{"line_number":189,"context_line":""},{"line_number":190,"context_line":"Ideally, Nova should reject a request when given a port ID where the port"},{"line_number":191,"context_line":"details include subport:parent_id, meaning that the port is a subport.  Nova"},{"line_number":192,"context_line":"should never attempt to attach a subport to a VM."},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"If Nova ignores subport:parent_id and attempts to use a subport, it will still"},{"line_number":195,"context_line":"fail.  Neutron will reject the port update request to set binding:host_id, as"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_796a9b1c","line":192,"in_reply_to":"da85f559_b88c4636","updated":"2015-11-16 13:14:20.000000000","message":"A previous suggestion could help here somewhat. If we encode the parent relationship in the device_owner/id fields, then it naturally follows that nova can\u0027t boot a vm on a subport. Because the port either has (owner\u003dnova/compute, id\u003dVM-UUID), or it has (owner\u003dnetwork/trunk, id\u003dPARENT-UUID).\n\nThe other question discussed. Do we allow conversions between a port and a subport (a subtype of port)? I believe the type-narrowing conversion (from port to subport) must be allowed, but the benefit of the type-widening conversion is questionable. There\u0027s no identity to be preserved while converting a subport into a port (other than the port uuid). On the other hand the implementation would be simpler prohibiting the type-widening conversion.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"aef1c00cffeda1b288f2bbdca6e2b9e6fc3f3d33","unresolved":false,"context_lines":[{"line_number":189,"context_line":""},{"line_number":190,"context_line":"Ideally, Nova should reject a request when given a port ID where the port"},{"line_number":191,"context_line":"details include subport:parent_id, meaning that the port is a subport.  Nova"},{"line_number":192,"context_line":"should never attempt to attach a subport to a VM."},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"If Nova ignores subport:parent_id and attempts to use a subport, it will still"},{"line_number":195,"context_line":"fail.  Neutron will reject the port update request to set binding:host_id, as"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_613f20d7","line":192,"in_reply_to":"da85f559_e44a2d55","updated":"2015-11-21 01:35:10.000000000","message":"Ok, understood, although that\u0027s different from your initial position of \u0027the nova-side code that handles networking is super-brittle I don\u0027t want to touch it\u0027. Changes implied above are just as impactful if not more.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"591d97b65ab42a29ddc1f65b32453343b46ac6b3","unresolved":false,"context_lines":[{"line_number":189,"context_line":""},{"line_number":190,"context_line":"Ideally, Nova should reject a request when given a port ID where the port"},{"line_number":191,"context_line":"details include subport:parent_id, meaning that the port is a subport.  Nova"},{"line_number":192,"context_line":"should never attempt to attach a subport to a VM."},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"If Nova ignores subport:parent_id and attempts to use a subport, it will still"},{"line_number":195,"context_line":"fail.  Neutron will reject the port update request to set binding:host_id, as"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_e44a2d55","line":192,"in_reply_to":"da85f559_f533bef4","updated":"2015-11-13 18:13:40.000000000","message":"Just to be clear, I\u0027m not saying I don\u0027t want nova to change. I\u0027m saying I don\u0027t want to introduce another variable (i.e. type of port) to our process when I don\u0027t think it\u0027s absolutely necessary.\n\nI\u0027m more than fine making nova wary of being provided a sub-port and rejecting the request so that the user gets the proper behavior. if, as Kevin says, rejecting a sub-port is not the right thing to do, then sure. But if it is, I\u0027m more than supportive of making that change.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"adb7d142b757ab1f9934c50f4617c39837480e10","unresolved":false,"context_lines":[{"line_number":189,"context_line":""},{"line_number":190,"context_line":"Ideally, Nova should reject a request when given a port ID where the port"},{"line_number":191,"context_line":"details include subport:parent_id, meaning that the port is a subport.  Nova"},{"line_number":192,"context_line":"should never attempt to attach a subport to a VM."},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"If Nova ignores subport:parent_id and attempts to use a subport, it will still"},{"line_number":195,"context_line":"fail.  Neutron will reject the port update request to set binding:host_id, as"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_b88c4636","line":192,"in_reply_to":"da85f559_f533bef4","updated":"2015-11-13 20:06:09.000000000","message":"Making them immutable makes them a special case though, which is what I was hoping we can avoid. Other than the fact that the port is wired up by sending tagged traffic down another VIF, there is nothing special about these ports (i.e. they still have IP allocations/mac address/security groups/etc). That\u0027s what I was trying to illustrate below by pointing out that these can just be viewed as a particular case of the port binding process.\n\nWe already handle the case where a port that was bound to a particular host is bound to a different host or VIF type, so these shouldn\u0027t be any different. Even though we will have a new API to set specific VLAN tags, that information will just end up informing a normal port binding process.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"99831e7abdeec979f258eaea51880e5c9ff91e17","unresolved":false,"context_lines":[{"line_number":209,"context_line":"I would expect a similar 400 response with a message like \"Port \u003cfoo\u003e must not"},{"line_number":210,"context_line":"be a subport.\"."},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"The existing OVS VIF type is sufficient to support this model from an OVS"},{"line_number":213,"context_line":"perspective.  For example, OVN already supports this subport model with the"},{"line_number":214,"context_line":"existing OVS VIF type.  However, it\u0027s possible that certain Neutron backends"},{"line_number":215,"context_line":"that use OVS could require a new VIF type to make subports work with how they"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_7efb4a48","line":212,"updated":"2015-11-13 09:53:10.000000000","message":"Maybe I\u0027m just slow, but can you please explain to me why the existing ovs vif type is sufficient?","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"6a44284182659f6ab86b010a61fcf44dc3798d52","unresolved":false,"context_lines":[{"line_number":209,"context_line":"I would expect a similar 400 response with a message like \"Port \u003cfoo\u003e must not"},{"line_number":210,"context_line":"be a subport.\"."},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"The existing OVS VIF type is sufficient to support this model from an OVS"},{"line_number":213,"context_line":"perspective.  For example, OVN already supports this subport model with the"},{"line_number":214,"context_line":"existing OVS VIF type.  However, it\u0027s possible that certain Neutron backends"},{"line_number":215,"context_line":"that use OVS could require a new VIF type to make subports work with how they"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_13baea0a","line":212,"in_reply_to":"ba8a016a_2fc7a213","updated":"2015-11-23 17:55:03.000000000","message":"Yes, something like that.  I haven\u0027t looked into the detailed way to define it yet.\n\nI\u0027d also have to look at how vif_details is (loosely) defined today, but I suspect the interpretation is vif type specific.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"9c1c4e4f80eb2e5c40b8842936fab71062493364","unresolved":false,"context_lines":[{"line_number":209,"context_line":"I would expect a similar 400 response with a message like \"Port \u003cfoo\u003e must not"},{"line_number":210,"context_line":"be a subport.\"."},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"The existing OVS VIF type is sufficient to support this model from an OVS"},{"line_number":213,"context_line":"perspective.  For example, OVN already supports this subport model with the"},{"line_number":214,"context_line":"existing OVS VIF type.  However, it\u0027s possible that certain Neutron backends"},{"line_number":215,"context_line":"that use OVS could require a new VIF type to make subports work with how they"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_2fc7a213","line":212,"in_reply_to":"ba8a016a_931621f0","updated":"2015-11-23 13:05:29.000000000","message":"What do you think about this?\n\n vif_type \u003d ovs\n vif_details \u003d {\"bridge_name\": \"FOO\"}\n\nOut of curiosity, without any consequence here: Is vif_details interpreted only in the a context of one vif driver, or is it generic for all drivers?","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"fc73a86d99c568425722eb82e6ebfbfd25cc70fd","unresolved":false,"context_lines":[{"line_number":209,"context_line":"I would expect a similar 400 response with a message like \"Port \u003cfoo\u003e must not"},{"line_number":210,"context_line":"be a subport.\"."},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"The existing OVS VIF type is sufficient to support this model from an OVS"},{"line_number":213,"context_line":"perspective.  For example, OVN already supports this subport model with the"},{"line_number":214,"context_line":"existing OVS VIF type.  However, it\u0027s possible that certain Neutron backends"},{"line_number":215,"context_line":"that use OVS could require a new VIF type to make subports work with how they"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_931621f0","line":212,"in_reply_to":"ba8a016a_ed7322b3","updated":"2015-11-20 20:15:32.000000000","message":"A trunk bridge seems fine.  It\u0027s the least invasive way to address this.\n\nWhat\u0027s not clear is the best way to enable this on the Nova side.  Maybe we should just add custom bridge name support to the existing OVS VIF type.  The Nova code basically has that as a TODO anyway.  That would make more sense to me than a new VIF type, I think.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"b71f3d065edcad92d2b97c51c5d38d9ce926614f","unresolved":false,"context_lines":[{"line_number":209,"context_line":"I would expect a similar 400 response with a message like \"Port \u003cfoo\u003e must not"},{"line_number":210,"context_line":"be a subport.\"."},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"The existing OVS VIF type is sufficient to support this model from an OVS"},{"line_number":213,"context_line":"perspective.  For example, OVN already supports this subport model with the"},{"line_number":214,"context_line":"existing OVS VIF type.  However, it\u0027s possible that certain Neutron backends"},{"line_number":215,"context_line":"that use OVS could require a new VIF type to make subports work with how they"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_ed7322b3","line":212,"in_reply_to":"da85f559_4358af56","updated":"2015-11-16 13:14:20.000000000","message":"We hope to solve (or hack around for the lack of a better way) this problem by creating a bridge per parent port (ie. trunk port). Then wire that bridge to br-int and plug the tap into the trunk bridge. As written here:\n\nhttps://wiki.openstack.org/wiki/Neutron/TrunkPort#openvswitch_vlan_model\n\n(Other stuff on that wiki page still reflects the previous state of the spec, please ignore it.)\n\nLet me know if you see a better way, I\u0027d be very happy to avoid creating trunk bridges.\n\nAlso this is the point where I think a vif driver is needed to create the per trunk port bridge and to do the wiring.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"624b40876dd20fb20f0f6b2ab1e433394313af60","unresolved":false,"context_lines":[{"line_number":209,"context_line":"I would expect a similar 400 response with a message like \"Port \u003cfoo\u003e must not"},{"line_number":210,"context_line":"be a subport.\"."},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"The existing OVS VIF type is sufficient to support this model from an OVS"},{"line_number":213,"context_line":"perspective.  For example, OVN already supports this subport model with the"},{"line_number":214,"context_line":"existing OVS VIF type.  However, it\u0027s possible that certain Neutron backends"},{"line_number":215,"context_line":"that use OVS could require a new VIF type to make subports work with how they"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_4358af56","line":212,"in_reply_to":"da85f559_5b2522ac","updated":"2015-11-15 21:15:13.000000000","message":"OK, after being stubborn and having to prove it to myself, I agree that doing this with the current ovs agent is pretty invasive.  At first I was thinking we could do it combination with still using the NORMAL action, but I think it requires dropping NORMAL completely, which would be quite a big change from how things work now.\n\nIf anyone is curious, here\u0027s how we\u0027d handle packets from the VM to the hypervisor in the current setup, but then we\u0027re stuck and have to drop NORMAL to handle packets sent back into the VM.\n\n------\n\nI have a devstack setup where I booted 2 VMs.  1 VM has a NIC on the network \"private\".  The second VM has a NIC on the network \"private2\".  The ovs agent uses local VLANs to isolate ports on different networks.  The VLAN ID set using \"tag\" on the OVS port.  So, for my 2 VMs, I have two tap interfaces on br-int:\n\n    $ sudo ovs-vsctl show \n    cdb6e14b-1781-4e04-8f4e-1c25585b1fce\n        Bridge br-int\n            fail_mode: secure\n            Port \"tap7068c368-e4\"\n                tag: 2\n                Interface \"tap7068c368-e4\"\n                    type: internal\n    ...\n            Port \"tapa41ffc84-45\"\n                tag: 1\n                Interface \"tapa41ffc84-45\"\n                    type: internal\n    ...\n\nSo, we have one VM using tag 1, and the other tag 2, indicating the two different networks these ports are on.  Now, let\u0027s look at the OpenFlow flows:\n\n    table\u003d0, priority\u003d10,icmp6,in_port\u003d7,icmp_type\u003d136 actions\u003dresubmit(,24)\n    table\u003d0, priority\u003d10,icmp6,in_port\u003d8,icmp_type\u003d136 actions\u003dresubmit(,24)\n    table\u003d0, priority\u003d10,arp,in_port\u003d7 actions\u003dresubmit(,24)\n    table\u003d0, priority\u003d10,arp,in_port\u003d8 actions\u003dresubmit(,24)\n    table\u003d0, priority\u003d0 actions\u003dNORMAL\n    table\u003d23, priority\u003d0 actions\u003ddrop\n    table\u003d24, priority\u003d2,icmp6,in_port\u003d7,icmp_type\u003d136,nd_target\u003dfd86:2abc:a18a:0:f816:3eff:feec:b528 actions\u003dNORMAL\n    table\u003d24, priority\u003d2,icmp6,in_port\u003d7,icmp_type\u003d136,nd_target\u003dfe80::f816:3eff:feec:b528 actions\u003dNORMAL\n    table\u003d24, priority\u003d2,icmp6,in_port\u003d8,icmp_type\u003d136,nd_target\u003dfe80::f816:3eff:fe87:f8b4 actions\u003dNORMAL\n    table\u003d24, priority\u003d2,arp,in_port\u003d7,arp_spa\u003d10.0.0.3 actions\u003dNORMAL\n    table\u003d24, priority\u003d2,arp,in_port\u003d8,arp_spa\u003d10.0.1.3 actions\u003dNORMAL\n    table\u003d24, priority\u003d0 actions\u003ddrop\n\nThe first step is that we need to move everything that is in table 0 to table 1 unchanged.  Then we have:\n\n    table\u003d0, priority\u003d0 actions\u003dresubmit(,1)\n    table\u003d1, priority\u003d10,icmp6,in_port\u003d7,icmp_type\u003d136 actions\u003dresubmit(,24)\n    table\u003d1, priority\u003d10,icmp6,in_port\u003d8,icmp_type\u003d136 actions\u003dresubmit(,24)\n    table\u003d1, priority\u003d10,arp,in_port\u003d7 actions\u003dresubmit(,24)\n    table\u003d1, priority\u003d10,arp,in_port\u003d8 actions\u003dresubmit(,24)\n    table\u003d1, priority\u003d0 actions\u003dNORMAL\n    table\u003d23, priority\u003d0 actions\u003ddrop\n    table\u003d24, priority\u003d2,icmp6,in_port\u003d7,icmp_type\u003d136,nd_target\u003dfd86:2abc:a18a:0:f816:3eff:feec:b528 actions\u003dNORMAL\n    table\u003d24, priority\u003d2,icmp6,in_port\u003d7,icmp_type\u003d136,nd_target\u003dfe80::f816:3eff:feec:b528 actions\u003dNORMAL\n    table\u003d24, priority\u003d2,icmp6,in_port\u003d8,icmp_type\u003d136,nd_target\u003dfe80::f816:3eff:fe87:f8b4 actions\u003dNORMAL\n    table\u003d24, priority\u003d2,arp,in_port\u003d7,arp_spa\u003d10.0.0.3 actions\u003dNORMAL\n    table\u003d24, priority\u003d2,arp,in_port\u003d8,arp_spa\u003d10.0.1.3 actions\u003dNORMAL\n    table\u003d24, priority\u003d0 actions\u003ddrop\n\nNext, we need to start creating ovs ports *without* setting tag.  Instead, we need to apply the VLAN ID using a flow.  For reference, Port \"tapa41ffc84-45\" is OpenFlow port 2 and Port\" tap7068c368-e4\" is OpenFlow port 5.  Using our same setup, if \"tag\" were removed from our two OVS ports, the flows would become:\n\n    table\u003d0, priority\u003d100,in_port\u003d2 actions\u003dpush_vlan:0x8100,set_field:1-\u003evlan_vid,resubmit(,1)\n    table\u003d0, priority\u003d100,in_port\u003d5 actions\u003dpush_vlan:0x8100,set_field:2-\u003evlan_vid,resubmit(,1)\n    table\u003d0, priority\u003d0 actions\u003dresubmit(,1)\n    table\u003d1, priority\u003d10,icmp6,in_port\u003d7,icmp_type\u003d136 actions\u003dresubmit(,24)\n    table\u003d1, priority\u003d10,icmp6,in_port\u003d8,icmp_type\u003d136 actions\u003dresubmit(,24)\n    table\u003d1, priority\u003d10,arp,in_port\u003d7 actions\u003dresubmit(,24)\n    table\u003d1, priority\u003d10,arp,in_port\u003d8 actions\u003dresubmit(,24)\n    table\u003d1, priority\u003d0 actions\u003dNORMAL\n    table\u003d23, priority\u003d0 actions\u003ddrop\n    table\u003d24, priority\u003d2,icmp6,in_port\u003d7,icmp_type\u003d136,nd_target\u003dfd86:2abc:a18a:0:f816:3eff:feec:b528 actions\u003dNORMAL\n    table\u003d24, priority\u003d2,icmp6,in_port\u003d7,icmp_type\u003d136,nd_target\u003dfe80::f816:3eff:feec:b528 actions\u003dNORMAL\n    table\u003d24, priority\u003d2,icmp6,in_port\u003d8,icmp_type\u003d136,nd_target\u003dfe80::f816:3eff:fe87:f8b4 actions\u003dNORMAL\n    table\u003d24, priority\u003d2,arp,in_port\u003d7,arp_spa\u003d10.0.0.3 actions\u003dNORMAL\n    table\u003d24, priority\u003d2,arp,in_port\u003d8,arp_spa\u003d10.0.1.3 actions\u003dNORMAL\n    table\u003d24, priority\u003d0 actions\u003ddrop\n\nFinally, imagine that we added two subports to \"tapa41ffc84-45\".  The first subport has --subport:encap_info 101 and the second has --subport:encap_info 102.  Both of these ports are attached to indepedent networks, so we have a result of 4 ports (2 VIFs, and 2 subports) all on different Neutron networks.  The flows would be:\n\n    table\u003d0, priority\u003d150,in_port\u003d2,dl_vlan\u003d101 actions\u003dset_field:3-\u003evlan_vid,resubmit(,1)\n    table\u003d0, priority\u003d150,in_port\u003d2,dl_vlan\u003d102 actions\u003dset_field:4-\u003evlan_vid,resubmit(,1)\n    table\u003d0, priority\u003d100,in_port\u003d2 actions\u003dpush_vlan:0x8100,set_field:1-\u003evlan_vid,resubmit(,1)\n    table\u003d0, priority\u003d100,in_port\u003d5 actions\u003dpush_vlan:0x8100,set_field:2-\u003evlan_vid,resubmit(,1)\n    table\u003d0, priority\u003d0 actions\u003dresubmit(,1)\n    table\u003d1, priority\u003d10,icmp6,in_port\u003d7,icmp_type\u003d136 actions\u003dresubmit(,24)\n    table\u003d1, priority\u003d10,icmp6,in_port\u003d8,icmp_type\u003d136 actions\u003dresubmit(,24)\n    table\u003d1, priority\u003d10,arp,in_port\u003d7 actions\u003dresubmit(,24)\n    table\u003d1, priority\u003d10,arp,in_port\u003d8 actions\u003dresubmit(,24)\n    table\u003d1, priority\u003d0 actions\u003dNORMAL\n    table\u003d23, priority\u003d0 actions\u003ddrop\n    table\u003d24, priority\u003d2,icmp6,in_port\u003d7,icmp_type\u003d136,nd_target\u003dfd86:2abc:a18a:0:f816:3eff:feec:b528 actions\u003dNORMAL\n    table\u003d24, priority\u003d2,icmp6,in_port\u003d7,icmp_type\u003d136,nd_target\u003dfe80::f816:3eff:feec:b528 actions\u003dNORMAL\n    table\u003d24, priority\u003d2,icmp6,in_port\u003d8,icmp_type\u003d136,nd_target\u003dfe80::f816:3eff:fe87:f8b4 actions\u003dNORMAL\n    table\u003d24, priority\u003d2,arp,in_port\u003d7,arp_spa\u003d10.0.0.3 actions\u003dNORMAL\n    table\u003d24, priority\u003d2,arp,in_port\u003d8,arp_spa\u003d10.0.1.3 actions\u003dNORMAL\n    table\u003d24, priority\u003d0 actions\u003ddrop","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"a25627ca1ae8d94379d3a57cd62033043a306698","unresolved":false,"context_lines":[{"line_number":209,"context_line":"I would expect a similar 400 response with a message like \"Port \u003cfoo\u003e must not"},{"line_number":210,"context_line":"be a subport.\"."},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"The existing OVS VIF type is sufficient to support this model from an OVS"},{"line_number":213,"context_line":"perspective.  For example, OVN already supports this subport model with the"},{"line_number":214,"context_line":"existing OVS VIF type.  However, it\u0027s possible that certain Neutron backends"},{"line_number":215,"context_line":"that use OVS could require a new VIF type to make subports work with how they"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_5b2522ac","line":212,"in_reply_to":"da85f559_7efb4a48","updated":"2015-11-13 15:36:42.000000000","message":"because you can handle this easily with OpenFlow.\n\nHere are flows for table 0 to handle input from a single VIF.  This is how  we\u0027d handle a port with 2 subports.  The 2 subports are using VLAN ids 101 and 102.  The parent port is connected to network 1.  The subport using VLAN 101 is connected to network 2.  The subport using VLAN 102 is connected to network 3.\n\nThe input port 1 is the VM\u0027s VIF.  We need to handle input from 3 logical ports on this single VIF.  These flows use \"metadata\" to remember what logical network the packet is destined for.  They also use reg6 to remember the source logical port (an ID local to the logical network, so they\u0027re all the same here).\n\n   table\u003d0, priority\u003d150,in_port\u003d1,dl_vlan\u003d101 actions\u003dset_field:0x2-\u003emetadata,set_field:0x1-\u003ereg6,pop_vlan,resubmit(,16)\n\nMatch on input from port 1 and VLAN 101.  Set 2 in \"metadata\" to remember that this packet is destined for network 2.  Set 1 in reg6 to remember that this packet arrived from logical port 1 within network 2.  Strip the VLAN header and continue processing in table 16.\n\n   table\u003d0, priority\u003d150,in_port\u003d1,dl_vlan\u003d102 actions\u003dset_field:0x3-\u003emetadata,set_field:0x1-\u003ereg6,pop_vlan,resubmit(,16)\n\nSimilar to above, but logical port 1 within network 3.\n\n   table\u003d0, priority\u003d100,in_port\u003d1 actions\u003dset_field:0x1-\u003emetadata,set_field:0x1-\u003ereg6,resubmit(,16)\n\nFinally, at a lower priority, match all other traffic from port 1 (this is the parent port).  The source is logical port 1 on network 1.\n\nI know the existing ovs support makes heavy use of the normal action, but you can mix that with flows.  I haven\u0027t gone back to look at details to see if I can come up with a specific proposal for neutron\u0027s ovs agent.\n\nMy point is just that it\u0027s certainly possible with OVS, and is a question of how invasive it is to the OVS agent\u0027s current model.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"ab58c6801cb08aac8a3d8a61765852fbf416fc59","unresolved":false,"context_lines":[{"line_number":213,"context_line":"perspective.  For example, OVN already supports this subport model with the"},{"line_number":214,"context_line":"existing OVS VIF type.  However, it\u0027s possible that certain Neutron backends"},{"line_number":215,"context_line":"that use OVS could require a new VIF type to make subports work with how they"},{"line_number":216,"context_line":"currently utilize OVS.  If a new VIF type is needed, it will be defined and"},{"line_number":217,"context_line":"proposed separately."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_863d98bd","line":216,"updated":"2015-11-12 21:59:24.000000000","message":"If a new VIF type is needed, we would need to tell the parent port at creation time that it\u0027s going to be a parent...","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"fc73a86d99c568425722eb82e6ebfbfd25cc70fd","unresolved":false,"context_lines":[{"line_number":213,"context_line":"perspective.  For example, OVN already supports this subport model with the"},{"line_number":214,"context_line":"existing OVS VIF type.  However, it\u0027s possible that certain Neutron backends"},{"line_number":215,"context_line":"that use OVS could require a new VIF type to make subports work with how they"},{"line_number":216,"context_line":"currently utilize OVS.  If a new VIF type is needed, it will be defined and"},{"line_number":217,"context_line":"proposed separately."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_f3dbed4d","line":216,"in_reply_to":"ba8a016a_adf2fa04","updated":"2015-11-20 20:15:32.000000000","message":"OK, I\u0027ll re-add it.  It does at least have the benefit of letting Neutron reject the request earlier if the backend doesn\u0027t support parent/subports.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"b71f3d065edcad92d2b97c51c5d38d9ce926614f","unresolved":false,"context_lines":[{"line_number":213,"context_line":"perspective.  For example, OVN already supports this subport model with the"},{"line_number":214,"context_line":"existing OVS VIF type.  However, it\u0027s possible that certain Neutron backends"},{"line_number":215,"context_line":"that use OVS could require a new VIF type to make subports work with how they"},{"line_number":216,"context_line":"currently utilize OVS.  If a new VIF type is needed, it will be defined and"},{"line_number":217,"context_line":"proposed separately."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_adf2fa04","line":216,"in_reply_to":"da85f559_432f4fa1","updated":"2015-11-16 13:14:20.000000000","message":"I think we need to re-add the parent port marker even if it\u0027s ugly.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"99831e7abdeec979f258eaea51880e5c9ff91e17","unresolved":false,"context_lines":[{"line_number":213,"context_line":"perspective.  For example, OVN already supports this subport model with the"},{"line_number":214,"context_line":"existing OVS VIF type.  However, it\u0027s possible that certain Neutron backends"},{"line_number":215,"context_line":"that use OVS could require a new VIF type to make subports work with how they"},{"line_number":216,"context_line":"currently utilize OVS.  If a new VIF type is needed, it will be defined and"},{"line_number":217,"context_line":"proposed separately."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_dc9fde4e","line":216,"in_reply_to":"da85f559_863d98bd","updated":"2015-11-13 09:53:10.000000000","message":"This is right, and the previous comment about being free to rewire is not (because we would need to tell libvirt to re-plug into another bridge and that won\u0027t happen). So sorry for misleading everybody, but it seems like we still need the bit marking a port as a parent port.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"a25627ca1ae8d94379d3a57cd62033043a306698","unresolved":false,"context_lines":[{"line_number":213,"context_line":"perspective.  For example, OVN already supports this subport model with the"},{"line_number":214,"context_line":"existing OVS VIF type.  However, it\u0027s possible that certain Neutron backends"},{"line_number":215,"context_line":"that use OVS could require a new VIF type to make subports work with how they"},{"line_number":216,"context_line":"currently utilize OVS.  If a new VIF type is needed, it will be defined and"},{"line_number":217,"context_line":"proposed separately."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_fbabb6d4","line":216,"in_reply_to":"da85f559_dc9fde4e","updated":"2015-11-13 15:36:42.000000000","message":"Indeed...\n\nI\u0027m not sure we can resolve this without a more definitive answer to how this would be implemented in the ovs agent, so I\u0027ll take a closer look and see if I can propose something.  I was hoping to avoid those details in this spec, but it has a pretty fundamental impact on the API requirements.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"624b40876dd20fb20f0f6b2ab1e433394313af60","unresolved":false,"context_lines":[{"line_number":213,"context_line":"perspective.  For example, OVN already supports this subport model with the"},{"line_number":214,"context_line":"existing OVS VIF type.  However, it\u0027s possible that certain Neutron backends"},{"line_number":215,"context_line":"that use OVS could require a new VIF type to make subports work with how they"},{"line_number":216,"context_line":"currently utilize OVS.  If a new VIF type is needed, it will be defined and"},{"line_number":217,"context_line":"proposed separately."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_432f4fa1","line":216,"in_reply_to":"da85f559_fbabb6d4","updated":"2015-11-15 21:15:13.000000000","message":"OK, I\u0027ve convinced myself that just using flows is probably too invasive.  I guess we need the parent port marking, then?\n\nIt\u0027s unfortunate, because we\u0027re letting a backend limitation make the API a little uglier, but that\u0027s the tradeoff we are faced with here.\n\nWhat do you all think?  Re-add the parent port marker?","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"a36c4d276413b10e52acee03a517e9b3ef0d4b77","unresolved":false,"context_lines":[{"line_number":215,"context_line":"that use OVS could require a new VIF type to make subports work with how they"},{"line_number":216,"context_line":"currently utilize OVS.  If a new VIF type is needed, it will be defined and"},{"line_number":217,"context_line":"proposed separately."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"Alternatives"},{"line_number":220,"context_line":"------------"},{"line_number":221,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_a25131da","line":218,"updated":"2015-11-18 09:45:04.000000000","message":"Another note on the proposed vif driver that came up in an irc meet thanks to Bob Kukura. The new vif driver likely could be reused for the nfv-vlan-trunk kind of vlan transparent networks too. Strictly speaking this is probably out of scope here. This is just a note on a possible easy win for the implementation.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"ab58c6801cb08aac8a3d8a61765852fbf416fc59","unresolved":false,"context_lines":[{"line_number":217,"context_line":"proposed separately."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"Alternatives"},{"line_number":220,"context_line":"------------"},{"line_number":221,"context_line":""},{"line_number":222,"context_line":"A previous version of this proposal included a new first class resource called a"},{"line_number":223,"context_line":"\"trunk port\" instead of using a regular Neutron port as the parent.  The major"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_264aac56","line":220,"updated":"2015-11-12 21:59:24.000000000","message":"Something that has been bothering me is that the sub-port setup is essentially just another case of normal port binding. Someone could conceivably already implement all of this with an existing mechasism driver.\n\nneutron port-create SOMENET --binding:profile type\u003ddict vnic_type\u003dsubport,parent_port\u003d\u003cuuid\u003e,encap\u003dvlan,vid\u003d103\n\nThen a mech driver would get that; and, if it can tag to the VM, bind the port and setup the tagging on the agent. If it can\u0027t, it would just ignore it and the port would stay UNBOUND.\n\nDo you think you can list some advantages of having a new API to do this? The main one I can think of is that it can be separately allowed without giving users access to the binding API. But is that it?","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"fc73a86d99c568425722eb82e6ebfbfd25cc70fd","unresolved":false,"context_lines":[{"line_number":217,"context_line":"proposed separately."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"Alternatives"},{"line_number":220,"context_line":"------------"},{"line_number":221,"context_line":""},{"line_number":222,"context_line":"A previous version of this proposal included a new first class resource called a"},{"line_number":223,"context_line":"\"trunk port\" instead of using a regular Neutron port as the parent.  The major"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_93edc1f1","line":220,"in_reply_to":"ba8a016a_4b6256da","updated":"2015-11-20 20:15:32.000000000","message":"I\u0027m neutral on the use of \"subport:\" vs. \"binding:\".  I\u0027m happy to change it if Kevin prefers it, but I\u0027ll leave it as-is for the next revision.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"28051271d59000ab59cf969c1da843f3f687674c","unresolved":false,"context_lines":[{"line_number":217,"context_line":"proposed separately."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"Alternatives"},{"line_number":220,"context_line":"------------"},{"line_number":221,"context_line":""},{"line_number":222,"context_line":"A previous version of this proposal included a new first class resource called a"},{"line_number":223,"context_line":"\"trunk port\" instead of using a regular Neutron port as the parent.  The major"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_13969594","line":220,"in_reply_to":"da85f559_1341b539","updated":"2015-11-13 20:32:47.000000000","message":"Yes, that makes sense.  I\u0027ll incorporate some text about this in the next revision.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"624b40876dd20fb20f0f6b2ab1e433394313af60","unresolved":false,"context_lines":[{"line_number":217,"context_line":"proposed separately."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"Alternatives"},{"line_number":220,"context_line":"------------"},{"line_number":221,"context_line":""},{"line_number":222,"context_line":"A previous version of this proposal included a new first class resource called a"},{"line_number":223,"context_line":"\"trunk port\" instead of using a regular Neutron port as the parent.  The major"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_231b2b82","line":220,"in_reply_to":"da85f559_13969594","updated":"2015-11-15 21:15:13.000000000","message":"A thought ... with this way of thinking about it, we could call these attributes:\n\n    binding:parent_id\n    binding:segmentation_type\n    binding:segmentation_id","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"b71f3d065edcad92d2b97c51c5d38d9ce926614f","unresolved":false,"context_lines":[{"line_number":217,"context_line":"proposed separately."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"Alternatives"},{"line_number":220,"context_line":"------------"},{"line_number":221,"context_line":""},{"line_number":222,"context_line":"A previous version of this proposal included a new first class resource called a"},{"line_number":223,"context_line":"\"trunk port\" instead of using a regular Neutron port as the parent.  The major"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_4b6256da","line":220,"in_reply_to":"da85f559_231b2b82","updated":"2015-11-16 13:14:20.000000000","message":"Only half jokingly: For a long time I felt that binding is the catch-all sink of neutron behaviors nobody knows a better place for.\n\nBut if you think we should go for this, I can accept it.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"99831e7abdeec979f258eaea51880e5c9ff91e17","unresolved":false,"context_lines":[{"line_number":217,"context_line":"proposed separately."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"Alternatives"},{"line_number":220,"context_line":"------------"},{"line_number":221,"context_line":""},{"line_number":222,"context_line":"A previous version of this proposal included a new first class resource called a"},{"line_number":223,"context_line":"\"trunk port\" instead of using a regular Neutron port as the parent.  The major"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_fce502dc","line":220,"in_reply_to":"da85f559_264aac56","updated":"2015-11-13 09:53:10.000000000","message":"This is a really interesting comment. I have to read up on the use of binding:profile to have any meaningful answer.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"1b3f9b90cfe68b0f2a7755e0a4100ee29b72d9fe","unresolved":false,"context_lines":[{"line_number":217,"context_line":"proposed separately."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"Alternatives"},{"line_number":220,"context_line":"------------"},{"line_number":221,"context_line":""},{"line_number":222,"context_line":"A previous version of this proposal included a new first class resource called a"},{"line_number":223,"context_line":"\"trunk port\" instead of using a regular Neutron port as the parent.  The major"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_1341b539","line":220,"in_reply_to":"da85f559_dbc9125c","updated":"2015-11-13 20:24:22.000000000","message":"Right, I\u0027m fine with adding this API to control specific attributes and allow regular users to access it without opening up the rest of the binding API to normal tenants (which could cause security issues with bare metal binding stuff going on for Ironic).\n\nI think if we just point out that this API can be viewed as a standardized way to control binding information for encapsulated ports, maybe that will help people understand what the change will entail.\n\nWhen I think about how this will be implemented in the ML2 case, the API changes will probably just provide more information to the port binding internal calls so from an ML2 driver\u0027s perspective, this will essentially just be another case of port binding. Does that make sense?","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"a25627ca1ae8d94379d3a57cd62033043a306698","unresolved":false,"context_lines":[{"line_number":217,"context_line":"proposed separately."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"Alternatives"},{"line_number":220,"context_line":"------------"},{"line_number":221,"context_line":""},{"line_number":222,"context_line":"A previous version of this proposal included a new first class resource called a"},{"line_number":223,"context_line":"\"trunk port\" instead of using a regular Neutron port as the parent.  The major"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_dbc9125c","line":220,"in_reply_to":"da85f559_fce502dc","updated":"2015-11-13 15:36:42.000000000","message":"It\u0027s funny that you mention that, because this is roughly how the OVN plugin already supports this model.  This doc discusses containers, but the implementation is doing what this spec proposes, but with a custom binding:profile.\n\n   http://docs.openstack.org/developer/networking-ovn/containers.html\n\nThis isn\u0027t a very deep answer, but binding:profile is restricted to admin only by default.  Going that route means I think the default should change, but I\u0027m not sure how big of an impact that would be elsewhere.  I\u0027m not sure what all assumes that\u0027s the default policy.\n\nAlso, I thought binding:profile was pretty wide open and open to interpretation by different backends, meaning that different backends have different definitions of what binding:profile can be.  For example, OVN is using it for 2 major features that aren\u0027t expressed in the Neutron API yet, this being one of them.  I considered it short term hacks until we get a real API defined for them.\n\nSo, indeed binding:profile is an alternative.  I can discuss it here.  Even within the binding:profile idea there are some alternatives.  It can continue to be a free-for-all, or we could try to start putting some more official definitions around what valid binding:profile values are.\n\nTo attempt to summarize ... I think I still prefer formalizing these attributes.  If we went with binding:profile, I think it\u0027s worth doing some formalizing and enforcement around valid binding:profile values, which in the end isn\u0027t so different than what this proposes, except this doesn\u0027t mess with existing uses of binding:profile.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"b6a00f10e9f711d8e636b2ccd1a9b8b2d4bc715f","unresolved":false,"context_lines":[{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Neutron port:"},{"line_number":295,"context_line":"  * subport:parent_id - port id of parent."},{"line_number":296,"context_line":"  * subport:encap_type - Encapsulation type for subport traffic (vlan only for"},{"line_number":297,"context_line":"    now)"},{"line_number":298,"context_line":"  * subport:encap_info - For \"vlan\" encap_type, a integer that represents a"},{"line_number":299,"context_line":"    valid VLAN ID."}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_1500c2a9","line":296,"updated":"2015-11-13 17:43:53.000000000","message":"I think I finally realize why this proposal bothers me a lot: these are supposed to be optional fields that make sense only for when you need trunking. They should not be part of the port logical model, because in any other case they must be NULL in that a vlan id associated to a port on a network that has its segmentation type and id makes no sense whatsoever. This leads me to believe that we\u0027re actually spilling data plane details that pertains the container networking case, and that\u0027s wrong.\n\nIf I were to model this conceptually, the encap type and encap info are attributions of the parent-child ER relationship and as such would not belong to neither in the logical model.\n\nSo that\u0027s why I envision(ed) an entity that captures this information, when the trunk case is required, and would be visible then, and only then.\n\nBut what\u0027s troubling me on the other end, is why we expose these details and how they are going to be consumed and by whom. I see no clear reference about this in this spec.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"30d21a88ff005b0a6bea0cc8257d31e0eacdc40b","unresolved":false,"context_lines":[{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Neutron port:"},{"line_number":295,"context_line":"  * subport:parent_id - port id of parent."},{"line_number":296,"context_line":"  * subport:encap_type - Encapsulation type for subport traffic (vlan only for"},{"line_number":297,"context_line":"    now)"},{"line_number":298,"context_line":"  * subport:encap_info - For \"vlan\" encap_type, a integer that represents a"},{"line_number":299,"context_line":"    valid VLAN ID."}],"source_content_type":"text/x-rst","patch_set":4,"id":"9a8ffd7b_db10495c","line":296,"in_reply_to":"9a8ffd7b_4844231a","updated":"2015-11-30 19:11:17.000000000","message":"To define a trunk you need at least one parent and one child. Therefore you can create a trunk with at minimum two ports: one that acts as parent, the other that act as child. You may specify more than one child during the create operation. Conversely, you can have an operation that allows you to modify the trunk at a later time (e.g. trunk-subport-add, trunk-subport-remove). We have plenty of requests/resources that work this way. I don’t understand why you\u0027d be reluctant to it.\n\nAs for cascading, either way you go (cascade or not cascade), having an explicit trunk resource allows you to have a clear policy than if you didn’t.\n\nAs for the modeling, yes. I think that’s how you’d model logically both trunk and sub-port. I’d call port_id in the trunk resource, parent_id, with foreign key constraint to ports. Same for sub-port. I’d call port-id sub-port-id with foreign key constraint to ports. The status of the trunk needs more thinking, and not sure about the status of the sub-port, which I think is not needed (unless you think it\u0027s gonna be different from the status captured on the port foreign key).\n\nHaving explicit resources allows for a more modular implementation because you don’t have to inject trunk management actions within port management operations (e.g. when a user submit port-delete the code doesn’t have to branch out to handle trunk deletion, etc. etc). I am telling you this based on experience. If you don’t trust me on that, what is word of a core/ptl worth these days? :)","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"38e35c41ce26e3da0dbf4e3c40534cca38803958","unresolved":false,"context_lines":[{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Neutron port:"},{"line_number":295,"context_line":"  * subport:parent_id - port id of parent."},{"line_number":296,"context_line":"  * subport:encap_type - Encapsulation type for subport traffic (vlan only for"},{"line_number":297,"context_line":"    now)"},{"line_number":298,"context_line":"  * subport:encap_info - For \"vlan\" encap_type, a integer that represents a"},{"line_number":299,"context_line":"    valid VLAN ID."}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a740942_84ca6f4e","line":296,"in_reply_to":"9a8ffd7b_5ca85c8c","updated":"2015-12-03 17:59:25.000000000","message":"DVR is one of them","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"a328ba7d735121dfbc469ee5ea068991ea51ea26","unresolved":false,"context_lines":[{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Neutron port:"},{"line_number":295,"context_line":"  * subport:parent_id - port id of parent."},{"line_number":296,"context_line":"  * subport:encap_type - Encapsulation type for subport traffic (vlan only for"},{"line_number":297,"context_line":"    now)"},{"line_number":298,"context_line":"  * subport:encap_info - For \"vlan\" encap_type, a integer that represents a"},{"line_number":299,"context_line":"    valid VLAN ID."}],"source_content_type":"text/x-rst","patch_set":4,"id":"9a8ffd7b_caaf142a","line":296,"in_reply_to":"9a8ffd7b_b66ebc94","updated":"2015-11-30 19:59:31.000000000","message":"It\u0027s interesting that you mention that, because revising the relationship between host a port was one of the aspects that we never managed to deal with in the context of DVR ([1] for more details). Today the relationship is 1-1 (binding being a port-attribute), when in reality it could be one to many (a port logically bound to many hosts). So, yes, I would, even though not in the context of this initiative. \n\n[1] https://review.openstack.org/#/c/189410","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"aa3b6fc330bcf335dbfabf4e4dfa8d9293f9f89a","unresolved":false,"context_lines":[{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Neutron port:"},{"line_number":295,"context_line":"  * subport:parent_id - port id of parent."},{"line_number":296,"context_line":"  * subport:encap_type - Encapsulation type for subport traffic (vlan only for"},{"line_number":297,"context_line":"    now)"},{"line_number":298,"context_line":"  * subport:encap_info - For \"vlan\" encap_type, a integer that represents a"},{"line_number":299,"context_line":"    valid VLAN ID."}],"source_content_type":"text/x-rst","patch_set":4,"id":"9a8ffd7b_5ca85c8c","line":296,"in_reply_to":"9a8ffd7b_caaf142a","updated":"2015-12-02 14:36:16.000000000","message":"Right, I didn\u0027t think it\u0027d be in this context.  I was just curious.  Thanks for the reference.\n\nI can\u0027t think of any cast where a port and its parent would ever be a 1-many relationship, though.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"190546a1783967f22c587c8977cbb10ff6c18a4c","unresolved":false,"context_lines":[{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Neutron port:"},{"line_number":295,"context_line":"  * subport:parent_id - port id of parent."},{"line_number":296,"context_line":"  * subport:encap_type - Encapsulation type for subport traffic (vlan only for"},{"line_number":297,"context_line":"    now)"},{"line_number":298,"context_line":"  * subport:encap_info - For \"vlan\" encap_type, a integer that represents a"},{"line_number":299,"context_line":"    valid VLAN ID."}],"source_content_type":"text/x-rst","patch_set":4,"id":"9a8ffd7b_b66ebc94","line":296,"in_reply_to":"9a8ffd7b_db10495c","updated":"2015-11-30 19:15:28.000000000","message":"If it was possible to change it, would you drop a port\u0027s binding:host_id and instead have a separate \"host-binding\" resource that you create to bind a port to a host?  I\u0027m just trying to wrap my head around the proposal and what it means for where the line is generally drawn around a port.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"04ea36e793844dbf4f99bb845e64656c19af961d","unresolved":false,"context_lines":[{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Neutron port:"},{"line_number":295,"context_line":"  * subport:parent_id - port id of parent."},{"line_number":296,"context_line":"  * subport:encap_type - Encapsulation type for subport traffic (vlan only for"},{"line_number":297,"context_line":"    now)"},{"line_number":298,"context_line":"  * subport:encap_info - For \"vlan\" encap_type, a integer that represents a"},{"line_number":299,"context_line":"    valid VLAN ID."}],"source_content_type":"text/x-rst","patch_set":4,"id":"9a8ffd7b_4844231a","line":296,"in_reply_to":"9a8ffd7b_ea1d3810","updated":"2015-11-26 11:02:10.000000000","message":"Yesterday I spent a few hours trying to wrap my head around your proposal. Right now I\u0027m withholding judgement. Just trying to understand what\u0027s implied in your proposal. Let me know please if I\u0027m getting your draft.\n\n neutron net-create net0\n neutron net-create net1\n\n neutron port-create net0  # PORT0\n neutron port-create net1  # PORT1\n\nRealistically until the segmentation type and id is exposed over the\nmetadata service, we may supply the same MAC as the parent port has.\nAnd that may not work in combination with having the parent and child\nport on the same net.\n\n neutron port-create net1 --mac-address PARENT-PORTS-MAC  # PORT1\n\nI started thinking about how many children we allow in trunk-create.\nZero, one, more? If we allow more than one, then the client has to operate\non sets of children ports encoded in a single attribute. I\u0027d avoid that if\npossible. Then by the same reasoning you applied against optional attributes,\nI came to believe it may be better to have two different resources for trunks\nand subports like below.\n\ntrunk-create must come before nova boot. Return 4xx if the port has a device_owner already.\n\n neutron trunk-create --port PORT0  # TRUNK0\n\nSubports may be created at this time or later.\n\n nova boot --nic port-id\u003dPORT0 ...\n\nFor efficient operations on lots of subports, we\u0027d need to use the bulk API.\n\n neutron subport-create --port PORT1 --trunk TRUNK0 --segmentation-type TYPE-ENUM --segmentation-id ID-UINT\n\n nova delete ...\n\nport-delete may or may not cascade to trunk-delete.\ntrunk-delete may may or may not cascade to subport-delete.\nI have not formed an opinion yet to cascade or not. Cascading seems better if you don\u0027t want to know about trunks and subports at port deletion.\n\n neutron port-delete PORT0\n\nThe trunk resource would have the following attributes:\n\n id\n name\n tenant_id\n port_id\n ? status\n\nThe subport resource would have the following attributes:\n\n id\n name\n tenant_id\n port_id\n trunk_id\n segmentation_type\n segmentation_id\n ? status\n\nThe port referred by trunk would truly behave as a plain old port. However the port referred by subport could not behave exactly as a plain old port. Especially regarding its binding.\n\nIs this all in line with your thinking?\n\nOne thing I\u0027m still not getting regarding the implementation. Why this API would have a smaller effect on existing code paths? No matter which API representation we choose we still have to change *the port\u0027s behavior* to make it into a trunk or a subport. That means changing existing code paths just as much in both proposals. Like somewhere in the implementation of port_create/update we\u0027d have to say:\n\n if is_trunk(port):\n     make nova and ovs-agent wire the port differently: create trunk bridge, etc.\n\n if is_subport(port):\n     make ovs-agent skip its usual behavior and create remapping flow pairs instead\n\nThe body of the conditional stays the same with both APIs. The difference is the condition:\n\n def is_trunk(port):\n def is_subport(port):\n     look at port attributes, or\n     lookup if exists a trunk or subport instance referring to port\n\nThe changes implied in the binding behavior of the port referred by a subport seems to be same too regardless the API.\n\nAm I missing something?","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"0899979c2da9a4f8b69c6d9e2a73fae2f4b90947","unresolved":false,"context_lines":[{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Neutron port:"},{"line_number":295,"context_line":"  * subport:parent_id - port id of parent."},{"line_number":296,"context_line":"  * subport:encap_type - Encapsulation type for subport traffic (vlan only for"},{"line_number":297,"context_line":"    now)"},{"line_number":298,"context_line":"  * subport:encap_info - For \"vlan\" encap_type, a integer that represents a"},{"line_number":299,"context_line":"    valid VLAN ID."}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_cdb925cd","line":296,"in_reply_to":"ba8a016a_34792dfd","updated":"2015-11-23 17:19:25.000000000","message":"1) What is the purpose of use case (1)? \n\nVM and its nested containers connected to the same network; but let\u0027s say this model doesn\u0027t make sense; since it seems we relaxed the constraint of preventing the parent port from belonging to a network, this use case becomes perfectly legitimate from a CLI standpoint, no?\n\n2) Querying the properties:\n\nYou don\u0027t need to check if the trunk exists all the time you\u0027re querying a port. The resources that extend the port are seamlessly associated to the port every time you access it. As for your polymorph argument, not sure how justified it is: you do want a port to behave differently regardless of how you create the logical trunk. Besides, at line 192, it was discussed that it makes sense to allow for a port to mutate, am I missing your point?\n\n3) How do we solve that problem in this model?\n\nMy proposal does not get rid of the parent marker. I am only saying that it becomes an extension attribute, when a port indeed needs to be a parent of a trunk.\n\n4) Less importantly. This argument: \"as these properties are optional in any case that does not involve creating a trunk\". Isn\u0027t this reason true for all extensions of existing resources with extra attributes? I understand this type of extension is generally harder to implement than a the new resource type of extension. \n\nWhat experience do you have in order to make this claim? I don\u0027t believe it\u0027s true.\n\n5) which internal parts of neutron would benefit from the approach?\n\nI think my alternative proposal would simplify the server-side as well as the client side implementation (the agent-side is not affected), in that the changes are not going to interfere with the existing port-handling code paths as heavily, but that\u0027s not my primary justification. My primary justification is keeping the current API model sane.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"9ac7d33886926c7d3e6c69ffda8b2487015a5c38","unresolved":false,"context_lines":[{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Neutron port:"},{"line_number":295,"context_line":"  * subport:parent_id - port id of parent."},{"line_number":296,"context_line":"  * subport:encap_type - Encapsulation type for subport traffic (vlan only for"},{"line_number":297,"context_line":"    now)"},{"line_number":298,"context_line":"  * subport:encap_info - For \"vlan\" encap_type, a integer that represents a"},{"line_number":299,"context_line":"    valid VLAN ID."}],"source_content_type":"text/x-rst","patch_set":4,"id":"9a8ffd7b_ea1d3810","line":296,"in_reply_to":"ba8a016a_7a9c49c0","updated":"2015-11-24 17:25:38.000000000","message":"2) Resources can be extended dynamically, the core plugin provides hooks to do that, so based on the existence of a trunk you can tell whether a port is a subport or not.\n\n3) no, you don\u0027t specify the --is_parent on port create. The port-create CLI stays untouched. The is_parent property is associated to the port only after the trunk is created, and can be seen when you do port-show after the trunk-create command.\n\n5) I hope I addressed your concern on [2]. I meant sanity as a synonym of leaving the existing API and API workflow untouched. If users do not use trunks, these aspects are not going to be visible to them. I said that from a development standpoint, the code in one case is going to be simple (modular) additions, in the other, it\u0027s going to be lots of edition of existing code paths. The former is clearly more advantageous than the latter!\n\nIn the end, a spec is a tool for gathering feedback. I am giving you feedback based on my experience with Neutron development and what I have seen over the years.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"aef1c00cffeda1b288f2bbdca6e2b9e6fc3f3d33","unresolved":false,"context_lines":[{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Neutron port:"},{"line_number":295,"context_line":"  * subport:parent_id - port id of parent."},{"line_number":296,"context_line":"  * subport:encap_type - Encapsulation type for subport traffic (vlan only for"},{"line_number":297,"context_line":"    now)"},{"line_number":298,"context_line":"  * subport:encap_info - For \"vlan\" encap_type, a integer that represents a"},{"line_number":299,"context_line":"    valid VLAN ID."}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_c157ec24","line":296,"in_reply_to":"ba8a016a_909389a3","updated":"2015-11-21 01:35:10.000000000","message":"Ok, let me try to rephrase.\n\nAssociating the properties of encap_type, encap_info and parent_id associated directly to Port is not the right conceptual and logical model, as these properties are optional in any case that does not involve creating a trunk. As such, they are best modeled as required properties of a trunk resource shared between two Neutron Ports (parent and child(ren)) whose properties are the encap type, encap info and parent and child(ren) id(s).\n\nSo what I am saying is: leave the port alone. Create a new resource called Trunk and then you can do:\n\n \u003e neutron net-create Nx\n \u003e neutron port-create Nx # create P\u0027 on Nx\n \u003e neutron port-create Nx # create P\u0027\u0027 on Nx\n \u003e neutron trunk-create --parent P\u0027 --child P\u0027\u0027,vlan,33 [--child] # connects ports together on the same network (case 1)\n\nor \n\n \u003e neutron net-create Nx\n \u003e neutron port-create Nx # create P\u0027 on Nx\n \u003e neutron port-create Ny # create P\u0027\u0027 on Ny\n \u003e neutron trunk-create --parent P\u0027 --child P\u0027\u0027,vlan,33 [--child] # connects ports together on two different networks (case 2)\n\nIMO, this is a better modeling than the one being proposed, as it does not mess up with the existing model. As for the spillage of data plane details, let\u0027s agree to disagree, but as a dumb user of containers, I personally wouldn\u0027t want to care what vlan my container is gonna sit on, I wish my backend would do the handshake himself and just give me my damn port.\n\nNow you can still pass port to Nova, can\u0027t you? This is probably what I meant all along, and I suppose I got lost in translation somewhere along the journey. I apologize if I was not clear enough.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"9c1c4e4f80eb2e5c40b8842936fab71062493364","unresolved":false,"context_lines":[{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Neutron port:"},{"line_number":295,"context_line":"  * subport:parent_id - port id of parent."},{"line_number":296,"context_line":"  * subport:encap_type - Encapsulation type for subport traffic (vlan only for"},{"line_number":297,"context_line":"    now)"},{"line_number":298,"context_line":"  * subport:encap_info - For \"vlan\" encap_type, a integer that represents a"},{"line_number":299,"context_line":"    valid VLAN ID."}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_34792dfd","line":296,"in_reply_to":"ba8a016a_c157ec24","updated":"2015-11-23 13:05:29.000000000","message":"No problem and thanks for the details. Let\u0027s make sure this time we discuss the options thoroughly. So we come to a consensus which approach is better.\n\nI have several questions.\n\n1) What is the purpose of use case (1)? Why would a user want to see the traffic of the same network twice on a port and at the same time on one of its subports?\n\n2) Probably most of us agrees that the trunk port could be a seamless extension of a plain old port from cloud user perspective and/or API perspective. (This is likely not the case, when it comes to how a trunk port is implemented in ovs-agent, but here I intentionally ignore that for a moment.) On the other hand (regardless which API representation we choose), the subport must user-visibly *behave* differently from a plain old port (that it must not be directly attached to a vm, or that it must inherit certain attributes from the parent). If the subport behaves differently, but the API representation of it (as a port) is exactly the same, do you consider that good behavior? I mean the same port would behave differently (when it\u0027s a port or a subport) depending on whether there is a trunk instance pointing to it or not. As a cloud user I would have to check if such a trunk instance exists all the time I\u0027m querying a port. This sounds quite serious to me.\n\n3) If we don\u0027t have any marker of a port being a parent at the time of booting a vm with that port, we have the same problem with ovs-agent as discussed before. How do we solve that problem in this model? Is the answer any different?\n\n4) Less importantly. This argument: \"as these properties are optional in any case that does not involve creating a trunk\". Isn\u0027t this reason true for all extensions of existing resources with extra attributes? I understand this type of extension is generally harder to implement than a the new resource type of extension. However certain *extensions of behavior* naturally call for this type of API extension. What is our guideline which extension of behavior should fall into which API extension type? IMHO the complexity of the implementation should not be the sole viewpoint.\n\n5) Also, maybe this is trivial for others but for my own curiosity I would be interested in what you think which internal parts of neutron would benefit (by the change being simpler) from this approach?","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"83fb24118a1c7f8923f7838b1293ba2e2e2f78ba","unresolved":false,"context_lines":[{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Neutron port:"},{"line_number":295,"context_line":"  * subport:parent_id - port id of parent."},{"line_number":296,"context_line":"  * subport:encap_type - Encapsulation type for subport traffic (vlan only for"},{"line_number":297,"context_line":"    now)"},{"line_number":298,"context_line":"  * subport:encap_info - For \"vlan\" encap_type, a integer that represents a"},{"line_number":299,"context_line":"    valid VLAN ID."}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_7a9c49c0","line":296,"in_reply_to":"ba8a016a_cdb925cd","updated":"2015-11-24 10:08:39.000000000","message":"1) Agreed.\n\n2) Maybe I just missed it, but did we come to a conclusion on allowing or prohibiting the conversion from subport to port? If yes, which way did we decide?\n\nBut back to my main argument. Let\u0027s suppose I have a port which at some earlier time was created as usual:\n\n neutron port-create net0 --name port0\n ... time goes, other operations may happen, the client comes back ...\n neutron port-show port0\n\nFrom the output of port-show it\u0027s not possible to tell if port0 is a plain old port or a subport. That means we cannot tell what operations are possible at this point. Either the client must magically know that this port is a subport (which may be a reasonable expectation, but I\u0027m far from sure we can expect this in all possible cases), or the client must query if there is an instance of the trunk resource pointing to this port. In the latter case the trunk resource practically becomes an extension of the port resource, just in a hidden, unexpected way.\n\nI still believe that changing the type of an object (port to subport or back), because somebody else (an instance of the trunk resource) holds a reference to it is asking for trouble.\n\nAm I missing something here? Shall we have a read-only attribute for port subtype?\n\n3) Okay, so we would have this, right?\n\n neutron net-create Nx\n neutron net-create Ny\n neutron port-create Nx --is_parent # create P\u0027 on Nx\n neutron port-create Ny # create P\u0027\u0027 on Ny\n nova boot --nic port-id\u003dP\u0027 ...\n neutron trunk-create --parent P\u0027 --child P\u0027\u0027,vlan,33 [--child]\n\nWhere:\n\n * --is_parent cannot be changed\n ** after create\n ** after nova started using the port\n * the port given to --parent in trunk_create must be --is_parent\n * the --child may or may not be --is_parent\n * booting a vm on a --child must be rejected somewhere, probably when nova tries to update the port\u0027s device_owner to nova:compute\n * a port already used by nova must be rejected whenever given to --child\n\n4) All I meant is that implementing a new service plugin is less entangled with already existing code than changing a pre-existing plugin.\n\n5) I honestly have a hard time understanding your viewpoint. You\u0027re saying the difference between the two approaches is that only one of them is \"sane\", only one of them is the \"right conceptual and logical model\". One if them is \"invasive\", the other is not. These arguments for me are on a very high level. They are also quite subjective, just like developers talking about the beauty and simplicity of a design and every one of them finds something else beautiful. If I ignore my reservation expressed in (2), then I see that the trunk resource approach is *possible*. On the other hand I fail to see how is it *any better* then the original approach proposed in this bp. May I ask for one or two *concrete, low-level, technical* examples of how and where this approach proves better?\n\nAlso what other reviewers are thinking about the benefits and disadvantages of the two approaches? Which one do you prefer? Do you think (2) is a problem or not?","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"e5926e4ae8cce64d27dc9d91394ff3e9a1aa5f20","unresolved":false,"context_lines":[{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Neutron port:"},{"line_number":295,"context_line":"  * subport:parent_id - port id of parent."},{"line_number":296,"context_line":"  * subport:encap_type - Encapsulation type for subport traffic (vlan only for"},{"line_number":297,"context_line":"    now)"},{"line_number":298,"context_line":"  * subport:encap_info - For \"vlan\" encap_type, a integer that represents a"},{"line_number":299,"context_line":"    valid VLAN ID."}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_1826b216","line":296,"in_reply_to":"da85f559_1500c2a9","updated":"2015-11-13 20:13:36.000000000","message":"To be honest, I\u0027m having a hard time understanding this comment.  Maybe a real-time chat could help clear things up.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"b71f3d065edcad92d2b97c51c5d38d9ce926614f","unresolved":false,"context_lines":[{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Neutron port:"},{"line_number":295,"context_line":"  * subport:parent_id - port id of parent."},{"line_number":296,"context_line":"  * subport:encap_type - Encapsulation type for subport traffic (vlan only for"},{"line_number":297,"context_line":"    now)"},{"line_number":298,"context_line":"  * subport:encap_info - For \"vlan\" encap_type, a integer that represents a"},{"line_number":299,"context_line":"    valid VLAN ID."}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_909389a3","line":296,"in_reply_to":"da85f559_1826b216","updated":"2015-11-16 13:14:20.000000000","message":"I don\u0027t understand Armando\u0027s comment fully, but I definitely disagree that we are spilling data plane details. Here\u0027s why. We currently have an implicit promise to code running in a guest VM. That on your vNIC you have to speak ethernet. Actually you have to send/receive one particular ethernet frame format. I\u0027m not that familiar with the ethernet standards, but my guess is the relevant standard here is IEEE 802.3. But for the cloud user this is _not_ the forwarding plane. This is the entry point interface to the data plane and nothing beyond that.\n\nNow we are trying to extend this, so you can send/receive slightly different frame formats (802.1Q). The default case in OpenStack is implicit, but we have to explicitly describe what\u0027s beyond the default. Would it be better to have port attributes like this?\n\n id\n name\n ...\n frame_format \u003d 803.3 | 802.1Q | ...\n frame_format_details \u003d vlan_id:101,...\n\nCould you please elaborate on what you miss about consumers? I don\u0027t consider a good idea to specify who can use an API.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"b71f3d065edcad92d2b97c51c5d38d9ce926614f","unresolved":false,"context_lines":[{"line_number":308,"context_line":"|Name      |       |         |Value    |Conversion  |                     |"},{"line_number":309,"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\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\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+"},{"line_number":310,"context_line":"|subport:  |string |CR, all  |\u0027\u0027       |uuid of     |ID of the parent     |"},{"line_number":311,"context_line":"|parent_id |(UUID) |         |         |parent      |port that subport is |"},{"line_number":312,"context_line":"|          |       |         |         |            |connected to.        |"},{"line_number":313,"context_line":"+----------+-------+---------+---------+------------+---------------------+"},{"line_number":314,"context_line":"|subport:  |integer|CR, all  |\u0027\u0027       |uint or     |For encap_type of    |"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_5000c1aa","line":311,"updated":"2015-11-16 13:14:20.000000000","message":"How shall we decide to use a new parent_id attribute, or reuse device_owner/id? Maybe a vote here, replying to this comment?","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"b71f3d065edcad92d2b97c51c5d38d9ce926614f","unresolved":false,"context_lines":[{"line_number":312,"context_line":"|          |       |         |         |            |connected to.        |"},{"line_number":313,"context_line":"+----------+-------+---------+---------+------------+---------------------+"},{"line_number":314,"context_line":"|subport:  |integer|CR, all  |\u0027\u0027       |uint or     |For encap_type of    |"},{"line_number":315,"context_line":"|encap_info|       |         |         |\u0027\u0027          |vlan, this is the    |"},{"line_number":316,"context_line":"|          |       |         |         |            |VLAN id used for     |"},{"line_number":317,"context_line":"|          |       |         |         |            |packets to and from  |"},{"line_number":318,"context_line":"|          |       |         |         |            |this subport.        |"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_d02a712c","line":315,"updated":"2015-11-16 13:14:20.000000000","message":"s/encap_info/segmentation_id/","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"b71f3d065edcad92d2b97c51c5d38d9ce926614f","unresolved":false,"context_lines":[{"line_number":318,"context_line":"|          |       |         |         |            |this subport.        |"},{"line_number":319,"context_line":"+----------+-------+---------+---------+------------+---------------------+"},{"line_number":320,"context_line":"|subport:  |string |CR, all  |\u0027vlan\u0027   |enum (*)    |Encapsulation type   |"},{"line_number":321,"context_line":"|encap_type|       |         |         |            |for packets to/from  |"},{"line_number":322,"context_line":"|          |       |         |         |            |the subport as they  |"},{"line_number":323,"context_line":"|          |       |         |         |            |pass through the     |"},{"line_number":324,"context_line":"|          |       |         |         |            |parent port.         |"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_10d8f952","line":321,"updated":"2015-11-16 13:14:20.000000000","message":"s/encap_type/segmentation_type/","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"b6a00f10e9f711d8e636b2ccd1a9b8b2d4bc715f","unresolved":false,"context_lines":[{"line_number":399,"context_line":"* Neutron Plugin support."},{"line_number":400,"context_line":"  * networking-ovn (OVN supports this model already)"},{"line_number":401,"context_line":"  * ml2+ovs"},{"line_number":402,"context_line":"* Expose subport information in nova metadata service (likely will require a new"},{"line_number":403,"context_line":"  spec)"},{"line_number":404,"context_line":""},{"line_number":405,"context_line":"Dependencies"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_ea80b98d","line":402,"updated":"2015-11-13 17:43:53.000000000","message":"but wouldn\u0027t that require nova changes then?","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"aef1c00cffeda1b288f2bbdca6e2b9e6fc3f3d33","unresolved":false,"context_lines":[{"line_number":399,"context_line":"* Neutron Plugin support."},{"line_number":400,"context_line":"  * networking-ovn (OVN supports this model already)"},{"line_number":401,"context_line":"  * ml2+ovs"},{"line_number":402,"context_line":"* Expose subport information in nova metadata service (likely will require a new"},{"line_number":403,"context_line":"  spec)"},{"line_number":404,"context_line":""},{"line_number":405,"context_line":"Dependencies"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba8a016a_010c1441","line":402,"in_reply_to":"da85f559_64c95dac","updated":"2015-11-21 01:35:10.000000000","message":"ok, thanks for clearing that up.","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"591d97b65ab42a29ddc1f65b32453343b46ac6b3","unresolved":false,"context_lines":[{"line_number":399,"context_line":"* Neutron Plugin support."},{"line_number":400,"context_line":"  * networking-ovn (OVN supports this model already)"},{"line_number":401,"context_line":"  * ml2+ovs"},{"line_number":402,"context_line":"* Expose subport information in nova metadata service (likely will require a new"},{"line_number":403,"context_line":"  spec)"},{"line_number":404,"context_line":""},{"line_number":405,"context_line":"Dependencies"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da85f559_64c95dac","line":402,"in_reply_to":"da85f559_ea80b98d","updated":"2015-11-13 18:13:40.000000000","message":"I\u0027m not sure it would. We merged a thing a while back that generates a summary of the neutron info we have. It\u0027s fairly automatic I think, and may just work.\n\nBut as I said, I\u0027m not at all opposed to nova changes in support of this, and certainly not to making sure the guest has the proper information (see my previous comments on this spec about making *sure* nova exposes this properly).\n\nAll I care about is not adding a new resource, peer to port, which is a slightly-different-but-mostly-the-same-port thing :)","commit_id":"9c8f5e64c62bef7c0b734e7f06951c5adf017a9e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c6b5d8955e926d7178a80110f1fe674f311c114f","unresolved":false,"context_lines":[{"line_number":38,"context_line":"  hundreds of VIFs per VM."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"* Cloud workloads are often very dynamic.  It may be more efficient and/or less"},{"line_number":41,"context_line":"  complex to add/remove VLANs than to hotplug interfaces in a VM."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"* Admin controlled service VMs could use this to provide service to many tenant"},{"line_number":44,"context_line":"  networks."}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a8ffd7b_1e2b1a32","line":41,"updated":"2015-11-24 20:12:34.000000000","message":"one related usecase that this would enable is moving a vm/port to a different network without detaching and attach the vif from the vm. this usecase can be supported by deleting the subport attached to the old network and adding a new subport to the new network.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"7df587b2ac6dffa907fc24597158a6ca60855767","unresolved":false,"context_lines":[{"line_number":38,"context_line":"  hundreds of VIFs per VM."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"* Cloud workloads are often very dynamic.  It may be more efficient and/or less"},{"line_number":41,"context_line":"  complex to add/remove VLANs than to hotplug interfaces in a VM."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"* Admin controlled service VMs could use this to provide service to many tenant"},{"line_number":44,"context_line":"  networks."}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a8ffd7b_0c03af10","line":41,"in_reply_to":"9a8ffd7b_1e2b1a32","updated":"2015-11-25 19:55:17.000000000","message":"Interesting use case, I hadn\u0027t considered that.  I\u0027ll add it in the next revision.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"5de0ceab696753c78ed4a33f283c38bb7016f3ea","unresolved":false,"context_lines":[{"line_number":68,"context_line":"The first part of the API extension is the logical topology portion.  First, we"},{"line_number":69,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":70,"context_line":"strictly necessary, but is included for convenience.  It allows Neutron to go"},{"line_number":71,"context_line":"ahead and reject the port creation if subports aren\u0027t supported by the backend."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"::"},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_81823ac7","line":71,"updated":"2015-11-21 18:57:38.000000000","message":"I\u0027m still not sold that having this information be an attribute of the port data model (as opposed to there being a discovery mechanism that the neutron user can call to determine if a backend supports setting up child ports), but OK.\n\nI know this is_parent attribute would make the OVS agent implementation easier, but I guess I don\u0027t see the big deal in making the failure point be the attempt to add a child port as opposed to an attempt to create a port that has the ability to have child ports.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"73eb8345942b0b4131464d2f2dc8f5b1371e13ba","unresolved":false,"context_lines":[{"line_number":68,"context_line":"The first part of the API extension is the logical topology portion.  First, we"},{"line_number":69,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":70,"context_line":"strictly necessary, but is included for convenience.  It allows Neutron to go"},{"line_number":71,"context_line":"ahead and reject the port creation if subports aren\u0027t supported by the backend."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"::"},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a8ffd7b_72425212","line":71,"in_reply_to":"9a8ffd7b_720a5223","updated":"2015-11-25 20:22:44.000000000","message":"On a side note, I filed a nova blueprint for allowing Neutron to specify the ovs bridge name: https://blueprints.launchpad.net/nova/+spec/neutron-ovs-bridge-name\n\nArmando, I totally understand that you see it as cluttered.  I don\u0027t.  That part seems like a matter of taste.  Regarding implementation complexity, maybe I just need to spend some more time in the code trying to implement this and maybe that will help me come around to what you\u0027re proposing.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ffa0ce50ccf1d0c6b303ab61f8083bdd47c4323a","unresolved":false,"context_lines":[{"line_number":68,"context_line":"The first part of the API extension is the logical topology portion.  First, we"},{"line_number":69,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":70,"context_line":"strictly necessary, but is included for convenience.  It allows Neutron to go"},{"line_number":71,"context_line":"ahead and reject the port creation if subports aren\u0027t supported by the backend."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"::"},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a8ffd7b_d36e5bff","line":71,"in_reply_to":"9a8ffd7b_72425212","updated":"2015-12-03 00:39:10.000000000","message":"@Russell \nyes i am kind of sad that the of-agent is going away.\nthe multi table openflow pipeline it uses is much more powerful then how the ovs agent works today. it would also\nsolve alot of issue with how to support SFC and openflow base security groups.\n\nin the long run it would be probably better to move the ovs agent towards an openflow model similar to that used by the of-agent but as i would like to see this feature land hopefully this cycle i would prefer not to rip the guts out of the existing agent.\n\nbut back to why i originally wanted to comment . as you probably know better then i, there is no overhead to creating two ovs bridges connected by patch ports vs a singel bridge as in both case they will be colapsed in to a single datapth instace by ovs. adding a per port bridge also potentially  has other benifits. for example it would provide the perfect location to install openflow based ACLs via a security group driver.\n\nthat would allow you to do the following instead\nVM \u003c-\u003e tap device or vhost-user port \u003c-\u003e port-specific-ovs-bridge(with security group flows) \u003c-\u003e br-int ovs-bridge\n\nthe learn action based openflow security group driver we have for networking-ovs-dpdk currently installs its rules in the br-int but using a port specific would make debugging them much simplifier and should improve the performance vs using veth pairs/linux bridges even with standard ovs.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"1c07f91af56f9209597872c0ffe3df3ebe481739","unresolved":false,"context_lines":[{"line_number":68,"context_line":"The first part of the API extension is the logical topology portion.  First, we"},{"line_number":69,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":70,"context_line":"strictly necessary, but is included for convenience.  It allows Neutron to go"},{"line_number":71,"context_line":"ahead and reject the port creation if subports aren\u0027t supported by the backend."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"::"},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a8ffd7b_720a5223","line":71,"in_reply_to":"9a8ffd7b_b7d42c20","updated":"2015-11-25 20:11:57.000000000","message":"Simpler how? I am trying to explain that the \u0027simpler\u0027 API (to your eyes) will not lead to a cleaner API implementation and CLI support.\n\nBesides, why do you think that your proposal s simpler? Based on which criteria? If simplicity is a synonym of lack of clutter, you\u0027re adding clutter to an already cluttered resource (port) and CLI commands.\n\nYou have all the people interested in this spec and topic listening here with the context; Sean and Jay already commented on it. Not sure what difference a message on ML would make. Going down to a full-blown voting mechanism sounds like a waste of time.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"7df587b2ac6dffa907fc24597158a6ca60855767","unresolved":false,"context_lines":[{"line_number":68,"context_line":"The first part of the API extension is the logical topology portion.  First, we"},{"line_number":69,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":70,"context_line":"strictly necessary, but is included for convenience.  It allows Neutron to go"},{"line_number":71,"context_line":"ahead and reject the port creation if subports aren\u0027t supported by the backend."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"::"},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a8ffd7b_b7d42c20","line":71,"in_reply_to":"9a8ffd7b_efdc6248","updated":"2015-11-25 19:55:17.000000000","message":"Armando, no new resources just seems simpler to me.  I\u0027m not sure how to resolve this point of disagreement.  I could write up the two API approaches on the openstack-dev list and get reactions to which one makes more sense to people from an API usage perspective, I suppose?\n\n\n\"if this cannot be guaranteed then this will be very difficult to implement with ovs.\"  I\u0027m going to be super pedantic for a moment.  It\u0027s difficult for Neutron\u0027s OVS agent because of how it uses OVS, not difficult to do with OVS itself.  This is easy to handle using flows.  :-)\n\nRegarding the impact on the ovs agent, one solution would be to move to *always* creating a separate bridge per port.  In the common case, it would effectively just be a passthrough to br-int using patch ports.  I don\u0027t think the ovs side will have any real performance impact.  The downside is that it requires yet another veth pair to an already complex setup.  We would have VM \u003c-\u003e tap device \u003c-\u003e port-specific-ovs-bridge \u003c-\u003e veth pair \u003c-\u003e linux bridge for security groups iptables rules \u003c-\u003e veth pair \u003c-\u003e br-int ovs bridge... another way to look at this, if that setup is good enough for vlan-aware-vms, it should be good enough for all ports.  Otherwise, it\u0027s probably a bad idea, period.  This would at least let us get rid of the \"is_parent\" junk without making the ovs agent work any more difficult.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"d84d762e5c9b6d4057eb26d338f78c0e36b966c4","unresolved":false,"context_lines":[{"line_number":68,"context_line":"The first part of the API extension is the logical topology portion.  First, we"},{"line_number":69,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":70,"context_line":"strictly necessary, but is included for convenience.  It allows Neutron to go"},{"line_number":71,"context_line":"ahead and reject the port creation if subports aren\u0027t supported by the backend."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"::"},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_a530a308","line":71,"in_reply_to":"ba8a016a_45cbf772","updated":"2015-11-22 16:32:55.000000000","message":"Extension attributes can be attached to the resources they are associated to when the main resource is fetched, so an extra call should not be required. We do this extensively and there are hooks that allow that.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"a783cb65a3993e48855cce25b63c437cb21f36d8","unresolved":false,"context_lines":[{"line_number":68,"context_line":"The first part of the API extension is the logical topology portion.  First, we"},{"line_number":69,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":70,"context_line":"strictly necessary, but is included for convenience.  It allows Neutron to go"},{"line_number":71,"context_line":"ahead and reject the port creation if subports aren\u0027t supported by the backend."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"::"},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_eb263f15","line":71,"in_reply_to":"ba8a016a_5e3dd9b9","updated":"2015-11-24 02:03:51.000000000","message":"Russell, my suggestion is not going to bring us back closer to the original spec, because Nova will continue to see ports, which will be extended in case trunks are in use. I am suggesting this alternative because I believe it\u0027s going to less invasive. I am not NACK-ing because of matter of personal taste, but if you think I am wrong, please tell me so. You last comment reads like: it\u0027s either my way or no way...what\u0027s your rationale for proposing no new resources? I am trying to find a compromise that keeps everyone happy.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"f5bb385f1598a170a64794c38bf4eb86a953d933","unresolved":false,"context_lines":[{"line_number":68,"context_line":"The first part of the API extension is the logical topology portion.  First, we"},{"line_number":69,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":70,"context_line":"strictly necessary, but is included for convenience.  It allows Neutron to go"},{"line_number":71,"context_line":"ahead and reject the port creation if subports aren\u0027t supported by the backend."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"::"},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_87ebfc77","line":71,"in_reply_to":"ba8a016a_7d1b23cb","updated":"2015-11-23 16:57:14.000000000","message":"It would be for me, but I let someone from the nova team chime in on the necessity of a nova bp.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"7c08cd96a8c573240cf74ac3bac6742c0c97c483","unresolved":false,"context_lines":[{"line_number":68,"context_line":"The first part of the API extension is the logical topology portion.  First, we"},{"line_number":69,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":70,"context_line":"strictly necessary, but is included for convenience.  It allows Neutron to go"},{"line_number":71,"context_line":"ahead and reject the port creation if subports aren\u0027t supported by the backend."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"::"},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_f202f2b3","line":71,"in_reply_to":"ba8a016a_81823ac7","updated":"2015-11-22 03:02:52.000000000","message":"If you are not sold on having this information be an attribute of the port data model, would my suggestion on [1] (line 296), be something you\u0027d be happier with?\n\n[1] https://review.openstack.org/#/c/243786/4/specs/mitaka/vlan-aware-vms.rst","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"8c7a5eb4f51f5e14bef28279d409f5b877b918dc","unresolved":false,"context_lines":[{"line_number":68,"context_line":"The first part of the API extension is the logical topology portion.  First, we"},{"line_number":69,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":70,"context_line":"strictly necessary, but is included for convenience.  It allows Neutron to go"},{"line_number":71,"context_line":"ahead and reject the port creation if subports aren\u0027t supported by the backend."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"::"},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_5e3dd9b9","line":71,"in_reply_to":"ba8a016a_87ebfc77","updated":"2015-11-23 18:09:54.000000000","message":"I believe the only current nova impact is supporting neutron specifying a bridge name instead of only taking it from nova.conf.  Supporting this is in a TODO comment in the nova source, actually.  It seems like a pretty sane improvement on the nova side.\n\nRegarding is_parent, I actually don\u0027t like it.  I\u0027m fine with having another mechanism to discover whether the backend supports subports, or just fail when a subport is created.  Honestly, the real reason to have it is because without it, supporting this API in the ovs agent is going to be a lot more difficult.  I hate making the API worse for that reason, but it\u0027s a compromise worth considering.  It\u0027s the ovs agent\u0027s fault (not OVS fundamentally) that it\u0027s difficult.\n\nRegarding Armando\u0027s proposal in the last rev (I\u0027ll keep discussion here so we\u0027re not jumping between 2 revs), I feel like that brings us back closer to the original spec.  For the purpose of this version, I wanted to propose *not* requiring any new resource.  If you\u0027d like to NACK that, that\u0027s fine, and I\u0027ll just abandon this one.  Maybe I\u0027m misunderstanding the suggestion, though?","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"2497bc69479344f53ac36dd04504b945ce35562d","unresolved":false,"context_lines":[{"line_number":68,"context_line":"The first part of the API extension is the logical topology portion.  First, we"},{"line_number":69,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":70,"context_line":"strictly necessary, but is included for convenience.  It allows Neutron to go"},{"line_number":71,"context_line":"ahead and reject the port creation if subports aren\u0027t supported by the backend."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"::"},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_a825daae","line":71,"in_reply_to":"ba8a016a_a530a308","updated":"2015-11-22 16:42:27.000000000","message":"That said, your last statement makes me wonder if we have a full understanding on what\u0027s required nova-side and what would be the workflow when dealing with the use cases described. I don\u0027t see this articulated here very much. I personally think that it would be best if we captured all these details in a single spec (this one) and [1] be replaced by a simple pointer. Having to target two separate specs makes the design decision making process more cumbersome than it needs to be. \n\n[1] https://review.openstack.org/#/c/213644/","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"c41030c50473e7bdd5f18350a37a1772dd264278","unresolved":false,"context_lines":[{"line_number":68,"context_line":"The first part of the API extension is the logical topology portion.  First, we"},{"line_number":69,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":70,"context_line":"strictly necessary, but is included for convenience.  It allows Neutron to go"},{"line_number":71,"context_line":"ahead and reject the port creation if subports aren\u0027t supported by the backend."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"::"},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_7d1b23cb","line":71,"in_reply_to":"ba8a016a_a825daae","updated":"2015-11-23 13:05:47.000000000","message":"I have abandoned the previous nova bp/trunk-port with a pointer to this change.\n\nPlease see my questions regading the alternative API proposal in line 296.\n\nMy original intention with the extra nova bp was to discover the consequences on the nova workflow and implied nova changes when we had quite a lot of planned changes because of the new resource. Today we have several nova core members present in this review and two different design alternatives, both of them having less effect on nova. So I hope that this bp is sufficient without a standalone nova bp. Is that process okay for everybody?","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c6b5d8955e926d7178a80110f1fe674f311c114f","unresolved":false,"context_lines":[{"line_number":68,"context_line":"The first part of the API extension is the logical topology portion.  First, we"},{"line_number":69,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":70,"context_line":"strictly necessary, but is included for convenience.  It allows Neutron to go"},{"line_number":71,"context_line":"ahead and reject the port creation if subports aren\u0027t supported by the backend."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"::"},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a8ffd7b_efdc6248","line":71,"in_reply_to":"ba8a016a_eb263f15","updated":"2015-11-24 20:12:34.000000000","message":"i agree with Russell that passing the bridge name from neutron to nova makes alot of sense. the timing i would argue is also good as the os-vif library work is already trying to cleanup and plug and unplug logic in nova and it would be relatively easy to extend the plug drivers to read the bridge name from the vif binding details. \n\nArmando i have to admit i think i prefer your approch of encapultating the port relationship as a seperate entity provided, the api does not allow you to add a relationship, that would make a port a parent port, if it is currently attached to a vm and was not already a parent port when the vm was booted/interface attached.\n\nit is fine to add or remove a child port to/from a parent port at runtime provided \nthat during the lifetime of a vm the parenthood of a port is known and invariant  when the interface is attached to the vm.\n\nif this cannot be guaranteed then this will be very difficult to implement with ovs.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"8c9c11873dd569198c8f2a26777b27396f3d6c2f","unresolved":false,"context_lines":[{"line_number":68,"context_line":"The first part of the API extension is the logical topology portion.  First, we"},{"line_number":69,"context_line":"include a method to indicate that a port may have child ports.  This isn\u0027t"},{"line_number":70,"context_line":"strictly necessary, but is included for convenience.  It allows Neutron to go"},{"line_number":71,"context_line":"ahead and reject the port creation if subports aren\u0027t supported by the backend."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"::"},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_45cbf772","line":71,"in_reply_to":"ba8a016a_f202f2b3","updated":"2015-11-22 15:26:13.000000000","message":"Yes, it would, as long as it was not necessary for Nova to make two calls to Neutron in order to get all of the information about a (trunk) port instead of the single call to GET /ports/{port} that it currently does (via neutronclient of course).\n\nI\u0027m not against structuring the Neutron API for creating port -\u003e subport mappings in a way that makes more logical sense. What I\u0027m opposed to is having a special unicorn Neutron API call that must be used to grab the piece of information \"does this port have subports on it\".","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"5de0ceab696753c78ed4a33f283c38bb7016f3ea","unresolved":false,"context_lines":[{"line_number":75,"context_line":"    $ neutron port-create --subport:is_parent NETWORK"},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"Note that if a given plugin does not implement support for the subport API"},{"line_number":78,"context_line":"extension, this request will be rejected."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"Note that all example command lines are for demonstrating the concepts.  The"},{"line_number":81,"context_line":"exact syntax is subject to change."}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_2174aefb","line":78,"updated":"2015-11-21 18:57:38.000000000","message":"Yeah, I think it would be just as reasonable to reject the request to add a child port and not have the subport:is_parent attribute/switch at all.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"8c7a5eb4f51f5e14bef28279d409f5b877b918dc","unresolved":false,"context_lines":[{"line_number":75,"context_line":"    $ neutron port-create --subport:is_parent NETWORK"},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"Note that if a given plugin does not implement support for the subport API"},{"line_number":78,"context_line":"extension, this request will be rejected."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"Note that all example command lines are for demonstrating the concepts.  The"},{"line_number":81,"context_line":"exact syntax is subject to change."}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_7e58ddfa","line":78,"in_reply_to":"ba8a016a_2174aefb","updated":"2015-11-23 18:09:54.000000000","message":"Totally agreed.  The only issue is not knowing how we\u0027ll implement this in the OVS agent.\n\nFrom a purely selfish perspective, I don\u0027t care.  OVN (part of the OVS project and built on OVS) supports the model proposed by this spec and implements this without having to create a new OVS bridge per port.  The Neutron OVS agent could do the same, though it\u0027d be quite invasive.\n\nSo, to summarize, I\u0027m more than happy to remove \"is_parent\" because that\u0027s the \"right\" thing to do for the API, but supporting this feature in the OVS agent in the near term becomes much less likely as a result.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c6b5d8955e926d7178a80110f1fe674f311c114f","unresolved":false,"context_lines":[{"line_number":75,"context_line":"    $ neutron port-create --subport:is_parent NETWORK"},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"Note that if a given plugin does not implement support for the subport API"},{"line_number":78,"context_line":"extension, this request will be rejected."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"Note that all example command lines are for demonstrating the concepts.  The"},{"line_number":81,"context_line":"exact syntax is subject to change."}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a8ffd7b_2b41fd0b","line":78,"in_reply_to":"ba8a016a_7e58ddfa","updated":"2015-11-24 20:12:34.000000000","message":"as i said in my comment above provided we dont allow the \"parenthood\" of an interface to change while it is attached to a vm i dont think the --subport:is_parent is required in the ovs without ovn/odl case.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"5de0ceab696753c78ed4a33f283c38bb7016f3ea","unresolved":false,"context_lines":[{"line_number":87,"context_line":"    $ neutron port-create --subport:parent_id PARENT-PORT-ID NETWORK"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"If the Neutron backend does not support the subport API extension, this request"},{"line_number":90,"context_line":"will be rejected."},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"In addition to the logical topology piece, we need to define the type of"},{"line_number":93,"context_line":"encapsulation used between the hypervisor and VM for targeting packets to a"}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_e164664a","line":90,"updated":"2015-11-21 18:57:38.000000000","message":"Yes, this.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"5de0ceab696753c78ed4a33f283c38bb7016f3ea","unresolved":false,"context_lines":[{"line_number":118,"context_line":"destination logical port over a single VIF."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Subport details are also expected to be exposed to VMs via the Nova metadata"},{"line_number":121,"context_line":"service, though the details will most likely be tackled in a follow-up spec."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Example logical model::"},{"line_number":124,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_e1cb061d","line":121,"updated":"2015-11-21 18:57:38.000000000","message":"See here for ideas on how to expose this kind of information: \n\nhttps://review.openstack.org/#/c/195662/\n\nThat is for passing generic tags and other device information to the VM, but you could use it as a template for the above proposed metadata enhancements.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"8c7a5eb4f51f5e14bef28279d409f5b877b918dc","unresolved":false,"context_lines":[{"line_number":118,"context_line":"destination logical port over a single VIF."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Subport details are also expected to be exposed to VMs via the Nova metadata"},{"line_number":121,"context_line":"service, though the details will most likely be tackled in a follow-up spec."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Example logical model::"},{"line_number":124,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_fe036db6","line":121,"in_reply_to":"ba8a016a_e1cb061d","updated":"2015-11-23 18:09:54.000000000","message":"Thanks, Jay.  I\u0027ll add this as a reference if/when I rev this again.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"c41030c50473e7bdd5f18350a37a1772dd264278","unresolved":false,"context_lines":[{"line_number":118,"context_line":"destination logical port over a single VIF."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Subport details are also expected to be exposed to VMs via the Nova metadata"},{"line_number":121,"context_line":"service, though the details will most likely be tackled in a follow-up spec."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Example logical model::"},{"line_number":124,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_da2a4be7","line":121,"in_reply_to":"ba8a016a_e1cb061d","updated":"2015-11-23 13:05:47.000000000","message":"Thanks.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ffa0ce50ccf1d0c6b303ab61f8083bdd47c4323a","unresolved":false,"context_lines":[{"line_number":118,"context_line":"destination logical port over a single VIF."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Subport details are also expected to be exposed to VMs via the Nova metadata"},{"line_number":121,"context_line":"service, though the details will most likely be tackled in a follow-up spec."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Example logical model::"},{"line_number":124,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a8ffd7b_eefff6fe","line":121,"in_reply_to":"ba8a016a_fe036db6","updated":"2015-12-03 00:39:10.000000000","message":"+1\ni rather like that mechanism as a way \nto convey this kind of information to the guest.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"5de0ceab696753c78ed4a33f283c38bb7016f3ea","unresolved":false,"context_lines":[{"line_number":171,"context_line":"-----------"},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"* A top level port that may have child ports added must be marked with"},{"line_number":174,"context_line":"  subport:is_parent set to True."},{"line_number":175,"context_line":""},{"line_number":176,"context_line":"* The API supports multiple levels of nesting ports.  Implementations may reject"},{"line_number":177,"context_line":"  the request based on backend specific restrictions, though.  For example, if"}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_e1f2266f","line":174,"updated":"2015-11-21 18:57:38.000000000","message":"I\u0027m cool *returning* this data in the GET /ports/{port} API call. However, as mentioned above, I don\u0027t believe it should be an attribute that should be *settable* on the POST /ports API call.\n\nPerhaps, if I could be so bold, you could rename this read-only attribute to:\n\n subports:has_children\n\nor:\n\n subports:has_subports","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"f5bb385f1598a170a64794c38bf4eb86a953d933","unresolved":false,"context_lines":[{"line_number":171,"context_line":"-----------"},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"* A top level port that may have child ports added must be marked with"},{"line_number":174,"context_line":"  subport:is_parent set to True."},{"line_number":175,"context_line":""},{"line_number":176,"context_line":"* The API supports multiple levels of nesting ports.  Implementations may reject"},{"line_number":177,"context_line":"  the request based on backend specific restrictions, though.  For example, if"}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_2726d0ce","line":174,"in_reply_to":"ba8a016a_1aad3388","updated":"2015-11-23 16:57:14.000000000","message":"IMO, if we followed my suggestion of keeping the base port model pristine, is_parent can be treated as an extension attribute, the same way we treat the other extension attributes for other resources, and I see no sacrifices to be made.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"c41030c50473e7bdd5f18350a37a1772dd264278","unresolved":false,"context_lines":[{"line_number":171,"context_line":"-----------"},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"* A top level port that may have child ports added must be marked with"},{"line_number":174,"context_line":"  subport:is_parent set to True."},{"line_number":175,"context_line":""},{"line_number":176,"context_line":"* The API supports multiple levels of nesting ports.  Implementations may reject"},{"line_number":177,"context_line":"  the request based on backend specific restrictions, though.  For example, if"}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_1aad3388","line":174,"in_reply_to":"ba8a016a_e1f2266f","updated":"2015-11-23 13:05:47.000000000","message":"I don\u0027t see the point of having a get-only trunk port marker. Do we have a use case for that?\n\nWe have no optimal solution, but a trade-off between:\n\na) one port attr present in the API because it leaked from the implementation, but a significantly simpler change in ovs-agent, therefore much better guarantee of backward compatible behavior for plain old ports\n\nb) flawless API, but huge change in ovs-agent (maybe other agents too, I don\u0027t know), therefore less certain backward compatibility for plain old ports\n\nWhere do we want to make the sacrifice?","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"5de0ceab696753c78ed4a33f283c38bb7016f3ea","unresolved":false,"context_lines":[{"line_number":179,"context_line":"  QinQ support, which OVS does not yet support (though is very close to"},{"line_number":180,"context_line":"  supporting)."},{"line_number":181,"context_line":""},{"line_number":182,"context_line":"* Every subport of a given parent should have unique VID among its"},{"line_number":183,"context_line":"  siblings.  Otherwise, it\u0027s not possible to properly differentiate"},{"line_number":184,"context_line":"  the source and destination logical port."},{"line_number":185,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_21f90e4e","line":182,"updated":"2015-11-21 18:57:38.000000000","message":"s/VID/segmentation_id value/","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ffa0ce50ccf1d0c6b303ab61f8083bdd47c4323a","unresolved":false,"context_lines":[{"line_number":179,"context_line":"  QinQ support, which OVS does not yet support (though is very close to"},{"line_number":180,"context_line":"  supporting)."},{"line_number":181,"context_line":""},{"line_number":182,"context_line":"* Every subport of a given parent should have unique VID among its"},{"line_number":183,"context_line":"  siblings.  Otherwise, it\u0027s not possible to properly differentiate"},{"line_number":184,"context_line":"  the source and destination logical port."},{"line_number":185,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a8ffd7b_ee37f6ad","line":182,"in_reply_to":"9a8ffd7b_97afa893","updated":"2015-12-03 00:39:10.000000000","message":"yes this makes sense  thanks.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"7df587b2ac6dffa907fc24597158a6ca60855767","unresolved":false,"context_lines":[{"line_number":179,"context_line":"  QinQ support, which OVS does not yet support (though is very close to"},{"line_number":180,"context_line":"  supporting)."},{"line_number":181,"context_line":""},{"line_number":182,"context_line":"* Every subport of a given parent should have unique VID among its"},{"line_number":183,"context_line":"  siblings.  Otherwise, it\u0027s not possible to properly differentiate"},{"line_number":184,"context_line":"  the source and destination logical port."},{"line_number":185,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a8ffd7b_97afa893","line":182,"in_reply_to":"9a8ffd7b_ee3f8323","updated":"2015-11-25 19:55:17.000000000","message":"segmentation_id here is the subport:segmentation_id, or the one seen by the guest to identify traffic to/from the subport.\n\nYes, the API proposal leaves room to support other encapsulation types for segmenting subport traffic.  MPLS is a good example.\n\nYou can have 2 subports connected to the same neutron network.  Each would use a different subport segmentation_id, because we still need to differentiate the traffic to/from each individual port.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"8c7a5eb4f51f5e14bef28279d409f5b877b918dc","unresolved":false,"context_lines":[{"line_number":179,"context_line":"  QinQ support, which OVS does not yet support (though is very close to"},{"line_number":180,"context_line":"  supporting)."},{"line_number":181,"context_line":""},{"line_number":182,"context_line":"* Every subport of a given parent should have unique VID among its"},{"line_number":183,"context_line":"  siblings.  Otherwise, it\u0027s not possible to properly differentiate"},{"line_number":184,"context_line":"  the source and destination logical port."},{"line_number":185,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_bed3a537","line":182,"in_reply_to":"ba8a016a_21f90e4e","updated":"2015-11-23 18:09:54.000000000","message":"Thanks!","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c6b5d8955e926d7178a80110f1fe674f311c114f","unresolved":false,"context_lines":[{"line_number":179,"context_line":"  QinQ support, which OVS does not yet support (though is very close to"},{"line_number":180,"context_line":"  supporting)."},{"line_number":181,"context_line":""},{"line_number":182,"context_line":"* Every subport of a given parent should have unique VID among its"},{"line_number":183,"context_line":"  siblings.  Otherwise, it\u0027s not possible to properly differentiate"},{"line_number":184,"context_line":"  the source and destination logical port."},{"line_number":185,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a8ffd7b_ee3f8323","line":182,"in_reply_to":"ba8a016a_bed3a537","updated":"2015-11-24 20:12:34.000000000","message":"when we say segmentation_id value in this context are we refering to the vlan_id as seen by the guest or to the segmentation_id of the neutron network.\n\ni believe we are referring to the vlan id as seen by the guest correct?\n\nand in that context jay comment of changing from VID to segmentation_id value is reflecting the fact that in the future we may support other encapulation types like MPLS for example. is that correct?\n\nor is that a limitation saying i cant have two support on the connected to the same parent port on the same neutron network?","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"5de0ceab696753c78ed4a33f283c38bb7016f3ea","unresolved":false,"context_lines":[{"line_number":183,"context_line":"  siblings.  Otherwise, it\u0027s not possible to properly differentiate"},{"line_number":184,"context_line":"  the source and destination logical port."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":"* The parent port handles \"untagged\" traffic. The parent will receive all the"},{"line_number":187,"context_line":"  packets that do not match a sub-port, which is no different than how a regular"},{"line_number":188,"context_line":"  port already behaves today.  This also means that every VM has a port for"},{"line_number":189,"context_line":"  untagged traffic.  It doesn\u0027t necessarily have to be used though and could be"}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_4189b2c9","line":186,"updated":"2015-11-21 18:57:38.000000000","message":"In the case of multiple levels of nested ports, only the \"root port\" would handle untagged traffic, right?","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"8c7a5eb4f51f5e14bef28279d409f5b877b918dc","unresolved":false,"context_lines":[{"line_number":183,"context_line":"  siblings.  Otherwise, it\u0027s not possible to properly differentiate"},{"line_number":184,"context_line":"  the source and destination logical port."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":"* The parent port handles \"untagged\" traffic. The parent will receive all the"},{"line_number":187,"context_line":"  packets that do not match a sub-port, which is no different than how a regular"},{"line_number":188,"context_line":"  port already behaves today.  This also means that every VM has a port for"},{"line_number":189,"context_line":"  untagged traffic.  It doesn\u0027t necessarily have to be used though and could be"}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_3ee815e2","line":186,"in_reply_to":"ba8a016a_4189b2c9","updated":"2015-11-23 18:09:54.000000000","message":"correct.  I can add a clarification about that.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c6b5d8955e926d7178a80110f1fe674f311c114f","unresolved":false,"context_lines":[{"line_number":191,"context_line":"  security group set on the parent port to drop all incoming and outgoing"},{"line_number":192,"context_line":"  traffic.  A future enhancement could include the ability to create a Neutron"},{"line_number":193,"context_line":"  port not yet attached to a network, though it\u0027s unclear how valuable that"},{"line_number":194,"context_line":"  actually is."},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"* A port with a parent logically inherits its binding:host_id from its parent."},{"line_number":197,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a8ffd7b_ce74fffe","line":194,"updated":"2015-11-24 20:12:34.000000000","message":"having a neutron port not attached to a network might be useful if the neutron api allow port to be move between neutron networks.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"da76993e66554c00b643d049fd5acd31ab0d3600","unresolved":false,"context_lines":[{"line_number":193,"context_line":"  port not yet attached to a network, though it\u0027s unclear how valuable that"},{"line_number":194,"context_line":"  actually is."},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"* A port with a parent logically inherits its binding:host_id from its parent."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"* If binding:host_id is updated (by booting a Nova VM with a subport UUID, for"},{"line_number":199,"context_line":"  example) the port will become a top level port.  subport:parent_id,"}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_6e234ca8","line":196,"updated":"2015-11-23 18:58:44.000000000","message":"I wouldn\u0027t be opposed to this being left blank to avoid the cascading update issue.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"54bf814361d6dced0f7b3b83ff7385dff0338fc3","unresolved":false,"context_lines":[{"line_number":193,"context_line":"  port not yet attached to a network, though it\u0027s unclear how valuable that"},{"line_number":194,"context_line":"  actually is."},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"* A port with a parent logically inherits its binding:host_id from its parent."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"* If binding:host_id is updated (by booting a Nova VM with a subport UUID, for"},{"line_number":199,"context_line":"  example) the port will become a top level port.  subport:parent_id,"}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_ce5598c6","line":196,"in_reply_to":"ba8a016a_6e234ca8","updated":"2015-11-23 19:03:21.000000000","message":"On second thought, that might be invasive to normal port binding. How about setting it to the ID of the parent port?","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"7df587b2ac6dffa907fc24597158a6ca60855767","unresolved":false,"context_lines":[{"line_number":193,"context_line":"  port not yet attached to a network, though it\u0027s unclear how valuable that"},{"line_number":194,"context_line":"  actually is."},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"* A port with a parent logically inherits its binding:host_id from its parent."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"* If binding:host_id is updated (by booting a Nova VM with a subport UUID, for"},{"line_number":199,"context_line":"  example) the port will become a top level port.  subport:parent_id,"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a8ffd7b_b7898c28","line":196,"in_reply_to":"ba8a016a_ce5598c6","updated":"2015-11-25 19:55:17.000000000","message":"Sure, that\u0027s fine with me.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c6b5d8955e926d7178a80110f1fe674f311c114f","unresolved":false,"context_lines":[{"line_number":219,"context_line":"a new OVS bridge per parent port.  That would require an enhancement to the"},{"line_number":220,"context_line":"existing OVS VIF type support in Nova to allow Neutron to tell Nova the name of"},{"line_number":221,"context_line":"the bridge to use for the port.  Currently, Nova only supports a single bridge"},{"line_number":222,"context_line":"name provided by the Nova configuration file."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"Alternatives"},{"line_number":225,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a8ffd7b_5188b0e7","line":222,"updated":"2015-11-24 20:12:34.000000000","message":"passing the bridge name from neutron would make the interaction between nova and neutron more robust. \n\nthe os_vif work will make this simpler also but at present\nin the standard ovs case when i hybrid plug or vhost-user are used there is a vif plug method which handle plugging the interface into the ovs bridge. in the non hybrid plug case the interface is pluged by libvirt. \n\nto make things more consistent it might makes to not use libvirts support for plugging interfaces into ovs and just delegate that entirely to the (un)plug* methods.\n\nin both the current implementation / os_vif implementation it seam like it would be relatively simple to read the bridge name from the vif details instead of the nova conf.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"7df587b2ac6dffa907fc24597158a6ca60855767","unresolved":false,"context_lines":[{"line_number":219,"context_line":"a new OVS bridge per parent port.  That would require an enhancement to the"},{"line_number":220,"context_line":"existing OVS VIF type support in Nova to allow Neutron to tell Nova the name of"},{"line_number":221,"context_line":"the bridge to use for the port.  Currently, Nova only supports a single bridge"},{"line_number":222,"context_line":"name provided by the Nova configuration file."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"Alternatives"},{"line_number":225,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a8ffd7b_57a06090","line":222,"in_reply_to":"9a8ffd7b_5188b0e7","updated":"2015-11-25 19:55:17.000000000","message":"I believe the vif code actually already reads the bridge name from a vif details object.  The neutron interface code in Nova just populates it from nova.conf instead of from data from Neutron.  I think it\u0027s a *really* small patch to add this.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"5de0ceab696753c78ed4a33f283c38bb7016f3ea","unresolved":false,"context_lines":[{"line_number":233,"context_line":""},{"line_number":234,"context_line":"* It is my gut feeling that this proposal will result in a simpler"},{"line_number":235,"context_line":"  implementation that requires less code, though that will have to be proven"},{"line_number":236,"context_line":"  with code, which I\u0027d like to help with to help move things along."},{"line_number":237,"context_line":"* No changes are required to any project that handles VIF port"},{"line_number":238,"context_line":"  bindings, such as Nova, since a parent port is just a regular Neutron"},{"line_number":239,"context_line":"  port resource.  As discussed in the \"Nova changes\" section above, some"}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_e1c0e6e2","line":236,"updated":"2015-11-21 18:57:38.000000000","message":"++ I share this opinion.","commit_id":"45bc49bdb244fd98d529be21eb140d837ef9c96e"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"3d59d4eea3fab4032763e2854c5b9fde6f0e3e34","unresolved":false,"context_lines":[{"line_number":14,"context_line":""},{"line_number":15,"context_line":"This blueprint proposes how to incorporate VLAN aware VMs into"},{"line_number":16,"context_line":"OpenStack. In this document a VLAN aware VM is a VM that sends and receives"},{"line_number":17,"context_line":"VLAN tagged frames over its vNIC. Pros are better scalability and more"},{"line_number":18,"context_line":"dynamic handling of Neutron networks connected to VMs."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_8c243cc5","line":17,"updated":"2015-12-08 18:42:40.000000000","message":"A petty point: by that definition, VLAN aware VMs work in Openstack today.  Your definition is more \u0027VMs that can use VLAN tagged packets and Openstack support to tag those packets up\u0027.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"5f276ecbccf757d2babd14285593593a2b41b7de","unresolved":false,"context_lines":[{"line_number":14,"context_line":""},{"line_number":15,"context_line":"This blueprint proposes how to incorporate VLAN aware VMs into"},{"line_number":16,"context_line":"OpenStack. In this document a VLAN aware VM is a VM that sends and receives"},{"line_number":17,"context_line":"VLAN tagged frames over its vNIC. Pros are better scalability and more"},{"line_number":18,"context_line":"dynamic handling of Neutron networks connected to VMs."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_441c876a","line":17,"in_reply_to":"7a740942_8c243cc5","updated":"2015-12-10 10:48:21.000000000","message":"I agree. At one point I wanted to change much of this text to talk about trunk ports instead of vlan aware vms and generally get rid of the notion that vlans are required here. I was told to leave it, because this is how people are already familiar with the subject.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"3d59d4eea3fab4032763e2854c5b9fde6f0e3e34","unresolved":false,"context_lines":[{"line_number":36,"context_line":"  Neutron networks.  It is more practical to use a single or other small number"},{"line_number":37,"context_line":"  of VIFs and VLANs to differentiate traffic for each network than to have"},{"line_number":38,"context_line":"  hundreds of VIFs per VM."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"* Cloud workloads are often very dynamic.  It may be more efficient and/or less"},{"line_number":41,"context_line":"  complex to add/remove VLANs than to hotplug interfaces in a VM."},{"line_number":42,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_0c1fec6c","line":39,"updated":"2015-12-08 18:42:40.000000000","message":"To add to this: generally, hypervisors will run out of supported VIFs long before this.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"5f276ecbccf757d2babd14285593593a2b41b7de","unresolved":false,"context_lines":[{"line_number":36,"context_line":"  Neutron networks.  It is more practical to use a single or other small number"},{"line_number":37,"context_line":"  of VIFs and VLANs to differentiate traffic for each network than to have"},{"line_number":38,"context_line":"  hundreds of VIFs per VM."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"* Cloud workloads are often very dynamic.  It may be more efficient and/or less"},{"line_number":41,"context_line":"  complex to add/remove VLANs than to hotplug interfaces in a VM."},{"line_number":42,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_645e6314","line":39,"in_reply_to":"7a740942_0c1fec6c","updated":"2015-12-10 10:48:21.000000000","message":"Exactly. This is the gist of the spec, to overcome the limitations of the one vnic per one network model. I will add this more explicitly in the next patch set.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"897ba1cb1ff2101aecf2b658ddc336d21f6e5979","unresolved":false,"context_lines":[{"line_number":36,"context_line":"  Neutron networks.  It is more practical to use a single or other small number"},{"line_number":37,"context_line":"  of VIFs and VLANs to differentiate traffic for each network than to have"},{"line_number":38,"context_line":"  hundreds of VIFs per VM."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"* Cloud workloads are often very dynamic.  It may be more efficient and/or less"},{"line_number":41,"context_line":"  complex to add/remove VLANs than to hotplug interfaces in a VM."},{"line_number":42,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_81743a9c","line":39,"in_reply_to":"7a740942_2677cea0","updated":"2015-12-11 04:53:44.000000000","message":"The hypervisor will run out of supported VIFs? Really? I *did* not know that :)","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"6a46ee65727abce59932242c659d11a1ed98f0e7","unresolved":false,"context_lines":[{"line_number":36,"context_line":"  Neutron networks.  It is more practical to use a single or other small number"},{"line_number":37,"context_line":"  of VIFs and VLANs to differentiate traffic for each network than to have"},{"line_number":38,"context_line":"  hundreds of VIFs per VM."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"* Cloud workloads are often very dynamic.  It may be more efficient and/or less"},{"line_number":41,"context_line":"  complex to add/remove VLANs than to hotplug interfaces in a VM."},{"line_number":42,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_2677cea0","line":39,"in_reply_to":"7a740942_645e6314","updated":"2015-12-10 11:28:42.000000000","message":"I\u0027m pretty sure all the people reviewing this spec are aware of this, but adding it won\u0027t do any harm for sure!","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"897ba1cb1ff2101aecf2b658ddc336d21f6e5979","unresolved":false,"context_lines":[{"line_number":40,"context_line":"* Cloud workloads are often very dynamic.  It may be more efficient and/or less"},{"line_number":41,"context_line":"  complex to add/remove VLANs than to hotplug interfaces in a VM."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"* A VM could be moved from one network to another without detaching the VIF"},{"line_number":44,"context_line":"  from the VM."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"* Admin controlled service VMs could use this to provide service to many tenant"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_c1b9e22f","line":43,"updated":"2015-12-11 04:53:44.000000000","message":"strictly speaking you\u0027re not moving the VM, you\u0027re just funnelling traffic to/from one network to another.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"3d59d4eea3fab4032763e2854c5b9fde6f0e3e34","unresolved":false,"context_lines":[{"line_number":41,"context_line":"  complex to add/remove VLANs than to hotplug interfaces in a VM."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"* A VM could be moved from one network to another without detaching the VIF"},{"line_number":44,"context_line":"  from the VM."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"* Admin controlled service VMs could use this to provide service to many tenant"},{"line_number":47,"context_line":"  networks."}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_9f06a01a","line":44,"updated":"2015-12-08 18:42:40.000000000","message":"Doesn\u0027t require VLAN aware VMs, in fact, though I see the point you\u0027re making.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47cc480aee64c04489a304e53763c982bf15823c","unresolved":false,"context_lines":[{"line_number":41,"context_line":"  complex to add/remove VLANs than to hotplug interfaces in a VM."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"* A VM could be moved from one network to another without detaching the VIF"},{"line_number":44,"context_line":"  from the VM."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"* Admin controlled service VMs could use this to provide service to many tenant"},{"line_number":47,"context_line":"  networks."}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_c3360ab4","line":44,"in_reply_to":"7a740942_9f06a01a","updated":"2015-12-10 08:52:50.000000000","message":"I actually raised this on the last revision. This stems from some customer asks for a way to move legacy nfv appliance between networks  that was vlan aware but did not tolerate pci hotplug. As they did not share the applience in question it is my understanding it could be dynaically configured to manage new vlans at runtime but not addtional interfaces. This is also related to the previous point as they also wanted to the current appliance instance to provided a service to additional networks when they were created without having to restart the appliance to add a new interface.  \n\nStrictly speaking moveing a vm interface between neutron networks without hotplug does not require vlan awareness but it is a usecase that is enabled by the current spec that i cant currently do today via an openstack api.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"6a46ee65727abce59932242c659d11a1ed98f0e7","unresolved":false,"context_lines":[{"line_number":44,"context_line":"  from the VM."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"* Admin controlled service VMs could use this to provide service to many tenant"},{"line_number":47,"context_line":"  networks."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"* A VM may be running many containers. Each container may have requirements to"},{"line_number":50,"context_line":"  be connected to different Neutron networks. Assigning a VLAN id for each"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_466c5a9c","line":47,"updated":"2015-12-10 11:28:42.000000000","message":"This seems the same as the second bullet, albeit rephrased... That\u0027s ok, but not really adding a distinct use case.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"897ba1cb1ff2101aecf2b658ddc336d21f6e5979","unresolved":false,"context_lines":[{"line_number":44,"context_line":"  from the VM."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"* Admin controlled service VMs could use this to provide service to many tenant"},{"line_number":47,"context_line":"  networks."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"* A VM may be running many containers. Each container may have requirements to"},{"line_number":50,"context_line":"  be connected to different Neutron networks. Assigning a VLAN id for each"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_a185b659","line":47,"in_reply_to":"7a740942_466c5a9c","updated":"2015-12-11 04:53:44.000000000","message":"indeed, even though I see the previous bullet as tenant move VM within networks he/she owns, whereas here, the Admin is the actor?","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":6598,"name":"Berezovsky Irena","email":"irenab.dev@gmail.com","username":"irenab"},"change_message_id":"e41c2c065eddc1a17e10c0ded3e7b2d6ba34a098","unresolved":false,"context_lines":[{"line_number":48,"context_line":""},{"line_number":49,"context_line":"* A VM may be running many containers. Each container may have requirements to"},{"line_number":50,"context_line":"  be connected to different Neutron networks. Assigning a VLAN id for each"},{"line_number":51,"context_line":"  container is more efficient and scalable than requiring a VIF per container."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"The proposal may look related in some sense to the VLAN-transparent"},{"line_number":54,"context_line":"approach [1], but differs in that it doesn\u0027t provide a way to send opaque"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_e4a610ad","line":51,"updated":"2015-12-08 15:52:54.000000000","message":"Later in the spec you have support for various segmentation types. I think it should be mentioned in this section and not being VLAN specific","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"897ba1cb1ff2101aecf2b658ddc336d21f6e5979","unresolved":false,"context_lines":[{"line_number":48,"context_line":""},{"line_number":49,"context_line":"* A VM may be running many containers. Each container may have requirements to"},{"line_number":50,"context_line":"  be connected to different Neutron networks. Assigning a VLAN id for each"},{"line_number":51,"context_line":"  container is more efficient and scalable than requiring a VIF per container."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"The proposal may look related in some sense to the VLAN-transparent"},{"line_number":54,"context_line":"approach [1], but differs in that it doesn\u0027t provide a way to send opaque"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_615b4ef7","line":51,"in_reply_to":"7a740942_e45b33f5","updated":"2015-12-11 04:53:44.000000000","message":"The use of vlans is so pervasive in this spec that I wonder why we want to make the segmentation type parametric.  I\u0027d vote to prune it, and add it later on if need be.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"5f276ecbccf757d2babd14285593593a2b41b7de","unresolved":false,"context_lines":[{"line_number":48,"context_line":""},{"line_number":49,"context_line":"* A VM may be running many containers. Each container may have requirements to"},{"line_number":50,"context_line":"  be connected to different Neutron networks. Assigning a VLAN id for each"},{"line_number":51,"context_line":"  container is more efficient and scalable than requiring a VIF per container."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"The proposal may look related in some sense to the VLAN-transparent"},{"line_number":54,"context_line":"approach [1], but differs in that it doesn\u0027t provide a way to send opaque"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_e45b33f5","line":51,"in_reply_to":"7a740942_e4a610ad","updated":"2015-12-10 10:48:21.000000000","message":"Will add it here too in the next patch set.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"3d59d4eea3fab4032763e2854c5b9fde6f0e3e34","unresolved":false,"context_lines":[{"line_number":59,"context_line":"Proposed Change"},{"line_number":60,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"The proposal keeps the port resource unchanged."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"::"},{"line_number":65,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_cec3ea36","line":62,"updated":"2015-12-08 18:42:40.000000000","message":"Per the below, you probably need some reasoning why you\u0027ve chosen to use additional whole objects in the REST API rather than add attributes to ports.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"897ba1cb1ff2101aecf2b658ddc336d21f6e5979","unresolved":false,"context_lines":[{"line_number":65,"context_line":""},{"line_number":66,"context_line":"    $ neutron port-create NETWORK"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"For the new API extension this draft lists two minor alternatives, having the"},{"line_number":69,"context_line":"exact same meaning, but being syntactically little different:"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"#. Having two new resources [ alt-two-resources ]:"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_219f8651","line":68,"updated":"2015-12-11 04:53:44.000000000","message":"drafting the two alternatives is really confusing, pick one and stick to it please.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"dfe9bb9d7207ceeddc7f272598d7aa61a6793cd0","unresolved":false,"context_lines":[{"line_number":71,"context_line":"#. Having two new resources [ alt-two-resources ]:"},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"    * One trunk resource"},{"line_number":74,"context_line":"    * One subport resource"},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"#. One new resource with member_actions [ alt-one-resource ]:"},{"line_number":77,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_3ca8dd8c","line":74,"updated":"2015-12-08 00:34:57.000000000","message":"From an API standpoint, I don\u0027t believe we need a new sub-port resource.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"6a46ee65727abce59932242c659d11a1ed98f0e7","unresolved":false,"context_lines":[{"line_number":71,"context_line":"#. Having two new resources [ alt-two-resources ]:"},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"    * One trunk resource"},{"line_number":74,"context_line":"    * One subport resource"},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"#. One new resource with member_actions [ alt-one-resource ]:"},{"line_number":77,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_26bd8ed7","line":74,"in_reply_to":"7a740942_039f3260","updated":"2015-12-10 11:28:42.000000000","message":"My view is that you either have the trunk and attach ports to it, or the subport and connect them to a \"master\" port.\n\nI struggle to see the point for both a trunk and a subport resource.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"3003e7eed755124c962bf69af804678235355bb2","unresolved":false,"context_lines":[{"line_number":71,"context_line":"#. Having two new resources [ alt-two-resources ]:"},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"    * One trunk resource"},{"line_number":74,"context_line":"    * One subport resource"},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"#. One new resource with member_actions [ alt-one-resource ]:"},{"line_number":77,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_3b85a358","line":74,"in_reply_to":"7a740942_26bd8ed7","updated":"2015-12-10 14:26:44.000000000","message":"The point is that if we were talking about relations DB schemes, alt-two-resources would be normal form. With the advantages of the schema being normalized.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"897ba1cb1ff2101aecf2b658ddc336d21f6e5979","unresolved":false,"context_lines":[{"line_number":71,"context_line":"#. Having two new resources [ alt-two-resources ]:"},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"    * One trunk resource"},{"line_number":74,"context_line":"    * One subport resource"},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"#. One new resource with member_actions [ alt-one-resource ]:"},{"line_number":77,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_c176c23d","line":74,"in_reply_to":"7a740942_3b85a358","updated":"2015-12-11 04:53:44.000000000","message":"Let me try to explain this with an example:\n\nThink router: the router is your trunk, the gateway is like your parent port, the interfaces are your subports. Look at l3 and find your answers. Only router is a resource. Nothing else.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47cc480aee64c04489a304e53763c982bf15823c","unresolved":false,"context_lines":[{"line_number":71,"context_line":"#. Having two new resources [ alt-two-resources ]:"},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"    * One trunk resource"},{"line_number":74,"context_line":"    * One subport resource"},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"#. One new resource with member_actions [ alt-one-resource ]:"},{"line_number":77,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_039f3260","line":74,"in_reply_to":"7a740942_3ca8dd8c","updated":"2015-12-10 08:52:50.000000000","message":"from an API standpoint are you suggesting using an attribute on the trunk port resource (parent/child) \nto distinguish between trunk and subports or is this a preference for the second alternative below e.g. representing subports as standard neutron ports that are referenced as subports from the trunk if the subport resource is removed?","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"6a46ee65727abce59932242c659d11a1ed98f0e7","unresolved":false,"context_lines":[{"line_number":77,"context_line":""},{"line_number":78,"context_line":"    * One trunk resource"},{"line_number":79,"context_line":"    * Subports encoded in an attribute of the trunk, added and removed by"},{"line_number":80,"context_line":"      member_actions"},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"The proposal is to add an API extension to turn already existing ports"},{"line_number":83,"context_line":"into trunk and subports.  The best way to think about this is that"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_66d636f3","line":80,"updated":"2015-12-10 11:28:42.000000000","message":"The member actions are probably unnecessary, I\u0027d rather set the trunk on the subport, and maybe allow to link all the subports on a trunk.\n\nJust saying this because there is some debate in the API wg about whether OpenStack APIs should do member actions, and if yes how.\nMy feeling is that if there is a solution without member actions I\u0027d adopt it.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":6558,"name":"Sukhdev Kapur","email":"sukhdevkapur@gmail.com","username":"sukhdev-8"},"change_message_id":"e14441ca9008226d4a79b3d3eb84f6cc3fbe11d2","unresolved":false,"context_lines":[{"line_number":78,"context_line":"    * One trunk resource"},{"line_number":79,"context_line":"    * Subports encoded in an attribute of the trunk, added and removed by"},{"line_number":80,"context_line":"      member_actions"},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"The proposal is to add an API extension to turn already existing ports"},{"line_number":83,"context_line":"into trunk and subports.  The best way to think about this is that"},{"line_number":84,"context_line":"Neutron needs a method to describe a logical topology such that you have a"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_0e1b1982","line":81,"updated":"2015-12-09 06:20:26.000000000","message":"How does port binding work in this model? \nCan you please explain/add - for either of these models","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"5f276ecbccf757d2babd14285593593a2b41b7de","unresolved":false,"context_lines":[{"line_number":78,"context_line":"    * One trunk resource"},{"line_number":79,"context_line":"    * Subports encoded in an attribute of the trunk, added and removed by"},{"line_number":80,"context_line":"      member_actions"},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"The proposal is to add an API extension to turn already existing ports"},{"line_number":83,"context_line":"into trunk and subports.  The best way to think about this is that"},{"line_number":84,"context_line":"Neutron needs a method to describe a logical topology such that you have a"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_3fa5c5b4","line":81,"in_reply_to":"7a740942_0e1b1982","updated":"2015-12-10 10:48:21.000000000","message":"That\u0027s a good question. I shall add some of this to the next patch set.\n\nThe spec intentionally avoids the concept of a trunk network, therefore a parent port with all its children must exist on the same host.\n\nBinding involves setting up and/or checking multiple relations (port-host, port-segment, port-vif type), which we\u0027ll likely divide into two parts.\n\nThe first part is the placement of a port on a host. When binding:host_id is set for the top level parent port, it must mean that all children ports are placed on the same host too.\n\nIf a (currently) top level port already bound to a host is added as a child to another trunk, I believe we should reject that.\n\nFor the implementation of cascading the host placement we have several options:\n\n1) An update to the top level port, calls port_update internally in neutron-server to all children ports one by one. The fact that the children ports are placed on the same host as the parent may be expressed in different ways, I don\u0027t remember reaching conclusion:\n\n1.1.a) The binding:host_id attribute of the children are left empty.\n\n1.1.b) The binding:host_id attribute of the children are left as they are, they contain duplicated info on binding.\n\n1.1.c) The binding:host_id attribute of the children get a special getter/setter. The getter returns the parents value. The setter raises an error.\n\n1.2) As Kevin Benton suggested we could add some info into the binding:vif_details of the ports referred as subports. That would mean implicit port update operations when we update subports (either as a trunk attribute or its own resource). I\u0027d like to avoid duplication of information, like storing segmentation type and id at two places. I asked him to elaborate on this.\n\n2) Add a mass port bind method to the mechanismdriver interface, and bind all the children ports in one call. While this would be nice for performance I\u0027d like to avoid this in the first implementation because of the additional complexity.\n\nAltogether the binding of the top level parent is the usual binding process, plus triggering some kind of binding for its, subports.\n\nAttempts to change the binding:host_id of a subport must be treated as either a conversion into a plain old port, or must be rejected. I think it\u0027s simpler to reject it and we don\u0027t lose any functionality if we do that. The availability of a network segment must be checked while binding a subport.\n\nLacking knowledge in this area it is unclear to me how binding:vif_type, binding:vnic_type, binding:profile should be handled for subports. For the first implementation I hope we could just leave most of them unsupported. And fix later if needed.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47cc480aee64c04489a304e53763c982bf15823c","unresolved":false,"context_lines":[{"line_number":91,"context_line":"newly introduced resource(s) referring legacy ports.  A VLAN ID is just"},{"line_number":92,"context_line":"one possible encapsulation to use between the hypervisor and the guest"},{"line_number":93,"context_line":"to differentiate packets targeted at the regular port vs. one of the"},{"line_number":94,"context_line":"child ports."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"The first part of the API extension is the logical topology portion."},{"line_number":97,"context_line":"First, we include a method to indicate that a port may have children"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_c394cae9","line":94,"updated":"2015-12-10 08:52:50.000000000","message":"nit\nas we are allowing for additional encapsulations to be added in the future should we provide an example? the other obvious l2 candidate would be mpls. l3 encapsulation could also be supported but would be more complex to  implement.\n\ni do see the value in not restricting this to vlan in the future but we dont need to support every encapsulation protocol out of the gate either so starting with only vlans and extending later makes sense to me.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"897ba1cb1ff2101aecf2b658ddc336d21f6e5979","unresolved":false,"context_lines":[{"line_number":91,"context_line":"newly introduced resource(s) referring legacy ports.  A VLAN ID is just"},{"line_number":92,"context_line":"one possible encapsulation to use between the hypervisor and the guest"},{"line_number":93,"context_line":"to differentiate packets targeted at the regular port vs. one of the"},{"line_number":94,"context_line":"child ports."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"The first part of the API extension is the logical topology portion."},{"line_number":97,"context_line":"First, we include a method to indicate that a port may have children"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_a12e16f8","line":94,"in_reply_to":"7a740942_96dcb719","updated":"2015-12-11 04:53:44.000000000","message":"Please stop. Let\u0027s crawl before we can walk, we clearly demonstrated our inability to master the triviality.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"5f276ecbccf757d2babd14285593593a2b41b7de","unresolved":false,"context_lines":[{"line_number":91,"context_line":"newly introduced resource(s) referring legacy ports.  A VLAN ID is just"},{"line_number":92,"context_line":"one possible encapsulation to use between the hypervisor and the guest"},{"line_number":93,"context_line":"to differentiate packets targeted at the regular port vs. one of the"},{"line_number":94,"context_line":"child ports."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"The first part of the API extension is the logical topology portion."},{"line_number":97,"context_line":"First, we include a method to indicate that a port may have children"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_96dcb719","line":94,"in_reply_to":"7a740942_c394cae9","updated":"2015-12-10 10:48:21.000000000","message":"I\u0027d like to avoid broadening the scope. Otherwise I\u0027m afraid it\u0027ll take very long to settle this spec. While I fully support leaving it open to define new encapsulation types, I\u0027d defer that to later specs.\n\nDo you consider the current segmentation_id as an unsigned int sufficient for what you have in mind? Or should it be a string?","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"897ba1cb1ff2101aecf2b658ddc336d21f6e5979","unresolved":false,"context_lines":[{"line_number":101,"context_line":""},{"line_number":102,"context_line":"::"},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"    [ alt-two-resources ]"},{"line_number":105,"context_line":"    # Relation(s)s to subport(s) will be added later."},{"line_number":106,"context_line":"    $ neutron trunk-create --port-id PORT"},{"line_number":107,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_4183b2cc","line":104,"updated":"2015-12-11 04:53:44.000000000","message":"you forgot to mention here that PORT specified in port-id or subport are ports already created. Seems obvious but some comments made me think it\u0027s not.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"3d59d4eea3fab4032763e2854c5b9fde6f0e3e34","unresolved":false,"context_lines":[{"line_number":103,"context_line":""},{"line_number":104,"context_line":"    [ alt-two-resources ]"},{"line_number":105,"context_line":"    # Relation(s)s to subport(s) will be added later."},{"line_number":106,"context_line":"    $ neutron trunk-create --port-id PORT"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"::"},{"line_number":109,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_82716378","line":106,"updated":"2015-12-08 18:42:40.000000000","message":"Of your alternatives, I prefer this one.  The other one seems to have, and hide, a 1:n relationship inside it.\n\nI think you could do the same as an extension with extension attrs on the ports (per comment above).  Both trunks and subports are 1:1 with ports, so they\u0027re logically the same as adding attrs with an extension.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"897ba1cb1ff2101aecf2b658ddc336d21f6e5979","unresolved":false,"context_lines":[{"line_number":109,"context_line":""},{"line_number":110,"context_line":"    [ alt-one-resource ]"},{"line_number":111,"context_line":"    # trunk-create may refer to 0, 1 or more subport(s)."},{"line_number":112,"context_line":"    $ neutron trunk-create --port-id PORT \\"},{"line_number":113,"context_line":"                          [--subport PORT,SEGMENTATION-TYPE,SEGMENTATION-ID] \\"},{"line_number":114,"context_line":"                          [--subport ...]"},{"line_number":115,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_e172de10","line":112,"updated":"2015-12-11 04:53:44.000000000","message":"I think we can support both. In the end you want to try and minimize the call to set up the trunk once you have all the ports you care about.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":6598,"name":"Berezovsky Irena","email":"irenab.dev@gmail.com","username":"irenab"},"change_message_id":"e41c2c065eddc1a17e10c0ded3e7b2d6ba34a098","unresolved":false,"context_lines":[{"line_number":110,"context_line":"    [ alt-one-resource ]"},{"line_number":111,"context_line":"    # trunk-create may refer to 0, 1 or more subport(s)."},{"line_number":112,"context_line":"    $ neutron trunk-create --port-id PORT \\"},{"line_number":113,"context_line":"                          [--subport PORT,SEGMENTATION-TYPE,SEGMENTATION-ID] \\"},{"line_number":114,"context_line":"                          [--subport ...]"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Note that if a given plugin does not implement support for"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_02930ffb","line":113,"updated":"2015-12-08 15:52:54.000000000","message":"Are both segmentation type and id mandatory? It maybe the case, that plugin will handle id allocation and maintain default segmentation type","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47cc480aee64c04489a304e53763c982bf15823c","unresolved":false,"context_lines":[{"line_number":110,"context_line":"    [ alt-one-resource ]"},{"line_number":111,"context_line":"    # trunk-create may refer to 0, 1 or more subport(s)."},{"line_number":112,"context_line":"    $ neutron trunk-create --port-id PORT \\"},{"line_number":113,"context_line":"                          [--subport PORT,SEGMENTATION-TYPE,SEGMENTATION-ID] \\"},{"line_number":114,"context_line":"                          [--subport ...]"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Note that if a given plugin does not implement support for"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_a6b42cd1","line":113,"in_reply_to":"7a740942_02930ffb","updated":"2015-12-10 08:52:50.000000000","message":"i think the SEGMENTATION-ID is currently mandatory but segmentation type could default to vlan as only one segmentation type is initally supported.\n\nwe have not discussed auto provisioning of subport segmentation-ids previously.\nif it was allowed i would prefer the api to handel it not the backend plug-in to have consistency. a simply strategy would be to assign segmentation-ids incrementally to each subport in the order they were specified in.\n\nif allowed by the api the segmentation id would then have to be specified for all subports or none. specifying a segmentation id for some subports but not others in a bulk create should raise an exception as the complexity of supporting that edge case has no direct benefit in my opion.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"5f276ecbccf757d2babd14285593593a2b41b7de","unresolved":false,"context_lines":[{"line_number":110,"context_line":"    [ alt-one-resource ]"},{"line_number":111,"context_line":"    # trunk-create may refer to 0, 1 or more subport(s)."},{"line_number":112,"context_line":"    $ neutron trunk-create --port-id PORT \\"},{"line_number":113,"context_line":"                          [--subport PORT,SEGMENTATION-TYPE,SEGMENTATION-ID] \\"},{"line_number":114,"context_line":"                          [--subport ...]"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Note that if a given plugin does not implement support for"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_d6055f14","line":113,"in_reply_to":"7a740942_a6b42cd1","updated":"2015-12-10 10:48:21.000000000","message":"I have proposed the type and id as mandatory, because I see that as the minimal scope. I mean, if later we have a use case for id auto-allocation, we can seamlessly extend the all-mandatory case with the allocation logic dictated by the use case. On the other hand if we add an allocation logic right now without a use case, that may prove to be the wrong logic, and it may become hard to change or remove it.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"897ba1cb1ff2101aecf2b658ddc336d21f6e5979","unresolved":false,"context_lines":[{"line_number":110,"context_line":"    [ alt-one-resource ]"},{"line_number":111,"context_line":"    # trunk-create may refer to 0, 1 or more subport(s)."},{"line_number":112,"context_line":"    $ neutron trunk-create --port-id PORT \\"},{"line_number":113,"context_line":"                          [--subport PORT,SEGMENTATION-TYPE,SEGMENTATION-ID] \\"},{"line_number":114,"context_line":"                          [--subport ...]"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Note that if a given plugin does not implement support for"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_415ad284","line":113,"in_reply_to":"7a740942_d6055f14","updated":"2015-12-11 04:53:44.000000000","message":"All good points so far, but please let\u0027s state that we want to keep things simple.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"3d59d4eea3fab4032763e2854c5b9fde6f0e3e34","unresolved":false,"context_lines":[{"line_number":111,"context_line":"    # trunk-create may refer to 0, 1 or more subport(s)."},{"line_number":112,"context_line":"    $ neutron trunk-create --port-id PORT \\"},{"line_number":113,"context_line":"                          [--subport PORT,SEGMENTATION-TYPE,SEGMENTATION-ID] \\"},{"line_number":114,"context_line":"                          [--subport ...]"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Note that if a given plugin does not implement support for"},{"line_number":117,"context_line":"bp/vlan-aware-vms, this request will be rejected."}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_025493fc","line":114,"updated":"2015-12-08 18:42:40.000000000","message":"The whole \u0027this has a ton of data that is unbounded but isn\u0027t *really* a sub-resource\u0027 is not really selling me.  How would you store that data in the DB, a blob column of JSON?","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47cc480aee64c04489a304e53763c982bf15823c","unresolved":false,"context_lines":[{"line_number":111,"context_line":"    # trunk-create may refer to 0, 1 or more subport(s)."},{"line_number":112,"context_line":"    $ neutron trunk-create --port-id PORT \\"},{"line_number":113,"context_line":"                          [--subport PORT,SEGMENTATION-TYPE,SEGMENTATION-ID] \\"},{"line_number":114,"context_line":"                          [--subport ...]"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Note that if a given plugin does not implement support for"},{"line_number":117,"context_line":"bp/vlan-aware-vms, this request will be rejected."}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_a945df17","line":114,"in_reply_to":"7a740942_025493fc","updated":"2015-12-10 08:52:50.000000000","message":"i dislike json blobs...\nthe db model below suggest adding two new tables.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"6a46ee65727abce59932242c659d11a1ed98f0e7","unresolved":false,"context_lines":[{"line_number":111,"context_line":"    # trunk-create may refer to 0, 1 or more subport(s)."},{"line_number":112,"context_line":"    $ neutron trunk-create --port-id PORT \\"},{"line_number":113,"context_line":"                          [--subport PORT,SEGMENTATION-TYPE,SEGMENTATION-ID] \\"},{"line_number":114,"context_line":"                          [--subport ...]"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Note that if a given plugin does not implement support for"},{"line_number":117,"context_line":"bp/vlan-aware-vms, this request will be rejected."}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_662ab692","line":114,"in_reply_to":"7a740942_518179fa","updated":"2015-12-10 11:28:42.000000000","message":"I don\u0027t think any json blob here is involved. All datas could and should be properly structured. The concept here is that we have a sort of orchestrating call, which creates multiple resources (ports, subports) in one call. We have been trying to avoid these in Neutron as the preferred choice has been so far simple, quasi-atomic, API calls.\n\nThe previous option seems to be more inline with this style.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"897ba1cb1ff2101aecf2b658ddc336d21f6e5979","unresolved":false,"context_lines":[{"line_number":111,"context_line":"    # trunk-create may refer to 0, 1 or more subport(s)."},{"line_number":112,"context_line":"    $ neutron trunk-create --port-id PORT \\"},{"line_number":113,"context_line":"                          [--subport PORT,SEGMENTATION-TYPE,SEGMENTATION-ID] \\"},{"line_number":114,"context_line":"                          [--subport ...]"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Note that if a given plugin does not implement support for"},{"line_number":117,"context_line":"bp/vlan-aware-vms, this request will be rejected."}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_e11bbec8","line":114,"in_reply_to":"7a740942_662ab692","updated":"2015-12-11 04:53:44.000000000","message":"The ports are already created, this is only doing the association. Not sure we\u0027re talking about json blobs here. That\u0027s a hell of leap.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"5f276ecbccf757d2babd14285593593a2b41b7de","unresolved":false,"context_lines":[{"line_number":111,"context_line":"    # trunk-create may refer to 0, 1 or more subport(s)."},{"line_number":112,"context_line":"    $ neutron trunk-create --port-id PORT \\"},{"line_number":113,"context_line":"                          [--subport PORT,SEGMENTATION-TYPE,SEGMENTATION-ID] \\"},{"line_number":114,"context_line":"                          [--subport ...]"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Note that if a given plugin does not implement support for"},{"line_number":117,"context_line":"bp/vlan-aware-vms, this request will be rejected."}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_518179fa","line":114,"in_reply_to":"7a740942_a945df17","updated":"2015-12-10 10:48:21.000000000","message":"No matter which API alternative we agree on, I\u0027d like to keep at least the DB model normalized. Theoretically, I\u0027d like to apply the same normalization on the API model too.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"897ba1cb1ff2101aecf2b658ddc336d21f6e5979","unresolved":false,"context_lines":[{"line_number":120,"context_line":"may reject this call at all times.  Other backends, being able to"},{"line_number":121,"context_line":"turn ports into trunk ports at any time may accept it at all times."},{"line_number":122,"context_line":"Backends (eg. neutron-openvswitch-agent) are free to selectively accept"},{"line_number":123,"context_line":"or reject the call depending on their own logic, for example:"},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"* Accept it for newly created ports,"},{"line_number":126,"context_line":"  but reject it if the port is owned by a vm (as in device_owner/device_id)."}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_a1f1366c","line":123,"updated":"2015-12-11 04:53:44.000000000","message":"This is very difficult to read. If a plugin does not support the feature the trunk commands will return 404. Simple. All the rest is nonsense.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"3d59d4eea3fab4032763e2854c5b9fde6f0e3e34","unresolved":false,"context_lines":[{"line_number":125,"context_line":"* Accept it for newly created ports,"},{"line_number":126,"context_line":"  but reject it if the port is owned by a vm (as in device_owner/device_id)."},{"line_number":127,"context_line":"* Accept it for newly created ports,"},{"line_number":128,"context_line":"  but reject it after the port was bound."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"In addition to the logical topology piece, we need to define the type of"},{"line_number":131,"context_line":"encapsulation used between the hypervisor and VM for targeting packets to a"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_626a37b5","line":128,"updated":"2015-12-08 18:42:40.000000000","message":"I\u0027m fairly sure you\u0027ve named the same condition twice.\n\nI worry about \u0027you can reject this for any reason and inconsistently\u0027 permission, because I can\u0027t know as an application whether this is ever going to work or under what conditions, plus I can guarantee that different controllers will implement it differently and I have to qualify on everything.\n\nPerhaps better to say the other thing: if this works at all, it is guaranteed to work for a port that has been created and not yet bound.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47cc480aee64c04489a304e53763c982bf15823c","unresolved":false,"context_lines":[{"line_number":125,"context_line":"* Accept it for newly created ports,"},{"line_number":126,"context_line":"  but reject it if the port is owned by a vm (as in device_owner/device_id)."},{"line_number":127,"context_line":"* Accept it for newly created ports,"},{"line_number":128,"context_line":"  but reject it after the port was bound."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"In addition to the logical topology piece, we need to define the type of"},{"line_number":131,"context_line":"encapsulation used between the hypervisor and VM for targeting packets to a"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_d451e20f","line":128,"in_reply_to":"7a740942_626a37b5","updated":"2015-12-10 08:52:50.000000000","message":"+1\nif the backend supports creating trunk ports it should support always support it for any port that is not yet bound.\n\nif the port is bound it is implementation specific and may be rejected.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"5f276ecbccf757d2babd14285593593a2b41b7de","unresolved":false,"context_lines":[{"line_number":125,"context_line":"* Accept it for newly created ports,"},{"line_number":126,"context_line":"  but reject it if the port is owned by a vm (as in device_owner/device_id)."},{"line_number":127,"context_line":"* Accept it for newly created ports,"},{"line_number":128,"context_line":"  but reject it after the port was bound."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"In addition to the logical topology piece, we need to define the type of"},{"line_number":131,"context_line":"encapsulation used between the hypervisor and VM for targeting packets to a"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_2cc1f280","line":128,"in_reply_to":"7a740942_d451e20f","updated":"2015-12-10 10:48:21.000000000","message":"Okay, I will change the text to mandate support for all not-yet-bound ports if it is supported at all.\n\nOne thing I\u0027d still like to avoid is to the vague terminology of a port being \"bound\". We actually set  up so many relations while binding a port, that I perceive  talking about a port bound as inviting confusion about:\n\n - port-host relation\n - port-owner relation (which is a port-vm relation for plain old ports and trunk ports, but likely a port-trunk relation for subports)\n - port-vif/vnic_* relations\n\nWith all this complicated by ovs-agent, when actions on the host are not done after updating binding:host_id, instead they are triggered by nova actually starting the vm. So I will just stick to the update of binding:host_id as the boundary.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"dfe9bb9d7207ceeddc7f272598d7aa61a6793cd0","unresolved":false,"context_lines":[{"line_number":141,"context_line":""},{"line_number":142,"context_line":"    [ alt-two-resources ]"},{"line_number":143,"context_line":"    # Bulk API is needed to be efficient for lots of subports."},{"line_number":144,"context_line":"    $ neutron subport-create --port-id PORT \\"},{"line_number":145,"context_line":"                             --trunk-id TRUNK \\"},{"line_number":146,"context_line":"                             --segmentation-type SEGMENTATION-TYPE \\"},{"line_number":147,"context_line":"                             --segmentation-id SEGMENTATION-ID"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_7c718543","line":144,"updated":"2015-12-08 00:34:57.000000000","message":"We should strive to collapse these two calls together. There\u0027s no need to expose sub-port as a top-level resource. It\u0027s a trunk\u0027s attribute, just like router\u0027s interfaces.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"3d59d4eea3fab4032763e2854c5b9fde6f0e3e34","unresolved":false,"context_lines":[{"line_number":141,"context_line":""},{"line_number":142,"context_line":"    [ alt-two-resources ]"},{"line_number":143,"context_line":"    # Bulk API is needed to be efficient for lots of subports."},{"line_number":144,"context_line":"    $ neutron subport-create --port-id PORT \\"},{"line_number":145,"context_line":"                             --trunk-id TRUNK \\"},{"line_number":146,"context_line":"                             --segmentation-type SEGMENTATION-TYPE \\"},{"line_number":147,"context_line":"                             --segmentation-id SEGMENTATION-ID"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_ae7f7ede","line":144,"in_reply_to":"7a740942_738e642f","updated":"2015-12-08 18:42:40.000000000","message":"And to steal that analogy, note we have router-interface-add and -delete (which is what subport-create maps to).","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"89bec57a08713221ded665db9e14191852c3dda1","unresolved":false,"context_lines":[{"line_number":141,"context_line":""},{"line_number":142,"context_line":"    [ alt-two-resources ]"},{"line_number":143,"context_line":"    # Bulk API is needed to be efficient for lots of subports."},{"line_number":144,"context_line":"    $ neutron subport-create --port-id PORT \\"},{"line_number":145,"context_line":"                             --trunk-id TRUNK \\"},{"line_number":146,"context_line":"                             --segmentation-type SEGMENTATION-TYPE \\"},{"line_number":147,"context_line":"                             --segmentation-id SEGMENTATION-ID"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_8d4988b9","line":144,"in_reply_to":"7a740942_7c718543","updated":"2015-12-08 09:58:11.000000000","message":"I see your point. Maybe we don\u0027t need this differentiation on the API level. However I think we need it in the CLI. Because neutron trunk-show should never print thousands of subports (along with their segmentation_type/id) in a single attribute of the trunk. What do you think how this should look like in the CLI?","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"3d59d4eea3fab4032763e2854c5b9fde6f0e3e34","unresolved":false,"context_lines":[{"line_number":141,"context_line":""},{"line_number":142,"context_line":"    [ alt-two-resources ]"},{"line_number":143,"context_line":"    # Bulk API is needed to be efficient for lots of subports."},{"line_number":144,"context_line":"    $ neutron subport-create --port-id PORT \\"},{"line_number":145,"context_line":"                             --trunk-id TRUNK \\"},{"line_number":146,"context_line":"                             --segmentation-type SEGMENTATION-TYPE \\"},{"line_number":147,"context_line":"                             --segmentation-id SEGMENTATION-ID"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_8e15e29c","line":144,"in_reply_to":"7a740942_7c718543","updated":"2015-12-08 18:42:40.000000000","message":"My issue with that is port:subport is 1:n; it feels wrong to add subport to trunk and then get complex questions about how to store it, whether order matters (no), how to add one, remove one, ...","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"6a46ee65727abce59932242c659d11a1ed98f0e7","unresolved":false,"context_lines":[{"line_number":141,"context_line":""},{"line_number":142,"context_line":"    [ alt-two-resources ]"},{"line_number":143,"context_line":"    # Bulk API is needed to be efficient for lots of subports."},{"line_number":144,"context_line":"    $ neutron subport-create --port-id PORT \\"},{"line_number":145,"context_line":"                             --trunk-id TRUNK \\"},{"line_number":146,"context_line":"                             --segmentation-type SEGMENTATION-TYPE \\"},{"line_number":147,"context_line":"                             --segmentation-id SEGMENTATION-ID"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_293a4199","line":144,"in_reply_to":"7a740942_8d4988b9","updated":"2015-12-10 11:28:42.000000000","message":"I think the CLI here should be considered only as a simple way to communicate your intentions about the API. This spec is about the API (well at least for the mgmt part), and it\u0027s the API we should care about first.\n\nFor the CLI output, we can think about improvements later on. Also, I don\u0027t get how that would be related to the fact that a subport is a standalone resource or not. On that matter I\u0027d say that it should not be a new resource because semantically it does exactly what a port does; on the other hand I understand that strictly speaking in object model terms is a different object... but I wouldn\u0027t care about that.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"fe88bdc04a4f7dd5961c0cd33798645ef8ac0405","unresolved":false,"context_lines":[{"line_number":141,"context_line":""},{"line_number":142,"context_line":"    [ alt-two-resources ]"},{"line_number":143,"context_line":"    # Bulk API is needed to be efficient for lots of subports."},{"line_number":144,"context_line":"    $ neutron subport-create --port-id PORT \\"},{"line_number":145,"context_line":"                             --trunk-id TRUNK \\"},{"line_number":146,"context_line":"                             --segmentation-type SEGMENTATION-TYPE \\"},{"line_number":147,"context_line":"                             --segmentation-id SEGMENTATION-ID"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_738e642f","line":144,"in_reply_to":"7a740942_8d4988b9","updated":"2015-12-08 17:02:50.000000000","message":"Indeed we should not list the ports in trunk show, the same way we don\u0027t show (router) interfaces with router-show. We can then have a trunk-port-list command, just like we have the router-port-list command, and for that we clearly do not need a subport-create command.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47cc480aee64c04489a304e53763c982bf15823c","unresolved":false,"context_lines":[{"line_number":141,"context_line":""},{"line_number":142,"context_line":"    [ alt-two-resources ]"},{"line_number":143,"context_line":"    # Bulk API is needed to be efficient for lots of subports."},{"line_number":144,"context_line":"    $ neutron subport-create --port-id PORT \\"},{"line_number":145,"context_line":"                             --trunk-id TRUNK \\"},{"line_number":146,"context_line":"                             --segmentation-type SEGMENTATION-TYPE \\"},{"line_number":147,"context_line":"                             --segmentation-id SEGMENTATION-ID"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_d4d7a221","line":144,"in_reply_to":"7a740942_8e15e29c","updated":"2015-12-10 08:52:50.000000000","message":"i think it can be efficiently stored in the db provided it is not a json blob. \nbut i agree with the mappings to router-interface-add.\n\nfor consistency would it be better to have the following cli commands:\n\ntrunk-port-create or  trunk-create\n\ntrunk-port-delete or  trunk-delete\n\ntrunk-port-show or  trunk-show\n\ntrunk-port-list or  trunk-list\n\ntrunk-subport-add\n\ntrunk-subport-delete\n\ntrunk-subport-list\n\ntrunk-subport-show (not sure about this one as it is basically port-show + segmentation type + segmentation id)","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"3003e7eed755124c962bf69af804678235355bb2","unresolved":false,"context_lines":[{"line_number":141,"context_line":""},{"line_number":142,"context_line":"    [ alt-two-resources ]"},{"line_number":143,"context_line":"    # Bulk API is needed to be efficient for lots of subports."},{"line_number":144,"context_line":"    $ neutron subport-create --port-id PORT \\"},{"line_number":145,"context_line":"                             --trunk-id TRUNK \\"},{"line_number":146,"context_line":"                             --segmentation-type SEGMENTATION-TYPE \\"},{"line_number":147,"context_line":"                             --segmentation-id SEGMENTATION-ID"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_a6e73311","line":144,"in_reply_to":"7a740942_d4d7a221","updated":"2015-12-10 14:26:44.000000000","message":"Sounds good enough for me. I\u0027d choose trunk-VERB instead of trunk-port-VERB, because with this API the trunk is not a port anymore. Just something that refers to a port.\n\nAdded to the next patch set.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"89bec57a08713221ded665db9e14191852c3dda1","unresolved":false,"context_lines":[{"line_number":162,"context_line":"::"},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"    [ alt-one-resource ]"},{"line_number":165,"context_line":"    POST /v2/trunks"},{"line_number":166,"context_line":"         ..."},{"line_number":167,"context_line":"    POST /v2/trunks/TRUNK-ID/action"},{"line_number":168,"context_line":"         {\u0027add_subport\u0027:"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_25866edb","line":165,"updated":"2015-12-08 09:58:11.000000000","message":"s/v2/v2.0/","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"89bec57a08713221ded665db9e14191852c3dda1","unresolved":false,"context_lines":[{"line_number":164,"context_line":"    [ alt-one-resource ]"},{"line_number":165,"context_line":"    POST /v2/trunks"},{"line_number":166,"context_line":"         ..."},{"line_number":167,"context_line":"    POST /v2/trunks/TRUNK-ID/action"},{"line_number":168,"context_line":"         {\u0027add_subport\u0027:"},{"line_number":169,"context_line":"             {\u0027subports\u0027:"},{"line_number":170,"context_line":"                 [{\u0027port_id\u0027: PORT_ID,"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_0d7038db","line":167,"updated":"2015-12-08 09:58:11.000000000","message":"Which one is better?\n\n 1)\n POST /v2.0/trunks/TRUNK-ID/action\n BODY {\u0027add_subport\u0027: ...}\n BODY {\u0027delete_subport\u0027: ...}\n\n 2)\n POST /v2.0/trunks/TRUNK-ID/add_subport\n POST /v2.0/trunks/TRUNK-ID/delete_subport\n BODY {\u0027subports\u0027: ...}","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47cc480aee64c04489a304e53763c982bf15823c","unresolved":false,"context_lines":[{"line_number":164,"context_line":"    [ alt-one-resource ]"},{"line_number":165,"context_line":"    POST /v2/trunks"},{"line_number":166,"context_line":"         ..."},{"line_number":167,"context_line":"    POST /v2/trunks/TRUNK-ID/action"},{"line_number":168,"context_line":"         {\u0027add_subport\u0027:"},{"line_number":169,"context_line":"             {\u0027subports\u0027:"},{"line_number":170,"context_line":"                 [{\u0027port_id\u0027: PORT_ID,"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_7a0b377e","line":167,"in_reply_to":"7a740942_0d7038db","updated":"2015-12-10 08:52:50.000000000","message":"for  1)\ni would use\nPOST /v2.0/trunks/TRUNK-ID\ninstead as i dont think action is required.\n\nfor 2 i dont think having endpoint for crud operations isvery restful.\n\nmy option 3 would be to use 4 url entry points + http request method(get/post/put/delete) to request the different operations.\nurls:\n\n/v2.0/trunks/\n\n/v2.0/trunks/TRUNK-ID\n\n/v2.0/trunks/TRUNK-ID/subports\n\n/v2.0/trunks/TRUNK-ID/subports/SUBPORT-ID\n\nthe comment was getting rather long so i created a pastbin for the entry points requests and responses.\nhttp://pastebin.com/S2kew8i6","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"3003e7eed755124c962bf69af804678235355bb2","unresolved":false,"context_lines":[{"line_number":164,"context_line":"    [ alt-one-resource ]"},{"line_number":165,"context_line":"    POST /v2/trunks"},{"line_number":166,"context_line":"         ..."},{"line_number":167,"context_line":"    POST /v2/trunks/TRUNK-ID/action"},{"line_number":168,"context_line":"         {\u0027add_subport\u0027:"},{"line_number":169,"context_line":"             {\u0027subports\u0027:"},{"line_number":170,"context_line":"                 [{\u0027port_id\u0027: PORT_ID,"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_8d67bab6","line":167,"in_reply_to":"7a740942_4976ad3f","updated":"2015-12-10 14:26:44.000000000","message":"Sean, isn\u0027t your option (3) practically equivalent with having a standalone subport resource (with the lifecycle containment as Salvatore mentioned)? If we do that, why don\u0027t we just make it a top level resource?","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"6a46ee65727abce59932242c659d11a1ed98f0e7","unresolved":false,"context_lines":[{"line_number":164,"context_line":"    [ alt-one-resource ]"},{"line_number":165,"context_line":"    POST /v2/trunks"},{"line_number":166,"context_line":"         ..."},{"line_number":167,"context_line":"    POST /v2/trunks/TRUNK-ID/action"},{"line_number":168,"context_line":"         {\u0027add_subport\u0027:"},{"line_number":169,"context_line":"             {\u0027subports\u0027:"},{"line_number":170,"context_line":"                 [{\u0027port_id\u0027: PORT_ID,"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_4976ad3f","line":167,"in_reply_to":"7a740942_7a0b377e","updated":"2015-12-10 11:28:42.000000000","message":"I don\u0027t think actions are required too.\nBesides, if you really want to go down that road, I\u0027d suggest option #2 for style consistency with other neutron APIs.\n\n\nwhat Sean proposes is doable if the life cycle of a subport is entirely contained within the life cycle of its trunk. If you expect to provide a capability to move subports across trunks maybe this is not ideal anymore.\n\nA simpler option is instead to specify the trunk_id when creating the subport (or port if you do not adopt a new resource).\nYou could still do\n\nGET /v2.0/trunks/\u003ctrunk_id\u003e/subports \n\nto fetch all subports","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"6a46ee65727abce59932242c659d11a1ed98f0e7","unresolved":false,"context_lines":[{"line_number":181,"context_line":"Subport details are also expected to be exposed to VMs via the Nova metadata"},{"line_number":182,"context_line":"service, though the details will most likely be tackled in a follow-up spec."},{"line_number":183,"context_line":"A possible model to follow is `Virtual guest device role tagging"},{"line_number":184,"context_line":"\u003chttps://review.openstack.org/#q,I16845bd36878bbd9d7a877dc556b2650bc6f0fad,n,z\u003e`_."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":"Importantly, after creating trunks and maybe subports, VMs are still booted"},{"line_number":187,"context_line":"with a reference to plain old ports:"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_29ca411b","line":184,"updated":"2015-12-10 11:28:42.000000000","message":"can you put this in references?","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"3003e7eed755124c962bf69af804678235355bb2","unresolved":false,"context_lines":[{"line_number":181,"context_line":"Subport details are also expected to be exposed to VMs via the Nova metadata"},{"line_number":182,"context_line":"service, though the details will most likely be tackled in a follow-up spec."},{"line_number":183,"context_line":"A possible model to follow is `Virtual guest device role tagging"},{"line_number":184,"context_line":"\u003chttps://review.openstack.org/#q,I16845bd36878bbd9d7a877dc556b2650bc6f0fad,n,z\u003e`_."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":"Importantly, after creating trunks and maybe subports, VMs are still booted"},{"line_number":187,"context_line":"with a reference to plain old ports:"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_4dd6b228","line":184,"in_reply_to":"7a740942_29ca411b","updated":"2015-12-10 14:26:44.000000000","message":"Done","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"6a46ee65727abce59932242c659d11a1ed98f0e7","unresolved":false,"context_lines":[{"line_number":190,"context_line":""},{"line_number":191,"context_line":"    $ nova boot --nic port-id\u003d..."},{"line_number":192,"context_line":""},{"line_number":193,"context_line":"Nova need not know about trunks and subports."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"Example logical model::"},{"line_number":196,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_8902553d","line":193,"updated":"2015-12-10 11:28:42.000000000","message":"so, a subport is not a new resource after all?","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"3003e7eed755124c962bf69af804678235355bb2","unresolved":false,"context_lines":[{"line_number":190,"context_line":""},{"line_number":191,"context_line":"    $ nova boot --nic port-id\u003d..."},{"line_number":192,"context_line":""},{"line_number":193,"context_line":"Nova need not know about trunks and subports."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"Example logical model::"},{"line_number":196,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_ed819efc","line":193,"in_reply_to":"7a740942_8902553d","updated":"2015-12-10 14:26:44.000000000","message":"Here I wanted to refer to both alternatives. I believe nova needs to know the exact same port-id, regardless whether we have two resources in neutron or one.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"6a46ee65727abce59932242c659d11a1ed98f0e7","unresolved":false,"context_lines":[{"line_number":245,"context_line":"* A top level port that may have child ports added must be marked by creating"},{"line_number":246,"context_line":"  a trunk referring to the port in its `port_id` attribute."},{"line_number":247,"context_line":""},{"line_number":248,"context_line":"* Nested subports are supported.  Implementations may reject"},{"line_number":249,"context_line":"  the request based on backend specific restrictions, though.  For example, if"},{"line_number":250,"context_line":"  using the VLAN segmentation type, multiple levels of nesting would require"},{"line_number":251,"context_line":"  QinQ support, which OVS does not yet support (though is very close to"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_ec2207a3","line":248,"updated":"2015-12-10 11:28:42.000000000","message":"Do you really think this should be in constraints?\n\nThe fact that you can do it because you have QinQ or becuase some other technology allows you to do it does not mean you should do it.\nI am not sure we have a real use case that would require us to nest subports.\nIf we were allowing this just for \"future proofing\", I\u0027d just enable the capability when there\u0027s actual need for it.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"3003e7eed755124c962bf69af804678235355bb2","unresolved":false,"context_lines":[{"line_number":245,"context_line":"* A top level port that may have child ports added must be marked by creating"},{"line_number":246,"context_line":"  a trunk referring to the port in its `port_id` attribute."},{"line_number":247,"context_line":""},{"line_number":248,"context_line":"* Nested subports are supported.  Implementations may reject"},{"line_number":249,"context_line":"  the request based on backend specific restrictions, though.  For example, if"},{"line_number":250,"context_line":"  using the VLAN segmentation type, multiple levels of nesting would require"},{"line_number":251,"context_line":"  QinQ support, which OVS does not yet support (though is very close to"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_26182384","line":248,"in_reply_to":"7a740942_ec2207a3","updated":"2015-12-10 14:26:44.000000000","message":"Moved to the previous section. Made it subject to later spec.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47cc480aee64c04489a304e53763c982bf15823c","unresolved":false,"context_lines":[{"line_number":249,"context_line":"  the request based on backend specific restrictions, though.  For example, if"},{"line_number":250,"context_line":"  using the VLAN segmentation type, multiple levels of nesting would require"},{"line_number":251,"context_line":"  QinQ support, which OVS does not yet support (though is very close to"},{"line_number":252,"context_line":"  supporting)."},{"line_number":253,"context_line":""},{"line_number":254,"context_line":"* Every subport of a given parent should have unique (segmentation_type,"},{"line_number":255,"context_line":"  segmentation_id) among its siblings.  Otherwise, it would not be possible"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_b5877011","line":252,"updated":"2015-12-10 08:52:50.000000000","message":"are using different encapsulation types allowed at each layer also. i believe yes?","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"3003e7eed755124c962bf69af804678235355bb2","unresolved":false,"context_lines":[{"line_number":249,"context_line":"  the request based on backend specific restrictions, though.  For example, if"},{"line_number":250,"context_line":"  using the VLAN segmentation type, multiple levels of nesting would require"},{"line_number":251,"context_line":"  QinQ support, which OVS does not yet support (though is very close to"},{"line_number":252,"context_line":"  supporting)."},{"line_number":253,"context_line":""},{"line_number":254,"context_line":"* Every subport of a given parent should have unique (segmentation_type,"},{"line_number":255,"context_line":"  segmentation_id) among its siblings.  Otherwise, it would not be possible"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_a1463d4d","line":252,"in_reply_to":"7a740942_b5877011","updated":"2015-12-10 14:26:44.000000000","message":"Yes. Since the type is specified on the subport, you could even mix types amongst siblings. However as said before, this will be probably left for later.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"3d59d4eea3fab4032763e2854c5b9fde6f0e3e34","unresolved":false,"context_lines":[{"line_number":253,"context_line":""},{"line_number":254,"context_line":"* Every subport of a given parent should have unique (segmentation_type,"},{"line_number":255,"context_line":"  segmentation_id) among its siblings.  Otherwise, it would not be possible"},{"line_number":256,"context_line":"  to properly differentiate the source and destination logical port."},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"* The parent port handles \"untagged\" traffic. In case of nested subports,"},{"line_number":259,"context_line":"  the top level (\"root\") port handles \"untagged\" traffic. The parent"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_aef45e5a","line":256,"updated":"2015-12-08 18:42:40.000000000","message":"Seems to me that the type is vlan, the ID is the VLAN ID, but the segment (physical_network?) is different.  Or are you just thinking of a random number for identity?\n\nDon\u0027t think this matters much - this paragraph is a note to the code author they can take or leave.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47cc480aee64c04489a304e53763c982bf15823c","unresolved":false,"context_lines":[{"line_number":253,"context_line":""},{"line_number":254,"context_line":"* Every subport of a given parent should have unique (segmentation_type,"},{"line_number":255,"context_line":"  segmentation_id) among its siblings.  Otherwise, it would not be possible"},{"line_number":256,"context_line":"  to properly differentiate the source and destination logical port."},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"* The parent port handles \"untagged\" traffic. In case of nested subports,"},{"line_number":259,"context_line":"  the top level (\"root\") port handles \"untagged\" traffic. The parent"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_f5e418ad","line":256,"in_reply_to":"7a740942_aef45e5a","updated":"2015-12-10 08:52:50.000000000","message":"no this is an api constraint. the api does not allow the creation or two\nsubport with same segmentation type(vlan) and same segmentation id(vlan id) in the same trunk port. this is the segmentation type and segmentation id that the guest will see. i think it would be better to rename these to encapsulation type and encapsulation id to avoid confusion with the neutron network segmentation id and segmentation type.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"3003e7eed755124c962bf69af804678235355bb2","unresolved":false,"context_lines":[{"line_number":253,"context_line":""},{"line_number":254,"context_line":"* Every subport of a given parent should have unique (segmentation_type,"},{"line_number":255,"context_line":"  segmentation_id) among its siblings.  Otherwise, it would not be possible"},{"line_number":256,"context_line":"  to properly differentiate the source and destination logical port."},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"* The parent port handles \"untagged\" traffic. In case of nested subports,"},{"line_number":259,"context_line":"  the top level (\"root\") port handles \"untagged\" traffic. The parent"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_90183177","line":256,"in_reply_to":"7a740942_f5e418ad","updated":"2015-12-10 14:26:44.000000000","message":"We have chosen the names \u0027segmentation_type\u0027 and \u0027segmentation_id\u0027 to be consistent with the provider extension\u0027s terminology. ;-)\n\nIMO the distinction can be easily made by talking about provider:segmentation_type and trunk:segmentation_type.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"3d59d4eea3fab4032763e2854c5b9fde6f0e3e34","unresolved":false,"context_lines":[{"line_number":258,"context_line":"* The parent port handles \"untagged\" traffic. In case of nested subports,"},{"line_number":259,"context_line":"  the top level (\"root\") port handles \"untagged\" traffic. The parent"},{"line_number":260,"context_line":"  will receive all the packets that do not match a sub-port, which is no"},{"line_number":261,"context_line":"  different than how a regular port already behaves today.  This also"},{"line_number":262,"context_line":"  means that every VM has a port for untagged traffic.  It doesn\u0027t"},{"line_number":263,"context_line":"  necessarily have to be used though and could be attached to a dummy"},{"line_number":264,"context_line":"  Neutron network if desired.  You could also have a security group"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_2e538e6c","line":261,"updated":"2015-12-08 18:42:40.000000000","message":"... apart from not passing on the tagged traffic.  So it\u0027s quite different.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"3003e7eed755124c962bf69af804678235355bb2","unresolved":false,"context_lines":[{"line_number":258,"context_line":"* The parent port handles \"untagged\" traffic. In case of nested subports,"},{"line_number":259,"context_line":"  the top level (\"root\") port handles \"untagged\" traffic. The parent"},{"line_number":260,"context_line":"  will receive all the packets that do not match a sub-port, which is no"},{"line_number":261,"context_line":"  different than how a regular port already behaves today.  This also"},{"line_number":262,"context_line":"  means that every VM has a port for untagged traffic.  It doesn\u0027t"},{"line_number":263,"context_line":"  necessarily have to be used though and could be attached to a dummy"},{"line_number":264,"context_line":"  Neutron network if desired.  You could also have a security group"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_706ca59c","line":261,"in_reply_to":"7a740942_2713535e","updated":"2015-12-10 14:26:44.000000000","message":"I see the \"passing on of tagged traffic\" as orthogonal to this spec and specified by the nfv-vlan-trunking spec, that is the vlan-transparent attribute of a net. And yes if the two features are combined at some point in the future, the parent port should pass on the unknown tags (as payload) on the vlan transparent network. Or actually this could happen at any other level too.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47cc480aee64c04489a304e53763c982bf15823c","unresolved":false,"context_lines":[{"line_number":258,"context_line":"* The parent port handles \"untagged\" traffic. In case of nested subports,"},{"line_number":259,"context_line":"  the top level (\"root\") port handles \"untagged\" traffic. The parent"},{"line_number":260,"context_line":"  will receive all the packets that do not match a sub-port, which is no"},{"line_number":261,"context_line":"  different than how a regular port already behaves today.  This also"},{"line_number":262,"context_line":"  means that every VM has a port for untagged traffic.  It doesn\u0027t"},{"line_number":263,"context_line":"  necessarily have to be used though and could be attached to a dummy"},{"line_number":264,"context_line":"  Neutron network if desired.  You could also have a security group"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_2713535e","line":261,"in_reply_to":"7a740942_2e538e6c","updated":"2015-12-10 08:52:50.000000000","message":"that depends on the impentation. with the ovs neutron agent impentation assuming trunk bridges root port will only recive untagged traffic for one port and in all other cases it with recive tagged traffic from subport with a segmentation id and type configured.\n\nas far as i understand there will only ever be one subport even in the nested case which will receive untagged traffic from a neutron network due to the constraint on line 254","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47cc480aee64c04489a304e53763c982bf15823c","unresolved":false,"context_lines":[{"line_number":261,"context_line":"  different than how a regular port already behaves today.  This also"},{"line_number":262,"context_line":"  means that every VM has a port for untagged traffic.  It doesn\u0027t"},{"line_number":263,"context_line":"  necessarily have to be used though and could be attached to a dummy"},{"line_number":264,"context_line":"  Neutron network if desired.  You could also have a security group"},{"line_number":265,"context_line":"  set on the parent port to drop all incoming and outgoing traffic."},{"line_number":266,"context_line":"  A future enhancement could include the ability to create a Neutron"},{"line_number":267,"context_line":"  port not yet attached to a network, though it\u0027s unclear how valuable"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_c7edaf26","line":264,"updated":"2015-12-10 08:52:50.000000000","message":"can you state how this interacts with security groups.\n\ni assume they can only be applied to the trunk port and not the subports.\n\ncan security groups be applied to the supports independently?","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":6598,"name":"Berezovsky Irena","email":"irenab.dev@gmail.com","username":"irenab"},"change_message_id":"e41c2c065eddc1a17e10c0ded3e7b2d6ba34a098","unresolved":false,"context_lines":[{"line_number":263,"context_line":"  necessarily have to be used though and could be attached to a dummy"},{"line_number":264,"context_line":"  Neutron network if desired.  You could also have a security group"},{"line_number":265,"context_line":"  set on the parent port to drop all incoming and outgoing traffic."},{"line_number":266,"context_line":"  A future enhancement could include the ability to create a Neutron"},{"line_number":267,"context_line":"  port not yet attached to a network, though it\u0027s unclear how valuable"},{"line_number":268,"context_line":"  that actually is."},{"line_number":269,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_a48fa873","line":266,"updated":"2015-12-08 15:52:54.000000000","message":"This may make sense for the router port","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":6598,"name":"Berezovsky Irena","email":"irenab.dev@gmail.com","username":"irenab"},"change_message_id":"e41c2c065eddc1a17e10c0ded3e7b2d6ba34a098","unresolved":false,"context_lines":[{"line_number":269,"context_line":""},{"line_number":270,"context_line":"* A port with a parent logically inherits its binding:host_id from its parent."},{"line_number":271,"context_line":""},{"line_number":272,"context_line":"* An attempt tp update binding:host_id of a subport (by booting a Nova VM with"},{"line_number":273,"context_line":"  a subport UUID, for example) must result in an error."},{"line_number":274,"context_line":""},{"line_number":275,"context_line":"* A normal user can only connect subports to its own parent ports. Admin"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_c4e1942b","line":272,"updated":"2015-12-08 15:52:54.000000000","message":"typo: to","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"3003e7eed755124c962bf69af804678235355bb2","unresolved":false,"context_lines":[{"line_number":269,"context_line":""},{"line_number":270,"context_line":"* A port with a parent logically inherits its binding:host_id from its parent."},{"line_number":271,"context_line":""},{"line_number":272,"context_line":"* An attempt tp update binding:host_id of a subport (by booting a Nova VM with"},{"line_number":273,"context_line":"  a subport UUID, for example) must result in an error."},{"line_number":274,"context_line":""},{"line_number":275,"context_line":"* A normal user can only connect subports to its own parent ports. Admin"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_61bdb5d6","line":272,"in_reply_to":"7a740942_c4e1942b","updated":"2015-12-10 14:26:44.000000000","message":"Done","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"6a46ee65727abce59932242c659d11a1ed98f0e7","unresolved":false,"context_lines":[{"line_number":278,"context_line":"* Until OVS supports QinQ, an OVS based Neutron backend can not support having a"},{"line_number":279,"context_line":"  subport attached to a \"vlan_transparent\" network.  That would require the"},{"line_number":280,"context_line":"  abilty to transport VLAN tagged traffic over the VLAN tagged subport interface"},{"line_number":281,"context_line":"  (nested VLANs), which is not yet possible."},{"line_number":282,"context_line":""},{"line_number":283,"context_line":"Nova changes"},{"line_number":284,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_0c9bd3ca","line":281,"updated":"2015-12-10 11:28:42.000000000","message":"And therefore we need to disable such extension on the ml2 plugin with ovs driver, if that has not already been done","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47cc480aee64c04489a304e53763c982bf15823c","unresolved":false,"context_lines":[{"line_number":314,"context_line":"Neutron port: no changes."},{"line_number":315,"context_line":""},{"line_number":316,"context_line":"Neutron DB table: trunks"},{"line_number":317,"context_line":"  * id"},{"line_number":318,"context_line":"  * name"},{"line_number":319,"context_line":"  * tenant_id"},{"line_number":320,"context_line":"  * port_id: foreign key to ports.id"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_49723b7e","line":317,"updated":"2015-12-10 08:52:50.000000000","message":"id should be an integer primary key\nand a second uuid feild should be used for the trunk port id used in the api.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47cc480aee64c04489a304e53763c982bf15823c","unresolved":false,"context_lines":[{"line_number":316,"context_line":"Neutron DB table: trunks"},{"line_number":317,"context_line":"  * id"},{"line_number":318,"context_line":"  * name"},{"line_number":319,"context_line":"  * tenant_id"},{"line_number":320,"context_line":"  * port_id: foreign key to ports.id"},{"line_number":321,"context_line":""},{"line_number":322,"context_line":"Neutron DB table: subports"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_898263c7","line":319,"updated":"2015-12-10 08:52:50.000000000","message":"why is a tenant_id needed here?\nthe tenant id is a property of the port object so it\nshould not need to be stored in the trunk table.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"3003e7eed755124c962bf69af804678235355bb2","unresolved":false,"context_lines":[{"line_number":316,"context_line":"Neutron DB table: trunks"},{"line_number":317,"context_line":"  * id"},{"line_number":318,"context_line":"  * name"},{"line_number":319,"context_line":"  * tenant_id"},{"line_number":320,"context_line":"  * port_id: foreign key to ports.id"},{"line_number":321,"context_line":""},{"line_number":322,"context_line":"Neutron DB table: subports"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_61b935cb","line":319,"in_reply_to":"7a740942_898263c7","updated":"2015-12-10 14:26:44.000000000","message":"We may connect ports of different tenants as trunk and subports. In that case I believe the ownership of the trunk object should be explicit.\n\nOr is it enough if all trunk and possible subport instances implicitly belong to the tenant who owns the relevant port. And any cross-tenant trunk-subport relation can be manipulated by admin?\n\nI think it may not be, especially if we don\u0027t have a subport resource.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47cc480aee64c04489a304e53763c982bf15823c","unresolved":false,"context_lines":[{"line_number":317,"context_line":"  * id"},{"line_number":318,"context_line":"  * name"},{"line_number":319,"context_line":"  * tenant_id"},{"line_number":320,"context_line":"  * port_id: foreign key to ports.id"},{"line_number":321,"context_line":""},{"line_number":322,"context_line":"Neutron DB table: subports"},{"line_number":323,"context_line":"  * id [only for alt_two_resources]"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_49a31b9f","line":320,"updated":"2015-12-10 08:52:50.000000000","message":"the port_id should be the unique constraint\nwe should also have an insert/update trigger to ensure the port_id is not referenced in the subports table.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47cc480aee64c04489a304e53763c982bf15823c","unresolved":false,"context_lines":[{"line_number":322,"context_line":"Neutron DB table: subports"},{"line_number":323,"context_line":"  * id [only for alt_two_resources]"},{"line_number":324,"context_line":"  * name [only for alt_two_resources]"},{"line_number":325,"context_line":"  * tenant_id [only for alt_two_resources]"},{"line_number":326,"context_line":"  * port_id: foreign key to ports.id"},{"line_number":327,"context_line":"  * trunk_id: foreign key to trunks.id"},{"line_number":328,"context_line":"  * segmentation_type"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_495ebb46","line":325,"updated":"2015-12-10 08:52:50.000000000","message":"as above the tenant_id is a property of the port referenced by the port_id\nso should not be required here.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47cc480aee64c04489a304e53763c982bf15823c","unresolved":false,"context_lines":[{"line_number":323,"context_line":"  * id [only for alt_two_resources]"},{"line_number":324,"context_line":"  * name [only for alt_two_resources]"},{"line_number":325,"context_line":"  * tenant_id [only for alt_two_resources]"},{"line_number":326,"context_line":"  * port_id: foreign key to ports.id"},{"line_number":327,"context_line":"  * trunk_id: foreign key to trunks.id"},{"line_number":328,"context_line":"  * segmentation_type"},{"line_number":329,"context_line":"  * segmentation_id"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_a9eb9faf","line":326,"updated":"2015-12-10 08:52:50.000000000","message":"there should be an insert/update trigger to ensure the port_id is not referenced in the trunk table and this should be the table a unique constraint.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47cc480aee64c04489a304e53763c982bf15823c","unresolved":false,"context_lines":[{"line_number":324,"context_line":"  * name [only for alt_two_resources]"},{"line_number":325,"context_line":"  * tenant_id [only for alt_two_resources]"},{"line_number":326,"context_line":"  * port_id: foreign key to ports.id"},{"line_number":327,"context_line":"  * trunk_id: foreign key to trunks.id"},{"line_number":328,"context_line":"  * segmentation_type"},{"line_number":329,"context_line":"  * segmentation_id"},{"line_number":330,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_69a05791","line":327,"updated":"2015-12-10 08:52:50.000000000","message":"as per  comment above\nthis should reference the integer trunk port id field.\n\njoins on varchars or uuids make me sad when they can be avoided.\n\n(segmentation_type,segmentation_id,trunk_id) should be a second unique constraint on this table.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47cc480aee64c04489a304e53763c982bf15823c","unresolved":false,"context_lines":[{"line_number":329,"context_line":"  * segmentation_id"},{"line_number":330,"context_line":""},{"line_number":331,"context_line":"REST API Impact"},{"line_number":332,"context_line":"---------------"},{"line_number":333,"context_line":""},{"line_number":334,"context_line":"In case alt-two-resources:"},{"line_number":335,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_c7304fa1","line":332,"updated":"2015-12-10 08:52:50.000000000","message":"see comment on line 167 regarding rest api.","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47cc480aee64c04489a304e53763c982bf15823c","unresolved":false,"context_lines":[{"line_number":375,"context_line":""},{"line_number":376,"context_line":"Tenants should be aware that OpenStack does nothing to enable VMs"},{"line_number":377,"context_line":"to handle the tagged traffic, but just provides tagged packets. It"},{"line_number":378,"context_line":"is totally up to the user to set VMs up properly."},{"line_number":379,"context_line":""},{"line_number":380,"context_line":"Performance Impact"},{"line_number":381,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7a740942_67aabb87","line":378,"updated":"2015-12-10 08:52:50.000000000","message":"should we metion the segmentation info may be passed by the nova metadata service here also?","commit_id":"58c731e13410f6ad7e6a37f1278efdbbc51de86c"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"27f3d5ebad333c237a19b21ac62b16201aa77379","unresolved":false,"context_lines":[{"line_number":19,"context_line":"encapsulation) aware VM can differentiate between traffic of many networks by"},{"line_number":20,"context_line":"different encapsulation types and IDs, instead of using many vNICs. This"},{"line_number":21,"context_line":"approach scales to higher number of networks and enables dynamic handling of"},{"line_number":22,"context_line":"network attachments."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Problem Description"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_da70840a","line":22,"updated":"2015-12-14 16:22:45.000000000","message":"Technically you could already handle dynamic network attachments, but this certainly makes it more sane.  :-)","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"7354883b8d56e205a3c57a965dfa7e17968d2bde","unresolved":false,"context_lines":[{"line_number":19,"context_line":"encapsulation) aware VM can differentiate between traffic of many networks by"},{"line_number":20,"context_line":"different encapsulation types and IDs, instead of using many vNICs. This"},{"line_number":21,"context_line":"approach scales to higher number of networks and enables dynamic handling of"},{"line_number":22,"context_line":"network attachments."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Problem Description"}],"source_content_type":"text/x-rst","patch_set":8,"id":"5a710552_3916d855","line":22,"in_reply_to":"7a740942_da70840a","updated":"2015-12-16 15:09:32.000000000","message":"Adventurous people may prefer vNIC hotplugging. :-)","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"44b8f8717afd686b4deb72998ff2444a2758a0eb","unresolved":false,"context_lines":[{"line_number":84,"context_line":"has today (however some subport attributes must behave differently,"},{"line_number":85,"context_line":"eg. binding:host_id) and can be created on any Neutron network."},{"line_number":86,"context_line":"All needed information beyond legacy port attributes is contained in"},{"line_number":87,"context_line":"newly introduced resource(s) referring legacy ports.  A VLAN ID is just"},{"line_number":88,"context_line":"one possible encapsulation to use between the hypervisor and the guest"},{"line_number":89,"context_line":"to differentiate packets targeted at the regular port vs. one of the"},{"line_number":90,"context_line":"child ports."}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_d2f4365c","line":87,"updated":"2015-12-11 16:10:58.000000000","message":"VLAN is the only encapsulation allowed, you should update this line or better simply remove since you talk about the encapsulation later.","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"72cc8134c9f845b074359a83127d1b9ab7788bbb","unresolved":false,"context_lines":[{"line_number":84,"context_line":"has today (however some subport attributes must behave differently,"},{"line_number":85,"context_line":"eg. binding:host_id) and can be created on any Neutron network."},{"line_number":86,"context_line":"All needed information beyond legacy port attributes is contained in"},{"line_number":87,"context_line":"newly introduced resource(s) referring legacy ports.  A VLAN ID is just"},{"line_number":88,"context_line":"one possible encapsulation to use between the hypervisor and the guest"},{"line_number":89,"context_line":"to differentiate packets targeted at the regular port vs. one of the"},{"line_number":90,"context_line":"child ports."}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_daeba4a2","line":87,"in_reply_to":"7a740942_d2f4365c","updated":"2015-12-14 15:03:31.000000000","message":"Done","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"44b8f8717afd686b4deb72998ff2444a2758a0eb","unresolved":false,"context_lines":[{"line_number":104,"context_line":""},{"line_number":105,"context_line":"All ports referred must exist."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"Note that if a given plugin does not implement support for"},{"line_number":108,"context_line":"bp/vlan-aware-vms, this request will be rejected."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"Some backends, having no support for bp/vlan-aware-vms at all,"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_cc501d35","line":107,"updated":"2015-12-11 16:10:58.000000000","message":"These two lines are very clear, lines 110-118 are only details,  can be skipped.","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"f7b396ea713e18984f22f21a9f846bcde5f10070","unresolved":false,"context_lines":[{"line_number":115,"context_line":"if they accept any trunk-create calls, they must accept all trunk-create"},{"line_number":116,"context_line":"calls, for a port with binding:host_id not set. Handling of trunk-create"},{"line_number":117,"context_line":"calls for ports that have binding:host_id set already, the implementation"},{"line_number":118,"context_line":"is free to decide to accept or reject them, but must do the same for all."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"In addition to the logical topology piece, we need to define the type of"},{"line_number":121,"context_line":"encapsulation used between the hypervisor and VM for targeting packets to a"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_1d539818","line":118,"updated":"2015-12-12 03:01:46.000000000","message":"This paragraph may be simplified by saying:\n\nIf the plugin does not implement the extension any trunk operation will fail (with 404). If a plugin does implement the extension, trunk operations may return a conflict error if the port status is not compatible with the request.","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"72cc8134c9f845b074359a83127d1b9ab7788bbb","unresolved":false,"context_lines":[{"line_number":115,"context_line":"if they accept any trunk-create calls, they must accept all trunk-create"},{"line_number":116,"context_line":"calls, for a port with binding:host_id not set. Handling of trunk-create"},{"line_number":117,"context_line":"calls for ports that have binding:host_id set already, the implementation"},{"line_number":118,"context_line":"is free to decide to accept or reject them, but must do the same for all."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"In addition to the logical topology piece, we need to define the type of"},{"line_number":121,"context_line":"encapsulation used between the hypervisor and VM for targeting packets to a"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_da1964d2","line":118,"in_reply_to":"7a740942_1d539818","updated":"2015-12-14 15:03:31.000000000","message":"Done","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"44b8f8717afd686b4deb72998ff2444a2758a0eb","unresolved":false,"context_lines":[{"line_number":117,"context_line":"calls for ports that have binding:host_id set already, the implementation"},{"line_number":118,"context_line":"is free to decide to accept or reject them, but must do the same for all."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"In addition to the logical topology piece, we need to define the type of"},{"line_number":121,"context_line":"encapsulation used between the hypervisor and VM for targeting packets to a"},{"line_number":122,"context_line":"logical subport, as well as for determining the source logical port for a packet"},{"line_number":123,"context_line":"arriving from the VM.  A VLAN ID is just one possible encapsulation, though it"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_ef52abdd","line":120,"updated":"2015-12-11 16:10:58.000000000","message":"repetita iuvant but let\u0027s try to keep this crisp since the topic is complex enough. Lines 120-124 and 126-130 are about encapsulation, then again lines 152-155. Can you talk about this topic in one place (so move lines 152-155 here) and summarize a bit?","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"72cc8134c9f845b074359a83127d1b9ab7788bbb","unresolved":false,"context_lines":[{"line_number":117,"context_line":"calls for ports that have binding:host_id set already, the implementation"},{"line_number":118,"context_line":"is free to decide to accept or reject them, but must do the same for all."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"In addition to the logical topology piece, we need to define the type of"},{"line_number":121,"context_line":"encapsulation used between the hypervisor and VM for targeting packets to a"},{"line_number":122,"context_line":"logical subport, as well as for determining the source logical port for a packet"},{"line_number":123,"context_line":"arriving from the VM.  A VLAN ID is just one possible encapsulation, though it"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_b53269f0","line":120,"in_reply_to":"7a740942_ef52abdd","updated":"2015-12-14 15:03:31.000000000","message":"Done","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"f7b396ea713e18984f22f21a9f846bcde5f10070","unresolved":false,"context_lines":[{"line_number":141,"context_line":"The CLI has the following new commands:"},{"line_number":142,"context_line":""},{"line_number":143,"context_line":"* trunk-create"},{"line_number":144,"context_line":"* trunk-delete"},{"line_number":145,"context_line":"* trunk-list"},{"line_number":146,"context_line":"* trunk-show [should not print subports]"},{"line_number":147,"context_line":"* trunk-subport-add"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_fd9b2cc7","line":144,"updated":"2015-12-12 03:01:46.000000000","message":"You haven\u0027t mentioned how you\u0027re going to treat the delete operation: whether you are going to allow it or prevent it on the basis that subport-delete ops must be issued first. Thoughts?","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"72cc8134c9f845b074359a83127d1b9ab7788bbb","unresolved":false,"context_lines":[{"line_number":141,"context_line":"The CLI has the following new commands:"},{"line_number":142,"context_line":""},{"line_number":143,"context_line":"* trunk-create"},{"line_number":144,"context_line":"* trunk-delete"},{"line_number":145,"context_line":"* trunk-list"},{"line_number":146,"context_line":"* trunk-show [should not print subports]"},{"line_number":147,"context_line":"* trunk-subport-add"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_c0608e03","line":144,"in_reply_to":"7a740942_fd9b2cc7","updated":"2015-12-14 15:03:31.000000000","message":"Done","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"f7b396ea713e18984f22f21a9f846bcde5f10070","unresolved":false,"context_lines":[{"line_number":147,"context_line":"* trunk-subport-add"},{"line_number":148,"context_line":"* trunk-subport-delete"},{"line_number":149,"context_line":"* trunk-subport-list"},{"line_number":150,"context_line":"* trunk-subport-show [may prove unnecessary]"},{"line_number":151,"context_line":""},{"line_number":152,"context_line":"The encapsulation here is a local encapsulation used between the VM and"},{"line_number":153,"context_line":"hypervisor only.  It has nothing to do with how the Neutron network the port is"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_dd6f50c2","line":150,"updated":"2015-12-12 03:01:46.000000000","message":"It would (be necessary) if you want to show the segmentation details for the individual port, otherwise these must be shown in subport-list","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"44b8f8717afd686b4deb72998ff2444a2758a0eb","unresolved":false,"context_lines":[{"line_number":154,"context_line":"attached to is implemented.  It is only used to identify the source or"},{"line_number":155,"context_line":"destination logical port over a single VIF."},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"Subport details are also expected to be exposed to VMs via the Nova metadata"},{"line_number":158,"context_line":"service, though the details will most likely be tackled in a follow-up spec."},{"line_number":159,"context_line":"A possible model to follow is `Virtual guest device role tagging"},{"line_number":160,"context_line":"\u003chttps://review.openstack.org/#q,I16845bd36878bbd9d7a877dc556b2650bc6f0fad,n,z\u003e`_."}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_0fecd7f1","line":157,"updated":"2015-12-11 16:10:58.000000000","message":"I think having this in the reference section should be enough. Let\u0027s not add more details here since this is not the focus of this bp","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"72cc8134c9f845b074359a83127d1b9ab7788bbb","unresolved":false,"context_lines":[{"line_number":154,"context_line":"attached to is implemented.  It is only used to identify the source or"},{"line_number":155,"context_line":"destination logical port over a single VIF."},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"Subport details are also expected to be exposed to VMs via the Nova metadata"},{"line_number":158,"context_line":"service, though the details will most likely be tackled in a follow-up spec."},{"line_number":159,"context_line":"A possible model to follow is `Virtual guest device role tagging"},{"line_number":160,"context_line":"\u003chttps://review.openstack.org/#q,I16845bd36878bbd9d7a877dc556b2650bc6f0fad,n,z\u003e`_."}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_7a04ed16","line":157,"in_reply_to":"7a740942_0fecd7f1","updated":"2015-12-14 15:03:31.000000000","message":"Done","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"f7b396ea713e18984f22f21a9f846bcde5f10070","unresolved":false,"context_lines":[{"line_number":155,"context_line":"destination logical port over a single VIF."},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"Subport details are also expected to be exposed to VMs via the Nova metadata"},{"line_number":158,"context_line":"service, though the details will most likely be tackled in a follow-up spec."},{"line_number":159,"context_line":"A possible model to follow is `Virtual guest device role tagging"},{"line_number":160,"context_line":"\u003chttps://review.openstack.org/#q,I16845bd36878bbd9d7a877dc556b2650bc6f0fad,n,z\u003e`_."},{"line_number":161,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_bda124f9","line":158,"updated":"2015-12-12 03:01:46.000000000","message":"+1","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"44b8f8717afd686b4deb72998ff2444a2758a0eb","unresolved":false,"context_lines":[{"line_number":215,"context_line":"can be specified to match the parent\u0027s MAC address.  A parent and a subport"},{"line_number":216,"context_line":"having the same MAC address are not allowed to be on the same net."},{"line_number":217,"context_line":""},{"line_number":218,"context_line":"Nested subports (even with mixed encapsulation types) can be supported"},{"line_number":219,"context_line":"when specified by later specs.  Implementations may reject the request"},{"line_number":220,"context_line":"based on backend specific restrictions, though.  For example, using"},{"line_number":221,"context_line":"two levels of the VLAN segmentation type would require QinQ support,"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_0fa85776","line":218,"updated":"2015-12-11 16:10:58.000000000","message":"Here a simple line should suffice \"Nested subports are not supported.\"","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"72cc8134c9f845b074359a83127d1b9ab7788bbb","unresolved":false,"context_lines":[{"line_number":215,"context_line":"can be specified to match the parent\u0027s MAC address.  A parent and a subport"},{"line_number":216,"context_line":"having the same MAC address are not allowed to be on the same net."},{"line_number":217,"context_line":""},{"line_number":218,"context_line":"Nested subports (even with mixed encapsulation types) can be supported"},{"line_number":219,"context_line":"when specified by later specs.  Implementations may reject the request"},{"line_number":220,"context_line":"based on backend specific restrictions, though.  For example, using"},{"line_number":221,"context_line":"two levels of the VLAN segmentation type would require QinQ support,"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_bd3c8fc8","line":218,"in_reply_to":"7a740942_0fa85776","updated":"2015-12-14 15:03:31.000000000","message":"Done","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"44b8f8717afd686b4deb72998ff2444a2758a0eb","unresolved":false,"context_lines":[{"line_number":231,"context_line":"  segmentation_id) among its siblings.  Otherwise, it would not be possible"},{"line_number":232,"context_line":"  to properly differentiate the source and destination logical port."},{"line_number":233,"context_line":""},{"line_number":234,"context_line":"* The parent port handles \"untagged\" traffic. In case of nested subports,"},{"line_number":235,"context_line":"  the top level (\"root\") port handles \"untagged\" traffic. The parent"},{"line_number":236,"context_line":"  will receive all the packets that do not match a sub-port, which is no"},{"line_number":237,"context_line":"  different than how a regular port already behaves today.  This also"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_af61033b","line":234,"updated":"2015-12-11 16:10:58.000000000","message":"since we are not supporting nested subports in this spec I guess we can avoid adding details about something that we are not going to implement in this scope.","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"f7b396ea713e18984f22f21a9f846bcde5f10070","unresolved":false,"context_lines":[{"line_number":231,"context_line":"  segmentation_id) among its siblings.  Otherwise, it would not be possible"},{"line_number":232,"context_line":"  to properly differentiate the source and destination logical port."},{"line_number":233,"context_line":""},{"line_number":234,"context_line":"* The parent port handles \"untagged\" traffic. In case of nested subports,"},{"line_number":235,"context_line":"  the top level (\"root\") port handles \"untagged\" traffic. The parent"},{"line_number":236,"context_line":"  will receive all the packets that do not match a sub-port, which is no"},{"line_number":237,"context_line":"  different than how a regular port already behaves today.  This also"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_dda6700e","line":234,"in_reply_to":"7a740942_af61033b","updated":"2015-12-12 03:01:46.000000000","message":"+1","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"72cc8134c9f845b074359a83127d1b9ab7788bbb","unresolved":false,"context_lines":[{"line_number":231,"context_line":"  segmentation_id) among its siblings.  Otherwise, it would not be possible"},{"line_number":232,"context_line":"  to properly differentiate the source and destination logical port."},{"line_number":233,"context_line":""},{"line_number":234,"context_line":"* The parent port handles \"untagged\" traffic. In case of nested subports,"},{"line_number":235,"context_line":"  the top level (\"root\") port handles \"untagged\" traffic. The parent"},{"line_number":236,"context_line":"  will receive all the packets that do not match a sub-port, which is no"},{"line_number":237,"context_line":"  different than how a regular port already behaves today.  This also"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_3d841f5c","line":234,"in_reply_to":"7a740942_af61033b","updated":"2015-12-14 15:03:31.000000000","message":"Done","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"f7b396ea713e18984f22f21a9f846bcde5f10070","unresolved":false,"context_lines":[{"line_number":251,"context_line":"* A normal user can only connect subports to its own parent ports. Admin"},{"line_number":252,"context_line":"  can connect subports to parent ports of different owners."},{"line_number":253,"context_line":""},{"line_number":254,"context_line":"* Until OVS supports QinQ, an OVS based Neutron backend can not support having a"},{"line_number":255,"context_line":"  subport attached to a \"vlan_transparent\" network.  That would require the"},{"line_number":256,"context_line":"  abilty to transport VLAN tagged traffic over the VLAN tagged subport interface"},{"line_number":257,"context_line":"  (nested VLANs), which is not yet possible."}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_9dad48eb","line":254,"updated":"2015-12-12 03:01:46.000000000","message":"can not -\u003e cannot","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"44b8f8717afd686b4deb72998ff2444a2758a0eb","unresolved":false,"context_lines":[{"line_number":266,"context_line":"Currently, Nova only supports a single bridge name provided by the Nova"},{"line_number":267,"context_line":"configuration file."},{"line_number":268,"context_line":""},{"line_number":269,"context_line":"The change needed for the existing OVS VIF type has `its own blueprint"},{"line_number":270,"context_line":"\u003chttps://blueprints.launchpad.net/nova/+spec/neutron-ovs-bridge-name\u003e`_."},{"line_number":271,"context_line":""},{"line_number":272,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_cc649dba","line":269,"updated":"2015-12-11 16:10:58.000000000","message":"this should be listed under \"Dependencies\" if we depend on it","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"72cc8134c9f845b074359a83127d1b9ab7788bbb","unresolved":false,"context_lines":[{"line_number":266,"context_line":"Currently, Nova only supports a single bridge name provided by the Nova"},{"line_number":267,"context_line":"configuration file."},{"line_number":268,"context_line":""},{"line_number":269,"context_line":"The change needed for the existing OVS VIF type has `its own blueprint"},{"line_number":270,"context_line":"\u003chttps://blueprints.launchpad.net/nova/+spec/neutron-ovs-bridge-name\u003e`_."},{"line_number":271,"context_line":""},{"line_number":272,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_bdc6cf97","line":269,"in_reply_to":"7a740942_cc649dba","updated":"2015-12-14 15:03:31.000000000","message":"Done","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"f7b396ea713e18984f22f21a9f846bcde5f10070","unresolved":false,"context_lines":[{"line_number":272,"context_line":"Alternatives"},{"line_number":273,"context_line":"------------"},{"line_number":274,"context_line":""},{"line_number":275,"context_line":"For alternatives please see the long (and complicated) history of the spec,"},{"line_number":276,"context_line":"including:"},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"* v1: https://review.openstack.org/#q,I015762abe197b91916374143410b1f182908909e,n,z"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_5db3604d","line":275,"updated":"2015-12-12 03:01:46.000000000","message":"troubled I should say...no seriously, no need to make qualifying statements :)","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"72cc8134c9f845b074359a83127d1b9ab7788bbb","unresolved":false,"context_lines":[{"line_number":272,"context_line":"Alternatives"},{"line_number":273,"context_line":"------------"},{"line_number":274,"context_line":""},{"line_number":275,"context_line":"For alternatives please see the long (and complicated) history of the spec,"},{"line_number":276,"context_line":"including:"},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"* v1: https://review.openstack.org/#q,I015762abe197b91916374143410b1f182908909e,n,z"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_5d632bb1","line":275,"in_reply_to":"7a740942_5db3604d","updated":"2015-12-14 15:03:31.000000000","message":"Done","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"f7b396ea713e18984f22f21a9f846bcde5f10070","unresolved":false,"context_lines":[{"line_number":291,"context_line":""},{"line_number":292,"context_line":"Neutron DB table: trunks"},{"line_number":293,"context_line":""},{"line_number":294,"context_line":"* id: integer primary key"},{"line_number":295,"context_line":"* uuid"},{"line_number":296,"context_line":"* name"},{"line_number":297,"context_line":"* tenant_id"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_1d887870","line":294,"updated":"2015-12-12 03:01:46.000000000","message":"is that because of the standardattributes table?","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"72cc8134c9f845b074359a83127d1b9ab7788bbb","unresolved":false,"context_lines":[{"line_number":291,"context_line":""},{"line_number":292,"context_line":"Neutron DB table: trunks"},{"line_number":293,"context_line":""},{"line_number":294,"context_line":"* id: integer primary key"},{"line_number":295,"context_line":"* uuid"},{"line_number":296,"context_line":"* name"},{"line_number":297,"context_line":"* tenant_id"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_fdfbf778","line":294,"in_reply_to":"7a740942_1d887870","updated":"2015-12-14 15:03:31.000000000","message":"Not because of standardattributes, but because Sean asked us to join on integer keys instead of varchar keys.","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"f7b396ea713e18984f22f21a9f846bcde5f10070","unresolved":false,"context_lines":[{"line_number":294,"context_line":"* id: integer primary key"},{"line_number":295,"context_line":"* uuid"},{"line_number":296,"context_line":"* name"},{"line_number":297,"context_line":"* tenant_id"},{"line_number":298,"context_line":"* port_id: foreign key to ports.id"},{"line_number":299,"context_line":""},{"line_number":300,"context_line":"Neutron DB table: subports"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_7d973c90","line":297,"updated":"2015-12-12 03:01:46.000000000","message":"I\u0027d call this parent_id, but up to you.","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"44b8f8717afd686b4deb72998ff2444a2758a0eb","unresolved":false,"context_lines":[{"line_number":295,"context_line":"* uuid"},{"line_number":296,"context_line":"* name"},{"line_number":297,"context_line":"* tenant_id"},{"line_number":298,"context_line":"* port_id: foreign key to ports.id"},{"line_number":299,"context_line":""},{"line_number":300,"context_line":"Neutron DB table: subports"},{"line_number":301,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_d5a740bb","line":298,"updated":"2015-12-11 16:10:58.000000000","message":"port_id is the parent port? where are the subports, we should have them in this table right?","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"f7b396ea713e18984f22f21a9f846bcde5f10070","unresolved":false,"context_lines":[{"line_number":295,"context_line":"* uuid"},{"line_number":296,"context_line":"* name"},{"line_number":297,"context_line":"* tenant_id"},{"line_number":298,"context_line":"* port_id: foreign key to ports.id"},{"line_number":299,"context_line":""},{"line_number":300,"context_line":"Neutron DB table: subports"},{"line_number":301,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_bd78447f","line":298,"in_reply_to":"7a740942_3649e7b7","updated":"2015-12-12 03:01:46.000000000","message":"Rossella, DBMS 101!","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a30196ad7ed324868ef0b9f8d9911b61c81cc01e","unresolved":false,"context_lines":[{"line_number":295,"context_line":"* uuid"},{"line_number":296,"context_line":"* name"},{"line_number":297,"context_line":"* tenant_id"},{"line_number":298,"context_line":"* port_id: foreign key to ports.id"},{"line_number":299,"context_line":""},{"line_number":300,"context_line":"Neutron DB table: subports"},{"line_number":301,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_3649e7b7","line":298,"in_reply_to":"7a740942_d5a740bb","updated":"2015-12-11 18:32:00.000000000","message":"no to have a normalized db schema the subports should not be in this table.\n\nthe python trunk object can still contain a list of its subports but they do not need to be stored in the same table.","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"f7b396ea713e18984f22f21a9f846bcde5f10070","unresolved":false,"context_lines":[{"line_number":299,"context_line":""},{"line_number":300,"context_line":"Neutron DB table: subports"},{"line_number":301,"context_line":""},{"line_number":302,"context_line":"* id"},{"line_number":303,"context_line":"* port_id: foreign key to ports.id"},{"line_number":304,"context_line":"* trunk_id: foreign key to trunks.id"},{"line_number":305,"context_line":"* segmentation_type"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_fde9ec1a","line":302,"updated":"2015-12-12 03:01:46.000000000","message":"do you want a uuid for the subport?","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"72cc8134c9f845b074359a83127d1b9ab7788bbb","unresolved":false,"context_lines":[{"line_number":299,"context_line":""},{"line_number":300,"context_line":"Neutron DB table: subports"},{"line_number":301,"context_line":""},{"line_number":302,"context_line":"* id"},{"line_number":303,"context_line":"* port_id: foreign key to ports.id"},{"line_number":304,"context_line":"* trunk_id: foreign key to trunks.id"},{"line_number":305,"context_line":"* segmentation_type"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_8018461f","line":302,"in_reply_to":"7a740942_fde9ec1a","updated":"2015-12-14 15:03:31.000000000","message":"I guess I don\u0027t. Accordingly I have deleted subport-show too.","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"44b8f8717afd686b4deb72998ff2444a2758a0eb","unresolved":false,"context_lines":[{"line_number":309,"context_line":""},{"line_number":310,"context_line":"* (segmentation_type, segmentation_id, trunk_id) must be unique in the"},{"line_number":311,"context_line":"  subports table"},{"line_number":312,"context_line":"* In the case of not having support for port nesting yet, ports referred"},{"line_number":313,"context_line":"  by trunks.port_id must not be referred by subports.port_id and vice versa."},{"line_number":314,"context_line":""},{"line_number":315,"context_line":"REST API Impact"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_4f0bbf2a","line":312,"updated":"2015-12-11 16:10:58.000000000","message":"port nesting is not supported, change this line accordingly please","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"72cc8134c9f845b074359a83127d1b9ab7788bbb","unresolved":false,"context_lines":[{"line_number":309,"context_line":""},{"line_number":310,"context_line":"* (segmentation_type, segmentation_id, trunk_id) must be unique in the"},{"line_number":311,"context_line":"  subports table"},{"line_number":312,"context_line":"* In the case of not having support for port nesting yet, ports referred"},{"line_number":313,"context_line":"  by trunks.port_id must not be referred by subports.port_id and vice versa."},{"line_number":314,"context_line":""},{"line_number":315,"context_line":"REST API Impact"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_c0d08e21","line":312,"in_reply_to":"7a740942_4f0bbf2a","updated":"2015-12-14 15:03:31.000000000","message":"Done","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a30196ad7ed324868ef0b9f8d9911b61c81cc01e","unresolved":false,"context_lines":[{"line_number":326,"context_line":"    POST /v2.0/trunks"},{"line_number":327,"context_line":"         ..."},{"line_number":328,"context_line":"    PUT /v2.0/trunks/TRUNK-ID/add_subports"},{"line_number":329,"context_line":"    PUT /v2.0/trunks/TRUNK-ID/delete_subports"},{"line_number":330,"context_line":"         {\u0027subports\u0027:"},{"line_number":331,"context_line":"             [{\u0027port_id\u0027: PORT_ID,"},{"line_number":332,"context_line":"               \u0027segmentation_type\u0027: SEGMENTATION_TYPE,"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_295d0815","line":329,"updated":"2015-12-11 18:32:00.000000000","message":"i think the following would be cleaner\n\nPUT /v2.0/trunks/TRUNK-ID/subports (add subports)\nDELETE /v2.0/trunks/TRUNK-ID/subports (deletes subports)\n\nthat way the same url /v2.0/trunks/TRUNK-ID/subports\nis used to list,add and delete subports.\n\nthat is a personal preference though as i dislike apis the form \u003cverb\u003e_\u003cresource\u003e\nas they require a new endpoint for every new action.\n\ni think current form is also ok so this is just a suggestion not an objection.","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"72cc8134c9f845b074359a83127d1b9ab7788bbb","unresolved":false,"context_lines":[{"line_number":326,"context_line":"    POST /v2.0/trunks"},{"line_number":327,"context_line":"         ..."},{"line_number":328,"context_line":"    PUT /v2.0/trunks/TRUNK-ID/add_subports"},{"line_number":329,"context_line":"    PUT /v2.0/trunks/TRUNK-ID/delete_subports"},{"line_number":330,"context_line":"         {\u0027subports\u0027:"},{"line_number":331,"context_line":"             [{\u0027port_id\u0027: PORT_ID,"},{"line_number":332,"context_line":"               \u0027segmentation_type\u0027: SEGMENTATION_TYPE,"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_000a1679","line":329,"in_reply_to":"7a740942_295d0815","updated":"2015-12-14 15:03:31.000000000","message":"I see your point. However this is how router-interface add and delete works. Uniformity has its value too.","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a30196ad7ed324868ef0b9f8d9911b61c81cc01e","unresolved":false,"context_lines":[{"line_number":406,"context_line":"* Tempest scenario test(s) for doing functional validation"},{"line_number":407,"context_line":"* Neutron Plugin support."},{"line_number":408,"context_line":"  * networking-ovn (OVN supports this model already)"},{"line_number":409,"context_line":"  * ml2+ovs"},{"line_number":410,"context_line":"* Expose subport information in nova metadata service (likely will require a new"},{"line_number":411,"context_line":"  spec)"},{"line_number":412,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_a96fb8fa","line":409,"updated":"2015-12-11 18:32:00.000000000","message":"just one procedural question for my own knowledge. \n\nassuming the spec is approved. \nif we wanted to add support for another backend this cycle\nshould we submit a separate patch to update the spec or would an an rfe\nbug that referenced the spec be the correct approach. \n\nim thinking of backends like networking-odl. i think changes might be required in the odl netvirt app but if that was done in this cycle it would be good to add too.  this is something i will try to look into offline.","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"f7b396ea713e18984f22f21a9f846bcde5f10070","unresolved":false,"context_lines":[{"line_number":406,"context_line":"* Tempest scenario test(s) for doing functional validation"},{"line_number":407,"context_line":"* Neutron Plugin support."},{"line_number":408,"context_line":"  * networking-ovn (OVN supports this model already)"},{"line_number":409,"context_line":"  * ml2+ovs"},{"line_number":410,"context_line":"* Expose subport information in nova metadata service (likely will require a new"},{"line_number":411,"context_line":"  spec)"},{"line_number":412,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_ddf430f2","line":409,"in_reply_to":"7a740942_a96fb8fa","updated":"2015-12-12 03:01:46.000000000","message":"If you don\u0027t need changes to neutron proper, go nuts without oversight!","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"f7b396ea713e18984f22f21a9f846bcde5f10070","unresolved":false,"context_lines":[{"line_number":418,"context_line":""},{"line_number":419,"context_line":"Tempest and functional tests will be created."},{"line_number":420,"context_line":""},{"line_number":421,"context_line":"Tempest Tests"},{"line_number":422,"context_line":"-------------"},{"line_number":423,"context_line":""},{"line_number":424,"context_line":"Tempest tests to be implemented:"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_1dd6384f","line":421,"updated":"2015-12-12 03:01:46.000000000","message":"We should not develop tempest tests (i.e. to be committed to the tempest tree). We should leverage fullstack and functional coverage (and in-tree api tests). Reach out to Assaf for details.","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"72cc8134c9f845b074359a83127d1b9ab7788bbb","unresolved":false,"context_lines":[{"line_number":418,"context_line":""},{"line_number":419,"context_line":"Tempest and functional tests will be created."},{"line_number":420,"context_line":""},{"line_number":421,"context_line":"Tempest Tests"},{"line_number":422,"context_line":"-------------"},{"line_number":423,"context_line":""},{"line_number":424,"context_line":"Tempest tests to be implemented:"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7a740942_804cc6c8","line":421,"in_reply_to":"7a740942_1dd6384f","updated":"2015-12-14 15:03:31.000000000","message":"Will do.","commit_id":"71eed8b292c9978c925646b0f94e813abb7027a2"},{"author":{"_account_id":6558,"name":"Sukhdev Kapur","email":"sukhdevkapur@gmail.com","username":"sukhdev-8"},"change_message_id":"f24bb836e28110080844ac2f43d58ace87e82629","unresolved":false,"context_lines":[{"line_number":50,"context_line":""},{"line_number":51,"context_line":"* There are legacy applications that expect to use VLANs as a way to connect to"},{"line_number":52,"context_line":"  multiple networks.  Neutron should provide a way to expose that model to the"},{"line_number":53,"context_line":"  VM decoupled from how the network is actually implemented."},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"The proposal may look related in some sense to the VLAN-transparent"},{"line_number":56,"context_line":"approach (bp/nfv-vlan-trunks), but differs in that it doesn\u0027t provide a"}],"source_content_type":"text/x-rst","patch_set":9,"id":"7a740942_5a56c62a","line":53,"updated":"2015-12-14 17:55:39.000000000","message":"Another use case is baremetal deployments. This feature will be highly desirable when baremetal servers will be utilized to host services - which will require tagged and untagged traffic","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"ae987859a7289b197d4316544f8d47b39e38ae11","unresolved":false,"context_lines":[{"line_number":50,"context_line":""},{"line_number":51,"context_line":"* There are legacy applications that expect to use VLANs as a way to connect to"},{"line_number":52,"context_line":"  multiple networks.  Neutron should provide a way to expose that model to the"},{"line_number":53,"context_line":"  VM decoupled from how the network is actually implemented."},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"The proposal may look related in some sense to the VLAN-transparent"},{"line_number":56,"context_line":"approach (bp/nfv-vlan-trunks), but differs in that it doesn\u0027t provide a"}],"source_content_type":"text/x-rst","patch_set":9,"id":"3a7e1126_e2e1e7ff","line":53,"in_reply_to":"7a740942_5a56c62a","updated":"2015-12-17 03:27:24.000000000","message":"ack, but let\u0027s not bloat the list, otherwise people start thinking, the masses mobilize, they turns into a mob, and the revolution destroy order and civilization.","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"ae987859a7289b197d4316544f8d47b39e38ae11","unresolved":false,"context_lines":[{"line_number":95,"context_line":"::"},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"    # trunk-create may refer to 0, 1 or more subport(s)."},{"line_number":98,"context_line":"    $ neutron trunk-create --port-id PORT \\"},{"line_number":99,"context_line":"                          [--subport PORT,SEGMENTATION-TYPE,SEGMENTATION-ID] \\"},{"line_number":100,"context_line":"                          [--subport ...]"},{"line_number":101,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"3a7e1126_02b673dc","line":98,"range":{"start_line":98,"start_character":29,"end_line":98,"end_character":33},"updated":"2015-12-17 03:27:24.000000000","message":"say that the port is already in use (e.g. connected to a VM already). Do we allow the operation or reject it saying the port is in use? I\u0027d tempted to say the former, but then this may have implications on how we implement trunk ports in the backend (e.g. one bridge per port, any port).","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"0982da5a72a56f00ae8ac5c699035aa93904bb7b","unresolved":false,"context_lines":[{"line_number":95,"context_line":"::"},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"    # trunk-create may refer to 0, 1 or more subport(s)."},{"line_number":98,"context_line":"    $ neutron trunk-create --port-id PORT \\"},{"line_number":99,"context_line":"                          [--subport PORT,SEGMENTATION-TYPE,SEGMENTATION-ID] \\"},{"line_number":100,"context_line":"                          [--subport ...]"},{"line_number":101,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"3a7e1126_c41aa217","line":98,"range":{"start_line":98,"start_character":29,"end_line":98,"end_character":33},"in_reply_to":"3a7e1126_02b673dc","updated":"2015-12-18 10:29:31.000000000","message":"I\u0027d like to keep this open to allow both implementations.\n\nSo let\u0027s assume for the first implementation with ovs we go for creating a trunk bridge only for trunk ports.\n\n Pro: smaller scope\n Con: cannot turn a port already owned into a trunk port\n API: reject trunk-create for ports already owned/bound\n\nLater I hope we can improve and have a generic ovs model, which fits both legacy ports and trunk ports.\n\n Pro: can turn a port already owned into a trunk port\n Con: more work in ovs-agent\n API: allow trunk-create for ports already owned/bound\n\nThis is what I tried to cover around lines 107-109 before. Shall I bring that back? Or write something else about it?","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"55e9c1caf356dde391cf66023ce7a01e1b000948","unresolved":false,"context_lines":[{"line_number":95,"context_line":"::"},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"    # trunk-create may refer to 0, 1 or more subport(s)."},{"line_number":98,"context_line":"    $ neutron trunk-create --port-id PORT \\"},{"line_number":99,"context_line":"                          [--subport PORT,SEGMENTATION-TYPE,SEGMENTATION-ID] \\"},{"line_number":100,"context_line":"                          [--subport ...]"},{"line_number":101,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"3a7e1126_fa47bcb9","line":98,"range":{"start_line":98,"start_character":29,"end_line":98,"end_character":33},"in_reply_to":"3a7e1126_c41aa217","updated":"2015-12-19 01:03:59.000000000","message":"We may say that allowing trunk creation for ports actively in use by VMs may be implementation dependent. Some backends may reject the request, others may allow it.","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":9200,"name":"IWAMOTO Toshihiro","email":"iwamoto@valinux.co.jp","username":"toshii"},"change_message_id":"a5ed969c9bb187b5c6abd87a3692281de0093338","unresolved":false,"context_lines":[{"line_number":97,"context_line":"    # trunk-create may refer to 0, 1 or more subport(s)."},{"line_number":98,"context_line":"    $ neutron trunk-create --port-id PORT \\"},{"line_number":99,"context_line":"                          [--subport PORT,SEGMENTATION-TYPE,SEGMENTATION-ID] \\"},{"line_number":100,"context_line":"                          [--subport ...]"},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"All ports referred must exist."},{"line_number":103,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a710552_214f9bbe","line":100,"updated":"2015-12-16 05:47:11.000000000","message":"Will this command return a new trunk ID?","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"35b043420650d2ce341d0d08d10dca04e992eb40","unresolved":false,"context_lines":[{"line_number":97,"context_line":"    # trunk-create may refer to 0, 1 or more subport(s)."},{"line_number":98,"context_line":"    $ neutron trunk-create --port-id PORT \\"},{"line_number":99,"context_line":"                          [--subport PORT,SEGMENTATION-TYPE,SEGMENTATION-ID] \\"},{"line_number":100,"context_line":"                          [--subport ...]"},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"All ports referred must exist."},{"line_number":103,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a710552_79f22071","line":100,"in_reply_to":"5a710552_214f9bbe","updated":"2015-12-16 15:23:01.000000000","message":"Yes.","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":9200,"name":"IWAMOTO Toshihiro","email":"iwamoto@valinux.co.jp","username":"toshii"},"change_message_id":"a5ed969c9bb187b5c6abd87a3692281de0093338","unresolved":false,"context_lines":[{"line_number":105,"context_line":"bp/vlan-aware-vms, this request will be rejected."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"If the backend does not implement the extension any trunk operation will fail"},{"line_number":108,"context_line":"(with 404). If a plugin does implement the extension, trunk operations may"},{"line_number":109,"context_line":"return a conflict error if the port status is not compatible with the request."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"In addition to the logical topology piece, we need to define the type"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a710552_21dc7b11","line":108,"updated":"2015-12-16 05:47:11.000000000","message":"404 is NotFound error.  I think 400 BadRequest is better suited here.","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"dfd5c9830a9267e297f2c8c6ff033231344c25c1","unresolved":false,"context_lines":[{"line_number":105,"context_line":"bp/vlan-aware-vms, this request will be rejected."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"If the backend does not implement the extension any trunk operation will fail"},{"line_number":108,"context_line":"(with 404). If a plugin does implement the extension, trunk operations may"},{"line_number":109,"context_line":"return a conflict error if the port status is not compatible with the request."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"In addition to the logical topology piece, we need to define the type"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a710552_efbf39f9","line":108,"in_reply_to":"5a710552_21dc7b11","updated":"2015-12-16 06:56:42.000000000","message":"That\u0027s not how the extension framework works. Try it yourself.","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":6558,"name":"Sukhdev Kapur","email":"sukhdevkapur@gmail.com","username":"sukhdev-8"},"change_message_id":"f24bb836e28110080844ac2f43d58ace87e82629","unresolved":false,"context_lines":[{"line_number":112,"context_line":"of encapsulation (segmentation) used between the hypervisor and VM for"},{"line_number":113,"context_line":"targeting packets to a logical subport, as well as for determining the"},{"line_number":114,"context_line":"source logical port for a packet arriving from the VM. The encapsulation"},{"line_number":115,"context_line":"here is local, used between the VM and hypervisor only.  It has nothing"},{"line_number":116,"context_line":"to do with how the Neutron network the port is attached to is implemented."},{"line_number":117,"context_line":"SEGMENTATION-TYPE is an enum of strings, currently having one valid value"},{"line_number":118,"context_line":"\u0027vlan\u0027. SEGMENTATION-ID is an unsigned integer.  SEGMENTATION-TYPE and"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a710552_70106e4f","line":115,"updated":"2015-12-14 17:55:39.000000000","message":"For baremetal deployments, the main (parent port) may use untagged (native vlans) and sub-ports will use tagged traffic.","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"ae987859a7289b197d4316544f8d47b39e38ae11","unresolved":false,"context_lines":[{"line_number":112,"context_line":"of encapsulation (segmentation) used between the hypervisor and VM for"},{"line_number":113,"context_line":"targeting packets to a logical subport, as well as for determining the"},{"line_number":114,"context_line":"source logical port for a packet arriving from the VM. The encapsulation"},{"line_number":115,"context_line":"here is local, used between the VM and hypervisor only.  It has nothing"},{"line_number":116,"context_line":"to do with how the Neutron network the port is attached to is implemented."},{"line_number":117,"context_line":"SEGMENTATION-TYPE is an enum of strings, currently having one valid value"},{"line_number":118,"context_line":"\u0027vlan\u0027. SEGMENTATION-ID is an unsigned integer.  SEGMENTATION-TYPE and"}],"source_content_type":"text/x-rst","patch_set":9,"id":"3a7e1126_a2c75f44","line":115,"in_reply_to":"5a710552_70106e4f","updated":"2015-12-17 03:27:24.000000000","message":"Scope creep! Scope creep!!","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":6558,"name":"Sukhdev Kapur","email":"sukhdevkapur@gmail.com","username":"sukhdev-8"},"change_message_id":"f24bb836e28110080844ac2f43d58ace87e82629","unresolved":false,"context_lines":[{"line_number":122,"context_line":"::"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"    # trunk-add-subport adds 1 or more subport(s)"},{"line_number":125,"context_line":"    $ neutron trunk-subport-add TRUNK \\"},{"line_number":126,"context_line":"                                PORT,SEGMENTATION-TYPE,SEGMENTATION-ID \\"},{"line_number":127,"context_line":"                               [PORT,...]"},{"line_number":128,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a710552_10f1eacd","line":125,"updated":"2015-12-14 17:55:39.000000000","message":"This information is needed by ML2 Mech drivers to plumb the back-ends, therefore, I am assuming this API will invoke ML2 pre/post commit calls - please clarify ( See my comment in the work Items section below)","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"ae987859a7289b197d4316544f8d47b39e38ae11","unresolved":false,"context_lines":[{"line_number":122,"context_line":"::"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"    # trunk-add-subport adds 1 or more subport(s)"},{"line_number":125,"context_line":"    $ neutron trunk-subport-add TRUNK \\"},{"line_number":126,"context_line":"                                PORT,SEGMENTATION-TYPE,SEGMENTATION-ID \\"},{"line_number":127,"context_line":"                               [PORT,...]"},{"line_number":128,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"3a7e1126_624657c1","line":125,"in_reply_to":"5a710552_10f1eacd","updated":"2015-12-17 03:27:24.000000000","message":"This specification has nothing to do with ML2. In the reference implementation I would expect that this information be stored as any other resource attribute made available to ML2 during its operations. I don\u0027t think this should be clarified in this spec.","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"ae987859a7289b197d4316544f8d47b39e38ae11","unresolved":false,"context_lines":[{"line_number":128,"context_line":""},{"line_number":129,"context_line":"All ports referred must exist."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"The following deletion constraints exist:"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"* Deletion of a trunk automatically deletes all of its subports."},{"line_number":134,"context_line":"* Deletion of a port referred by subport automatically deletes the relevant"}],"source_content_type":"text/x-rst","patch_set":9,"id":"3a7e1126_029513e3","line":131,"range":{"start_line":131,"start_character":14,"end_line":131,"end_character":22},"updated":"2015-12-17 03:27:24.000000000","message":"have you considered moving all the constraints together?","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"0982da5a72a56f00ae8ac5c699035aa93904bb7b","unresolved":false,"context_lines":[{"line_number":128,"context_line":""},{"line_number":129,"context_line":"All ports referred must exist."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"The following deletion constraints exist:"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"* Deletion of a trunk automatically deletes all of its subports."},{"line_number":134,"context_line":"* Deletion of a port referred by subport automatically deletes the relevant"}],"source_content_type":"text/x-rst","patch_set":9,"id":"3a7e1126_af4fdfbb","line":131,"range":{"start_line":131,"start_character":14,"end_line":131,"end_character":22},"in_reply_to":"3a7e1126_029513e3","updated":"2015-12-18 10:29:31.000000000","message":"Done","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"ae987859a7289b197d4316544f8d47b39e38ae11","unresolved":false,"context_lines":[{"line_number":130,"context_line":""},{"line_number":131,"context_line":"The following deletion constraints exist:"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"* Deletion of a trunk automatically deletes all of its subports."},{"line_number":134,"context_line":"* Deletion of a port referred by subport automatically deletes the relevant"},{"line_number":135,"context_line":"  subport."},{"line_number":136,"context_line":"* Deletion of a port referred by a trunk automatically deletes the relevant"}],"source_content_type":"text/x-rst","patch_set":9,"id":"3a7e1126_027993fc","line":133,"range":{"start_line":133,"start_character":22,"end_line":133,"end_character":35},"updated":"2015-12-17 03:27:24.000000000","message":"and parent port?","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"0982da5a72a56f00ae8ac5c699035aa93904bb7b","unresolved":false,"context_lines":[{"line_number":130,"context_line":""},{"line_number":131,"context_line":"The following deletion constraints exist:"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"* Deletion of a trunk automatically deletes all of its subports."},{"line_number":134,"context_line":"* Deletion of a port referred by subport automatically deletes the relevant"},{"line_number":135,"context_line":"  subport."},{"line_number":136,"context_line":"* Deletion of a port referred by a trunk automatically deletes the relevant"}],"source_content_type":"text/x-rst","patch_set":9,"id":"3a7e1126_ef5f273f","line":133,"range":{"start_line":133,"start_character":22,"end_line":133,"end_character":35},"in_reply_to":"3a7e1126_027993fc","updated":"2015-12-18 10:29:31.000000000","message":"If we do that we close the option of demoting a trunk port back into a legacy port forever. We may want to reject it if the implementation does not support it, but I don\u0027t want to put this limitation into the API.","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"ae987859a7289b197d4316544f8d47b39e38ae11","unresolved":false,"context_lines":[{"line_number":133,"context_line":"* Deletion of a trunk automatically deletes all of its subports."},{"line_number":134,"context_line":"* Deletion of a port referred by subport automatically deletes the relevant"},{"line_number":135,"context_line":"  subport."},{"line_number":136,"context_line":"* Deletion of a port referred by a trunk automatically deletes the relevant"},{"line_number":137,"context_line":"  trunk."},{"line_number":138,"context_line":"* Deletion of a port referred by a trunk automatically deletes all ports"},{"line_number":139,"context_line":"  referred as subports. That is deletion of a parent port \"cascades\" to the"}],"source_content_type":"text/x-rst","patch_set":9,"id":"3a7e1126_e21007ab","line":136,"range":{"start_line":136,"start_character":16,"end_line":136,"end_character":20},"updated":"2015-12-17 03:27:24.000000000","message":"you mean the parent port?","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"0982da5a72a56f00ae8ac5c699035aa93904bb7b","unresolved":false,"context_lines":[{"line_number":133,"context_line":"* Deletion of a trunk automatically deletes all of its subports."},{"line_number":134,"context_line":"* Deletion of a port referred by subport automatically deletes the relevant"},{"line_number":135,"context_line":"  subport."},{"line_number":136,"context_line":"* Deletion of a port referred by a trunk automatically deletes the relevant"},{"line_number":137,"context_line":"  trunk."},{"line_number":138,"context_line":"* Deletion of a port referred by a trunk automatically deletes all ports"},{"line_number":139,"context_line":"  referred as subports. That is deletion of a parent port \"cascades\" to the"}],"source_content_type":"text/x-rst","patch_set":9,"id":"3a7e1126_61382ba1","line":136,"range":{"start_line":136,"start_character":16,"end_line":136,"end_character":20},"in_reply_to":"3a7e1126_e21007ab","updated":"2015-12-18 10:29:31.000000000","message":"Yes.","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"ae987859a7289b197d4316544f8d47b39e38ae11","unresolved":false,"context_lines":[{"line_number":137,"context_line":"  trunk."},{"line_number":138,"context_line":"* Deletion of a port referred by a trunk automatically deletes all ports"},{"line_number":139,"context_line":"  referred as subports. That is deletion of a parent port \"cascades\" to the"},{"line_number":140,"context_line":"  deletion of child ports."},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"The CLI has the following new commands:"},{"line_number":143,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"3a7e1126_e2d567b9","line":140,"range":{"start_line":140,"start_character":19,"end_line":140,"end_character":20},"updated":"2015-12-17 03:27:24.000000000","message":"It would be far easier to forbid some of these operations but I like your boldness :)","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"0982da5a72a56f00ae8ac5c699035aa93904bb7b","unresolved":false,"context_lines":[{"line_number":137,"context_line":"  trunk."},{"line_number":138,"context_line":"* Deletion of a port referred by a trunk automatically deletes all ports"},{"line_number":139,"context_line":"  referred as subports. That is deletion of a parent port \"cascades\" to the"},{"line_number":140,"context_line":"  deletion of child ports."},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"The CLI has the following new commands:"},{"line_number":143,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"3a7e1126_41b88fe5","line":140,"range":{"start_line":140,"start_character":19,"end_line":140,"end_character":20},"in_reply_to":"3a7e1126_e2d567b9","updated":"2015-12-18 10:29:31.000000000","message":"You\u0027re right. I\u0027ve just changed the spec to forbid most of these, for easier implementation. We can still smoothly return to the cascaded delete, if somebody needs it later.","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"ae987859a7289b197d4316544f8d47b39e38ae11","unresolved":false,"context_lines":[{"line_number":150,"context_line":"* trunk-subport-list"},{"line_number":151,"context_line":""},{"line_number":152,"context_line":"Importantly, after creating trunks and maybe subports, VMs are still booted"},{"line_number":153,"context_line":"with a reference to plain old ports:"},{"line_number":154,"context_line":""},{"line_number":155,"context_line":"::"},{"line_number":156,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"3a7e1126_02ee738b","line":153,"updated":"2015-12-17 03:27:24.000000000","message":"this seems superfluous, as VM\u0027s can\u0027t boot with a uuid of a subport and the uuid of the ports used to create the trunk won\u0027t change.","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"ae987859a7289b197d4316544f8d47b39e38ae11","unresolved":false,"context_lines":[{"line_number":265,"context_line":"* v4: https://review.openstack.org/#q,I8563e54cc984b60f2be2eb7cc2e3c6fc60e6de20,n,z"},{"line_number":266,"context_line":"  patch sets 6 and later (the current)"},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Data Model Impact"},{"line_number":269,"context_line":"-----------------"},{"line_number":270,"context_line":""},{"line_number":271,"context_line":"Neutron port: no changes."}],"source_content_type":"text/x-rst","patch_set":9,"id":"3a7e1126_024af383","line":268,"updated":"2015-12-17 03:27:24.000000000","message":"I am still not 100% convinced on the fields, but we can discuss this further during code review. The bulk of it\u0027s there so I am good for now.","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":6558,"name":"Sukhdev Kapur","email":"sukhdevkapur@gmail.com","username":"sukhdev-8"},"change_message_id":"f24bb836e28110080844ac2f43d58ace87e82629","unresolved":false,"context_lines":[{"line_number":387,"context_line":"* Tempest scenario test(s) for doing functional validation"},{"line_number":388,"context_line":"* Neutron Plugin support."},{"line_number":389,"context_line":"  * networking-ovn (OVN supports this model already)"},{"line_number":390,"context_line":"  * ml2+ovs"},{"line_number":391,"context_line":"* Expose subport information in nova metadata service (likely will require a new"},{"line_number":392,"context_line":"  spec)"},{"line_number":393,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a710552_30a74651","line":390,"updated":"2015-12-14 17:55:39.000000000","message":"* ML2 Driver API changes","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"35b043420650d2ce341d0d08d10dca04e992eb40","unresolved":false,"context_lines":[{"line_number":387,"context_line":"* Tempest scenario test(s) for doing functional validation"},{"line_number":388,"context_line":"* Neutron Plugin support."},{"line_number":389,"context_line":"  * networking-ovn (OVN supports this model already)"},{"line_number":390,"context_line":"  * ml2+ovs"},{"line_number":391,"context_line":"* Expose subport information in nova metadata service (likely will require a new"},{"line_number":392,"context_line":"  spec)"},{"line_number":393,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a710552_34a33f51","line":390,"in_reply_to":"5a710552_30a74651","updated":"2015-12-16 15:23:01.000000000","message":"Yes, we may implicitly update ports from other API operations. However I don\u0027t think we are changing the API by calling some API actions from a few more places. Particularly no mechanism driver should ever know about if it was called explicitly by an HTTP PUT on /v2.0/ports or implicitly from some other part of neutron-server.\n\nDo I miss something?","commit_id":"f52af961db8689829f5cfc8ce0cc8bdeefc25e47"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"65517bbb13be4ec70e470b79b65a9722b4b4012e","unresolved":false,"context_lines":[{"line_number":112,"context_line":"of encapsulation (segmentation) used between the hypervisor and VM for"},{"line_number":113,"context_line":"targeting packets to a logical subport, as well as for determining the"},{"line_number":114,"context_line":"source logical port for a packet arriving from the VM. The encapsulation"},{"line_number":115,"context_line":"here is local, used between the VM and hypervisor only.  It has nothing"},{"line_number":116,"context_line":"to do with how the Neutron network the port is attached to is implemented."},{"line_number":117,"context_line":"SEGMENTATION-TYPE is an enum of strings, currently having one valid value"},{"line_number":118,"context_line":"\u0027vlan\u0027. SEGMENTATION-ID is an unsigned integer.  SEGMENTATION-TYPE and"}],"source_content_type":"text/x-rst","patch_set":10,"id":"fa69d971_440b6d8e","line":115,"updated":"2016-01-06 00:55:46.000000000","message":"\u003eIf the nova node is not able to manipulate the packet\n\nI\u0027m not following what you are saying here. Nova doesn\u0027t manipulate the packet at all. It just receives traffic on the interface and passes it into the VM. It\u0027s up to the VM to actually tag and untag the packets.\n\n\u003eFrom a networking perspective I would argue that the encapsulation id is something which is determined on the network level and not on the attached device\n\nI think you are confusing the segmenation ID used to transport the traffic after it has left the compute node with what is being proposed here. This patch does not let the user choose the VLAN that their traffic will be carried on between compute nodes. The entire point is that we want to provide access to a number of arbitrary Neutron networks with arbitrary encapsulations (e.g. Net1 is GRE, Net2 is VXLAN VNI 125612, Net4 is flat, Net5 is VLAN12, etc) to one single VM interface multiplexed using VLAN tags.\n\n\u003ethe relevant encapsulation settings would be determined by the neutron network/segment\n\nThis is leaking information about port binding to the end-user, which is not something we want to do. Also, if they see the port is bound using VXLAN VNI 12540, how does that help them gain access to the network with their service VM?","commit_id":"8080a13127f15ac180ca35f543185efbd2afca60"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"4c65a4740991394784ffa464efd587d34f3a52bb","unresolved":false,"context_lines":[{"line_number":112,"context_line":"of encapsulation (segmentation) used between the hypervisor and VM for"},{"line_number":113,"context_line":"targeting packets to a logical subport, as well as for determining the"},{"line_number":114,"context_line":"source logical port for a packet arriving from the VM. The encapsulation"},{"line_number":115,"context_line":"here is local, used between the VM and hypervisor only.  It has nothing"},{"line_number":116,"context_line":"to do with how the Neutron network the port is attached to is implemented."},{"line_number":117,"context_line":"SEGMENTATION-TYPE is an enum of strings, currently having one valid value"},{"line_number":118,"context_line":"\u0027vlan\u0027. SEGMENTATION-ID is an unsigned integer.  SEGMENTATION-TYPE and"}],"source_content_type":"text/x-rst","patch_set":10,"id":"fa69d971_9ad3e45f","line":115,"updated":"2016-01-06 15:52:20.000000000","message":"There are a couple of issues if we try to go that route. The first is that the user experience is not as good because pre-configured service VMs would be out of the question. With the current proposal, tags can be requested that match a pre-imaged service VM. Not allowing selection will now require a Neutron API call after the VM is booted and then a reconfiguration of the VM. This isn\u0027t the worst thing in the world, but it\u0027s definitely a step down from what is being proposed.\n\nThe second (and bigger) issue is that what you are proposing will break migration in various cases. The first is in HPB and the second is in multi-segment networks. The issue is the same in both and that\u0027s where VLAN 100 on one compute node may be connected to a different network on another compute node. A VM migration will kill the traffic in these scenarios and there would be no way to fix it without a script constantly hammering the API to see if the trunk port tags have changed to reconfigure the internals of the VM. So essentially we can\u0027t re-use portbinding details because they are not static.","commit_id":"8080a13127f15ac180ca35f543185efbd2afca60"},{"author":{"_account_id":20007,"name":"Martin Klein","email":"martin.klein01@sap.com"},"change_message_id":"9ceb3fdf6d4c4b3c15d4253651b70eec4fed08a8","unresolved":false,"context_lines":[{"line_number":112,"context_line":"of encapsulation (segmentation) used between the hypervisor and VM for"},{"line_number":113,"context_line":"targeting packets to a logical subport, as well as for determining the"},{"line_number":114,"context_line":"source logical port for a packet arriving from the VM. The encapsulation"},{"line_number":115,"context_line":"here is local, used between the VM and hypervisor only.  It has nothing"},{"line_number":116,"context_line":"to do with how the Neutron network the port is attached to is implemented."},{"line_number":117,"context_line":"SEGMENTATION-TYPE is an enum of strings, currently having one valid value"},{"line_number":118,"context_line":"\u0027vlan\u0027. SEGMENTATION-ID is an unsigned integer.  SEGMENTATION-TYPE and"}],"source_content_type":"text/x-rst","patch_set":10,"id":"fa69d971_f94ee76d","line":115,"updated":"2016-01-05 14:38:12.000000000","message":"Treating the encapsulation between the VM and the hypervisor as a local scope only would seriously limit the possible implementations of this. If the neutron network uses a segmentation ID of x and the port using y would require any implementation to be able to either change the tag on the fly or re-encapsulate the whole packet. For an openvswitch implementation this would only add a further processing step in the packet handling but If the nova node is not able to manipulate the packet in that precise manner the feature would be lost, since the segment-id is user definable. From a networking perspective I would argue that the encapsulation id is something which is determined on the network level and not on the attached device. From that perspective a trunk port would  only need to store the segment it is bound to and the relevant encapsulation settings would be determined by the neutron network/segment leaving only the special case of the \"native\" VLAN that needs to send to the vm without encapsulation.Implementation wise that would only require the ability to set the native VLAN and control the \"allowed vlan\" ID for a given port, which is very common functionality not only in hypervisor/vswitch implementations but could also without change be adapted to other ports like bare metal and other devices where vnic creation is not an option.","commit_id":"8080a13127f15ac180ca35f543185efbd2afca60"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"0499c42daaf246bb05031f0b6a62cd0e0e8b688c","unresolved":false,"context_lines":[{"line_number":112,"context_line":"of encapsulation (segmentation) used between the hypervisor and VM for"},{"line_number":113,"context_line":"targeting packets to a logical subport, as well as for determining the"},{"line_number":114,"context_line":"source logical port for a packet arriving from the VM. The encapsulation"},{"line_number":115,"context_line":"here is local, used between the VM and hypervisor only.  It has nothing"},{"line_number":116,"context_line":"to do with how the Neutron network the port is attached to is implemented."},{"line_number":117,"context_line":"SEGMENTATION-TYPE is an enum of strings, currently having one valid value"},{"line_number":118,"context_line":"\u0027vlan\u0027. SEGMENTATION-ID is an unsigned integer.  SEGMENTATION-TYPE and"}],"source_content_type":"text/x-rst","patch_set":10,"id":"fa69d971_4110cda8","line":115,"in_reply_to":"fa69d971_22ec1bf2","updated":"2016-01-08 01:38:22.000000000","message":"At one point, I had considered the workflow where the system itself \u0027figures out\u0027 the segmentation type and id, meaning that the user only specifies the logical topology without worrying about the communication mechanism between the trunk port and the subport. This is doable, so long as this information is still made available to the deployed VM to implement the vlan aware use case, which after all is what this spec is about.\n\nIf I understand Martin\u0027s point correctly we could address his -1 by simply making SEGMENTATION_TYPE and SEGMENTATION_ID non mandatory, and leaving to the backend to accept/reject a request without these parameters. We could assume that the implementation on top of openvswitch would require these, but it could easily not.\n\n@Martin: is that what you\u0027re advocating for? I am not 100% sure if this would be enough to enable the implementation on hypervisor platforms like the ones you mentioned, but at least it would give some extra flexibility. Without knowing if we ever are going to see this implemented on top of vmware or hyperv, I would be wary of complicating this further, especially after so many cycles spent trying to get consensus on OVS/KVM alone!","commit_id":"8080a13127f15ac180ca35f543185efbd2afca60"},{"author":{"_account_id":20007,"name":"Martin Klein","email":"martin.klein01@sap.com"},"change_message_id":"dbbf85be4643f82ed3c23a4a20624f01f699c961","unresolved":false,"context_lines":[{"line_number":112,"context_line":"of encapsulation (segmentation) used between the hypervisor and VM for"},{"line_number":113,"context_line":"targeting packets to a logical subport, as well as for determining the"},{"line_number":114,"context_line":"source logical port for a packet arriving from the VM. The encapsulation"},{"line_number":115,"context_line":"here is local, used between the VM and hypervisor only.  It has nothing"},{"line_number":116,"context_line":"to do with how the Neutron network the port is attached to is implemented."},{"line_number":117,"context_line":"SEGMENTATION-TYPE is an enum of strings, currently having one valid value"},{"line_number":118,"context_line":"\u0027vlan\u0027. SEGMENTATION-ID is an unsigned integer.  SEGMENTATION-TYPE and"}],"source_content_type":"text/x-rst","patch_set":10,"id":"fa69d971_79ce7a2e","line":115,"in_reply_to":"fa69d971_4110cda8","updated":"2016-01-11 12:37:09.000000000","message":"@Armando: yes this is very much what i am advocating for. \n\nIn general i can see two usage patterns for this. One being the service VM use-case where a neutron port needs to match specific expectations within the VM\u0027s configuration like the vlan numbers.\n \nThe other one being \"regular\" VM\u0027s where users over the corse of time add and remove networks to an existing adapter.\n\nIdeally both usage patterns should get the maximum out of this feature.\nFor the second use-case it is i think more desireable to not have to pick a segmentation ID because it would force the user to manage the ID allocation himself which is a lot of redundant work.\n\nFrom the VM perspective sub-port removal and addition is a transparent operation unlike adapter hotplug and removal which one can react on. So having the vlan data available to the instance via metadata is crucial to at least being able to run a polling loop to \ndynamically react on changes inside a VM.\n\nMaking the segmentation information optional and letting the driver choose how to react when it is provided or not sounds like a good approach for both sides of the argument.","commit_id":"8080a13127f15ac180ca35f543185efbd2afca60"},{"author":{"_account_id":20007,"name":"Martin Klein","email":"martin.klein01@sap.com"},"change_message_id":"0955d1144027a4a08fd13c393b6fdac4d3c8848a","unresolved":false,"context_lines":[{"line_number":112,"context_line":"of encapsulation (segmentation) used between the hypervisor and VM for"},{"line_number":113,"context_line":"targeting packets to a logical subport, as well as for determining the"},{"line_number":114,"context_line":"source logical port for a packet arriving from the VM. The encapsulation"},{"line_number":115,"context_line":"here is local, used between the VM and hypervisor only.  It has nothing"},{"line_number":116,"context_line":"to do with how the Neutron network the port is attached to is implemented."},{"line_number":117,"context_line":"SEGMENTATION-TYPE is an enum of strings, currently having one valid value"},{"line_number":118,"context_line":"\u0027vlan\u0027. SEGMENTATION-ID is an unsigned integer.  SEGMENTATION-TYPE and"}],"source_content_type":"text/x-rst","patch_set":10,"id":"fa69d971_22ec1bf2","line":115,"in_reply_to":"fa69d971_440b6d8e","updated":"2016-01-06 10:39:09.000000000","message":"Sorry poor choice of words on my side, i am aware that nova itself does not manipulate the traffic. The point i was trying to make is that in a \"basic\" installation where nova is used in combination with the openvswitch / openvswitc-agent. As far as i read it in that case it would result in the following :\n\nneutron net (Type:VLAN, ID:20) -\u003e openvswitch -\u003e VIF (Type: VLAN, ID:100)\n\nor \n\nneutron net (Type:VXLAN, VNI:12450) -\u003e openvswitch -\u003e VIF (Type:VLAN, ID:200)\n\nIf that is the correct assumption than the requirement on openvswitch would be to rewrite the VLAN Tag in the first example or decap VXLAN and re-encap to VLAN on the second example. \n\nI am not an openvswitch expert but i assume that this would be rather easy to do in openvswitch.\n\nSince nova supports a multitude of hypervisors and network connectivity options i am having trouble seeing how this could be implemented for users not using the openvswitch/kvm installation option.\n\nThe vmware and hyper-v hypervisor options do not enable a user to do what is proposed here (re-tagging). But both hypervisors can support nics in trunc mode with a list of allowed vlan tags. Also if a user is using SR-IOV he would not be able to use the feature since in that case there is no intermediate hypervisor component between the VNIC and the physical device which could do such a thing. Without knowing the details of all the openvswitch replacement options for nova nodes i would guess that a multitude are not able to retag packets but a majority will be able to  control trunk/non-trunk on an interface and the allowed vlan tags on a trunk. \n\nSo if the user were not able to chose the \"local\" VLAN ID but were simply told which one to use it would result in the following:\n\nSorry poor choice of words on my side, i am aware that nova itself does not manipulate the traffic. The point i was trying to make is that in a \"basic\" installation where nova is used in combination with the openvswitch / openvswitc-agent. As far as i read it in that case it would result in the following :\n\nneutron net (Type:VLAN, ID:20) -\u003e openvswitch -\u003e VIF (Type: VLAN, ID:100)\n\nor \n\nneutron net (Type:VXLAN, VNI:12450) -\u003e openvswitch -\u003e VIF (Type:VLAN, ID:200)\n\nIf that is the correct assumption than the requirement on openvswitch would be to rewrite the VLAN Tag in the first example or decap VXLAN and re-encap to VLAN on the second example. \n\nI am not an openvswitch expert but i assume that this would be rather easy to do in openvswitch.\n\nSince nova supports a multitude of hypervisors and network connectivity options i am having trouble seeing how this could be implemented for users not using the openvswitch/kvm installation option.\n\nThe vmware and hyper-v hypervisor options do not enable a user to do what is proposed here (re-tagging). But both hypervisors can support nics in trunc mode with a list of allowed vlan tags. Also if a user is using SR-IOV he would not be able to use the feature since in that case there is no intermediate hypervisor component between the VNIC and the physical device which could do such a thing. Without knowing the details of all the openvswitch replacement options for nova nodes i would guess that a multitude are not able to retag packets but a majority will be able to  control trunk/non-trunk on an interface and the allowed vlan tags on a trunk. \n\nSo if the user were not able to chose the \"local\" VLAN ID but were simply told which one to use it would result in the following:\n\nneutron net (Type:VLAN, ID:20) -\u003e openvswitch -\u003e VIF (Type: VLAN, ID:20)\n\nFrom an implementation standpoint this would require a hypervisor/vswitch combination to simply allow/disallow a particular vlan tag on a particular VIF which is very much less of an requirement in comparison to translating a tag from one ID to another.\n\nWhen the Type on the Neutron side is not VLAN it is a little more complex since than a simple pass-through of the tagged packet is not an option.\n\nConsidering the problem of connecting an entity which is not overlay-aware to a neutron network which uses an overlay technology i would suggest to maybe take a look into already available concepts for that. \n\nHierarchical Port Binding in neutron enables a mechanism driver to make that translation in a partial binding before it is passed to the next driver for the final binding.\n\nSo in the VXLAN example an implementation could look like this:\n\nneutron net (Type:VXLAN, VNI:12450) -\u003e mech_driver (Type:VLAN ID:200) -\u003e openvswitch -\u003e VIF (Type:VLAN, ID:200)\n\nThis splits up the responsibilities for making the translation between VXLAN and VLAN and the actual pass-throug handling of the tag.\n\nSo for people who are already using hierarchical port binding (ex. for hypervisors which are not vxlan aware / capable) the hypervisor is already only seeing only vlan tagged packets meaning no further implementation is needed to enable the vxlan to vlan translation. \n\nSo for the openvswitch implementation it becomes only a question on how to implement the bookkeeping on the \"local\" vlan tag that is exposed towards the VNIC.\n\nIn the current proposal the user would be responsible for choosing non overlapping vlan ids for sub-ports resulting in an error if he \nchooses the same one twice. \n\nIn the hierarchical port binding case a mechanism driver is responsible for managing segmentation ID\u0027s in its lower segments.\n\nSo if this hierarchical translation should be recorded in neutron for the openvswitch itself the openvswitch driver would need to create a \"local\" segment for each openvswitch agent (nova node) involved and record the chosen \"local\" VLAN ID which should be used to pass to the vnic. The actual encap decap inside the local openvswitch is the same onyl the method of choosing the used VLAN ID differs.\n\nExample segments for a network would look like:\n\n {\"provider:network_type\": \"vxlan\", \"provider:physical_network\": null, \"provider:segmentation_id\": 12450}\n\n{\"provider:network_type\": \"vlan\", \"provider:physical_network\": \"bb98-fi\", \"provider:segmentation_id\": 200}\n\nWith the VXLAN segment being the top of the hierarchy and the vlan beeing the segment where the sub-port is bound to.\n\nAnother way would be to implement the VLAN ID pooling into the openvswitch agent and make the decision which one to use there.\nThe drawback being that it would only be known to the local agent \nand not recorded properly in neutron. \n\nIn either way the final choice which vlans are actually passed to the vnic needs to be reported to the user somehow as well as to the instance itself via metadata so a script can pick it up and reconfigure the os accordingly. \n\nMaking it a local choice would probably make it more difficult to construct the metadata.\n\nThat said i hope i could articulate my point better this time.\nBullet point being: Letting the user chose the VLAN ID makes\nit hard for people to implement this for deployments other than \nopenvswitch based ones, letting the driver chose opens options\nfor other implementations.","commit_id":"8080a13127f15ac180ca35f543185efbd2afca60"},{"author":{"_account_id":20007,"name":"Martin Klein","email":"martin.klein01@sap.com"},"change_message_id":"dbbf85be4643f82ed3c23a4a20624f01f699c961","unresolved":false,"context_lines":[{"line_number":112,"context_line":"of encapsulation (segmentation) used between the hypervisor and VM for"},{"line_number":113,"context_line":"targeting packets to a logical subport, as well as for determining the"},{"line_number":114,"context_line":"source logical port for a packet arriving from the VM. The encapsulation"},{"line_number":115,"context_line":"here is local, used between the VM and hypervisor only.  It has nothing"},{"line_number":116,"context_line":"to do with how the Neutron network the port is attached to is implemented."},{"line_number":117,"context_line":"SEGMENTATION-TYPE is an enum of strings, currently having one valid value"},{"line_number":118,"context_line":"\u0027vlan\u0027. SEGMENTATION-ID is an unsigned integer.  SEGMENTATION-TYPE and"}],"source_content_type":"text/x-rst","patch_set":10,"id":"fa69d971_9ee9d4b9","line":115,"in_reply_to":"fa69d971_9ad3e45f","updated":"2016-01-11 12:37:09.000000000","message":"For the pre configured use case it would make things a little bit more difficult since the user needs to implement a \"post-create\" script which reconfigures the VM based on information it got from the metadata service.\n\nMigration in multi segment network would mean that it would only work seamlessly as long as you migrate within a segment, which is a very much bigger inconvenience of cause but i would imagine an installation of a size that needs multi segment networks to live with some limitations of what one can do cross segment.\n\nMigration in HPB networks is a tougher nut to crack since here it is expected that a hierarchical driver picks a segment ID by themselves.\nComing from a world were the hypervisor/neutron node is already representing a group of hosts rather than a single hypervisor made that very important case of vm movement slip my thoughts.","commit_id":"8080a13127f15ac180ca35f543185efbd2afca60"},{"author":{"_account_id":20007,"name":"Martin Klein","email":"martin.klein01@sap.com"},"change_message_id":"9ceb3fdf6d4c4b3c15d4253651b70eec4fed08a8","unresolved":false,"context_lines":[{"line_number":117,"context_line":"SEGMENTATION-TYPE is an enum of strings, currently having one valid value"},{"line_number":118,"context_line":"\u0027vlan\u0027. SEGMENTATION-ID is an unsigned integer.  SEGMENTATION-TYPE and"},{"line_number":119,"context_line":"SEGMENTATION-ID are mandatory in both trunk-create and trunk-subport-add."},{"line_number":120,"context_line":"Further segmentation types may be introduced by later specs."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"::"},{"line_number":123,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"fa69d971_d9ad239c","line":120,"updated":"2016-01-05 14:38:12.000000000","message":"Maybe this should only be VLAN because thats the encapsulation that is  exposed to the VM / attached device. If a user wants to bind to a non VLAN network it can be easily accomplished by using hirarchical port binding to create a vlan type segment which is local to the binding host.","commit_id":"8080a13127f15ac180ca35f543185efbd2afca60"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"65517bbb13be4ec70e470b79b65a9722b4b4012e","unresolved":false,"context_lines":[{"line_number":117,"context_line":"SEGMENTATION-TYPE is an enum of strings, currently having one valid value"},{"line_number":118,"context_line":"\u0027vlan\u0027. SEGMENTATION-ID is an unsigned integer.  SEGMENTATION-TYPE and"},{"line_number":119,"context_line":"SEGMENTATION-ID are mandatory in both trunk-create and trunk-subport-add."},{"line_number":120,"context_line":"Further segmentation types may be introduced by later specs."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"::"},{"line_number":123,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"fa69d971_e4fb8179","line":120,"updated":"2016-01-06 00:55:46.000000000","message":"This segmentation type is not related to the encapsulation used to carry the traffic around the network.","commit_id":"8080a13127f15ac180ca35f543185efbd2afca60"},{"author":{"_account_id":20007,"name":"Martin Klein","email":"martin.klein01@sap.com"},"change_message_id":"0955d1144027a4a08fd13c393b6fdac4d3c8848a","unresolved":false,"context_lines":[{"line_number":117,"context_line":"SEGMENTATION-TYPE is an enum of strings, currently having one valid value"},{"line_number":118,"context_line":"\u0027vlan\u0027. SEGMENTATION-ID is an unsigned integer.  SEGMENTATION-TYPE and"},{"line_number":119,"context_line":"SEGMENTATION-ID are mandatory in both trunk-create and trunk-subport-add."},{"line_number":120,"context_line":"Further segmentation types may be introduced by later specs."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"::"},{"line_number":123,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"fa69d971_a2ad6b9c","line":120,"in_reply_to":"fa69d971_e4fb8179","updated":"2016-01-06 10:39:09.000000000","message":"Yes that is understood but making it an arbitrary user choice makes it very hard to implement in a lot of technologies.","commit_id":"8080a13127f15ac180ca35f543185efbd2afca60"},{"author":{"_account_id":20007,"name":"Martin Klein","email":"martin.klein01@sap.com"},"change_message_id":"9ceb3fdf6d4c4b3c15d4253651b70eec4fed08a8","unresolved":false,"context_lines":[{"line_number":124,"context_line":"    # trunk-add-subport adds 1 or more subport(s)"},{"line_number":125,"context_line":"    $ neutron trunk-subport-add TRUNK \\"},{"line_number":126,"context_line":"                                PORT,SEGMENTATION-TYPE,SEGMENTATION-ID \\"},{"line_number":127,"context_line":"                               [PORT,...]"},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"All ports referred must exist."},{"line_number":130,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"fa69d971_19f09bfd","line":127,"updated":"2016-01-05 14:38:12.000000000","message":"in line with the comment on line 115 this would change to something like \n\nneutron trunk-subport-add TRUNK NETWORK-ID","commit_id":"8080a13127f15ac180ca35f543185efbd2afca60"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"827aa64d43ec7d3a7ef097a86d62c4d71760f0f6","unresolved":false,"context_lines":[{"line_number":245,"context_line":""},{"line_number":246,"context_line":"The Neutron OVS agent uses OVS in such a way that it will likely need"},{"line_number":247,"context_line":"to create a new OVS bridge per top level parent port.  That requires"},{"line_number":248,"context_line":"an enhancement to the existing OVS VIF type support in Nova to allow"},{"line_number":249,"context_line":"Neutron to tell Nova the name of the bridge to use for the port."},{"line_number":250,"context_line":"Currently, Nova only supports a single bridge name provided by the Nova"},{"line_number":251,"context_line":"configuration file."}],"source_content_type":"text/x-rst","patch_set":10,"id":"1a7b0d38_fadd90e0","line":248,"range":{"start_line":248,"start_character":31,"end_line":248,"end_character":43},"updated":"2015-12-28 03:33:03.000000000","message":"just a minor note the vhost-user vif type will also need to be updated but it is a trivial change.\n\nhttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/vif.py#L637\n\nif get_bridge_name(self, vif)\nhttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/vif.py#L158\nis updated to read the bridge name from the vif binding info it should work for both the vhost-user and ovs vif types","commit_id":"8080a13127f15ac180ca35f543185efbd2afca60"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"866327039193ed36fb533371c51342f5e3fdce46","unresolved":false,"context_lines":[{"line_number":14,"context_line":""},{"line_number":15,"context_line":"This blueprint proposes how to incorporate VLAN aware VMs into"},{"line_number":16,"context_line":"OpenStack. In this document a VLAN aware VM is a VM that sends and receives"},{"line_number":17,"context_line":"VLAN tagged frames over its vNIC. The main point of that is to overcome the"},{"line_number":18,"context_line":"limitations of the current one vNIC per network model. A VLAN (or other"},{"line_number":19,"context_line":"encapsulation) aware VM can differentiate between traffic of many networks by"},{"line_number":20,"context_line":"different encapsulation types and IDs, instead of using many vNICs. This"}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_dc0fa22c","line":17,"range":{"start_line":17,"start_character":33,"end_line":17,"end_character":34},"updated":"2016-01-19 20:52:17.000000000","message":"... and wants the traffic with different tags to go to different places (versus what already works, which is all that traffic going to one place).","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"866327039193ed36fb533371c51342f5e3fdce46","unresolved":false,"context_lines":[{"line_number":25,"context_line":"Problem Description"},{"line_number":26,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"Currently VLANs in VMs are not integrated with Neutron.  There are various use"},{"line_number":29,"context_line":"cases where it would be useful to allow a VM to be attached to multiple Neutron"},{"line_number":30,"context_line":"networks using VLANs as a local encapsulation to differentiate the traffic for"},{"line_number":31,"context_line":"each network as it goes in/out of a single VIF."}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_3c759e97","line":28,"range":{"start_line":28,"start_character":23,"end_line":28,"end_character":53},"updated":"2016-01-19 20:52:17.000000000","message":"\"Currently, Neutron has no awareness of VLANs beyond knowing what a trunk is.\" (\u0027integrated\u0027 is not a useful description.)","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"866327039193ed36fb533371c51342f5e3fdce46","unresolved":false,"context_lines":[{"line_number":69,"context_line":""},{"line_number":70,"context_line":"The new API extension looks like this:"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"#. One new trunk resource with member_actions for subport operations:"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"    * One trunk resource"},{"line_number":75,"context_line":"    * Subports encoded in an attribute of the trunk, added and removed by"}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_5c9f32b4","line":72,"range":{"start_line":72,"start_character":11,"end_line":72,"end_character":16},"updated":"2016-01-19 20:52:17.000000000","message":"Naming\u0027s a little off?  Not that I have an alternative.","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":20000,"name":"Songming Yan","email":"yan.songming@zte.com.cn","username":"SonmingYan.zte"},"change_message_id":"423d05086fca8261dd3c0706de8d4cd5e2491924","unresolved":false,"context_lines":[{"line_number":95,"context_line":"::"},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"    # trunk-create may refer to 0, 1 or more subport(s)."},{"line_number":98,"context_line":"    $ neutron trunk-create --port-id PORT \\"},{"line_number":99,"context_line":"                          [--subport PORT[,SEGMENTATION-TYPE,SEGMENTATION-ID]] \\"},{"line_number":100,"context_line":"                          [--subport ...]"},{"line_number":101,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_ae0ce694","line":98,"updated":"2016-01-20 03:26:57.000000000","message":"I don\u0027t think it is  necessary to make subport as a option.\nCreate subport later maybe more clearly.\nJust like we create a net,we don\u0027t allow to add port in it at the same time, we should create it later.","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":20082,"name":"JianGang Weng","email":"weng.jiangang@zte.com.cn","username":"wengjiangang"},"change_message_id":"7c8f9c317d6e2a608e894bcef13ab481144db560","unresolved":false,"context_lines":[{"line_number":95,"context_line":"::"},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"    # trunk-create may refer to 0, 1 or more subport(s)."},{"line_number":98,"context_line":"    $ neutron trunk-create --port-id PORT \\"},{"line_number":99,"context_line":"                          [--subport PORT[,SEGMENTATION-TYPE,SEGMENTATION-ID]] \\"},{"line_number":100,"context_line":"                          [--subport ...]"},{"line_number":101,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"9a68dd71_cabac371","line":98,"in_reply_to":"ba63e191_ae0ce694","updated":"2016-01-26 06:57:53.000000000","message":"I agree this point too, since we have the command \u0027trunk-subport-add\u0027.","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"866327039193ed36fb533371c51342f5e3fdce46","unresolved":false,"context_lines":[{"line_number":107,"context_line":"If the backend does not implement the extension any trunk operation will fail"},{"line_number":108,"context_line":"(with 404). If a plugin does implement the extension, trunk operations may"},{"line_number":109,"context_line":"return a conflict error if the port status is not compatible with the request."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"In addition to the logical topology piece, we need to define the type"},{"line_number":112,"context_line":"of encapsulation (segmentation) used between the hypervisor and VM for"},{"line_number":113,"context_line":"targeting packets to a logical subport, as well as for determining the"}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_5cd73223","line":110,"updated":"2016-01-19 20:52:17.000000000","message":"It concerns me a little that, by simply looking at a port, I can\u0027t tell that it\u0027s a subport of a trunk and treated oddly.","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"866327039193ed36fb533371c51342f5e3fdce46","unresolved":false,"context_lines":[{"line_number":115,"context_line":"here is local, used between the VM and hypervisor only.  It has nothing"},{"line_number":116,"context_line":"to do with how the Neutron network the port is attached to is implemented."},{"line_number":117,"context_line":"SEGMENTATION-TYPE is an enum of strings, currently having one valid value"},{"line_number":118,"context_line":"\u0027vlan\u0027. SEGMENTATION-ID is an unsigned integer.  SEGMENTATION-TYPE and"},{"line_number":119,"context_line":"SEGMENTATION-ID are optional in both trunk-create and trunk-subport-add"},{"line_number":120,"context_line":"in the generic case, allowing neutron server to choose the type and id"},{"line_number":121,"context_line":"if needed. On the other hand backends are allowed to reject requests"}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_7cc9d677","line":118,"range":{"start_line":118,"start_character":30,"end_line":118,"end_character":38},"updated":"2016-01-19 20:52:17.000000000","message":"It\u0027s a little more restrictive than that, but add \u0027that must be a valid VLAN ID\u0027 and we\u0027ll call it quits.","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"866327039193ed36fb533371c51342f5e3fdce46","unresolved":false,"context_lines":[{"line_number":174,"context_line":"  | Ports combined into one VIF   |"},{"line_number":175,"context_line":"  | by turning port0 into a trunk |"},{"line_number":176,"context_line":"  | and the other ports into      |"},{"line_number":177,"context_line":"  | subports of the trunk.        |"},{"line_number":178,"context_line":"  |                               |"},{"line_number":179,"context_line":"  +-------------------------------+"},{"line_number":180,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_fc82a6ff","line":177,"range":{"start_line":177,"start_character":12,"end_line":177,"end_character":13},"updated":"2016-01-19 20:52:17.000000000","message":"Will you be binding the subports?  (Hint: you need to bind the subports the moment they\u0027re attached to the trunk, and you\u0027re effectively binding them to the parent port or the trunk, either of which you could use as device_id in the binding.  You do not want other VMs to be allowed to bind to them, and you might as well make the bind descriptive.)","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"628f0874086b642d102fb187399abebc0fea6492","unresolved":false,"context_lines":[{"line_number":174,"context_line":"  | Ports combined into one VIF   |"},{"line_number":175,"context_line":"  | by turning port0 into a trunk |"},{"line_number":176,"context_line":"  | and the other ports into      |"},{"line_number":177,"context_line":"  | subports of the trunk.        |"},{"line_number":178,"context_line":"  |                               |"},{"line_number":179,"context_line":"  +-------------------------------+"},{"line_number":180,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_49fd2c39","line":177,"updated":"2016-01-20 00:09:34.000000000","message":"yes, the binding process is how it will be handled internally.","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"25a4af8f3ccdaf9deec39c9c2715d32b3968d5a5","unresolved":false,"context_lines":[{"line_number":174,"context_line":"  | Ports combined into one VIF   |"},{"line_number":175,"context_line":"  | by turning port0 into a trunk |"},{"line_number":176,"context_line":"  | and the other ports into      |"},{"line_number":177,"context_line":"  | subports of the trunk.        |"},{"line_number":178,"context_line":"  |                               |"},{"line_number":179,"context_line":"  +-------------------------------+"},{"line_number":180,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_29c0f8df","line":177,"in_reply_to":"ba63e191_49fd2c39","updated":"2016-01-20 00:12:09.000000000","message":"Meaning, \u0027will you be binding the subports the moment they\u0027re attached to the trunk\u0027","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"866327039193ed36fb533371c51342f5e3fdce46","unresolved":false,"context_lines":[{"line_number":179,"context_line":"  +-------------------------------+"},{"line_number":180,"context_line":""},{"line_number":181,"context_line":"* The traffic of port0 is untagged in vm0."},{"line_number":182,"context_line":"* The traffic of port1 is encapsulated, for example as vlan id 100."},{"line_number":183,"context_line":"* The traffic of port2 is encapsulated, for example as vlan id 200."},{"line_number":184,"context_line":""},{"line_number":185,"context_line":"In the above example, a VM connects to 3 Neutron networks.  port0 is"}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_7c4a36c7","line":182,"updated":"2016-01-19 20:52:17.000000000","message":"Name the flow direction and behaviour.  I assume you mean\n\n- port0\u0027s network traffic is filtered to exclude tagged traffic [because otherwise you\u0027ll have a domain bridging problem you don\u0027t want] and passed from network to VM unchanged; only untagged VM traffic is output to the network; \n- port1\u0027s traffic is encapped with VLAN 100 before handing to the VM; only traffic with VLAN tag 100 sent from the VM goes via this port, where it is decapped before sending on the network.\n\n...","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"866327039193ed36fb533371c51342f5e3fdce46","unresolved":false,"context_lines":[{"line_number":207,"context_line":""},{"line_number":208,"context_line":"* Every subport of a given parent should have unique (segmentation_type,"},{"line_number":209,"context_line":"  segmentation_id) among its siblings.  Otherwise, it would not be possible"},{"line_number":210,"context_line":"  to properly differentiate the source and destination logical port."},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"* The parent port handles \"untagged\" traffic.  The parent will receive"},{"line_number":213,"context_line":"  all the packets that do not match a subport, which is no"}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_42e3cc33","line":210,"range":{"start_line":210,"start_character":43,"end_line":210,"end_character":67},"updated":"2016-01-19 20:52:17.000000000","message":"... and we wish to actively prevent accidental bridging between networks.","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"866327039193ed36fb533371c51342f5e3fdce46","unresolved":false,"context_lines":[{"line_number":221,"context_line":"  that actually is."},{"line_number":222,"context_line":""},{"line_number":223,"context_line":"* A port with a parent logically inherits its binding:host_id from its parent."},{"line_number":224,"context_line":""},{"line_number":225,"context_line":"* An attempt to update binding:host_id of a subport (by booting a Nova VM with"},{"line_number":226,"context_line":"  a subport UUID, for example) must result in an error."},{"line_number":227,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_62c5b08c","line":224,"updated":"2016-01-19 20:52:17.000000000","message":"... Bad idea.  A port with a parent should not be bindable from the moment it gets a parent.","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"866327039193ed36fb533371c51342f5e3fdce46","unresolved":false,"context_lines":[{"line_number":224,"context_line":""},{"line_number":225,"context_line":"* An attempt to update binding:host_id of a subport (by booting a Nova VM with"},{"line_number":226,"context_line":"  a subport UUID, for example) must result in an error."},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"* A normal user can only connect subports to its own parent ports. Admin"},{"line_number":229,"context_line":"  can connect subports to parent ports of different owners."},{"line_number":230,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_e23760ae","line":227,"updated":"2016-01-19 20:52:17.000000000","message":"... Bound ports cannot be rebound before they\u0027re unbound.  Not sure if this is saying anything new?","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"928238fb3697e43671beaa798073ac708517552d","unresolved":false,"context_lines":[{"line_number":224,"context_line":""},{"line_number":225,"context_line":"* An attempt to update binding:host_id of a subport (by booting a Nova VM with"},{"line_number":226,"context_line":"  a subport UUID, for example) must result in an error."},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"* A normal user can only connect subports to its own parent ports. Admin"},{"line_number":229,"context_line":"  can connect subports to parent ports of different owners."},{"line_number":230,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_0c4e626f","line":227,"updated":"2016-01-20 00:16:43.000000000","message":"Whoops, the binding:host_id field is an admin-only API so it would have to be invoked via Nova for a regular tenant to do it. So whatever restrictions Nova imposes would apply.","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"628f0874086b642d102fb187399abebc0fea6492","unresolved":false,"context_lines":[{"line_number":224,"context_line":""},{"line_number":225,"context_line":"* An attempt to update binding:host_id of a subport (by booting a Nova VM with"},{"line_number":226,"context_line":"  a subport UUID, for example) must result in an error."},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"* A normal user can only connect subports to its own parent ports. Admin"},{"line_number":229,"context_line":"  can connect subports to parent ports of different owners."},{"line_number":230,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_69f8304a","line":227,"updated":"2016-01-20 00:09:34.000000000","message":"yes they can. you can issue a port update to change the host ID when a port is already bound. Live migration depends on it.","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"22ce9fb228a34c45a5ca987bb8c32254a40f8fde","unresolved":false,"context_lines":[{"line_number":224,"context_line":""},{"line_number":225,"context_line":"* An attempt to update binding:host_id of a subport (by booting a Nova VM with"},{"line_number":226,"context_line":"  a subport UUID, for example) must result in an error."},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"* A normal user can only connect subports to its own parent ports. Admin"},{"line_number":229,"context_line":"  can connect subports to parent ports of different owners."},{"line_number":230,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_dfb78af3","line":227,"in_reply_to":"ba63e191_0c4e626f","updated":"2016-01-20 01:05:54.000000000","message":"Yeah, that\u0027s part of it, but it\u0027s not the only binding field (device id and device owner matter more at bind time, host_id is theoretically specific to the binding type).  While Neutron may not enforce it, I think Nova will not rebind (in the manner you describe) a port it doesn\u0027t own, and will not bind a port that is already bound when it\u0027s attempting to start a VM.  Consider: if it did, someone would have managed to bind a router port to a VM before now...\n\nI\u0027ll leave it to the great and good whether Neutron ought to be a bit more rigorous in its checks during binding, but - here - I\u0027ll say again, I\u0027d bind it to a device owner belonging to the VLAN service or some name created out of that, I would use a device ID of the trunk, and really I don\u0027t care one way or the other if the *actual* binding takes place in a Nova-like manner on in the internal manner that Neutron uses for e.g. L3 ports (imo it would be nice if Neutron ate its own dogfood on that one and that applies to this service, but I don\u0027t think it\u0027s necessary to ask of this code something that core Neutron doesn\u0027t do for itself).","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"25a4af8f3ccdaf9deec39c9c2715d32b3968d5a5","unresolved":false,"context_lines":[{"line_number":224,"context_line":""},{"line_number":225,"context_line":"* An attempt to update binding:host_id of a subport (by booting a Nova VM with"},{"line_number":226,"context_line":"  a subport UUID, for example) must result in an error."},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"* A normal user can only connect subports to its own parent ports. Admin"},{"line_number":229,"context_line":"  can connect subports to parent ports of different owners."},{"line_number":230,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_69a6f054","line":227,"in_reply_to":"ba63e191_69f8304a","updated":"2016-01-20 00:12:09.000000000","message":"Even if you aren\u0027t the owner?  Bear in mind here that Neutron would be the device_owner. Fairly sure Nova won\u0027t bind a port that is already bound to a fresh VM, anyway.\n\nYou add questions of HA that I think we should ignore for the moment...","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"866327039193ed36fb533371c51342f5e3fdce46","unresolved":false,"context_lines":[{"line_number":229,"context_line":"  can connect subports to parent ports of different owners."},{"line_number":230,"context_line":""},{"line_number":231,"context_line":"* Until OVS supports QinQ, an OVS based Neutron backend cannot support having a"},{"line_number":232,"context_line":"  subport attached to a \"vlan_transparent\" network.  That would require the"},{"line_number":233,"context_line":"  abilty to transport VLAN tagged traffic over the VLAN tagged subport interface"},{"line_number":234,"context_line":"  (nested VLANs), which is not yet possible."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"The following deletion constraints exist:"}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_9c7daab3","line":233,"range":{"start_line":232,"start_character":11,"end_line":233,"end_character":13},"updated":"2016-01-19 20:52:17.000000000","message":"I would perhaps word this in terms of API and not implementation, and fwiw it\u0027s already covered by the definition here.  \u0027If you attach a subport to a network that is not a VLAN trunk (which e.g. the OVS driver cannot provide) then - as per normal - tagged packets sent from that port will be dropped.  So: if a VM attached to a trunk port emits a QinQ packet, then the trunk port will strip one header, but the remaining 1q header will cause the packet to be dropped.","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"1e7f48a7be6f0199e3e652ec8f5341fde6a98f73","unresolved":false,"context_lines":[{"line_number":231,"context_line":"* Until OVS supports QinQ, an OVS based Neutron backend cannot support having a"},{"line_number":232,"context_line":"  subport attached to a \"vlan_transparent\" network.  That would require the"},{"line_number":233,"context_line":"  abilty to transport VLAN tagged traffic over the VLAN tagged subport interface"},{"line_number":234,"context_line":"  (nested VLANs), which is not yet possible."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"The following deletion constraints exist:"},{"line_number":237,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"da6ed579_c68073fa","line":234,"updated":"2016-01-16 01:48:44.000000000","message":"No, this is just saying that it wouldn\u0027t work in OVS with a tenant network that carries VLAN encapsulated traffic internally. However, that\u0027s already the case for regular tenant networks and the reference OVS plugin (because of our use of the local VLAN), so there wouldn\u0027t really be any difference here for the reference. The encap for the tenant network once it\u0027s on the physical wire has no impact on that.\n\nHowever, in Martin\u0027s case where he suggested passing through the VLAN of the physical network directly, he will likely be limited to only supporting this for specific encapsulation types without the involvement of a top-of-rack switch.","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"8a77a53d0e14b15f4787e30aa07e210a55f3f10f","unresolved":false,"context_lines":[{"line_number":231,"context_line":"* Until OVS supports QinQ, an OVS based Neutron backend cannot support having a"},{"line_number":232,"context_line":"  subport attached to a \"vlan_transparent\" network.  That would require the"},{"line_number":233,"context_line":"  abilty to transport VLAN tagged traffic over the VLAN tagged subport interface"},{"line_number":234,"context_line":"  (nested VLANs), which is not yet possible."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"The following deletion constraints exist:"},{"line_number":237,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"da6ed579_f52443b3","line":234,"updated":"2016-01-15 23:22:02.000000000","message":"One thing I always forgot to mention/ask, but clarification can come as follow up: are there any constraints on the types of networks that can be trunked? Eg. are we assuming that the networks whose ports and supports are used to build the trunk can be of any nature (tenant vs provider networks, vlan vs vxlan)?\n\nSo are we saying here that I cannot trunk ports from networks that have a vlan segmentation type, and  I can do so if and only if they are overlays?","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":20007,"name":"Martin Klein","email":"martin.klein01@sap.com"},"change_message_id":"814ab623c46832df91c375585832f2e17ce60416","unresolved":false,"context_lines":[{"line_number":231,"context_line":"* Until OVS supports QinQ, an OVS based Neutron backend cannot support having a"},{"line_number":232,"context_line":"  subport attached to a \"vlan_transparent\" network.  That would require the"},{"line_number":233,"context_line":"  abilty to transport VLAN tagged traffic over the VLAN tagged subport interface"},{"line_number":234,"context_line":"  (nested VLANs), which is not yet possible."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"The following deletion constraints exist:"},{"line_number":237,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"da6ed579_ef0a1a79","line":234,"in_reply_to":"da6ed579_c68073fa","updated":"2016-01-16 21:24:06.000000000","message":"Yes the idea would be for hypervisors who don\u0027t do so well in the overlay support to offload that decap to an TOR switch and make\na translation to a local vlan.","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"866327039193ed36fb533371c51342f5e3fdce46","unresolved":false,"context_lines":[{"line_number":231,"context_line":"* Until OVS supports QinQ, an OVS based Neutron backend cannot support having a"},{"line_number":232,"context_line":"  subport attached to a \"vlan_transparent\" network.  That would require the"},{"line_number":233,"context_line":"  abilty to transport VLAN tagged traffic over the VLAN tagged subport interface"},{"line_number":234,"context_line":"  (nested VLANs), which is not yet possible."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"The following deletion constraints exist:"},{"line_number":237,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_dc5a4250","line":234,"in_reply_to":"da6ed579_ef0a1a79","updated":"2016-01-19 20:52:17.000000000","message":"TORs have opinions about qinq too...  Per above - it\u0027s not about the implementation you choose, it\u0027s about the API.  (In fact, the most likely network infra to work for this is Linuxbridge + VXLAN, which is VLAN transparent today; you could implement these trunk ports as a set of VLAN tagged interfaces in a network namespace, and bind them to networks using LB attachments which would then happily send the packets to their destinations unmolested.)","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"866327039193ed36fb533371c51342f5e3fdce46","unresolved":false,"context_lines":[{"line_number":238,"context_line":"* Deletion of a trunk automatically deletes all of its subports."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":"* Deletion of a (child) port referred by a subport is forbidden. The subport"},{"line_number":241,"context_line":"  must be deleted first."},{"line_number":242,"context_line":""},{"line_number":243,"context_line":"* Deletion of a (parent) port referred by a trunk is forbidden. The trunk"},{"line_number":244,"context_line":"  must be deleted first."}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_226d7898","line":241,"range":{"start_line":241,"start_character":0,"end_line":241,"end_character":24},"updated":"2016-01-19 20:52:17.000000000","message":"Subports aren\u0027t actually objects, so I think this might be better expressed as \u0027deletion of a port referred to by a trunk is forbidden.\u0027","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":20082,"name":"JianGang Weng","email":"weng.jiangang@zte.com.cn","username":"wengjiangang"},"change_message_id":"e9417b7799dfa2c4188d5d5ae0040c74d1bf5500","unresolved":false,"context_lines":[{"line_number":249,"context_line":"The Neutron OVS agent uses OVS in such a way that it will likely need"},{"line_number":250,"context_line":"to create a new OVS bridge per top level parent port.  That requires"},{"line_number":251,"context_line":"an enhancement to the existing OVS and vhost-user VIF types in Nova to"},{"line_number":252,"context_line":"allow Neutron to tell Nova the name of the bridge to use for the port."},{"line_number":253,"context_line":"Currently, Nova only supports a single bridge name provided by the Nova"},{"line_number":254,"context_line":"configuration file."},{"line_number":255,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_f313de5a","line":252,"updated":"2016-01-19 09:04:45.000000000","message":"how can we decide name of the bridge for trunk port?","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"866327039193ed36fb533371c51342f5e3fdce46","unresolved":false,"context_lines":[{"line_number":249,"context_line":"The Neutron OVS agent uses OVS in such a way that it will likely need"},{"line_number":250,"context_line":"to create a new OVS bridge per top level parent port.  That requires"},{"line_number":251,"context_line":"an enhancement to the existing OVS and vhost-user VIF types in Nova to"},{"line_number":252,"context_line":"allow Neutron to tell Nova the name of the bridge to use for the port."},{"line_number":253,"context_line":"Currently, Nova only supports a single bridge name provided by the Nova"},{"line_number":254,"context_line":"configuration file."},{"line_number":255,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_02edd424","line":252,"in_reply_to":"ba63e191_b6f538cc","updated":"2016-01-19 20:52:17.000000000","message":"\u0027In the case that the OVS driver and an OVS binding are in use, ...\u0027  \u0027Other mechdrivers might require similar adaptations to their binding types.\u0027  All good stuff, but don\u0027t get tied up with one mechdriver when you\u0027re changing a Neutron API.","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"1468b52988bbf25ac297007ffc141409cfc1fa73","unresolved":false,"context_lines":[{"line_number":249,"context_line":"The Neutron OVS agent uses OVS in such a way that it will likely need"},{"line_number":250,"context_line":"to create a new OVS bridge per top level parent port.  That requires"},{"line_number":251,"context_line":"an enhancement to the existing OVS and vhost-user VIF types in Nova to"},{"line_number":252,"context_line":"allow Neutron to tell Nova the name of the bridge to use for the port."},{"line_number":253,"context_line":"Currently, Nova only supports a single bridge name provided by the Nova"},{"line_number":254,"context_line":"configuration file."},{"line_number":255,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_b6f538cc","line":252,"in_reply_to":"ba63e191_f313de5a","updated":"2016-01-19 16:43:11.000000000","message":"I imagine it\u0027d be based on something like the port UUID.  I don\u0027t think that detail really matters for this spec, though.","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":20000,"name":"Songming Yan","email":"yan.songming@zte.com.cn","username":"SonmingYan.zte"},"change_message_id":"423d05086fca8261dd3c0706de8d4cd5e2491924","unresolved":false,"context_lines":[{"line_number":270,"context_line":"Data Model Impact"},{"line_number":271,"context_line":"-----------------"},{"line_number":272,"context_line":""},{"line_number":273,"context_line":"Neutron port: no changes."},{"line_number":274,"context_line":""},{"line_number":275,"context_line":"Neutron DB table: trunks"},{"line_number":276,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"ba63e191_2ef236d3","line":273,"updated":"2016-01-20 03:26:57.000000000","message":"I think we should need to add a column to  mark that this port is use to be a trunkport/subport or not.","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"},{"author":{"_account_id":20000,"name":"Songming Yan","email":"yan.songming@zte.com.cn","username":"SonmingYan.zte"},"change_message_id":"1d2950595c89aecff490a8975906f5dbd053b529","unresolved":false,"context_lines":[{"line_number":275,"context_line":"Neutron DB table: trunks"},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"* id: integer primary key"},{"line_number":278,"context_line":"* uuid"},{"line_number":279,"context_line":"* name"},{"line_number":280,"context_line":"* tenant_id"},{"line_number":281,"context_line":"* port_id: foreign key to ports.id"}],"source_content_type":"text/x-rst","patch_set":11,"id":"9a68dd71_968072f9","line":278,"updated":"2016-01-26 09:01:39.000000000","message":"This \"uuid\" use for what? I don\u0027t think it is usefull.","commit_id":"5b28871408fcafa51a0ebc767695c476f3b7fe5a"}]}