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
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
@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
@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
(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
: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
(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
)
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
--
*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
,
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
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.
11 matches
Mail list logo
