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 knowled
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, iprout
r 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
r
>
> 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
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
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 fo
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
list
er 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: [op
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
valuabl
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
&
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 a
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.
12 matches
Mail list logo
