Re: [openstack-dev] [Octavia] PTL and core team members
Hi Brandon, Yep, that sounds like a good way to approach this. And FWIW, this week I'm planning on moving several of the designs I've presented to the group into blueprints / gerrit specs for the project and otherwise start working on a roadmap to actually get the thing built. In the mean time, there's still a ton that needs to be done on the Neutron LBaaS side of things to make sure we get feature improvements and cleaner Neutron API interfaces in before the Juno freeze. So I don't think there's a reason anyone should be idle working on these two projects, eh. Stephen On Sun, Jun 22, 2014 at 11:38 AM, Brandon Logan wrote: > I'm thinking we are going to need more than 2 on the core team at first > but it is hard to tell exactly how many people will be contributing code > at first. I know we've got a lot of interested parties and the > possibility that some 10+ people are actively contributing. Of course, > these things can only be predicted and will be unknown until it is > actually known. > > Also, we really need to have a good plan of action. Once we get a > consensus on the design we should start breaking the implementation up > into umbrella blueprint specs (or epic blueprint specs) with each one > detailing the bigger picture and breaking up the bigger picture into > smaller tasks/stories that can be accomplished. Then people can start > choosing which they would like to implement. Sounds good in theory, but > actually executing it will be the tough part. > > Thanks, > Brandon > > On Sun, 2014-06-22 at 13:42 +0200, Flavio Percoco wrote: > > On 20/06/14 07:29 +0100, Mark McLoughlin wrote: > > >On Thu, 2014-06-19 at 20:36 -0700, Dustin Lundquist wrote: > > >> Dolph, > > >> > > >> > > >> I appreciate the suggestion. In the mean time how does the review > > >> process work without core developers to approve gerrit submissions? > > > > > >If you're just getting started, have a small number (possibly just 1 to > > >begin with) of developers collaborate closely, with the minimum possible > > >process and then use that list of developers as your core review team > > >when you gradually start adopting some process. Aim to get from zero to > > >bootstrapped with that core team in a small number of weeks at most. > > > > > >Minimum possible process could mean a git repo anywhere that those > > >initial developers have direct push access to. You could use stackforge > > >from the beginning and the developers just approve their own changes, > > >but that's a bit annoying. > > > > +1 this is how we did it in Marconi (except for the repo with push > > access). At the beginning, we kept a core team of 2 developers despite > > there being at least 4 ppl working on the project. This allowed the > > team to have better discussions on what got in the repo and what not. > > > > One benefit of using stackforge is that you get a great CI system to > > test your project with but the development will slow down for sure. We > > started on stackforge right away, then had a 2 days hackathon on a > > github fork which was not a good idea because we had to submit al > > those patches for review after the hackathon. :( > > > > Flavio > > > > _______ > > 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 > -- 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
[openstack-dev] [Neutron][LBaaS] and [Octavia] haproxy-1.5.0 is out
. The links have been updated below. Note the removal of /devel/ for the sources and the introduction of haproxy-1.5.git since this is not the development tree anymore : Site index : http://www.haproxy.org/ Sources : http://www.haproxy.org/download/1.5/src/ Git repository : http://git.haproxy.org/git/haproxy-1.5.git/ Git Web browsing : http://git.haproxy.org/?p=haproxy-1.5.git Changelog: http://www.haproxy.org/download/1.5/src/CHANGELOG Cyril's HTML doc : http://cbonte.github.com/haproxy-dconv/configuration-1.5.html I'm figuring that tomorrow is Friday. Guys, be reasonable, don't forget the good old principle of not upgrading on Fridays, try to hold on till monday if you can :-) BTW, since I've got this question off-list a number of times now, yes we're going to release updated HAPEE packages very soon, please keep an eye on it : https://www.haproxy.com/products/haproxy-enterprise-edition/ And finally the changelog since 1.5-dev26. Have fun an as usual, please report anything abnormal you'd face up, but after checking the doc. Willy 2014/06/19 : 1.5.0 - MEDIUM: ssl: ignored file names ending as '.issuer' or '.ocsp'. - MEDIUM: ssl: basic OCSP stapling support. - MINOR: ssl/cli: Fix unapropriate comment in code on 'set ssl ocsp-response' - MEDIUM: ssl: add 300s supported time skew on OCSP response update. - MINOR: checks: mysql-check: Add support for v4.1+ authentication - MEDIUM: ssl: Add the option to use standardized DH parameters >= 1024 bits - MEDIUM: ssl: fix detection of ephemeral diffie-hellman key exchange by using the cipher description. - MEDIUM: http: add actions "replace-header" and "replace-values" in http-req/resp - MEDIUM: Break out check establishment into connect_chk() - MEDIUM: Add port_to_str helper - BUG/MEDIUM: fix ignored values for half-closed timeouts (client-fin and server-fin) in defaults section. - BUG/MEDIUM: Fix unhandled connections problem with systemd daemon mode and SO_REUSEPORT. - MINOR: regex: fix a little configuration memory leak. - MINOR: regex: Create JIT compatible function that return match strings - MEDIUM: regex: replace all standard regex function by own functions - MEDIUM: regex: Remove null terminated strings. - MINOR: regex: Use native PCRE API. - MINOR: missing regex.h include - DOC: Add Exim as Proxy Protocol implementer. - BUILD: don't use type "uint" which is not portable - BUILD: stats: workaround stupid and bogus -Werror=format-security behaviour - BUG/MEDIUM: http: clear CF_READ_NOEXP when preparing a new transaction - CLEANUP: http: don't clear CF_READ_NOEXP twice - DOC: fix proxy protocol v2 decoder example - DOC: fix remaining occurrences of "pattern extraction" - MINOR: log: allow the HTTP status code to be logged even in TCP frontends - MINOR: logs: don't limit HTTP header captures to HTTP frontends - MINOR: sample: improve sample_fetch_string() to report partial contents - MINOR: capture: extend the captures to support non-header keys - MINOR: tcp: prepare support for the "capture" action - MEDIUM: tcp: add a new tcp-request capture directive - MEDIUM: session: allow shorter retry delay if timeout connect is small - MEDIUM: session: don't apply the retry delay when redispatching - MEDIUM: session: redispatch earlier when possible - MINOR: config: warn when tcp-check rules are used without option tcp-check - BUG/MINOR: connection: make proxy protocol v1 support the UNKNOWN protocol - DOC: proxy protocol example parser was still wrong - DOC: minor updates to the proxy protocol doc - CLEANUP: connection: merge proxy proto v2 header and address block - MEDIUM: connection: add support for proxy protocol v2 in accept-proxy - MINOR: tools: add new functions to quote-encode strings - DOC: clarify the CSV format - MEDIUM: stats: report the last check and last agent's output on the CSV status - MINOR: freq_ctr: introduce a new averaging method - MEDIUM: session: maintain per-backend and per-server time statistics - MEDIUM: stats: report per-backend and per-server time stats in HTML and CSV outputs - BUG/MINOR: http: fix typos in previous patch - DOC: remove the ultra-obsolete TODO file - DOC: update roadmap - DOC: minor updates to the README - DOC: mention the maxconn limitations with the select poller - DOC: commit a few old design thoughts files -- 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] Great Mid-cycle Sprint
+1 to what Brandon just said. :) Seriously, though-- this week was nothing short of amazing! It's great to have such a wonderful team to work with, eh! And yes-- special thanks to Mark McClain and Kyle Mestery for being willing to come out and work so hard with us to make so much progress in such little time. LBaaS in Juno is going to kick ass! Stephen On Thu, Jun 19, 2014 at 9:17 PM, Brandon Logan wrote: > Greetings all, > I'd like to thank everyone who attended the LBaaS mid-cyle sprint for > taking the time and effort to make the trip to San Antonio. This was a > very productive sprint in all forms: direction, consensus, blueprints, > documentation, and of course code. It was just great to be able to get > so much done and have a clearer idea on the direction this project is > headed. > > I'd like to especially thank Kyle Mestery and Mark Mcclain for taking > the time out of their busy schedules to direct, teach, and giving us > help where and when we needed. The fact that they managed to have the > patience for three full days of this is just amazing. Actually, them > having the patience over the last few months and still willing to help > is just short of miraculous. Thanks again guys, you are great! > > I look forward to continuing to work with everyone on this and other > projects. We've got a lot to do but we'll be able to accomplish > everything we want if we continue to work together. Thanks again to all > involved! > > Brandon > > ___ > 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Octavia] PTL and core team members
Hi y'all! So, scanning through my e-mail archives, list of people active on the ML talking about Neutron LBaaS and the load balancer side project (ie. before we started calling it "octavia"), people who attended the Neutron LBaaS mid-cycle hackathon (in person or remotely), people recently contributing to Neutron LBaaS related code or specs, people I recognize being active in the IRC meetings, etc. I come up with the following list. Apologies in advance for anyone I've forgotten here; errors are entirely my fault: Avishay Balderman Susanne Balle Stephen Balukoff Samuel Bercovici Vijay Bhamidipati Tom Creighton German Eichberger Evgeny Fedoruk Carlos Garza Adam Harwell Vivek Jain Miguel Lavalle Brandon Logan Dustin Lundquist Mark McClain Kyle Mestery Jorge Miramontes Eugene Nikanorov Anand Palanisamy Phil Toohill Craig Tracey Trevor Vardeman Vijay Venkatachalam Min Wang Doug Wiegley I'm thinking the people who should be involved in this election should have shown both an interest in LBaaS or the Octavia side project, and have interest and intent to contribute to this project in meaningful ways in the near future. What do y'all think of these criteria? If y'all agree to this criteria, then the next steps / questions are: 1. Who should be added to the above list who isn't on it yet (and how have they shown their interest in LBaaS or Octavia in the recent past)? 2. Who on the above list doesn't want to be on it (ie. won't be contributing to Octavia)? 3. Do we have any volunteers to run the election? (The person running the election should not be a candidate, and should, if at all possible, have no interests one way or another in Octavia.) Thanks, Stephen On Thu, Jun 19, 2014 at 6:33 PM, Anita Kuno wrote: > On 06/19/2014 09:13 PM, Stephen Balukoff wrote: > > Also, to clarify: It's obviously up to Doug to determine whether he > thinks > > contributing to Octavia would be a conflict of interest. I was just > saying > > I wouldn't be surprised or offended if he decided to opt out because of > > this, eh. > > > > > > On Thu, Jun 19, 2014 at 5:55 PM, Stephen Balukoff > > > wrote: > > > >> Thanks for the link, Anita! > >> > >> These are definitely good guidelines, but there are a couple problems > with > >> doing the election exactly as described in the document: It looks like > to > >> generate the list of voters, it recommends using the list of people who > >> have committed code to the project in the last year. As this project is > >> just getting bootstrapped, obviously we have no committed code yet. > >> > >> It might be possible to use mailing list activity (in [Neutron][LBaaS] > in > >> particular) to generate this list, but also keep in mind that not > everyone > >> who has been active on the mailing list is interested in contributing to > >> Octavia. For example, while Doug Wiegley has made great contributions to > >> Neutron LBaaS, it's probably a conflict of interest for him to > participate > >> in Octavia, since he works for a load balancer vendor. > >> > >> I do agree that the election should not be conducted by one of the > >> candidates in any case. What do y'all think, as far as determining the > list > >> of who should be able to vote and/or nominate candidates? > >> > >> Thanks, > >> Stephen > >> > Yes, the links were meant as a starting point for the Octivia group to > decide what rules to use to conduct their election. Deciding the > electorate is an important discussion to have. > > Once the group has decided what rules to be bound by and selected an > election official, then you are ready to begin your election process. > > May it go well, > Anita. > >> > >> > >> On Thu, Jun 19, 2014 at 3:37 PM, Anita Kuno > wrote: > >> > >>> On 06/19/2014 06:29 PM, Craig Tracey wrote: > >>>> I'd like to nominate Brandon Logan and Doug Wiegley as core members. > >>>> > >>>> > >>>> On Thu, Jun 19, 2014 at 6:18 PM, Stephen Balukoff < > >>> sbaluk...@bluebox.net> > >>>> wrote: > >>>> > >>>>> Howdy y'all! > >>>>> > >>>>> Among other things that happened at the Neutron LBaaS mid-cycle > >>> hackathon, > >>>>> we have now put together process around, and established Octavia as a > >>>>> stackforge project. For those just joining us, Octavia is going to > >>> become > >>>>> an open-source operator-grade load balancer implementation
Re: [openstack-dev] [Octavia] PTL and core team members
Also, to clarify: It's obviously up to Doug to determine whether he thinks contributing to Octavia would be a conflict of interest. I was just saying I wouldn't be surprised or offended if he decided to opt out because of this, eh. On Thu, Jun 19, 2014 at 5:55 PM, Stephen Balukoff wrote: > Thanks for the link, Anita! > > These are definitely good guidelines, but there are a couple problems with > doing the election exactly as described in the document: It looks like to > generate the list of voters, it recommends using the list of people who > have committed code to the project in the last year. As this project is > just getting bootstrapped, obviously we have no committed code yet. > > It might be possible to use mailing list activity (in [Neutron][LBaaS] in > particular) to generate this list, but also keep in mind that not everyone > who has been active on the mailing list is interested in contributing to > Octavia. For example, while Doug Wiegley has made great contributions to > Neutron LBaaS, it's probably a conflict of interest for him to participate > in Octavia, since he works for a load balancer vendor. > > I do agree that the election should not be conducted by one of the > candidates in any case. What do y'all think, as far as determining the list > of who should be able to vote and/or nominate candidates? > > Thanks, > Stephen > > > > On Thu, Jun 19, 2014 at 3:37 PM, Anita Kuno wrote: > >> On 06/19/2014 06:29 PM, Craig Tracey wrote: >> > I'd like to nominate Brandon Logan and Doug Wiegley as core members. >> > >> > >> > On Thu, Jun 19, 2014 at 6:18 PM, Stephen Balukoff < >> sbaluk...@bluebox.net> >> > wrote: >> > >> >> Howdy y'all! >> >> >> >> Among other things that happened at the Neutron LBaaS mid-cycle >> hackathon, >> >> we have now put together process around, and established Octavia as a >> >> stackforge project. For those just joining us, Octavia is going to >> become >> >> an open-source operator-grade load balancer implementation. It will >> consume >> >> the Neutron LBaaS driver API, and be a consumer of Neutron, Nova, and >> other >> >> OpenStack APIs to deliver load balancing services. (It is not meant to >> >> supplant Neutron LBaaS, or be a general solution which can work with >> any >> >> vendor back-end. Think of it as another load balancer vendor.) >> >> >> >> Anyway, since we want to run this project with the intent of eventually >> >> being incubated, we'd like to get it off the ground using standard >> >> OpenStack methodologies, processes, and best practices. This also means >> >> that we need a PTL and team of core developers who will have +2 voting >> >> status on code and spec reviews for the project. >> >> >> >> I'd like to throw my hat into the ring for PTL. >> >> >> >> I'm not sure how elections on this should work (other than being open). >> >> But in any case, I also think that core developers for this project >> should >> >> probably come from the companies who have been active in the >> discussion of >> >> LBaaS in the last few months who are also interested in contributing >> to the >> >> Octavia project. >> >> >> >> Who would you like to see as PTL and core developers in this project? >> >> >> >> Thanks, >> >> Stephen >> >> >> >> >> >> -- >> >> Stephen Balukoff >> >> Blue Box Group, Inc. >> >> (800)613-4305 x807 >> >> >> >> ___ >> >> 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 >> > >> Technical Governance in OpenStack: >> https://wiki.openstack.org/wiki/Governance >> >> Guidelines for Election Officials: >> https://wiki.openstack.org/wiki/Election_Officiating_Guidelines >> >> I recommend asking or designating someone to act as an election official >> for the election. OpenStack elections need two officials, Stackforge >> elections often have one, though you can have two if you wish. Establish >> which processes you as a group will follow for the election. Part of the >> election official's job is to open nominations. >> >> Congratulations on the new Stackforge project, may you have a good >> election process, >> Anita. >> >> ___ >> 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Octavia] PTL and core team members
Thanks for the link, Anita! These are definitely good guidelines, but there are a couple problems with doing the election exactly as described in the document: It looks like to generate the list of voters, it recommends using the list of people who have committed code to the project in the last year. As this project is just getting bootstrapped, obviously we have no committed code yet. It might be possible to use mailing list activity (in [Neutron][LBaaS] in particular) to generate this list, but also keep in mind that not everyone who has been active on the mailing list is interested in contributing to Octavia. For example, while Doug Wiegley has made great contributions to Neutron LBaaS, it's probably a conflict of interest for him to participate in Octavia, since he works for a load balancer vendor. I do agree that the election should not be conducted by one of the candidates in any case. What do y'all think, as far as determining the list of who should be able to vote and/or nominate candidates? Thanks, Stephen On Thu, Jun 19, 2014 at 3:37 PM, Anita Kuno wrote: > On 06/19/2014 06:29 PM, Craig Tracey wrote: > > I'd like to nominate Brandon Logan and Doug Wiegley as core members. > > > > > > On Thu, Jun 19, 2014 at 6:18 PM, Stephen Balukoff > > > wrote: > > > >> Howdy y'all! > >> > >> Among other things that happened at the Neutron LBaaS mid-cycle > hackathon, > >> we have now put together process around, and established Octavia as a > >> stackforge project. For those just joining us, Octavia is going to > become > >> an open-source operator-grade load balancer implementation. It will > consume > >> the Neutron LBaaS driver API, and be a consumer of Neutron, Nova, and > other > >> OpenStack APIs to deliver load balancing services. (It is not meant to > >> supplant Neutron LBaaS, or be a general solution which can work with any > >> vendor back-end. Think of it as another load balancer vendor.) > >> > >> Anyway, since we want to run this project with the intent of eventually > >> being incubated, we'd like to get it off the ground using standard > >> OpenStack methodologies, processes, and best practices. This also means > >> that we need a PTL and team of core developers who will have +2 voting > >> status on code and spec reviews for the project. > >> > >> I'd like to throw my hat into the ring for PTL. > >> > >> I'm not sure how elections on this should work (other than being open). > >> But in any case, I also think that core developers for this project > should > >> probably come from the companies who have been active in the discussion > of > >> LBaaS in the last few months who are also interested in contributing to > the > >> Octavia project. > >> > >> Who would you like to see as PTL and core developers in this project? > >> > >> Thanks, > >> Stephen > >> > >> > >> -- > >> Stephen Balukoff > >> Blue Box Group, Inc. > >> (800)613-4305 x807 > >> > >> ___ > >> 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 > > > Technical Governance in OpenStack: > https://wiki.openstack.org/wiki/Governance > > Guidelines for Election Officials: > https://wiki.openstack.org/wiki/Election_Officiating_Guidelines > > I recommend asking or designating someone to act as an election official > for the election. OpenStack elections need two officials, Stackforge > elections often have one, though you can have two if you wish. Establish > which processes you as a group will follow for the election. Part of the > election official's job is to open nominations. > > Congratulations on the new Stackforge project, may you have a good > election process, > Anita. > > ___ > 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Octavia] PTL and core team members
Howdy y'all! Among other things that happened at the Neutron LBaaS mid-cycle hackathon, we have now put together process around, and established Octavia as a stackforge project. For those just joining us, Octavia is going to become an open-source operator-grade load balancer implementation. It will consume the Neutron LBaaS driver API, and be a consumer of Neutron, Nova, and other OpenStack APIs to deliver load balancing services. (It is not meant to supplant Neutron LBaaS, or be a general solution which can work with any vendor back-end. Think of it as another load balancer vendor.) Anyway, since we want to run this project with the intent of eventually being incubated, we'd like to get it off the ground using standard OpenStack methodologies, processes, and best practices. This also means that we need a PTL and team of core developers who will have +2 voting status on code and spec reviews for the project. I'd like to throw my hat into the ring for PTL. I'm not sure how elections on this should work (other than being open). But in any case, I also think that core developers for this project should probably come from the companies who have been active in the discussion of LBaaS in the last few months who are also interested in contributing to the Octavia project. Who would you like to see as PTL and core developers in this project? Thanks, Stephen -- Stephen Balukoff Blue Box Group, Inc. (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] TLS support RST document on Gerrit
Samuel, So at the LBaaS hackathon, Dustin, Carlos and I discussed order vs. hostname and we came to the conclusion that we'd be OK with order on the SNI list / SNI Policy, so long as we also make note that individual back-ends may choose to implement this as a hostname hash lookup, based on hostnames embedded in the cert as the CN or x509v3 Subject Alternative Names. In this case, then, we should specifically not make 'hostname' an attribute of the SNI list / SNI policy object because this information will be extracted by the driver / back-end implementation. I think, though, we all still agree that supporting cipher selection criteria is probably beyond the scope of what we think we can reasonably offer in Juno. Back-ends should plan on using sane defaults for the first release, eh. If you're in agreement with the above, could y'all update the spec, and we'll remove our '-1's? https://review.openstack.org/#/c/98640/ Thanks, Stephen On Thu, Jun 19, 2014 at 6:23 AM, Stephen Balukoff wrote: > Hi Samuel, > > Yes, it's more friendly to extract this information on behalf of the user, > but does occasionally break use cases we've seen. It should be possible, > when there is hostname overlap, for the user to specify which certificate > to use. It sounds like the Radware solution uses certificate ordering to > resolve this conflict. > > stunnel requires the user to specify which certs should be used with which > hostnames, and I think balks if you try to repeat a hostname. So in > stunnel's case, conflict resolution happens through user configuration. > > So in both cases, the user specifies some way to do conflict resolution. > > There's not a reason we couldn't do it the Radware way for stunnel. The > algorithm would be: > 1. Order configured certificates based on the 'order' attribute. > 2. One by one in sequence, extract CN and Subject Alternative Names from > the certificates. > 3. If a conflict arises, do not allow certs later in the sequence to > supersede / override hostnames set earlier in the sequence. > > However, I'm not sure it's possible to do the opposite (ie. "stunnel" way) > for Radware and get exactly similar behavior. > > People should be aware that we are potentially catering to one vendor's > needs here by adopting the above conflict resolution / certificate hostname > extraction model. > > In any case, it is probably still very handy to show the list of hostnames > for which each certificate is valid to the user (ie. in UI's or whatever). > > What do people think? > > Stephen > > > On Thu, Jun 19, 2014 at 12:03 AM, Samuel Bercovici > wrote: > >> Hi Stephen, >> >> >> >> The difference is whether the user get to specify hostnames or whether >> this get concluded from the certificate. >> >> I agree, that it might be more friendly if we have an immutable hostname >> field that get cached in lbaas but being read from the certificate and not >> managed by the end user. >> >> >> >> -Sam. >> >> >> >> >> >> >> >> *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net] >> *Sent:* Thursday, June 19, 2014 1:44 AM >> >> *To:* OpenStack Development Mailing List (not for usage questions) >> *Subject:* Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document >> on Gerrit >> >> >> >> So... what I'm hearing here is that we might want to support both a >> 'hostname' and 'order' attribute. Though exact behavior from vendor to >> vendor when there is name overlap is not likely to be consistent. >> >> >> >> Note that while we have seen that corner case, it is unusual... so I'm >> not against having slightly different behavior when there's name overlap >> from vendor to vendor. >> >> >> >> Stephen >> >> >> >> On Wed, Jun 18, 2014 at 2:15 PM, Samuel Bercovici >> wrote: >> >> Hi Stephen, >> >> >> >> Radware Alteon extract the hostname information and the alt >> subjectAltName from the certificate information. >> >> It then do: >> >> 1. Find if there is exact match with the name in the https >> handshake and the ones extracted from the certificate, if there are more >> than a single match, the 1st one in the order will be used >> >> 2. If no match was found than try to use the regexp hostname to >> match, if you have multiple matches, the 1st one will be used >> >> 3. If no match was found than try to use subjectAltName to match. >> I
Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit
Hi Samuel, Yes, it's more friendly to extract this information on behalf of the user, but does occasionally break use cases we've seen. It should be possible, when there is hostname overlap, for the user to specify which certificate to use. It sounds like the Radware solution uses certificate ordering to resolve this conflict. stunnel requires the user to specify which certs should be used with which hostnames, and I think balks if you try to repeat a hostname. So in stunnel's case, conflict resolution happens through user configuration. So in both cases, the user specifies some way to do conflict resolution. There's not a reason we couldn't do it the Radware way for stunnel. The algorithm would be: 1. Order configured certificates based on the 'order' attribute. 2. One by one in sequence, extract CN and Subject Alternative Names from the certificates. 3. If a conflict arises, do not allow certs later in the sequence to supersede / override hostnames set earlier in the sequence. However, I'm not sure it's possible to do the opposite (ie. "stunnel" way) for Radware and get exactly similar behavior. People should be aware that we are potentially catering to one vendor's needs here by adopting the above conflict resolution / certificate hostname extraction model. In any case, it is probably still very handy to show the list of hostnames for which each certificate is valid to the user (ie. in UI's or whatever). What do people think? Stephen On Thu, Jun 19, 2014 at 12:03 AM, Samuel Bercovici wrote: > Hi Stephen, > > > > The difference is whether the user get to specify hostnames or whether > this get concluded from the certificate. > > I agree, that it might be more friendly if we have an immutable hostname > field that get cached in lbaas but being read from the certificate and not > managed by the end user. > > > > -Sam. > > > > > > > > *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net] > *Sent:* Thursday, June 19, 2014 1:44 AM > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document > on Gerrit > > > > So... what I'm hearing here is that we might want to support both a > 'hostname' and 'order' attribute. Though exact behavior from vendor to > vendor when there is name overlap is not likely to be consistent. > > > > Note that while we have seen that corner case, it is unusual... so I'm not > against having slightly different behavior when there's name overlap from > vendor to vendor. > > > > Stephen > > > > On Wed, Jun 18, 2014 at 2:15 PM, Samuel Bercovici > wrote: > > Hi Stephen, > > > > Radware Alteon extract the hostname information and the alt subjectAltName > from the certificate information. > > It then do: > > 1. Find if there is exact match with the name in the https handshake > and the ones extracted from the certificate, if there are more than a > single match, the 1st one in the order will be used > > 2. If no match was found than try to use the regexp hostname to > match, if you have multiple matches, the 1st one will be used > > 3. If no match was found than try to use subjectAltName to match. If > you have multiple matches, the 1st one will be used > > 4. If no match than use default certificate > > > > -Sam. > > > > > > > > > > *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net] > *Sent:* Thursday, June 19, 2014 12:03 AM > > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document > on Gerrit > > > > Hi Evg, > > > > I do not think stunnel supports an "ordered list" without hostnames. Since > we're talking about making the reference implementation use stunnel for TLS > termination, then this seems like it's important to support its behavioral > model. > > > > It is possible to extract hostnames from the CN and x509v3 Subject > Alternative Names in the certs, but, as has been discussed previously, > these can overlap, and it's not always reliable to rely on this data from > the certs themselves. So, while I have nothing against having an ordered > certificate list, stunnel won't use the order here, and stunnel will likely > have unexpected behavior if hostnames are duplicated. > > > > Would it work for Radware to simply order the (unique) hostnames > alphabetically, and put any wildcard certificates at the end of the list? > > > > Also, while I'm loathe to ask for details on a proprietary s
Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit
So... what I'm hearing here is that we might want to support both a 'hostname' and 'order' attribute. Though exact behavior from vendor to vendor when there is name overlap is not likely to be consistent. Note that while we have seen that corner case, it is unusual... so I'm not against having slightly different behavior when there's name overlap from vendor to vendor. Stephen On Wed, Jun 18, 2014 at 2:15 PM, Samuel Bercovici wrote: > Hi Stephen, > > > > Radware Alteon extract the hostname information and the alt subjectAltName > from the certificate information. > > It then do: > > 1. Find if there is exact match with the name in the https handshake > and the ones extracted from the certificate, if there are more than a > single match, the 1st one in the order will be used > > 2. If no match was found than try to use the regexp hostname to > match, if you have multiple matches, the 1st one will be used > > 3. If no match was found than try to use subjectAltName to match. If > you have multiple matches, the 1st one will be used > > 4. If no match than use default certificate > > > > -Sam. > > > > > > > > > > *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net] > *Sent:* Thursday, June 19, 2014 12:03 AM > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document > on Gerrit > > > > Hi Evg, > > > > I do not think stunnel supports an "ordered list" without hostnames. Since > we're talking about making the reference implementation use stunnel for TLS > termination, then this seems like it's important to support its behavioral > model. > > > > It is possible to extract hostnames from the CN and x509v3 Subject > Alternative Names in the certs, but, as has been discussed previously, > these can overlap, and it's not always reliable to rely on this data from > the certs themselves. So, while I have nothing against having an ordered > certificate list, stunnel won't use the order here, and stunnel will likely > have unexpected behavior if hostnames are duplicated. > > > > Would it work for Radware to simply order the (unique) hostnames > alphabetically, and put any wildcard certificates at the end of the list? > > > > Also, while I'm loathe to ask for details on a proprietary system: How > does Radware do SNI *without* hostnames? Isn't that entirely the point of > SNI? Client sends a hostname, and server responds with the certificate that > applies to that hostname? > > > > Thanks, > > Stephen > > > > On Wed, Jun 18, 2014 at 8:00 AM, Evgeny Fedoruk > wrote: > > Hi Stephen, > Regarding your comment related to SNI list management and behavior in the > RST document: > > I understand the need to explicitly specify specific certificates for > specific hostnames. > However we need to deliver lowest common denominator for this feature > which every vendor is able to support > In this case, specifying hostname for certificate will not be supported by > Radware. > The original proposal with ordered certificates list may be the lowest > common denominator for all vendors and we should find out if this is the > case. > If not, managing a simple none-ordered list will probably be the lowest > common denominator. > > With the proposed flavors framework considered, extra SNI management > capabilities may be represented for providers > but meanwhile we should agree on proposal that can be implemented by all > vendors. > What are your thought on this? > > Regarding the SNIPolicy, I agree and will change the document accordingly. > > Thanks, > Evg > > > > > > > -Original Message- > From: Evgeny Fedoruk > Sent: Sunday, June 15, 2014 1:55 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on > Gerrit > > Hi All, > > The document was updated and ready for next review round. > Main things that were changed: > 1. Comments were addressed > 2. No back-end re-encryption supported > 3. Intermediate certificates chain supported > *Opened question: Should chain be stored in same TLS container of > the certificate? > > Please review > Regards, > Evgeny > > > -Original Message- > From: Douglas Mendizabal [mailto:douglas.mendiza...@rackspace.com] > Sent: Wednesday, June 11, 2014 10:22 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST docume
Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit
eviewing the RST doc. > >>> > There are some issues I want to pinpoint final decision on them > >>here, in > >>> ML, before writing it down in the doc. > >>> > Other issues will be commented on the document itself. > >>> > > >>> > 1. Support/No support in JUNO > >>> > Referring to summit's etherpad > >>> https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7, > >>> > a. SNI certificates list was decided to be supported. Was > >>decision made > >>> not to support it? > >>> > Single certificate with multiple domains can only partly address > >>> > the need for SNI, still, different applications on back-end will > >>> > need > >>different > >>> certificates. > >>> > b. Back-end re-encryption was decided to be supported. Was > >>decision > >>> made not to support it? > >>> > c. With front-end client authentication and back-end server > >>> authentication not supported, > >>> > Should certificate chains be supported? > >>> > 2. Barbican TLS containers > >>> > a. TLS containers are immutable. > >>> > b. TLS container is allowed to be deleted, always. > >>> >i. > >>Even when it is used by LBaaS VIP > >>> listener (or other service). > >>> > ii. > >>Meta data on TLS container will > >>> help tenant to understand that container is in use by LBaaS > >>service/VIP > >>> listener > >>> > iii. > >>If every VIP listener will "register" > >>> itself in meta-data while retrieving container, how that > >>"registration" will be > >>> removed when VIP listener stops using the certificate? > >>> > > >>> > Please comment on these points and review the document on gerrit > >>> > (https://review.openstack.org/#/c/98640) > >>> > I will update the document with decisions on above topics. > >>> > > >>> > Thank you! > >>> > Evgeny > >>> > > >>> > > >>> > From: Evgeny Fedoruk > >>> > Sent: Monday, June 09, 2014 2:54 PM > >>> > To: OpenStack Development Mailing List (not for usage questions) > >>> > Subject: [openstack-dev] [Neutron][LBaaS] TLS support RST document > >>on > >>> > Gerrit > >>> > > >>> > Hi All, > >>> > > >>> > A Spec. RST document for LBaaS TLS support was added to Gerrit > >>> > for review > >>> > https://review.openstack.org/#/c/98640 > >>> > > >>> > You are welcome to start commenting it for any open discussions. > >>> > I tried to address each aspect being discussed, please add > >>> > comments > >>> about missing things. > >>> > > >>> > Thanks, > >>> > Evgeny > >>> > > >>> > ___ > >>> > 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 > >>> > >>> ___ > >>> 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 > > > > > >___ > >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 > ___ > 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Tuesday, June 10, 2014 2:53 PM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS > Integration Ideas > >> In any case, it strikes me as misleading to have an explicit delete > command sent to Barbican not have the effect of making the key unusable in > all other contexts. It would be less surprising behavior, IMO, to have a > deleted barbican container result in connected load balancing services > breaking. (Though without notification to LBaaS, the connected service > might break weeks or months after the key disappeared from barbican, which > would be more surprising behavior.) > > Since a delete in barbican will not affect neutron/lbaas, and since most > backends will have had to make their own copy of the key at lb provision > time, the barbican delete will not result in lbaas breaking, I think. The > shadow copy would only get used if the lb had to be re-provisioned for some > reason before it was given a new key id, which seems a fair bit of > complexity for what is gained. > > doug > > > From: Stephen Balukoff > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Tuesday, June 10, 2014 at 1:47 PM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS > Integration Ideas > > Adam-- > > Wouldn't the user see the duplicate key/cert copy in their barbican > interface, or are you proposing storing these secrets in a > not-assigned-to-the-tenant kind of way? > > In any case, it strikes me as misleading to have an explicit delete > command sent to Barbican not have the effect of making the key unusable in > all other contexts. It would be less surprising behavior, IMO, to have a > deleted barbican container result in connected load balancing services > breaking. (Though without notification to LBaaS, the connected service > might break weeks or months after the key disappeared from barbican, which > would be more surprising behavior.) > > Personally, I like your idea, as I think most of our users would rather > have LBaaS issue warnings when the user has done something stupid like this > rather than break entirely. I know our support staff would rather it > behaved this way. > > What's your proposal for cleaning up copied secrets when they're > actually no longer in use by any LB? > > Stephen > > > On Tue, Jun 10, 2014 at 12:04 PM, Adam Harwell > wrote: > >> So, it looks like any sort of validation on Deletes in Barbican is going >> to be a no-go. I'd like to propose a third option, which might be the >> safest route to take for LBaaS while still providing some of the >> convenience of using Barbican as a central certificate store. Here is a >> diagram of the interaction sequence to create a loadbalancer: >> http://bit.ly/1pgAC7G >> >> Summary: Pass the Barbican "TLS Container ID" to the LBaaS create call, >> get the container from Barbican, and store a "shadow-copy" of the >> container again in Barbican, this time on the LBaaS service account. >> The secret will now be duplicated (it still exists on the original tenant, >> but also exists on the LBaaS tenant), but we're not talking about a huge >> amount of data here -- just a few kilobytes. With this approach, we retain >> most of the advantages we wanted to get from using Barbican -- we don't >> need to worry about taking secret data through the LBaaS API (we still >> just take a barbicanID from the user), and the user can still use a single >> barbicanID (the original one they created -- the copies are invisible to >> them) when passing their TLS info to other services. We gain the >> additional advantage that it no longer matters what happens to the >> original TLS container -- it could be deleted and it would not impact our >> service. >> >> What do you guys think of that option? >> >> >> >> As an addendum (not saying we necessarily want to do this, but it's an >> option), we COULD retain both the original and the copied barbicanID in >> our database and attempt to fetch them in that order when we need the TLS >> info again, which would allow us to do some alerting if the user does >> delete their key. For example: the user has delet
Re: [openstack-dev] [Neutron][LBaaS] dealing with M:N relashionships for Pools and Listeners
Hi Jorge, On Fri, Jun 6, 2014 at 12:48 PM, Jorge Miramontes < jorge.miramon...@rackspace.com> wrote: > > 1) We are assuming that load balancers can only operate on one update at a > time correct? I.E. We are not allowing multiple updates to occur > concurrently? Whatever the case on this I advocate that we do NOT allow > concurrent modification as complexity of the system increases dramatically > and the gain is very small since load balancers are usually configured > upon create and then rarely updated over their lifetime. > I agree. The only exception to this rule I would say is that operations which delete objects should be allowed to override any queued up reconfiguration. (If a resource gets into a strange state where it isn't otherwise alterable, it's handy to be able to delete it without operator intervention.) 2) It appears that sharing objects is causing complexity to creep in the > deeper the conversations are getting. For example, managing object > statuses seems like a nightmare! That said, does the fundamental rationale > for sharing objects outweigh the simplicity of not sharing objects? > I wouldn't say it's a nightmare, but it certainly isn't trivial, and some solutions to this problem may reveal more about the back-end than we really want to reveal to a user. This particular complication only comes into play when "status" becomes a meaningful attribute of the object. (For example, "status" is meaningless on logical constructs like L7Policies or TLS Certificates.) Do you see complications other than status and stats collection becoming an issue here? Having said this, it would be possible to define most things with a 'status' from the load balancer down in the object tree as being non-share-able, I suppose. It does simplify what needs to be done algorithmically by quite a bit, but does complicate the user experience when it comes to setting up and maintaining load balancer related configuration. I will say: I'm a little reluctant to change horses at this stage in the race, though. I feel like we have discussed this pretty thoroughly in the past and am not sure it's appropriate to re-hash those discussions now. What you're talking about are essentially core object-model level changes. (Obviously, others should feel free to disagree with me about whether it makes sense to revisit this discussion yet again.) > I understand that we've been diligently working on the API revision but I > wanted to take a step back and look at the goal we are trying to solve and > weigh the perceived need for complexity (i.e "flexibility" in the API) vs > a simpler solution. > > 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] Barbican Neutron LBaaS Integration Ideas
questions)" < > openstack-dev@lists.openstack.org> > Date: Tuesday, June 10, 2014 3:42 PM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS > Integration Ideas > > > Doug: The reasons a LB might be reprovisioned are fairly important — > mostly around HA, for fail overs or capacity — exactly the times we're > trying avoid a failure. > > Certainly the ticking time bomb is a bad idea, but HA seems cleaner to > do in the backend, rather than at the openstack API level (the dangling > reference doesn’t kick in until the lbaas api is used to accomplish that > failover.) And the lbaas api also doesn’t have any provisions for helping > to shuffle for capacity, so that also becomes a backend issue. And the > backend won’t be natively dealing with a barbican reference. > > > However, couple this with service VM’s, and I guess the issue pops back > into the forefront. This is going to be an issue that everyone using ssl > certs in barbican is going to have, so it seems we’re applying a band-aid > in the wrong place. > > Doug > > > From: Adam Harwell > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Tuesday, June 10, 2014 at 2:19 PM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS > Integration Ideas > > Doug: The reasons a LB might be reprovisioned are fairly important — > mostly around HA, for fail overs or capacity — exactly the times we're > trying avoid a failure. > > Stephen: yes, I am talking about storing the copy in a non-tenant way > (on the tenant-id for the LBaaS Service Account, not visible to the user). > We would have to delete our shadow-copy when the loadbalancer was updated > with a new barbicanID by the user, and make a copy of the new container to > take its place. > Also, yes, I think it would be quite surprising (and far from ideal) when > the LB you set up breaks weeks or months later when an HA event occurs and > you haven't actually made any "changes" in quite a long time. > Unfortunately, "making the key unusable in all other contexts" on a > Barbican delete isn't really an option, so this is the best fallback I can > think of. > > --Adam > > https://keybase.io/rm_you > > > From: Doug Wiegley > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Tuesday, June 10, 2014 2:53 PM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS > Integration Ideas > >> In any case, it strikes me as misleading to have an explicit delete > command sent to Barbican not have the effect of making the key unusable in > all other contexts. It would be less surprising behavior, IMO, to have a > deleted barbican container result in connected load balancing services > breaking. (Though without notification to LBaaS, the connected service > might break weeks or months after the key disappeared from barbican, which > would be more surprising behavior.) > > Since a delete in barbican will not affect neutron/lbaas, and since most > backends will have had to make their own copy of the key at lb provision > time, the barbican delete will not result in lbaas breaking, I think. The > shadow copy would only get used if the lb had to be re-provisioned for some > reason before it was given a new key id, which seems a fair bit of > complexity for what is gained. > > doug > > > From: Stephen Balukoff > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Tuesday, June 10, 2014 at 1:47 PM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS > Integration Ideas > > Adam-- > > Wouldn't the user see the duplicate key/cert copy in their barbican > interface, or are you proposing storing these secrets in a > not-assigned-to-the-tenant kind of way? > > In any case, it strikes me as misleading to have an explicit delete > command sent to Barbican not have the effect of making the key unusable in > all other contexts. It would be less s
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
I get the impression that the "right place" that the barbican team wants to support is in the eventing system they're already planning on implementing. But I understand that's also not on tap for Juno release, which means if we want to use barbican in how we do TLS termination on LBaaS, we need an alternate solution for at least the Juno release cycle. So far, the suggestion proposed by Adam is the best I've heard to handle this kind of thing gracefully. On Tue, Jun 10, 2014 at 1:42 PM, Doug Wiegley wrote: > > Doug: The reasons a LB might be reprovisioned are fairly important — > mostly around HA, for fail overs or capacity — exactly the times we're > trying avoid a failure. > > Certainly the ticking time bomb is a bad idea, but HA seems cleaner to > do in the backend, rather than at the openstack API level (the dangling > reference doesn’t kick in until the lbaas api is used to accomplish that > failover.) And the lbaas api also doesn’t have any provisions for helping > to shuffle for capacity, so that also becomes a backend issue. And the > backend won’t be natively dealing with a barbican reference. > > However, couple this with service VM’s, and I guess the issue pops back > into the forefront. This is going to be an issue that everyone using ssl > certs in barbican is going to have, so it seems we’re applying a band-aid > in the wrong place. > > Doug > > > From: Adam Harwell > > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Tuesday, June 10, 2014 at 2:19 PM > > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS > Integration Ideas > > Doug: The reasons a LB might be reprovisioned are fairly important — > mostly around HA, for fail overs or capacity — exactly the times we're > trying avoid a failure. > > Stephen: yes, I am talking about storing the copy in a non-tenant way > (on the tenant-id for the LBaaS Service Account, not visible to the user). > We would have to delete our shadow-copy when the loadbalancer was updated > with a new barbicanID by the user, and make a copy of the new container to > take its place. > Also, yes, I think it would be quite surprising (and far from ideal) when > the LB you set up breaks weeks or months later when an HA event occurs and > you haven't actually made any "changes" in quite a long time. > Unfortunately, "making the key unusable in all other contexts" on a > Barbican delete isn't really an option, so this is the best fallback I can > think of. > > --Adam > > https://keybase.io/rm_you > > > From: Doug Wiegley > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Tuesday, June 10, 2014 2:53 PM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS > Integration Ideas > >> In any case, it strikes me as misleading to have an explicit delete > command sent to Barbican not have the effect of making the key unusable in > all other contexts. It would be less surprising behavior, IMO, to have a > deleted barbican container result in connected load balancing services > breaking. (Though without notification to LBaaS, the connected service > might break weeks or months after the key disappeared from barbican, which > would be more surprising behavior.) > > Since a delete in barbican will not affect neutron/lbaas, and since most > backends will have had to make their own copy of the key at lb provision > time, the barbican delete will not result in lbaas breaking, I think. The > shadow copy would only get used if the lb had to be re-provisioned for some > reason before it was given a new key id, which seems a fair bit of > complexity for what is gained. > > doug > > > From: Stephen Balukoff > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Tuesday, June 10, 2014 at 1:47 PM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS > Integration Ideas > > Adam-- > > Wouldn't the user see the duplicate key/cert copy in their barbican > interface, or are you proposing storing these secrets in a > not-assigned-to-the-tenant kind
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
Hi Adam, If nothing else, we could always write a "garbage collector" process which periodically scans for shadow containers that are not in use by any listeners anymore and cleans them up. I suppose that's actually not a difficult problem to solve. Anyway, yes, I'm liking your suggestion quite a bit: It leaves barbican and LBaaS neatly de-coupled, and prevents a ticking time bomb from exploding in the face of a user who deletes a container they didn't know was still in use. Stephen On Tue, Jun 10, 2014 at 1:19 PM, Adam Harwell wrote: > Doug: The reasons a LB might be reprovisioned are fairly important — > mostly around HA, for fail overs or capacity — exactly the times we're > trying avoid a failure. > > Stephen: yes, I am talking about storing the copy in a non-tenant way > (on the tenant-id for the LBaaS Service Account, not visible to the user). > We would have to delete our shadow-copy when the loadbalancer was updated > with a new barbicanID by the user, and make a copy of the new container to > take its place. > Also, yes, I think it would be quite surprising (and far from ideal) when > the LB you set up breaks weeks or months later when an HA event occurs and > you haven't actually made any "changes" in quite a long time. > Unfortunately, "making the key unusable in all other contexts" on a > Barbican delete isn't really an option, so this is the best fallback I can > think of. > > --Adam > > https://keybase.io/rm_you > > > From: Doug Wiegley > > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Tuesday, June 10, 2014 2:53 PM > > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS > Integration Ideas > >> In any case, it strikes me as misleading to have an explicit delete > command sent to Barbican not have the effect of making the key unusable in > all other contexts. It would be less surprising behavior, IMO, to have a > deleted barbican container result in connected load balancing services > breaking. (Though without notification to LBaaS, the connected service > might break weeks or months after the key disappeared from barbican, which > would be more surprising behavior.) > > Since a delete in barbican will not affect neutron/lbaas, and since most > backends will have had to make their own copy of the key at lb provision > time, the barbican delete will not result in lbaas breaking, I think. The > shadow copy would only get used if the lb had to be re-provisioned for some > reason before it was given a new key id, which seems a fair bit of > complexity for what is gained. > > doug > > > From: Stephen Balukoff > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Tuesday, June 10, 2014 at 1:47 PM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS > Integration Ideas > > Adam-- > > Wouldn't the user see the duplicate key/cert copy in their barbican > interface, or are you proposing storing these secrets in a > not-assigned-to-the-tenant kind of way? > > In any case, it strikes me as misleading to have an explicit delete > command sent to Barbican not have the effect of making the key unusable in > all other contexts. It would be less surprising behavior, IMO, to have a > deleted barbican container result in connected load balancing services > breaking. (Though without notification to LBaaS, the connected service > might break weeks or months after the key disappeared from barbican, which > would be more surprising behavior.) > > Personally, I like your idea, as I think most of our users would rather > have LBaaS issue warnings when the user has done something stupid like this > rather than break entirely. I know our support staff would rather it > behaved this way. > > What's your proposal for cleaning up copied secrets when they're > actually no longer in use by any LB? > > Stephen > > > On Tue, Jun 10, 2014 at 12:04 PM, Adam Harwell > wrote: > >> So, it looks like any sort of validation on Deletes in Barbican is going >> to be a no-go. I'd like to propose a third option, which might be the >> safest route to take for LBaaS while still providing some of the >> convenience of using Barbican as a central certificate store. Here is a >> diagram of the
Re: [openstack-dev] [Neutron] Implementing new LBaaS API
ot have to rename > > >> > > unchanged resources and models > > >> > > CONS: > > >> > > -May end up being confusing to an end-user. > > >> > > -Separation of old api and new api is less clear -Deprecating and > > >> > > removing old api and object model will take a bit more work -This > > >> > > is basically API versioning the wrong way > > >> > > > > >> > > 2) A new extension and plugin are created for the new API and > > >> > > object model. Each API would live side by side. New API would > > >> > > need to have different names for resources and object models from > > >> > > Old API resources and object models. > > >> > > PROS: > > >> > > -Clean demarcation point between old and new -No translation > > >> > > layer needed -Do not need to modify existing API and object > > >> > > model, no new bugs -Drivers do not need to be immediately > > >> > > modified -Easy to deprecate and remove old API and object model > > >> > > later > > >> > > CONS: > > >> > > -Separate extensions and object model will be confusing to > > >> > > end-users -Code reuse by copy paste since old extension and > > >> > > plugin will be deprecated and removed. > > >> > > -This is basically API versioning the wrong way > > >> > > > > >> > > Now if #2 is chosen to be feasible and acceptable then there are > > >> > > a number of ways to actually do that. I won't bring those up > > >> > > until a clear decision is made on which strategy above is the > most acceptable. > > >> > > > > >> > Thanks for sending this out Brandon. I'm in favor of option #2 > > >> > above, especially considering the long-term plans to remove LBaaS > > >> > from Neutron. That approach will help the eventual end goal there. > > >> > I am also curious on what others think, and to this end, I've added > > >> > this as an agenda item for the team meeting next Monday. Brandon, > > >> > it would be great to get you there for the part of the meeting > > >> > where we'll discuss this. > > >> > > > >> > Thanks! > > >> > Kyle > > >> > > > >> > > Thanks, > > >> > > Brandon > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > ___ > > >> > > 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 > > >> > > >> ___ > > >> 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 > > > > > > ___ > > > 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 > > > > ___ > > 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 > -- 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] TLS support RST document on Gerrit
Hi Evgeny, Comments inline. On Tue, Jun 10, 2014 at 4:13 AM, Evgeny Fedoruk wrote: > Hi All, > > > > Carlos, Vivek, German, thanks for reviewing the RST doc. > > There are some issues I want to pinpoint final decision on them here, in > ML, before writing it down in the doc. > > Other issues will be commented on the document itself. > > > > 1. Support/No support in JUNO > > Referring to summit’s etherpad > https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7, > > a. SNI certificates list was decided to be supported. Was decision > made not to support it? > Single certificate with multiple domains can only partly address the need > for SNI, still, different applications > on back-end will need different certificates. > SNI support is a "show stopper" for us if it's not there. We have too many production services which rely on SNI working for us not to have this feature going forward. I'm not sure I understand what you're proposing when you say "Single certificate with multiple domains can only partly address the need for SNI, still, different applications on back-end will need different certificates." In order to "fully" support SNI, you simply need to be able to specify alternate certificate/key(s) to use indexed by the hostname with which the non-default certificate(s) correspond. And honestly, if you're going to implement TLS termination support at all, then adding SNI is a pretty trivial next step. b. Back-end re-encryption was decided to be supported. Was decision > made not to support it? > So, some operators have said they need this eventually, but I think the plan was to hold off on both re-encryption and any kind of client certificate authentication in this release cycle. I could be remembering the discussion on this incorrectly, though, so others should feel free to correct me on this. c. With front-end client authentication and back-end server > authentication not supported, > Should certificate chains be supported? > Certificate chains are a different beast entirely. What I mean by that is: Any given front-end (ie. "server") certificate issued by an authoritative CA today may need intermediate certificates supplied for most browsers to trust the issued certificate implicitly. (Most do, in my experience.) Therefore, in order to effectively do TLS offload at all, we need to be able to supply an intermediate CA chain which will be supplied with the server cert when a client connects to the service. If you're talking about the CA bundle or chain which will be used to verify client certificates when we offer that feature... then no, we don't need that until we offer the feature. > 2. Barbican TLS containers > > a. TLS containers are immutable. > > b. TLS container is allowed to be deleted, always. > >i. Even > when it is used by LBaaS VIP listener (or other service). > > ii. Meta > data on TLS container will help tenant to understand that container is in > use by LBaaS service/VIP listener > > iii. If > every VIP listener will “register” itself in meta-data while retrieving > container, how that “registration” will be removed when VIP listener stops > using the certificate? > So, there's other discussion of these points in previous replies in this thread, but to summarize: * There are multiple strategies for handling barbican container deletion, and I favor the one suggested by Adam of creating "shadow" versions of any referenced containers. I specifically do not like the one which allows for dangling references, as this could mean the associated listener breaks weeks or months after the barbican container was deleted (assuming no eventing system is used, which it sounds like people are against.) * Meta data on container is a good idea, IMO. Perhaps we might consider simply leaving "generic" meta-data which is essentially a note to the barbican system, or any GUI referencing the cert to check with the LBaaS service to see which listeners are using the cert? This wouldn't need to be cleaned up, because if the container actually isn't in use by LBaaS anymore, then LBaaS would simply respond that nothing is using the cert anymore. > > > Please comment on these points and review the document on gerrit ( > https://review.openstack.org/#/c/98640) > > I will update the document with decisions on above topics. > I shall try to make sure I have time to review the document later today or tomorrow. 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] TLS support RST document on Gerrit
tener stops > using the certificate? > > > > Please comment on these points and review the document on gerrit ( > https://review.openstack.org/#/c/98640) > > I will update the document with decisions on above topics. > > > > Thank you! > > Evgeny > > > > > > From: Evgeny Fedoruk > > Sent: Monday, June 09, 2014 2:54 PM > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: [openstack-dev] [Neutron][LBaaS] TLS support RST document on > Gerrit > > > > Hi All, > > > > A Spec. RST document for LBaaS TLS support was added to Gerrit for > review > > https://review.openstack.org/#/c/98640 > > > > You are welcome to start commenting it for any open discussions. > > I tried to address each aspect being discussed, please add comments > about missing things. > > > > Thanks, > > Evgeny > > > > ___ > > 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 > -- 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] Barbican Neutron LBaaS Integration Ideas
Adam-- Wouldn't the user see the duplicate key/cert copy in their barbican interface, or are you proposing storing these secrets in a not-assigned-to-the-tenant kind of way? In any case, it strikes me as misleading to have an explicit delete command sent to Barbican not have the effect of making the key unusable in all other contexts. It would be less surprising behavior, IMO, to have a deleted barbican container result in connected load balancing services breaking. (Though without notification to LBaaS, the connected service might break weeks or months after the key disappeared from barbican, which would be more surprising behavior.) Personally, I like your idea, as I think most of our users would rather have LBaaS issue warnings when the user has done something stupid like this rather than break entirely. I know our support staff would rather it behaved this way. What's your proposal for cleaning up copied secrets when they're actually no longer in use by any LB? Stephen On Tue, Jun 10, 2014 at 12:04 PM, Adam Harwell wrote: > So, it looks like any sort of validation on Deletes in Barbican is going > to be a no-go. I'd like to propose a third option, which might be the > safest route to take for LBaaS while still providing some of the > convenience of using Barbican as a central certificate store. Here is a > diagram of the interaction sequence to create a loadbalancer: > http://bit.ly/1pgAC7G > > Summary: Pass the Barbican "TLS Container ID" to the LBaaS create call, > get the container from Barbican, and store a "shadow-copy" of the > container again in Barbican, this time on the LBaaS service account. > The secret will now be duplicated (it still exists on the original tenant, > but also exists on the LBaaS tenant), but we're not talking about a huge > amount of data here -- just a few kilobytes. With this approach, we retain > most of the advantages we wanted to get from using Barbican -- we don't > need to worry about taking secret data through the LBaaS API (we still > just take a barbicanID from the user), and the user can still use a single > barbicanID (the original one they created -- the copies are invisible to > them) when passing their TLS info to other services. We gain the > additional advantage that it no longer matters what happens to the > original TLS container -- it could be deleted and it would not impact our > service. > > What do you guys think of that option? > > > > As an addendum (not saying we necessarily want to do this, but it's an > option), we COULD retain both the original and the copied barbicanID in > our database and attempt to fetch them in that order when we need the TLS > info again, which would allow us to do some alerting if the user does > delete their key. For example: the user has deleted their key because it > was compromised, but they forgot they used it on their loadbalancer -> a > failover event occurs and we attempt to fetch the info from Barbican -> > the first fetch fails, but the second fetch to our copy succeeds -> the > failover of the LB is successful, and we send an alert to notify the user > that their LB is using TLS info that has been deleted from Barbican. > > > --Adam > > > https://keybase.io/rm_you > > > > > > On 6/10/14 6:21 AM, "Clark, Robert Graham" wrote: > > >It looks like this has come full circle and we are back at the simplest > >case. > > > ># Containers are immutable > ># Changing a cert means creating a new container and, when ready, > >pointing LBaaS at the new container > > > >This makes a lot of sense to me, it removes a lot of handholding and > >keeps Barbican and LBaaS nicely decoupled. It also keeps certificate > >lifecycle management firmly in the hands of the user, which imho is a > >good thing. With this model it¹s fairly trivial to provide guidance / > >additional tooling for lifecycle management if required but at the same > >time the simplest case (I want a cert and I want LBaaS) is met without > >massive code overhead for edge-cases. > > > > > >From: Vijay Venkatachalam > >mailto:vijay.venkatacha...@citrix.com>> > >Reply-To: OpenStack List > > openstack-...@lists.openstack.or > >g>> > >Date: Tuesday, 10 June 2014 05:48 > >To: OpenStack List > > openstack-...@lists.openstack.or > >g>> > >Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS > >Integration Ideas > > > > > >My vote is for option #2 (without the registration). It is simpler to > >start with this approach. How is delete handled though? > > > >Ex. What is the expectation when user attempts to d
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
Weighing in here: I'm all for option #2 as well. Stephen On Mon, Jun 9, 2014 at 4:42 PM, Clint Byrum wrote: > Excerpts from Douglas Mendizabal's message of 2014-06-09 16:08:02 -0700: > > Hi all, > > > > I’m strongly in favor of having immutable TLS-typed containers, and very > > much opposed to storing every revision of changes done to a container. I > > think that storing versioned containers would add too much complexity to > > Barbican, where immutable containers would work well. > > > > Agree completely. Create a new one for new values. Keep the old ones > while they're still active. > > > > > I’m still not sold on the idea of registering services with Barbican, > even > > though (or maybe especially because) Barbican would not be using this > data > > for anything. I understand the problem that we’re trying to solve by > > associating different resources across projects, but I don’t feel like > > Barbican is the right place to do this. > > > > Agreed also, this is simply not Barbican or Neutron's role. Be a REST > API for secrets and networking, not all dancing all singing nannies that > prevent any possibly dangerous behavior with said API's. > > > It seems we’re leaning towards option #2, but I would argue that > > orchestration of services is outside the scope of Barbican’s role as a > > secret-store. I think this is a problem that may need to be solved at a > > higher level. Maybe an openstack-wide registry of dependend entities > > across services? > > An optional openstack-wide registry of depended entities is called > "Heat". > > ___ > 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 ___ 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 around statistics and billing
Hi Jorge, This thread as started mostly to try to determine what people are actually after, as far as stats collection goes. Surprisingly (to me at least), it doesn't look like we need all that much to meet the needs of those who have responded to this thread thus far. In any case, my sights are set on preparation for next week's hack-a-thon, and in any case I don't see stats gathering as a high priority for this group right now. (Though basic stats will need to happen before we can consider the service "minimally viable," IMO.) In any case, I'm seeing nothing anyone is asking for, stats-wise, which is going to cause problems for us as we continue on our current course developing LBaaS. And having this thread to look back on when it comes time to actually solve the stats problem will be a good thing, eh. Stephen On Fri, Jun 6, 2014 at 11:35 AM, Jorge Miramontes < jorge.miramon...@rackspace.com> wrote: > Hey Stephen, > > What we really care about are the following: > > - Inbound bandwidth (bytes) > - Outbound bandwidth (bytes) > - "Instance" Uptime (requires create/delete events) > > Just to note our current LBaaS implementation at Rackspace keeps track of > when features are enabled/disabled. For example, we have markers for when > SSL is turned on/off, markers for when we suspend/unsuspend load > balancers, etc. Some of this stuff is used for tracking purposes, some of > it is used for billing purposes and some of it used for both purposes. We > also keep track of all user initiated API requests to help us out when > issues arise. > > From my experience building usage collection systems just know it is not a > trivial task, especially if we need to track events. One good tip is to be > as explicit as possible and as granular as possible. Being implicit causes > bad things to happen. Also, if we didn't have UDP as a protocol I would > recommend using Hadoop's map reduce functionality to get accurate > statistics by map-reducing request logs. > > I would not advocate tracking per node statistics as the user can track > that information by themselves if they really want to. We currently, don't > have any customers that have asked for this feature. > > If you want to tackle the usage collection problem for Neutron LBaaS I > would be glad to help as I've got quite a bit of experience in this > subject matter. > > Cheers, > --Jorge > > > > > From: , German > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > > Date: Tuesday, June 3, 2014 5:20 PM > To: "OpenStack Development Mailing List (not for usage questions)" > > Subject: Re: [openstack-dev] [Neutron][LBaaS] Requirements around > statistics and billing > > > >Hi Stephen, > > > >We would like all those numbers as well > >J > > > >Additionally, we measure: > >· > >When a lb instance was created, deleted, etc. > >· > >For monitoring we ³ping² a load balancers health check and report/act on > >the results > >· > >For user¹s troubleshooting we make the haproxy logs available. Which > >contain connection information like from, to, duration, protocol, status > >(though > > we frequently have been told that this is not really useful for > >debuggingŠ) and of course having that more gui-fied would be neat > > > >German > > > > > > > >From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] > > > >Sent: Tuesday, May 27, 2014 8:22 PM > >To: OpenStack Development Mailing List (not for usage questions) > >Subject: [openstack-dev] [Neutron][LBaaS] Requirements around statistics > >and billing > > > > > >Hi folks! > > > > > >We have yet to have any kind of meaningful discussion on this list around > >load balancer stats (which, I presume to include data that will > >eventually need to be consumed by a billing system). I'd like to get the > >discussion started here, > > as this will have significant meaning for how we both make this data > >available to users, and how we implement back-end systems to be able to > >provide this data. > > > > > > > >So! What kinds of data are people looking for, as far as load balancer > >statistics. > > > > > > > >For our part, as an absolute minimum we need the following per > >loadbalancer + listener combination: > > > > > > > >* Total bytes transferred in for a given period > > > >* Total bytes transferred out for a given period > > > > > > > >Our product and billing people I'm sure would like the following as
Re: [openstack-dev] Your suggestions in the BP
Hi ya'll! Comments inline: On Sun, Jun 1, 2014 at 1:09 PM, Brandon Logan wrote: > Hi Eugene and Sam, > > On Sun, 2014-06-01 at 12:07 +0400, Eugene Nikanorov wrote: > > Hi Sam, > > > > Eugene, please comment on the migration process bellow. > > > > I think that closing down the "status" handling should be done > > in phase 1. > > I don't mind. If you're talking about provisioning status then such > > status (if we're still going to maintain it per each kind of object) > > goes to various associations: loadbalancer-listener, or > > loadbalancer-listener-pool, etc. > > Not a big deal of course, it was just my initial intent to limit phase > > #1 as much as possible. > > I was hoping to limit it as well to keep it focused on just the > refactoring portion. I didn't want the scope to include all new > features and changes under the sun. It also makes reviewing much > simpler. > I'm OK with limiting scope here so long as we don't implement something that is effectively "forward compatible" with whatever we will probably want to do in the future. (So, having a discussion around this is probably worthwhile.) To phrase this another way, what consumes the 'status' information, and what do they really want to know? > > > > > > > Missing to do so, will create tests and other depending > > workflows that assume the "current" status field, which will > > add a technology debt to this new code. > > I'd say it would depend on the strategy options you're suggestion > > below. > > As far as bw compatibility is concerned (if it's concerned at all), we > > have to support existing status field, so that would not be any > > additional debt. > > > > > > Migration and co-existence: > > I think that it would be better to have the new object model > > and API done in a way that does not "break" existing code, and > > then switch the "old" api to redirect to the "new" api. > > Basically this means creating another lbaas plugin, that expose > > existing lbaas api extension. > > I'm not sure how this can be done considering the difference between > > new proposed api and existing api. > > > > This might be done in one of the two ways bellow: > > 1. Rename all objects in the "new" api so you have a clear > > demarcation point. This might be sufficient. > > I'm not sure how this could be done, can you explain? > > I actually would consider changing the prefix to /v3/ to not to deal > > with any renamings, that would require some minor refactoring on > > extension framework side. > His suggestion in the BP was to rename pool, healthmonitor, and member > to group, healthcheck, and node respectively. Since loadbalancer and > listener are already new those don't have to be renamed. This way the > old object models and db tables remain intact and the old API can still > function as before. > > > > 2. Copy the existing LBaaS "extension" and create a > > "new-lbaas" extension with new object names, then create a > > "new old lbaas" extension that has the "old API" but redirect > > to the "new API" > > I also don't fully understand this, please explain. > I need more clarification on this as well. Sounds like you're saying to > create a lbaas extension v2 with the new object names. Then copy the > existing lbaas extension and change it to redirect to the v2 extension. > If that is the case, why create a "new old lbaas" and just change the > "old lbaas" extension? > > > > > > > > Doing 2, can allow "co-existence" of old code with old drivers > > until new code with new drivers can take its place. > > New extension + new plugin, is that what you are suggesting? To me it > > would be the cleanest and the most simple way to execute the > > transition, but... i'm not sure it was a consensus on design session. > > I agree this would be the cleanest but I was under the impression this > was not an accepted way to go. I'd honestly prefer a v2 extension and > v2 plugin. This would require different names for the object model and > db tables since you don't want the old api and new api sharing the same > tables. We can either append v2 to the names or rename them entirely. > Sam suggested group for pool, healthcheck
Re: [openstack-dev] [Neutron][LBaaS] dealing with M:N relashionships for Pools and Listeners
istener? > No-- I mean that with object re-use, we have only one way to set the admin_state for a shared object, and therefore disabling member 'M' disables it for all connected pools and listeners. I specifically mean that 'admin status' changes of child objects do not affect the 'admin status' of parent objects, though it will (briefly) affect the generic 'status' of the parents as the admin state of the child gets propagated through the connected tree. Sorry, it's early... clear as mud still? :P > > > > > I do not think it makes sense to propagate to all child objects. For > > example, disabling a listener should not disable all the pools it > > references. > > > > And by 'propagate' here I mean that config changes are pushed to all > > affected listeners and load balancers-- not that we actually update > > all parents to be 'ADMIN_STATUS_DOWN' or something. Does this make > > sense to you? > > Propogating to child objects would be bad with shared listeners and > pools. > Sorry, I don't think that's what I'm suggesting. Does my explanation above shed more light on this? > > > > > o Do we expect a change in the operation state to reflect > > this? > > > > > > Yes. > > > > ·Statistics consumption > > > > > > I actually started another thread on this to get some operator and > > user requirements here, but so far nobody has replied. FWIW, I'm > > leaning toward having a RESTful interface for statistics that's > > separate from the main configuration interface tree and has implied > > context depending on how it's used. > > > > > > For example, if you want to see the stats for a particular member of a > > particular pool of a particular listener on a particular load > > balancer, you'd GET something like the following: > > > > > > GET > /stats/loadbalancer/LB_UUID/listener/LB_UUID/pool/POOL_UUID/member/MEMBER_UUID > > > > > > ...which would give you just the stats for that member in that > > context. > > > > I think we might also want to support getting overall stats for a > > single logical object. So for example: > > > > GET /stats/member/MEMBER_UUID > > > > > > ...would get you total stats for that member, regardless of which > > pool, listener, or loadbalancer it happens to reside in. > > > > > > But... all of this really depends on what users are going to be > > interested in and operators want to provide. What's the point of going > > to the trouble of collecting very specific-context stats if the user > > only cares about aggregate stats? > > I know from just a billing standpoint all we care about is just the > loadbalancer stats since a loadbalancer will only have one vip (assuming > we don't do the IPv4 and IPv6). Those stats would be incoming and > outgoing bandwidth, connections (total and concurrent), and obviously > uptime which will most likely be available through the DB. > > We do expose other stats to customers and I am sure our Ops needs other > stats as well. I'll try to get a full list and respond to your other > email about stats. > > I'm not sure how much we would need stats on each individual pool > member, or even the pool. It is possible our Ops need it though. > However, other operators may need that. > Thanks! I appreciate the input, eh! > > > > > o From which object will the user “poll” to get statistics > > for the different sub objects in the model (ex: load > > balancer)? > > > > > > o How can statistics from a shared logical object be obtained > > in context of the load balancer (ex: pool statistics for a > > specific listener in a specific load balancer)? > Thats why I think we put only the stats on the loadbalancer resource > (i.e. /loadbalancers/LB_UUID/stats) and that shows the stats for all of > its children entities if we decide to show that. Alternatively, we > allow the child resource through the load balancer resource > (i.e. /loadbalancers/LB_UUID/listeners/LISTENER_UUID/stats) > Makes sense to me. Makes more sense than what I suggested, too. :) > > > > > > ·Deletion of shared objects > > > > o Do we support deletion of shared objects that will cascade > > delete? > > I'm not a big fan of cascading deletes on behalf of a customer. I think > the customer should detach a child object from all of its parents and > then and only then are they able to delete that object. > Same here. Cascade-deleting of shared objects should not be allowed in any case. Thanks, 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] dealing with M:N relashionships for Pools and Listeners
Hi Sam, Here are my thoughts on this: On Thu, May 29, 2014 at 12:32 PM, Samuel Bercovici wrote: > Before solving everything, I would like first to itemize the things we > should solve/consider. > > So pleas focus first on what is it that we need to pay attention for and > less on how to solve such issues. > > > > Follows the list of items: > > · Provisioning status/state > > o Should it only be on the loadblancer? > That makes sense to me, unless we're also using this field to indicate a pending change from an update as well. Pending changes here should be reflected in the listener state. > o Do we need a more granular status per logical child object? > Than what? I'm not sure I understand what you're saying here. Can you give a couple examples? > o Update process > > § What happens when a logical child object is modified? > Any affected parent objects should show a 'PENDING_UPDATE' status or something similar until the change is pushed to them. > § Where can a user check the success of the update? > Depending on the object... either the status of the child object itself or all of its affected parent(s). Since we're allowing reusing of the pool object, when getting the status of a pool, maybe it makes sense to produce a list showing the status of all the pool's members, as well as the update status of all the listeners using the pool? > · Operation status/state – this refers to information returning > from the load balancing back end / driver > > o How is member status that failed health monitor reflected, on which > LBaaS object and how can a user understand the failure? > Assuming you're not talking about an alert which would be generated by a back-end load balancer and get routed to some notification system... I think you should be able to get the status of a member by just checking the member status directly (ie. GET /members/[UUID]) or, if people like my suggestion above, by checking the status of the pool to which the member belongs (ie. GET /pools/[UUID]). > · Administrator state management > > o How is a change in admin_state on member, pool, listener get managed > I'm thinking that disabling members, pools, and listeners should propagate to all parent objects. (For example, disabling a member should propagate to all affected pools and listeners, which essentially pulls the member out of rotation for all load balancers but otherwise leaves listeners and pools up and running. This is probably what the user is trying to accomplish by disabling the member.) I do not think it makes sense to propagate to all child objects. For example, disabling a listener should not disable all the pools it references. And by 'propagate' here I mean that config changes are pushed to all affected listeners and load balancers-- not that we actually update all parents to be 'ADMIN_STATUS_DOWN' or something. Does this make sense to you? > o Do we expect a change in the operation state to reflect this? > Yes. > · Statistics consumption > I actually started another thread on this to get some operator and user requirements here, but so far nobody has replied. FWIW, I'm leaning toward having a RESTful interface for statistics that's separate from the main configuration interface tree and has implied context depending on how it's used. For example, if you want to see the stats for a particular member of a particular pool of a particular listener on a particular load balancer, you'd GET something like the following: GET /stats/loadbalancer/LB_UUID/listener/LB_UUID/pool/POOL_UUID/member/MEMBER_UUID ...which would give you just the stats for that member in that context. I think we might also want to support getting overall stats for a single logical object. So for example: GET /stats/member/MEMBER_UUID ...would get you total stats for that member, regardless of which pool, listener, or loadbalancer it happens to reside in. But... all of this really depends on what users are going to be interested in and operators want to provide. What's the point of going to the trouble of collecting very specific-context stats if the user only cares about aggregate stats? > o From which object will the user “poll” to get statistics for the > different sub objects in the model (ex: load balancer)? > o How can statistics from a shared logical object be obtained in context > of the load balancer (ex: pool statistics for a specific listener in a > specific load balancer)? > · Deletion of shared objects > > o Do we support deletion of shared objects that will cascade delete? > > > Thanks, 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] Unanswered questions in object model refactor blueprint
object? >> > >> > My opinion: I don't think it needs the status field. I think >> > the >> > LoadBalancer object may be the only thing that needs a status, >> > other >> > than the pool members for health monitoring. I might be >> > corrected on >> > this though. >> > >> > ___ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> <https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=DYApm8uTUC2lxp%2B0qmdN9UhsdAxGdWaIHf5dr1N1tJE%3D%0A&s=ec3a8e21156d1b946db652fac0dab2e2268340aea37bd8c30adbf52fe2f3e8de> >> > >> > >> > ___ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> <https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=DYApm8uTUC2lxp%2B0qmdN9UhsdAxGdWaIHf5dr1N1tJE%3D%0A&s=ec3a8e21156d1b946db652fac0dab2e2268340aea37bd8c30adbf52fe2f3e8de> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> <https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=DYApm8uTUC2lxp%2B0qmdN9UhsdAxGdWaIHf5dr1N1tJE%3D%0A&s=ec3a8e21156d1b946db652fac0dab2e2268340aea37bd8c30adbf52fe2f3e8de> >> > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > > https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=DYApm8uTUC2lxp%2B0qmdN9UhsdAxGdWaIHf5dr1N1tJE%3D%0A&s=ec3a8e21156d1b946db652fac0dab2e2268340aea37bd8c30adbf52fe2f3e8de > > > ___ > 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][LBaaS] Requirements around statistics and billing
Hi folks! We have yet to have any kind of meaningful discussion on this list around load balancer stats (which, I presume to include data that will eventually need to be consumed by a billing system). I'd like to get the discussion started here, as this will have significant meaning for how we both make this data available to users, and how we implement back-end systems to be able to provide this data. So! What kinds of data are people looking for, as far as load balancer statistics. For our part, as an absolute minimum we need the following per loadbalancer + listener combination: * Total bytes transferred in for a given period * Total bytes transferred out for a given period Our product and billing people I'm sure would like the following as well: * Some kind of peak connections / second data (95th percentile or average over a period, etc.) * Total connections for a given period * Total HTTP / HTTPS requests served for a given period And the people who work on UIs and put together dashboards would like: * Current requests / second (average for last X seconds, either on-demand, or simply dumped regularly). * Current In/Out bytes throughput And our monitoring people would like this: * Errors / second * Current connections / second and bytes throughput secant slope (ie. like derivative but easier to calculate from digital data) for last X seconds (ie. detecting massive spikes or drops in traffic, potentially useful for detecting a problem before it becomes critical) And some of our users would like all of the above data per pool, and not just for loadbalancer + listener. Some would also like to see it per member (though I'm less inclined to make this part of our standard). I'm also interested in hearing vendor capabilities here, as it doesn't make sense to design stats that most can't implement, and I imagine vendors also have valuable data on what their customer ask for / what stats are most useful in troubleshooting. What other statistics data for load balancing are meaningful and hopefully not too arduous to calculate? What other data are your users asking for or accustomed to seeing? Thanks, 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] Unanswered questions in object model refactor blueprint
nk of the idea of having both IPv4 and IPv6 attributes on a 'load balancer' object? One doesn't need to have a single appliance serving both types of addresses for the listener, but there's certainly a chance (albeit small) to hit an async scenario if they're not. Vijay: I think the plan here was to come up with an use an entirely different DB schema than the legacy Neutron LBaaS, and then retro-fit backward compatibility with the old user API once the new LBaaS service is functional. I don't think anyone here is suggesting we try to make the old schema work for the new API. 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]TLS API support for authentication
Hi y'all! On Fri, May 23, 2014 at 1:24 PM, Carlos Garza wrote: > Right so are you advocating that the front end API never return a > private key back to the user once regardless if the key was generated > on the back end or sent in to the API from the user? We kind of are > already are implying that they can refer to the key via a private > key id. > I would advocate that if the user asks the front-end API for the private key information (ie. "GET" request), what they get back is the key's modulus and nothing else. This should work to verify whether a given key matches a given cert, and doesn't break security requirements for those who are never allowed to actually touch private key data. And if a user added the key themselves through the front-end API, I think it's safe to assume the responsibility for keeping a copy of the key they can access lies with the user. Having said this, of course anything which spins up virtual appliances, or configures physical appliances is going to need access to the actual private key. So any back-end API(s) will probably need to have different behavior here. One thing I do want to point out is that with the 'transient' nature of back-end guests / virtual servers, it's probably going to be important to store the private key data in something non-volatile, like barbican's store. While it may be a good idea to add a feature that generates a private key and certificate signing request via our API someday for certain organizations' security requirements, one should never have the only store for this private key be a single virtual server. This is also going to be important if a certificate + key combination gets re-used in another listener in some way, or when horizontal scaling features get added. Thanks, 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] Updated Object Model?
Another question for the group: Would it be helpful to go ahead and update the API google doc we've also been using in discussing API / object model changes? (Also, I'd eventually like to see this become part of the standard documentation, so pointers on how to get started making that happen would be appreciated!) Thanks, Stephen On Mon, May 19, 2014 at 4:45 PM, Stephen Balukoff wrote: > Hi folks, > > Ok, I've attached a newly-updated object diagram (and its source) which is > hopefully both a little bit clearer than the monstrosity I created for the > summit, and also incorporates a couple agreed-upon changes at the summit. > Notes about this: > > >- The grayed-out object (LBtoListener and VIPGroupToAntiGroup) are >simply there to show the database objects that will be used to express the >n:m relationship between VIPs and Listeners, and VIPGroups and >VIPAntiGroups. The user API will have no direct access to these "join" >objects. >- I've update the TLSCertificate object to reflect that we intend to >use barbican to manage TLS certificates. >- I've also split out a 'TLS CA Chain' object from the TLS Certificate >object since it has much different usage than the TLS Certificate object >and after talking with y'all (especially Samuel) I think this is probably >clearer. Note that it might be possible to manage the CA chains in barbican >as well if they eventually add full certificate management... however I'm >not showing this here, as a CA chain is public data, so there's no reason >we couldn't safely store this in the Neutron database. (And we probably >don't need full certificate management for CA chains.) >- There may be a few missing fields (for example, I think status needs >to be two fields?) In any case, I think I've captured all the most >consequential ones. > > Also: > >- We talked briefly about the differences between Samuel's proposed L7 >Policies / Rules proposal and my proposal in the Friday LBaaS meeting, >however we deferred full discussion of this to the mailing list. What it >boils down to is essentially whether people think there will be a need to >re-use L7Policies. (L7Policies in both our proposals are a group of L7Rules >that get logically ANDed together). Perhaps we should start this discussion >in another thread? >- We're also not 100% in agreement over how TLS SNI Policies should >work. I'm unclear on Samuel's model here, and I think this is something >else we deferred to discussion on the mailing list. > > Oh and! Please keep in mind that I think both Eugene and Samuel were going > to be on vacation this week. :) > > Thanks, > Stephen > > > > On Mon, May 19, 2014 at 2:22 PM, Youcef Laribi > wrote: > >> 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.com> wrote: >> >> Yeah that’s a good point. Thanks! >> >> >> >> *From: *Eugene Nikanorov >> *Reply-To: *"openstack-dev@lists.openstack.org" < >> openstack-dev@lists.openstack.org> >> >> *Date: *Thursday, May 15, 2014 at 10:38 PM >> >> >> *To: *"openstack-dev@lists.openstack.org" < >> 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, Br
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Hi Craig, I was attempting to avoid haproxy-specific terminology here, but some of those attributes are on the listener (ie. keepalive = 0 would be equivalent to httpclose). Other options (like adding headers) are expressed through the layer-7 functionality. So, we have yet to update the API to correspond with this object diagram, but if you recall the API I linked on the list a couple weeks ago ( https://docs.google.com/document/d/129Da7zEk5p437_88_IKiQnNuWXzWaS_CpQVm4JBeQnc/edit?usp=sharing) look in the section on L7 policies and L7 rules. (Note also that we don't yet have group consensus on the specifics of implementing the L7 stuff-- but adding headers would definitely fall in that category, eh.) Stephen On Wed, May 14, 2014 at 3:04 PM, Craig Tracey wrote: > Thanks Stephen, > > One nit and one question > - For each of the tables with status fields we will want to have > status_description fields as well. This is already a part of the V2 models. > - How does this model handle things like implementation-specific options > and/or things like additional headers? I'm thinking of some of those very > common cases with http/https...X-Forwarded-For, httpclose, etc. > > Best, > Craig > > > On Wed, May 14, 2014 at 1:32 PM, Stephen Balukoff > wrote: > >> Aah-- and here's a small error correction. :) >> >> Please also note: >> * We're not yet in consensus on the L7 or SSL related objects, but the >> Loadbalancer, Listener, Pool, and Member should probably not change at this >> point (unless there are major objections voiced in the very near term). >> * I've tried to use color coordination to indicate different logical >> parts that can probably be implemented in different blueprints / by >> different engineering teams. >> * The LBtoListener object is grayed out because it will need to exist in >> the database (to allow Listeners to be re-used, solving the IPv4 + IPv6 >> common use case), but should not be directly addressable via the user API. >> (This is also the reason it's got no tenant_id.) >> * The vip group and vip anti group stuff is meant to solve the vip >> colocation / apolocation problem. These are optional objects that don't >> need to be created unless a user has colocation / apolocation needs. (I'd >> be happy to run anyone through the logic on how these work, as it's >> probably not immediately intuitive.) >> >> Stephen >> >> >> >> On Wed, May 14, 2014 at 10:22 AM, Stephen Balukoff > > wrote: >> >>> Also, apologies for the crappy formatting. I like gv files as they're >>> easily tracked in a text-based revision control system (like git) that >>> depends on useful diffs to do code reviews. But sometimes the layout it >>> chooses is a little dumb. >>> >>> Stephen >>> >>> >>> On Wed, May 14, 2014 at 10:18 AM, Stephen Balukoff < >>> sbaluk...@bluebox.net> wrote: >>> >>>> Hi Craig, >>>> >>>> I'm attaching the latest object model diagram as discussed with the RAX >>>> team last night, Samuel and Eugene. Note that we don't necessarily have >>>> HP's blessing on this model yet, nor do we have Neutron core developer buy >>>> in. But in any case, here it is. >>>> >>>> Also, I think the #openstack-lbaas channel is a great idea! >>>> >>>> Stephen >>>> >>>> >>>> On Wed, May 14, 2014 at 9:05 AM, Craig Tracey wrote: >>>> >>>>> Hi all, >>>>> >>>>> From what I heard last night, it sounds like there has been some >>>>> consensus achieved around the LBaaS object model. Unfortunately, I missed >>>>> this ad-hoc conversation. Is someone capturing this information and/or >>>>> perhaps posting to the list? someplace else? >>>>> >>>>> On a related note, does it make sense to create an lbaas IRC topic >>>>> channel? #openstack-lbaas? Just thinking that a dedicated channel might >>>>> help to make the weekly meetings more productive with less crosstalk. >>>>> Thoughts? >>>>> >>>>> Best, >>>>> Craig >>>>> >>>>> ___ >>>>> 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 >>> >> >> >> >> -- >> 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 >> >> > > ___ > 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 ___ 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?
Also, apologies for the crappy formatting. I like gv files as they're easily tracked in a text-based revision control system (like git) that depends on useful diffs to do code reviews. But sometimes the layout it chooses is a little dumb. Stephen On Wed, May 14, 2014 at 10:18 AM, Stephen Balukoff wrote: > Hi Craig, > > I'm attaching the latest object model diagram as discussed with the RAX > team last night, Samuel and Eugene. Note that we don't necessarily have > HP's blessing on this model yet, nor do we have Neutron core developer buy > in. But in any case, here it is. > > Also, I think the #openstack-lbaas channel is a great idea! > > Stephen > > > On Wed, May 14, 2014 at 9:05 AM, Craig Tracey wrote: > >> Hi all, >> >> From what I heard last night, it sounds like there has been some >> consensus achieved around the LBaaS object model. Unfortunately, I missed >> this ad-hoc conversation. Is someone capturing this information and/or >> perhaps posting to the list? someplace else? >> >> On a related note, does it make sense to create an lbaas IRC topic >> channel? #openstack-lbaas? Just thinking that a dedicated channel might >> help to make the weekly meetings more productive with less crosstalk. >> Thoughts? >> >> Best, >> Craig >> >> ___ >> 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] API proposal review thoughts
Hi Eugene, A couple notes of clarification: On Sat, May 10, 2014 at 2:30 AM, Eugene Nikanorov wrote: > > On Fri, May 9, 2014 at 10:25 PM, Stephen Balukoff > wrote: > >> Hi Eugene, >> >> This assumes that 'VIP' is an entity that can contain both an IPv4 >> address and an IPv6 address. This is how it is in the API proposal and >> corresponding object model that I suggested, but it is a slight >> re-definition of the term "virtual IP" as it's used in the rest of the >> industry. (And again, we're not yet in agreement that 'VIP' should actually >> contain two ip addresses like this.) >> > That seems a minor issue to me. May be we can just introduce a statement > that VIP has L2 endpoint first of all? > Well, sure, except the user is going to want to know what the IP address(es) are for obvious reasons, and expect them to be taken from subnet(s) the user specifies. Asking the user to provide a Neutron network_id (ie. where we'll attach the L2 interface) isn't definitive here because a neutron network can contain many subnets, and these subnets might be either IPv4 or IPv6. Asking the user to provide an IPv4 and IPv6 subnet might cause us problems if the IPv4 subnet provided and the IPv6 subnet provided are not on the same neutron network. In that scenario, we'd need two L2 interfaces / neutron ports to service this, and of course some way to record this information in the model. We could introduce the restriction that all of the IP addresses / subnets associated with the VIP must come from the same neutron network, but this begs the question: Why? Why shouldn't a VIP be allowed to connect to multiple neutron networks to service all its front-end IPs? If the answer to the above is "there's no reason" or "because it's easier to implement," then I think these are not good reasons to apply these restrictions. If the answer to the above is "because nobody deploys their IPv4 and IPv6 networks separate like that," then I think you are unfamiliar with the environments in which many operators must survive, nor the requirements imposed on us by our users. :P In any case, if you agree that in the IPv4 + IPv6 case it might make sense to allow for multiple L2 interfaces on the VIP, doesn't it then also make more sense to define a VIP as a single IP address (ie. what the rest of the industry calls a "VIP"), and call the groupings of all these IP addresses together a 'load balancer' ? At that point the number of L2 interfaces required to service all the IPs in this VIP grouping becomes an implementation problem. For what it's worth, I do go back and forth on my opinion on this one, as you can probably tell. I'm trying to get us to a model that is first and foremost simple to understand for users, and relatively easy for operators and vendors to implement. > In my mind, the main reasons I would like to see the container object are: >> >> >>- It solves the colocation / apolcation (or affinity / anti-affinity) >>problem for VIPs in a way that is much more intuitive to understand and >>less confusing for users than either the "hints" included in my API, or >>something based off the nova blueprint for doing the same for virtual >>servers/containers. (Full disclosure: There probably would still be a need >>for some anti-affinity logic at the logical load balancer level as well, >>though at this point it would be an operator concern only and expressed to >>the user in the "flavor" of the logical load balancer object, and probably >>be associated with different billing strategies. "The user wants a >>dedicated physical load balancer? Then he should create one with this >>flavor, and note that it costs this much more...") >> >> In fact, that can be solved by scheduling, without letting user to > control that. Flavor Framework will be able to address that. > I never said it couldn't be solved by scheduling. In fact, my original API proposal solves it this way! I was saying that it's *much more intuitive to understand and less confusing for users* to do it using a logical load balancer construct. I've yet to see a good argument for why working with colocation_hints / apolocation_hints or affinity grouping rules (akin to the nova model) is *easier* *for the user to understand* than working with a logical load balancer model. And by the way-- maybe you didn't see this in my example below, but just because a user is using separate load balancer objects doesn't mean the vendor or operator needs to implement these on separate pieces of hardware. Whether or not the operator decides to let the user have this level of control
Re: [openstack-dev] [Neutron][LBaaS] Multiple VIPs per loadbalancer
Hi Eugene, On Fri, May 9, 2014 at 1:36 PM, Eugene Nikanorov wrote: > > > > On Fri, May 9, 2014 at 7:40 PM, Brandon Logan > wrote: > >> Yes, Rackspace has users that have multiple IPv4 and IPv6 VIPs on a >> single load balancer. > > For sure that can be supported by particular physical appliance, but I > doubt we need to translate it to logical loadbalancer. > > >> However, I don't think it is a matter of it being >> needed. It's a matter of having an API that makes sense to a user. >> Just because the API has multiple VIPs doesn't mean every VIP needs its >> own port. In fact creating a port is an implementation detail (you know > > that phrase that everyone throws out to stonewall any discussions?). >> The user doesn't care how many neutron ports are set up underneath, they >> only care about the VIPs. >> > Right, port creation is implementation detail, however, L2 connectivity > for the frontend is a certain API expectation. > I think VIP creation should have clear semantics: user creates L2 > endpoint, e.g. l2 port + ipv4[+ipv6] address. > If we agree that we only need 1 L2 port per logical loadbalancer, then it > could be handled by two API/objmodel approaches: > > 1) loadbalancer + VIPs, 1:n relationship > 2) VIP + listeners, 1:n relationship > You see that from API and obj model structure perspective those approaches > are exactly the same. > However, in (1) we would need to specify L3 information (ipv4 + ipv6 > addresses, subnet_id) for the loadbalancer, and that will be inherited by > VIPs which would keep info about L4+ > To me it seems a little bit confusing (per our glossary) > > While in second approach VIP remains a keeper of L2/L3 information, while > listeners keep L4+ information. > That seems to be more clear. > There's a complication though: Pools may also need some L2/L3 information (per the discussion of adding subnet_id as an attribute of the pool, eh.) > In case we want more than one L2 port, then we need to combine those > approaches and have loadbalancer+VIPs+Listeners, where loadbalancer is a > container that maps to a backend. > However, per discussed on the last meeting, we don't want to let user have > direct control over the backend. > If the VIP subnet/neutron network and Pool subnet/neutron network are not the same, then the load balancer is going to need separate L2 interfaces to each. In fact, a VIP with a Listener that references several different pool via L7 policies, which pools are on different subnets, is going to need an L2 interface on all of them. Unless I'm totally misunderstanding something (which is always a possibility-- this stuff is hard, eh!) And actually, there are a few cases that have been discussed where operators do want users to be able to have some (limited) control over the back end. These almost all have to do with VIP affinity. > Also we've heard objection to this approach several times from other core > team members (this discussion has been going for more than half a year > now), so I would suggest to move forward with single L2 port approach. Then > the question goes down to terminology: loadbalancer/VIPs or VIP/Listeners. > To be fair this is definitely about more than terminology. In the examples you've listed mentioning loadbalancer objects, it seems to me that you're ignoring that this model also still contains Listeners. So, to be more accurate, it's really about: loadbalancer/VIPs/Listeners or VIPs/Listeners. To me, that says it's all about: Does the loadbalancer object add something meaningful to this model? And I think the answer is: * To smaller users with very basic load balancing needs: No (mostly, though to many it's still "yes") * To larger customers with advanced load balancing needs: Yes. * To operators of any size: Yes. I've outlined my reasoning for thinking so in the other discussion thread. Thanks, 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]User Stories and sruvey
Sam, That deadline seems reasonable to me. I should have time later today or later this weekend to fill it out. Thanks, Stephen On Fri, May 9, 2014 at 9:21 AM, Samuel Bercovici wrote: > Hi, > > > > 9 people have filled the survey so far. > > See attached pdf. > > > > Regards, > > -Sam. > > > > > > *From:* Samuel Bercovici > *Sent:* Thursday, May 08, 2014 2:51 PM > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey > > > > Hi everyone, > > > > I think that it is a good feedback to prioritize features. > > I can publish the results in time for the 2nd LBaaS meeting (so deadline > would be end of 15th May “summit time”) > > Is this acceptable? > > > > -Sam. > > > > > > > > *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net] > > *Sent:* Thursday, May 08, 2014 2:17 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey > > > > Hi Samuel-- > > > > I've been heads down working on API proposal review documentation, and > haven't had time to fill it out yet. Do you have a deadline by which we > should have filled out the survey to get our voices heard? > > > > Thanks, > > Stephen > > > > On Wed, May 7, 2014 at 2:16 PM, Samuel Bercovici > wrote: > > 6 people have completed the survey so far. > > > > > > *From:* Samuel Bercovici > *Sent:* Tuesday, May 06, 2014 10:56 AM > > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey > > > > Hi Everyone, > > > > The survey is now live via: http://eSurv.org?u=lbaas_project_user > > The password is: lbaas > > > > The survey includes all the tenant facing use cases from > https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?usp=sharing > > Please try and fill the survey this week so we can have enough information > to base decisions next week. > > > > Regards, > > -Sam. > > > > > > > > *From:* Samuel Bercovici > *Sent:* Monday, May 05, 2014 4:52 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey > > > > Hi, > > > > I will not freeze the document to allow people to work on requirements > which are not tenant facing (ex: operator, etc.) > > I think that we have enough use cases for tenant facing capabilities to > reflect most common use cases. > > I am in the process of creation a survey in surveymonkey for tenant facing > use cases and hope to send it to ML ASAP. > > > > Regards, > > -Sam. > > > > > > *From:* Samuel Bercovici > *Sent:* Thursday, May 01, 2014 8:40 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Cc:* Samuel Bercovici > *Subject:* [openstack-dev] [Neutron][LBaaS]User Stories and sruvey > > > > Hi Everyone! > > > > To assist in evaluating the use cases that matter and since we now have > ~45 use cases, I would like to propose to conduct a survey using something > like surveymonkey. > > The idea is to have a non-anonymous survey listing the use cases and ask > you identify and vote. > > Then we will publish the results and can prioritize based on this. > > > > To do so in a timely manner, I would like to freeze the document for > editing and allow only comments by Monday May 5th 08:00AMUTC and publish > the survey link to ML ASAP after that. > > > > Please let me know if this is acceptable. > > > > Regards, > > -Sam. > > > > > > > > > ___ > 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 > > ___ > 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Multiple VIPs per loadbalancer
+1 to everything Brandon just said. :) Stephen On Fri, May 9, 2014 at 8:40 AM, Brandon Logan wrote: > Yes, Rackspace has users that have multiple IPv4 and IPv6 VIPs on a > single load balancer. However, I don't think it is a matter of it being > needed. It's a matter of having an API that makes sense to a user. > Just because the API has multiple VIPs doesn't mean every VIP needs its > own port. In fact creating a port is an implementation detail (you know > that phrase that everyone throws out to stonewall any discussions?). > The user doesn't care how many neutron ports are set up underneath, they > only care about the VIPs. > > Also, the load balancer wouldn't just be a container, the load balancer > would have flavor, affinity, and other metadata on it. Plus, a user > will expect to get a load balancer back. Since this object can only be > described as a load balancer, the name of it shouldn't be up for debate. > > The API is meant to be a generic language that can be translated into a > working load balancer and should be driver agnostic. We believe this is > the most generic and flexible API structure. Each driver will be able > to translate this into what makes sense for that product. > > On a side note, if this is too disruptive for the current LBaaS then why > couldn't this go into Neutron V3? I thought that was the plan all along > anyway with redesigning the API. > > Thanks, > Brandon > > On Fri, 2014-05-09 at 14:30 +0400, Eugene Nikanorov wrote: > > Hi folks, > > > > > > I'm pulling this question out of another discussion: > > > > > > Is there a need to have multiple VIPs (e.g. multiple L2 ports/IP > > addresses) per logical loadbalancer? > > If so, we need the description of such cases to evaluate them. > > > > > > Thanks, > > Eugene. > > ___ > > 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 > -- 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] API proposal review thoughts
object? In answering this question, please keep in mind: - If you say "implementation details," please just go ahead and be more specific because that's what I'm going to ask you to do anyway. If "implementation details" is the concern, please follow this with a hypothetical or concrete example as to what kinds of implementations this object would invalidate simply by existing in the model, or what restrictions this object introduces. - If you say "I don't see a need" then you're really just asking people to come up with a use case that is more easily solved using the logical load balancer object rather than the VIP without the load balancer. I hope my reasons above address this, but I'm happy to be more specific if you'd like: Please point out how my examples above are not convincing reasons for having this object, and I will be more specific. Thanks, Stephen On Fri, May 9, 2014 at 1:36 AM, Eugene Nikanorov wrote: > Hi Brandon > > Let me know if I am misunderstanding this,and please explain it >> further. >> A single neutron port can have many fixed ips on many subnets. Since >> this is the case you're saying that there is no need for the API to >> define multiple VIPs since a single neutron port can represent all the >> IPs that all the VIPs require? >> > Right, if you want to to have both ipv4 and ipv6 addresses on the VIP then > it's possible with single neutron port. > So multiple VIPs for this case are not needed. > > Eugene. > > ___ > 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][LBaaS] API proposal review thoughts
uot;root" of the tree. This whole concept seems to strike me as odd-- because when you have a graph, even if it's somewhat tree-like (ie. there are leaf nodes), does the term "root" even apply? Can someone please tell me what criteria they're using when they say that one object should be a "root" and another should not? (For what it's worth, I could probably propose a version of the API that does single-call through a 'healthmonitor' object. Though it would be silly, it would still be perfectly functional. :P ) Having said all this, we already know the API is going to support manipulation of individual objects as a way to provision services. If the people advocating for making the "VIP" the root of the object tree don't actually intend to use single-call for manipulating their objects, what do we care if those who are going to use single-call would rather do this through the "listener / load balancer" object? And... that's about it. Sorry for the length of this e-mail, y'all! Thanks, Stephen -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807i ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey
Hi Samuel-- I've been heads down working on API proposal review documentation, and haven't had time to fill it out yet. Do you have a deadline by which we should have filled out the survey to get our voices heard? Thanks, Stephen On Wed, May 7, 2014 at 2:16 PM, Samuel Bercovici wrote: > 6 people have completed the survey so far. > > > > > > *From:* Samuel Bercovici > *Sent:* Tuesday, May 06, 2014 10:56 AM > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey > > > > Hi Everyone, > > > > The survey is now live via: http://eSurv.org?u=lbaas_project_user > > The password is: lbaas > > > > The survey includes all the tenant facing use cases from > https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?usp=sharing > > Please try and fill the survey this week so we can have enough information > to base decisions next week. > > > > Regards, > > -Sam. > > > > > > > > *From:* Samuel Bercovici > *Sent:* Monday, May 05, 2014 4:52 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey > > > > Hi, > > > > I will not freeze the document to allow people to work on requirements > which are not tenant facing (ex: operator, etc.) > > I think that we have enough use cases for tenant facing capabilities to > reflect most common use cases. > > I am in the process of creation a survey in surveymonkey for tenant facing > use cases and hope to send it to ML ASAP. > > > > Regards, > > -Sam. > > > > > > *From:* Samuel Bercovici > *Sent:* Thursday, May 01, 2014 8:40 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Cc:* Samuel Bercovici > *Subject:* [openstack-dev] [Neutron][LBaaS]User Stories and sruvey > > > > Hi Everyone! > > > > To assist in evaluating the use cases that matter and since we now have > ~45 use cases, I would like to propose to conduct a survey using something > like surveymonkey. > > The idea is to have a non-anonymous survey listing the use cases and ask > you identify and vote. > > Then we will publish the results and can prioritize based on this. > > > > To do so in a timely manner, I would like to freeze the document for > editing and allow only comments by Monday May 5th 08:00AMUTC and publish > the survey link to ML ASAP after that. > > > > Please let me know if this is acceptable. > > > > Regards, > > -Sam. > > > > > > > > ___ > 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Subteam meeting Thursday, 05/08 14-00 UTC
Hi folks, It's late, so I of course am not going to mind if y'all haven't had a chance to review these before the meeting, but here are my additions: https://docs.google.com/document/d/1m3XXd98_pnYGxS3ubw7NMmxs2dxi__c-TzRiHykNpyU/edit?usp=sharing Note that I've only written up the same use cases that the RAX team answered (1-10 and 14). I've not generated as much detailed information as the RAX team (great job with that, guys!), but I have tried to include enough information for a person trying to meet the use case to know how to go about doing it using the Blue Box edit of Rackspace's original API proposal. So, having gone through this exercise I definitely have a few thoughts and trepidations about our API proposal review thus far that I will be sharing in another thread (as I imagine it will spawn some discussion). Expect to see that e-mail later tonight. Stephen On Wed, May 7, 2014 at 1:10 PM, Jorge Miramontes < jorge.miramon...@rackspace.com> wrote: > All of our relevant material is in this Google Drive folder ==> > https://drive.google.com/#folders/0B_x8_4x6DRLad1NZMjgyVFhqakU > > Cheers, > --Jorge > > > > > On 5/7/14 1:19 PM, "Kyle Mestery" wrote: > > >Lets go over the Rackspace portion of the API comparison tomorrow > >then, and we can cover Stephen's on the ML when it's complete. > > > >On Wed, May 7, 2014 at 4:55 AM, Stephen Balukoff > >wrote: > >> Howdy, y'all! > >> > >> I just wanted to give you a quick update: It looks like the Rackspace > >>team > >> is mostly done with their half of the API comparison, however, it is > >> extremely unlikely I'll be able to finish my half of this in time for > >>the > >> team meeting this Thursday. I apologize for this. > >> > >> Stephen > >> > >> > >> On Tue, May 6, 2014 at 1:27 PM, Eugene Nikanorov > >> > >> wrote: > >>> > >>> Hi folks, > >>> > >>> This will be the last meeting before the summit, so I suggest we will > >>> focus on the agenda for two > >>> design track slots we have. > >>> > >>> Per my experience design tracks are not very good for in-depth > >>>discussion, > >>> so it only make sense to present a road map and some other items that > >>>might > >>> need core team attention like interaction with Barbican and such. > >>> > >>> Another item for the meeting will be comparison of API proposals which > >>>as > >>> an action item from the last meeting. > >>> > >>> Thanks, > >>> Eugene. > >>> > >>> ___ > >>> 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 > >> > >> ___ > >> 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 > > > ___ > 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Subteam meeting Thursday, 05/08 14-00 UTC
Howdy, y'all! I just wanted to give you a quick update: It looks like the Rackspace team is mostly done with their half of the API comparison, however, it is extremely unlikely I'll be able to finish my half of this in time for the team meeting this Thursday. I apologize for this. Stephen On Tue, May 6, 2014 at 1:27 PM, Eugene Nikanorov wrote: > Hi folks, > > This will be the last meeting before the summit, so I suggest we will > focus on the agenda for two > design track slots we have. > > Per my experience design tracks are not very good for in-depth discussion, > so it only make sense to present a road map and some other items that might > need core team attention like interaction with Barbican and such. > > Another item for the meeting will be comparison of API proposals which as > an action item from the last meeting. > > Thanks, > Eugene. > > ___ > 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey
I think the plan is to release all the raw results of this to the public as well-- meaning that it should be possible to come up with a "representative average" per organization, as well as several other ways to interpret the data. Right now, the emphasis is just to gather the data. We can decide how to interpret it later. There's a reason this survey is not anonymous. :) Thanks, Stephen On Tue, May 6, 2014 at 12:24 PM, Adam Harwell wrote: > I'd like to add that size of the organization (or really, size of the > development team) that is voting in this quiz does not directly correlate > to size of customer base. If there were any weighting happening, I'd hope > these answers would be weighted by size of user base, since really it is > the users' interests we are all trying to represent, not our own! > > --Adam > > On 5/6/14 2:16 PM, "Jorge Miramontes" > wrote: > > >I agree that everyone's thoughts should be in it. I don't see why a > >representative vote does not allow for that. Sam put a text box on each > >use case to capture extra thoughts. > > > >I would hope that no organization would be so confused as to have widely > >varying viewpoints on *what their customers want*, since that is the > >supposed purpose of all of this, right? We're supposed to be deciding > >which use-cases matter *to our customers*, so there should be no real > >variance for what I would vote versus what my teammates would vote, since > >we have the same customersŠ > > > > > >Also, if we are using this as a type of voting mechanism then interests of > >large/vocal organizations drown out smaller organizations. If this is > >being used as a voting mechanism then how do you suggest we weight votes > >for smaller companies so that we do not alienate them from further > >voting/discussions? > > > >Cheers, > >--Jorge > > > > > > > > > >On 5/6/14 1:52 PM, "Jay Pipes" wrote: > > > >>On 05/06/2014 02:42 PM, Jorge Miramontes wrote: > >>> Sam, > >>> > >>> I'm assuming you want one person from each company to answer correct? > >>> I'm pretty sure people in each organization will vote the sameŠat least > >>> I'd hope! > >> > >>I'd hope not! :) > >> > >>Even within the same organization or company, we all have different > >>ideas on use cases, the appropriateness of certain things "in the > >>cloud", and the role of a load balancer service in the general mix of > >>things. > >> > >>I certainly would hope that lots of Mirantis engineers other than myself > >>fill out the use case survey and offer their own insights. > >> > >>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 > > > ___ > 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Use-Cases with VPNs Distinction
German-- I agree. This sounds very much like an edge case that we don't need to worry about supporting until someone comes up with a specific use case to illustrate the problem. Stephen On Mon, May 5, 2014 at 5:03 PM, Eichberger, German wrote: > Hi Stephen, > > > > I think this is too strange an edge case to be covered by the LBaaS. In > any case I am wondering if there is a valid use case if we can add it to > the user stories. > > > > German > > > > *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net] > *Sent:* Monday, May 05, 2014 4:05 PM > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Use-Cases with VPNs > Distinction > > > > Hi Sam, > > > > So, If I understand you correctly, you don't think that specifying routing > rules (eg. static routing configuration) should be beyond the scope of > LBaaS? > > > > I agree that it might be possible to reach a given member over different > routes. The example that comes to mind for me is a member with a public IP > on the internet somewhere that's either accessible from the VIP address via > the VIP's subnet's default gateway, or via a VPN service available on the > same layer 2 network. But if we're going to support choosing routes to a > given member, shouldn't this information be located with the member? > > > > I don't know why putting this information as properties of the VIP in the > object model would make scheduling and placing the configuration any > easier-- specifically, if you've got enough information / completed > objects to deploy a load balancing service, wouldn't the service's pools > and pool member information also be implicitly available as part of the > overall configuration for the service? > > > > Thanks, > > Stephen > > > > On Sun, May 4, 2014 at 12:36 AM, Samuel Bercovici > wrote: > > Hi, > > > > I prefer a different approach (AKA, I oppose J) > > I think that this information should be properties of the VIP and not the > pool. > > So VIP should have: > > 1. VIP subnet (this is where the IP will be allocated) > > 2. List of members subnets (it could be optional. This means that > members have L2 proximity on the VIP subnet) > > 3. List of static routes (to be able to specify how to reach > members which are not on L2 proximity) – if not presented, this could be > calculated by the “driver” backend but sometimes where you can use multiple > different paths a user intervention might be required. > > > > I prefer this approach for the following: > > 1. Concentrating the L3 information in a single place (VIP) – this > also makes scheduling and placement of the configuration easier. > > 2. When using multiple pools (L7 content switching) that have > members on the same subnet, no need to repeat the subnet information > > > > Regards, > > -Sam. > > > > > > > > *From:* Adam Harwell [mailto:adam.harw...@rackspace.com] > *Sent:* Saturday, May 03, 2014 10:17 AM > > > *To:* OpenStack Development Mailing List (not for usage questions) > > *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Use-Cases with VPNs > Distinction > > > > Sounds about right to me. I guess I agree with your agreement. :) > > Does anyone actually *oppose* this arrangement? > > > > --Adam > > > > *From: *Stephen Balukoff > *Reply-To: *"OpenStack Development Mailing List (not for usage > questions)" > *Date: *Friday, May 2, 2014 7:53 PM > *To: *"OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > *Subject: *Re: [openstack-dev] [Neutron][LBaaS] Use-Cases with VPNs > Distinction > > > > Hi guys, > > > > Yep, so what I'm hearing is that we should be able to assume that either > all members in a single pool are adjacent (ie. layer-2 connected), or are > routable from that subnet. > > > > Adam-- I could see it going either way with regard to how to communicate > with members: If the particular device that the provider uses lives > outside tenant private networks, the driver for said devices would need to > make sure that VIFs (or some logical equivalent) are added such that the > devices can talk to the members. This is also the case for virtual load > balancers (or other devices) which are assigned to the tenant but live on > an "external" network. (In this topology, VIP subnet and pool subnet could > differ, and the driver needs to make sure that the load bal
Re: [openstack-dev] [Neutron][LBaaS]L7 conent switching APIs
Hi Sam,
In working off the document in the wiki on L7 functionality for LBaaS (
https://wiki.openstack.org/wiki/Neutron/LBaaS/l7 ), I notice that
"MODIFY_CONTENT" is one of the actions listed for a
L7VipPolicyAssociation. That's
the primary reason I included this in the API design I created.
To be honest, it frustrates me more than a little to hear after the fact
that the only locate-able documentation like this online is inaccurate on
many meaningful details like this.
I could actually go either way on this issue: I included content
modification as one possible action of L7Policies, but it is somewhat
wedged in there: It works, but in L7Policies that do content modification
or blocking of the request, the order field as I've proposed it could be
confusing for users, and these L7Policies wouldn't be associated with a
back-end pool anyway.
I'm interested in hearing others' opinions on this as well.
Stephen
On Mon, May 5, 2014 at 6:47 AM, Samuel Bercovici wrote:
> Hi Stephen,
>
>
>
> For Icehouse we did not go into L7 content modification as the general
> feeling was that it might not be exactly the same as content switching and
> we wanted to tackle content switching fiest.
>
>
>
> L7 content switching and L7 content modification are different, I prefer
> to be explicit and declarative and use different objects.
>
> This will make the API more readable.
>
> What do you think?
>
>
>
> I plan to look deeper into L7 content modification later this week to
> propose a list of capabilities.
>
>
>
> -Sam.
>
>
>
>
>
> *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net]
> *Sent:* Saturday, May 03, 2014 1:33 AM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron][LBaaS]L7 conent switching APIs
>
>
>
> Hi Adam and Samuel!
>
>
>
> Thanks for the questions / comments! Reactions in-line:
>
>
>
> On Thu, May 1, 2014 at 8:14 PM, Adam Harwell
> wrote:
>
> Stephen, the way I understood your API proposal, I thought you could
> essentially combine L7Rules in an L7Policy, and have multiple L7Policies,
> implying that the L7Rules would use AND style combination, while the
> L7Policies themselves would use OR combination (I think I said that right,
> almost seems like a tongue-twister while I'm running on pure caffeine). So,
> if I said:
>
>
>
> Well, my goal wasn't to create a whole DSL for this (or anything much
> resembling this) because:
>
>1. Real-world usage of the L7 stuff is generally pretty primitive.
>Most L7Policies will consist of 1 rule. Those that consist of more than one
>rule are almost always the sort that need a simple sort. This is based off
>the usage data collected here (which admittedly only has Blue Box's data--
>because apparently nobody else even offers L7 right now?)
>
> https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc&usp=sharing
>2. I was trying to keep things as simple as possible to make it easier
>for load balancer vendors to support. (That is to say, I wouldn't expect
>all vendors to provide the same kind of functionality as HAProxy ACLs, for
>example.)
>
> Having said this, I think yours and Sam's clarification that different
> L7Policies can be used to effective "OR" conditions together makes sense,
> and therefore assuming all the Rules in a given policy are ANDed together
> makes sense.
>
>
>
> If we do this, it therefore also might make sense to expose other criteria
> on which L7Rules can be made, like HTTP method used for the request and
> whatnot.
>
>
>
> Also, should we introduce a flag to say whether a given Rule's condition
> should be negated? (eg. "HTTP method is GET and URL is *not* "/api") This
> would get us closer to being able to use more sophisticated logic for L7
> routing.
>
>
>
> Does anyone foresee the need to offer this kind of functionality?
>
>
>
> * The policy { rules: [ rule1: match path REGEX ".*index.*", rule2:
> match path REGEX "hello/.*" ] } directs to Pool A
>
> * The policy { rules: [ rule1: match hostname EQ "mysite.com" ] }
> directs to Pool B
>
> then order would matter for the policies themselves. In this case, if they
> ran in the order I listed, it would match "mysite.com/hello/index.htm"
> and direct it to Pool A, while "mysite.com/hello/nope.htm" would not
> match BOTH rules in the first policy, and would be caught by the second
> policy, directing it to Pool B. If I had wanted the first policy to use OR
> logic, I would have just s
Re: [openstack-dev] [Neutron][LBaaS] Use-Cases with VPNs Distinction
Hi Sam, So, If I understand you correctly, you don't think that specifying routing rules (eg. static routing configuration) should be beyond the scope of LBaaS? I agree that it might be possible to reach a given member over different routes. The example that comes to mind for me is a member with a public IP on the internet somewhere that's either accessible from the VIP address via the VIP's subnet's default gateway, or via a VPN service available on the same layer 2 network. But if we're going to support choosing routes to a given member, shouldn't this information be located with the member? I don't know why putting this information as properties of the VIP in the object model would make scheduling and placing the configuration any easier-- specifically, if you've got enough information / completed objects to deploy a load balancing service, wouldn't the service's pools and pool member information also be implicitly available as part of the overall configuration for the service? Thanks, Stephen On Sun, May 4, 2014 at 12:36 AM, Samuel Bercovici wrote: > Hi, > > > > I prefer a different approach (AKA, I oppose J) > > I think that this information should be properties of the VIP and not the > pool. > > So VIP should have: > > 1. VIP subnet (this is where the IP will be allocated) > > 2. List of members subnets (it could be optional. This means that > members have L2 proximity on the VIP subnet) > > 3. List of static routes (to be able to specify how to reach > members which are not on L2 proximity) – if not presented, this could be > calculated by the “driver” backend but sometimes where you can use multiple > different paths a user intervention might be required. > > > > I prefer this approach for the following: > > 1. Concentrating the L3 information in a single place (VIP) – this > also makes scheduling and placement of the configuration easier. > > 2. When using multiple pools (L7 content switching) that have > members on the same subnet, no need to repeat the subnet information > > > > Regards, > > -Sam. > > > > > > > > *From:* Adam Harwell [mailto:adam.harw...@rackspace.com] > *Sent:* Saturday, May 03, 2014 10:17 AM > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Use-Cases with VPNs > Distinction > > > > Sounds about right to me. I guess I agree with your agreement. :) > > Does anyone actually *oppose* this arrangement? > > > > --Adam > > > > *From: *Stephen Balukoff > *Reply-To: *"OpenStack Development Mailing List (not for usage > questions)" > *Date: *Friday, May 2, 2014 7:53 PM > *To: *"OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > *Subject: *Re: [openstack-dev] [Neutron][LBaaS] Use-Cases with VPNs > Distinction > > > > Hi guys, > > > > Yep, so what I'm hearing is that we should be able to assume that either > all members in a single pool are adjacent (ie. layer-2 connected), or are > routable from that subnet. > > > > Adam-- I could see it going either way with regard to how to communicate > with members: If the particular device that the provider uses lives > outside tenant private networks, the driver for said devices would need to > make sure that VIFs (or some logical equivalent) are added such that the > devices can talk to the members. This is also the case for virtual load > balancers (or other devices) which are assigned to the tenant but live on > an "external" network. (In this topology, VIP subnet and pool subnet could > differ, and the driver needs to make sure that the load balancer has a > virtual interface/neutron port + IP address on the pool subnet.) > > > > There's also the option that if the "device" being used for load balancing > exists as a virtual appliance that can be deployed on an internal network, > one can make it publicly accessible by adding a "neutron floating IP" (ie. > static NAT rule) that forwards any traffic destined for a public "external" > IP to the load balancer's internal IP address. (In this topology, VIP > subnet and pool subnet would be the same thing.) The nifty thing about this > topology is that load balancers that don't have this static NAT rule added > are implicitly "private" to the tenant internal subnet. > > > > Having seen what our customers do with their topologies, my gut reaction > is to say that the 99.9% use case is that all the members of a pool will be > in the same subnet, or routable f
Re: [openstack-dev] [Neutron][LBaaS] Use-Cases with VPNs Distinction
Hi guys, Yep, so what I'm hearing is that we should be able to assume that either all members in a single pool are adjacent (ie. layer-2 connected), or are routable from that subnet. Adam-- I could see it going either way with regard to how to communicate with members: If the particular device that the provider uses lives outside tenant private networks, the driver for said devices would need to make sure that VIFs (or some logical equivalent) are added such that the devices can talk to the members. This is also the case for virtual load balancers (or other devices) which are assigned to the tenant but live on an "external" network. (In this topology, VIP subnet and pool subnet could differ, and the driver needs to make sure that the load balancer has a virtual interface/neutron port + IP address on the pool subnet.) There's also the option that if the "device" being used for load balancing exists as a virtual appliance that can be deployed on an internal network, one can make it publicly accessible by adding a "neutron floating IP" (ie. static NAT rule) that forwards any traffic destined for a public "external" IP to the load balancer's internal IP address. (In this topology, VIP subnet and pool subnet would be the same thing.) The nifty thing about this topology is that load balancers that don't have this static NAT rule added are implicitly "private" to the tenant internal subnet. Having seen what our customers do with their topologies, my gut reaction is to say that the 99.9% use case is that all the members of a pool will be in the same subnet, or routable from the pool subnet. And I agree that if someone has a really strange topology in use that doesn't work with this assumption, it's not the job of LBaaS to try and solve this for them. Anyway, I'm hearing general agreement that subnet_id should be an attribute of the pool. On Fri, May 2, 2014 at 5:24 AM, Eugene Nikanorov wrote: > Agree with Sam here, > Moreover, i think it makes sense to leave subnet an attribute of the pool. > Which would mean that members reside in that subnet or are available > (routable) from this subnet, and LB should have a port on this subnet. > > Thanks, > Eugene. > > > On Fri, May 2, 2014 at 3:51 PM, Samuel Bercovici wrote: > >> I think that associating a VIP subnet and list of member subnets is a >> good choice. >> This is declaratively saying to where is the configuration expecting >> layer 2 proximity. >> The minimal would be the VIP subnet which in essence means the VIP and >> members are expected on the same subnet. >> >> Any member outside the specified subnets is supposedly accessible via >> routing. >> >> It might be an option to state the static route to use to access such >> member(s). >> On many cases the needed static routes could also be computed >> automatically. >> >> Regards, >>-Sam. >> >> On 2 במאי 2014, at 03:50, "Stephen Balukoff" >> wrote: >> >> Hi Trevor, >> >> I was the one who wrote that use case based on discussion that came out >> of the question I wrote the list last week about SSL re-encryption: >> Someone had stated that sometimes pool members are local, and sometimes >> they are hosts across the internet, accessible either through the usual >> default route, or via a VPN tunnel. >> >> The point of this use case is to make the distinction that if we >> associate a neutron_subnet with the pool (rather than with the member), >> then some members of the pool that don't exist in that neutron_subnet might >> not be accessible from that neutron_subnet. However, if the behavior of >> the system is such that attempting to reach a host through the subnet's >> "default route" still works (whether that leads to communication over a VPN >> or the usual internet routes), then this might not be a problem. >> >> The other option is to associate the neutron_subnet with a pool member. >> But in this case there might be problems too. Namely: >> >>- The device or software that does the load balancing may need to >>have an interface on each of the member subnets, and presumably an IP >>address from which to originate requests. >>- How does one resolve cases where subnets have overlapping IP ranges? >> >> In the end, it may be simpler not to associate neutron_subnet with a pool >> at all. Maybe it only makes sense to do this for a VIP, and then the >> assumption would be that any member addresses one adds to pools must be >> accessible from the VIP subnet. (Which is easy, if the VIP exists on the >> same neutron_subnet.
Re: [openstack-dev] [Neutron][LBaaS]L7 conent switching APIs
claration order, and the first one which matches will assign the backend. If this is true, this seem to imply that for HAProxy at least, order only really matters for policies which switch back-ends. That is to say, all the 'block' policies get processed first, followed by all the content modification policies, followed by the switching policies. If you have two conflicting content modification policies, what actually happens isn't defined in the manual (though again-- why would anyone do this? Seems like a scenario in which users shoot themselves in the foot.) Given this, it may make sense to enforce this order in our model somehow, assuming other load balancer vendors would want to duplicate this behavior. Otherwise, users might be confused why (for example) a modification rule is applying a header to a request when that policy comes after a switching policy in the overall list of policies. (One could do this by always inserting new 'block' policies in order before any 'modification' policies, and 'modification' policies before any 'redirect' policies, and not allowing any API updates to move any rules in a way that would violate this order.) Or, we could make that 'order' attribute only allowed (and necessary) for 'redirect' policies-- the implication being no order applies to block or content modification policies because they always get processed first. We could do this by splitting modification, block, and switching L7 policy types into their own separate objects (all of which would have similar 'rule' semantics), but I'm really not seeing a compelling reason to do so. (Again, I'm usually in favor of introducing fewer new objects.) What seems like the least confusing thing to do for the user? What are others' thoughts on this? Thanks, 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] Fulfilling Operator Requirements: Driver / Management API
via a Management API to allow > syncing/reloading existing LBs or moving them across clusters > (Recoverability, DDoS Mitigation). > This new driver would be named to reflect what features it provides, or at > least given a unique name that can be referenced without confusion > (something like "OpenHA" or "NovaHA" would work if that's not taken). > > -- > 2) Management API > -- > Going forward, it should then be required (can we enforce this?) that > any mainline driver include support for calls to handle these named > Operator Requirements, for example: obtaining logs (or log locations?), > diagnostic information, and admin type actions including rebuilding or > migrating LB instances. So far we haven't really talked about any of these > features in depth, though I believe the general need for a Management API > was alluded to on several occasions. Should we shelve this discussion until > after we have the User API specification locked down? Should we begin > defining a contract for this Management API at the summit, since it would > be the main gateway to the Operator Requirements that we have all been > stressing recently? > > -- > Summary > -- > I would apologize for not having much concrete specification here, but I > think it is better to validate my basic assumptions first, before jumping > deeper down this rabbit hole. The type of comments I'm hoping to prompt are > along the lines of: > * "We should just focus on the existing haproxy driver." > * "We should definitely collaborate to make a new driver as a community." > * "I don't think a Management API is necessary." > * "This is definitely what I was thinking we'd need to do." > Anything specific implementation details I've mentioned are intended be > taken as one possible example, not as a well thought out proposal. I am, as > one might say, "speaking my mind". My hope is that some of this will simmer > on the general subconscious. I'd like to hear what the general consensus is > on these topics, because these are some of the assumptions I've been > operating under during the rest of our discussions, and if they're invalid, > I may need to rebase my view on the API discussion as a whole. > > Thanks ya'll, I'm looking forward to getting some additional viewpoints! > --Adam Harwell (rm_work) > > ___ > 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 ___ 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 Use Cases Assessment and Questions
t; Use-Case 37: I'm not entirely sure what this one would mean. I know I > included it in the section that sounded more like features, but I was > still curious what this one referred to. Does this have to do with the > desire for auto-scaling? When a pool member gains a certain threshold > of connections another pool member is created or chosen to handle the > next connection(s) as they come? > Well, this one didn't come from me, but I think I know what it means: By 'backup servers' I think they're probably talking about how that terminology is used in haproxy. In haproxy, any member of a pool marked as a 'backup' will not be used unless all other members of the pool (which aren't marked backup) are unavailable. This could be used instead of showing an 'error 503' page, or to serve a reduced-functionality version of the site or whatever. In other words, this is an option to more gracefully handle site overload situations. > > Please feel free to correct me anywhere I've blundered here, and if my > proposed "solution" is inaccurate or not easily understood, I'd be more > than happy to explain in further detail. Thanks for any help you can > offer! > > -Trevor Vardeman > ___ > 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Use-Cases with VPNs Distinction
Hi Trevor, I was the one who wrote that use case based on discussion that came out of the question I wrote the list last week about SSL re-encryption: Someone had stated that sometimes pool members are local, and sometimes they are hosts across the internet, accessible either through the usual default route, or via a VPN tunnel. The point of this use case is to make the distinction that if we associate a neutron_subnet with the pool (rather than with the member), then some members of the pool that don't exist in that neutron_subnet might not be accessible from that neutron_subnet. However, if the behavior of the system is such that attempting to reach a host through the subnet's "default route" still works (whether that leads to communication over a VPN or the usual internet routes), then this might not be a problem. The other option is to associate the neutron_subnet with a pool member. But in this case there might be problems too. Namely: - The device or software that does the load balancing may need to have an interface on each of the member subnets, and presumably an IP address from which to originate requests. - How does one resolve cases where subnets have overlapping IP ranges? In the end, it may be simpler not to associate neutron_subnet with a pool at all. Maybe it only makes sense to do this for a VIP, and then the assumption would be that any member addresses one adds to pools must be accessible from the VIP subnet. (Which is easy, if the VIP exists on the same neutron_subnet. But this might require special routing within Neutron itself if it doesn't.) This topology question (ie. what is feasible, what do people actually want to do, and what is supported by the model) is one of the more difficult ones to answer, especially given that users of OpenStack that I've come in contact with barely understand the Neutron networking model, if at all. In our case, we don't actually have any users in the scenario of having members spread across different subnets that might not be be routable, so the use case is somewhat contrived, but I thought it was worth mentioning based on what people were saying in the SSL re-encryption discussion last week. On Thu, May 1, 2014 at 1:52 PM, Trevor Vardeman < trevor.varde...@rackspace.com> wrote: > Hello, > > After going back through the use-cases to double check some of my > understanding, I realized I didn't quite understand the ones I had > already answered. I'll use a specific use-case as an example of my > misunderstanding here, and hopefully the clarification can be easily > adapted to the rest of the use-cases that are similar. > > Use Case 13: A project-user has an HTTPS application in which some of > the back-end servers serving this application are in the same subnet, > and others are across the internet, accessible via VPN. He wants this > HTTPS application to be available to web clients via a single IP > address. > > In this use-case, is the Load Balancer going to act as a node in the > VPN? What I mean here, is the Load Balancer supposed to establish a > connection to this VPN for the client, and simulate itself as a computer > on the VPN? If this is not the case, wouldn't the VPN have a subnet ID, > and simply be added to a pool during its creation? If the latter is > accurate, would this not just be a basic HTTPS Load Balancer creation? > After looking through the VPNaaS API, you would provide a subnet ID to > the create VPN service request, and it establishes a VPN on said subnet. > Couldn't this be provided to the Load Balancer pool as its subnet? > > Forgive me for requiring so much distinction here, but what may be clear > to the creator of this use-case, it has left me confused. This same > type of clarity would be very helpful across many of the other > VPN-related use-cases. Thanks again! > > -Trevor > _______ > 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Use Case Question
Question for those of you using the SSL session ID for persistency: About how long do you typically set these sessions to persist? Also, I think this is a cool way to handle this kind of persistence efficiency-- I'd never seen it done that way before, eh! It should also almost go without saying that of course in the case where the SSL session is not terminated on the load balancer, you can't do anything else with the content (like insert X-Forwarded-For headers or do anything else that has to do with L7). Stephen On Wed, Apr 30, 2014 at 9:39 AM, Samuel Bercovici wrote: > Hi, > > > > As stated, this could either be handled by SSL session ID persistency or > by SSL termination and using cookie based persistency options. > > If there is no need to inspect the content hence to terminate the SSL > connection on the load balancer for this sake, than using SSL session ID > based persistency is obviously a much more efficient way. > > The reference to source client IP changing was to negate the use of source > IP as the stickiness algorithm. > > > > > > -Sam. > > > > > > *From:* Trevor Vardeman [mailto:trevor.varde...@rackspace.com] > *Sent:* Thursday, April 24, 2014 7:26 PM > *To:* openstack-dev@lists.openstack.org > *Subject:* [openstack-dev] [Neutron][LBaaS] Use Case Question > > > > Hey, > > > > I'm looking through the use-cases doc for review, and I'm confused about > one of them. I'm familiar with HTTP cookie based session persistence, but > to satisfy secure-traffic for this case would there be decryption of > content, injection of the cookie, and then re-encryption? Is there another > session persistence type that solves this issue already? I'm copying the > doc link and the use case specifically; not sure if the document order > would change so I thought it would be easiest to include both :) > > > > Use Cases: > https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis > > > > Specific Use Case: A project-user wants to make his *secured *web based > application (HTTPS) highly available. He has n VMs deployed on the same > private subnet/network. Each VM is installed with a web server (ex: apache) > and content. The application requires that a transaction which has started > on a specific VM will continue to run against the same VM. The application > is also available to end-users via smart phones, a case in which the end > user IP might change. The project-user wishes to represent them to the > application users as a web application available via a single IP. > > > > -Trevor Vardeman > > ___ > 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS]L7 conent switching APIs
rder' attribute from L7Rules because if all the conditions that make up a policy are OR'ed together, then order no longer matters. If we want to define a more feature-rich DSL here, then rule order would matter. (Note that the order in which entire L7Policies appear still matters. The first one to match wins in the case of a 'redirect' match, eh.) > > > Regards, > > -Avishay, Evgeny and Sam > > > > > -- 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]User Stories and sruvey
German, They certainly are essential-- but as far as I can tell, we haven't been concentrating on them, so the list there is likely very incomplete. Stephen On Thu, May 1, 2014 at 1:04 PM, Eichberger, German wrote: > Stephen, > > > > I would prefer if we can vote on them, too. They are essential and I would > like to make sure they are considered first-class citizen when it comes to > use cases. > > > > Thanks, > > German > > > > *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net] > *Sent:* Thursday, May 01, 2014 12:52 PM > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey > > > > Yep, I'm all for this as well! > > > > Note: We're just talking about "user" use cases in this survey, correct? > (We'll leave the operator use cases for later when we have more of a story > and/or model to work with on how we're going to approach those, yes?) > > > > Thanks, > > Stephen > > > > On Thu, May 1, 2014 at 11:54 AM, Jorge Miramontes < > jorge.miramon...@rackspace.com> wrote: > > That sounds good to me. The only thing I would caution is that we have > prioritized certain requirements (like HA and SSL Termination) and I want > to ensure we use the survey to compliment what we have already mutually > agreed upon. Thanks for spearheading this! > > > > Cheers, > > --Jorge > > > > *From: *Samuel Bercovici > *Reply-To: *"OpenStack Development Mailing List (not for usage > questions)" > *Date: *Thursday, May 1, 2014 12:39 PM > *To: *"OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > *Subject: *[openstack-dev] [Neutron][LBaaS]User Stories and sruvey > > > > Hi Everyone! > > > > To assist in evaluating the use cases that matter and since we now have > ~45 use cases, I would like to propose to conduct a survey using something > like surveymonkey. > > The idea is to have a non-anonymous survey listing the use cases and ask > you identify and vote. > > Then we will publish the results and can prioritize based on this. > > > > To do so in a timely manner, I would like to freeze the document for > editing and allow only comments by Monday May 5th 08:00AMUTC and publish > the survey link to ML ASAP after that. > > > > Please let me know if this is acceptable. > > > > Regards, > > -Sam. > > > > > > > > > ___ > 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 > > ___ > 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey
Yep, I'm all for this as well! Note: We're just talking about "user" use cases in this survey, correct? (We'll leave the operator use cases for later when we have more of a story and/or model to work with on how we're going to approach those, yes?) Thanks, Stephen On Thu, May 1, 2014 at 11:54 AM, Jorge Miramontes < jorge.miramon...@rackspace.com> wrote: > That sounds good to me. The only thing I would caution is that we have > prioritized certain requirements (like HA and SSL Termination) and I want > to ensure we use the survey to compliment what we have already mutually > agreed upon. Thanks for spearheading this! > > Cheers, > --Jorge > > From: Samuel Bercovici > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Thursday, May 1, 2014 12:39 PM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey > >Hi Everyone! > > > > To assist in evaluating the use cases that matter and since we now have > ~45 use cases, I would like to propose to conduct a survey using something > like surveymonkey. > > The idea is to have a non-anonymous survey listing the use cases and ask > you identify and vote. > > Then we will publish the results and can prioritize based on this. > > > > To do so in a timely manner, I would like to freeze the document for > editing and allow only comments by Monday May 5th 08:00AMUTC and publish > the survey link to ML ASAP after that. > > > > Please let me know if this is acceptable. > > > > Regards, > > -Sam. > > > > > > > > > ___ > 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Thoughts on current process
Jorge, In looking over your API proposal linked above, have things significantly changed there since you sent it out two weeks ago? (And if so, which parts should I take a look at again?) Thanks, Stephen On Wed, Apr 30, 2014 at 5:07 PM, Stephen Balukoff wrote: > Hi Jorge! > > +1 to everything you just said. In fact, I think you said essentially what > I was trying to last week with 100% less drama. > > I'll work to add workflows to my proposal, but please note it's late on a > Wednesday and tomorrow's IRC meeting is awfully early in my time zone. I > probably won't have workflow documentation done in time. > > Thanks, > Stephen > > > > On Wed, Apr 30, 2014 at 3:26 PM, Jorge Miramontes < > jorge.miramon...@rackspace.com> wrote: > >> Oops! Everywhere I said Samuel I meant Stephen. Sorry you both have SB as >> you initials so I got confused. :) >> >> Cheers, >> --Jorge >> >> >> >> >> On 4/30/14 5:17 PM, "Jorge Miramontes" >> wrote: >> >> >Hey everyone, >> > >> >I agree that we need to be preparing for the summit. Using Google docs >> >mixed with Openstack wiki works for me right now. I need to become more >> >familiar the gerrit process and I agree with Samuel that it is not >> >conducive to "large" design discussions. That being said I'd like to add >> >my thoughts on how I think we can most effectively get stuff done. >> > >> >As everyone knows there are many new players from across the industry >> that >> >have an interest in Neutron LBaaS. Companies I currently see >> >involved/interested are Mirantis, Blue Box Group, HP, PNNL, Citrix, >> >eBay/Paypal and Rackspace. We also have individuals involved as well. I >> >echo Kyle's sentiment on the passion everyone is bringing to the project! >> >Coming into this project a few months ago I saw that a few things needed >> >to be done. Most notably, I realized that gathering everyone's >> >expectations on what they wanted Neutron LBaaS to be was going to be >> >crucial. Hence, I created the requirements document. Written requirements >> >are important within a single organization. They are even more important >> >when multiple organizations are working together because everyone is >> >spread out across the world and every organization has a different >> >development process. Again, my goal with the requirements document is to >> >make sure that everyone's voice in the community is taken into >> >consideration. The benefit I've seen from this document is that we ask >> >"Why?" to each other, iterate on the document and in the end have a clear >> >understanding of everyone's motives. We also learn from each other by >> >doing this which is one of the great benefits of open source. >> > >> >Now that we have a set of requirements the next question to ask is, "How >> >doe we prioritize requirements so that we can start designing and >> >implementing them"? If this project were a completely new piece of >> >software I would argue that we iterate on individual features based on >> >anecdotal information. In essence I would argue an agile approach. >> >However, most of the companies involved have been operating LBaaS for a >> >while now. Rackspace, for example, has been operating LBaaS for the >> better >> >part of 4 years. We have a clear understanding of what features our >> >customers want and how to operate at scale. I believe other operators of >> >LBaaS have the same understanding of their customers and their >> operational >> >needs. I guess my main point is that, collectively, we have data to back >> >up which requirements we should be working on. That doesn't mean we >> >preclude requirements based on anecdotal information (i.e. "Our customers >> >are saying they want new shiny feature X"). At the end of the day I want >> >to prioritize the community's requirements based on factual data and >> >anecdotal information. >> > >> >Assuming requirements are prioritized (which as of today we have a pretty >> >good idea of these priorities) the next step is to design before laying >> >down any actual code. I agree with Samuel that pushing the cart before >> the >> >horse is a bad idea in this case (and it usually is the case in software >> >development), especially since we have a pretty clear idea on what we >> need >> >to be designing for. I
Re: [openstack-dev] [Neutron][LBaaS] Thoughts on current process
much as possible first. However, in this case we have a > >particular set of requirements that changes the game. Particularly, > >operator requirements have not been given the attention they deserve. > > > >I think of Openstack as being cloud software that is meant to operate at > >scale and have the necessary operator tools to do so. Otherwise, why do we > >have so many companies interested in Openstack if you can't operate a > >cloud that scales? In the case of LBaaS, user/feature requirements and > >operator requirements are not necessarily mutually exclusive. How you > >design the system in regards to one set of requirements affects the design > >of the system in regards to the other set of requirements. SSL > >termination, for example, affects the ability to scale since it is CPU > >intensive. As an operator, I need to know how to provision load balancer > >instances efficiently so that I'm not having to order new hardware more > >than I have to. With this in mind, I am assuming that most of us are > >vendor-agnostic and want to cooperate in developing an open source driver > >while letting vendors create their own drivers. If this is not the case > >then perhaps a lot of the debates we have been having are moot since we > >can separate efforts depending on what driver we want to work on. The only > >item of Neutron LBaaS that we need to have consensus on then is the API > >(web app, database, messaging system, etc.). Keep in mind that the API > >implies what feature/user requirements are satisfied, but no so much for > >operator requirements. I think this is one reason why we have been working > >on API proposals. Samuel, thank you for the time you spent on your > >proposal as we know how much time and effort it takes. > > > >Because several of us have been spending large amounts of time on API > >proposals, and because we can safely assume that most operational > >requirements are abstracted into the driver layer I say we continue the > >conversation around the different proposals since this is the area we > >definitely need consensus on. So far there are three proposals--Stephen's, > >Rackspace's and Eugene's. To date, we honestly haven't had an actual > >discussion on the pros and cons of each proposal. To give structure to > >this we here at Rackspace have been going to great lengths to make sure we > >have enough tangible documentation in order to clearly convey our > >thoughts. We also went to great lengths to satisfy the user/feature > >requirements in our API. Here is what we have done: > > > >- An API specification located here ==> > > > https://docs.google.com/document/d/1mTfkkdnPAd4tWOMZAdwHEx7IuFZDULjG9bTmWy > >X > >e-zo/edit > >- Single API call workflows & multiple API call workflows of each of the > >use cases (#1 through #9 for now) from > > > https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXu > >S > >INis/edit#heading=h.48fieovwttzg. Our workflows are located here ==> > >https://drive.google.com/#folders/0B2r4apUP7uPwRVc2MzQ2MHNpcE0 > >- A lightweight proof of concept that is in the works so that people that > >need to actually send requests to an API to believe in it can do so. We > >will send an update in a few days when this POC is complete. > > > >In order to fairly compare proposals I think it would be nice if each > >proposal give workflows on how their API will operate. This is isn't > >necessary but I think it will definitely give structure in any discussions > >we have when comparing. If others have thoughts on how to compare the > >proposals on equal footing then by all means speak up. > > > >Once we come to a consensus on the API then we can figure out how to make > >iterative changes in order to get the API to the consensus state. That is > >a separate conversation in my mind. First we need to agree on a spec > >without the confines of looking at current implementation. > > > > > >Cheers, > >--Jorge > > > > > >P.S. Sorry for the delay in responding to the ML. Just reading them takes > >several hours. > > > > > >___ > >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 > -- 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]Conforming to Open Stack API style in LBaaS
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 > > -- 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] BBG edit of new API proposal
Per Samuel's request, I have set my API proposal document to be edit-able by all. Also, my work priorities have changed somewhat in preparation for the summit in two weeks, so I may not be able to add more use cases prior to the summit. On Tue, Apr 29, 2014 at 3:55 AM, Samuel Bercovici wrote: > Hi, > > I think it is a good idea to have the use cases in a different document > that API proposals (Stephen's, included) > Once we declare the uses cases done for Juno, I will move it to the BP > repository. > I would also like to see operator's use cases flushed out in the document. > > Stephen, could you please open the document also for editing? > > Regards, > -Sam. > > > > > -Original Message- > From: Kyle Mestery [mailto:mest...@noironetworks.com] > Sent: Tuesday, April 29, 2014 5:27 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal > > On Mon, Apr 28, 2014 at 6:23 PM, Stephen Balukoff > wrote: > > Hi guys, > > > > Sorry for all the drama on the list lately. > > > Not a problem. Like I said, the passion from all sides is great, and I'm > especially happy to see all the operators engaging with Neutron for LBaaS. > > > Kyle: I appreciate the sentiment. I'd also be happy to open up my API > > doc for general editing by people on the internet (and not just > > comments) if you think that would help. > > > My main reason for asking this was in case the gerrit bar was too high for > new people to Neutron and LBaaS in particular. I want to make sure we > capture everyone's ideas and allow everyone a chance to comment. > The gerrit BP process does this nicely, but I just want to ensure it's not > too high of a bar for people new to the entire process. > > > For us new-comers to the OpenStack project environment, what do people > > usually use for discussing potential design changes (and especially > > large design changes)? (From my perspective, Blue prints seem mostly > > useful as collections of links to other documents, without having an > > obvious way to discuss things in the blueprint directly. Gerrit seems > > like it's mostly "github workflow" with CI baked in-- ie. useful for > > specific smaller code changes, but not as much for design-level > > discussions. I suppose etherpads might duplicate much of the > > functionality we're currently using google docs to accomplish (though > > I don't think etherpads have the ability to do spreadsheets, from what I > can tell). > > > I think it's fine to use the gdoc for now, with the idea being we will > then converge on work items formed into multiple BPs out of the gdoc. > So perhaps it does make sense to use your document as the communal > starting point for this. But I'm open to what others may say as well. > > > As far as the meetings go: It might help if you could share with us > > what you hope to accomplish prior to the summit, and what kinds of > > things you'd like us to be prepared to discuss at the summit. (Is > > there an LBaaS meeting of some kind scheduled there yet?) > > > I've given LBaaS 2 40 minute sessions. What I'd like us to do is come to > come to a consensus on what needs discussing in person vs. what everyone is > agreeing on and we don't need to discuss in those sessions. If we need time > to discuss the object model and API in Atlanta, that's fine too. > > > For my part, I plan on concentrating on filling out more use cases and > > then returning to the software load balancer virtual appliance porting > > project that's been on the back-burner for way too long for me. > > > Perfect! How about if we try to close the use case gap for this week's > LBaaS meeting. Then, next week we can at least make a stab at the object > model and API which satisfies as many use cases as we come up with. > > > Samuel and German: I've gone ahead and added around 20 new use cases > > to the google doc you linked. More will be on the way, but I'm happy > > to add these to gerrit myself if you'd prefer, so long as I can see > > how you're doing this for the first use cases and can follow your > > template. Let me know if you'd like me to change what I've been doing > > here, eh! Note also that so far these are only "user" use cases; It > > doesn't look like admin/operator use cases have been filled out at all > yet. > > > Getting the admin/operator use cases in there would be good as well > Stephen. > > Thanks, > Kyle >
Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal
roduct. > > > > It's just now they suddenly became exploratory. Because someone has > > introduced whole set of new requirements that didn't exist at the > > point when the design and the code was written. While it's fine to > > adopt and reevaluate them with new requirements, it's not fine to say > > folks didn't have their requirements. > > > >> Whenever I see this done, where assumptions about how the pieces fit > >> together are not re-evaluated once exploratory POCs have yielded more > >> knowledge or where said POCs end up becoming the final product, I see > >> significant design flaws that get baked into final products. Why do > >> y'all think it's been so hard to get "VIP" and "Listener" and "Pool" > >> separated into separate entities? > > > > It's not hard at all. Explaining obvious things and getting consensus > > is hard. > > > >> My proposal is a design discussion. > > > > My opinion is that design discussion alone can be split by features. > > My opinion is that while there are some dependencies between features, > > they are not such that design discussion can't be split. > > Exact design of L7 rules is not required to know how to move 'root > object' > > role from Pool to Vip. > > Exact design of SSL is not required to know how to allow multiple tcp > > endpoints. > > > >> Look, I agree that splitting out VIP, Listener, and Pool to be their > >> own objects, and moving the "root" of the object tree to the VIP is > >> probably the right thing to do. But there are valuable contributors > >> in this discussion who are still not on-board with this idea. So why > >> is this fundamental design discussion being closed early? That was the > point of my comment. > > > > So the discussion has been held up for whole release cycle, with two > > last months this particular proposal being out on the wiki and > > discussed on the meetings. And then again people say about 'duct > > taping' current API and 'convenience of legacy developers'. How valuable > is that?! > > Especially given the fact the proposal on gerrit describes the part > > which actually had the consensus on the meetings, I might also ask - > > are people reading other's specs at all? > > > > > > Eugene. > > > > ___ > > 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 > > ___ > 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 > -- 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] BBG edit of new API proposal
27;d > keep it out of scope of 'API improvement' work. > 2) ipv6_subnet_id/addressv6 - that IMO also deserves it's own > miniblueprint (whole thing about ipv6 support) > Yep, custom_503 is extremely minor, and its use case is "User would like to have custom error 503 page displayed on HTTP / HTTPS requests when no servers are available in the back-end pool(s)." IPv6 discussions are quite a bit more involved-- but I will note that at least one major vendor mentioned this as a high priority item, (and it turns out it's easy to address in the model) which is why we threw it in this proposal. > So, I'd like to make the following action items out of the document: > > 1. Extract 'core API' - VIPs/Listeners/Pools/Members/Healthmonitors. > This action item is actually the blueprint that I've filed and that's what > I'm going to implement > "that's what I'm going to implement"-- ie. Discussion is closed on this. > 2. Work on defining single-call API that goes along with single object > core API (above) > Your document already does a very good job on this front. > Thank you. It's nice to know some of my work is being paid attention to. > 3. Extract 'Loadbalancer' portion of API into additional Doc/blueprint. I > deserves it's own discussion and use cases. > I think separating it will also help to reduce discussion contention. > Fine, though I would say that justifying the "VIP-centric" approach becomes more difficult if we're not starting to think about how we're going to address operator concerns (like, say, HA) and how these potentially intersect and/or interface with user concerns. > 4. Work with https://review.openstack.org/#/c/89903/ to define proper > attribute placement of existing attributes > Given that you totally ignored (or planned to ignore) the work you knew I was doing on this API proposal in writing the above blueprint... does my opinion on the attribute placement even matter at this point? > 5. Define a set of attributes that are missing in proposed API and make a > list of work items based on that. > (I assume that there also could be some, that may make sense to include in > proposal) > This stems directly from use cases. Please also point out which attributes are mutable after creation and which are not. I'm still of the (perhaps misguided) opinion that if I share these use cases, someone is actually going to pay attention to them, so my plan is to work on fleshing these out before I do anything regarding arguing over attribute placement. > I think following this list will actually help us to make iterative > progress and also to work on items in parallel. > > Thanks again for the great document! > Right. Thanks, 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] Use Case Question
Hi Trevor, If the use case here requires the same client (identified by session cookie) to go to the same back-end, the only way to do this with HTTPS is to decrypt on the load balancer. Re-encryption of the HTTP request may or may not happen on the back-end depending on the user's needs. Again, if the client can potentially change IP addresses, and the session still needs to go to the same back-end, the only way the load balancer is going to know this is by decrypting the HTTPS request. I know of no other way to make this work. Stephen On Thu, Apr 24, 2014 at 9:25 AM, Trevor Vardeman < trevor.varde...@rackspace.com> wrote: > Hey, > > I'm looking through the use-cases doc for review, and I'm confused about > one of them. I'm familiar with HTTP cookie based session persistence, but > to satisfy secure-traffic for this case would there be decryption of > content, injection of the cookie, and then re-encryption? Is there another > session persistence type that solves this issue already? I'm copying the > doc link and the use case specifically; not sure if the document order > would change so I thought it would be easiest to include both :) > > Use Cases: > https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis > > Specific Use Case: A project-user wants to make his secured web based > application (HTTPS) highly available. He has n VMs deployed on the same > private subnet/network. Each VM is installed with a web server (ex: apache) > and content. The application requires that a transaction which has started > on a specific VM will continue to run against the same VM. The application > is also available to end-users via smart phones, a case in which the end > user IP might change. The project-user wishes to represent them to the > application users as a web application available via a single IP. > > -Trevor Vardeman > > ___ > 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Use cases document
Hi Samuel, I'm a little confused what you're asking for: Do you want us to add use cases to the document directly, or discuss them here first and then someone (presumably you?) adds them to the document after it's agreed it's a valid use case? It sounds like one or more of the use cases you've collected so far might have gone missing. Does it make sense to move the list of use cases to the wiki, then, where everyone can edit and there's history kept so mistakes can be rolled back easily? (I ask, because I've been thinking of new use cases all week as I've been working on the API revision proposal, and I'd like to get them recorded and / or discussed.) Stephen On Tue, Apr 22, 2014 at 1:26 AM, Samuel Bercovici wrote: > Hi, > > > > I have seen a few addition to > https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?pli=1 > > I think that it would make sense to keep this document with uses cases > that were discussed in ML. > > A use case that I have seen and is missing is related to availability > zones. > > Please feel free to update this and add your own to the document. > > > > I have also added sections for Cloud Admin/Cloud Operator use cases. > Please add additional use cases based on your experience. > > > > Regards, > > -Sam. > > > > ___ > 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal
.. take a closer look at your object model. There's probably a way
to do it without the join. :)
> 9. can pool members be shared between pools on the same tenant?
>-if so, what happens if two pools are sharing the same pool member, one
> pool has a health monitor, the other does not. The pool member's status
> will get updated to "DOWN" for both pools.
>-if not, why not just make them children resources of /pools (i.e.
> /pools/{pool_id}/members).
>
The answer is: No. And you're right! We could easily make members a pure
leaf primitive connected to the pool primitive. This would mean that when
the pool is destroyed, the members are implicitly destroyed. The same is
true for L7Rules and L7Policies.
Can anyone think of an instance where a user might want to destroy a pool,
but leave its member primitives intact (presumably so they could be
attached to another pool at a later time)?
Absent any counterexamples, I'm all for making Members a leaf primitive of
Pools, and L7Rules a leaf primitive of L7Policies.
>
> Again, thanks for spending the time on this. It has a lot of good ideas
> and things we did not think about. We've been requested to do a POC of our
> proposal, will you and your team be able to do the same?
>
No problem, eh! I'm glad you've apparently found it useful. :)
And... I guess it depends on what form the POC has to take. Blue Box is a
much, much smaller organization than Rackspace, so we don't have nearly the
amount of man-power for pursuing POCs and whatnot as I would like. (It's a
normal course of events for prototypes we build to end up being put into
production for a given customer shortly thereafter. We do a lot of custom
things for our customers, and occasionally we get to build something more
general purpose, like the load balancer software appliances we made...)
Assuming we're still making progress in the discussion on things like this
API revision, or how exactly we're going to solve the operator concerns
around HA functionality... I'm hoping to spend more time porting our
software appliance to a form that can be deployed on-demand for OpenStack.
(We're open-sourcing the software appliance for this purpose-- so far,
though, I've only had time to work on refining its API documentation...
which is of course not the same one we've been discussing here. XD)
What did you have in mind, as far as a POC is concerned?
Thanks,
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
[openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal
Hi y'all! As discussed in last week's IRC meeting, my team members and I have produced a revised draft of the API v2.0 proposal started last week by the Rackspace crew. (Thanks again for this, y'all-- this helped us get a heck of a head start on our revised proposal.) Our v2.0 API proposal revision can be found here: https://docs.google.com/document/d/129Da7zEk5p437_88_IKiQnNuWXzWaS_CpQVm4JBeQnc/edit?usp=sharing (I've enabled commenting on the above google doc, but for longer discussion of fundamental issues, let's keep that to this mailing list, eh!) Please also pay attention to the Introduction section of this document: I've defined which glossary of terms we're using there and provided links to a proposed corresponding object model diagram and its source. Further, I've pointed out decisions we made drafting this API as well as issues not yet addressed. I would appreciate your feedback on all of this (again, the discussions for which should probably happen on this mailing list). To get to some of the points I know a lot of people will be interested in: - This proposal does include a single-call interface for both creation and deletion, and yes, all primitives can be created through it. - This proposal does include L7 functionality support, based somewhat loosely on the ideas represented here: https://wiki.openstack.org/wiki/Neutron/LBaaS/l7 - This proposal does include SSL termination and re-encryption support, based loosely both on what we already do in our envionment, as well as this: https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL - We have also tried to keep in mind features in use and requested in the following two documents as well: https://wiki.openstack.org/wiki/Neutron/LBaaS/requirements https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc&usp=sharing - HA functionality is not addressed in this document, per se, other than expressing the conviction that however this is handled will probably not affect the user API expressed in this document. (We have an ongoing discussion about this going on in another mailing list thread-- and now that I'm not neck deep in API documentation I'll probably jump back onto this in the next couple of days.) And... I think that's about it. Please have fun ripping this draft to shreds! Thanks, 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] SSL re-encryption scenario question
German: I'm hearing from a lot of different sources / organizations on this list that re-encryption at the load balancer is a must-have feature. And I was already part of previous discussions on SSL functionality. ( https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL ) Also, even if the load balancer does support re-encryption on the back-end, this doesn't prevent users from using a VPN-based solution either. Stephen On Mon, Apr 21, 2014 at 11:51 AM, Eichberger, German < german.eichber...@hp.com> wrote: > Hi, > > > > Despite there are some good use cases for the re-encryption I think it’s > out of scope for a Load Balancer. We can defer that functionality to the > VPN – as long as we have a mechanism to insert a LoadBalancer as a VPN node > we should get all kind of encryption infrastructure “for free”. > > > > I like the Unix philosophy of little programs doing one task very well and > can be chained. So in our case we might want to chain a firewall to a load > balancer to a VPN to get the functionality we want. > > > > Thoughts? > > > > German > > > > *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net] > *Sent:* Friday, April 18, 2014 9:07 PM > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][LBaaS] SSL re-encryption > scenario question > > > > Hi y'all! > > > > Carlos: When I say 'client cert' I'm talking about the certificate / key > combination the load balancer will be using to initiate the SSL connection > to the back-end server. The implication here is that if the back-end server > doesn't like the client cert, it will reject the connection (as being not > from a trusted source). By 'CA cert' I'm talking about the certificate > (sans key) that the load balancer will be using the authenticate the > back-end server. If the back-end server's "server certificate" isn't signed > by the CA, then the load balancer should reject the connection. > > > > Of course, the use of a client cert or CA cert on the load balancer should > be optional: As Clint pointed out, for some users, just using SSL without > doing any particular authentication (on either the part of the load > balancer or back-end) is going to be good enough. > > > > Anyway, the case for supporting re-encryption on the load-balancers has > been solidly made, and the API proposal we're making will reflect this > capability. Next question: > > > > When specific client certs / CAs are used for re-encryption, should these > be associated with the pool or member? > > > > I could see an argument for either case: > > > > *Pool* (ie. one client cert / CA cert will be used for all members in a > pool): > > * Consistency of back-end nodes within a pool is probably both extremely > common, and a best practice. It's likely all will be accessed the same way. > > * Less flexible than certs associated with members, but also less > complicated config. > > * For CA certs, assumes user knows how to manage their own PKI using a CA. > > > > *Member* (ie. load balancer will potentially use a different client cert > / CA cert for each member individually): > > * Customers will sometimes run with inconsistent back-end nodes (eg. > "local" nodes in a pool treated differently than "remote" nodes in a pool). > > * More flexible than certs associated with members, more complicated > configuration. > > * If back-end certs are all individually self-signed (ie. no single CA > used for all nodes), then certs must be associated with members. > > > > What are people seeing "in the wild"? Are your users using > inconsistently-signed or per-node self-signed certs in a single pool? > > > > Thanks, > > Stephen > > > > > > > > > > On Fri, Apr 18, 2014 at 5:56 PM, Carlos Garza > wrote: > > > > On Apr 18, 2014, at 12:36 PM, Stephen Balukoff > wrote: > > > > Dang. I was hoping this wasn't the case. (I personally think it's a > little silly not to trust your service provider to secure a network when > they have root access to all the machines powering your cloud... but I > digress.) > > > > Part of the reason I was hoping this wasn't the case, isn't just because > it consumes a lot more CPU on the load balancers, but because now we > potentially have to manage client certificates and CA certificates (for > authenticating from the proxy to back-end app servers). And we also have to > decide whether we allow the proxy to use a different client cert / CA per > pool, or p
Re: [openstack-dev] [Neutron][LBaas] "Single call" API discussion
Hi y'all! Yes-- I agree that is a very bad idea to delete a primitive that's being shared by other load balancing configurations. The only case where this seems acceptable to me is the case that German mentioned where all assets on a given user's account are being wrapped up. But even in this case, assuming each load balancing service is being deleted from the root level, eventually none of the primitives will be shared anymore... In fact, what do y'all think of this policy? If a primitive is shared at all, an attempt to delete it directly should return an error indicating it's still in use. Also, I've been making this assumption the whole time, but it's probably worth mentioning: I'm assuming primitives cannot be shared among tenants. (It seems to me that we'd be opening up a whole nasty can of worms security-wise if we allowed tenants to share primitives.) Here's an alternate idea for handling the case of abandoned primitives suggested by my team-mate Dustin Lundquist: Instead of doing any kind of cascading delete when a root object gets deleted, follow Brandon's idea and simply detach the primitives from the object being deleted. Later, a periodic garbage-collection process goes through and removes any orphaned primitives a reasonable interval after it was orphaned (this interval could be configurable per operator, per tenant, per user... whatever). If we do this: * Each primitive would need an additional 'orphaned_at' attribute * Primitives (other than the root object) created outside of a single-call interface would be created in an orphaned state. * Viewing the attributes of a primitive should also show whether it's an orphan, and if so, when the garbage collector will delete it. * Update and creation tasks that reference any connected primitives would clear the above orphaned_at attributes of said primitives * Deletion tasks would need to check connected primitives and update their orphaned_at attribute if said deletion orphans the primitive (ie. do an immediate reference check, set orphaned_at if references = 0) * It probably also makes sense to allow some primitives to have a flag set by the user to prevent garbage collection from ever cleaning them up (ex. SSL certificates are probably a good candidate for this). Maybe a "persist" boolean attribute or something? * Garbage collection never cleans up root objects. It seems to me the above: * Would prevent the CI user from having a bazillion orphaned primitives. * Does not immediately nuke anything the customer wasn't planning on nuking * Probably follows the principle of least surprise a little better than my previous "conditional cascading delete" suggestion * Still allows the simple act of deleting all the root objects to eventually delete all primitives on an account (ie. the "delete this account" task German was talking about.) * Has a secondary side-benefit of not immediately destroying all the supporting primitives of an object if the user accidentally nukes the wrong object. Also, it may be appropriate for some primitives to skip the garbage collection process and simply get deleted when their immediate parent primitive is deleted. This applies to primitives that aren't allowed to be shared, like: * Members (ie, deleting a pool deletes all its members, immediately) * "join" objects, like the 'rule' object that associates a listener with a non-default pool in the case of L7 switching I still like the idea of also having a cascading delete of some kind, in case the user wants to see all the primitives go away immediately (though they could always step through these themselves), or, again, as an immediate way to ensure all objects associated with a customer account are cleaned up quickly when the account is deleted. Though, I'm also thinking this should be an explicit flag the user has to set. (And again, even with this flag set, shared primitives are not deleted.) What do y'all think of the above idea? Thanks, Stephen On Fri, Apr 18, 2014 at 2:35 PM, Carlos Garza wrote: > > On Apr 17, 2014, at 8:39 PM, Stephen Balukoff > wrote: > > Hello German and Brandon! > > Responses in-line: > > > On Thu, Apr 17, 2014 at 3:46 PM, Brandon Logan < > brandon.lo...@rackspace.com> wrote: > >> Stephen, >> I have responded to your questions below. >> >> >> On 04/17/2014 01:02 PM, Stephen Balukoff wrote: >> >> Howdy folks! >> >> Based on this morning's IRC meeting, it seems to me there's some >> contention and confusion over the need for "single call" functionality for >> load balanced services in the new API being discussed. This is what I >> understand: >> >> * Those advocating "single call" are arguing that this simplifies the >> API for
Re: [openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario question
Hi y'all! Carlos: When I say 'client cert' I'm talking about the certificate / key combination the load balancer will be using to initiate the SSL connection to the back-end server. The implication here is that if the back-end server doesn't like the client cert, it will reject the connection (as being not from a trusted source). By 'CA cert' I'm talking about the certificate (sans key) that the load balancer will be using the authenticate the back-end server. If the back-end server's "server certificate" isn't signed by the CA, then the load balancer should reject the connection. Of course, the use of a client cert or CA cert on the load balancer should be optional: As Clint pointed out, for some users, just using SSL without doing any particular authentication (on either the part of the load balancer or back-end) is going to be good enough. Anyway, the case for supporting re-encryption on the load-balancers has been solidly made, and the API proposal we're making will reflect this capability. Next question: When specific client certs / CAs are used for re-encryption, should these be associated with the pool or member? I could see an argument for either case: *Pool* (ie. one client cert / CA cert will be used for all members in a pool): * Consistency of back-end nodes within a pool is probably both extremely common, and a best practice. It's likely all will be accessed the same way. * Less flexible than certs associated with members, but also less complicated config. * For CA certs, assumes user knows how to manage their own PKI using a CA. *Member* (ie. load balancer will potentially use a different client cert / CA cert for each member individually): * Customers will sometimes run with inconsistent back-end nodes (eg. "local" nodes in a pool treated differently than "remote" nodes in a pool). * More flexible than certs associated with members, more complicated configuration. * If back-end certs are all individually self-signed (ie. no single CA used for all nodes), then certs must be associated with members. What are people seeing "in the wild"? Are your users using inconsistently-signed or per-node self-signed certs in a single pool? Thanks, Stephen On Fri, Apr 18, 2014 at 5:56 PM, Carlos Garza wrote: > > On Apr 18, 2014, at 12:36 PM, Stephen Balukoff > wrote: > > Dang. I was hoping this wasn't the case. (I personally think it's a > little silly not to trust your service provider to secure a network when > they have root access to all the machines powering your cloud... but I > digress.) > > Part of the reason I was hoping this wasn't the case, isn't just because > it consumes a lot more CPU on the load balancers, but because now we > potentially have to manage client certificates and CA certificates (for > authenticating from the proxy to back-end app servers). And we also have to > decide whether we allow the proxy to use a different client cert / CA per > pool, or per member. > > > If you choose to support re-encryption on your service then you are > free to charge for the extra CPU cycles. I'm convinced re-encryption and > SslTermination is general needs to be mandatory but I think the API should > allow them to be specified. > > Yes, I realize one could potentially use no client cert or CA (ie. > encryption but no auth)... but that actually provides almost no extra > security over the unencrypted case: If you can sniff the traffic between > proxy and back-end server, it's not much more of a stretch to assume you > can figure out how to be a man-in-the-middle. > > > Yes but considering you have no problem advocating pure ssl > termination for your customers(Decryption on the front end and plain text) > on the back end I'm actually surprised this disturbs you. I would recommend > users use Straight SSL passthrough or re-enecryption but I wouldn't force > this on them should they choose naked encryption with no checking. > > > Do any of you have a use case where some back-end members require SSL > authentication from the proxy and some don't? (Again, deciding whether > client cert / CA usage should attach to a "pool" or to a "member.") > > > When you say client Cert are you referring to the end users X509 > Certificate (To be rejected by the backend server)or are you referring to > the back end servers X509Certificate which the loadbalancer would reject if > it discovered the back end server had a bad signature or mismatched key? I > am speaking of the case where the user wants re-encryption but wants to be > able to install CA certificates that sign backend servers Keys via PKIX > path building. I would even like to offer the customer the ability to skip > h
Re: [openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario question
Dang. I was hoping this wasn't the case. (I personally think it's a little silly not to trust your service provider to secure a network when they have root access to all the machines powering your cloud... but I digress.) Part of the reason I was hoping this wasn't the case, isn't just because it consumes a lot more CPU on the load balancers, but because now we potentially have to manage client certificates and CA certificates (for authenticating from the proxy to back-end app servers). And we also have to decide whether we allow the proxy to use a different client cert / CA per pool, or per member. Yes, I realize one could potentially use no client cert or CA (ie. encryption but no auth)... but that actually provides almost no extra security over the unencrypted case: If you can sniff the traffic between proxy and back-end server, it's not much more of a stretch to assume you can figure out how to be a man-in-the-middle. Do any of you have a use case where some back-end members require SSL authentication from the proxy and some don't? (Again, deciding whether client cert / CA usage should attach to a "pool" or to a "member.") It's a bit of a rabbit hole, eh. Stephen On Fri, Apr 18, 2014 at 10:21 AM, Eichberger, German < german.eichber...@hp.com> wrote: > Hi Stephen, > > > > The use case is that the Load Balancer needs to look at the HTTP requests > be it to add an X-Forward field or change the timeout – but the network > between the load balancer and the nodes is not completely private and the > sensitive information needs to be again transmitted encrypted. This is > admittedly an edge case but we had to implement a similar scheme for HP > Cloud’s swift storage. > > > > German > > > > *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net] > *Sent:* Friday, April 18, 2014 8:22 AM > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* [openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario > question > > > > Howdy, folks! > > > > Could someone explain to me the SSL usage scenario where it makes sense to > re-encrypt traffic traffic destined for members of a back-end pool? SSL > termination on the load balancer makes sense to me, but I'm having trouble > understanding why one would be concerned about then re-encrypting the > traffic headed toward a back-end app server. (Why not just use straight TCP > load balancing in this case, and save the CPU cycles on the load balancer?) > > > > We terminate a lot of SSL connections on our load balancers, but have yet > to have a customer use this kind of functionality. (We've had a few ask > about it, usually because they didn't understand what a load balancer is > supposed to do-- and with a bit of explanation they went either with SSL > termination on the load balancer + clear text on the back-end, or just > straight TCP load balancing.) > > > > Thanks, > > 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 > > -- 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
[openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario question
Howdy, folks! Could someone explain to me the SSL usage scenario where it makes sense to re-encrypt traffic traffic destined for members of a back-end pool? SSL termination on the load balancer makes sense to me, but I'm having trouble understanding why one would be concerned about then re-encrypting the traffic headed toward a back-end app server. (Why not just use straight TCP load balancing in this case, and save the CPU cycles on the load balancer?) We terminate a lot of SSL connections on our load balancers, but have yet to have a customer use this kind of functionality. (We've had a few ask about it, usually because they didn't understand what a load balancer is supposed to do-- and with a bit of explanation they went either with SSL termination on the load balancer + clear text on the back-end, or just straight TCP load balancing.) Thanks, 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 and API revision progress
Hi Brandon, Yep! I agree that both those definitions are correct: It all depends on context. I'm usually OK with going with whatever definition is in popular use by the user-base. However, "load balancer" as a term is so ambiguous among people actually developing a cloud load balancing system that a definition or more specific term is probably called for. :) In any case, all I'm really looking for is a glossary of defined terms attached to the API proposal, especially for terms like this that can have several meanings depending on context. (That is to say, I don't think it's necessary to define "IP address" for example-- unless, say, the distinction between IPv4 or IPv6 becomes important to the conversation somehow.) In any case note that I actually like your API thus far and think it's a pretty good start: Y'all put forth the laudable effort to actually create it, there's obviously a lot of forethought put into your proposal, and that certainly deserves respect! In fact, my team and I will probably be building off of what you've started in creating our proposal (which, again, I hope to have in a "showable" state before next week's meeting, and which I'm anticipating won't be the final form this API revision takes anyway.) Thanks, Stephen "There are only two truly difficult problems in computer science: Naming things, cache invalidation, and off-by-one errors." On Thu, Apr 17, 2014 at 6:31 PM, Brandon Logan wrote: > Stephen, > Thanks for elaborating on this. I agreed and still do that our proposal's > load balancer falls more in line with that glossary's term for "listener" > and now can see the discrepancy with "load balancer". Yes, in this case > the term "load balancer" would have to be redefined, but that doesn't mean > it is the wrong thing to do. > > I've always been on the side of the Load Balancing as a Service API using > a root object called a "load balancer". This just really makes sense to me > and others, but obviously it doesn't for everyone. However, in our > experience end users just understand the service better when the service > takes in load balancer objects and returns load balancer objects. > > Also, since it has been tasked to defined a new API we felt that it was > implied that some definitions were going to change, especially those that > are subjective. There are definitely many definitions of a load balancer. > Is a load balancer an appliance (virtual or physical) that load balances > many protocols and ports and is it also one that load balances a single > protocol on a single port? I would say that is definitely subjective. > Obviously I, and others, feel that both of those are true. I would like to > hear arguments as to why one of them is not true, though. > > Either way, we could have named that object a "sqonkey" and given a > definition in that glossary. Now we can all agree that while that word is > just an amazing word, its a terrible name to use in any context for this > service. It seems to me that an API can define and also redefine > subjective terms. > > I'm glad you don't find this as a deal breaker and are okay with > redefining the term. I hope we all can come to agreement on an API and I > hope it satisfies everyone's needs and ideas of a good API. > > Thanks, > Brandon > > > On 04/17/2014 07:03 PM, Stephen Balukoff wrote: > > Hi Brandon! > > Per the meeting this morning, I seem to recall you were looking to have > me elaborate on why the term 'load balancer' as used in your API proposal > is significantly different from the term 'load balancer' as used in the > glossary at: https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary > > As promised, here's my elaboration on that: > > The glossary above states: "An object that represent a logical load > balancer that may have multiple resources such as Vips, Pools, Members, > etc.Loadbalancer > is a root object in the meaning described above." and references the > diagram here: > https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion#Loadbalancer_instance_solution > > On that diagram, it's clear that VIPs, & etc. are subordinate objects to > a load balancer. What's more, attributes like 'protocol' and 'port' are not > part of the load balancer object in that diagram (they're part of a 'VIP' > in one proposed version, and part of a 'Listener' in the others). > > In your proposal, you state "only one port and one protocol per load > balancer," and then later (on page 9 under "GET /vips&quo
Re: [openstack-dev] [Neutron][LBaas] "Single call" API discussion
Hello German and Brandon! Responses in-line: On Thu, Apr 17, 2014 at 3:46 PM, Brandon Logan wrote: > Stephen, > I have responded to your questions below. > > > On 04/17/2014 01:02 PM, Stephen Balukoff wrote: > > Howdy folks! > > Based on this morning's IRC meeting, it seems to me there's some > contention and confusion over the need for "single call" functionality for > load balanced services in the new API being discussed. This is what I > understand: > > * Those advocating "single call" are arguing that this simplifies the > API for users, and that it more closely reflects the users' experience with > other load balancing products. They don't want to see this functionality > necessarily delegated to an orchestration layer (Heat), because > coordinating how this works across two OpenStack projects is unlikely to > see success (ie. it's hard enough making progress with just one project). I > get the impression that people advocating for this feel that their current > users would not likely make the leap to Neutron LBaaS unless some kind of > functionality or workflow is preserved that is no more complicated than > what they currently have to do. > > Another reason, which I've mentioned many times before and keeps getting > ignored, is because the more primitives you add the longer it will take to > provision a load balancer. Even if we relied on the orchestration layer to > build out all the primitives, it still will take much more time to > provision a load balancer than a single create call provided by the API. > Each request and response has an inherent time to process. Many primitives > will also have an inherent build time. Combine this in an environment that > becomes more and more dense, build times will become very unfriendly to end > users whether they are using the API directly, going through a UI, or going > through an orchestration layer. This industry is always trying to improve > build/provisioning times and there are no reasons why we shouldn't try to > achieve the same goal. > Noted. > * Those (mostly) against the idea are interested in seeing the API > provide primitives and delegating "higher level" single-call stuff to Heat > or some other orchestration layer. There was also the implication that if > "single-call" is supported, it ought to support both simple and advanced > set-ups in that single call. Further, I sense concern that if there are > multiple ways to accomplish the same thing supported in the API, this > redundancy breeds complication as more features are added, and in > developing test coverage. And existing Neutron APIs tend to expose only > primitives. I get the impression that people against the idea could be > convinced if more compelling reasons were illustrated for supporting > single-call, perhaps other than "we don't want to change the way it's done > in our environment right now." > > I completely disagree with "we dont want to change the way it's done in > our environment right now". Our proposal has changed the way our current > API works right now. We do not have the notion of primitives in our > current API and our proposal included the ability to construct a load > balancer with primitives individually. We kept that in so that those > operators and users who do like constructing a load balancer that way can > continue doing so. What we are asking for is to keep our users happy when > we do deploy this in a production environment and maintain a single create > load balancer API call. > > There's certainly something to be said for having a less-disruptive user experience. And after all, what we've been discussing is so radical a change that it's close to starting over from scratch in many ways. > > I've mostly stayed out of this debate because our solution as used by > our customers presently isn't "single-call" and I don't really understand > the requirements around this. > > So! I would love it if some of you could fill me in on this, especially > since I'm working on a revision of the proposed API. Specifically, what I'm > looking for is answers to the following questions: > > 1. Could you please explain what you understand single-call API > functionality to be? > > Single-call API functionality is a call that supports adding multiple > features to an entity (load balancer in this case) in one API request. > Whether this supports all features of a load balancer or a subset is up for > debate. I prefer all features to be supported. Yes it adds complexity, > but complexity is always introduced by improving the end user experience
Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress
Hi Brandon! Per the meeting this morning, I seem to recall you were looking to have me elaborate on why the term 'load balancer' as used in your API proposal is significantly different from the term 'load balancer' as used in the glossary at: https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary As promised, here's my elaboration on that: The glossary above states: "An object that represent a logical load balancer that may have multiple resources such as Vips, Pools, Members, etc.Loadbalancer is a root object in the meaning described above." and references the diagram here: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion#Loadbalancer_instance_solution On that diagram, it's clear that VIPs, & etc. are subordinate objects to a load balancer. What's more, attributes like 'protocol' and 'port' are not part of the load balancer object in that diagram (they're part of a 'VIP' in one proposed version, and part of a 'Listener' in the others). In your proposal, you state "only one port and one protocol per load balancer," and then later (on page 9 under "GET /vips") you show that a vip may have many load balancers associated with it. So clearly, "load balancer" the way you're using it is subordinate to a VIP. So in the glossary, it sounds like the object which has a single port and protocol associated with it that is subordinate to a VIP: A listener. Now, I don't really care if y'all decide to re-define "load balancer" from what is in the glossary so long as you do define it clearly in the proposal. (If we go with your proposal, it would then make sense to update the glossary accordingly.) Mostly, I'm just trying to avoid confusion because it's exactly these kinds of misunderstandings which have stymied discussion and progress in the past, eh. Also-- I can guess where the confusion comes from: I'm guessing most customers refer to "a service which listens on a tcp or udp port, understands a specific protocol, and forwards data from the connecting client to some back-end server which actually services the request" as a "load balancer." It's entirely possible that in the glossary and in previous discussions we've been mis-using the term (like we have with VIP). Personally, I suspect it's an overloaded term that in use in our industry means different things depending on context (and is probably often mis-used by people who don't understand what load balancing actually is). Again, I care less about what specific terms we decide on so long as we define them so that everyone can be on the same page and know what we're talking about. :) Stephen On Wed, Apr 16, 2014 at 7:17 PM, Brandon Logan wrote: > You say 'only one port and protocol per load balancer', yet I don't know > how this works. Could you define what a 'load balancer' is in this case? > (port and protocol are attributes that I would associate with a TCP or UDP > listener of some kind.) Are you using 'load balancer' to mean 'listener' > in this case (contrary to previous discussion of this on this list and the > one defined here https://wiki.openstack.org/wiki/Neutron/LBaaS > /Glossary#Loadbalancer )? > > > Yes, it could be considered as a Listener according to that > documentation. The way to have a "listener" using the same VIP but listen > on two different ports is something we call VIP sharing. You would assign > a VIP to one load balancer that uses one port, and then assign that same > VIP to another load balancer but that load balancer is using a different > port than the first one. How the backend implements it is an > implementation detail (redudant, I know). In the case of HaProxy it would > just add the second port to the same config that the first load balancer > was using. In other drivers it might be different. -- 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
[openstack-dev] [Neutron][LBaaS] HA functionality discussion
and type of load balancing services deployed
* Per appliance bandwidth consumption
* Per appliance connections / sec
* Per appliance SSL connections / sec
Since our devices are software appliances running on linux we also track
OS-level metrics as well, though these aren't used directly in the load
balancing features in our cloud OS.
3. We operate with an availability pool that our current cloud OS pays
attention to.
3a. Since the devices we use correspond to physical hardware this must of
course be rack-and-stacked by a datacenter technician, who also does
initial configuration of these devices.
4. All of our load balancers are deployed in an active / standby
configuration. Two machines which make up an active / standby pair are
registered with the cloud OS as a single unit that we call a "load balancer
cluster." Our availability pool consists of a whole bunch of these load
balancer clusters. (The devices themselves are registered individually at
the time the cluster object is created in our database.) There are a couple
manual steps in this process (currently handled by the datacenter techs who
do the racking and stacking), but these could be automated via API. In
fact, as we move to virtual appliances with these, we expect the entire
process to become automated via API (first cluster primitive is created,
and then "load balancer device objects" get attached to it, then the
cluster gets added to our availability pool.)
Removal of a "cluster" object is handled by first evacuating any customer
services off the cluster, then destroying the load balancer device objects,
then the cluster object. Replacement of a single load balancer device
entails removing the dead device, adding the new one, synchronizing
configuration data to it, and starting services.
5. At the present time, all our load balancing services are deployed in an
active / standby HA configuration, so the user has no choice or visibility
into any HA details. As we move to Neutron LBaaS, we would like to give
users the option of deploying non-HA load balancing capacity. Therefore,
the only visibility we want the user to get is:
* Choose whether a given load balancing service should be deployed in an HA
configuration ("flavor" functionality could handle this)
* See whether a running load balancing service is deployed in an HA
configuration (and see the "hint" for which physical or virtual device(s)
it's deployed on)
* Give a "hint" as to which device(s) a new load balancing service should
be deployed on (ie. for customers looking to deploy a bunch of test / QA /
etc. environments on the same device(s) to reduce costs).
Note that the "hint" above corresponds to the "load balancing cluster"
alluded to above, not necessarily any specific physical or virtual device.
This means we retain the ability to switch out the underlying hardware
powering a given service at any time.
Users may also see usage data, of course, but that's more of a generic
stats / billing function (which doesn't have to do with HA at all, really).
6. We need to see the status of all our load balancing devices, including
availability, current role (active or standby), and all the metrics listed
under 2 above. Some of this data is used for creating trend graphs and
business metrics, so being able to query the current metrics at any time
via API is important. It would also be very handy to query specific device
info (like revision of software on it, etc.) Our current cloud OS does all
this for us, and having Neutron LBaaS provide visibility into all of this
as well would be ideal. We do almost no management of our load balancing
services outside the purview of our current cloud OS.
7. Shared load balancers must live outside customer firewalls, private load
balancers typically live within customer firewalls (sometimes in a DMZ). In
any case, we use layer-3 routing (distributed using routing protocols on
our core networking gear and static routes on customer firewalls) to route
requests for "service IPs" to the "highly available routing IPs" which live
on the load balancers themselves. (When a fail-over happens, at a low
level, what's really going on is the "highly available routing IPs" shift
from the active to standby load balancer.)
We have contemplated using layer-2 topology (ie. directly connected on the
same vlan / broadcast domain) and are building a version of our appliance
which can operate in this way, potentially reducing the reliance on layer-3
routes (and making things more friendly for the OpenStack environment,
which we understand probably isn't ready for layer-3 routing just yet).
8. I wrote this survey, so none come to mind for me. :)
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] "Single call" API discussion
Oh! One other question: 5. Should "single-call" stuff work for the lifecycle of a load balancing service? That is to say, should "delete" functionality also clean up all primitives associated with the service? On Thu, Apr 17, 2014 at 11:44 AM, Stephen Balukoff wrote: > Hi Sri, > > Yes, the meeting minutes & etc. are all available here, usually a few > minutes after the meeting is over: > http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/ > > (You are also, of course, welcome to join!) > > Stephen > > > On Thu, Apr 17, 2014 at 11:34 AM, Sri wrote: > >> hello Stephen, >> >> >> I am interested in LBaaS and want to know if we post the weekly meeting's >> chat transcripts online? >> or may be update an etherpad? >> >> >> Can you please share the links? >> >> thanks, >> SriD >> >> >> >> -- >> View this message in context: >> http://openstack.10931.n7.nabble.com/Neutron-LBaas-Single-call-API-discussion-tp38533p38542.html >> Sent from the Developer mailing list archive at Nabble.com. >> >> _______ >> 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaas] "Single call" API discussion
Hi Sri, Yes, the meeting minutes & etc. are all available here, usually a few minutes after the meeting is over: http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/ (You are also, of course, welcome to join!) Stephen On Thu, Apr 17, 2014 at 11:34 AM, Sri wrote: > hello Stephen, > > > I am interested in LBaaS and want to know if we post the weekly meeting's > chat transcripts online? > or may be update an etherpad? > > > Can you please share the links? > > thanks, > SriD > > > > -- > View this message in context: > http://openstack.10931.n7.nabble.com/Neutron-LBaas-Single-call-API-discussion-tp38533p38542.html > Sent from the Developer mailing list archive at Nabble.com. > > ___ > 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][LBaas] "Single call" API discussion
Howdy folks! Based on this morning's IRC meeting, it seems to me there's some contention and confusion over the need for "single call" functionality for load balanced services in the new API being discussed. This is what I understand: * Those advocating "single call" are arguing that this simplifies the API for users, and that it more closely reflects the users' experience with other load balancing products. They don't want to see this functionality necessarily delegated to an orchestration layer (Heat), because coordinating how this works across two OpenStack projects is unlikely to see success (ie. it's hard enough making progress with just one project). I get the impression that people advocating for this feel that their current users would not likely make the leap to Neutron LBaaS unless some kind of functionality or workflow is preserved that is no more complicated than what they currently have to do. * Those (mostly) against the idea are interested in seeing the API provide primitives and delegating "higher level" single-call stuff to Heat or some other orchestration layer. There was also the implication that if "single-call" is supported, it ought to support both simple and advanced set-ups in that single call. Further, I sense concern that if there are multiple ways to accomplish the same thing supported in the API, this redundancy breeds complication as more features are added, and in developing test coverage. And existing Neutron APIs tend to expose only primitives. I get the impression that people against the idea could be convinced if more compelling reasons were illustrated for supporting single-call, perhaps other than "we don't want to change the way it's done in our environment right now." I've mostly stayed out of this debate because our solution as used by our customers presently isn't "single-call" and I don't really understand the requirements around this. So! I would love it if some of you could fill me in on this, especially since I'm working on a revision of the proposed API. Specifically, what I'm looking for is answers to the following questions: 1. Could you please explain what you understand single-call API functionality to be? 2. Could you describe the simplest use case that uses single-call API in your environment right now? Please be very specific-- ideally, a couple examples of specific CLI commands a user might run, or API (along with specific configuration data) would be great. 3. Could you describe the most complicated use case that your single-call API supports? Again, please be very specific here. 4. What percentage of your customer base are used to using single-call functionality, and what percentage are used to manipulating primitives? Thanks! 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 and API revision progress
proposed transient ids to allow the user to avoid creating > duplicate objects with different ids) on the fly as well as reference > preexisting objects by id. The allowance for transient ids is adding > flexibility to the api not taking away from it as you declared. I would > like you to really be clear on what "our requirements"? What requirement is > our single API call violating? > > We have thus far attempted to support a single call API that doesn't > interfere with multiple smaller object creation calls. If we are just > adding to the API in a demonstrably workable fashion what is the real > objection. > > > While I understand that it might be simpler to use such API for some > cases, it makes complex configurations fall back to our existing approach > which is creating configuration on per object basis. > While the problem with complex configurations is not sorted out, I'd > prefer if we focus on existing 'object-oriented' approach. > > > Your basically saying > P1: "The single API call proposal doesn't support *ALL* complex > configurations" > P2: " if the single API proposal doesn't support *ALL* complex > configurations the proposal should be rejected" > > We have demonstrated that the proposed single API call can handle > complex configurations via transient ids. So we already disagree with > preposition 1. > > We don't agree with preposition 2 either: > We believe it is unfair to punish the API end user due to the > religious belief that "The single API calls must support all possible > configurations or you as the customer can't be allowed to use the single > API call even for simpler configurations." > > We want the single API call proposal to be as useful as possible so we > are like wise looking at ways to have it solve ALL complex configurations > and so far we feel transient IDs solve this problem already. > > Is the real objection that a single API call makes the > implementation too complex? We are advocating that a single API makes it > easier on the end user of the API and are of the impression that its better > to have a complex implementation inside our neutron/lbaas code rather then > passing that complexity down to the end user of the API. > > We don't object to multiple smaller object creation transactions we > just want the addition of having single API call. > > > On the other hand, without single-call API the rest of proposal seems > to be similar to approaches discussed in > https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion > > Since you linked the object model proposals could you also link the > "rest of the proposals" or are you referring to our draft as "rest of > proposal"? > > > Thanks, > Eugene. > > > > > > On Thu, Apr 17, 2014 at 12:59 AM, Brandon Logan < > brandon.lo...@rackspace.com> wrote: > >> Sorry about that. It should be readable now. >> -- >> *From:* Eugene Nikanorov [enikano...@mirantis.com] >> *Sent:* Wednesday, April 16, 2014 3:51 PM >> >> *To:* OpenStack Development Mailing List (not for usage questions) >> *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Requirements and API >> revision progress >> >>Hi Brandon, >> >> Seems that doc has not been made public, so please share. >> >> Thanks, >> Eugene. >> >> >> On Thu, Apr 17, 2014 at 12:39 AM, Brandon Logan < >> brandon.lo...@rackspace.com> wrote: >> >>> Here is Jorge and team’s API proposal based on Atlas. The document >>> has some questions and answers about why decisions were made. Feel free to >>> open up a discussion about these questions and answers and really about >>> anything. This can be changed up to fit any flaws or use cases we missed >>> that this would not support. >>> >>> There is a CLI example at the bottom along with a possible L7 >>> switching API model. >>> >>> >>> https://docs.google.com/document/d/1mTfkkdnPAd4tWOMZAdwHEx7IuFZDULjG9bTmWyXe-zo/edit >>> >>> Thanks, >>> Brandon Logan >>> >>> From: Eugene Nikanorov >>> Reply-To: "openstack-dev@lists.openstack.org" < >>> openstack-dev@lists.openstack.org> >>> Date: Tuesday, April 15, 2014 at 7:00 AM >>> To: "openstack-dev@lists.openstack.org" < >>> openstack-dev@lists.openstack.org> >>> >>> Subject: Re: [openstack-dev] [Neutron][LBaaS] Requirements and API >&g
[openstack-dev] [Neutron][LBaaS] Requirements and API revision progress
Hello y'all! Over the last few months, I feel like we've seen a renewed vigor for participation in making the LBaaS project successful. After the (still unresolved) object model discussion started in January, based on feedback we were getting from Neutron core developers (mainly Mark McClain, from what I understand) this was followed up by a requirements discussion, a use cases discussion, and as of the last weekly IRC meeting, I think there are people in this group now working on proposals for API revision. We've coordinated this using various documents, and I think the ones that have carried the most weight are: * Object model revision summary as started by Eugene: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion (Feedback from core was the 'load balancer' object was an implementation detail. I think most people on this project don't think so, but it's clear more work was needed here.) * Requirements document as started by Jorge: https://wiki.openstack.org/wiki/Neutron/LBaaS/requirements (Feedback was that requirements needed to be stated in the form of user or operator requirements, and not in the form of what a load balancer should do, per se.) * Samuel then created this google document to describe several use cases from the user's point of view: https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?usp=sharing * And to prioritize what features are needed, Jorge started this document to collect operator feature usage data (with current load balancer deployments, presumably outside of OpenStack, since Neutron LBaaS doesn't presently have many of these features): https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc&usp=sharing (Feedback on this is that everyone agrees the legacy API is really confusing, and that a clean break for the API for Juno is probably prudent, possibly preserving some backward compatibility with a versioned API. Further, it was clear we needed an example of what the new API should look like.) There are also these proposal documents for L7 and SSL functionality, presumably on hold until either the API draft being made is closer to reality, or until we come to an agreement on the required changes to the object model the proposals imply: https://wiki.openstack.org/wiki/Neutron/LBaaS/l7 https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL So! On this front: 1. Does is make sense to keep filling out use cases in Samuel's document above? I can think of several more use cases that our customers actually use on our current deployments which aren't considered in the 8 cases in Samuel's document thus far. Plus nobody has create any use cases from the cloud operator perspective yet. 2. It looks like we've started to get real-world data on Load Balancer features in use in the real world. If you've not added your organization's data, please be sure to do so soon so we can make informed decisions about product direction. On this front, when will we be making these decisions? 3. Jorge-- I know an action item from the last meeting was to draft a revision of the API (probably starting from something similar to the Atlas API). Have you had a chance to get started on this, and are you open for collaboration on this document at this time? Alternatively, I'd be happy to take a stab at it this week (though I'm not very familiar with the Atlas API-- so my proposal might not look all that similar). What format or template should we be following to create the API documentation? (I see this here: http://docs.openstack.org/api/openstack-network/2.0/content/ch_preface.html but this seems like it might be a little heavy for an API draft that is likely to get altered significantly, especially given how this discussion has gone thus far. :/ ) Thanks, 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] Load balancing use cases. Data from Operators needed.
I've also added our L7 feature usage data on a new tab. On Mon, Apr 14, 2014 at 3:03 PM, Prashanth Hari wrote: > Hi, > > We have updated the operators data - > https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc#gid=1 > > Please note the percentage is based on number of VIPs. The traffic > distribution (connections / sec) will vary by services. > > Thanks, > Prashanth > Comcast > > > > > On Wed, Apr 9, 2014 at 11:28 AM, Susanne Balle wrote: > >> Hi >> >> >> >> I wasn't able to get % for the spreadsheet but our Product Manager >> prioritized the features: >> >> >> >> *Function* >> >> *Priority (0 = highest)* >> >> *HTTP+HTTPS on one device* >> >> 5 >> >> *L7 Switching* >> >> 2 >> >> *SSL Offloading* >> >> 1 >> >> *High Availability* >> >> 0 >> >> *IP4 & IPV6 Address Support* >> >> 6 >> >> *Server Name Indication (SNI) Support* >> >> 3 >> >> *UDP Protocol* >> >> 7 >> >> *Round Robin Algorithm* >> >> 4 >> >> >> >> Susanne >> >> >> On Thu, Apr 3, 2014 at 9:32 AM, Vijay Venkatachalam < >> vijay.venkatacha...@citrix.com> wrote: >> >>> >>> >>> The document has Vendor column, it should be from Cloud >>> Operator? >>> >>> >>> >>> Thanks, >>> >>> Vijay V. >>> >>> >>> >>> >>> >>> *From:* Eugene Nikanorov [mailto:enikano...@mirantis.com] >>> *Sent:* Thursday, April 3, 2014 11:23 AM >>> *To:* OpenStack Development Mailing List (not for usage questions) >>> >>> *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Load balancing use >>> cases. Data from Operators needed. >>> >>> >>> >>> Stephen, >>> >>> >>> >>> Agree with you. Basically the page starts looking as requirements page. >>> >>> I think we need to move to google spreadsheet, where table is organized >>> easily. >>> >>> Here's the doc that may do a better job for us: >>> >>> >>> https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc&usp=sharing >>> >>> >>> >>> Thanks, >>> >>> Eugene. >>> >>> >>> >>> On Thu, Apr 3, 2014 at 5:34 AM, Prashanth Hari >>> wrote: >>> >>> More additions to the use cases ( >>> https://wiki.openstack.org/wiki/Neutron/LBaaS/Usecases). >>> >>> I have updated some of the features we are interested in. >>> >>> >>> >>> >>> >>> >>> >>> Thanks, >>> >>> Prashanth >>> >>> >>> >>> >>> >>> On Wed, Apr 2, 2014 at 8:12 PM, Stephen Balukoff >>> wrote: >>> >>> Hi y'all-- >>> >>> >>> >>> Looking at the data in the page already, it looks more like a feature >>> wishlist than actual usage data. I thought we agreed to provide data based >>> on percentage usage of a given feature, the end result of the data >>> collection being that it would become more obvious which features are the >>> most relevant to the most users, and therefore are more worthwhile targets >>> for software development. >>> >>> >>> >>> Specifically, I was expecting to see something like the following (using >>> hypothetical numbers of course, and where technical people from "Company A" >>> & etc. fill out the data for their organization): >>> >>> >>> >>> == L7 features == >>> >>> >>> >>> "Company A" (Cloud operator serving external customers): 56% of >>> load-balancer instances use >>> >>> "Company B" (Cloud operator serving external customers): 92% of >>> load-balancer instances use >>> >>> "Company C" (Fortune 100 company serving internal customers): 0% of >>> load-balancer instances use >>> >>> >>> >>> == SSL termination == >>> >>> >>> >>> "Company A" (Cloud operator serving external customers): 95% of >>> load-balancer instances use >>> >>> &qu
Re: [openstack-dev] [Neutron][LBaaS]Clarification in regards to https://docs.google.com/a/mirantis.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc#gid=1
The answers for our organization are generally pretty close to those that Jorge has said. So my response is mostly a big +1 to his, with the following differences: On Wed, Apr 9, 2014 at 1:49 PM, Jorge Miramontes < jorge.miramon...@rackspace.com> wrote: > 1. Monitoring Tab: > > a. Are there users that use load balancing who do not monitor > members? Can you share the use cases where this makes sense? > This is a good question. In our case we supply static ip addresses so > some users have only one backend node. With one node it isn't necessary. > Another case I can think of is lbs that are being used for non-critical > environments (i.e. dev or testing environment). For the most part it would > make sense to have monitoring. > For the case of dev or testing environments: It could be argued that if you're going to bother to deploy load balancing at all, it's with the intent of having a functional representative of production. As such, such non-production environments should probably also make use of monitoring. ;) > 2. Logging Tab: > > a. What is logging use for? > This is specifically connection logging. It allows the user to see all > of the requests that went through the load balancer. It is mostly used for > big data and troubleshooting. > We tend to only use error logs for troubleshooting in cases where there might be a problem at the load-balancer level. Most of our customers get their big data and other troubleshooting logs from the back-end application servers. > 6. L7 > > a. Does any cloud provider support L7 switching and L7 content > modifications? > > We do. (Both L7 switching and L7 content modifications.) On the switching side of things, our most two common use cases are: 1. Switching based on URI base path (ex. anything under "/api" goes to a different pool) 2. Switching based on HTTP/1.1 hostname (ex. "www.example.com" goes to a different pool than "api.example.com") We do have a few customers using cookie-based switching. The content modification we allow is also pretty basic. Mostly, we insert the "X-Fowarded-For" header, and allow our customers to do HSTS at the load balancer. Most everything else can be done at the application server layer, so we have our customers do that. > b. If so can you please add a tab noting how much such features > are used? > Will do, once I get the data. Might not happen before tomorrow's meeting. > c. If not, can anyone attest to whether this feature was > requested by customers? > Yep, these features were requested by our customers and have become mission-critical for some. We could not transition these customers to another load balancer product without having this functionality now. Thanks, 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] Load balancing use cases. Data from Operators needed.
Hi y'all-- Looking at the data in the page already, it looks more like a feature wishlist than actual usage data. I thought we agreed to provide data based on percentage usage of a given feature, the end result of the data collection being that it would become more obvious which features are the most relevant to the most users, and therefore are more worthwhile targets for software development. Specifically, I was expecting to see something like the following (using hypothetical numbers of course, and where technical people from "Company A" & etc. fill out the data for their organization): == L7 features == "Company A" (Cloud operator serving external customers): 56% of load-balancer instances use "Company B" (Cloud operator serving external customers): 92% of load-balancer instances use "Company C" (Fortune 100 company serving internal customers): 0% of load-balancer instances use == SSL termination == "Company A" (Cloud operator serving external customers): 95% of load-balancer instances use "Company B" (Cloud operator serving external customers): 20% of load-balancer instances use "Company C" (Fortune 100 company serving internal customers): 50% of load-balancer instances use. == Racing stripes == "Company A" (Cloud operator serving external customers): 100% of load-balancer instances use "Company B" (Cloud operator serving external customers): 100% of load-balancer instances use "Company C" (Fortune 100 company serving internal customers): 100% of load-balancer instances use In my mind, a wish-list of features is only going to be relevant to this discussion if (after we agree on what the items under consideration ought to be) each technical representative presents a prioritized list for their organization. :/ A wish-list is great for brain-storming what ought to be added, but is less relevant for prioritization. In light of last week's meeting, it seems useful to list the features most recently discussed in that meeting and on the mailing list as being points on which we want to gather actual usage data (ie. from what people are actually using on the load balancers in their organization right now). Should we start a new page that lists actual usage percentages, or just re-vamp the one above? (After all, wish-list can be useful for discovering things we're missing, especially if we get people new to the discussion to add their $0.02.) Thanks, Stephen On Wed, Apr 2, 2014 at 3:46 PM, Jorge Miramontes < jorge.miramon...@rackspace.com> wrote: > Thanks Eugene, > > I added our data onto the requirements page since I was hoping to > prioritize requirements based on the operator data that gets provided. We > can move it over to the other page if you think that makes sense. See > everyone on the weekly meeting tomorrow! > > Cheers, > --Jorge > > From: Susanne Balle > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Tuesday, April 1, 2014 4:09 PM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases. > Data from Operators needed. > > I added two more. I am still working on our HA use cases. Susanne > > > On Tue, Apr 1, 2014 at 4:16 PM, Fox, Kevin M wrote: > >> I added our priorities. I hope its formatted well enough. I just took a >> stab in the dark. >> >> Thanks, >> Kevin >> -- >> *From:* Eugene Nikanorov [enikano...@mirantis.com] >> *Sent:* Tuesday, April 01, 2014 3:02 AM >> *To:* OpenStack Development Mailing List >> *Subject:* [openstack-dev] [Neutron][LBaaS] Load balancing use cases. >> Data from Operators needed. >> >>Hi folks, >> >> On the last meeting we decided to collect usage data so we could >> prioritize features and see what is demanded most. >> >> Here's the blank page to do that (in a free form). I'll structure it >> once we have some data. >> https://wiki.openstack.org/wiki/Neutron/LBaaS/Usecases >> >> Please fill with the data you have. >> >> Thanks, >> Eugene. >> >> ___ >> 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 > > -- 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
Aah! Yes-- you are correct. I was thinking a the load balancer level, not the pool level. (Maybe we can clarify this distinction in the requirements doc?) But I would also be surprised if there are load balancers today that don't intrinsically offer "active / backup pool membership" as a standard feature. Eugene: This is somewhat similar to weighting, but not exactly the same thing. Stephen On Thu, Mar 20, 2014 at 10:17 AM, Youcef Laribi wrote: > 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 > -- 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
Hi y'all! It's good to be back, eh! On Wed, Mar 19, 2014 at 11:35 PM, Eugene Nikanorov 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] Mini-summit Interest?
If a mini-summit is held (no matter when), I'll try to make it in person. Failing that, if a google hangout is set up, I ought to be able to attend that way. (And... it's good to be back, eh!) Stephen On Thu, Mar 13, 2014 at 2:17 PM, Edgar Magana wrote: > That sounds like a good idea Mark! > Yes, please do not do it during the World Cup at least the meeting is in > Brazil :-) > > Edgar > > On 3/13/14 2:11 PM, "Mark McClain" wrote: > > > > >On Mar 13, 2014, at 4:22 PM, Jay Pipes wrote: > > > >> > >> > >> I personally would not be able to attend a mini-summit days before the > >> regular summit. I would, however, support a mini-summit about a month > >> after the regular summit, where the focus would be on implementing the > >> designs that are discussed at the regular summit. > > > >I¹ve been working some of the others on the core team to setup another > >Neutron mid-cycle meet up. Like the last one, this will be focused on > >writing/reviewing code for important Juno blueprints (so those who can¹t > >travel can still participate). The trouble with finding dates in late > >May to early July dates is there are a number of large regional OpenStack > >events, other conferences, and the World Cup (we do have a several > >football fans on the team). I hope that we¹ll be able to share the > >information with everyone soon. > > > >mark > >___ > >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 > -- 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] Object Model discussion
Hi folks! Just one other thing I'd like to bring up here as well: On Thu, Feb 27, 2014 at 4:00 AM, Eugene Nikanorov wrote: > I see IP address sharing as user intent, not an implementation detail. >> Same backend could be not only the only obstacle here. >> >> The backend is not exposed anyhow by the API, by the way. >> >> When you create root object with flavor - you really can't control to >> which driver it will be scheduled. >> >> So even if there is driver that is somehow (how?) will allow same IP on >> different backends, user just will not be able to create 2 vips that share >> IP address. >> >> >> >> Eugene, is your point that the logical model addresses the capability for >> IP sharing but that it can’t be scheduled correctly? >> > That's one of concerns, correct. > >> >> I also want to point out that there is the practical limitation that in no IP network that I'm aware of, you can't have to different devices share the same IP on the same layer-2 network and have this work. (I understand that two neutron ports connected to the same netutron_network or subnet is effectively putting them on the same layer-2 network.) I know that an active-standby topology can work here, but in this case we're talking about two different VIPs sharing the same IP, not on the same device, and both being active at the same time. But... I've been wrong before and I just might not be aware of any technology which makes this work: Do any of y'all know of any technology here which makes this feasible? If not, then y'all must concede that this is one technological limitation which is going to make it necessary for the user to actually specify somehow that services collocated on the same IP must be collocated on the same back-end (if a layer-2 topology is used). It is possible to have two devices share the same IP in a layer-3 network topology, but then there needs to also be some kind of logic there to determine how packets get routed to each device (and this can break stateful protocols like TCP if you're not careful)-- but again, this would be "routed mode" load balancing, which I understand is not yet feasible with Neutron LBaaS, correct? 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] Enterprise Ready Features
o this project please forgive me, and also > > correct me, if my understanding of some of these things is false. > > I've already spoken to Eugene about some of this, but I think it would > > be nice to get everyone's opinion. And since the object model > > discussions are going on right now I believe this to be a good time to > > bring it up. > > Ya, no worries. I'm new to the LBaaS discussions myself. > > > As of its current incarnation Neutron LBaaS does not seem to be HA, > > scalable, and doesn't isolate resources for each load balancer. I > > know there is a blueprint for HA for the agent > > (https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-agent) and HA > > for HaProxy > > (https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy). > > That is only for HaProxy, though, and sounds like it has to be > > implemented at the driver level. > > Right. Different drivers will enable HA in different ways. > > > Is that the intended direction for implementing these goals, to > > implement them at the driver level? > > I *believe* that is the intended direction, yes. The ongoing > conversations about Neutron "flavors" as well as the conversation about > the future object model and API have really been about how to expose the > capabilities of different drivers -- and match those capabilities to > requested capabilities from the user -- without leaking any particular > driver's implementation specifics into the public API. I think the hope > is that in the coming few months and during the summit, the community > will coalesce around a game plan for implementing "flavors" (or types, > as I prefer to call them), and from that implementation, contributors > will be able to work on adding these features to drivers and expose this > functionality in a generic fashion. > > > I can definitely see why that is the way to do it because some > > drivers may already implement these features, while others don't. It > > would be nice if there was a way to give those features to drivers > > that do not have it out of the box. > > Well, on the HA and scaling front, one solution is to run multiple > instances of something like HA Proxy and have some healthcheck software > that would fail over operations from one load balancer instance to > another if a failure condition occurred. In fact, that is similar to > what the Libra project does with its node pool manager [1]. > > > Basically, I'd like this project to have these enterprise level > > features to that it can be adopted in an enterprise cloud. It will > > require a lot of work to achieve these goals, and I believe it should > > be something that is a goal. > > I don't think you'll get any disagreement from anyone on that :) > Although there has certainly been a fragmentation of effort on the LBaaS > front with Atlas, Libra and Neutron LBaaS, it seems that the community > is now coming together a bit. > > Best, > -jay > > [1] http://libra.readthedocs.org/en/latest/pool_mgm/index.html > > > > ___ > 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 > -- 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] [Openstack] Need unique ID for every Network Service
Hi y'all! The ongoing debate in the LBaaS group is whether the concept of a 'Loadbalancer' needs to exist as an entity. If it is decided that we need it, I'm sure it'll have a unique ID. (And please feel free to join the discussion on this as well, eh!) Stephen On Thu, Feb 27, 2014 at 10:27 PM, Veera Reddy wrote: > Hi, > > Good idea to have unique id for each entry of network functions. > So that we can configure multiple network function with different > configuration. > > > Regards, > Veera. > > > On Fri, Feb 28, 2014 at 11:23 AM, Srikanth Kumar Lingala < > srikanth.ling...@freescale.com> wrote: > >> Hi- >> >> In the existing Neutron, we have FWaaS, LBaaS, VPNaaS …etc. >> >> In FWaaS, each Firewall has its own UUID. >> >> It is good to have a unique ID [UUID] for LBaaS also. >> >> >> >> Please share your comments on the above. >> >> >> >> Regards, >> >> Srikanth. >> >> ___ >> Mailing list: >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> Post to : openst...@lists.openstack.org >> Unsubscribe : >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> >> > > _______ > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openst...@lists.openstack.org > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > -- 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] Object Model discussion
Hi Ed, That sounds good to me, actually: As long as 'cloud admin' API functions are represented as well as 'simple user workflows', then I'm all for a unified API that simply exposes more depending on permissions. Stephen On Tue, Feb 25, 2014 at 12:15 PM, Ed Hall wrote: > > On Feb 25, 2014, at 10:10 AM, Stephen Balukoff > wrote: > >On Feb 25, 2014 at 3:39 AM, enikano...@mirantis.com wrote: > >> Agree, however actual hardware is beyond logical LBaaS API but could >> be a part of admin LBaaS API. >> > > Aah yes-- In my opinion, users should almost never be exposed to > anything that represents a specific piece of hardware, but cloud > administrators must be. The logical constructs the user is exposed to can > "come close" to what an actual piece of hardware is, but again, we should > be abstract enough that a cloud admin can swap out one piece of hardware > for another without affecting the user's workflow, application > configuration, (hopefully) availability, etc. > > I recall you said previously that the concept of having an 'admin API' > had been discussed earlier, but I forget the resolution behind this (if > there was one). Maybe we should revisit this discussion? > > I tend to think that if we acknowledge the need for an admin API, as > well as some of the core features it's going to need, and contrast this > with the user API (which I think is mostly what Jay and Mark McClain are > rightly concerned about), it'll start to become obvious which features > belong where, and what kind of data model will emerge which supports both > APIs. > > > [I’m new to this discussion; my role at my employer has been shifted from > an internal to a community focus and I’m madly > attempting to come up to speed. I’m a software developer with an > operations focus; I’ve worked with OpenStack since Diablo > as Yahoo’s team lead for network integration.] > > Two levels (user and admin) would be the minimum. But our experience over > time is that even administrators occasionally > need to be saved from themselves. This suggests that, rather than two or > more separate APIs, a single API with multiple > roles is needed. Certain operations and attributes would only be > accessible to someone acting in an appropriate role. > > This might seem over-elaborate at first glance, but there are other > dividends: a single API is more likely to be consistent, > and maintained consistently as it evolves. By taking a role-wise view the > hierarchy of concerns is clarified. If you focus on > the data model first you are more likely to produce an arrangement that > mirrors the hardware but presents difficulties in > representing and implementing user and operator intent. > > Just some general insights/opinions — take for what they’re worth. > > -Ed > > > ___ > 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 ___ 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! Responses inline: On Tue, Feb 25, 2014 at 3:33 AM, Eugene Nikanorov wrote: > > I'm really not sure what Mark McClain on some other folks see as > implementation details. To me the 'instance' concept is as logical as > others (vips/pool/etc). But anyway, it looks like majority of those who > discuss, sees it as redundant concept. > Maybe we should have a discussion around what qualifies as a 'logical concept' or 'logical construct,' and why the 'loadbalancer' concept you've been championing either does or does not qualify, so we're all (closer to being) on the same page before we discuss model changes? > Agree, however actual hardware is beyond logical LBaaS API but could be a > part of admin LBaaS API. > Aah yes-- In my opinion, users should almost never be exposed to anything that represents a specific piece of hardware, but cloud administrators must be. The logical constructs the user is exposed to can "come close" to what an actual piece of hardware is, but again, we should be abstract enough that a cloud admin can swap out one piece of hardware for another without affecting the user's workflow, application configuration, (hopefully) availability, etc. I recall you said previously that the concept of having an 'admin API' had been discussed earlier, but I forget the resolution behind this (if there was one). Maybe we should revisit this discussion? I tend to think that if we acknowledge the need for an admin API, as well as some of the core features it's going to need, and contrast this with the user API (which I think is mostly what Jay and Mark McClain are rightly concerned about), it'll start to become obvious which features belong where, and what kind of data model will emerge which supports both APIs. Thanks, 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] Object Model discussion
_id}
>>
>> with JSON body of request like so:
>>
>> {
>> "front-port": 443,
>> "front-protocol": "https",
>> "back-port": 80,
>> "back-protocol": "http"
>> }
>>
>> And the code handling the above request would simply look to see if the
>> load balancer had a "routing entry" for the front-end port and protocol
>> of (443, https) and set the entry to route to back-end port and protocol
>> of (80, http).
>>
>> For the advanced L7 policy heuristics, it makes sense to me to use a
>> similar strategy. For example (using a similar example from ELB):
>>
>> neutron l7-policy-create --type="ssl-negotiation" \
>> --attr=ProtocolSSLv3=true \
>> --attr=ProtocolTLSv1.1=true \
>> --attr=DHE-RSA-AES256-SHA256=true \
>> --attr=Server-Defined-Cipher-Order=true
>>
>> Presume above returns an ID for the policy $L7_POLICY_ID. We could then
>> assign that policy to operate on the front-end of the load balancer by
>> doing:
>>
>> neutron balancer-apply-policy $BALANCER_ID $L7_POLICY_ID --port=443
>>
>> There's no need to specify --front-port of course, since the policy only
>> applies to the front-end.
>>
>> There is also no need to refer to a "listener" object, no need to call
>> anything a VIP, nor any reason to use the term "pool" in the API.
>>
>> Best,
>> -jay
>>
>> > In our current proposal backend is chosen and step (1) and all further
>> > objects are implicitly go on the same backend as VipName.
>> >
>> >
>> > The API allows the following addition:
>> > 8) create-vip --name VipName2 address=addr2
>> > 9) create-listener ... listener3 ...
>> > 10) set-listener-pool listener_id3 pool_id1
>> >
>> >
>> > E.g. from API stand point the commands above are valid. But that
>> > particular ability (pool1 is shared by two different backends)
>> > introduces lots of complexity in the implementation and API, and that
>> > is what we would like to avoid at this point.
>> >
>> >
>> > So the proposal makes step #10 forbidden: pool is already associated
>> > with the listener on other backend, so we don't share it with
>> > listeners on another one.
>> > That kind of restriction introduces implicit knowledge about the
>> > object-to-backend mapping into the API.
>> > In my opinion it's not a big deal. Once we sort out those
>> > complexities, we can allow that.
>> >
>> >
>> > What do you think?
>> >
>> >
>> > Thanks,
>> > Eugene.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > > Looking at your proposal it reminds me Heat template for
>> > > loadbalancer.
>> > > It's fine, but we need to be able to operate on particular
>> > objects.
>> >
>> >
>> > I'm not ruling out being able to add or remove nodes from a
>> > balancer, if
>> > that's what you're getting at?
>> >
>> > 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
>>
>>
>>
>> ___
>> 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
>
>
--
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
[openstack-dev] [Neutron][LBaaS] Feedback on SSL implementation
ode) that exactly one certificate associated with a given VIP is marked as default whenever the VIP<->ssl_certificate associations are created or modified. In the screen associating certificates with a given VIP, we need to provide a field (checkbox?) for the user to specify which one of them is the default. Thanks, 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] Object Model discussion
> > > > > > I think that the current logical model is fine with the exception that the > two way reference between vip and pool (vipßàpool) 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 > about that) - that's no problem, but if they don't, then: > > 1) what 'status' attribute of the pool would mean? > Presumably if the pool is down for one back-end, it's down for all the back-ends. But you're right that there might be cases (eg. network connectivity problem) where a pool is down for one back-end but not another. Maybe the question of pool status only makes sense in the context of a specific listener? > 2) how health monitors for the pool will be deployed? and what their > statuses would mean? > To be frank, I don't understand why healthmonitors aren't just extra attributes of the pool object. (Does anyone know of any case where having multiple healthmonitors per pool makes sense?) Also, isn't asking the status of a healthmonitor functionally equivalent to asking the status of the pool? > 3) what pool statistics would mean? > Aah, this is trickier. Again, maybe this only makes sense in the context of a specific listener, as well? But yes, the problem of gathering aggregate statistics for a single pool spread across many back-ends becomes a lot more complicated. > 4) If the same pool is used on > > > > To be able to preserve existing meaningful healthmonitors, members and > statistics API we will need to create associations for everything, or just > change API in backward incompatible way. > > My opinion is that it make sense to limit such ability (reusing pools by > vips deployed on different backends) in favor of simpler code, IMO it's > really a big deal. Pool is lightweight enough to not to share it as an > object. > Agreed-- not having re-usable pools just means the tenant needs to do more housekeeping in a larger environment. Honestly... even among our largest clients, we rarely see them re-using pools, or having pools associated with multiple listeners. So, this might be a moot point for the 90% use case anyway. Thanks, 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] Proposal for model change - Loadbalancer Instance feedback
cts are logical config, it
> could be deployed in HA or in single mode, depending on user's choice and
> driver capabilities.
> And regarding allowing users to talk directly to a driver - that's a big
> question. I think it can be desirable in some cases.
> You know, lb appliances nowadays can make cookies and fly to space and I'm
> not sure we want all that in the generic lb API, but that could be provided
> via specific extensions. Even in a public cloud case, where you want your
> tenants to be completely unaware of the backend, it's still possible that
> there are some tenants with specific demands (willing to pay) where more
> control could be useful.
>
> And going back to HA, this is a common feature that needs to be introduced
> into generic API.
>
>
So, I'm thinking that the "cluster" in my design fills that need.
For example, if a cluster has a "cluster_type" of "HA-active-standby" and
from that the cloud OS knows it needs to keep two load balancer nodes up
and running (and that these need to be configured to be in an
active-standby role, though such specific configuration will happen at the
driver level). Again, I think the cloud OS should be aware of how many
physical (or virtual) load balancer nodes make up a "cluster" and that this
shouldn't be visible only to the driver.
HA and horizontal scalability do not seem like those "fly into space"
vendor-specific features. They seem like core components we should be
shooting to achieve in the general case.
>
>>- Side note: It's possible to still have drivers / load balancer
>>appliances which do not support certain types of HA or auto-scaling
>>topologies. In this case, it probably makes sense to add some kind of
>>'capabilities' list that the driver publishes to the lbaas daemon when
>> it's
>>loaded.
>>
>> Yes, that makes sense and was discussed previously, but not implemented
> so far.
>
Aah, cool!
>
>>-
>>
>> So, I won't elaborate on the model I would propose we use instead of the
>> above, since I've already done so before. I'll just say that what we're
>> trying to solve with the LoadBalancerInstance resource in this proposal can
>> also be solved with the 'cluster' and 'loadbalancer' resources in the model
>> I've proposed, and my proposal is also capable of supporting HA and
>> auto-scaling topologies without further significant model changes.
>>
>> Beyond this, other feedback I have:
>>
>>
>>- I don't recommend having loadbalancer_id added to the pool, member,
>>and healthmonitor objects. I see no reason a pool (and its child objects)
>>needs to be restricted to a single load balancer (and it may be very
>>advantageous in large clusters for it not to be).
>>
>> That is something we need to evaluate. Currently we already have that
> with the difference that pool is our 'loadbalancer object'.
> Ability to share objects between appliances definitely makes sense, but
> I'm not sure we need to address it right now.
>
Fair enough-- but I worry that if people write automation around
determining loadbalancer_id ("cluster_id" in my model) based on the pool or
member, then we'll break that automation if we ever add the ability for a
single pool to be shared across load balancer (clusters).
>
>
>>- I general, I prefer DRY code, so if we can avoid adding the
>> loadbalancer_id attribute to existing resources except for where it's
>>really needed, that's what I'd recommend. (Do we expect significant
>> savings
>>by repeating this attribute in various locations and avoiding one SQL
>>query? It seems to me we're inviting annoying bugs we'll have to work out
>>by having that field essentially act as a cache for the authoritative
>>source of information-- ie. the load balancer (cluster) object itself.)
>>
>> Well, DRY principle is good, but save on sql queries is good also,
> because the more queries we do, the more are the chances of different
> races, not to say that it could just eat up a bit of performance if DB is
> large enough.
>
Fair enough, eh.
>
>>-
>>- Having loadbalancer_id (cluster_id in my model) an attribute of the
>>VIP makes sense. I can't think of any reason a given VIP would be
>>associated with multiple load balancer (clusters).
>>
>>
>> Thanks,
>> Stephen
>>
>>
> One of the important properties of proposed loadbalancer object is not
> just another entity of API, but also a helper object for various coding
> problems that mostly don't affect API consumers.
>
>
Yep-- I think I'm addressing this with my proposed "cluster" object, also
being separate from the "loadbalancer" object, eh.
> Thanks,
> Eugene.
>
>
> ___
> 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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] L7 data types
Oh! One thing I forgot to mention below: On Sat, Feb 15, 2014 at 11:55 PM, Avishay Balderman wrote: > > Entity: L7Rule > > Field : compare_type > > Description: The way we compare the value against a given value > > Possible values: REG_EXP, EQ, GT, LT,EQ_IGNORE_CASE,(?) > > *Note*: With REG_EXP we can cover the rest of the values. > > > I seem to recall reading in the haproxy manual that regex matches are generally a lot slower than other kinds of matches. So, if you can do a 'path_beg' match, for example, that's a better performing choice over a 'path_reg' match which would accomplish the same thing. Given you have mentioned that 'STARTS_WITH' and 'ENDS_WITH' are listed as compare_types we're enumerating, I guess this has already been taken into account? 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] L7 data types
A couple quick suggestions (additions): Entity: L7Rule o Attribute: type § Possible values: - HTTP_METHOD o Attribute: compare_type § Possible values: - GT (greater than) - LT (less than) - GE (greater than or equal to) - LE (less than or equal to) Will we be doing syntax checking based on the L7Rule type being presented? (eg. if w'ere going to check that HEADER X has a value that is greater than Y, are we going to make sure that "Y" is an integer? Or if we're going to check that the PATH STARTS_WITH Z, are we going to make sure that Z is a non-zero-length string? ) Thanks, Stephen On Tue, Feb 18, 2014 at 3:58 AM, Avishay Balderman wrote: > Here are the suggested values for the attributes below: > > · Entity: L7Rule > > o Attribute: type > > § Possible values: > > · HOST_NAME > > · PATH > > · FILE_NAME > > · FILE_TYPE > > · HEADER > > · COOKIE > > o Attribute: compare_type > > § Possible values: > > · EQUAL > > · CONTAINS > > · REGEX > > · STARTS_WITH > > · ENDS_WITH > > · Entity:L7VipPolicyAssociation > > o Attribute:action > > § Possible values: > > · POOL (must have pool id) > > · REDIRECT(must have a url to be used as redirect destination) > > · REJECT > > > > > > *From:* Oleg Bondarev [mailto:obonda...@mirantis.com] > *Sent:* Monday, February 17, 2014 9:17 AM > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][LBaaS] L7 data types > > > > Hi, > > > > I would add another candidate for being a closed set: > L7VipPolicyAssociation.action (use_backend, block, etc.) > > > > Thanks, > > Oleg > > > > On Sun, Feb 16, 2014 at 3:53 PM, Avishay Balderman > wrote: > > (removing extra space from the subject – let email clients apply their > filters) > > > > *From:* Avishay Balderman > *Sent:* Sunday, February 16, 2014 9:56 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* [openstack-dev] [Neutron][LBaaS] L7 data types > > > > Hi > > There are 2 fields in the L7 model that are candidates for being a closed > set (Enum). > > I would like to hear your opinion. > > > > Entity: L7Rule > > Field : type > > Description: this field holds the part of the request where we should > look for a value > > Possible values: URL,HEADER,BODY,(?) > > > > Entity: L7Rule > > Field : compare_type > > Description: The way we compare the value against a given value > > Possible values: REG_EXP, EQ, GT, LT,EQ_IGNORE_CASE,(?) > > *Note*: With REG_EXP we can cover the rest of the values. > > > > In general In the L7rule one can express the following (Example): > > “check if in the value of header named ‘Jack’ starts with X” – if this is > true – this rule “returns” true > > > > > > Thanks > > > > Avishay > > > ___ > 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 > > -- 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] L7 - Update L7Policy
Hi! On Tue, Feb 18, 2014 at 12:18 AM, Samuel Bercovici wrote: > Hi, > > > > It matters, as someone might need to “debug” the backend setup and the > name, if exists, can add details. > > This obviously a vendor’s choice if they wish to push this back to backend > but the API should not remove this as a choice. > +1 > > > -Sam. > > > -- 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] Proposal for model change - Multiple services per floating IP
Hi Eugene, Aah, Ok. FWIW, splitting up the VIP into instance/"floating IP entity" separate from listener (ie. carries most of the attributes of VIP, in current implementation) still allows us to ensure tenants don't end up accidentally sharing an IP address. The "instance" could be associated with the neutron network port, and the haproxy listeners (one process per listener) could simply be made to listen on that port (ie. in that network namespace on the neutron node). There wouldn't be a need for two instances to share a single neutron network port. Has any thought been put to preventing tenants from accidentally sharing an IP if we stick with the current model? Stephen On Thu, Feb 13, 2014 at 4:20 AM, Eugene Nikanorov wrote: > So we have some constraints here because of existing haproxy driver impl, > the particular reason is that VIP created by haproxy is not a floating ip, > but an ip on the internal tenant network with a neutron port. So ip > uniqueness is enforced at port level and not at VIP level. We need to allow > VIPs to share the port, that is a part of multiple-vips-per-pool blueprint. > > Thanks, > Eugene. > -- 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] Proposal for model change - Logging configuration
(for > > example): > > > > Automated scaling of load-balancer services > > > [Roger] Would the Heat module be called on to add more LB's to the farm? > > > I talked about horizontal scaling of load balancers above under "High > > Availability," but, at least in the case of a software appliance, > > vertical scaling should also be possible in an active-standby > > cluster_model by > ** > > ___ > 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Proposal for model change - Loadbalancer Instance feedback
oadbalancer_id added to the pool, member, and healthmonitor objects. I see no reason a pool (and its child objects) needs to be restricted to a single load balancer (and it may be very advantageous in large clusters for it not to be). - I general, I prefer DRY code, so if we can avoid adding the loadbalancer_id attribute to existing resources except for where it's really needed, that's what I'd recommend. (Do we expect significant savings by repeating this attribute in various locations and avoiding one SQL query? It seems to me we're inviting annoying bugs we'll have to work out by having that field essentially act as a cache for the authoritative source of information-- ie. the load balancer (cluster) object itself.) - Having loadbalancer_id (cluster_id in my model) an attribute of the VIP makes sense. I can't think of any reason a given VIP would be associated with multiple load balancer (clusters). Thanks, Stephen On Tue, Feb 11, 2014 at 7:12 AM, Eugene Nikanorov wrote: > > The proposed model is described here, although without a picture: > https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance > > autoscaling is something that generally out of scope of Neutron project > and more in the scope of Heat project. > Automated provisioning of load balancer devices as was said is what > 'service vm framework' is trying to address. > -- 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] Proposal for model change - Multiple services per floating IP
Hello! This e-mail is concerning the "Multiple load balanced services per floating IP" feature: Sam, I think you said: On Tue, Feb 11, 2014 at 5:26 AM, Samuel Bercovici wrote: > > · Multiple load balanced services per floating IP - You can > already multiple VIPs using the same IP address for different services. > > > And Eugene said: > Multiple load balanced services per floating IP That is what blueprint 'multiple vips per pool' is trying to address. Is this blueprint not yet implemented? When I attempt to create multiple VIPs using the same IP in my test cluster, I get: sbalukoff@testbox:~$ neutron lb-vip-create --name test-vip2 --protocol-port 8000 --protocol HTTP --subnet-id a4370142-dc49-4633-9679-ce5366c482f5 --address 10.48.7.7 test-lb2 Unable to complete operation for network aa370a26-742d-4eb6-a6f3-a8c344c664de. The IP address 10.48.7.7 is in use. >From that, I gathered there was a uniqueness check on the IP address. If this has been implemented previously, could y'all point me at a working example showcasing the CLI or API commands used to create multiple services per floating IP (or just point out to me what I'm doing wrong)? Regardless of the above: I think splitting the concept of a 'VIP' into 'instance' and 'listener' objects has a couple other benefits as well: - You can continue to do a simple uniqueness check on the IP address, as only one instance should have a given IP. - The 'instance' object can contain a 'tenant_id' attribute, which means that at the model level, we enforce the idea that a given floating IP can only be used by one tenant (which is good, from a security perspective). - This seems less ambiguous from a terminology perspective. The name 'VIP' in other contexts means 'virtual IP address', which is the same thing as a floating IP, which in other contexts is usually considered to be unique to a subset of devices that share the IP (or pass it between them). It doesn't necessarily have anything to do with layers 4 and above in the OSI model. However, if in the context of Neutron LBaaS, "VIP" has a "protocol-port" attribute, this means it's no longer just a floating IP: It's a floating IP + TCP port (plus other attributes that make sense for a TCP service). This feels like Neutron LBaaS is trying to redefine what a "virtual IP" is, and is in any case going to be confusing for new comers expecting it to be one thing when it's actually another. Thanks, 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
