Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
+1 for option 2. In addition as an additional safeguard, the LBaaS service could check with Barbican when failing to use an existing secret to see if the secret has changed (lazy detection). Youcef -Original Message- From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] Sent: Friday, June 06, 2014 12:16 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas Hey everyone, Per our IRC discussion yesterday I'd like to continue the discussion on how Barbican and Neutron LBaaS will interact. There are currently two ideas in play and both will work. If you have another idea please free to add it so that we may evaluate all the options relative to each other. Here are the two current ideas: 1. Create an eventing system for Barbican that Neutron LBaaS (and other services) consumes to identify when to update/delete updated secrets from Barbican. For those that aren't up to date with the Neutron LBaaS API Revision, the project/tenant/user provides a secret (container?) id when enabling SSL/TLS functionality. * Example: If a user makes a change to a secret/container in Barbican then Neutron LBaaS will see an event and take the appropriate action. PROS: - Barbican is going to create an eventing system regardless so it will be supported. - Decisions are made on behalf of the user which lessens the amount of calls the user has to make. CONS: - An eventing framework can become complex especially since we need to ensure delivery of an event. - Implementing an eventing system will take more time than option #2ŠI think. 2. Push orchestration decisions to API users. This idea comes with two assumptions. The first assumption is that most providers' customers use the cloud via a GUI, which in turn can handle any orchestration decisions that need to be made. The second assumption is that power API users are savvy and can handle their decisions as well. Using this method requires services, such as LBaaS, to register in the form of metadata to a barbican container. * Example: If a user makes a change to a secret the GUI can see which services are registered and opt to warn the user of consequences. Power users can look at the registered services and make decisions how they see fit. PROS: - Very simple to implement. The only code needed to make this a reality is at the control plane (API) level. - This option is more loosely coupled that option #1. CONS: - Potential for services to not register/unregister. What happens in this case? - Pushes complexity of decision making on to GUI engineers and power API users. I would like to get a consensus on which option to move forward with ASAP since the hackathon is coming up and delivering Barbican to Neutron LBaaS integration is essential to exposing SSL/TLS functionality, which almost everyone has stated is a #1/#2 priority. I'll start the decision making process by advocating for option #2. My reason for choosing option #2 has to deal mostly with the simplicity of implementing such a mechanism. Simplicity also means we can implement the necessary code and get it approved much faster which seems to be a concern for everyone. What option does everyone else want to move forward with? Cheers, --Jorge ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Thanks Susanne, and was great meeting many of you. Actually I was trying to find an updated version of the object model that was presented at the summit but couldn’t find it. Is there a link online? Youcef From: Susanne Balle [mailto:sleipnir...@gmail.com] Sent: Monday, May 19, 2014 2:07 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Great summit!! fantastic to meeting you all in person. We now have agreement on the Object model. How do we turn that into blueprints and also how do we start making progress on the rest of the items we agree upon at the summit? Susanne On Fri, May 16, 2014 at 2:07 AM, Brandon Logan brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote: Yeah that’s a good point. Thanks! From: Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 10:38 PM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Brandon, It's allowed right now just per API. It's up to a backend to decide the status of a node in case some monitors find it dead. Thanks, Eugene. On Fri, May 16, 2014 at 4:41 AM, Brandon Logan brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote: I have concerns about multiple health monitors on the same pool. Is this always going to be the same type of health monitor? There’s also ambiguity in the case where one health monitor fails and another doesn’t. Is it an AND or OR that determines whether the member is down or not? Thanks, Brandon Logan From: Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 9:55 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Vijay, Pools-monitors are still many to many, if it's not so on the picture - we'll fix that. I brought this up as an example of how we dealt with m:n via API. Thanks, Eugene. On Thu, May 15, 2014 at 6:43 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.commailto:vijay.venkatacha...@citrix.com wrote: Thanks for the clarification. Eugene. A tangential point since you brought healthmon and pool. There will be an additional entity called ‘PoolMonitorAssociation’ which results in a many to many relationship between pool and monitors. Right? Now, the model is indicating a pool can have only one monitor. So a minor correction is required to indicate the many to many relationship via PoolMonitorAssociation. Thanks, Vijay V. From: Eugene Nikanorov [mailto:enikano...@mirantis.commailto:enikano...@mirantis.com] Sent: Thursday, May 15, 2014 7:36 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Hi Vijay, When you say API is not available, it means this should not be considered like a resource/entity. Correct? But then, there would be API like a bind API, that accepts loadbalancer_id listener_id, which creates this object. And also, there would be an API that will be used to list the listeners of a LoadBalancer. Right? Right, that's the same as health monitors and pools work right now: there are separate REST action to associate healthmon to a pool Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS]Conforming to Open Stack API style in LBaaS
Sam,
I think it's important to keep the Neutron API style consistent. It would be
odd if LBaaS uses a different style than the rest of the Neutron APIs.
Youcef
From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Wednesday, April 30, 2014 10:59 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron][LBaaS]Conforming to Open Stack API style in
LBaaS
Hi Everyone,
During the last few days I have looked into the different LBaaS API proposals.
I have also looked on the API style used in Neutron. I wanted to see how
Neutron APIs addressed tree like object models.
Follows my observation:
1. Security groups -
http://docs.openstack.org/api/openstack-network/2.0/content/security-groups-ext.html)
-
a.
security-group-ruleshttp://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html
are children of
security-groupshttp://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroups_v2.0_security-groups_security-groups-ext.html,
the capability to create a security group with its children in a single call
is not possible.
b. The capability to create
security-group-ruleshttp://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html
using the following URI path
v2.0/security-groupshttp://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroups_v2.0_security-groups_security-groups-ext.html/{SG-ID}/security-group-ruleshttp://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html
is not supported
c.The capability to update
security-group-ruleshttp://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html
using the following URI path
v2.0/security-groupshttp://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroups_v2.0_security-groups_security-groups-ext.html/{SG-ID}/security-group-ruleshttp://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html/{SGR-ID}
is not supported
d. The notion of creating
security-group-ruleshttp://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html
(child object) without providing the parent {SG-ID} is not supported
2. Firewall as a service -
http://docs.openstack.org/api/openstack-network/2.0/content/fwaas_ext.html -
the API to manage firewall_policy and firewall_rule which have parent child
relationships behaves the same way as Security groups
3. Group Policy - this is work in progress -
https://wiki.openstack.org/wiki/Neutron/GroupPolicy - If I understand
correctly, this API has a complex object model while the API adheres to the way
other neutron APIs are done (ex: flat model, granular api, etc.)
How critical is it to preserve a consistent API style for LBaaS?
Should this be a consideration when evaluating API proposals?
Regards,
-Sam.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Requirements Wiki
Stephen, I don’t think the active/passive pools feature is referring to the HA of loadbalancers. This is about the ability to divide the list of members servicing load-balanced requests into 2 groups: The first one is active and the second one is passive (or a backup pool). If all the members in the first pool are down, then the passive pool’s members become serving traffic for that VIP. Youcef From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] Sent: Thursday, March 20, 2014 7:06 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Requirements Wiki Hi y'all! It's good to be back, eh! On Wed, Mar 19, 2014 at 11:35 PM, Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com wrote: * Active/Passive Failover * I think this is solved with multiple pools. The multiple pools support that is coming with L7 rules is to support content-switching based on L7 HTTP information (URL, headers, etc.). There is no support today for an active vs. passive pool. I'm not sure that's the priority. It depends on if this is widely supported among vendors. A commercial load balancer that doesn't have high availability features? Is there really such a thing still being sold in 2014? ;) Also, Jorge-- thanks for creating that page! I've made a few additions to it as well that I'd love to see prioritized. Stephen -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Requirements Wiki
Jorge, Just to clarify, is this a feature to control which client IP addresses can access the VIP? Thanks, Youcef From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] Sent: Thursday, March 20, 2014 8:37 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Requirements Wiki Thanks for the input. I too was thinking IP Access Control could be solved with the firewall service in Neutron. To clarify what I mean check out our current API docs on this feature herehttp://docs.rackspace.com/loadbalancers/api/v1.0/clb-devguide/content/Manage_Access_Lists-d1e3187.html. Cheers, --Jorge From: Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 20, 2014 1:35 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Requirements Wiki Hi folks, my comments inlined: On Thu, Mar 20, 2014 at 6:13 AM, Youcef Laribi youcef.lar...@citrix.commailto:youcef.lar...@citrix.com wrote: Jorge, Thanks for taking the time to put up a requirements list. Some comments below: * Static IP Addresses * Our current Cloud Load Balancing (CLB) offering utilizes static IP addresses which is something our customers really like, especially when setting up DNS. AWS for example, gives you an A record which you CNAME to. This should also already be addressed, as you can today specify the VIP's IP address explicitly on creation. We do not have DNS-based support for LB like in AWS ELB though. Right, it's already there. Probably that's why it confused me :) * Active/Passive Failover * I think this is solved with multiple pools. The multiple pools support that is coming with L7 rules is to support content-switching based on L7 HTTP information (URL, headers, etc.). There is no support today for an active vs. passive pool. I'm not sure that's the priority. It depends on if this is widely supported among vendors. * IP Access Control * Our current CLB offering allows the user to restrict access through their load balancer by blacklisting/whitelisting cidr blocks and even individual ip addresses. This is just a basic security feature. Is this controlling access to the VIP's IP address or to pool members IP addresses? There is also a Firewall service in Neutron. Could this feature better fit in that service? Agree, it's better to utilize what fwaas has to offer. Eugene. Youcef From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.commailto:jorge.miramon...@rackspace.com] Sent: Wednesday, March 19, 2014 11:44 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Requirements Wiki Oleg, thanks for the updates. Eugene, High/Medium/Low is fine with me. I really just wanted to find a way to rank even amongst all of 'X' priorities. As people start adding more items we may need more columns to add things such as this, links to blueprints (per Ryan's idea), etc. In terms of the requirements marked with a '?' I can try to clarify here: * Static IP Addresses * Our current Cloud Load Balancing (CLB) offering utilizes static IP addresses which is something our customers really like, especially when setting up DNS. AWS for example, gives you an A record which you CNAME to. * Active/Passive Failover * I think this is solved with multiple pools. * IP Access Control * Our current CLB offering allows the user to restrict access through their load balancer by blacklisting/whitelisting cidr blocks and even individual ip addresses. This is just a basic security feature. Cheers, --Jorge From: Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, March 19, 2014 7:32 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Requirements Wiki Hi Jorge, Thanks for taking care of the page. I've added priorities, although I'm not sure we need precise priority weights. Those features that still have '?' need further clarification. Thanks, Eugene. On Wed, Mar 19, 2014 at 11:18 AM, Oleg Bondarev obonda...@mirantis.commailto:obonda...@mirantis.com wrote: Hi Jorge, Thanks for taking care of this and bringing it all together! This will be really useful for LBaaS discussions. I updated the wiki to include L7 rules support and also marking already implemented requirements. Thanks, Oleg On Wed, Mar 19, 2014 at 2
Re: [openstack-dev] [Neutron][LBaaS] Requirements Wiki
Jorge, Thanks for taking the time to put up a requirements list. Some comments below: * Static IP Addresses * Our current Cloud Load Balancing (CLB) offering utilizes static IP addresses which is something our customers really like, especially when setting up DNS. AWS for example, gives you an A record which you CNAME to. This should also already be addressed, as you can today specify the VIP's IP address explicitly on creation. We do not have DNS-based support for LB like in AWS ELB though. * Active/Passive Failover * I think this is solved with multiple pools. The multiple pools support that is coming with L7 rules is to support content-switching based on L7 HTTP information (URL, headers, etc.). There is no support today for an active vs. passive pool. * IP Access Control * Our current CLB offering allows the user to restrict access through their load balancer by blacklisting/whitelisting cidr blocks and even individual ip addresses. This is just a basic security feature. Is this controlling access to the VIP's IP address or to pool members IP addresses? There is also a Firewall service in Neutron. Could this feature better fit in that service? Youcef From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] Sent: Wednesday, March 19, 2014 11:44 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Requirements Wiki Oleg, thanks for the updates. Eugene, High/Medium/Low is fine with me. I really just wanted to find a way to rank even amongst all of 'X' priorities. As people start adding more items we may need more columns to add things such as this, links to blueprints (per Ryan's idea), etc. In terms of the requirements marked with a '?' I can try to clarify here: * Static IP Addresses * Our current Cloud Load Balancing (CLB) offering utilizes static IP addresses which is something our customers really like, especially when setting up DNS. AWS for example, gives you an A record which you CNAME to. * Active/Passive Failover * I think this is solved with multiple pools. * IP Access Control * Our current CLB offering allows the user to restrict access through their load balancer by blacklisting/whitelisting cidr blocks and even individual ip addresses. This is just a basic security feature. Cheers, --Jorge From: Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, March 19, 2014 7:32 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Requirements Wiki Hi Jorge, Thanks for taking care of the page. I've added priorities, although I'm not sure we need precise priority weights. Those features that still have '?' need further clarification. Thanks, Eugene. On Wed, Mar 19, 2014 at 11:18 AM, Oleg Bondarev obonda...@mirantis.commailto:obonda...@mirantis.com wrote: Hi Jorge, Thanks for taking care of this and bringing it all together! This will be really useful for LBaaS discussions. I updated the wiki to include L7 rules support and also marking already implemented requirements. Thanks, Oleg On Wed, Mar 19, 2014 at 2:57 AM, Jorge Miramontes jorge.miramon...@rackspace.commailto:jorge.miramon...@rackspace.com wrote: Hey Neutron LBaaS folks, Per last week's IRC meeting I have created a preliminary requirements use case wiki page. I requested adding such a page since there appears to be a lot of new interest in load balancing and feel that we need a structured way to align everyone's interest in the project. Furthermore, it appears that understanding everyone's requirements and use cases will aid in the current object model discussion we all have been having. That being said, this wiki is malleable and open to discussion. I have added some preliminary requirements from my team's perspective in order to start the discussion. My vision is that people add requirements and use cases to the wiki for what they envision Neutron LBaaS becoming. That way, we can all discuss as a group, figure out what should and shouldn't be a requirement and prioritize the rest in an effort to focus development efforts. ReadyŠsetŠgo! Here is the link to the wiki == https://wiki.openstack.org/wiki/Neutron/LBaaS/requirements Cheers, --Jorge ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
Re: [openstack-dev] [Neutron][LBaaS] Mini-summit Interest?
+1 I think if we can have it before the Juno summit, we can take concrete, well thought-out proposals to the community at the summit. Cheers, Youcef From: Stephen Wong [mailto:s3w...@midokura.com] Sent: Thursday, March 06, 2014 11:57 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Mini-summit Interest? I agree with that, and it should take place before the J-Summit. Location is key here :-) On Thu, Mar 6, 2014 at 7:32 AM, Jorge Miramontes jorge.miramon...@rackspace.commailto:jorge.miramon...@rackspace.com wrote: Hi everyone, I'd like to gauge everyone's interest in a possible mini-summit for Neturon LBaaS. If enough people are interested I'd be happy to try and set something up. The Designate team just had a productive mini-summit in Austin, TX and it was nice to have face-to-face conversations with people in the Openstack community. While most of us will meet in Atlanta in May, I feel that a focused mini-summit will be more productive since we won't have other Openstack distractions around us. Let me know what you all think! Cheers, --Jorge ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Mini-summit Interest?
Jay, What I meant is that the people who are involved regularly in LBaaS can have a space and time to hash out all the arguments and get clarity, and this is open to anybody to attend (hence mini-summit), while at the summit itself there is so much going on, it's hard to find time and focus to have these discussions (from my previous experience at the last few summits). My 2 cents :) Youcef -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: Thursday, March 06, 2014 1:31 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Mini-summit Interest? On Thu, 2014-03-06 at 21:14 +, Youcef Laribi wrote: +1 I think if we can have it before the Juno summit, we can take concrete, well thought-out proposals to the community at the summit. Unless something has changed starting at the Hong Kong design summit (which unfortunately I was not able to attend), the design summits have always been a place to gather to *discuss* and *debate* proposed blueprints and design specs. It has never been about a gathering to rubber-stamp proposals that have already been hashed out in private somewhere else. Or, am I missing something? Has this changed in the past year? Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Health monitoring and statistics for complex LB configurations.
Hi Eugene, Having an aggregate call to get all of the stats and statuses is good, but we should also keep the ability to retrieve statistics or the status of individual resources IMHO. Thanks Youcef From: Eugene Nikanorov [mailto:enikano...@mirantis.com] Sent: Wednesday, March 05, 2014 12:42 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [Neutron][LBaaS] Health monitoring and statistics for complex LB configurations. Hi community, Another interesting questions were raised during object model discussion about how pool statistics and health monitoring should be used in case of multiple vips sharing one pool. Right now we can query statistics for the pool, and some data like in/out bytes and request count will be returned. If we had several vips sharing the pool, what kind of statistics would make sense for the user? The options are: 1) aggregated statistics for the pool, e.g. statistics of all requests that has hit the pool through any VIP 2) per-vip statistics for the pool. Depending on the answer, the statistics workflow will be different. The good option of getting the statistics and health status could be to query it through the vip and get it for the whole logical instance, e.g. a call like: lb-vip-statistics-get --vip-id vip_id the would result in json that returns statistics for every pool associated with the vip, plus operational status of all members for the pools associated with that VIP. Looking forward to your feedback. Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [LBaaS] API spec for SSL Support
Hi Anand, I don't think it's fully documented in the API spec yet, but there is a patchset being reviewed in gerrit that shows how the API would look like (LbaasSSLDBMixin class): https://review.openstack.org/#/c/74031/5/neutron/db/loadbalancer/lbaas_ssl_db.py Thanks, Youcef From: Palanisamy, Anand [mailto:apalanis...@paypal.com] Sent: Wednesday, March 05, 2014 5:26 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [LBaaS] API spec for SSL Support Hi All, Please let us know if we have the blueprint or the proposal for the LBaaS SSL API specification. We see only the workflow documented here https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL. Thanks Anand ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion
Hi Eugene, Thanks for the provided detail. See my comments below. The point is to be able to share IP address, it really means that two VIPs(as we understand them in current model) need to reside within same backend (technically they need to share neutron port). Aren't we leaking some implementation detail here? Why is it that 2 VIPs using the same IP address have to be implemented on the same backend? Isn't this a driver/technology capability? If a certain driver *requires* that VIPs sharing the same IP address have to be on the same backend (whatever a backend means), it just needs to ensure that this is the case, but another driver might be able to support VIPs sharing the same IP to be on different backends. The user really shouldn't care. Did I miss some important detail? It feels like it, so please be patient with me :) I'm sorry this all creates so much confusion. In order to understand why we need additional entity, you need to keep in mind the following things: 1) We have a notion of root object. From user perspective it represents logical instance, from implementation perspective it also represents how that instance is mapped to a backend (agent, device), which flavor/provider/driver it has, etc 2) We're trying to change vip-pool relationship to m:n, if vip or pool remain the root object, that creates inconsistency because root object can be connected to another root object with different parameters. I'm not against introducing a wrapper entity that correlates the different config objects that logically make up one LB config, but I don't think it is needed from the logical object model pov IMO. Yes, it might make the implementation of the object model for some drivers easier, and I'm OK with having it, if it helps. But strictly speaking it is not needed, because a driver doesn't have to choose a backend when the pool is created or when a vip is created, if it doesn't have enough info yet. It can wait until a vip/pool are created and attached to each other, then it would have a clearer idea of the backends eligible to host that whole LB configuration. Another driver though, might be able to perform the configuration on its backend straight-away on each API call, and still be able to comply with the object model. Youcef On Thu, Feb 27, 2014 at 5:20 AM, Youcef Laribi youcef.lar...@citrix.commailto:youcef.lar...@citrix.com wrote: Hi Eugene, 1) In order to allow real multiple 'vips' per pool feature, we need the listener concept. It's not just a different tcp port, but also a protocol, so session persistence and all ssl-related parameters should move to listener. Why do we need a new 'listener' concept? Since as Sam pointed out, we are removing the reference to a pool from the VIP in the current model, isn't this enough by itself to allow the model to support multiple VIPs per pool now? lb-pool-create --$POOL-1 lb-vip-create .$VIP_ADDRESS,$TCP_PORT, default_pool=$POOL-1... -- $VIP-1 lb-vip-create .$VIP_ADDRESS,$TCP_PORT, default_pool=$POOL-1... -- $VIP-2 Youcef From: Eugene Nikanorov [mailto:enikano...@mirantis.commailto:enikano...@mirantis.com] Sent: Wednesday, February 26, 2014 1:26 PM To: Samuel Bercovici Cc: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion Hi Sam, I've looked over the document, couple of notes: 1) In order to allow real multiple 'vips' per pool feature, we need the listener concept. It's not just a different tcp port, but also a protocol, so session persistence and all ssl-related parameters should move to listener. 2) ProviderResourceAssociation - remains on the instance object (our instance object is VIP) as a relation attribute. Though it is removed from public API, so it could not be specified on creation. Remember provider is needed for REST call dispatching. The value of provider attribute (e.g. ProviderResourceAssociation) is result of scheduling. 3) As we discussed before, pool-vip relation will be removed, but pool reuse by different vips (e.g. different backends) will be forbidden for implementation simplicity, because this is definitely not a priority right now. I think it's a fair limitation that can be removed later. On workflows: WFs #2 and #3 are problematic. First off, sharing the same IP is not possible for other vip for the following reason: vip is created (with new model) with flavor (or provider) and scheduled to a provider (and then to a particular backend), doing so for 2 vips makes address reuse impossible if we want to maintain logical API, or otherwise we would need to expose implementation details that will allow us to connect two vips to the same backend. On the open discussion questions: I think most of them are resolved by following existing API expectations about status fields, etc. Main thing that allows to go with existing API expectations is the notion of 'root object'. Root object
Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion
Hi Eugene, 1) In order to allow real multiple 'vips' per pool feature, we need the listener concept. It's not just a different tcp port, but also a protocol, so session persistence and all ssl-related parameters should move to listener. Why do we need a new 'listener' concept? Since as Sam pointed out, we are removing the reference to a pool from the VIP in the current model, isn't this enough by itself to allow the model to support multiple VIPs per pool now? lb-pool-create --$POOL-1 lb-vip-create .$VIP_ADDRESS,$TCP_PORT, default_pool=$POOL-1... -- $VIP-1 lb-vip-create .$VIP_ADDRESS,$TCP_PORT, default_pool=$POOL-1... -- $VIP-2 Youcef From: Eugene Nikanorov [mailto:enikano...@mirantis.com] Sent: Wednesday, February 26, 2014 1:26 PM To: Samuel Bercovici Cc: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion Hi Sam, I've looked over the document, couple of notes: 1) In order to allow real multiple 'vips' per pool feature, we need the listener concept. It's not just a different tcp port, but also a protocol, so session persistence and all ssl-related parameters should move to listener. 2) ProviderResourceAssociation - remains on the instance object (our instance object is VIP) as a relation attribute. Though it is removed from public API, so it could not be specified on creation. Remember provider is needed for REST call dispatching. The value of provider attribute (e.g. ProviderResourceAssociation) is result of scheduling. 3) As we discussed before, pool-vip relation will be removed, but pool reuse by different vips (e.g. different backends) will be forbidden for implementation simplicity, because this is definitely not a priority right now. I think it's a fair limitation that can be removed later. On workflows: WFs #2 and #3 are problematic. First off, sharing the same IP is not possible for other vip for the following reason: vip is created (with new model) with flavor (or provider) and scheduled to a provider (and then to a particular backend), doing so for 2 vips makes address reuse impossible if we want to maintain logical API, or otherwise we would need to expose implementation details that will allow us to connect two vips to the same backend. On the open discussion questions: I think most of them are resolved by following existing API expectations about status fields, etc. Main thing that allows to go with existing API expectations is the notion of 'root object'. Root object is the object which status and admin_state show real operability of the configuration. While from implementation perspective it is a mounting point between logical config and the backend. The real challenge of model #3 is ability to share pools between different VIPs, e.g. between different flavors/providers/backends. User may be unaware of it, but it requires really complex logic to handle statistics, healthchecks, etc. I think while me may leave this ability at object model and API level, we will limit it, as I said previously. Thanks, Eugene. On Wed, Feb 26, 2014 at 9:06 PM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi, I have added to the wiki page: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion#1.1_Turning_existing_model_to_logical_model that points to a document that includes the current model + L7 + SSL. Please review. Regards, -Sam. From: Samuel Bercovici Sent: Monday, February 24, 2014 7:36 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Samuel Bercovici Subject: RE: [openstack-dev] [Neutron][LBaaS] Object Model discussion Hi, I also agree that the model should be pure logical. I think that the existing model is almost correct but the pool should be made pure logical. This means that the vip pool relationships needs also to become any to any. Eugene, has rightfully pointed that the current state management will not handle such relationship well. To me this means that the state management is broken and not the model. I will propose an update to the state management in the next few days. Regards, -Sam. From: Mark McClain [mailto:mmccl...@yahoo-inc.com] Sent: Monday, February 24, 2014 6:32 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion On Feb 21, 2014, at 1:29 PM, Jay Pipes jaypi...@gmail.commailto:jaypi...@gmail.com wrote: I disagree on this point. I believe that the more implementation details bleed into the API, the harder the API is to evolve and improve, and the less flexible the API becomes. I'd personally love to see the next version of the LBaaS API be a complete breakaway from any implementation specifics and refocus itself to be a control plane API that is written from the perspective of the *user* of a load balancing service, not the perspective of
Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion
Hi guys, I have been catching up on this interesting thread around the object model, so sorry in advance to jump in late in this debate, and if I missed some of the subtleties of the points being made so far. I tend to agree with Sam that the original intention of the current object model was never tied to a physical deployment. We seem to be confusing the tenant-facing object model which is completely logical (albeit with some properties or qualities that a tenant can express) from the deployment/implementation aspects of such a logical model (things like cluster/HA, one vs. multiple backends, virtual appliance vs. OS process, etc). We discussed in the past, the need for an Admin API (separate from the tenant API) where a cloud administrator (as opposed to a tenant) could manage the deployment aspects, and could construct different offerings that can be exposed to a tenant, but in the absence of such as admin API (which would necessarily be very technology-specific), this responsibility is currently shouldered by the drivers. IMO a tenant should only care about whether VIPs/Pools are grouped together to the extent that the provider allows the tenant to express such a preference. Some providers will allow their tenants to express such a preference (e.g. because it might impact cost), and others might not as it wouldn't make sense in their implementation. Also the mapping between pool and backend is not necessarily 1:1, and is not necessarily at the creation time of pool, as this is purely a driver implementation decision (I know that currently implementations are like this, but another driver can choose a different approach). A driver could for example delay mapping a pool to a backend, until a full LB configuration is completed (when pool has members, and a VIP is attached to the pool). A driver can also move these resources around between backends, if it finds out, it put them in a non-optimal backend initially. As long as the logical model is realized and remains consistent from the tenant point of view, implementations should be free to achieve that goal in any way they see fit. Youcef From: Eugene Nikanorov [mailto:enikano...@mirantis.com] Sent: Wednesday, February 19, 2014 8:23 AM To: Samuel Bercovici Cc: OpenStack Development Mailing List; Mark McClain; Salvatore Orlando; sbaluk...@bluebox.net; Youcef Laribi; Avishay Balderman Subject: Re: [Neutron][LBaaS] Object Model discussion Hi Sam, My comments inline: On Wed, Feb 19, 2014 at 4:57 PM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi, I think we mix different aspects of operations. And try to solve a non problem. Not really, Advanced features we're trying to introduce are incompatible by both object model and API. From APIs/Operations we are mixing the following models: 1. Logical model (which as far as I understand is the topic of this discussion) - tenants define what they need logically vip--default_pool, l7 association, ssl, etc. That's correct. Tenant may or may not care about how it is grouped on the backend. We need to support both cases. 2. Physical model - operator / vendor install and specify how backend gets implemented. 3. Deploying 1 on 2 - this is currently the driver's responsibility. We can consider making it better but this should not impact the logical model. I think grouping vips and pools is important part of logical model, even if some users may not care about it. I think this is not a problem. In a logical model a pool which is part of L7 policy is a logical object which could be placed at any backend and any existing vippool and accordingly configure the backend that those vippool are deployed on. That's not how it currently works - that's why we're trying to address it. Having pool shareable between backends at least requires to move 'instance' role from the pool to some other entity, and also that changes a number of API aspects. If the same pool that was part of a l7 association will also be connected to a vip as a default pool, than by all means this new vippool pair can be instantiated into some back end. The proposal to not allow this (ex: only allow pools that are connected to the same lb-instance to be used for l7 association), brings the physical model into the logical model. So proposal tries to address 2 issues: 1) in many cases it is desirable to know about grouping of logical objects on the backend 2) currently physical model implied when working with pools, because pool is the root and corresponds to backend with 1:1 mapping I think that the current logical model is fine with the exception that the two way reference between vip and pool (vippool) should be modified with only vip pointing to a pool (vip--pool) which allows reusing the pool with multiple vips. Reusing pools by vips is not as simple as it seems. If those vips belong to 1 backend (that by itself requires tenant to know
