)]}'
{"doc/source/design/version0.5/component-design.rst":[{"author":{"_account_id":6437,"name":"Susanne Balle","email":"sleipnir012@gmail.com","username":"susanne-balle"},"change_message_id":"0481f2042ce24f787aade12c1aea3da4db367ed7","unresolved":false,"context_lines":[{"line_number":60,"context_line":"with which it must interact in order to keep these interfaces as clean as"},{"line_number":61,"context_line":"possible."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"Initially, all the components in this section will be entirely under the"},{"line_number":64,"context_line":"purview of the Octavia project. Over time some of these components might be"},{"line_number":65,"context_line":"eliminated entirely, or reduced in scope as these third-party services"},{"line_number":66,"context_line":"evolve and increase in cleanly-consumable functionality."}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_674b155f","line":63,"updated":"2014-08-12 10:36:30.000000000","message":"Not sure I agree or maybe I am just misunderstanding what you are saying. Won\u0027t we need to interact with some of the other advanced services as part of services chaining, etc? I agree that we need clean interfaces all the way through the stack of interactions e.g. between LBaaS and Neutron, etc.","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"165b60c63f3ba608b4afbbaf5d2e5b6b39942798","unresolved":false,"context_lines":[{"line_number":60,"context_line":"with which it must interact in order to keep these interfaces as clean as"},{"line_number":61,"context_line":"possible."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"Initially, all the components in this section will be entirely under the"},{"line_number":64,"context_line":"purview of the Octavia project. Over time some of these components might be"},{"line_number":65,"context_line":"eliminated entirely, or reduced in scope as these third-party services"},{"line_number":66,"context_line":"evolve and increase in cleanly-consumable functionality."}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_78dc8146","line":63,"in_reply_to":"baada198_674b155f","updated":"2014-08-12 18:17:49.000000000","message":"So, \"service chaining\" has yet to see any kind of realistic plan, let alone implementation within Neutron. Presumably, it should be possible to chain LBaaS together with, say, VPNaaS...  once there is a tangible plan to do so.\n\nIn any case, what we are going after here is loosely-coupled services, which will entail clean interfaces at all points of interaction. (Unfortunately, that\u0027s not what we get today, but that\u0027s what the \u0027Network Driver\u0027 is all about...  more on that below.)","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":6437,"name":"Susanne Balle","email":"sleipnir012@gmail.com","username":"susanne-balle"},"change_message_id":"0481f2042ce24f787aade12c1aea3da4db367ed7","unresolved":false,"context_lines":[{"line_number":118,"context_line":"  same Octavia VM at the same time. Emphasis on the idempotency of the update"},{"line_number":119,"context_line":"  algorithms used should help minimize the issues this can potentially cause."},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"NETWORK DRIVER"},{"line_number":122,"context_line":"--------------"},{"line_number":123,"context_line":"In order to keep Octavia\u0027s design more clean as a pure consumer of network"},{"line_number":124,"context_line":"services, yet still be able to develop Octavia at a time when it is impossible"}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_27fd9db2","line":121,"updated":"2014-08-12 10:36:30.000000000","message":"Could somebody elaborate on this? What functionality would this \"network driver\" do? I am assuming it is just triggering Neutron APIs and not rewriting Neutron functionality.  Have we designed this yet?","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":10273,"name":"Adam Harwell","email":"flux.adam@gmail.com","username":"rm_you"},"change_message_id":"e634a0749a9ffb1d00726185c9ef9520f5c60ca7","unresolved":false,"context_lines":[{"line_number":118,"context_line":"  same Octavia VM at the same time. Emphasis on the idempotency of the update"},{"line_number":119,"context_line":"  algorithms used should help minimize the issues this can potentially cause."},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"NETWORK DRIVER"},{"line_number":122,"context_line":"--------------"},{"line_number":123,"context_line":"In order to keep Octavia\u0027s design more clean as a pure consumer of network"},{"line_number":124,"context_line":"services, yet still be able to develop Octavia at a time when it is impossible"}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_b8c45962","line":121,"in_reply_to":"baada198_27fd9db2","updated":"2014-08-12 18:17:58.000000000","message":"I know we\u0027re having velocity issues with Neutron, but I don\u0027t know if making our own temporary API to access to functions we need is the best idea... Could we not devote that same effort to actually putting the functions we need in the official Neutron API? Or are we considering working within Neutron a lost cause at this point? :/","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"165b60c63f3ba608b4afbbaf5d2e5b6b39942798","unresolved":false,"context_lines":[{"line_number":118,"context_line":"  same Octavia VM at the same time. Emphasis on the idempotency of the update"},{"line_number":119,"context_line":"  algorithms used should help minimize the issues this can potentially cause."},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"NETWORK DRIVER"},{"line_number":122,"context_line":"--------------"},{"line_number":123,"context_line":"In order to keep Octavia\u0027s design more clean as a pure consumer of network"},{"line_number":124,"context_line":"services, yet still be able to develop Octavia at a time when it is impossible"}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_b86d3904","line":121,"in_reply_to":"baada198_27fd9db2","updated":"2014-08-12 18:17:49.000000000","message":"It is doubtful that Neutron\u0027s publicly-consumable API as it currently stands will be able to do everything we need to do to accomplish delivering load balancing services, including managing the lifecycle of the Octavia VMs, special routing rules for front- and back-end connectivity, etc.\n\nIn the past, other projects have simply loaded Neutron objects directly and/or manipulated the Neutron database. This is a very \"dirty\" way of achieving the kind of functionality necessary to deliver the service and makes these other services inherently tied closely to Neutron (in a very fragile way, I might add).\n\nSo the dilemma is that we definitely need our networking functionality to work, but we don\u0027t want to be that closely coupled with Neutron. To solve this problem, we\u0027ll put all our \"dirty hacks\" into this component which will be as loosely coupled with Octavia, as Octavia is to Neutron. Eventually, we will want to work to make interfaces cleaner, but we can\u0027t wait indefinitely long for Neutron to deliver clean interfaces.\n\nAlso, in the v1.0 design under consideration, I called this component the \"Neutron-shim\". I\u0027m changing the name to Network Driver at this point, because given the political fiasco presently happening with the Neutron project  (and the \u0027neutron-incubator\u0027 offshoot proposal), it may behoove us to be even less closely tied to Neutron. If we make this component a \u0027network driver\u0027, there\u0027s no reason we couldn\u0027t also make a network driver that works with nova-networking, nor is there a reason a 3rd party vendor couldn\u0027t develop a driver to talk with their own proprietary networking product.","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"956fb4a8bff94bf66ece6240b52ac904f9afa7e6","unresolved":false,"context_lines":[{"line_number":118,"context_line":"  same Octavia VM at the same time. Emphasis on the idempotency of the update"},{"line_number":119,"context_line":"  algorithms used should help minimize the issues this can potentially cause."},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"NETWORK DRIVER"},{"line_number":122,"context_line":"--------------"},{"line_number":123,"context_line":"In order to keep Octavia\u0027s design more clean as a pure consumer of network"},{"line_number":124,"context_line":"services, yet still be able to develop Octavia at a time when it is impossible"}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_fb6c0b6e","line":121,"in_reply_to":"baada198_b8c45962","updated":"2014-08-12 18:31:23.000000000","message":"So, I don\u0027t think we want to rely on features we push to get into the official Neutron API landing in any kind of timeframe that we can work with. By abstracting out communication with the networking provider, this gives us the following benefits:\n\n* A \"stable\" API we can work with (which will just get translated into Neutron API commands).\n\n* Ability to change the API we interface with quickly, and without having to jump through the hoops necessary to get this through Neutron approval.\n\n* Ability to use an alternate networking service provider should Neutron not pan out in the long run.\n\n* Separates concerns around delivering reliable, high-performance load balancing from interfacing with the networking layer.","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":6437,"name":"Susanne Balle","email":"sleipnir012@gmail.com","username":"susanne-balle"},"change_message_id":"0481f2042ce24f787aade12c1aea3da4db367ed7","unresolved":false,"context_lines":[{"line_number":201,"context_line":"  data about specific loadbalancers or sub-objects, their status, and"},{"line_number":202,"context_line":"  statistics."},{"line_number":203,"context_line":""},{"line_number":204,"context_line":"* octavia VM lifecycle management, including interfacing with Nova and Neutron"},{"line_number":205,"context_line":"  to spin up new octavia VMs as necessary and handle initial configuration and"},{"line_number":206,"context_line":"  network plumbing for their LB network interface, and cleaning this up when a"},{"line_number":207,"context_line":"  octavia VM is destroyed."}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_678dd529","line":204,"updated":"2014-08-12 10:36:30.000000000","message":"I am assuming the Octavia VMs will be owned by the LBaaS tenant? or are we planning to have them be owned byt the user \u0027s tenant? If the VMs are owned by the user tenant the user will see them if he/she does a nova list.","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"165b60c63f3ba608b4afbbaf5d2e5b6b39942798","unresolved":false,"context_lines":[{"line_number":201,"context_line":"  data about specific loadbalancers or sub-objects, their status, and"},{"line_number":202,"context_line":"  statistics."},{"line_number":203,"context_line":""},{"line_number":204,"context_line":"* octavia VM lifecycle management, including interfacing with Nova and Neutron"},{"line_number":205,"context_line":"  to spin up new octavia VMs as necessary and handle initial configuration and"},{"line_number":206,"context_line":"  network plumbing for their LB network interface, and cleaning this up when a"},{"line_number":207,"context_line":"  octavia VM is destroyed."}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_98579528","line":204,"in_reply_to":"baada198_678dd529","updated":"2014-08-12 18:17:49.000000000","message":"Octavia VMs will be owned by the LBaaS tenant (or some other \"service\" or \"system\" account).","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":10273,"name":"Adam Harwell","email":"flux.adam@gmail.com","username":"rm_you"},"change_message_id":"e634a0749a9ffb1d00726185c9ef9520f5c60ca7","unresolved":false,"context_lines":[{"line_number":201,"context_line":"  data about specific loadbalancers or sub-objects, their status, and"},{"line_number":202,"context_line":"  statistics."},{"line_number":203,"context_line":""},{"line_number":204,"context_line":"* octavia VM lifecycle management, including interfacing with Nova and Neutron"},{"line_number":205,"context_line":"  to spin up new octavia VMs as necessary and handle initial configuration and"},{"line_number":206,"context_line":"  network plumbing for their LB network interface, and cleaning this up when a"},{"line_number":207,"context_line":"  octavia VM is destroyed."}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_98c3153a","line":204,"in_reply_to":"baada198_678dd529","updated":"2014-08-12 18:17:58.000000000","message":"Same question, I had assumed the VMs would be owned by LBaaS tenant, but it would be good to be on the same page.","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"956fb4a8bff94bf66ece6240b52ac904f9afa7e6","unresolved":false,"context_lines":[{"line_number":201,"context_line":"  data about specific loadbalancers or sub-objects, their status, and"},{"line_number":202,"context_line":"  statistics."},{"line_number":203,"context_line":""},{"line_number":204,"context_line":"* octavia VM lifecycle management, including interfacing with Nova and Neutron"},{"line_number":205,"context_line":"  to spin up new octavia VMs as necessary and handle initial configuration and"},{"line_number":206,"context_line":"  network plumbing for their LB network interface, and cleaning this up when a"},{"line_number":207,"context_line":"  octavia VM is destroyed."}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_7b98fb69","line":204,"in_reply_to":"baada198_98c3153a","updated":"2014-08-12 18:31:23.000000000","message":"See my response to Susanne above. (I think you and I published comments at the same moment. XD)","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":6437,"name":"Susanne Balle","email":"sleipnir012@gmail.com","username":"susanne-balle"},"change_message_id":"0481f2042ce24f787aade12c1aea3da4db367ed7","unresolved":false,"context_lines":[{"line_number":239,"context_line":"This is the subnet that controllers will use to communicate with octavia VMs."},{"line_number":240,"context_line":"This means that controllers must have connectivity (either layer 2 or routed)"},{"line_number":241,"context_line":"to this subnet in order to function, and visa versa. Since Octavia VMs will be"},{"line_number":242,"context_line":"communicating on it, this means the network is not part of the \"undercloud.\""},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"**Notes:**"},{"line_number":245,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_872ca902","line":242,"updated":"2014-08-12 10:36:30.000000000","message":"Isn\u0027t this a deployment decision? I could setup a service network with a neutron provider network and decide to have all my load-balancers communicate over that network. I would take the part about \"undercloud\" out.","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"165b60c63f3ba608b4afbbaf5d2e5b6b39942798","unresolved":false,"context_lines":[{"line_number":239,"context_line":"This is the subnet that controllers will use to communicate with octavia VMs."},{"line_number":240,"context_line":"This means that controllers must have connectivity (either layer 2 or routed)"},{"line_number":241,"context_line":"to this subnet in order to function, and visa versa. Since Octavia VMs will be"},{"line_number":242,"context_line":"communicating on it, this means the network is not part of the \"undercloud.\""},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"**Notes:**"},{"line_number":245,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_b81b7983","line":242,"in_reply_to":"baada198_872ca902","updated":"2014-08-12 18:17:49.000000000","message":"The point is that both Neutron and Nova need to be aware of the LB Network in order to plumb interfaces on it. As far as I\u0027m aware, this is not possible if the LB Network is part of the undercloud, because Neutron and Nova are not aware of \u0027undercloud\u0027 networks.","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":6437,"name":"Susanne Balle","email":"sleipnir012@gmail.com","username":"susanne-balle"},"change_message_id":"0481f2042ce24f787aade12c1aea3da4db367ed7","unresolved":false,"context_lines":[{"line_number":280,"context_line":""},{"line_number":281,"context_line":"* Since octavia VMs speak to controllers in a \"trusted\" way, it\u0027s important to"},{"line_number":282,"context_line":"  ensure that users do not have command-line access to the octavia VMs. In"},{"line_number":283,"context_line":"  other words, the octavia VMs should be a black box from the users\u0027"},{"line_number":284,"context_line":"  perspective."},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"* Octavia VMs will be powered using haproxy 1.5 initially. We may decide to use"}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_67931500","line":283,"updated":"2014-08-12 10:36:30.000000000","message":"See comment above about lbaas tenant versus user tenant. The other alternative would be to have a nova flavor that is not visible to the user when he/she does nova list but is still running under the user\u0027 tenant.","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"165b60c63f3ba608b4afbbaf5d2e5b6b39942798","unresolved":false,"context_lines":[{"line_number":280,"context_line":""},{"line_number":281,"context_line":"* Since octavia VMs speak to controllers in a \"trusted\" way, it\u0027s important to"},{"line_number":282,"context_line":"  ensure that users do not have command-line access to the octavia VMs. In"},{"line_number":283,"context_line":"  other words, the octavia VMs should be a black box from the users\u0027"},{"line_number":284,"context_line":"  perspective."},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"* Octavia VMs will be powered using haproxy 1.5 initially. We may decide to use"}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_f825f1bf","line":283,"in_reply_to":"baada198_67931500","updated":"2014-08-12 18:17:49.000000000","message":"Again, Octavia VMs are not on the user tenant account.","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":6437,"name":"Susanne Balle","email":"sleipnir012@gmail.com","username":"susanne-balle"},"change_message_id":"0481f2042ce24f787aade12c1aea3da4db367ed7","unresolved":false,"context_lines":[{"line_number":283,"context_line":"  other words, the octavia VMs should be a black box from the users\u0027"},{"line_number":284,"context_line":"  perspective."},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"* Octavia VMs will be powered using haproxy 1.5 initially. We may decide to use"},{"line_number":287,"context_line":"  other software (especially for SSL termination) later on."},{"line_number":288,"context_line":""},{"line_number":289,"context_line":"* The \"glue scripts\" which communicate with the controller should be as"}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_078259a4","line":286,"updated":"2014-08-12 10:36:30.000000000","message":"The reason for choosing haproxy 1.5 is because it support ssl termination and earlier packages do not. Right?","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"165b60c63f3ba608b4afbbaf5d2e5b6b39942798","unresolved":false,"context_lines":[{"line_number":283,"context_line":"  other words, the octavia VMs should be a black box from the users\u0027"},{"line_number":284,"context_line":"  perspective."},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"* Octavia VMs will be powered using haproxy 1.5 initially. We may decide to use"},{"line_number":287,"context_line":"  other software (especially for SSL termination) later on."},{"line_number":288,"context_line":""},{"line_number":289,"context_line":"* The \"glue scripts\" which communicate with the controller should be as"}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_1812a564","line":286,"in_reply_to":"baada198_078259a4","updated":"2014-08-12 18:17:49.000000000","message":"Correct. If we went with haproxy 1.4, we would need stunnel or some other TLS session terminator in order to support TLS.","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":10273,"name":"Adam Harwell","email":"flux.adam@gmail.com","username":"rm_you"},"change_message_id":"e634a0749a9ffb1d00726185c9ef9520f5c60ca7","unresolved":false,"context_lines":[{"line_number":283,"context_line":"  other words, the octavia VMs should be a black box from the users\u0027"},{"line_number":284,"context_line":"  perspective."},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"* Octavia VMs will be powered using haproxy 1.5 initially. We may decide to use"},{"line_number":287,"context_line":"  other software (especially for SSL termination) later on."},{"line_number":288,"context_line":""},{"line_number":289,"context_line":"* The \"glue scripts\" which communicate with the controller should be as"}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_78e721ac","line":286,"in_reply_to":"baada198_078259a4","updated":"2014-08-12 18:17:58.000000000","message":"Yes, HAProxy 1.5 includes native SSL termination support, though we haven\u0027t yet fully evaluated its effectiveness (as far as I am aware). Is it still possible we might want to use an alternative approach, or are we 100% set on HAP 1.5 handling it?","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"956fb4a8bff94bf66ece6240b52ac904f9afa7e6","unresolved":false,"context_lines":[{"line_number":283,"context_line":"  other words, the octavia VMs should be a black box from the users\u0027"},{"line_number":284,"context_line":"  perspective."},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"* Octavia VMs will be powered using haproxy 1.5 initially. We may decide to use"},{"line_number":287,"context_line":"  other software (especially for SSL termination) later on."},{"line_number":288,"context_line":""},{"line_number":289,"context_line":"* The \"glue scripts\" which communicate with the controller should be as"}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_fbba4bb9","line":286,"in_reply_to":"baada198_78e721ac","updated":"2014-08-12 18:31:23.000000000","message":"I\u0027m OK with using stunnel here with haproxy (version 1.4 or 1.5-- doesn\u0027t matter to me.) But if haproxy 1.5 performs well enough, this reduces one level of complexity in managing Octavia VMs.","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":6437,"name":"Susanne Balle","email":"sleipnir012@gmail.com","username":"susanne-balle"},"change_message_id":"0481f2042ce24f787aade12c1aea3da4db367ed7","unresolved":false,"context_lines":[{"line_number":299,"context_line":"* Connection logs, and other things anticipated to generate a potential large"},{"line_number":300,"context_line":"  amount of data should be communicated by the octavia VM directly to which"},{"line_number":301,"context_line":"  ever service is going to consume that data. (for example, if logs are being"},{"line_number":302,"context_line":"  shunted off to swift on a nightly basis, the octavia VM should handle this"},{"line_number":303,"context_line":"  directly and not go through the controller.)"},{"line_number":304,"context_line":""},{"line_number":305,"context_line":"INTERNAL HEALTH MONITORS"}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_67615510","line":302,"updated":"2014-08-12 10:36:30.000000000","message":"or a centralized logging service e.g. logstach, etc...","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"165b60c63f3ba608b4afbbaf5d2e5b6b39942798","unresolved":false,"context_lines":[{"line_number":299,"context_line":"* Connection logs, and other things anticipated to generate a potential large"},{"line_number":300,"context_line":"  amount of data should be communicated by the octavia VM directly to which"},{"line_number":301,"context_line":"  ever service is going to consume that data. (for example, if logs are being"},{"line_number":302,"context_line":"  shunted off to swift on a nightly basis, the octavia VM should handle this"},{"line_number":303,"context_line":"  directly and not go through the controller.)"},{"line_number":304,"context_line":""},{"line_number":305,"context_line":"INTERNAL HEALTH MONITORS"}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_fb132b57","line":302,"in_reply_to":"baada198_67615510","updated":"2014-08-12 18:17:49.000000000","message":"The \u0027logging\u0027 functionality has yet to be fleshed out because nobody has produced any real requirements for it yet. It\u0027s mentioned here as an example of something, when it\u0027s eventually implemented, that Octavia VMs should handle directly instead of relaying through the controller.","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":6437,"name":"Susanne Balle","email":"sleipnir012@gmail.com","username":"susanne-balle"},"change_message_id":"0481f2042ce24f787aade12c1aea3da4db367ed7","unresolved":false,"context_lines":[{"line_number":348,"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"},{"line_number":349,"context_line":"Supported Octavia VM Virtual Appliance Topologies"},{"line_number":350,"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"},{"line_number":351,"context_line":"Initially, I propose we support two topologies with version 0.5 of Octavia:"},{"line_number":352,"context_line":""},{"line_number":353,"context_line":"Option 1: \"Single active node + spares pool\""},{"line_number":354,"context_line":"--------------------------------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_023a47c3","line":351,"updated":"2014-08-12 10:36:30.000000000","message":"Given what we learned with juno do we expect to be able to do 2 topologies for Kilo. Wouldn\u0027t it be better to focus on one and make sure we get it done in time for the kilo release?","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"165b60c63f3ba608b4afbbaf5d2e5b6b39942798","unresolved":false,"context_lines":[{"line_number":348,"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"},{"line_number":349,"context_line":"Supported Octavia VM Virtual Appliance Topologies"},{"line_number":350,"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"},{"line_number":351,"context_line":"Initially, I propose we support two topologies with version 0.5 of Octavia:"},{"line_number":352,"context_line":""},{"line_number":353,"context_line":"Option 1: \"Single active node + spares pool\""},{"line_number":354,"context_line":"--------------------------------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_5b6897bc","line":351,"in_reply_to":"baada198_023a47c3","updated":"2014-08-12 18:17:49.000000000","message":"Not if we want to maintain support of all the operators involved in developing this.\n\nBlue Box can\u0027t use this product without having \"true active / standby.\" And I understand that HP can\u0027t use this product without \"single active node + spares pool.\"","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":10273,"name":"Adam Harwell","email":"flux.adam@gmail.com","username":"rm_you"},"change_message_id":"e634a0749a9ffb1d00726185c9ef9520f5c60ca7","unresolved":false,"context_lines":[{"line_number":416,"context_line":"relenquish all the vip_addresses it has, and the standby needs to take them"},{"line_number":417,"context_line":"over *and* start up haproxy services. This is OK if a given octavia"},{"line_number":418,"context_line":"VM only has a few load balancers, but can lead to several minutes\u0027 down-time"},{"line_number":419,"context_line":"during a graceful failover if there are a dozen or more load balancers on the"},{"line_number":420,"context_line":"active/standby octavia VM pair. It\u0027s also more risky: The standby node might"},{"line_number":421,"context_line":"not be able to start up all the haproxy services during such a"},{"line_number":422,"context_line":"failover. What\u0027s more, most types of VRRP-like services which handle floating"}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_5b03370c","line":419,"updated":"2014-08-12 18:17:58.000000000","message":"I was under the impression that our plan was always: 1 VM -\u003e 1 HAProxy LB\n\nAre we actually considering having multiple LBs on one VM? Or when you say \"Octavia VM\", do you not mean the HAProxy instances?","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"956fb4a8bff94bf66ece6240b52ac904f9afa7e6","unresolved":false,"context_lines":[{"line_number":416,"context_line":"relenquish all the vip_addresses it has, and the standby needs to take them"},{"line_number":417,"context_line":"over *and* start up haproxy services. This is OK if a given octavia"},{"line_number":418,"context_line":"VM only has a few load balancers, but can lead to several minutes\u0027 down-time"},{"line_number":419,"context_line":"during a graceful failover if there are a dozen or more load balancers on the"},{"line_number":420,"context_line":"active/standby octavia VM pair. It\u0027s also more risky: The standby node might"},{"line_number":421,"context_line":"not be able to start up all the haproxy services during such a"},{"line_number":422,"context_line":"failover. What\u0027s more, most types of VRRP-like services which handle floating"}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_1be8df7d","line":419,"in_reply_to":"baada198_5b03370c","updated":"2014-08-12 18:31:23.000000000","message":"Yes, I am talking about having multiple LBs (and their attendant listeners, etc.) on a single Octavia VM pair. This is actually expressed in the colocation / apolocation design which was discussed earlier this year (but not yet implemented).\n\nPart of the reason for this is around being efficient with hardware: It\u0027s actually quite common for many load balancing services to need relatively few resources, so from an operator perspective it makes sense to combine these on fewer VMs.\n\nNote that this is also similar to how other commercial load balancer products operate: It\u0027s common to have the ability to have many tenant load balancing services deployed on the same physical hardware.","commit_id":"2663327f3df31afba0157c8fe9a754ef6dfa7747"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"780094b882e23e014e61f0fab207bc91350a3a3e","unresolved":false,"context_lines":[{"line_number":23,"context_line":"USER API HANDLER"},{"line_number":24,"context_line":"----------------"},{"line_number":25,"context_line":"This is the front-end that users (and user GUIs or what have you) talk to to"},{"line_number":26,"context_line":"manipulate load balancing services."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"**Notes:**"},{"line_number":29,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_4a6d1567","line":26,"updated":"2014-08-12 23:54:05.000000000","message":"I was under the assumption that user\u0027s would use the Neutron LBaaS v2.0 API to talk to us. So I am not sure the purpose of this component - maybe we need to find a better name/description to make clear what the difference is (I talked in the irc with rm_work and we think it might be good for future use/life insurance if LBaaS v2 doesn\u0027t hit)","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"aaa6c568dd6af68952c9716ec3c8968beeefe803","unresolved":false,"context_lines":[{"line_number":23,"context_line":"USER API HANDLER"},{"line_number":24,"context_line":"----------------"},{"line_number":25,"context_line":"This is the front-end that users (and user GUIs or what have you) talk to to"},{"line_number":26,"context_line":"manipulate load balancing services."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"**Notes:**"},{"line_number":29,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_019bd7c8","line":26,"in_reply_to":"baada198_4a6d1567","updated":"2014-08-13 19:08:02.000000000","message":"Yes, that\u0027s why it\u0027s under \"LBaaS Components\" which (in the diagram) is under Neutron\u0027s purview.\n\nHaving said this--  yes, given recent developments in Neutron (and the neutron-incubator proposal), we may simply want to have Octavia have its own user-facing API, and then the Neutron LBaaS driver simply becomes a thin \"translation\" layer between Neutron LBaaS and Octavia.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":10750,"name":"Jorge Miramontes","email":"jorge.miramontes@rackspace.com","username":"jorgem"},"change_message_id":"9f5105f075ea334dca5b8422b1ea5da5f3e9d83e","unresolved":false,"context_lines":[{"line_number":66,"context_line":"evolve and increase in cleanly-consumable functionality."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"DRIVER"},{"line_number":69,"context_line":"------"},{"line_number":70,"context_line":"This is the part of the load balancing service that actually interfaces between"},{"line_number":71,"context_line":"the (sanitized) user and operator configuration and the back-end load balancing"},{"line_number":72,"context_line":"appliances or other \"service providing entity.\""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ab29df4_3dccb735","line":69,"updated":"2014-08-13 19:56:42.000000000","message":"Where is \"Driver\" in the diagram? Is it the Octavia box?","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"777039644a60e6ef59b8cc2dd466a48de31bfed8","unresolved":false,"context_lines":[{"line_number":66,"context_line":"evolve and increase in cleanly-consumable functionality."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"DRIVER"},{"line_number":69,"context_line":"------"},{"line_number":70,"context_line":"This is the part of the load balancing service that actually interfaces between"},{"line_number":71,"context_line":"the (sanitized) user and operator configuration and the back-end load balancing"},{"line_number":72,"context_line":"appliances or other \"service providing entity.\""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7ac7a964_8572cce3","line":69,"in_reply_to":"9ab29df4_3dccb735","updated":"2014-08-14 00:23:15.000000000","message":"It\u0027s inside the \u0027Neutron LBaaS\u0027 box on the left side.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"780094b882e23e014e61f0fab207bc91350a3a3e","unresolved":false,"context_lines":[{"line_number":80,"context_line":"  configuration) which is used by the driver to define implementation"},{"line_number":81,"context_line":"  specifics (for example, HA configuration and other details)."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"* Driver will be loaded by the daemon that does the user API and operator API."},{"line_number":84,"context_line":"  It is not, in and of itself, its own daemon, though a given vendor\u0027s back-end"},{"line_number":85,"context_line":"  may contain its own daemons or other services that the driver interfaces"},{"line_number":86,"context_line":"  with."}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_aa2f91f4","line":83,"updated":"2014-08-12 23:54:05.000000000","message":"Isn\u0027t that duplicating Neutron LBaaS?","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"aaa6c568dd6af68952c9716ec3c8968beeefe803","unresolved":false,"context_lines":[{"line_number":80,"context_line":"  configuration) which is used by the driver to define implementation"},{"line_number":81,"context_line":"  specifics (for example, HA configuration and other details)."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"* Driver will be loaded by the daemon that does the user API and operator API."},{"line_number":84,"context_line":"  It is not, in and of itself, its own daemon, though a given vendor\u0027s back-end"},{"line_number":85,"context_line":"  may contain its own daemons or other services that the driver interfaces"},{"line_number":86,"context_line":"  with."}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_a1b30b4d","line":83,"in_reply_to":"baada198_aa2f91f4","updated":"2014-08-13 19:08:02.000000000","message":"This section is actually describing Neutron LBaaS as we understand it.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"780094b882e23e014e61f0fab207bc91350a3a3e","unresolved":false,"context_lines":[{"line_number":91,"context_line":"  components which need not be stateless."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"* It is also possible for multiple instances of the driver will talk to the"},{"line_number":94,"context_line":"  same Octavia VM at the same time. Emphasis on the idempotency of the update"},{"line_number":95,"context_line":"  algorithms used should help minimize the issues this can potentially cause."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"NETWORK DRIVER"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_ca0be57a","line":94,"updated":"2014-08-12 23:54:05.000000000","message":"didn\u0027t we say the Octavia VM has a synchronous API? So why do we allow multiple connections at the same time? Should we limit it to 1 to limit trouble?","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"74b14ca8df4a5e0b0f93c8e20d7628e64fb3bd78","unresolved":false,"context_lines":[{"line_number":91,"context_line":"  components which need not be stateless."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"* It is also possible for multiple instances of the driver will talk to the"},{"line_number":94,"context_line":"  same Octavia VM at the same time. Emphasis on the idempotency of the update"},{"line_number":95,"context_line":"  algorithms used should help minimize the issues this can potentially cause."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"NETWORK DRIVER"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7ac7a964_29ea5275","line":94,"in_reply_to":"7ac7a964_3c1d3574","updated":"2014-08-16 04:25:22.000000000","message":"We do this transitional state lock with our current product and there have been occasions where it does get stuck in one of those states.  In which case, it comes down to support or ops to get it out of that state, and then we figure out why and fix the bug.\n\nAn option is to have some timeout on a transitional status in which it will go back to ACTIVE after some time.  Could even a DEGRADED state since something wrong did happen.  But then once its fixed that status would have to be changed back to ACTIVE, which will most likely be a manual fix so probably not on the DEGRADED status.\n\nIn a nearly perfect world, getting stuck in these states will happen at first but with bug fixes to fix these the frequency should get less and less.  Unfortunately we don\u0027t live in that near perfect world and I can\u0027t guarantee that will be the case.  So as a fail safe I\u0027d say a timeout on the transitional status after which the status goes to ACTIVE, unless it causes an operational issue in which it should go to ERROR.\n\nWhich reminds me, we need an ERROR status.\n\nI\u0027ll reply to your status on the ML since this comment is already too long.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"433798bd93d52bcaec68b518c1823c5776133480","unresolved":false,"context_lines":[{"line_number":91,"context_line":"  components which need not be stateless."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"* It is also possible for multiple instances of the driver will talk to the"},{"line_number":94,"context_line":"  same Octavia VM at the same time. Emphasis on the idempotency of the update"},{"line_number":95,"context_line":"  algorithms used should help minimize the issues this can potentially cause."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"NETWORK DRIVER"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7ac7a964_3c1d3574","line":94,"in_reply_to":"7ac7a964_f4177ba1","updated":"2014-08-16 01:22:43.000000000","message":"I\u0027m generally in agreement that any resource pending a change should not allow for additional changes to get queued up. That\u0027s a can of worms we probably don\u0027t need to worry about because usage of the user API is going to be pretty low per tenant.\n\nI responded to your ideas regarding transitional (provisional) states on the mailing list, but will copy some of that here for posterity:\n\n---\nIf we\u0027re using a separate haproxy instance per listener, I think that probably both the loadbalancer and listener objects have different needs here that are appropriate. Specifically, this is what I\u0027m thinking, regarding the statuses and what they mean:\n\nLoadbalancer:\n  PENDING_CREATE: VIP address is being assigned (reserved, or put on a port) in Neutron, or is being allocated on Octavia VMs.\n  ACTIVE: VIP address is up and running on at least one Octavia VM (ex. a ping check would succeed, assuming no blocking firewall rules)\n  PENDING_DELETE: VIP address is being removed from Octavia VM(s) and reservation in Neutron released\n (Is there any need for a PENDING_UPDATE status for a loadbalancer? Shouldn\u0027t the vip_address be immutable after it\u0027s created?)\n\nListener:\n PENDING_CREATE: A new Listener haproxy configuration is being created on Octavia VM(s)\n PENDING_UPDATE: An existing Listener haproxy configuration is being updated on Octavia VM(s)\n PENDING_DELETE: Listener haproxy configuration is about to be deleted off associated Octavia VM(s)\n ACTIVE: haproxy Listener is up and running (ex. responds to TCP SYN check).\n---\n\nSo, effectively this would cascade down: If a Loadbalancer is in a transitional state, none of its Listeners (and related sub-objects) should be allowed to change.\n\nAaanyway-- the one worry I have with using transitional states for locking is that it\u0027s possible for some resources to get stuck in a transitional state (due to... well... things that happen in a real operational environment), and so if we\u0027re going to do this, we need to also think carefully about how to get objects in a transitional state for too long (ie. stuck) out of this state-- and hopefully in a way that doesn\u0027t require the operator or the operator\u0027s support staff to manually intervene. Do y\u0027all have suggestions for that?","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"597d3ac7e86667b3d38e6b1fa239fc2f22abf2b0","unresolved":false,"context_lines":[{"line_number":91,"context_line":"  components which need not be stateless."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"* It is also possible for multiple instances of the driver will talk to the"},{"line_number":94,"context_line":"  same Octavia VM at the same time. Emphasis on the idempotency of the update"},{"line_number":95,"context_line":"  algorithms used should help minimize the issues this can potentially cause."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"NETWORK DRIVER"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7ac7a964_f4177ba1","line":94,"in_reply_to":"baada198_01d03751","updated":"2014-08-15 04:48:48.000000000","message":"Regarding sync vs async: I\u0027m not sure synchronous would be good for us because we are spinning up Nova VMs and they can take a good while depending on the flavor.\n\nRegarding connection locking:\nI responded to this in the v1.0 spec.  I\u0027ll copy and paste that here:\n\nI like what we\u0027ve done with our current API in that we do not allow load balancers in transitional states to be modified. PENDING_CREATE, PENDING_UPDATE, PENDING_DELETE. If an entity is in that state it, it\u0027s just not allowed to be modified until it becomes ACTIVE.\n\nI don\u0027t foresee a load balancing API to be a high request volume API. So I don\u0027t think this kind of lock would be an issue. It simplifies the workflow too, so the code can expect to only be dealing with one modification to a loadbalancer at one time instead of dealing with the concurrency problem of two threads/processes pulling off the queue and deciding which one should be done first.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"aaa6c568dd6af68952c9716ec3c8968beeefe803","unresolved":false,"context_lines":[{"line_number":91,"context_line":"  components which need not be stateless."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"* It is also possible for multiple instances of the driver will talk to the"},{"line_number":94,"context_line":"  same Octavia VM at the same time. Emphasis on the idempotency of the update"},{"line_number":95,"context_line":"  algorithms used should help minimize the issues this can potentially cause."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"NETWORK DRIVER"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_01d03751","line":94,"in_reply_to":"baada198_ca0be57a","updated":"2014-08-13 19:08:02.000000000","message":"I\u0027m not sure we ever agreed it would be a synchronous API. In fact, in a topology involving a zero-size spares pool, I\u0027m not sure it can be.\n\nAlso, what method would you recommend we use to ensure 1 connection at a time, given multiple clients can connect to the API at random intervals? (Some form of locking? What specifically?)","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"780094b882e23e014e61f0fab207bc91350a3a3e","unresolved":false,"context_lines":[{"line_number":111,"context_line":""},{"line_number":112,"context_line":"* This is a daemon or \"unofficial extension\", presumably living on a Neutron"},{"line_number":113,"context_line":"  network node which should have \"back door\" access to all things Neutron and"},{"line_number":114,"context_line":"  exposes an API that should only be used by Octavia."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"* Exactly what API will be provided by this driver will be defined as we"},{"line_number":117,"context_line":"  continue to build out the reference implementation for Octavia."}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_4aa19539","line":114,"updated":"2014-08-12 23:54:05.000000000","message":"1) Since we might need changes to how nova allocates ports it is conceivable that this is more complex than some daemon running on some networking host.\n2) Some things could be done at the API level but not really from an outside component (see the wafflehaus middleware concept - https://github.com/roaet/wafflehaus) - we should entertain that as a less intrusive option, too\n3) I agree that there might be hacks needed but with the new incubator model we could make \"official\" (incubated) extensions \n\nAll in all I feel we should explore/entertain some less hacky options first :-)","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"aaa6c568dd6af68952c9716ec3c8968beeefe803","unresolved":false,"context_lines":[{"line_number":111,"context_line":""},{"line_number":112,"context_line":"* This is a daemon or \"unofficial extension\", presumably living on a Neutron"},{"line_number":113,"context_line":"  network node which should have \"back door\" access to all things Neutron and"},{"line_number":114,"context_line":"  exposes an API that should only be used by Octavia."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"* Exactly what API will be provided by this driver will be defined as we"},{"line_number":117,"context_line":"  continue to build out the reference implementation for Octavia."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ab29df4_3704d814","line":114,"in_reply_to":"baada198_4aa19539","updated":"2014-08-13 19:08:02.000000000","message":"I do not for a second trust that anything that ends up in the incubator will ever see \"official\" supported status.\n\nThe point behind the network driver here is to keep separation from Octavia proper so that Octavia can be written with \"clean\" interfaces. I\u0027ve specifically avoided defining a lot of the specifics as to what it does because we don\u0027t yet know everything we\u0027ll need it to do (ie. see the next bullet point).\n\nI\u0027ve never actually used wafflehaus, so I\u0027m not sure whether it actually applies to what we\u0027ll need the network driver to do. Since we don\u0027t yet completely know what we\u0027ll need the network driver to do, it\u0027s going to be hard to evaluate whether wafflehaus meets these (undefined) criteria. :/\n\nIn a nutshell, the network driver is supposed to provide a layer of abstraction for Octavia to use to manipulate network resources. Whether the network driver then plugs into Neutron, nova-networking, or some vendor\u0027s proprietary SDN solution is immaterial. (We will, of course, be developing the driver to work with Neutron first.)","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"780094b882e23e014e61f0fab207bc91350a3a3e","unresolved":false,"context_lines":[{"line_number":127,"context_line":"Everything from here down are entities that have to do with the Octavia driver"},{"line_number":128,"context_line":"and load balancing system. Other vendor drivers are unlikely to have the same"},{"line_number":129,"context_line":"components and internal structure. It is planned that Octavia will become the"},{"line_number":130,"context_line":"new reference implementation for LBaaS, though it of course doesn\u0027t need to be"},{"line_number":131,"context_line":"the only one. (In fact, a given operator should be able to use multiple vendors"},{"line_number":132,"context_line":"with potentially multiple drivers and multiple driver configurations through"},{"line_number":133,"context_line":"the Neutron Flavor framework.)"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_6a449976","line":130,"updated":"2014-08-12 23:54:05.000000000","message":"s/LBaaS/Neutron LBaaS/g","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"aaa6c568dd6af68952c9716ec3c8968beeefe803","unresolved":false,"context_lines":[{"line_number":127,"context_line":"Everything from here down are entities that have to do with the Octavia driver"},{"line_number":128,"context_line":"and load balancing system. Other vendor drivers are unlikely to have the same"},{"line_number":129,"context_line":"components and internal structure. It is planned that Octavia will become the"},{"line_number":130,"context_line":"new reference implementation for LBaaS, though it of course doesn\u0027t need to be"},{"line_number":131,"context_line":"the only one. (In fact, a given operator should be able to use multiple vendors"},{"line_number":132,"context_line":"with potentially multiple drivers and multiple driver configurations through"},{"line_number":133,"context_line":"the Neutron Flavor framework.)"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ab29df4_1726f4ba","line":130,"in_reply_to":"baada198_6a449976","updated":"2014-08-13 19:08:02.000000000","message":"Given recent developments in Neutron, I\u0027m more inclined to say:  s/LBaaS/OpenStack LBaaS/","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"780094b882e23e014e61f0fab207bc91350a3a3e","unresolved":false,"context_lines":[{"line_number":151,"context_line":""},{"line_number":152,"context_line":"* This interface is stateless. State should be managd by the controller, and"},{"line_number":153,"context_line":"  stored in a highly available database."},{"line_number":154,"context_line":""},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"CONTROLLER"},{"line_number":157,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_6a12d965","line":154,"updated":"2014-08-12 23:54:05.000000000","message":"We should define the user management a bit. Our support/NOC for instance requires like three level of roles. From people who only have read access, to once who can change, and others who can delete/create","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"aaa6c568dd6af68952c9716ec3c8968beeefe803","unresolved":false,"context_lines":[{"line_number":151,"context_line":""},{"line_number":152,"context_line":"* This interface is stateless. State should be managd by the controller, and"},{"line_number":153,"context_line":"  stored in a highly available database."},{"line_number":154,"context_line":""},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"CONTROLLER"},{"line_number":157,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ab29df4_37d5b843","line":154,"in_reply_to":"baada198_6a12d965","updated":"2014-08-13 19:08:02.000000000","message":"Yes, so far we\u0027ve avoided gathering operator API requirements because it\u0027s been difficult enough to achieve consensus on the user API requirements. I agree that this needs to happen, but are you saying we need to do this before we can approve the component layout for Octavia?\n\nKeep in mind that this document is only trying to set topology, and only \"sufficiently defining\" the roles each component will have. We\u0027re avoiding too many specifics in this document because they\u0027ll be defined later on when we actually define APIs.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"780094b882e23e014e61f0fab207bc91350a3a3e","unresolved":false,"context_lines":[{"line_number":160,"context_line":"driver."},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"It should be noted that in later releases of Octavia, the controller functions"},{"line_number":163,"context_line":"will be split across several components. At this stage we are less concerned"},{"line_number":164,"context_line":"with how this internal communcation will happen, and are most concerned with"},{"line_number":165,"context_line":"ensuring communication with Octavia VMs, the LBaaS driver, and the Network"},{"line_number":166,"context_line":"driver are all made as perfect as possible."}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_4db52f18","line":163,"updated":"2014-08-12 23:54:05.000000000","message":"I think that simplifying by just putting everything in one daemon will make it difficult to split tasks\n between people (I am not very fond of watching the rebasing hell brandon lives in)\n\u003csbalukoff\u003e xgerman: There\u0027s no reason we couldn\u0027t make the controller multiple daemons, really...  but doing so at this point is less important than getting its external interfaces correct.\n\u003csbalukoff\u003e (Interfaces to Neutron, Neutron LBaaS and Octavia VMs)\n\u003cxgerman\u003e understood. I just don\u0027t want to close the door on that before we have a better idea how to split work\n\u003csbalukoff\u003e Yep!\n\u003c-- sbfox has quit (Quit: Leaving.)\n\u003csbalukoff\u003e I\u0027m actually in favor of making the controller several daemons, but it does add extra complexity to the project up front...  0.5 is sort of a proof of concept of \"does this model using Octavia VMs work?\"\n It\u0027s not the scalable version we all need.\n\u003csbalukoff\u003e xgerman: In any case, please add those comments in gerrit, too-- so they\u0027re perserved (sort of) for posterity?\n\u003cxgerman\u003e of course :-)\n yeah, I also like the proof of concept idea but I found it easier to split work when everybody gets their own component\n\u003csbalukoff\u003e Agreed.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"597d3ac7e86667b3d38e6b1fa239fc2f22abf2b0","unresolved":false,"context_lines":[{"line_number":160,"context_line":"driver."},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"It should be noted that in later releases of Octavia, the controller functions"},{"line_number":163,"context_line":"will be split across several components. At this stage we are less concerned"},{"line_number":164,"context_line":"with how this internal communcation will happen, and are most concerned with"},{"line_number":165,"context_line":"ensuring communication with Octavia VMs, the LBaaS driver, and the Network"},{"line_number":166,"context_line":"driver are all made as perfect as possible."}],"source_content_type":"text/x-rst","patch_set":2,"id":"7ac7a964_d4951fe5","line":163,"in_reply_to":"9ab29df4_57ddcc41","updated":"2014-08-15 04:48:48.000000000","message":"I\u0027m indifferent towards this.  If we keep it as one for now it should be written with separation of concerns any way.  So whatever the majority wants is fine by me.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"be19972e9f556a5218bb852953bb048d8050227c","unresolved":false,"context_lines":[{"line_number":160,"context_line":"driver."},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"It should be noted that in later releases of Octavia, the controller functions"},{"line_number":163,"context_line":"will be split across several components. At this stage we are less concerned"},{"line_number":164,"context_line":"with how this internal communcation will happen, and are most concerned with"},{"line_number":165,"context_line":"ensuring communication with Octavia VMs, the LBaaS driver, and the Network"},{"line_number":166,"context_line":"driver are all made as perfect as possible."}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_d00b927a","line":163,"in_reply_to":"baada198_4db52f18","updated":"2014-08-13 00:25:19.000000000","message":"I agree with German here.  We know we are going to have these split out in the long run.  It seems simpler to start that way.  I worry about python threading issues with all of these roles in one daemon.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"aaa6c568dd6af68952c9716ec3c8968beeefe803","unresolved":false,"context_lines":[{"line_number":160,"context_line":"driver."},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"It should be noted that in later releases of Octavia, the controller functions"},{"line_number":163,"context_line":"will be split across several components. At this stage we are less concerned"},{"line_number":164,"context_line":"with how this internal communcation will happen, and are most concerned with"},{"line_number":165,"context_line":"ensuring communication with Octavia VMs, the LBaaS driver, and the Network"},{"line_number":166,"context_line":"driver are all made as perfect as possible."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ab29df4_57ddcc41","line":163,"in_reply_to":"baada198_d00b927a","updated":"2014-08-13 19:08:02.000000000","message":"I\u0027m OK with this if other people are. I\u0027ve heard from some that having separate daemons and defining interfaces between them was too much complication for v0.5, where the main effort is to get APIs between control and Octavia VMs, and between the user and operator APIs and control are the main emphasis.\n\nBut... I\u0027m happy to change this design of \"control\" to be closer to how things will look in v1.0 if the majority think we should.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"597d3ac7e86667b3d38e6b1fa239fc2f22abf2b0","unresolved":false,"context_lines":[{"line_number":160,"context_line":"driver."},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"It should be noted that in later releases of Octavia, the controller functions"},{"line_number":163,"context_line":"will be split across several components. At this stage we are less concerned"},{"line_number":164,"context_line":"with how this internal communcation will happen, and are most concerned with"},{"line_number":165,"context_line":"ensuring communication with Octavia VMs, the LBaaS driver, and the Network"},{"line_number":166,"context_line":"driver are all made as perfect as possible."}],"source_content_type":"text/x-rst","patch_set":2,"id":"7ac7a964_94fc8740","line":163,"in_reply_to":"baada198_d00b927a","updated":"2014-08-15 04:48:48.000000000","message":"Python and threading issues? I don\u0027t believe Python would have any threading issues, it does everything we need perfectly!  It practically writes itself. oh wait...GIL","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":10750,"name":"Jorge Miramontes","email":"jorge.miramontes@rackspace.com","username":"jorgem"},"change_message_id":"9f5105f075ea334dca5b8422b1ea5da5f3e9d83e","unresolved":false,"context_lines":[{"line_number":178,"context_line":"* Interfacing with network driver to plumb additional interfaces on the octavia"},{"line_number":179,"context_line":"  VMs as necessary."},{"line_number":180,"context_line":""},{"line_number":181,"context_line":"* Monitoring the health of all octavia VMs."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"* Receiving and routing certain kinds of notifications originating on the"},{"line_number":184,"context_line":"  octavia VMs (ex. \"member down\")"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ab29df4_a0f8a0c5","line":181,"updated":"2014-08-13 19:56:42.000000000","message":"I\u0027m a little concerned with the scalability of this. Monitoring needs to scale with a component that also scales the way instances will.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"777039644a60e6ef59b8cc2dd466a48de31bfed8","unresolved":false,"context_lines":[{"line_number":178,"context_line":"* Interfacing with network driver to plumb additional interfaces on the octavia"},{"line_number":179,"context_line":"  VMs as necessary."},{"line_number":180,"context_line":""},{"line_number":181,"context_line":"* Monitoring the health of all octavia VMs."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"* Receiving and routing certain kinds of notifications originating on the"},{"line_number":184,"context_line":"  octavia VMs (ex. \"member down\")"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7ac7a964_0555dc1c","line":181,"in_reply_to":"9ab29df4_a0f8a0c5","updated":"2014-08-14 00:23:15.000000000","message":"That\u0027s true-- but again, the 0.5 release is not concerned with scale at the control layer.\n\nIn 1.0 and beyond, this should scale with the number of Octavia VMs, since the number of controllers also scales with the number of Octavia VMs.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":10750,"name":"Jorge Miramontes","email":"jorge.miramontes@rackspace.com","username":"jorgem"},"change_message_id":"9f5105f075ea334dca5b8422b1ea5da5f3e9d83e","unresolved":false,"context_lines":[{"line_number":184,"context_line":"  octavia VMs (ex. \"member down\")"},{"line_number":185,"context_line":""},{"line_number":186,"context_line":"* This is a stateful service, and should keep its state in a central, highly"},{"line_number":187,"context_line":"  available database of some sort."},{"line_number":188,"context_line":""},{"line_number":189,"context_line":"* Respecting colocation / apolocation requirements of loadbalancers as set"},{"line_number":190,"context_line":"  forth by users."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ab29df4_20bad0e1","line":187,"updated":"2014-08-13 19:56:42.000000000","message":"Can you add a database component that is attached to the controller component please?","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"777039644a60e6ef59b8cc2dd466a48de31bfed8","unresolved":false,"context_lines":[{"line_number":184,"context_line":"  octavia VMs (ex. \"member down\")"},{"line_number":185,"context_line":""},{"line_number":186,"context_line":"* This is a stateful service, and should keep its state in a central, highly"},{"line_number":187,"context_line":"  available database of some sort."},{"line_number":188,"context_line":""},{"line_number":189,"context_line":"* Respecting colocation / apolocation requirements of loadbalancers as set"},{"line_number":190,"context_line":"  forth by users."}],"source_content_type":"text/x-rst","patch_set":2,"id":"7ac7a964_e52e20a5","line":187,"in_reply_to":"9ab29df4_20bad0e1","updated":"2014-08-14 00:23:15.000000000","message":"Yep! I\u0027ll get that added with the next push.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"780094b882e23e014e61f0fab207bc91350a3a3e","unresolved":false,"context_lines":[{"line_number":187,"context_line":"  available database of some sort."},{"line_number":188,"context_line":""},{"line_number":189,"context_line":"* Respecting colocation / apolocation requirements of loadbalancers as set"},{"line_number":190,"context_line":"  forth by users."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"* Receiving notifications, statistics data and other short, regular messages"},{"line_number":193,"context_line":"  from octavia VMs and routing them to the appropriate entity."}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_0d69778d","line":190,"updated":"2014-08-12 23:54:05.000000000","message":"This is not very relevant for HP/RAX since our nova scheduling only takes Availability Zones (HP)/nothing else (RAX) into account","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"433798bd93d52bcaec68b518c1823c5776133480","unresolved":false,"context_lines":[{"line_number":187,"context_line":"  available database of some sort."},{"line_number":188,"context_line":""},{"line_number":189,"context_line":"* Respecting colocation / apolocation requirements of loadbalancers as set"},{"line_number":190,"context_line":"  forth by users."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"* Receiving notifications, statistics data and other short, regular messages"},{"line_number":193,"context_line":"  from octavia VMs and routing them to the appropriate entity."}],"source_content_type":"text/x-rst","patch_set":2,"id":"7ac7a964_dc07e11a","line":190,"in_reply_to":"7ac7a964_34a57353","updated":"2014-08-16 01:22:43.000000000","message":"Haha! You can credit Dustin for inventing that one. Apparently he knows (latin?) prefixes better than I.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"74b14ca8df4a5e0b0f93c8e20d7628e64fb3bd78","unresolved":false,"context_lines":[{"line_number":187,"context_line":"  available database of some sort."},{"line_number":188,"context_line":""},{"line_number":189,"context_line":"* Respecting colocation / apolocation requirements of loadbalancers as set"},{"line_number":190,"context_line":"  forth by users."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"* Receiving notifications, statistics data and other short, regular messages"},{"line_number":193,"context_line":"  from octavia VMs and routing them to the appropriate entity."}],"source_content_type":"text/x-rst","patch_set":2,"id":"7ac7a964_296fb2fe","line":190,"in_reply_to":"7ac7a964_dc07e11a","updated":"2014-08-16 04:25:22.000000000","message":"Hey if it becomes sanctioned by mirriam-webster, or even just wikipedia (he should make that page), that\u0027s a nice feather in his hat.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"597d3ac7e86667b3d38e6b1fa239fc2f22abf2b0","unresolved":false,"context_lines":[{"line_number":187,"context_line":"  available database of some sort."},{"line_number":188,"context_line":""},{"line_number":189,"context_line":"* Respecting colocation / apolocation requirements of loadbalancers as set"},{"line_number":190,"context_line":"  forth by users."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"* Receiving notifications, statistics data and other short, regular messages"},{"line_number":193,"context_line":"  from octavia VMs and routing them to the appropriate entity."}],"source_content_type":"text/x-rst","patch_set":2,"id":"7ac7a964_34a57353","line":190,"in_reply_to":"9ab29df4_77b9f0e8","updated":"2014-08-15 04:48:48.000000000","message":"I\u0027ve made compromises on accepting apolocation as a word!","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"aaa6c568dd6af68952c9716ec3c8968beeefe803","unresolved":false,"context_lines":[{"line_number":187,"context_line":"  available database of some sort."},{"line_number":188,"context_line":""},{"line_number":189,"context_line":"* Respecting colocation / apolocation requirements of loadbalancers as set"},{"line_number":190,"context_line":"  forth by users."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"* Receiving notifications, statistics data and other short, regular messages"},{"line_number":193,"context_line":"  from octavia VMs and routing them to the appropriate entity."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ab29df4_77b9f0e8","line":190,"in_reply_to":"baada198_0d69778d","updated":"2014-08-13 19:08:02.000000000","message":"That\u0027s fine. Also note that a single active node + standby pool topology is irrelevant to Blue Box\u0027s needs. We all make compromises to work together. ;)","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"780094b882e23e014e61f0fab207bc91350a3a3e","unresolved":false,"context_lines":[{"line_number":192,"context_line":"* Receiving notifications, statistics data and other short, regular messages"},{"line_number":193,"context_line":"  from octavia VMs and routing them to the appropriate entity."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"* Responding to requests from octavia VMs for configuration data."},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"* Responding to requests from the user API or operator API handler driver for"},{"line_number":198,"context_line":"  data about specific loadbalancers or sub-objects, their status, and"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_4dfa8fbb","line":195,"updated":"2014-08-12 23:54:05.000000000","message":"VM\u0027s shouldn\u0027t send requests? Would the controller not just configure them and if there is a change just reconfigure. If they loose their configuration they are likely dead/unhealthy and need to replaced...","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"aaa6c568dd6af68952c9716ec3c8968beeefe803","unresolved":false,"context_lines":[{"line_number":192,"context_line":"* Receiving notifications, statistics data and other short, regular messages"},{"line_number":193,"context_line":"  from octavia VMs and routing them to the appropriate entity."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"* Responding to requests from octavia VMs for configuration data."},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"* Responding to requests from the user API or operator API handler driver for"},{"line_number":198,"context_line":"  data about specific loadbalancers or sub-objects, their status, and"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ab29df4_f7a9807c","line":195,"in_reply_to":"baada198_4dfa8fbb","updated":"2014-08-13 19:08:02.000000000","message":"I think you\u0027re mis-interpreting what I\u0027m saying.\n\nFrom an extremely high level, I\u0027m thinking an exchange that looks like the following:\n\nController to Nova: \"Please spin up a new Octavia VM\"\n\nNew Octavia VM to Controller: \"Ok, I\u0027m here now, what should I do?\"\n\nController to new Octavia VM: \"Here\u0027s your configuration data. Go run it.\"","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"780094b882e23e014e61f0fab207bc91350a3a3e","unresolved":false,"context_lines":[{"line_number":242,"context_line":""},{"line_number":243,"context_line":"* As certain sensitive data (TLS private keys, for example) will be transmitted"},{"line_number":244,"context_line":"  over this communication infrastructure, all messages carrying a sensitive"},{"line_number":245,"context_line":"  payload should be done via encrypted and authenticated means. Further, we"},{"line_number":246,"context_line":"  recommend that messages to and from octavia VMs be signed regardless of the"},{"line_number":247,"context_line":"  sensitivity of their content."},{"line_number":248,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_8da027a6","line":245,"updated":"2014-08-12 23:54:05.000000000","message":"This should be configurable (encryption YES/NO) for debugging and users who are not security sensitive","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"aaa6c568dd6af68952c9716ec3c8968beeefe803","unresolved":false,"context_lines":[{"line_number":242,"context_line":""},{"line_number":243,"context_line":"* As certain sensitive data (TLS private keys, for example) will be transmitted"},{"line_number":244,"context_line":"  over this communication infrastructure, all messages carrying a sensitive"},{"line_number":245,"context_line":"  payload should be done via encrypted and authenticated means. Further, we"},{"line_number":246,"context_line":"  recommend that messages to and from octavia VMs be signed regardless of the"},{"line_number":247,"context_line":"  sensitivity of their content."},{"line_number":248,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ab29df4_b7d708bf","line":245,"in_reply_to":"baada198_8da027a6","updated":"2014-08-13 19:08:02.000000000","message":"I agree, but by default let\u0027s not encourage people to shoot themselves in the foot. :)  In other words, default should be \"encryption / authentication is enabled.\" I\u0027m thinking that we should generate copious log messages warning people when they\u0027re using an insecure setting here. Again, this touches directly the \"security is not an afterthought\" part of our constitution / hacking guidelines.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"780094b882e23e014e61f0fab207bc91350a3a3e","unresolved":false,"context_lines":[{"line_number":255,"context_line":"* Actually accomplishing the load balancing services for user-configured"},{"line_number":256,"context_line":"  loadbalancers using haproxy."},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"* Sending regular heartbeats (which should include some status information)."},{"line_number":259,"context_line":""},{"line_number":260,"context_line":"* Responding to specific requests from the controller for very basic"},{"line_number":261,"context_line":"  loadbalancer or sub-object status data, including statistics."}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_cd813ffc","line":258,"updated":"2014-08-12 23:54:05.000000000","message":"Should it be sending? There is something said to keep it simple in 0.5 and just respond to REST API healthcheck requests","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"aaa6c568dd6af68952c9716ec3c8968beeefe803","unresolved":false,"context_lines":[{"line_number":255,"context_line":"* Actually accomplishing the load balancing services for user-configured"},{"line_number":256,"context_line":"  loadbalancers using haproxy."},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"* Sending regular heartbeats (which should include some status information)."},{"line_number":259,"context_line":""},{"line_number":260,"context_line":"* Responding to specific requests from the controller for very basic"},{"line_number":261,"context_line":"  loadbalancer or sub-object status data, including statistics."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ab29df4_7772d0e6","line":258,"in_reply_to":"baada198_cd813ffc","updated":"2014-08-13 19:08:02.000000000","message":"This has to do with poll-based vs. push-based healthchecks. It turns out that poll-based checks entail more work on the part of the controller in any case, and also don\u0027t scale as well as push-based healthchecks.\n\nSo, I disagree with the implication that REST API healthchecks will be any simpler than push-based healthchecks.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"780094b882e23e014e61f0fab207bc91350a3a3e","unresolved":false,"context_lines":[{"line_number":260,"context_line":"* Responding to specific requests from the controller for very basic"},{"line_number":261,"context_line":"  loadbalancer or sub-object status data, including statistics."},{"line_number":262,"context_line":""},{"line_number":263,"context_line":"* Shipping listener logs to a swift data store, if configured."},{"line_number":264,"context_line":""},{"line_number":265,"context_line":"* Sending \"edge\" notifications (ie. status changes) to the controller when"},{"line_number":266,"context_line":"  members go up and down, when listeners go up and down, etc."}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_8db587d1","line":263,"updated":"2014-08-12 23:54:05.000000000","message":"This seems to be something I would leave off of .5. It\u0027s not clear to me how the VM would store the secret to log into Swift and this likely detracts from other features...\n\nAlso as I said earlier: Storing logs in Swift wasn\u0027t very useful for HP\u0027s customers and they were looking for  a more configurable scope into the traffic.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"aaa6c568dd6af68952c9716ec3c8968beeefe803","unresolved":false,"context_lines":[{"line_number":260,"context_line":"* Responding to specific requests from the controller for very basic"},{"line_number":261,"context_line":"  loadbalancer or sub-object status data, including statistics."},{"line_number":262,"context_line":""},{"line_number":263,"context_line":"* Shipping listener logs to a swift data store, if configured."},{"line_number":264,"context_line":""},{"line_number":265,"context_line":"* Sending \"edge\" notifications (ie. status changes) to the controller when"},{"line_number":266,"context_line":"  members go up and down, when listeners go up and down, etc."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ab29df4_d7055c15","line":263,"in_reply_to":"baada198_8db587d1","updated":"2014-08-13 19:08:02.000000000","message":"So, again, this has yet to be defined at all because nobody has yet presented requirements for this. It\u0027s mentioned here as an example of the kinds of things that will be handled by Octavia VMs directly instead of being relayed through the control layer.  I felt it was worthwhile to mention here to remove ambiguity as to where it should live the moment someone does come to us with requirements for shipping logs off the VM.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"780094b882e23e014e61f0fab207bc91350a3a3e","unresolved":false,"context_lines":[{"line_number":262,"context_line":""},{"line_number":263,"context_line":"* Shipping listener logs to a swift data store, if configured."},{"line_number":264,"context_line":""},{"line_number":265,"context_line":"* Sending \"edge\" notifications (ie. status changes) to the controller when"},{"line_number":266,"context_line":"  members go up and down, when listeners go up and down, etc."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"**Notes:**"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_8ddca719","line":265,"updated":"2014-08-12 23:54:05.000000000","message":"Again is sending the right approach fro 1.0. Just responding might be sufficient --","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"aaa6c568dd6af68952c9716ec3c8968beeefe803","unresolved":false,"context_lines":[{"line_number":262,"context_line":""},{"line_number":263,"context_line":"* Shipping listener logs to a swift data store, if configured."},{"line_number":264,"context_line":""},{"line_number":265,"context_line":"* Sending \"edge\" notifications (ie. status changes) to the controller when"},{"line_number":266,"context_line":"  members go up and down, when listeners go up and down, etc."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"**Notes:**"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ab29df4_fa19657a","line":265,"in_reply_to":"baada198_8ddca719","updated":"2014-08-13 19:08:02.000000000","message":"Again, \"I respectfully disagree that it\u0027s any simpler\"","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"780094b882e23e014e61f0fab207bc91350a3a3e","unresolved":false,"context_lines":[{"line_number":284,"context_line":"  other software (especially for TLS termination) later on."},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"* The \"glue scripts\" which communicate with the controller should be as"},{"line_number":287,"context_line":"  lightweight as possible: Intelligence about how to put together an haproxy"},{"line_number":288,"context_line":"  config, for example, should not live on the octavia VM. Rather, the octavia"},{"line_number":289,"context_line":"  VM should perform simple syntax checks, start / restart haproxy if the checks"},{"line_number":290,"context_line":"  pass, and report success/failure of the haproxy restart."}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_4dd28ffe","line":287,"updated":"2014-08-12 23:54:05.000000000","message":"this contradicts our desire for more complex things like shipping logs to Swift","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"aaa6c568dd6af68952c9716ec3c8968beeefe803","unresolved":false,"context_lines":[{"line_number":284,"context_line":"  other software (especially for TLS termination) later on."},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"* The \"glue scripts\" which communicate with the controller should be as"},{"line_number":287,"context_line":"  lightweight as possible: Intelligence about how to put together an haproxy"},{"line_number":288,"context_line":"  config, for example, should not live on the octavia VM. Rather, the octavia"},{"line_number":289,"context_line":"  VM should perform simple syntax checks, start / restart haproxy if the checks"},{"line_number":290,"context_line":"  pass, and report success/failure of the haproxy restart."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ab29df4_3a791d94","line":287,"in_reply_to":"baada198_4dd28ffe","updated":"2014-08-13 19:08:02.000000000","message":"Seeing as how there are no requirements for shipping logs defined anywhere, I don\u0027t think we can say it\u0027s actually complicated at this juncture.\n\nThe idea behind this statement is the whole \"centralize intelligence, decentralize workload\" philosophy that\u0027s part of our constitution.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"780094b882e23e014e61f0fab207bc91350a3a3e","unresolved":false,"context_lines":[{"line_number":324,"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"},{"line_number":325,"context_line":"In order to keep things as scalable as possible, the thought was that short,"},{"line_number":326,"context_line":"periodic and arguably less vital messages being emitted by the octavia VM and"},{"line_number":327,"context_line":"associated controller would be done via HMAC-signed UDP, and more vital, more"},{"line_number":328,"context_line":"sensitive, and potentially longer transactional messages would be handled via a"},{"line_number":329,"context_line":"RESTful API on the controller, accessed via bi-directionally authenticated"},{"line_number":330,"context_line":"HTTPS."}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_6d73d31c","line":327,"updated":"2014-08-12 23:54:05.000000000","message":"We should stick to one protocol for 0.5. Having eveyrhting be REST should simplify things and accelerate delivery.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"433798bd93d52bcaec68b518c1823c5776133480","unresolved":false,"context_lines":[{"line_number":324,"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"},{"line_number":325,"context_line":"In order to keep things as scalable as possible, the thought was that short,"},{"line_number":326,"context_line":"periodic and arguably less vital messages being emitted by the octavia VM and"},{"line_number":327,"context_line":"associated controller would be done via HMAC-signed UDP, and more vital, more"},{"line_number":328,"context_line":"sensitive, and potentially longer transactional messages would be handled via a"},{"line_number":329,"context_line":"RESTful API on the controller, accessed via bi-directionally authenticated"},{"line_number":330,"context_line":"HTTPS."}],"source_content_type":"text/x-rst","patch_set":2,"id":"7ac7a964_f719167a","line":327,"in_reply_to":"9ab29df4_ba928d9d","updated":"2014-08-16 01:22:43.000000000","message":"Also, as discussed in the Octavia meeting on 13 Aug 2014: I\u0027m fine with coding it all using a REST interface initially... but if someone wants to go out of their way to make the UDP stuff work in v0.5, I\u0027m not going to reject that code, eh. ;)","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"aaa6c568dd6af68952c9716ec3c8968beeefe803","unresolved":false,"context_lines":[{"line_number":324,"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"},{"line_number":325,"context_line":"In order to keep things as scalable as possible, the thought was that short,"},{"line_number":326,"context_line":"periodic and arguably less vital messages being emitted by the octavia VM and"},{"line_number":327,"context_line":"associated controller would be done via HMAC-signed UDP, and more vital, more"},{"line_number":328,"context_line":"sensitive, and potentially longer transactional messages would be handled via a"},{"line_number":329,"context_line":"RESTful API on the controller, accessed via bi-directionally authenticated"},{"line_number":330,"context_line":"HTTPS."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ab29df4_ba928d9d","line":327,"in_reply_to":"baada198_308daed5","updated":"2014-08-13 19:08:02.000000000","message":"I\u0027m not married to the UDP stuff at this time, but doing everything over REST will become a performance bottleneck later on. It didn\u0027t seem to me that using UDP for the above would be very difficult, but if the majority disagree I\u0027m happy to change this.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"be19972e9f556a5218bb852953bb048d8050227c","unresolved":false,"context_lines":[{"line_number":324,"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"},{"line_number":325,"context_line":"In order to keep things as scalable as possible, the thought was that short,"},{"line_number":326,"context_line":"periodic and arguably less vital messages being emitted by the octavia VM and"},{"line_number":327,"context_line":"associated controller would be done via HMAC-signed UDP, and more vital, more"},{"line_number":328,"context_line":"sensitive, and potentially longer transactional messages would be handled via a"},{"line_number":329,"context_line":"RESTful API on the controller, accessed via bi-directionally authenticated"},{"line_number":330,"context_line":"HTTPS."}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_308daed5","line":327,"in_reply_to":"baada198_6d73d31c","updated":"2014-08-13 00:25:19.000000000","message":"+1, I think we should stick to REST and not create a custom UDP protocol.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"780094b882e23e014e61f0fab207bc91350a3a3e","unresolved":false,"context_lines":[{"line_number":365,"context_line":"  failure, but is much less efficient, as far as VM resource utilization is"},{"line_number":366,"context_line":"  concerned."},{"line_number":367,"context_line":""},{"line_number":368,"context_line":"* In this topology a floating IP address (different from a Neutron floating"},{"line_number":369,"context_line":"  IP!) is used to determine which octavia VM is the \"active\" one at any given"},{"line_number":370,"context_line":"  time."},{"line_number":371,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_adcb2b1c","line":368,"updated":"2014-08-12 23:54:05.000000000","message":"This requires some Neutron plugins or switching off the anti-spoofing logic. This needs to be described in more detail to make sure the algorithm works in a particular network topology","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"aaa6c568dd6af68952c9716ec3c8968beeefe803","unresolved":false,"context_lines":[{"line_number":365,"context_line":"  failure, but is much less efficient, as far as VM resource utilization is"},{"line_number":366,"context_line":"  concerned."},{"line_number":367,"context_line":""},{"line_number":368,"context_line":"* In this topology a floating IP address (different from a Neutron floating"},{"line_number":369,"context_line":"  IP!) is used to determine which octavia VM is the \"active\" one at any given"},{"line_number":370,"context_line":"  time."},{"line_number":371,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ab29df4_1a37f9b1","line":368,"in_reply_to":"baada198_adcb2b1c","updated":"2014-08-13 19:08:02.000000000","message":"Right. So the initial thought was to make Octavia VMs part of the \"services\" group (if I recall correctly), which would mean that anti-spoofing logic would be turned off by default. In any case, managing this is something we could potentially rely on the networking driver to do as well.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"780094b882e23e014e61f0fab207bc91350a3a3e","unresolved":false,"context_lines":[{"line_number":381,"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"},{"line_number":382,"context_line":"This is actually where things get tricky, as far as octavia VM plumbing is"},{"line_number":383,"context_line":"concerned. And it only grows trickier when we consider that front-end"},{"line_number":384,"context_line":"connectivity (ie. to the \u0027loadbalancer\u0027 vip_address) and back-end connectivity"},{"line_number":385,"context_line":"(ie. to members of a loadbalancing pool) can be handled in different ways."},{"line_number":386,"context_line":"Having said this, we can break things down into LB network, front-end and"},{"line_number":387,"context_line":"back-end topology to discuss the various possible permutations here."}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_8ded8790","line":384,"updated":"2014-08-12 23:54:05.000000000","message":"Please also explore the use case where a customer is employign a load balancer between two subnets, e.g. to load balance between application servers and the database for instance","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"aaa6c568dd6af68952c9716ec3c8968beeefe803","unresolved":false,"context_lines":[{"line_number":381,"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"},{"line_number":382,"context_line":"This is actually where things get tricky, as far as octavia VM plumbing is"},{"line_number":383,"context_line":"concerned. And it only grows trickier when we consider that front-end"},{"line_number":384,"context_line":"connectivity (ie. to the \u0027loadbalancer\u0027 vip_address) and back-end connectivity"},{"line_number":385,"context_line":"(ie. to members of a loadbalancing pool) can be handled in different ways."},{"line_number":386,"context_line":"Having said this, we can break things down into LB network, front-end and"},{"line_number":387,"context_line":"back-end topology to discuss the various possible permutations here."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ab29df4_5a26d169","line":384,"in_reply_to":"baada198_8ded8790","updated":"2014-08-13 19:08:02.000000000","message":"I\u0027m not sure that actually changes anything here. There\u0027s no reason a front end vip_address can\u0027t be on a tenant\u0027s back-end network somewhere (unless I\u0027m missing something important here?)  In this layout, we\u0027d be using layer-2 connectivity to the front-end.","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"d6e35f6454a63ba5b977fd0a7cb1ea16a1e5ca14","unresolved":false,"context_lines":[{"line_number":110,"context_line":"**Notes:**"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"* This is a daemon or \"unofficial extension\", presumably living on a Neutron"},{"line_number":113,"context_line":"  network node which should have \"back door\" access to all things Neutron and"},{"line_number":114,"context_line":"  exposes an API that should only be used by Octavia."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"* Exactly what API will be provided by this driver will be defined as we"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7ac7a964_465b3354","line":113,"updated":"2014-08-15 04:49:14.000000000","message":"So is the Networking Driver living in Neutron or is the driver going to be living in Octavia as a daemon that the controller can call, that in turn calls this unofficial extension?\n\nSounds like this extension will just need to be a way to get access to the _core_plugin methods.  I assume your idea is to basically have another set of resources that would give us access to that other than the core ports, subnets, and networks resources?","commit_id":"b203196ddd77d5bc815715fc34d275bb083fd981"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"597fae7cb72f30df087ffd50c9affcd2f39b4b28","unresolved":false,"context_lines":[{"line_number":110,"context_line":"**Notes:**"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"* This is a daemon or \"unofficial extension\", presumably living on a Neutron"},{"line_number":113,"context_line":"  network node which should have \"back door\" access to all things Neutron and"},{"line_number":114,"context_line":"  exposes an API that should only be used by Octavia."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"* Exactly what API will be provided by this driver will be defined as we"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1abeadc6_2422fcb8","line":113,"in_reply_to":"1abeadc6_a2554dc3","updated":"2014-08-29 18:57:51.000000000","message":"As long as the main Octavia code only has to worry about talking with our own abstraction layer, I don\u0027t have a strong opinion on exactly how we communicate with the networking layer below that.","commit_id":"b203196ddd77d5bc815715fc34d275bb083fd981"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"6559648b5c0a58bf9a3e63ce1ff85caa06cb807f","unresolved":false,"context_lines":[{"line_number":110,"context_line":"**Notes:**"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"* This is a daemon or \"unofficial extension\", presumably living on a Neutron"},{"line_number":113,"context_line":"  network node which should have \"back door\" access to all things Neutron and"},{"line_number":114,"context_line":"  exposes an API that should only be used by Octavia."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"* Exactly what API will be provided by this driver will be defined as we"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7ac7a964_fc165df0","line":113,"in_reply_to":"7ac7a964_465b3354","updated":"2014-08-16 01:08:39.000000000","message":"There might be more than one component to this, like an unofficial extension that operationally gets put on Neutron networking nodes so it can be loaded with the rest of Neutron, as well as the actual networking driver which interfaces with that and Neutron proper within Octavia. In any case, I think it makes sense for control of this code to lie with Octavia.\n\nI\u0027m mostly interested in ensuring that what \"Octavia proper\" talks to is an abstraction layer under the (sole) control of Octavia project leadership so that we have maximum flexibility in defining that interface.\n\nThis abstraction layer may have 1:1 correspondence with certain Neutron concepts, though it may behoove us to get a closer look at nova-networking too to see what objects / concepts they\u0027re working with. Also, this would make Octavia potentially more usable for operators who aren\u0027t using Neutron networking.\n\nNote also that this concept is still being fleshed out since the changes necessitating this are pretty recent. I\u0027m definitely open to suggestions here!","commit_id":"b203196ddd77d5bc815715fc34d275bb083fd981"},{"author":{"_account_id":10980,"name":"Doug Wiegley","email":"dougwig@parkside.io","username":"dougw"},"change_message_id":"735b939b29369222b075e5b3fec68d465a9313f2","unresolved":false,"context_lines":[{"line_number":110,"context_line":"**Notes:**"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"* This is a daemon or \"unofficial extension\", presumably living on a Neutron"},{"line_number":113,"context_line":"  network node which should have \"back door\" access to all things Neutron and"},{"line_number":114,"context_line":"  exposes an API that should only be used by Octavia."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"* Exactly what API will be provided by this driver will be defined as we"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1abeadc6_a2554dc3","line":113,"in_reply_to":"7ac7a964_fc165df0","updated":"2014-08-28 23:04:07.000000000","message":"No need for it to live in neutron.  It can import neutron, and it\u0027s just on us to CI test for regressions.","commit_id":"b203196ddd77d5bc815715fc34d275bb083fd981"},{"author":{"_account_id":10980,"name":"Doug Wiegley","email":"dougwig@parkside.io","username":"dougw"},"change_message_id":"735b939b29369222b075e5b3fec68d465a9313f2","unresolved":false,"context_lines":[{"line_number":170,"context_line":"* Generating configuration files for haproxy and PEM-formatted user"},{"line_number":171,"context_line":"  certificates and sending these to individual octavia VMs. Configuration files"},{"line_number":172,"context_line":"  will be generated from jinja templates kept in an template directory"},{"line_number":173,"context_line":"  specific to haproxy."},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"* Processing the configuration updates that need to be applied to individual"},{"line_number":176,"context_line":"  octavia VMs, as sent by the LBaaS driver."}],"source_content_type":"text/x-rst","patch_set":3,"id":"1abeadc6_e2f905c9","line":173,"updated":"2014-08-28 23:04:07.000000000","message":"Would prefer: Sending configuration and certificate information to an octavia backend driver, which in the first implementation will be ... \u003cinsert current text\u003e.","commit_id":"b203196ddd77d5bc815715fc34d275bb083fd981"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"597fae7cb72f30df087ffd50c9affcd2f39b4b28","unresolved":false,"context_lines":[{"line_number":170,"context_line":"* Generating configuration files for haproxy and PEM-formatted user"},{"line_number":171,"context_line":"  certificates and sending these to individual octavia VMs. Configuration files"},{"line_number":172,"context_line":"  will be generated from jinja templates kept in an template directory"},{"line_number":173,"context_line":"  specific to haproxy."},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"* Processing the configuration updates that need to be applied to individual"},{"line_number":176,"context_line":"  octavia VMs, as sent by the LBaaS driver."}],"source_content_type":"text/x-rst","patch_set":3,"id":"1abeadc6_186000ce","line":173,"in_reply_to":"1abeadc6_e2f905c9","updated":"2014-08-29 18:57:51.000000000","message":"Done","commit_id":"b203196ddd77d5bc815715fc34d275bb083fd981"},{"author":{"_account_id":10980,"name":"Doug Wiegley","email":"dougwig@parkside.io","username":"dougw"},"change_message_id":"735b939b29369222b075e5b3fec68d465a9313f2","unresolved":false,"context_lines":[{"line_number":178,"context_line":"* Interfacing with network driver to plumb additional interfaces on the octavia"},{"line_number":179,"context_line":"  VMs as necessary."},{"line_number":180,"context_line":""},{"line_number":181,"context_line":"* Monitoring the health of all octavia VMs."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"* Receiving and routing certain kinds of notifications originating on the"},{"line_number":184,"context_line":"  octavia VMs (ex. \"member down\")"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1abeadc6_22005daa","line":181,"updated":"2014-08-28 23:04:07.000000000","message":"By calling an octavia driver interface.","commit_id":"b203196ddd77d5bc815715fc34d275bb083fd981"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"597fae7cb72f30df087ffd50c9affcd2f39b4b28","unresolved":false,"context_lines":[{"line_number":178,"context_line":"* Interfacing with network driver to plumb additional interfaces on the octavia"},{"line_number":179,"context_line":"  VMs as necessary."},{"line_number":180,"context_line":""},{"line_number":181,"context_line":"* Monitoring the health of all octavia VMs."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"* Receiving and routing certain kinds of notifications originating on the"},{"line_number":184,"context_line":"  octavia VMs (ex. \"member down\")"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1abeadc6_385bfc22","line":181,"in_reply_to":"1abeadc6_22005daa","updated":"2014-08-29 18:57:51.000000000","message":"Done","commit_id":"b203196ddd77d5bc815715fc34d275bb083fd981"},{"author":{"_account_id":10980,"name":"Doug Wiegley","email":"dougwig@parkside.io","username":"dougw"},"change_message_id":"735b939b29369222b075e5b3fec68d465a9313f2","unresolved":false,"context_lines":[{"line_number":207,"context_line":"  and deleting ones from the pool when we have too much inventory here.)"},{"line_number":208,"context_line":""},{"line_number":209,"context_line":"* Gracefully spinning down \"dirty old octavia VMs\""},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"**Notes:**"},{"line_number":212,"context_line":""},{"line_number":213,"context_line":"* Almost all the intelligence around putting together and validating"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1abeadc6_e220254b","line":210,"updated":"2014-08-28 23:04:07.000000000","message":"* Loading and calling cofnigured octavia backend drivers.","commit_id":"b203196ddd77d5bc815715fc34d275bb083fd981"},{"author":{"_account_id":10980,"name":"Doug Wiegley","email":"dougwig@parkside.io","username":"dougw"},"change_message_id":"735b939b29369222b075e5b3fec68d465a9313f2","unresolved":false,"context_lines":[{"line_number":260,"context_line":"* Responding to specific requests from the controller for very basic"},{"line_number":261,"context_line":"  loadbalancer or sub-object status data, including statistics."},{"line_number":262,"context_line":""},{"line_number":263,"context_line":"* Shipping listener logs to a swift data store, if configured."},{"line_number":264,"context_line":""},{"line_number":265,"context_line":"* Sending \"edge\" notifications (ie. status changes) to the controller when"},{"line_number":266,"context_line":"  members go up and down, when listeners go up and down, etc."}],"source_content_type":"text/x-rst","patch_set":3,"id":"1abeadc6_82d93159","line":263,"updated":"2014-08-28 23:04:07.000000000","message":"Why swift?  It\u0027s optional in most projects.  Suggest remote syslog.","commit_id":"b203196ddd77d5bc815715fc34d275bb083fd981"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"597fae7cb72f30df087ffd50c9affcd2f39b4b28","unresolved":false,"context_lines":[{"line_number":260,"context_line":"* Responding to specific requests from the controller for very basic"},{"line_number":261,"context_line":"  loadbalancer or sub-object status data, including statistics."},{"line_number":262,"context_line":""},{"line_number":263,"context_line":"* Shipping listener logs to a swift data store, if configured."},{"line_number":264,"context_line":""},{"line_number":265,"context_line":"* Sending \"edge\" notifications (ie. status changes) to the controller when"},{"line_number":266,"context_line":"  members go up and down, when listeners go up and down, etc."}],"source_content_type":"text/x-rst","patch_set":3,"id":"1abeadc6_78d57441","line":263,"in_reply_to":"1abeadc6_82d93159","updated":"2014-08-29 18:57:51.000000000","message":"So, this is just mentioned as an example of something we would want to do on the VM and specifically not on the controller. Nobody has defined any logging requirements at all yet, so this probably won\u0027t actually happen in the first iteration (or at all-- until someone defines their requirements).  I\u0027ll clarify the wording here.","commit_id":"b203196ddd77d5bc815715fc34d275bb083fd981"},{"author":{"_account_id":6437,"name":"Susanne Balle","email":"sleipnir012@gmail.com","username":"susanne-balle"},"change_message_id":"1a04c23ef1603e01e7bf74ccb9c147c82a83af93","unresolved":false,"context_lines":[{"line_number":404,"context_line":"host to the subnet on which the loadbalancer vip_address resides. In this"},{"line_number":405,"context_line":"scenario, the octavia VM would need to send ARP responses to requests for the"},{"line_number":406,"context_line":"vip_address, and therefore octavia VMs need to have interfaces plumbed on said"},{"line_number":407,"context_line":"vip_address subnets which participate in ARP."},{"line_number":408,"context_line":""},{"line_number":409,"context_line":"Note that this is somewhat problematic for active / standby virtual appliance"},{"line_number":410,"context_line":"topologies because the vip_address for a given load balancer effectively"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1abeadc6_3bc47f5e","line":407,"updated":"2014-08-19 06:56:05.000000000","message":"Just wanted to make sure this is noted somewhere that we can only access the LB via floating IPs managed by Neutron and cannot use static IPs or IPs not managed by Neutron.","commit_id":"b203196ddd77d5bc815715fc34d275bb083fd981"},{"author":{"_account_id":6437,"name":"Susanne Balle","email":"sleipnir012@gmail.com","username":"susanne-balle"},"change_message_id":"83a5a996a787b0e4a42646fd18cb8c9ca5eaf8c6","unresolved":false,"context_lines":[{"line_number":404,"context_line":"host to the subnet on which the loadbalancer vip_address resides. In this"},{"line_number":405,"context_line":"scenario, the octavia VM would need to send ARP responses to requests for the"},{"line_number":406,"context_line":"vip_address, and therefore octavia VMs need to have interfaces plumbed on said"},{"line_number":407,"context_line":"vip_address subnets which participate in ARP."},{"line_number":408,"context_line":""},{"line_number":409,"context_line":"Note that this is somewhat problematic for active / standby virtual appliance"},{"line_number":410,"context_line":"topologies because the vip_address for a given load balancer effectively"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1abeadc6_b685ef08","line":407,"in_reply_to":"1abeadc6_3bc47f5e","updated":"2014-08-27 13:03:10.000000000","message":"I had a chat with Jack McCann our Neutron lead and here is what I learned:\n\nA *neutron floating IP* is implemented at the neutron router, so the VM never sees that address; the VM will only see the fixed IP address on its neutron port where the floating IP is associated.\n\nThere is also the neutron \"allowed-address-pairs\" api extension that lets you put additional fixed IP addresses on a neutron port, addresses that the VM would see; it was specificially designed for VIPs that could be moved from one port\nto another.\n\nWe want to make sure octavia works with *neutron floating IPs*, but that is a  separate concern from what is documented in “Front-end topologies” section.  Perhaps that is a gap in the spec that could be addressed.","commit_id":"b203196ddd77d5bc815715fc34d275bb083fd981"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"597fae7cb72f30df087ffd50c9affcd2f39b4b28","unresolved":false,"context_lines":[{"line_number":404,"context_line":"host to the subnet on which the loadbalancer vip_address resides. In this"},{"line_number":405,"context_line":"scenario, the octavia VM would need to send ARP responses to requests for the"},{"line_number":406,"context_line":"vip_address, and therefore octavia VMs need to have interfaces plumbed on said"},{"line_number":407,"context_line":"vip_address subnets which participate in ARP."},{"line_number":408,"context_line":""},{"line_number":409,"context_line":"Note that this is somewhat problematic for active / standby virtual appliance"},{"line_number":410,"context_line":"topologies because the vip_address for a given load balancer effectively"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1abeadc6_5814389f","line":407,"in_reply_to":"1abeadc6_b685ef08","updated":"2014-08-29 18:57:51.000000000","message":"So, the way to accomplish that if you\u0027re using \"Option 1: Layer-2 connectivity\" is to have the vip_address be an internal address that exists in a specific tenant subnet, and then set your neutron floating IP to point to that.  That should allow for highly available active/standby topologies that can do automatic failover without having to alter the \"Neutron floating IP\" when the failover happens.\n\nHaving said this, as we flesh out the abstract networking interface that Octavia will use, it may be up to the networking driver to determine how to shuffle things when a failover happens. If you\u0027ve got what boils down to a low-level way to address network concerns here, there might be several ways to accomplish failover ranging from adjusting the neutron floating IP on the fly, to using a \"real\" VRRP or CARP interface on the octavia VMs, and several other options.\n\nThe only thing I\u0027m fairly certain of at this point is that the Octavia VMs need to be able to have several IP addresses associated with them. It\u0027s not going to work if the Octavia VM can only have one IP address.\n\nIn any case, though--  I\u0027m not much of a fan of the \"Option 1\" here as I think failovers are far less graceful than \"Option 2\" below, and because when we introduce active-active topologies, \"Option 1\" is effectively not an option with that topology. (That is to say, you can really only do active-active topologies using routed-mode front-end connectivity.)\n\nAlso note that neutron floating IPs inherently use NAT. At some point we want to support IPv6 with Octavia, and IPv6 does not have any equivalent concept of NAT.  So...  again, \"routed mode\" (Option 2) is the only thing I\u0027ve seen work well for highly available IPv6.\n\nSusanne-- what do your networking folks think of Option 2 below? Is that feasible in your network?","commit_id":"b203196ddd77d5bc815715fc34d275bb083fd981"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"d6e35f6454a63ba5b977fd0a7cb1ea16a1e5ca14","unresolved":false,"context_lines":[{"line_number":413,"context_line":"relenquish all the vip_addresses it has, and the standby needs to take them"},{"line_number":414,"context_line":"over *and* start up haproxy services. This is OK if a given octavia"},{"line_number":415,"context_line":"VM only has a few load balancers, but can lead to several minutes\u0027 down-time"},{"line_number":416,"context_line":"during a graceful failover if there are a dozen or more load balancers on the"},{"line_number":417,"context_line":"active/standby octavia VM pair. It\u0027s also more risky: The standby node might"},{"line_number":418,"context_line":"not be able to start up all the haproxy services during such a"},{"line_number":419,"context_line":"failover. What\u0027s more, most types of VRRP-like services which handle floating"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7ac7a964_543f4f25","line":416,"updated":"2014-08-15 04:49:14.000000000","message":"Regarding the multiple haproxy instances on a single VM:\n\nHow do we prevent the chance of IP collisions for interfaces if multiple tenants\u0027 load balancers can reside on the same VM since two tenants can have similar CIDRs for their subnets? Part of the scheduling? Don\u0027t allow multiple tenants on one VM?\n\nThis is similar to an issue we talked about with the neutron lbaas API on putting the subnet on the member. What if a user has two subnets, both created with similar CIDRs. If they choose to create member1 with subnet1 and member2 with subnet2, they\u0027ve kinda shot themselves in the foot. We were fine with allowing a user to shoot themselves in the foot, but if it happens between two tenants its not on them, its on us.","commit_id":"b203196ddd77d5bc815715fc34d275bb083fd981"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"6559648b5c0a58bf9a3e63ce1ff85caa06cb807f","unresolved":false,"context_lines":[{"line_number":413,"context_line":"relenquish all the vip_addresses it has, and the standby needs to take them"},{"line_number":414,"context_line":"over *and* start up haproxy services. This is OK if a given octavia"},{"line_number":415,"context_line":"VM only has a few load balancers, but can lead to several minutes\u0027 down-time"},{"line_number":416,"context_line":"during a graceful failover if there are a dozen or more load balancers on the"},{"line_number":417,"context_line":"active/standby octavia VM pair. It\u0027s also more risky: The standby node might"},{"line_number":418,"context_line":"not be able to start up all the haproxy services during such a"},{"line_number":419,"context_line":"failover. What\u0027s more, most types of VRRP-like services which handle floating"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7ac7a964_dcab611b","line":416,"in_reply_to":"7ac7a964_543f4f25","updated":"2014-08-16 01:08:39.000000000","message":"I see two possible solutions to this problem:\n\nSolution 1: Network Namespaces\n\nWe could use network namespaces on the Octavia VM to keep things separate. We could do this either at the tenant level, the loadbalancer or the listener, depending on what we think makes the most sense.\n\nPros:\n\n* Allows several different tenant loadbalancers to occupy the same Octavia VM, resulting in hardware savings for the operator, while also ensuring overlapping tenant IP address ranges are kept separate and appropriately reachable, and that tenants aren\u0027t inadvertently able to access resources of another tenant on the same Octavia VM.\n\nCons:\n\n* More difficult to code and troubleshoot, and therefore easier for obscure bugs to break assumptions about hard partitions between tenants.\n\n* No real benefit to private cloud operators.\n\n* Network namespaces means more logical interfaces which need to be managed somehow.\n\n\nSolution 2: Never allow more than 1 tenant per Octavia VM\n\n(Note this is actually a similar model to the above, with easier-defined partitioning between tenants. This is also one solution you alluded to.)\n\nPros:\n\n* Relatively simple to code, simple to troubleshoot\n\n* Less error-prone security model\n\nCons:\n\n* Less efficient use of hardware for large cloud operators\n\nUltimately, I think that the savings in terms of code debt, avoiding potential security problems, and... well, simpler code to write and troubleshoot will probably outweigh any benefits that can be gained by having multiple tenants on a single Octavia VM in the short to medium term.  When we get to Octavia v2 (or v3) territory, and especially when auto-scaling active-active topologies of Octavia VMs becomes a thing... it may make sense to revisit solution 1 here to reduce costs for large public cloud operators.","commit_id":"b203196ddd77d5bc815715fc34d275bb083fd981"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"9fc09a03c8ab06fb5f71fb445790bc582b7dde38","unresolved":false,"context_lines":[{"line_number":413,"context_line":"relenquish all the vip_addresses it has, and the standby needs to take them"},{"line_number":414,"context_line":"over *and* start up haproxy services. This is OK if a given octavia"},{"line_number":415,"context_line":"VM only has a few load balancers, but can lead to several minutes\u0027 down-time"},{"line_number":416,"context_line":"during a graceful failover if there are a dozen or more load balancers on the"},{"line_number":417,"context_line":"active/standby octavia VM pair. It\u0027s also more risky: The standby node might"},{"line_number":418,"context_line":"not be able to start up all the haproxy services during such a"},{"line_number":419,"context_line":"failover. What\u0027s more, most types of VRRP-like services which handle floating"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7ac7a964_898526af","line":416,"in_reply_to":"7ac7a964_dcab611b","updated":"2014-08-16 04:25:42.000000000","message":"Exactly what I was thinking, and definitely the best way forward to go.","commit_id":"b203196ddd77d5bc815715fc34d275bb083fd981"},{"author":{"_account_id":6951,"name":"Brandon Logan","email":"brandon.logan@rackspace.com","username":"brandon-logan"},"change_message_id":"b84bfad87b8c4efefb872f9a12bc544c970149d2","unresolved":false,"context_lines":[{"line_number":506,"context_line":"**Option 2: Routed (layer-3) connectivity**"},{"line_number":507,"context_line":""},{"line_number":508,"context_line":"This is routed connectivity to back-end members. This is implied when a member"},{"line_number":509,"context_line":"object does not have a subnet_id specified. In this topology, it is assumed"},{"line_number":510,"context_line":"that member ip_addresses are reachable through standard neutron routing, and"},{"line_number":511,"context_line":"therefore connections to them can be initiated from the octavia VM\u0027s default"},{"line_number":512,"context_line":"gateway. No new virtual interfaces need to be plumbed for this type of"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa98f980_c1aa9ed1","line":509,"updated":"2014-09-02 04:30:18.000000000","message":"I\u0027m sure this is obvious, but making sure it\u0027s noted.  If one member has already been added with a specific subnet, and a second member is added within the same cidr but not subnet is specified, it won\u0027t use the default gateway.  This is transparent to a user and really I don\u0027t think the code should have to be any different either.  So moot point?  Unless I missed something.","commit_id":"e9fb154ce891b10982c5a7e962efbc444bb2840f"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"8679f28dd3b0d74f3abfb034ae58e9f00d3d402b","unresolved":false,"context_lines":[{"line_number":506,"context_line":"**Option 2: Routed (layer-3) connectivity**"},{"line_number":507,"context_line":""},{"line_number":508,"context_line":"This is routed connectivity to back-end members. This is implied when a member"},{"line_number":509,"context_line":"object does not have a subnet_id specified. In this topology, it is assumed"},{"line_number":510,"context_line":"that member ip_addresses are reachable through standard neutron routing, and"},{"line_number":511,"context_line":"therefore connections to them can be initiated from the octavia VM\u0027s default"},{"line_number":512,"context_line":"gateway. No new virtual interfaces need to be plumbed for this type of"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa98f980_fc0ab977","line":509,"in_reply_to":"fa98f980_c1aa9ed1","updated":"2014-09-03 02:32:16.000000000","message":"Yeah, I think this is one of those cases where a user can potentially shoot themselves in the foot by having overlapping subnet ranges that are being referenced. I don\u0027t think there\u0027s a way around this because even in the context of network namespaces, a single process (eg. haproxy) can only exist within one namespace.\n\nSo, yes-- this is mostly a moot point. Think it\u0027s worth mentioning in the documentation somewhere? (I don\u0027t think code should be affected by this.)","commit_id":"e9fb154ce891b10982c5a7e962efbc444bb2840f"}],"doc/source/design/version0.5/v0.5-component-design.dot":[{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"be19972e9f556a5218bb852953bb048d8050227c","unresolved":false,"context_lines":[{"line_number":98,"context_line":""},{"line_number":99,"context_line":"      NetworkingDriver [shape\u003drectangle label\u003d\"Networking Driver\"];"},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"      OperatorAPIHandler [shape\u003dnone margin\u003d0 label\u003d"},{"line_number":102,"context_line":"         \u003c\u003ctable border\u003d\"0\" cellspacing\u003d\"0\" cellborder\u003d\"1\"\u003e"},{"line_number":103,"context_line":"           \u003ctr\u003e"},{"line_number":104,"context_line":"             \u003ctd style\u003d\"invis\"\u003e\u003c/td\u003e"}],"source_content_type":"application/msword","patch_set":2,"id":"baada198_338a1866","line":101,"updated":"2014-08-13 00:25:19.000000000","message":"The changes to the diagram confuse me.  How does this relate or not relate to compatibility with the Nuetron LBaaS v2 API?","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"},{"author":{"_account_id":11685,"name":"Stephen Balukoff","email":"stephen@balukoff.com","username":"sbalukoff"},"change_message_id":"aaa6c568dd6af68952c9716ec3c8968beeefe803","unresolved":false,"context_lines":[{"line_number":98,"context_line":""},{"line_number":99,"context_line":"      NetworkingDriver [shape\u003drectangle label\u003d\"Networking Driver\"];"},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"      OperatorAPIHandler [shape\u003dnone margin\u003d0 label\u003d"},{"line_number":102,"context_line":"         \u003c\u003ctable border\u003d\"0\" cellspacing\u003d\"0\" cellborder\u003d\"1\"\u003e"},{"line_number":103,"context_line":"           \u003ctr\u003e"},{"line_number":104,"context_line":"             \u003ctd style\u003d\"invis\"\u003e\u003c/td\u003e"}],"source_content_type":"application/msword","patch_set":2,"id":"9ab29df4_daf021cc","line":101,"in_reply_to":"baada198_338a1866","updated":"2014-08-13 19:08:02.000000000","message":"So, the Operator API handler has been moved inside the \"Octavia\" box to show that it\u0027s actually under the control of Octavia. As is the Networking Driver.\n\nThe user API handler is shown inside the \"Neutron LBaaS\" box to show that it\u0027s handled by Neutron LBaaS.\n\nDoes that make sense?","commit_id":"5a075bb0310986217fa9eba48cff5521c2e571f4"}]}