Hi Stephen,
Well, sure, except the user is going to want to know what the IP
> address(es) are for obvious reasons, and expect them to be taken from
> subnet(s) the user specifies. Asking the user to provide a Neutron
> network_id (ie. where we'll attach the L2 interface) isn't definitive here
> b
On 05/09/2014 04:37 PM, Samuel Bercovici wrote:
It boils down to two aspects:
1.How common is it for tenant to care about affinity or have more than a
single VIP used in a way that adding an additional (mandatory) construct
makes sense for them to handle?
For example if 99% of users do not care
On Sat, 2014-05-10 at 09:50 -0700, Stephen Balukoff wrote:
>
> Correct me if I'm wrong, but wasn't "the existing API is confusing and
> difficult to use" one of the major complaints with it (as voiced in
> the IRC meeting, say on April 10th in IRC, starting around... I
> dunno... 14:13 GMT)? If
ses?
>
>
>
> Regards,
>
> -Sam.
>
>
>
>
>
>
>
> From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
> Sent: Friday, May 09, 2014 9:26 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [ope
Hi Eugene,
A couple notes of clarification:
On Sat, May 10, 2014 at 2:30 AM, Eugene Nikanorov
wrote:
>
> On Fri, May 9, 2014 at 10:25 PM, Stephen Balukoff
> wrote:
>
>> Hi Eugene,
>>
>> This assumes that 'VIP' is an entity that can contain both an IPv4
>> address and an IPv6 address. This is ho
Hi Stephen,
Some comments on comments on comments:
On Fri, May 9, 2014 at 10:25 PM, Stephen Balukoff wrote:
> Hi Eugene,
>
> This assumes that 'VIP' is an entity that can contain both an IPv4 address
> and an IPv6 address. This is how it is in the API proposal and
> corresponding object model th
v@lists.openstack.org>>
Date: Friday, May 9, 2014 3:37 PM
To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS] API proposal review thoughts
It boils down to two aspects:
ustify why they need multiple vips and ports. Thats a completely disconnected
discussion.
Regards,
-Sam.
From: Stephen Balukoff [mailto:sbaluk...@bluebox.net<http://bluebox.net>]
Sent: Friday, May 09, 2014 9:26 PM
To: OpenStack Development Mailing List (not for usage que
to assist to understand how common are
those use cases?
Regards,
-Sam.
From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Friday, May 09, 2014 9:26 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] API
Hi Eugene,
This assumes that 'VIP' is an entity that can contain both an IPv4 address
and an IPv6 address. This is how it is in the API proposal and
corresponding object model that I suggested, but it is a slight
re-definition of the term "virtual IP" as it's used in the rest of the
industry. (And
On May 9, 2014, at 3:26 AM, Eugene Nikanorov
mailto:enikano...@mirantis.com>>
wrote:
Carlos,
The general objection is that if we don't need multiple VIPs (different ip, not
just tcp ports) per single logical loadbalancer, then we don't need
loadbalancer because everything else is addressed b
Hi Brandon
Let me know if I am misunderstanding this,and please explain it
> further.
> A single neutron port can have many fixed ips on many subnets. Since
> this is the case you're saying that there is no need for the API to
> define multiple VIPs since a single neutron port can represent all
Carlos,
The general objection is that if we don't need multiple VIPs (different ip,
not just tcp ports) per single logical loadbalancer, then we don't need
loadbalancer because everything else is addressed by VIP playing a role of
loadbalancer.
Regarding conclusions - I think we've heard enough ne
On May 8, 2014, at 2:45 PM, Eugene Nikanorov
mailto:enikano...@mirantis.com>> wrote:
Hi Carlos,
Are you saying that we should only have a loadbalancer resource only in the
case where we want it to span multiple L2 networks as if it were a router? I
don't see how you arrived at that conclu
Hi Carlos,
Are you saying that we should only have a loadbalancer resource only in
> the case where we want it to span multiple L2 networks as if it were a
> router? I don't see how you arrived at that conclusion. Can you explain
> further.
>
No, I mean that loadbalancer instance is needed if
Hi Eugene,
Comments in-line.
On Thu, 2014-05-08 at 17:01 +0400, Eugene Nikanorov wrote:
> Hi Adam,
>
>
> My comments inline:
> 1. We shouldn't be looking at the current model and deciding
> which object is the root object, or what object to rename as a
> "loadbalancer"...
On May 8, 2014, at 8:01 AM, Eugene Nikanorov
mailto:enikano...@mirantis.com>>
wrote:
Hi Adam,
My comments inline:
1. We shouldn't be looking at the current model and deciding which object is
the root object, or what object to rename as a "loadbalancer"... That's
totally backwards! *We don'
Hi Adam,
My comments inline:
> 1. We shouldn't be looking at the current model and deciding which object
> is the root object, or what object to rename as a "loadbalancer"... That's
> totally backwards! *We don't define which object is named the
> "loadbalancer" by looking for the root object --
Hi Stephen,
A couple of inline comments:
>-
> BBG proposal just has attributes for both and IPv4 address and an
> IPv6 address in its "VIP" object. (Meaning it's slightly different than
> a
> "VIP" as people are likely to assume what that term means.)
>
> This is a correct
Just a couple of quick comments since it is super late here and I don't want to
reply to the entire email just yet...
Firstly, I think most of us at Rackspace like the way your proposal handles L7
(hopefully my team actually agrees and I am not speaking out of turn, but I
definitely like it), s
Howdy y'all!
Per the e-mail I sent out earlier today, I wanted to share some thoughts on
the API proposals from Rackspace and Blue Box that we're currently working
on evaluating, presumably to decide which will be the version will be the
"starting point" from which we make revisions going forward.
21 matches
Mail list logo
