Good stuff. Thanks everyone for your hard work on getting Octavia to this point!
Cheers,
--Jorge
From: Brandon Logan
mailto:brandon.lo...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, May 1, 2015
I want to be friends with Phil :(. Congrats!
Cheers,
--Jorge
On 4/21/15, 11:57 AM, "Brandon Logan" wrote:
>Welcome Phil!
>
>From: Doug Wiegley
>Sent: Tuesday, April 21, 2015 11:54 AM
>To: OpenStack Development Mailing List (not for usage questions)
>S
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
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][LBaaS][Octavia] Usage Requiremen
ded like we were
in disagreement on the IRC. I am not sure why but it sounded like you were
talking about something else when you were talking about the real time
processing. If we are just taking about moving the logs to your Hadoop cluster
or any backedn a scalable way we agree.
Susanne
O
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 make
d privacy issue. What are your thoughts on
>logging those?
>
>Thanks,
>German
>
>-Original Message-
>From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com]
>Sent: Thursday, October 23, 2014 3:30 PM
>To: OpenStack Development Mailing List (not for usage questions)
dle the IO 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
en connections' or something.)
One other thing: If there's a chance we'll be storing logs on the amphorae
themselves, then we need to have log rotation as part of the configuration
here. It would be silly to have an amphora failure just because its ephemeral
disk fills up, eh.
St
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 several
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) T
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
O
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 ch
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, ple
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 ==>
https://etherpad.openstack.org/
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 two items:
* Review Updates
* TLS work division
Cheers,
--Jorge
P.S. Please don't forget to update the weekly standup ==>
https://etherpad.openstack.o
Hey Kyle,
I've viewed that link many times but it mentions nothing about 7-20 being
Spec approval deadline. Am I missing something?
Cheers,
--Jorge
On 7/18/14 9:52 PM, "Kyle Mestery" wrote:
>On Fri, Jul 18, 2014 at 4:40 PM, Jorge Miramontes
> wrote:
>> Hey Kyl
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 tha
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 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/ but can still
rivers
> "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
mailto
+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 the
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
av
I agree.
Also, since we are planning on having two different API versions run in
parallel the only driver that needs to be worked on initially is the reference
implementation. I'm guessing we will have two reference implementations, one
for v1 and one for v2. The v2 implementation currently see
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,
--Jor
Hey LBaaS folks,
This is your friendly reminder to update the weekly standup etherpad so that
everyone is aware of what everyone is working on. Here is the link ==>
https://etherpad.openstack.org/p/neutron-lbaas-weekly-standup. Thanks!
Cheers,
--Jorge
__
istics 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][LBaaS] Consolidated metrics proposal
Hey Andres,
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 pro
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
telling him things changed (and we helpfully updated all affected
>load balancers) -- which isn't as immediate as #2.
>
>If we implement an "auto-update flag" for #1 we can have both. User's who
>like #2 juts hit the flag. Then the discussion changes to what we should
ling List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican 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
A couple of questions have come to mind since reading this thread:
1) We are assuming that load balancers can only operate on one update at a
time correct? I.E. We are not allowing multiple updates to occur
concurrently? Whatever the case on this I advocate that we do NOT allow
concurrent modifica
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 othe
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 hav
Sam, our larger customers especially care about affinity since they have many
load balancer instances. Their use case usually centers around being
re-sellers. Also, if you have a deployment that utilizes several load balancers
our customers have created tickets to ensure they are on different ho
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" wrote:
>Lets go over the Rackspace portion of the API comparison tomorrow
>then, and we can cover Stephen's on the
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" wrote:
>On 05/06/2014 04:22 PM, Stephen Balukoff wrote:
>> I think the plan is to releas
e
On 5/6/14 1:52 PM, "Jay Pipes" 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
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 mailto:samu...@radware.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions
ck Development Mailing List (not for usage questions)"
mailto: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
mailto:jorge.miramon...@rackspace.com>> wrote:
Hey
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 Berco
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 c
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 (i.e
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"
wrote:
>Hey everyone,
>
>I agree that we need to be preparing for the summit. Using Google docs
>mix
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
m
+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" wrote:
>Excerpts from Stephen Balukoff's messa
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
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 our
Answers inlined. Thanks for the questions! They forced me to think about
certain features.
Cheers,
--Jorge
From: Samuel Bercovici mailto:samu...@radware.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, Apr
Thanks Eugene,
I added our data onto the requirements page since I was hoping to prioritize
requirements based on the operator data that gets provided. We can move it over
to the other page if you think that makes sense. See everyone on the weekly
meeting tomorrow!
Cheers,
--Jorge
From: Susan
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 to
Thanks Itsuro,
Good requirement since Neutron LBaaS is an asynchronous API.
Cheers,
--Jorge
On 3/24/14 7:27 PM, "Itsuro ODA" wrote:
>Hi LBaaS developpers,
>
>I added 'Status Indication' to requirement Wiki.
>It may be independent from object model discussion
>but I think this is an item whi
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 po
eature.
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
[mailto:jorge.mi
ther! 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
mailto:jorge.miramon...@rackspace.com>> wrote:
Hey Neutron LBaaS folks,
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.
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 that
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 pe
59 matches
Mail list logo
