Hey LBaaS folks,
This is you friendly reminder to provide any agenda items for tomorrow's weekly
IRC meeting. Please add them to the agenda wiki ==
https://wiki.openstack.org/wiki/Network/LBaaS#Agenda. The agenda currently has
these items:
* Review the work items from the Hackathon and
Hey LBaaS folks,
This is you friendly reminder to provide any agenda items for tomorrow's weekly
IRC meeting. Please add them to the agenda wiki ==
https://wiki.openstack.org/wiki/Network/LBaaS#Agenda.
Cheers,
--Jorge
___
OpenStack-dev mailing list
Hey guys,
I just noticed that Amphora won the vote. I have several issues with
this.
1) Amphora wasn't in the first list of items to vote on. I'm confused as
to how it ended up in the final round. The fact that it did makes me
feel like the first round of votes were totally disregarded.
2) The
Hi everyone,
I'd like to gauge everyone's interest in a possible mini-summit for Neturon
LBaaS. If enough people are interested I'd be happy to try and set something
up. The Designate team just had a productive mini-summit in Austin, TX and it
was nice to have face-to-face conversations with
Hey everyone,
Now that the thread has had enough time for people to reply it appears that the
majority of people that vocalized their opinion are in favor of a mini-summit,
preferably to occur in Atlanta days before the Openstack summit. There are
concerns however, most notably the concern
Hey Neutron LBaaS folks,
Per last week's IRC meeting I have created a preliminary requirements
use case wiki page. I requested adding such a page since there appears to
be a lot of new interest in load balancing and feel that we need a
structured way to align everyone's interest in the project.
together! This will be
really useful for LBaaS discussions.
I updated the wiki to include L7 rules support and also marking already
implemented requirements.
Thanks,
Oleg
On Wed, Mar 19, 2014 at 2:57 AM, Jorge Miramontes
jorge.miramon...@rackspace.commailto:jorge.miramon...@rackspace.com
security feature.
Is this controlling access to the VIP’s IP address or to pool members IP
addresses? There is also a Firewall service in Neutron. Could this feature
better fit in that service?
Agree, it's better to utilize what fwaas has to offer.
Eugene.
Youcef
From: Jorge Miramontes
The use case from our customers has been mostly for database (MySql) load
balancing. If the master goes down then they want another master/slave on
standby ready to receive traffic. In the simplest case, I think Neutron can
achieve this with 2 pools with 1 node each. If pool #1 goes down then
Thanks Itsuro,
Good requirement since Neutron LBaaS is an asynchronous API.
Cheers,
--Jorge
On 3/24/14 7:27 PM, Itsuro ODA o...@valinux.co.jp wrote:
Hi LBaaS developpers,
I added 'Status Indication' to requirement Wiki.
It may be independent from object model discussion
but I think this is
Hey Susanne,
I think it makes sense to group drivers by each LB software. For example, there
would be a driver for HAProxy, one for Citrix's Netscalar, one for Riverbed's
Stingray, etc. One important aspect about Openstack that I don't want us to
forget though is that a tenant should be able
Hey Neutron LBaaS folks!
I created the following etherpad in an effort to mitigate the visibility issue
some of us have been trying to address. Please update it before tomorrow's
weekly IRC meeting if possible so that the community is aware of what every
team is currently engaged on. This will
Hey Andres,
In my experience with usage gathering consolidating statistics at the root
layer is usually a bad idea. The reason is that you lose potentially useful
information once you consolidate data. When it comes to troubleshooting issues
(such as billing) this lost information can cause
or should I follow the “Requirements around
statistics and billing” thread?
Thank you!
Andres
From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com]
Sent: Thursday, June 12, 2014 6:35 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron
Hey LBaaS folks!
Please send me any agenda items you would like discussed tomorrow so I can
organize the meeting. And as usual, please update the weekly standup etherpad.
Everything should be organized on the main wiki page now ==
https://wiki.openstack.org/wiki/Neutron/LBaaS :)
Cheers,
Hey German,
We have similar statuses. I have been wanting to add a 'QUEUED' status
however. The reason is that we currently use 'BUILD' which indicates
active provisioning when in reality it is actually queued first and then
provisioned. Thus, there are potential issues when trying to determine
+1 to QUEUED status.
For entities that have the concept of being attached/detached why not have
a 'DETACHED' status to indicate that the entity is not provisioned at all
(i.e. The config is just stored in the DB). When it is attached during
provisioning then we can set it to 'ACTIVE' or any of
for certain drivers to hold other drivers
hostage
For some time there was a policy (openstack-wide) that public API should have a
free open source implementation.
In this sense open source driver may hold other drivers as hostages.
Eugene.
On Thu, Jul 3, 2014 at 10:37 PM, Jorge Miramontes
Hey Mark,
To add, one reason we have a DELETED status at Rackspace is that certain
sub-resources are still relevant to our customers. For example, we have a
usage sub-resource which reveals usage records for the load balancer. To
illustrate, a user issues a DELETE on /loadbalancers/id but can
Hi LBaaS folks,
This is your weekly friendly reminder to give me agenda items for tomorrow's
meeting. Also please update the weekly standup document when you get a chance!
Thanks!
Current agenda items:
* Paris summit talks (Susanne)
* Reviews
Cheers,
--Jorge
Hey Kyle (and anyone else that may know the answers to my questions),
There are several blueprints that don't have Juno milestones attached to them
and was wondering if we could assign them so the broader community is aware of
the work the LBaaS folks are working on. These are the blueprints
Hey LBaaS folks,
This is you friendly reminder to provide any agenda items for tomorrow's weekly
IRC meeting. The agenda currently has two items:
* Review Updates
* TLS work division
Cheers,
--Jorge
P.S. Please don't forget to update the weekly standup ==
Hey Doug,
In terms of taking a step backward from a user perspective I'm fine with
making v1 the default. I think there was always the notion of supporting
what v1 currently offers by making a config change. Thus, Horizon should
still have all the support it had in Icehouse. I am a little worried
Hey LBaaS folks,
This is you friendly reminder to provide any agenda items for tomorrow's weekly
IRC meeting. The agenda currently has these items:
* Review Updates
* Octavia Work
Cheers,
--Jorge
P.S. Please don't forget to update the weekly standup ==
Hey LBaaS folks,
This is you friendly reminder to provide any agenda items for tomorrow's weekly
IRC meeting. Please add them to the agenda wiki ==
https://wiki.openstack.org/wiki/Network/LBaaS#Agenda. The agenda currently has
these items:
* Review Updates
Cheers,
--Jorge
P.S. Also,
Answers inlined. Thanks for the questions! They forced me to think about
certain features.
Cheers,
--Jorge
From: Samuel Bercovici samu...@radware.commailto:samu...@radware.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
Hi Kevin,
We are trying to prioritize features based on actual data utilization. If you
have some, by all means please add it to
https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc#gid=0.
One reason we are focusing on HTTP(S) and not FTP is that 0.27% of
Hi all,
In order to ease confusion I think I might create use case walk-throughs to
show how the API would work. There's only been one week to work on this (minus
other work) so I haven't had enough time to create them. I'll try to capture
most of them in this form over the following week as I
+1 for German's use cases. We need SSL re-encryption for decisions the
load balancer needs to make at the l7 layer as well. Thanks Clint, for
your thorough explanation from a security standpoint.
Cheers,
--Jorge
On 4/18/14 1:38 PM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Stephen
Hey everyone,
I agree that we need to be preparing for the summit. Using Google docs
mixed with Openstack wiki works for me right now. I need to become more
familiar the gerrit process and I agree with Samuel that it is not
conducive to large design discussions. That being said I'd like to add
my
Oops! Everywhere I said Samuel I meant Stephen. Sorry you both have SB as
you initials so I got confused. :)
Cheers,
--Jorge
On 4/30/14 5:17 PM, Jorge Miramontes jorge.miramon...@rackspace.com
wrote:
Hey everyone,
I agree that we need to be preparing for the summit. Using Google docs
mixed
I agree it may be odd, but is that a strong argument? To me, following RESTful
style/constructs is the main thing to consider. If people can specify
everything in the parent resource then let them (i.e. single call). If they
want to specify at a more granular level then let them do that too
Hey Eugene,
I think there is a misunderstanding on what iterative development means to you
and me and I want to make sure we are on the same page. First of all, I'll try
not to use the term duct-taping even though it's a widely used term in the
industry. My main concern is that implementing
That sounds good to me. The only thing I would caution is that we have
prioritized certain requirements (like HA and SSL Termination) and I want to
ensure we use the survey to compliment what we have already mutually agreed
upon. Thanks for spearheading this!
Cheers,
--Jorge
From: Samuel
, 2014 3:10 PM
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] Thoughts on current process
Hi,
On Thu, May 1, 2014 at 10:46 PM, Jorge Miramontes
jorge.miramon
Sam,
I'm assuming you want one person from each company to answer correct? I'm
pretty sure people in each organization will vote the same…at least I'd hope!
Cheers,
--Jorge
From: Samuel Bercovici samu...@radware.commailto:samu...@radware.com
Reply-To: OpenStack Development Mailing List (not
1:52 PM, Jay Pipes jaypi...@gmail.com wrote:
On 05/06/2014 02:42 PM, Jorge Miramontes wrote:
Sam,
I'm assuming you want one person from each company to answer correct?
I'm pretty sure people in each organization will vote the sameŠat least
I'd hope!
I'd hope not! :)
Even within the same
Okay, makes sense to gather all data now and interpret this later. I'm too
jaded for these types of debates right now since the summit is around the
corner.
Cheers,
--Jorge
On 5/6/14 3:32 PM, Jay Pipes jaypi...@gmail.com wrote:
On 05/06/2014 04:22 PM, Stephen Balukoff wrote:
I think the
All of our relevant material is in this Google Drive folder ==
https://drive.google.com/#folders/0B_x8_4x6DRLad1NZMjgyVFhqakU
Cheers,
--Jorge
On 5/7/14 1:19 PM, Kyle Mestery mest...@noironetworks.com wrote:
Lets go over the Rackspace portion of the API comparison tomorrow
then, and we can
Hey Stephen,
What we really care about are the following:
- Inbound bandwidth (bytes)
- Outbound bandwidth (bytes)
- Instance Uptime (requires create/delete events)
Just to note our current LBaaS implementation at Rackspace keeps track of
when features are enabled/disabled. For example, we have
Hey everyone,
Per our IRC discussion yesterday I'd like to continue the discussion on
how Barbican and Neutron LBaaS will interact. There are currently two
ideas in play and both will work. If you have another idea please free to
add it so that we may evaluate all the options relative to each
Neutron LBaaS
Integration Ideas
+1 for option 2.
In addition as an additional safeguard, the LBaaS service could check
with Barbican when failing to use an existing secret to see if the secret
has changed (lazy detection).
Youcef
-Original Message-
From: Jorge Miramontes
have both. User's who
like #2 juts hit the flag. Then the discussion changes to what we should
implement first and I agree with Jorge + John that this should likely be
#2.
German
-Original Message-
From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com]
Sent: Friday, June 06, 2014 3
Hey Octavia folks!
First off, yes, I'm still alive and kicking. :)
I,d like to start a conversation on usage requirements and have a few
suggestions. I advocate that, since we will be using TCP and HTTP/HTTPS
based protocols, we inherently enable connection logging for load
balancers for
:03 PM, Jorge Miramontes
jorge.miramon...@rackspace.commailto:jorge.miramon...@rackspace.com wrote:
Hey Octavia folks!
First off, yes, I'm still alive and kicking. :)
I,d like to start a conversation on usage requirements and have a few
suggestions. I advocate that, since we will be using TCP
coming from logging. Some operators
might choose to
hook up very cheap and non performing disks which might not be able to
deal with the log traffic. So I would suggest that there is some rate
limiting on the log output to help with that.
Thanks,
German
From: Jorge Miramontes [mailto:jorge.miramon
and non performing disks which
might not be able to deal with the log traffic. So I would suggest that
there is some rate limiting on the log output to help with that.
Thanks,
German
From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com]
Sent: Wednesday, October 22, 2014 6:51 AM
Thanks for the reply Angus,
DDoS attacks are definitely a concern we are trying to address here. My
assumptions are based on a solution that is engineered for this type of
thing. Are you more concerned with network I/O during a DoS attack or
storing the logs? Under the idea I had, I wanted to
would be happy to just move them on demand to a
place the user can access.
Thanks,
German
From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com]
Sent: Tuesday, November 04, 2014 8:20 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron
The example you put implicitly assigns the status tree to a load balancer.
Is sharing only allowed for sub resources? Or can sub resources be shared
across multiple load balancers? If that is the case then I suspect that
statuses may be exposed in many different places correct?
Cheers,
--Jorge
I want to be friends with Phil :(. Congrats!
Cheers,
--Jorge
On 4/21/15, 11:57 AM, Brandon Logan brandon.lo...@rackspace.com wrote:
Welcome Phil!
From: Doug Wiegley doug...@parksidesoftware.com
Sent: Tuesday, April 21, 2015 11:54 AM
To: OpenStack
Good stuff. Thanks everyone for your hard work on getting Octavia to this point!
Cheers,
--Jorge
From: Brandon Logan
brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
52 matches
Mail list logo
