[openstack-dev] [neutron] documenting configuration option segregation between services and agents
We should expand services_and_agents devref to describe how and why configuration options should be segregated between services and agents. I stumbled into this recently while trying to remove a confusing duplicate configuration option [1][2][3]. The present separation appears to be 'tribal knowledge', and not consistently enforced. So I'll take a shot at explaining the status quo as I understand it and hopefully some seasoned contributors can fill in the gaps. =BEGIN PROPOSED DEVREF SECTION= Configuration Options - In addition to database access, configuration options are segregated between neutron-server and agents. Both services and agents may load the main neutron.conf since this file should contain the Oslo message configuration for internal Neutron RPCs and may contain host specific configuration such as file paths. In addition neutron.conf contains the database, keystone and nova credentials and endpoints strictly for use by neutron-server. In addition neutron-server may load a plugin specific configuration file, yet the agents should not. As the plugin configuration is primarily site wide options and the plugin provides the persistence layer for Neutron, agents should instructed to act upon these values via RPC. Each individual agent may have its own configuration file. This file should be loaded after the main neutron.conf file, so the agent configuration takes precedence. The agent specific configuration may contain configurations which vary between hosts in a Neutron deployment such as the external_network_bridge for a L3 agent. If any agent requires access to additional external services beyond the Neutron RPC, those endpoints should be defined in the agent specific configuration file (e.g. nova metadata for metadata agent). ==END PROPOSED DEVREF SECTION== Disclaimers: this description is informed my by own experiences reading existing documentation and examining example configurations including various devstack deployments. I've tried to use RFC style wording: should, may, etc.. I'm relatively confused on this subject, and my goal in writing this is to obtain some clarity myself and share it with others in the form of documentation. [1] https://review.openstack.org/262621 [2] https://bugs.launchpad.net/neutron/+bug/1523614 [3] https://review.openstack.org/268153 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Octavia] Octavia VM image design
It seems to me there are two major approaches to the Octavia VM design: 1. Start with a standard Linux distribution (e.g. Ubuntu 14.04 LTS) and install HAProxy 1.5 and Octavia control layer 2. Develop a minimal purpose driven distribution (similar to m0n0wall) with just HAProxy, iproute2 and a Python runtime for the control layer. The primary difference here is additional development effort for option 2, verses the increased image size of option 1. Using Ubuntu and CirrOS images a representative of the two options it looks like the image size difference is on the about 20 times larger for a full featured distribution. If one of the HA models is to spin up a replacement instance on failure the image size could be significantly affect fail-over time. For initial work I think starting with a standard distribution would be sensible, but we should target systemd (Debian adopted systemd as new default, and Ubuntu is following suit). I wanted to find out if there is interest in a minimal Octavia image, and if so this may affect design decisions on the instance control plane component. -Dustin ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Octavia] Proposal to support multiple listeners on one HAProxy instance
I'm on the fence here, I see a number of advantages to each: Single HAProxy process per listener: - Failure isolation - TLS Performance -- for non TLS services HAProxy is IO bound, and there is no reason to run it across multiple CPU cores, but with HAProxy terminating TLS there is an increased potential of a DoS with a large number of incoming TLS handshakes. - Reduced impact of reconfiguration -- while there is very little impact when reloading the configuration since HAProxy hands off the listener sockets to the new instance and the old instance continues to handle those connections, with a more complex configuration it is more likely to affect services on other listeners. Multiple listeners on a single HAProxy instance: - Enables sharing pools between listeners -- this would reduce keep health monitor traffic, and pipe-lining requests from multiple listeners is possible - Reduced resource usage -- we should preform the benchmarks and quantify this - Simplified stats/log aggregation - Simplified Octavia instances -- I think each Octavia instance only running a single HAProxy process is a win, its easier to monitor and upstart/systemd/init only needs to start a single process. Dustin Lundquist ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor
Brandon, One key limitation of such a driver, is it will not work in installations where the Neutron server is installed across multiple nodes since the HAProxy network namespace will be created or updated on the node which received the Neutron API request. This will work for Devstack and testing and is a good starting place, but is not usable for many deployments. -Dustin On Thu, Jul 10, 2014 at 1:37 PM, Brandon Logan wrote: > Okay so after talking to Kyle, we've decided to forego creating a new > version of the agent right away and just creating a new haproxy driver > based off the namespace_driver, but it does not require the agent. This > will speed up development and allow for TLS and L7 features to get in with > a reference implementation. If anyone objects please let me know. I'm > going to start on this right away. > > Thanks, > Brandon > -- > *From:* Samuel Bercovici [samu...@radware.com] > *Sent:* Thursday, July 10, 2014 1:26 PM > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor > > The haproxy reference is dependent on the agent. > > Radware’s solution does not use an agent. > > I was making sure that solutions such as ours will be possible. > > > > *From:* Dustin Lundquist [mailto:dus...@null-ptr.net] > *Sent:* Thursday, July 10, 2014 8:51 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor > > > > Samuel, > > > > I've heard this mentioned before, but looking at the code the haproxy > namespace driver uses the agent driver interface rather the the abstract > driver interface. Are you sure the HAProxy driver can be used without the > agent, if so could you explain how? > > Thanks, > > > > > > Dustin Lundquist > > > > > On Thursday, July 10, 2014, Samuel Bercovici wrote: > > New/updated v2 driver could be done without an agent (same as was possible > in v1). > > > > *From:* Doug Wiegley [mailto:do...@a10networks.com > <http://UrlBlockedError.aspx>] > *Sent:* Thursday, July 10, 2014 8:06 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor > > > > Modified slightly, my read on the decision was: > >- Create a v2 agent, and make the ref haproxy driver use the v2 agent >and v2 obj model. >- At a lower priority, work on a shim for non-agent older drivers. > This is de-coupled from the haproxy ref driver, and could happen in >parallel if we had extra resources. This shim will have odd corner cases >(a second listener on a vip, e.g.), which will chuck errors. > > The ref haproxy driver is highest priority, and thus the v2 agent, as > lbaas v2 goes nowhere without it. > > > > Doug > > > > > > > > *From: *Samuel Bercovici <http://UrlBlockedError.aspx>> > *Reply-To: *"OpenStack Development Mailing List (not for usage > questions)" <http://UrlBlockedError.aspx>> > *Date: *Thursday, July 10, 2014 at 10:36 AM > *To: *"OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org <http://UrlBlockedError.aspx>> > *Subject: *Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor > > > > This is also my understanding. > > > > > > *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net > <http://UrlBlockedError.aspx>] > *Sent:* Thursday, July 10, 2014 6:30 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor > > > > Per the IRC discussion this morning, I believe it was decided that we > would prioritize creating a v2 agent which should run in parallel with the > v1 agent. Further, for any subsequent driver shim layer, this should happen > after the v2 agent is functional. > > > > ... or I may have misunderstood what was decided in the meeting. :) In > any case, y'all should feel free to correct me here and/or raise other > concerns we didn't think about, eh! > > > > Stephen > > > > On Wed, Jul 9, 2014 at 3:12 PM, Brandon Logan <http://UrlBlockedError.aspx>> wrote: > > Shim will become quite complicated due to the fact we won't be able to > actually send any load balancer information to the driver until a load > balancer is linked to a listener, pool, and member. The reason is because > for a vip to be created it needs attributes from a loa
Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor
Samuel, I've heard this mentioned before, but looking at the code the haproxy namespace driver uses the agent driver interface rather the the abstract driver interface. Are you sure the HAProxy driver can be used without the agent, if so could you explain how? Thanks, Dustin Lundquist On Thursday, July 10, 2014, Samuel Bercovici wrote: > New/updated v2 driver could be done without an agent (same as was > possible in v1). > > > > *From:* Doug Wiegley [mailto:do...@a10networks.com > ] > *Sent:* Thursday, July 10, 2014 8:06 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor > > > > Modified slightly, my read on the decision was: > >- Create a v2 agent, and make the ref haproxy driver use the v2 agent >and v2 obj model. >- At a lower priority, work on a shim for non-agent older drivers. > This is de-coupled from the haproxy ref driver, and could happen in >parallel if we had extra resources. This shim will have odd corner cases >(a second listener on a vip, e.g.), which will chuck errors. > > The ref haproxy driver is highest priority, and thus the v2 agent, as > lbaas v2 goes nowhere without it. > > > > Doug > > > > > > > > *From: *Samuel Bercovici > > *Reply-To: *"OpenStack Development Mailing List (not for usage > questions)" > > *Date: *Thursday, July 10, 2014 at 10:36 AM > *To: *"OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org > > > *Subject: *Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor > > > > This is also my understanding. > > > > > > *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net > ] > *Sent:* Thursday, July 10, 2014 6:30 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor > > > > Per the IRC discussion this morning, I believe it was decided that we > would prioritize creating a v2 agent which should run in parallel with the > v1 agent. Further, for any subsequent driver shim layer, this should happen > after the v2 agent is functional. > > > > ... or I may have misunderstood what was decided in the meeting. :) In > any case, y'all should feel free to correct me here and/or raise other > concerns we didn't think about, eh! > > > > Stephen > > > > On Wed, Jul 9, 2014 at 3:12 PM, Brandon Logan > wrote: > > Shim will become quite complicated due to the fact we won't be able to > actually send any load balancer information to the driver until a load > balancer is linked to a listener, pool, and member. The reason is because > for a vip to be created it needs attributes from a load balancer and > listener. A vip also has a required attribute of pool_id in the old API so > all the old driver are expecting a pool_id. So this means we need a pool > first. Since the subnet_id has been moved off the pool and onto the pool > member, we will need to have a pool with at least one member before we can > send all that information to the driver. > > Now once that is done, it will probably get even crazier with updates and > deletes to each one of those entities. > > So should time and effort be spent on the shim, which is temporary and > eventually thrown away. Or should time be spent on creating a new version > of the agent and namspace driver based off the new driver interface, which > will need to be done anyway? > > Doing the shim could end up being faster than creating a new version of > the agent, but since there are going to be a lot of crazy edge cases, I > question the stability of it and the time it may take for it to become > stable. > > One problem with not doing the shim is the older drivers cannot be used > with the new API and will have to be updated. To this, I would argue that > there is no benefit to using the new API with an old driver versus using > the Old API with the old driver, right now. Once L7 and TLS get in then > yes there would be. > > I'd just like to get people's ideas on this. > > Thanks, > 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] [Neutron][LBaaS] subjAltName and CN extraction from x509 certificates
It doesn't look like NSS is currently used within Neutron or Keystone. Another alternative would be to write the certificate to a temp file and then invoke "openssl x509 -text -noout -in $TEMP_FILE" and parse the output, Keystone currently does similar (keystone/common/openssl.py). Given renewed focus by security researchers on cryptographic libraries, I think we should avoid requiring additional cryptographic libraries and use what is already in use within OpenStack. -Dustin On Fri, Jun 27, 2014 at 7:26 AM, John Dennis wrote: > On 06/27/2014 12:21 AM, Carlos Garza wrote: > > I don't know where we can check in experimental code so I have a > demonstration > > of how to extract CNs subjAltNames or what ever we want from x509 > certificates. Later on > > I plan to use the OpenSSL libraries to verify certs coming from barbican > are valid and > > actually do sign the private_key it is associated with. > > > > https://github.com/crc32a/ssl_exp.git > > > > > I'm always leary of reinventing the wheel, we already have code to > manage pem files (maybe this should be in oslo, it was proposed once) > > keystone/common/pemutils.py > > I'm also leary of folks writing their own ASN.1 parsing as opposed to > using existing libraries. Why? It's really hard to get right so you > correctly handle all the cases, long established robust libraries are > better at this. > > python-nss (which is a Python binding to the NSS crypto library) has > easy to use code to extract just about anything from a cert, here is an > example python script using your example pem file. If using NSS isn't an > option I'd rather see us provide the necessary binding in pyopenssl than > handcraft one-off routines. FWIW virtually everything you see in the > cert output below can be accessed as Pythonically as a Python object(s) > when using python-nss. > > #!/usr/bin/python > > import sys > import nss.nss as nss > > nss.nss_init_nodb() > > filename = sys.argv[1] > > # Read the PEM file > try: > binary_cert = nss.read_der_from_file(filename, True) > except Exception as e: > print e > sys.exit(1) > else: > print "loaded cert from file: %s" % filename > > # Create a Certificiate object from the binary data > cert = nss.Certificate(binary_cert) > > # Dump some basic information > print > print "cert subject: %s " % cert.subject > print "cert CN: %s " % cert.subject_common_name > print "cert validity:" > print "Not Before: %s" % cert.valid_not_before_str > print "Not After: %s" % cert.valid_not_after_str > > print > print "\ncert has %d extensions" % len(cert.extensions) > > for extension in cert.extensions: > print "%s (critical: %s)" % (extension.name, extension.critical) > > print > extension = cert.get_extension(nss.SEC_OID_X509_SUBJECT_ALT_NAME) > if extension: > print "Subject Alt Names:" > for name in nss.x509_alt_name(extension.value): > print "%s" % name > else: > print "cert does not have a subject alt name extension" > > # Dump entire cert in friendly format > print > print ">>> Entire cert contents <<<" > print cert > > sys.exit(0) > > Yields this output: > > loaded cert from file: cr1.pem > > cert subject: CN=www.digicert.com,O="DigiCert, > Inc.",L=Lehi,ST=Utah,C=US,postalCode=84043,STREET=2600 West Executive > Parkway,STREET=Suite > 500,serialNumber=5299537-0142,incorporationState=Utah,incorporationCountry=US,businessCategory=Private > Organization > cert CN: www.digicert.com > cert validity: > Not Before: Thu Mar 20 00:00:00 2014 UTC > Not After: Sun Jun 12 12:00:00 2016 UTC > > > cert has 10 extensions > Certificate Authority Key Identifier (critical: False) > Certificate Subject Key ID (critical: False) > Certificate Subject Alt Name (critical: False) > Certificate Key Usage (critical: True) > Extended Key Usage (critical: False) > CRL Distribution Points (critical: False) > Certificate Policies (critical: False) > Authority Information Access (critical: False) > Certificate Basic Constraints (critical: True) > OID.1.3.6.1.4.1.11129.2.4.2 (critical: False) > > Subject Alt Names: > www.digicert.com > content.digicert.com > digicert.com > www.origin.digicert.com > login.digicert.com > > >>> Entire cert contents <<< > Data: > Version: 3 (0x2) > Serial Number: 13518267578909330747227050733614153347 > (0xa2b860cca01f45fd7ee63601b1c3e83) > Signature Algorithm: > Algorithm: PKCS #1 SHA-256 With RSA Encryption > Issuer: CN=DigiCert SHA2 Extended Validation Server CA,OU= > www.digicert.com,O=DigiCert Inc,C=US > Validity: > Not Before: Thu Mar 20 00:00:00 2014 UTC > Not After: Sun Jun 12 12:00:00 2016 UTC > Subject: CN=www.digicert.com,O="DigiCert, > Inc.",L=Lehi,ST=Utah,C=US,postalCode=84043,STREET=2600 West Executive > Parkway,STREET=Suite > 500,serialNumber=5299537-0142,incorporationState=Utah,incorporationCountry=US,busin
Re: [openstack-dev] [Neutron][LBaaS] Which entities need status
I think there is significant value in having status on the listener object even in the case of HAProxy. While HAProxy can support multiple listeners in a single process, there is no reason it needs to be deployed that way. Additionally in the case of updating a configuration with an additional listener, the other listeners and the load balancer object are not in an unavailable or down state before the configuration is applied, only the new listener object is down or building. In the case of the HAProxy namespace driver, one could map the namespace creation and HAProxy process to the load balancer object status, but each listener can have its own status based on the availability of members in its pools. For the initial version of our new object model we be pragmatic and minimize complexity and change, we can preform a reduction across all listeners to generate an overall load balancer status. -Dustin On Tue, Jun 24, 2014 at 3:15 PM, Vijay B wrote: > Hi Brandon, Eugene, Doug, > > During the hackathon, I remember that we had briefly discussed how > listeners would manifest themselves on the LB VM/device, and it turned out > that for some backends like HAProxy it simply meant creating a frontend > entry in the cfg file whereas on other solutions it could mean spawning a > process/equivalent. So we must have status fields to track the state of any > such entities that are actually created. In the listener case, an ACTIVE > state would mean that the appropriate backend processes have been created > or that the required config file entries have been made. > > I like the idea of having relational objects and setting the status on > them, and in our case we can use the status fields > (pool/healthmonitor/listener) in each table to denote the state of the > relationship (configuration/association on backend) to another object like > LoadBalancer. So I think the status fields should stay. > > In this scenario, some entities' status could be updated in lbaas proper, > and some in the driver implementation. I don't have a strict preference as > to which among lbaas proper or the driver layer announces the status since > we discussed on the IRC that we'd have helper functions in the driver to do > these updates. > > > Regards, > Vijay > > > On Tue, Jun 24, 2014 at 12:16 PM, Brandon Logan < > brandon.lo...@rackspace.com> wrote: > >> On Tue, 2014-06-24 at 18:53 +, Doug Wiegley wrote: >> > Hi Brandon, >> > >> > I think just one status is overloading too much onto the LB object >> (which >> > is perhaps something that a UI should do for a user, but not something >> an >> > API should be doing.) >> >> That is a good point and perhaps its another discussion to just have >> some way to show the status an entity has for each load balancer, which >> is what mark suggested for the member status at the meet-up. >> >> > >> > > 1) If an entity exists without a link to a load balancer it is purely >> > > just a database entry, so it would always be ACTIVE, but not really >> > > active in a technical sense. >> > >> > Depends on the driver. I don¹t think this is a decision for lbaas >> proper. >> >> Driver is linked to the flavor or provider. Flavor or provider will/is >> linked to load balancer. We won't be able get a driver to send anything >> to if there isn't a load balancer. Without a driver it is a decision >> for lbaas proper. I'd be fine with setting the status of these >> "orphaned" entities to just ACTIVE but I'm just worried about the status >> management in the future. >> >> > >> > >> > > 2) If some of these entities become shareable then how does the status >> > > reflect that the entity failed to create on one load balancer but was >> > > successfully created on another. That logic could get overly complex. >> > >> > That¹s a status on the join link, not the object, and I could argue >> > multiple ways in which that should be one way or another based on the >> > backend, which to me, again implies driver question (backend could queue >> > for later, or error immediately, or let things run degraded, orŠ) >> >> Yeah that is definitely an argument. I'm just trying to keep in mind >> the complexities that could arise from decisions made now. Perhaps it >> is the wrong way to look at it to some, but I don't think thinking about >> the future is a bad thing and should never be done. >> >> > >> > Thanks, >> > Doug >> > >> > >> > >> > >> > On 6/24/14, 11:23 AM, "Brandon Logan" >> wrote: >> > >> > >I think we missed this discussion at the meet-up but I'd like to bring >> > >it up here. To me having a status on all entities doesn't make much >> > >sense, and justing having a status on a load balancer (which would be a >> > >provisioning status) and a status on a member (which would be an >> > >operational status) are what makes sense because: >> > > >> > >1) If an entity exists without a link to a load balancer it is purely >> > >just a database entry, so it would always be ACTIVE, but not really >> > >active i
Re: [openstack-dev] [Neutron][LBaaS] Layer7 Switching - L7 Rule - comapre_type values
I brought this up on https://review.openstack.org/#/c/101084/. -Dustin On Tue, Jun 24, 2014 at 7:57 AM, Avishay Balderman wrote: > Hi Dustin > > I agree with the concept you described but as far as I understand it is > not currently supported in Neutron. > > So a driver should be fully compatible with the interface it implements. > > > > Avishay > > > > *From:* Dustin Lundquist [mailto:dus...@null-ptr.net] > *Sent:* Tuesday, June 24, 2014 5:41 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Layer7 Switching - L7 > Rule - comapre_type values > > > > I think the API should provide an richly featured interface, and > individual drivers should indicate if they support the provided > configuration. For example there is a spec for a Linux LVS LBaaS driver, > this driver would not support TLS termination or any layer 7 features, but > would still be valuable for some deployments. The user experience of such a > solution could be improved if the driver to propagate up a message > specifically identifying the unsupported feature. > > > > > > -Dustin > > > > On Tue, Jun 24, 2014 at 4:28 AM, Avishay Balderman > wrote: > > Hi > > One of L7 Rule attributes is ‘compare_type’. > > This field is the match operator that the rule should activate against the > value found in the request. > > Below is list of the possible values: > > - Regexp > > - StartsWith > > - EndsWith > > - Contains > > - EqualTo (*) > > - GreaterThan (*) > > - LessThan (*) > > > > The last 3 operators (*) in the list are used in numerical matches. > > Radware load balancing backend does not support those operators “out of > the box” and a significant development effort should be done in order to > support it. > > We are afraid to miss the Junu timeframe if we will have to focus in > supporting the numerical operators. > > Therefore we ask to support the non-numerical operators for Junu and add > the numerical operators support post Junu. > > > > See https://review.openstack.org/#/c/99709/4/specs/juno/lbaas-l7-rules.rst > > > > 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 > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Layer7 Switching - L7 Rule - comapre_type values
I think the API should provide an richly featured interface, and individual drivers should indicate if they support the provided configuration. For example there is a spec for a Linux LVS LBaaS driver, this driver would not support TLS termination or any layer 7 features, but would still be valuable for some deployments. The user experience of such a solution could be improved if the driver to propagate up a message specifically identifying the unsupported feature. -Dustin On Tue, Jun 24, 2014 at 4:28 AM, Avishay Balderman wrote: > Hi > > One of L7 Rule attributes is ‘compare_type’. > > This field is the match operator that the rule should activate against the > value found in the request. > > Below is list of the possible values: > > - Regexp > > - StartsWith > > - EndsWith > > - Contains > > - EqualTo (*) > > - GreaterThan (*) > > - LessThan (*) > > > > The last 3 operators (*) in the list are used in numerical matches. > > Radware load balancing backend does not support those operators “out of > the box” and a significant development effort should be done in order to > support it. > > We are afraid to miss the Junu timeframe if we will have to focus in > supporting the numerical operators. > > Therefore we ask to support the non-numerical operators for Junu and add > the numerical operators support post Junu. > > > > See https://review.openstack.org/#/c/99709/4/specs/juno/lbaas-l7-rules.rst > > > > 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
Re: [openstack-dev] [Octavia] PTL and core team members
Dolph, I appreciate the suggestion. In the mean time how does the review process work without core developers to approve gerrit submissions? Thanks, Dustin Lundquist On Thu, Jun 19, 2014 at 8:06 PM, Dolph Mathews wrote: > > On Thu, Jun 19, 2014 at 7: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? >> >> > I'm going to jump in here and suggest that you slow down. Using an awful > horse and cart analogy, it seems you're trying to select the best > cart-pulling horse when there's not yet a cart. > > I'd suggest running through a development cycle without an election or an > official PTL. **Work as a tight community of contributors to establish the > project,** and by the time you have a real need for a PTL (probably around > the time you begin dealing with release overhead), you'll have a list of > eligible voters (per the election guidelines that Anita linked). More > importantly, those voters will have developed the necessary perspective to > go about nominating and voting for a PTL with confidence. > > Best of luck! > > -Dolph > > >> 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 >>> >>
Re: [openstack-dev] [Neutron][LBaaS] LBaaS Mid Cycle Sprint
Actually the channel name is #neutron-lbaas. On Tue, Jun 17, 2014 at 8:03 AM, Kyle Mestery wrote: > Also, pop into #openstack-lbaas on Freenode, we have people there > monitoring the channel. > > On Tue, Jun 17, 2014 at 9:19 AM, Dustin Lundquist > wrote: > > We have an Etherpad going here: > > https://etherpad.openstack.org/p/juno-lbaas-mid-cycle-hackathon > > > > > > Dustin > > > > > > On Tue, Jun 17, 2014 at 4:05 AM, Avishay Balderman > > > wrote: > >> > >> Hi > >> As the lbass mid cycle sprint starts today, is there any way to track > and > >> understand the progress (without flying to Texas... ) > >> > >> 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 > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] LBaaS Mid Cycle Sprint
We have an Etherpad going here: https://etherpad.openstack.org/p/juno-lbaas-mid-cycle-hackathon Dustin On Tue, Jun 17, 2014 at 4:05 AM, Avishay Balderman wrote: > Hi > As the lbass mid cycle sprint starts today, is there any way to track and > understand the progress (without flying to Texas... ) > > 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
