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 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] 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 brandon.lo...@rackspace.commailto: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.orgmailto: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
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.commailto:samu...@radware.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto: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.orgmailto: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 brandon.lo...@rackspace.commailto: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.orgmailto: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
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 samu...@radware.commailto:samu...@radware.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto: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.orgmailto: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 brandon.lo...@rackspace.commailto: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.orgmailto: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
Absolutely, and work on those can start immediately, for any vendor that wants to update their driver. I’d recommend using the driver base class in this review, which modifies the current new one, based on some stuff that Brandon found: https://review.openstack.org/#/c/105610 Thanks, Doug From: Samuel Bercovici samu...@radware.commailto:samu...@radware.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, July 10, 2014 at 11:36 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor 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 samu...@radware.commailto:samu...@radware.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto: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.orgmailto: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 brandon.lo...@rackspace.commailto: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.orgmailto: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
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
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.commailto: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.comjavascript:_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.comjavascript:_e(%7B%7D,'cvml','samu...@radware.com'); Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgjavascript:_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.orgjavascript:_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.netjavascript:_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.comjavascript:_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.orgjavascript:_e(%7B%7D,'cvml','OpenStack-dev@lists.openstack.org'); http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Stephen Balukoff Blue
Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor
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.commailto: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.comUrlBlockedError.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.comUrlBlockedError.aspx Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgUrlBlockedError.aspx Date: Thursday, July 10, 2014 at 10:36 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgUrlBlockedError.aspx Subject: Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor This is also my understanding. From: Stephen Balukoff [mailto:sbaluk...@bluebox.netUrlBlockedError.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.comUrlBlockedError.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 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
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] Shim vs Agent Refactor
Dustin, Oh I understand that, but this is just an easy way to get a reference implementation in that can be used for testing newer features such as TLS and L7. Like I said before, sorry I keep course correcting on this but it's a very fluid process when there are so many unknowns. Thanks, Brandon From: Dustin Lundquist [dus...@null-ptr.net] Sent: Thursday, July 10, 2014 4:24 PM To: OpenStack Development Mailing List (not for usage questions) Subject: 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.commailto: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.netmailto: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.commailto: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.comhttp://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.comhttp://UrlBlockedError.aspx Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orghttp://UrlBlockedError.aspx Date: Thursday, July 10, 2014 at 10:36 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orghttp://UrlBlockedError.aspx Subject: Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor This is also my understanding. From: Stephen Balukoff [mailto:sbaluk...@bluebox.nethttp://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.comhttp://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
[openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor
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
