hanks,
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 s
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 Refacto
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: Thur
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
ment 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.
ons)"
mailto: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:0
rg>>
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] [Neutr
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][LBaa
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
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 de
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
