[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
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 samu...@radware.com wrote: New/updated v2 driver could be done without an agent (same as was possible in v1). *From:* Doug Wiegley [mailto:do...@a10networks.com javascript:_e(%7B%7D,'cvml','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 samu...@radware.com javascript:_e(%7B%7D,'cvml','samu...@radware.com'); *Reply-To: *OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org javascript:_e(%7B%7D,'cvml','openstack-dev@lists.openstack.org'); *Date: *Thursday, July 10, 2014 at 10:36 AM *To: *OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org javascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','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 brandon.lo...@rackspace.com javascript:_e(%7B%7D,'cvml','brandon.lo...@rackspace.com'); 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 javascript:_e(%7B%7D,'cvml','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] 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 brandon.lo...@rackspace.com 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 samu...@radware.com 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 samu...@radware.com http://UrlBlockedError.aspx *Reply-To: *OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org 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 brandon.lo...@rackspace.com 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 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
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 jden...@redhat.com 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,businessCategory=Private Organization Subject Public Key Info: Public Key Algorithm: Algorithm: PKCS #1 RSA Encryption
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 avish...@radware.com 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] [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 avish...@radware.com 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 avish...@radware.com 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] 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 os.v...@gmail.com 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 brandon.lo...@rackspace.com 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 in a technical sense. 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
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 dolph.math...@gmail.com wrote: On Thu, Jun 19, 2014 at 7:55 PM, Stephen Balukoff sbaluk...@bluebox.net 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 ante...@anteaya.info 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
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 avish...@radware.com 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
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 mest...@noironetworks.com 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 dus...@null-ptr.net 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 avish...@radware.com 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
