Hi Stephen,
Some comments on comments on comments:
On Fri, May 9, 2014 at 10:25 PM, Stephen Balukoff sbaluk...@bluebox.netwrote:
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
Hi Eugene,
A couple notes of clarification:
On Sat, May 10, 2014 at 2:30 AM, Eugene Nikanorov
enikano...@mirantis.comwrote:
On Fri, May 9, 2014 at 10:25 PM, Stephen Balukoff
sbaluk...@bluebox.netwrote:
Hi Eugene,
This assumes that 'VIP' is an entity that can contain both an IPv4
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 proposal review
thoughts
Hi Eugene,
This assumes that 'VIP' is an entity that can contain
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 that's
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
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
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
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 the
On May 9, 2014, at 3:26 AM, Eugene Nikanorov
enikano...@mirantis.commailto: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
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
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
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),
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 approach.
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 -- we
On May 8, 2014, at 8:01 AM, Eugene Nikanorov
enikano...@mirantis.commailto: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
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 we
On May 8, 2014, at 2:45 PM, Eugene Nikanorov
enikano...@mirantis.commailto: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
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.
18 matches
Mail list logo
