)]}'
{"specs/version0.5/network-driver-interface.rst":[{"author":{"_account_id":10806,"name":"Trevor Vardeman","email":"tvardema@redhat.com","username":"tvardeman"},"change_message_id":"5db4f70e0c92116eb441efae8600651b75faa98d","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"https://blueprints.launchpad.net/octavia/+spec/network-driver-interface"},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"We need a generic interface in which to create networking resources.  Octavia"},{"line_number":16,"context_line":"cannot just assume Neutron will be used, it must also support nova-network"},{"line_number":17,"context_line":"as much as possible."},{"line_number":18,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a890539_0d2bfbeb","line":15,"updated":"2014-11-20 16:46:22.000000000","message":"Nit:  No reason for \"in which\" since \"to create\" will already satisfy why the interface is needed.","commit_id":"33a281b7809f9b7892eab4c646b7d8ff233f585f"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"7f69014b4343355769a851aebf3c01717857574a","unresolved":false,"context_lines":[{"line_number":13,"context_line":"https://blueprints.launchpad.net/octavia/+spec/network-driver-interface"},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"We need a generic interface in which to create networking resources.  Octavia"},{"line_number":16,"context_line":"cannot just assume Neutron will be used, it must also support nova-network"},{"line_number":17,"context_line":"as much as possible."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Problem description"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_f5fdf109","line":16,"updated":"2014-12-05 03:26:23.000000000","message":"... and third party SDNs that provide a compatible feature set.","commit_id":"63a427ea49e3ed9474f108e062e444a9b69de3c4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"7f69014b4343355769a851aebf3c01717857574a","unresolved":false,"context_lines":[{"line_number":45,"context_line":"    * id"},{"line_number":46,"context_line":"    * network_id"},{"line_number":47,"context_line":"    * amphora_id"},{"line_number":48,"context_line":"    * ip_address"},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"New Exceptions defined in the octavia.network package:"},{"line_number":51,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_ed2d2591","line":48,"updated":"2014-12-05 03:26:23.000000000","message":"Is the idea here that we are trying not to worry about anything resembling a Neutron port (or a virtual interface) on the amphora?","commit_id":"63a427ea49e3ed9474f108e062e444a9b69de3c4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"7fe094022206f0a919f3bd3880015a5a06732e46","unresolved":false,"context_lines":[{"line_number":45,"context_line":"    * id"},{"line_number":46,"context_line":"    * network_id"},{"line_number":47,"context_line":"    * amphora_id"},{"line_number":48,"context_line":"    * ip_address"},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"New Exceptions defined in the octavia.network package:"},{"line_number":51,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_53389cee","line":48,"in_reply_to":"5a890539_13fc540c","updated":"2014-12-05 04:38:25.000000000","message":"Totally agree that vif makes more sense. It annoys the shit out of me when I see OpenStack unnecessarily re-defining terms that carry a pre-defined meaning for the rest of the IT industry.","commit_id":"63a427ea49e3ed9474f108e062e444a9b69de3c4"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"7018708b2a8b73a625518ff79df5f2cd6ab0458d","unresolved":false,"context_lines":[{"line_number":45,"context_line":"    * id"},{"line_number":46,"context_line":"    * network_id"},{"line_number":47,"context_line":"    * amphora_id"},{"line_number":48,"context_line":"    * ip_address"},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"New Exceptions defined in the octavia.network package:"},{"line_number":51,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_13fc540c","line":48,"in_reply_to":"5a890539_ed2d2591","updated":"2014-12-05 04:17:17.000000000","message":"yeah but if you want to stick to standard networking terminology we can.  instead of port use vif, etc.  Though I suppose port is standard as well, but vif might make more sense?","commit_id":"63a427ea49e3ed9474f108e062e444a9b69de3c4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"7f69014b4343355769a851aebf3c01717857574a","unresolved":false,"context_lines":[{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Unresolved:"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"* Who owns these network resources? Service account or the user?"},{"line_number":97,"context_line":"* Who should own the resources Octavia creates?"},{"line_number":98,"context_line":"* Does Octavia create and link floating ips to neutron ports to public"},{"line_number":99,"context_line":"  connectivity?  Is there a limit on orchestration?  What if a user doesn\u0027t"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_ada87dda","line":96,"updated":"2014-12-05 03:26:23.000000000","message":"One of the concerns brought up in IRC discussion yesterday was that the user should own the VIP so that it doesn\u0027t change if they want to shuffle it around. But this is going to create problems depending on how that VIP actually gets connected with the rest of the network (eg. Neutron FLIP (ie. 1:1 static NAT), or layer-3 routing destination, etc.)\n\nIn any case, I doubt we\u0027re going to be able to arrive at a conclusion until we\u0027ve had a whiteboarding session in which we\u0027ve mapped out all the possible ways that amphorae and VIPs and routing happens on all the topologies we want to support. (Regardless of whatever Neutron or nova-networking is capable of doing at this time.) Once we know what that looks like, we should be able to decide on an abstraction that makes sense, its associated data model, and the methods and exceptions that make sense for manipulating these.","commit_id":"63a427ea49e3ed9474f108e062e444a9b69de3c4"},{"author":{"_account_id":10273,"name":"Adam Harwell","email":"flux.adam@gmail.com","username":"rm_you"},"change_message_id":"2aeefad0ef4056645fda943e515ace10300509c7","unresolved":false,"context_lines":[{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Unresolved:"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"* Who owns these network resources? Service account or the user?"},{"line_number":97,"context_line":"* Who should own the resources Octavia creates?"},{"line_number":98,"context_line":"* Does Octavia create and link floating ips to neutron ports to public"},{"line_number":99,"context_line":"  connectivity?  Is there a limit on orchestration?  What if a user doesn\u0027t"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_b057f626","line":96,"in_reply_to":"5a890539_ada87dda","updated":"2014-12-05 04:19:56.000000000","message":"The fact that a Neutron FLIP is 1:1 static is an assumption that is not always correct (as ours will not be). I don\u0027t know if the patches will make it upstream, but at least for our Neutron deployment, FLIPs will be 1:N. I also believe we won\u0027t initially *allow* users to create/manage FLIPs directly, so for us Octavia will *need* to be the one doing this work. I guess it\u0027ll have to be ... configurable, either a flag or a different implementation altogether (as long as it is possible both ways somehow). T_T\n\nI agree we probably won\u0027t nail this down until after whiteboarding.","commit_id":"63a427ea49e3ed9474f108e062e444a9b69de3c4"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"7018708b2a8b73a625518ff79df5f2cd6ab0458d","unresolved":false,"context_lines":[{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Unresolved:"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"* Who owns these network resources? Service account or the user?"},{"line_number":97,"context_line":"* Who should own the resources Octavia creates?"},{"line_number":98,"context_line":"* Does Octavia create and link floating ips to neutron ports to public"},{"line_number":99,"context_line":"  connectivity?  Is there a limit on orchestration?  What if a user doesn\u0027t"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_73ccb8bc","line":96,"in_reply_to":"5a890539_ada87dda","updated":"2014-12-05 04:17:17.000000000","message":"You are probably right, but I think as far as I can tell, this is generic enough for the creation of a vip to handle any implementation.  the network attachments methods, im not sure.  Either way, this and the overall controller scalability should be top priorities of discussion.","commit_id":"63a427ea49e3ed9474f108e062e444a9b69de3c4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"7fe094022206f0a919f3bd3880015a5a06732e46","unresolved":false,"context_lines":[{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Unresolved:"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"* Who owns these network resources? Service account or the user?"},{"line_number":97,"context_line":"* Who should own the resources Octavia creates?"},{"line_number":98,"context_line":"* Does Octavia create and link floating ips to neutron ports to public"},{"line_number":99,"context_line":"  connectivity?  Is there a limit on orchestration?  What if a user doesn\u0027t"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_d302cc0b","line":96,"in_reply_to":"5a890539_b057f626","updated":"2014-12-05 04:38:25.000000000","message":"Hmmm...  well, HP\u0027s concern that users get pissed off when their VIP goes away (because they made a small error in order of operations when doing maintenance or something) is definitely a valid one. It\u0027s a pain for users to update DNS and causes outages, eh.\n\nSo... if the user doesn\u0027t own the VIP, we\u0027ll need some way to at least keep it in reserve when the user is doing anything but a delete here, and make sure we don\u0027t change it unless that\u0027s specifically what the user is trying to do.\n\nThis would be soooo much easier if Neutron actually had a decent IP administrator. :P","commit_id":"63a427ea49e3ed9474f108e062e444a9b69de3c4"},{"author":{"_account_id":10273,"name":"Adam Harwell","email":"flux.adam@gmail.com","username":"rm_you"},"change_message_id":"a9432b5d16adbcad122848519852240745b25d3b","unresolved":false,"context_lines":[{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Unresolved:"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"* Who owns these network resources? Service account or the user?"},{"line_number":97,"context_line":"* Who should own the resources Octavia creates?"},{"line_number":98,"context_line":"* Does Octavia create and link floating ips to neutron ports to public"},{"line_number":99,"context_line":"  connectivity?  Is there a limit on orchestration?  What if a user doesn\u0027t"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_813d4ae0","line":96,"in_reply_to":"5a890539_d302cc0b","updated":"2014-12-05 06:20:36.000000000","message":"I think it\u0027s just that the answer might be that this *interface* works for both options -- I think this would work with the following two implementations, for example:\n\nRS Impl: Octavia assigns a FLIP to the Amphorae, returns IP. User uses that IP as the LB\u0027s public IP.\n\nHP Impl: Octavia assigns whatever their scaling backend IP thing is, returns the IP. User assigns their own FLIP to that IP. User uses their FLIP\u0027s IP as the LB\u0027s public IP.\n\nEither way, Octavia has to do something similar -- attach some sort of scaling IP to all of the Amphorae. It\u0027s just that in our case, that IS the public IP, and in HP\u0027s case, it\u0027s an internal only IP that needs a FLIP created and routed to it.","commit_id":"63a427ea49e3ed9474f108e062e444a9b69de3c4"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"d6a9d078f3cd3afea841895cc7a401dfbeb9cf79","unresolved":false,"context_lines":[{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Unresolved:"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"* Who owns these network resources? Service account or the user?"},{"line_number":97,"context_line":"* Who should own the resources Octavia creates?"},{"line_number":98,"context_line":"* Does Octavia create and link floating ips to neutron ports to public"},{"line_number":99,"context_line":"  connectivity?  Is there a limit on orchestration?  What if a user doesn\u0027t"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_5c1d0962","line":96,"in_reply_to":"5a890539_d302cc0b","updated":"2014-12-05 06:21:20.000000000","message":"The way to go here is to let the network driver implementation decide who owns the VIP.  and not make any assumptions in the of ownership outside of the network driver.","commit_id":"63a427ea49e3ed9474f108e062e444a9b69de3c4"},{"author":{"_account_id":10273,"name":"Adam Harwell","email":"flux.adam@gmail.com","username":"rm_you"},"change_message_id":"2aeefad0ef4056645fda943e515ace10300509c7","unresolved":false,"context_lines":[{"line_number":94,"context_line":"Unresolved:"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"* Who owns these network resources? Service account or the user?"},{"line_number":97,"context_line":"* Who should own the resources Octavia creates?"},{"line_number":98,"context_line":"* Does Octavia create and link floating ips to neutron ports to public"},{"line_number":99,"context_line":"  connectivity?  Is there a limit on orchestration?  What if a user doesn\u0027t"},{"line_number":100,"context_line":"  want to relinquish the ip on the floating ip?"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_503892ee","line":97,"updated":"2014-12-05 04:19:56.000000000","message":"IMO Octavia should -- the user should not have any visibility to behind-the-scenes, and cluttering up their nova server lists with a ton of Amphorae sounds like a recipe for a support headache.","commit_id":"63a427ea49e3ed9474f108e062e444a9b69de3c4"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"53d86177a9b6dd1ef1069472e3bf117fac7fc736","unresolved":false,"context_lines":[{"line_number":94,"context_line":"Unresolved:"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"* Who owns these network resources? Service account or the user?"},{"line_number":97,"context_line":"* Who should own the resources Octavia creates?"},{"line_number":98,"context_line":"* Does Octavia create and link floating ips to neutron ports to public"},{"line_number":99,"context_line":"  connectivity?  Is there a limit on orchestration?  What if a user doesn\u0027t"},{"line_number":100,"context_line":"  want to relinquish the ip on the floating ip?"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_7cdf253b","line":97,"in_reply_to":"5a890539_41336213","updated":"2014-12-05 06:32:55.000000000","message":"and I mean users probably wont be able to own the VIP in RAX\u0027s implementation.","commit_id":"63a427ea49e3ed9474f108e062e444a9b69de3c4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"7fe094022206f0a919f3bd3880015a5a06732e46","unresolved":false,"context_lines":[{"line_number":94,"context_line":"Unresolved:"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"* Who owns these network resources? Service account or the user?"},{"line_number":97,"context_line":"* Who should own the resources Octavia creates?"},{"line_number":98,"context_line":"* Does Octavia create and link floating ips to neutron ports to public"},{"line_number":99,"context_line":"  connectivity?  Is there a limit on orchestration?  What if a user doesn\u0027t"},{"line_number":100,"context_line":"  want to relinquish the ip on the floating ip?"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_b60c4e3b","line":97,"in_reply_to":"5a890539_503892ee","updated":"2014-12-05 04:38:25.000000000","message":"+1\n\nAlso, the operator might not want to expose what\u0027s actually in the amphora image to the user. If the user owns the amphora, I think they might be able to create a snapshot of it, which would be bad in this case.\n\nAmphora should absolutely be a black box to the user.","commit_id":"63a427ea49e3ed9474f108e062e444a9b69de3c4"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"d6a9d078f3cd3afea841895cc7a401dfbeb9cf79","unresolved":false,"context_lines":[{"line_number":94,"context_line":"Unresolved:"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"* Who owns these network resources? Service account or the user?"},{"line_number":97,"context_line":"* Who should own the resources Octavia creates?"},{"line_number":98,"context_line":"* Does Octavia create and link floating ips to neutron ports to public"},{"line_number":99,"context_line":"  connectivity?  Is there a limit on orchestration?  What if a user doesn\u0027t"},{"line_number":100,"context_line":"  want to relinquish the ip on the floating ip?"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_41336213","line":97,"in_reply_to":"5a890539_b60c4e3b","updated":"2014-12-05 06:21:20.000000000","message":"So I just don\u0027t think users are going to be able to own the vip (which woudl be our version of a FLIP).  However, I think this is still up to the network driver implementation and as long as the network driver implementation also has the appropriate clean up methods, it shouldn\u0027t be a problem.  In theory of course.","commit_id":"63a427ea49e3ed9474f108e062e444a9b69de3c4"},{"author":{"_account_id":10273,"name":"Adam Harwell","email":"flux.adam@gmail.com","username":"rm_you"},"change_message_id":"2aeefad0ef4056645fda943e515ace10300509c7","unresolved":false,"context_lines":[{"line_number":97,"context_line":"* Who should own the resources Octavia creates?"},{"line_number":98,"context_line":"* Does Octavia create and link floating ips to neutron ports to public"},{"line_number":99,"context_line":"  connectivity?  Is there a limit on orchestration?  What if a user doesn\u0027t"},{"line_number":100,"context_line":"  want to relinquish the ip on the floating ip?"},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Alternatives"},{"line_number":103,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_93f5a4ce","line":100,"updated":"2014-12-05 04:19:56.000000000","message":"It needs to be doable by Octavia in some cases, as mentioned above (when the FLIP is the *only* scaling-IP connected to the Amphorae).","commit_id":"63a427ea49e3ed9474f108e062e444a9b69de3c4"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"11c6241228967ecb09778c559157ab8c22fcba17","unresolved":false,"context_lines":[{"line_number":97,"context_line":"* Who should own the resources Octavia creates?"},{"line_number":98,"context_line":"* Does Octavia create and link floating ips to neutron ports to public"},{"line_number":99,"context_line":"  connectivity?  Is there a limit on orchestration?  What if a user doesn\u0027t"},{"line_number":100,"context_line":"  want to relinquish the ip on the floating ip?"},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Alternatives"},{"line_number":103,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a961159_e9f6598e","line":100,"in_reply_to":"3a961159_56f7248b","updated":"2014-12-11 17:20:53.000000000","message":"We also liked the model of VIP -\u003e \"internal routing IP\" because it nicely fits LVS as well... \n\nNeutron might be too unstable to effectively run keepalived, inserting routes at scale -- just a thought experiment you loose a complete rack with say 1000 lbs - that means you need to insert 1000 new routes at the same time. Not sure if Neutron can handle that. We found that rate limiting calls to neutron (and nova) is a must to not make them explode... but without real tests we are just speculating :-(","commit_id":"63a427ea49e3ed9474f108e062e444a9b69de3c4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"52c318c359fca9c79d35c2c661e3f9fac6b04da8","unresolved":false,"context_lines":[{"line_number":97,"context_line":"* Who should own the resources Octavia creates?"},{"line_number":98,"context_line":"* Does Octavia create and link floating ips to neutron ports to public"},{"line_number":99,"context_line":"  connectivity?  Is there a limit on orchestration?  What if a user doesn\u0027t"},{"line_number":100,"context_line":"  want to relinquish the ip on the floating ip?"},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Alternatives"},{"line_number":103,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a961159_56f7248b","line":100,"in_reply_to":"5a890539_5c06e91d","updated":"2014-12-11 00:33:38.000000000","message":"We\u0027re actually somewhat flexible on this so long as it can be done using standard OpenStack components or other open-source components. Off the top of my head, in implementing ACTIVE-STANDBY, if we do this like we\u0027ve done other highly-available IPs then our topology looks a lot like what I assume HP\u0027s looks like. Steps for setting up the VIP and internal \"routing IP\" (which lives on the LoadBalancer network) looks like this, in a nutshell:\n\n1. Assign \"routing IP\" from LoadBalancer network to non-existent port (in effect, to reserve the IP).\n2. Adjust port security settings on active and standby amphorae ports on the LB network to allow them to send and receive packets originating from the routing IP.\n3. Set up ucarp / keepalived / corosync + pacemaker up on active and standby nodes to keep the routing IP highly available.\n4. Set up FLIP from external IP address (load balancer VIP) to the routing IP.\n\n(Obviously, a lot of detail skipped above, but that\u0027s essentially what the process looks like.) The above would allow for sub-second failover from the active to standby amphora without intervention of Octavia\u0027s controller, Neutron, or anything else.\n\nNote that on 4: I would really rather follow what I think is the RS model here (and this is what we do on our legacy load balancing product):\n\nA. Do steps 1-3 above, and the \"routing IP\" is still an internal IP.\nB. When a new loadbalancer VIP is deployed to the active-standby pair, each machine binds to the VIP IP address on a non-arping interface (eg. dummy0).\nC. Then, Octavia inserts a routing rule into Neutron to route the loadbalancer\u0027s VIP traffic to the routing IP (no NAT necessary). (I don\u0027t presently know whether this is possible.)\n\nIf we can get the above, it\u0027s only a small step to be able to do ACTIVE-ACTIVE everywhere.","commit_id":"63a427ea49e3ed9474f108e062e444a9b69de3c4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"7fe094022206f0a919f3bd3880015a5a06732e46","unresolved":false,"context_lines":[{"line_number":97,"context_line":"* Who should own the resources Octavia creates?"},{"line_number":98,"context_line":"* Does Octavia create and link floating ips to neutron ports to public"},{"line_number":99,"context_line":"  connectivity?  Is there a limit on orchestration?  What if a user doesn\u0027t"},{"line_number":100,"context_line":"  want to relinquish the ip on the floating ip?"},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Alternatives"},{"line_number":103,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_963672e7","line":100,"in_reply_to":"5a890539_93f5a4ce","updated":"2014-12-05 04:38:25.000000000","message":"Yep. Need to get those front-end and back-end topologies ironed out so we know exactly which cases this applies to.","commit_id":"63a427ea49e3ed9474f108e062e444a9b69de3c4"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"d6a9d078f3cd3afea841895cc7a401dfbeb9cf79","unresolved":false,"context_lines":[{"line_number":97,"context_line":"* Who should own the resources Octavia creates?"},{"line_number":98,"context_line":"* Does Octavia create and link floating ips to neutron ports to public"},{"line_number":99,"context_line":"  connectivity?  Is there a limit on orchestration?  What if a user doesn\u0027t"},{"line_number":100,"context_line":"  want to relinquish the ip on the floating ip?"},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Alternatives"},{"line_number":103,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_5c06e91d","line":100,"in_reply_to":"5a890539_963672e7","updated":"2014-12-05 06:21:20.000000000","message":"How are you planning on doing BBG\u0027s implementation?  Shared IP at first, but how will you accomplish that?","commit_id":"63a427ea49e3ed9474f108e062e444a9b69de3c4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"7f69014b4343355769a851aebf3c01717857574a","unresolved":false,"context_lines":[{"line_number":103,"context_line":"------------"},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"* Straight Neutron Interface (networks, subnets, ports, floatingips)"},{"line_number":106,"context_line":"* Straight Nova-Network Interface (network, fixed_ips, floatingips)"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"Data model impact"},{"line_number":109,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_ed89a570","line":106,"updated":"2014-12-05 03:26:23.000000000","message":"Yeah... I would say that not using an abstraction is simply not an option. XD But I agree that mentioning what you have here makes sense.","commit_id":"63a427ea49e3ed9474f108e062e444a9b69de3c4"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"ba47094ccaf4d9720fd4efee24b785866b8de9b8","unresolved":false,"context_lines":[{"line_number":71,"context_line":"    * vip \u003d instance of a VIP"},{"line_number":72,"context_line":"    * returns None"},{"line_number":73,"context_line":"    * raises UnplugVIPException"},{"line_number":74,"context_line":"* plug_network(amphora_id, network_id)"},{"line_number":75,"context_line":"    * amphora_id \u003d id of an amphora"},{"line_number":76,"context_line":"    * network_id \u003d id of the network to attach"},{"line_number":77,"context_line":"    * returns Interface instance"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3a961159_40e94919","line":74,"updated":"2014-12-17 22:31:51.000000000","message":"I think we talked about specifying an  ip if needed","commit_id":"e342d3d855fbc6170d8f7a4d9c30cf5918ed341e"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"1114a8e26d751467cfff8d56518281d69658b0b4","unresolved":false,"context_lines":[{"line_number":71,"context_line":"    * vip \u003d instance of a VIP"},{"line_number":72,"context_line":"    * returns None"},{"line_number":73,"context_line":"    * raises UnplugVIPException"},{"line_number":74,"context_line":"* plug_network(amphora_id, network_id)"},{"line_number":75,"context_line":"    * amphora_id \u003d id of an amphora"},{"line_number":76,"context_line":"    * network_id \u003d id of the network to attach"},{"line_number":77,"context_line":"    * returns Interface instance"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3a961159_7320dd9b","line":74,"in_reply_to":"3a961159_40e94919","updated":"2014-12-17 23:33:11.000000000","message":"Done","commit_id":"e342d3d855fbc6170d8f7a4d9c30cf5918ed341e"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"ba47094ccaf4d9720fd4efee24b785866b8de9b8","unresolved":false,"context_lines":[{"line_number":80,"context_line":"    * attachment \u003d instance of an Attachment"},{"line_number":81,"context_line":"    * returns None"},{"line_number":82,"context_line":"    * raises UnplugNetworkException"},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"Alternatives"},{"line_number":85,"context_line":"------------"},{"line_number":86,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"3a961159_208b5d69","line":83,"updated":"2014-12-17 22:31:51.000000000","message":"- I think we talked about a reserveVIP method yesterday...\n- also if we start a VM it will come with one interface already attached. How is that handled?","commit_id":"e342d3d855fbc6170d8f7a4d9c30cf5918ed341e"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"1114a8e26d751467cfff8d56518281d69658b0b4","unresolved":false,"context_lines":[{"line_number":80,"context_line":"    * attachment \u003d instance of an Attachment"},{"line_number":81,"context_line":"    * returns None"},{"line_number":82,"context_line":"    * raises UnplugNetworkException"},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"Alternatives"},{"line_number":85,"context_line":"------------"},{"line_number":86,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"3a961159_a0158d4a","line":83,"in_reply_to":"3a961159_208b5d69","updated":"2014-12-17 23:33:11.000000000","message":"yeah you\u0027re right, i forgot about that.","commit_id":"e342d3d855fbc6170d8f7a4d9c30cf5918ed341e"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"9eab202f62958e415399767187c3ba97d734f834","unresolved":false,"context_lines":[{"line_number":90,"context_line":"    * returns Interface instance"},{"line_number":91,"context_line":"    * raises PlugNetworkException"},{"line_number":92,"context_line":"* unplug_network(amphora_id, network_id)"},{"line_number":93,"context_line":"    * attachment \u003d instance of an Attachment"},{"line_number":94,"context_line":"    * returns None"},{"line_number":95,"context_line":"    * raises UnplugNetworkException"},{"line_number":96,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"3a961159_49b21407","line":93,"updated":"2014-12-19 16:14:13.000000000","message":"I need to fix this, but will wait until the overall taskflow discussion wraps up.","commit_id":"b60ccf5cd11c6ad24a2d734b131f8efc6a1a7e55"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"d7742a3996296e92703beae4561f87510c6b4a67","unresolved":false,"context_lines":[{"line_number":32,"context_line":"frontend and backend connectivity. The idea is that to implement these methods"},{"line_number":33,"context_line":"it may require multiple requests to the networking service to accomplish the"},{"line_number":34,"context_line":"end result.  This will also require keeping track of resources internally,"},{"line_number":35,"context_line":"so we may need tables for that."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Existing data model:"},{"line_number":38,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_e28fe774","line":35,"updated":"2015-01-09 21:44:59.000000000","message":"1) The network driver should be as stateless as possible. State should be stored in the network system (e.g. neutron) itself\n\n2) To scale we might run things like attachVIP for the same compute node for multiple VIPs in parallel on multiple workers on different servers e.g. plug VIp1 with worker on server1, plug VIP2 with worker2 on server2 -- the driver should be capable of that or document limitations.","commit_id":"06ede5f91e2187b4e7bc2031518d21418e980741"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"138d98eed88d4f6a8a36a4d494a7990e42ebef2f","unresolved":false,"context_lines":[{"line_number":32,"context_line":"frontend and backend connectivity. The idea is that to implement these methods"},{"line_number":33,"context_line":"it may require multiple requests to the networking service to accomplish the"},{"line_number":34,"context_line":"end result.  This will also require keeping track of resources internally,"},{"line_number":35,"context_line":"so we may need tables for that."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Existing data model:"},{"line_number":38,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_e2ca8745","line":35,"in_reply_to":"3a961159_e28fe774","updated":"2015-01-09 22:07:24.000000000","message":"+1","commit_id":"06ede5f91e2187b4e7bc2031518d21418e980741"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"7f564b265d6b148c80a54100b209ff0f30630cec","unresolved":false,"context_lines":[{"line_number":32,"context_line":"frontend and backend connectivity. The idea is that to implement these methods"},{"line_number":33,"context_line":"it may require multiple requests to the networking service to accomplish the"},{"line_number":34,"context_line":"end result.  This will also require keeping track of resources internally,"},{"line_number":35,"context_line":"so we may need tables for that."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Existing data model:"},{"line_number":38,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_b8642ee7","line":35,"in_reply_to":"3a961159_e28fe774","updated":"2015-01-09 23:52:21.000000000","message":"I will make a note about this.","commit_id":"06ede5f91e2187b4e7bc2031518d21418e980741"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"138d98eed88d4f6a8a36a4d494a7990e42ebef2f","unresolved":false,"context_lines":[{"line_number":42,"context_line":"    * network_id - (neutron subnet)"},{"line_number":43,"context_line":"    * interface_id - (neutron port)"},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"New data model:"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"* class Interface"},{"line_number":48,"context_line":"    * id"}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_e24d27c7","line":45,"updated":"2015-01-09 22:07:24.000000000","message":"Are you proposing replacing the VIP data model with \"Interface\" or is this in addition to VIP?","commit_id":"06ede5f91e2187b4e7bc2031518d21418e980741"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"7f564b265d6b148c80a54100b209ff0f30630cec","unresolved":false,"context_lines":[{"line_number":42,"context_line":"    * network_id - (neutron subnet)"},{"line_number":43,"context_line":"    * interface_id - (neutron port)"},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"New data model:"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"* class Interface"},{"line_number":48,"context_line":"    * id"}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_184382b0","line":45,"in_reply_to":"3a961159_e24d27c7","updated":"2015-01-09 23:52:21.000000000","message":"No this would be a new one.  I am unsure whether this needs to be an actual db table though as this is merely a data structure meant to be for easily readable return values (as opposed to returning a tuple).\n\nAs of now, its just intended to be a container for what neutorn/nova/name your service returns.  We may end up putting these in our database if the system needs to start querying neutron/nova/name your service and a high rate.","commit_id":"06ede5f91e2187b4e7bc2031518d21418e980741"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"d7742a3996296e92703beae4561f87510c6b4a67","unresolved":false,"context_lines":[{"line_number":48,"context_line":"    * id"},{"line_number":49,"context_line":"    * network_id"},{"line_number":50,"context_line":"    * amphora_id"},{"line_number":51,"context_line":"    * ip_address"},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"New Exceptions defined in the octavia.network package:"},{"line_number":54,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_0269538c","line":51,"updated":"2015-01-09 21:44:59.000000000","message":"v4 or v6 - please be specific or if it can be either one say so","commit_id":"06ede5f91e2187b4e7bc2031518d21418e980741"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"d7742a3996296e92703beae4561f87510c6b4a67","unresolved":false,"context_lines":[{"line_number":63,"context_line":"The interface will be the following:"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"class AbstractNetworkDriver"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* plug_vip(loadbalancer, vip)"},{"line_number":68,"context_line":"    * loadbalancer - instance of data_models.LoadBalancer"},{"line_number":69,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_82daa349","line":66,"updated":"2015-01-09 21:44:59.000000000","message":"Per harlowja if we want to use Taskflow inside the driver effectively we need to communicate a \"logbook handle\" -- how will that be done?","commit_id":"06ede5f91e2187b4e7bc2031518d21418e980741"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"138d98eed88d4f6a8a36a4d494a7990e42ebef2f","unresolved":false,"context_lines":[{"line_number":86,"context_line":"    * ip_address \u003d will attempt to allocate this specific IP address"},{"line_number":87,"context_line":"    * returns VIP instance"},{"line_number":88,"context_line":"    * raises AllocateVIPException"},{"line_number":89,"context_line":"* deallocate_vip(vip):"},{"line_number":90,"context_line":"    * vip \u003d VIP instance"},{"line_number":91,"context_line":"    * returns None"},{"line_number":92,"context_line":"    * raises DeallocateVIPException"}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_22000f02","line":89,"updated":"2015-01-09 22:07:24.000000000","message":"I would like to see a bit more in comments about how this interface is expected to behave.  I.e. if I deallocate_vip that is plugged, is it expected that it will get un-plugged or throw an exception?","commit_id":"06ede5f91e2187b4e7bc2031518d21418e980741"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"7f564b265d6b148c80a54100b209ff0f30630cec","unresolved":false,"context_lines":[{"line_number":86,"context_line":"    * ip_address \u003d will attempt to allocate this specific IP address"},{"line_number":87,"context_line":"    * returns VIP instance"},{"line_number":88,"context_line":"    * raises AllocateVIPException"},{"line_number":89,"context_line":"* deallocate_vip(vip):"},{"line_number":90,"context_line":"    * vip \u003d VIP instance"},{"line_number":91,"context_line":"    * returns None"},{"line_number":92,"context_line":"    * raises DeallocateVIPException"}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_785486fe","line":89,"in_reply_to":"3a961159_22000f02","updated":"2015-01-09 23:52:21.000000000","message":"I would expect that to be detailed in any spec that defines how this interface will be implemented (i.e. implementation detail).  This interface cannot control how the implementor wants to implement it.\n\nHowever, this could provide details on what exactly these methods are generally expected to do.  I don\u0027t think it should make assumptions on specific behavior like you mentioned above.","commit_id":"06ede5f91e2187b4e7bc2031518d21418e980741"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"3eea0b3b6b3669f93d1659e58d2cbdf754a8a749","unresolved":false,"context_lines":[{"line_number":86,"context_line":"    * ip_address \u003d will attempt to allocate this specific IP address"},{"line_number":87,"context_line":"    * returns VIP instance"},{"line_number":88,"context_line":"    * raises AllocateVIPException"},{"line_number":89,"context_line":"* deallocate_vip(vip):"},{"line_number":90,"context_line":"    * vip \u003d VIP instance"},{"line_number":91,"context_line":"    * returns None"},{"line_number":92,"context_line":"    * raises DeallocateVIPException"}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_a71dea64","line":89,"in_reply_to":"3a961159_785486fe","updated":"2015-01-10 06:15:12.000000000","message":"Thinking about this even more I could see an argument for raising a NotFound exception on many of these methods and a VIPInUse exception in this method in particular.  However, I feel like that is a slippery slope.  What if an implementation can\u0027t deallocate a vip because for some reason it already got deleted? \n\nI could be wrong on this and in the end we need to define these methods but since we know we have control over the layer calling these methods, we can guarantee we call unplug_vip first and then deallocate_vip after.","commit_id":"06ede5f91e2187b4e7bc2031518d21418e980741"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"138d98eed88d4f6a8a36a4d494a7990e42ebef2f","unresolved":false,"context_lines":[{"line_number":108,"context_line":"* Straight Neutron Interface (networks, subnets, ports, floatingips)"},{"line_number":109,"context_line":"* Straight Nova-Network Interface (network, fixed_ips, floatingips)"},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"Data model impact"},{"line_number":112,"context_line":"-----------------"},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"* Remove floating_ip_id from VIP model and migration"}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_227bafbf","line":111,"updated":"2015-01-09 22:07:24.000000000","message":"This should include the \"new data model\" comment from above right?","commit_id":"06ede5f91e2187b4e7bc2031518d21418e980741"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"7f564b265d6b148c80a54100b209ff0f30630cec","unresolved":false,"context_lines":[{"line_number":108,"context_line":"* Straight Neutron Interface (networks, subnets, ports, floatingips)"},{"line_number":109,"context_line":"* Straight Nova-Network Interface (network, fixed_ips, floatingips)"},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"Data model impact"},{"line_number":112,"context_line":"-----------------"},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"* Remove floating_ip_id from VIP model and migration"}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_38475e7c","line":111,"in_reply_to":"3a961159_227bafbf","updated":"2015-01-09 23:52:21.000000000","message":"I believe the spirit of this was intended to show database changes, so thats why I\u0027m only listing those.  Though if we want to show even data models that that is our perogative.  Doesn\u0027t matter to me.","commit_id":"06ede5f91e2187b4e7bc2031518d21418e980741"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"a842ad8570fd0c97927f0ee8b3d72ff34a9772c9","unresolved":false,"context_lines":[{"line_number":64,"context_line":"* DeallocateVIPException"},{"line_number":65,"context_line":"* PlugNetworkException"},{"line_number":66,"context_line":"* UnplugNetworkException"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"This class defines the methods for a fully functional network driver."},{"line_number":70,"context_line":"Implementations of this interface can expect a rollback to occur if any of"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_53b324ec","line":67,"updated":"2015-01-11 03:45:49.000000000","message":"There was some discussion in previous versions about raising NotFound, etc. exceptions. As my 2ct it is often better to program as defensive as possible since it is unclear if the person making changes in the future remembers all the constraints.","commit_id":"4e383b943ba99b0aa77421500bbad9cdd51b1c4f"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"0be8b9204d6474a1f651f22d983d6aee25d50f2f","unresolved":false,"context_lines":[{"line_number":64,"context_line":"* DeallocateVIPException"},{"line_number":65,"context_line":"* PlugNetworkException"},{"line_number":66,"context_line":"* UnplugNetworkException"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"This class defines the methods for a fully functional network driver."},{"line_number":70,"context_line":"Implementations of this interface can expect a rollback to occur if any of"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_33005802","line":67,"in_reply_to":"3a961159_53b324ec","updated":"2015-01-11 05:49:41.000000000","message":"No strong opinion on this.  I do believe we shouldn\u0027t try to have an exception to try and cover implementation issues.  However, a NotFound and VIPInUse exception should be fairly obvious.  I\u0027ll add them in next PS.","commit_id":"4e383b943ba99b0aa77421500bbad9cdd51b1c4f"}]}