Re: [openstack-dev] [Octavia] Minutes from 8/6/2014 meeting
Great notes! thanks it helped me catch up after vacation. :) On Thu, Aug 7, 2014 at 4:33 AM, Stephen Balukoff sbaluk...@bluebox.net wrote: On where to capture notes like this long-term: I would say the wiki is more searchable for now. When we make the transition to IRC meetings, then the meeting bots will capture minutes and transcripts in the usual way and we can link to these from the wiki. On Thu, Aug 7, 2014 at 1:29 AM, Stephen Balukoff sbaluk...@bluebox.net wrote: Wow, Trevor! Thanks for capturing all that! On Wed, Aug 6, 2014 at 9:47 PM, Trevor Vardeman trevor.varde...@rackspace.com wrote: Agenda items are numbered, and topics, as discussed, are described beneath in list format. 1) Octavia Constitution and Project Direction Documents (Road map) a) Constitution and Road map will potentially be adopted after another couple days; providing those who were busy more time to review the information 2) Octavia Design Proposals a) Difference between version 0.5 and 1.0 isn't huge b) Version 2 has many network topology changes and Layer 4 routing + This includes N node Active-Active + Would like to avoid Layer 2 connectivity with Load Balancers (included in version 1 however) + Layer router driver + Layer router controller + Long term solution c) After refining Version 1 document (with some scrutiny) all changes will be propagated to the Version 2 document d) Version 0.5 is unpublished e) All control layer, anything connected to the intermediate message bus in version 1, will be collapsed down to 1 daemon. + No scale-able control, but scale-able service delivery + Version 1 will be the first large operator compatible version, that will have both scale-able control and scale-able service delivery + 0.5 will be a good start - laying out ground work - rough topology for the end users - must be approved by the networking teams for each contributing company f) The portions under control of neutron lbaas is the User API and the driver (for neutron lbaas) g) If neutron LBaaS is a sufficient front-end (user API doesn't suck), then Octavia will be kept as a vendor driver h) Potentially including a REST API on top of Octavia + Octavia is initially just a vendor driver, no real desire for another API in front of Octavia + If someone wants it, the work is trivial and can be done in another project at another time i) Octavia should have a loose coupling with Neutron; use a shim for network connectivity (one specifically for Neutron communication in the start) + This is going to hold any dirty hacks that would be required to get something done, keeping Octavia clean - Example: changing the mac address on a port 3) Operator Network Topology Requirements a) One requirement is floating IPs. b) IPv6 is in demand, but is currently not supported reliably on Neutron + IPv6 would be represented as a different load balancer entity, and possibly include co-location with another Load Balancer c) Network interface plug-ability (potentially) d) Sections concerning front-end connectivity should be forwarded to each company's network specialists for review + Share findings in the mailing list, and dissect the proposals with the information and comment what requirements are needing added etc. 4) HA/Failover Options/Solutions a) Rackspace may have a solution to this, but the conversation will be pushed off to the next meeting (at least) + Will gather more information from another member in Rackspace to provide to the ML for initial discussions b) One option for HA: Spare pool option (similar to Libra) + Poor recovery time is a big problem c) Another option for HA: Active/Passive + Bluebox uses one active and one passive configuration, and has sub-second fail over. However is not resource-sufficient Questions: Q: What is the expectation for a release time-frame A: Wishful thinking; Octavia version 0.5 beta for Juno (probably not, but would be awesome to push for that) Notes: + We need to pressure the Neutron core reviewers to review the Neutron LBaaS changes to get merges. + Version 2 front-end topology is different than the Version 1. Please review them individually, and thoroughly PS. I re-wrote most of the information from the recording (thanks again Doug). I have one question for everyone: should I just email this out after each meeting to the Octavia mailing list, or should I also add it to a page in an Octavia wiki for Meeting Notes/Minutes or something for review by anyone? What are your thoughts? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Octavia] Minutes from 8/6/2014 meeting
On where to capture notes like this long-term: I would say the wiki is more searchable for now. When we make the transition to IRC meetings, then the meeting bots will capture minutes and transcripts in the usual way and we can link to these from the wiki. On Thu, Aug 7, 2014 at 1:29 AM, Stephen Balukoff sbaluk...@bluebox.net wrote: Wow, Trevor! Thanks for capturing all that! On Wed, Aug 6, 2014 at 9:47 PM, Trevor Vardeman trevor.varde...@rackspace.com wrote: Agenda items are numbered, and topics, as discussed, are described beneath in list format. 1) Octavia Constitution and Project Direction Documents (Road map) a) Constitution and Road map will potentially be adopted after another couple days; providing those who were busy more time to review the information 2) Octavia Design Proposals a) Difference between version 0.5 and 1.0 isn't huge b) Version 2 has many network topology changes and Layer 4 routing + This includes N node Active-Active + Would like to avoid Layer 2 connectivity with Load Balancers (included in version 1 however) + Layer router driver + Layer router controller + Long term solution c) After refining Version 1 document (with some scrutiny) all changes will be propagated to the Version 2 document d) Version 0.5 is unpublished e) All control layer, anything connected to the intermediate message bus in version 1, will be collapsed down to 1 daemon. + No scale-able control, but scale-able service delivery + Version 1 will be the first large operator compatible version, that will have both scale-able control and scale-able service delivery + 0.5 will be a good start - laying out ground work - rough topology for the end users - must be approved by the networking teams for each contributing company f) The portions under control of neutron lbaas is the User API and the driver (for neutron lbaas) g) If neutron LBaaS is a sufficient front-end (user API doesn't suck), then Octavia will be kept as a vendor driver h) Potentially including a REST API on top of Octavia + Octavia is initially just a vendor driver, no real desire for another API in front of Octavia + If someone wants it, the work is trivial and can be done in another project at another time i) Octavia should have a loose coupling with Neutron; use a shim for network connectivity (one specifically for Neutron communication in the start) + This is going to hold any dirty hacks that would be required to get something done, keeping Octavia clean - Example: changing the mac address on a port 3) Operator Network Topology Requirements a) One requirement is floating IPs. b) IPv6 is in demand, but is currently not supported reliably on Neutron + IPv6 would be represented as a different load balancer entity, and possibly include co-location with another Load Balancer c) Network interface plug-ability (potentially) d) Sections concerning front-end connectivity should be forwarded to each company's network specialists for review + Share findings in the mailing list, and dissect the proposals with the information and comment what requirements are needing added etc. 4) HA/Failover Options/Solutions a) Rackspace may have a solution to this, but the conversation will be pushed off to the next meeting (at least) + Will gather more information from another member in Rackspace to provide to the ML for initial discussions b) One option for HA: Spare pool option (similar to Libra) + Poor recovery time is a big problem c) Another option for HA: Active/Passive + Bluebox uses one active and one passive configuration, and has sub-second fail over. However is not resource-sufficient Questions: Q: What is the expectation for a release time-frame A: Wishful thinking; Octavia version 0.5 beta for Juno (probably not, but would be awesome to push for that) Notes: + We need to pressure the Neutron core reviewers to review the Neutron LBaaS changes to get merges. + Version 2 front-end topology is different than the Version 1. Please review them individually, and thoroughly PS. I re-wrote most of the information from the recording (thanks again Doug). I have one question for everyone: should I just email this out after each meeting to the Octavia mailing list, or should I also add it to a page in an Octavia wiki for Meeting Notes/Minutes or something for review by anyone? What are your thoughts? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807
[openstack-dev] [Octavia] Minutes from 8/6/2014 meeting
Agenda items are numbered, and topics, as discussed, are described beneath in list format. 1) Octavia Constitution and Project Direction Documents (Road map) a) Constitution and Road map will potentially be adopted after another couple days; providing those who were busy more time to review the information 2) Octavia Design Proposals a) Difference between version 0.5 and 1.0 isn't huge b) Version 2 has many network topology changes and Layer 4 routing + This includes N node Active-Active + Would like to avoid Layer 2 connectivity with Load Balancers (included in version 1 however) + Layer router driver + Layer router controller + Long term solution c) After refining Version 1 document (with some scrutiny) all changes will be propagated to the Version 2 document d) Version 0.5 is unpublished e) All control layer, anything connected to the intermediate message bus in version 1, will be collapsed down to 1 daemon. + No scale-able control, but scale-able service delivery + Version 1 will be the first large operator compatible version, that will have both scale-able control and scale-able service delivery + 0.5 will be a good start - laying out ground work - rough topology for the end users - must be approved by the networking teams for each contributing company f) The portions under control of neutron lbaas is the User API and the driver (for neutron lbaas) g) If neutron LBaaS is a sufficient front-end (user API doesn't suck), then Octavia will be kept as a vendor driver h) Potentially including a REST API on top of Octavia + Octavia is initially just a vendor driver, no real desire for another API in front of Octavia + If someone wants it, the work is trivial and can be done in another project at another time i) Octavia should have a loose coupling with Neutron; use a shim for network connectivity (one specifically for Neutron communication in the start) + This is going to hold any dirty hacks that would be required to get something done, keeping Octavia clean - Example: changing the mac address on a port 3) Operator Network Topology Requirements a) One requirement is floating IPs. b) IPv6 is in demand, but is currently not supported reliably on Neutron + IPv6 would be represented as a different load balancer entity, and possibly include co-location with another Load Balancer c) Network interface plug-ability (potentially) d) Sections concerning front-end connectivity should be forwarded to each company's network specialists for review + Share findings in the mailing list, and dissect the proposals with the information and comment what requirements are needing added etc. 4) HA/Failover Options/Solutions a) Rackspace may have a solution to this, but the conversation will be pushed off to the next meeting (at least) + Will gather more information from another member in Rackspace to provide to the ML for initial discussions b) One option for HA: Spare pool option (similar to Libra) + Poor recovery time is a big problem c) Another option for HA: Active/Passive + Bluebox uses one active and one passive configuration, and has sub-second fail over. However is not resource-sufficient Questions: Q: What is the expectation for a release time-frame A: Wishful thinking; Octavia version 0.5 beta for Juno (probably not, but would be awesome to push for that) Notes: + We need to pressure the Neutron core reviewers to review the Neutron LBaaS changes to get merges. + Version 2 front-end topology is different than the Version 1. Please review them individually, and thoroughly PS. I re-wrote most of the information from the recording (thanks again Doug). I have one question for everyone: should I just email this out after each meeting to the Octavia mailing list, or should I also add it to a page in an Octavia wiki for Meeting Notes/Minutes or something for review by anyone? What are your thoughts? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
