ers.
> >Regards Susanne
> >
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-43
utron LBaaS. Susanne
>
>
> On Mon, Aug 11, 2014 at 5:44 PM, Stephen Balukoff
> wrote:
>
>> Susanne,
>>
>> Are you asking in the context of Load Balancer services in general, or in
>> terms of the Neutron LBaaS project or the Octavia project?
>>
>>
the
webex we're presently using for these meetings.
Thanks,
Stephen
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
or something similar. Would only
> eixst on loadbalancer entity if loadbalancer is the only top level object.
> >
> > Thanks,
> > Brandon
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.or
Hi Brandon,
Responses in-line:
On Fri, Aug 15, 2014 at 9:43 PM, Brandon Logan
wrote:
> Comments in-line
>
> On Fri, 2014-08-15 at 17:18 -0700, Stephen Balukoff wrote:
> > Hi folks,
> >
> >
> > I'm OK with going with no shareable child entities (List
ck-dev@lists.openstack.org
> > Subject: Re: [openstack-dev] [Octavia] Object Model and DB Structure
> >
> > Oh hello again!
> >
> > You know the drill!
> >
> > On Sat, 2014-08-16 at 11:42 -0700, Stephen Balukoff wrote:
> > > Hi Brandon,
>
’t share anything except the VIP J So my motivation
> is if we can have two listeners share the same VIP. Hope that makes sense.
>
>
>
> German
>
>
>
> *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net]
> *Sent:* Monday, August 18, 2014 1:39 PM
> *To:* OpenStack
uld accommodate that.
>
>
> German
>
>
>
> *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net]
> *Sent:* Monday, August 18, 2014 2:43 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Octavia] Object Mo
eting is still in IRC every thursday at
> >14:00 UTC. I've just been pushing for IRC because I hate phone/video
> >conferences with many people. The reasons you outlined are definitely
> >the main reasons to do it, I'm just being selfish with my own reason.
> >The plan
I've put the agenda for tomorrow's Octavia meeting on the wiki:
https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Agenda
Please feel free to edit it there and/or respond to this e-mail with
additional items if you would rather not edit the wiki.
Thanks,
Stephen
--
Stephe
without affecting any of the other listeners on the Octavia VM.
Again, this is not possible if all listeners are serviced by one process.
iii. If desired, an Operator can easily alter global logging configuration
(alter log file location, increase verbosity, etc.) for a single listener
(or all
n denominator.
Please use the voting system that Doug set up above if you with your vote
to be counted on this matter. (I would love to see newcomers showing up in
our IRC channel or responding to the various mailing list discussions we
have or will have going shortly, eh!
ngle Octavia
VM (perhaps at a lower price tier to the user). This is also similar to how
actual load balancing hardware appliance vendors tend to operate. The
restrction of 1 loadbalancer per Octavia VM does limit the operator's
options, eh.
Stephen
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
want to distance ourselves from Neutron to some extent. We will
> formalize this via a
> networking driver in Octavia. Note: we do not want to burn any
> bridges here, so we want to
> be appropriate in our spin-out process.
>
>
>
>
> Sorry for the delay in se
0 UTC in #openstack-lbaas on the usual (Freenode)
IRC network.
Thanks,
Stephen
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/lis
s-project issues, address key specific topics which need
>> face-to-face time and broader attendance, then try to replicate the
>> success of midcycle meetup-like open unscheduled time to discuss
>> whatever is hot at this point.
>>
>> There are still de
can have
> > something definitive on that soon.
> >
> > Thanks,
> > Brandon
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> >
&g
standalone stackforge project we are assuming that
> it would be looked favorable on when time is to move it into incubated
> status.
>
> Susanne
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.
tisfy one of the requirements around Neutron incubation
> graduation: Having a functional driver. And it also allows for the
> driver to continue to live on next to the API.
>
> What do people think about this?
>
> Thanks,
> Kyle
>
&g
other people working on the
project are engaged in from week to week (modeled after the Neutron LBaaS
weekly standup put together by Jorge). If you've been working on Octavia,
please update this following the template here:
https://etherpad.openstack.org/p/octavia-weekly-standup
Stephen
-
an image that doesn't support it. Lots of options,
all of which can be intelligently handled within the driver / controller.
Thoughts?
Stephen
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
the role of
the controller to essentially be a driver (presumably having to duplicate
all the common "controller" elements between these "effectively drivers"
thingies)... which seems silly to me. The step to implementation-specific
ob
default action to be taken upon a
failure to push out a new config to be to check the version of the amphora
and upgrade as necessary (ie. lazy upgrading)...
Also, not that we can't revisit this of course: But the v0.5 component
design entailing a "VM Driver" already went through gerrit review and was
approved (by yourself even!) This discussion was originally about where to
render the haproxy configs, but it really seems like y'all are against the
idea of having an amphora driver interface at all. :/
Stephen
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
nvey an idea
thoroughly or correctly, and lack of ability to grasp all the subtleties of
someone else's idea, especially if there's confusion on terminology. Heck,
in this thread alone I know I've misunderstood several of your points
several times (and *mostly* on accident. ;) But I think the communication
we've been having on this has been good and I think we're all understanding
each other's concerns and aligning our efforts better by doing so, eh!
In any case, I don't want anyone to feel like we can't revisit decisions
made in the past if new knowledge, ideas, or a better understanding
warrants it, eh. We just need to make sure we keep moving *mostly* forward,
eh. :)
Stephen
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
be walking a fine line between
> flexibility and complexity. We just need to define how far over that
> line and in which direction we are willing to go.
>
> Thanks,
> Brandon
> _______
> OpenStack-dev mailing
; Please review the current work in progress and comment is something is
> missing there.
>
> The logical load balancer API which is already addressed:
>
> · Multiple pools per VIP (ie. “layer 7” support) -
> https://blueprints.launchpad.net/neutron/+spec/lbaas-l7-rules.
, and don't really have plans to create drivers for any particular
proprietary load balancer. (The only driver I plan on working on is for the
software appliance model I already discussed-- and this is based on haproxy
already.) I guess I only bring this up so that it's clear to everyone
wor
ugene Nikanorov
wrote:
> Hi folks,
>
> Lets gather as usual on #openstack-meeting on Thursday, 13 at 14-00 UTC
> The updated agenda for our regular meeting is here:
> https://wiki.openstack.org/wiki/Network/LBaaS
>
> In addition to that I'd like to discuss some ideas that St
(plus other attributes that make sense for a
TCP service). This feels like Neutron LBaaS is trying to redefine what a
"virtual IP" is, and is in any case going to be confusing for new comers
expecting it to be one thing when it's actually another.
Thanks,
Stephen
On Tue, Feb 11, 2014 at 7:12 AM, Eugene Nikanorov
wrote:
>
> The proposed model is described here, although without a picture:
> https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance
>
> autoscaling is something that gen
le in an active-standby
> > cluster_model by
> **
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ated by haproxy is not a floating ip,
> but an ip on the internal tenant network with a neutron port. So ip
> uniqueness is enforced at port level and not at VIP level. We need to allow
> VIPs to share the port, that is a part of multiple-vips-per-pool blueprint.
>
> Thanks,
> Eugene.
t the API should not remove this as a choice.
>
+1
>
>
> -Sam.
>
>
>
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
te*: With REG_EXP we can cover the rest of the values.
>
>
>
> In general In the L7rule one can express the following (Example):
>
> “check if in the value of header named ‘Jack’ starts with X” – if this is
> true – this rule “returns” true
>
>
>
>
>
> Thanks
Oh! One thing I forgot to mention below:
On Sat, Feb 15, 2014 at 11:55 PM, Avishay Balderman wrote:
>
> Entity: L7Rule
>
> Field : compare_type
>
> Description: The way we compare the value against a given value
>
> Possible values: REG_EXP, EQ, GT, LT,EQ_IGNORE_CASE,(?)
>
> *Note*: With REG_E
t automation if we ever add the ability for a
single pool to be shared across load balancer (clusters).
>
>
>>- I general, I prefer DRY code, so if we can avoid adding the
>> loadbalancer_id attribute to existing resources except for where it's
>>really needed, that's what I'd recommend. (D
g meaningful healthmonitors, members and
> statistics API we will need to create associations for everything, or just
> change API in backward incompatible way.
>
> My opinion is that it make sense to limit such ability (reusing pools by
> vips deployed on different backends) in favor of simpler code, IMO it's
> really a big deal. Pool is lightweight enough to not to share it as an
> object.
>
Agreed-- not having re-usable pools just means the tenant needs to do more
housekeeping in a larger environment.
Honestly... even among our largest clients, we rarely see them re-using
pools, or having pools associated with multiple listeners. So, this might
be a moot point for the 90% use case anyway.
Thanks,
Stephen
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
P<->ssl_certificate associations are created or modified.
In the screen associating certificates with a given VIP, we need to provide
a field (checkbox?) for the user to specify which one of them is the
default.
Thanks,
Stephen
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
d API, and that
>> > is what we would like to avoid at this point.
>> >
>> >
>> > So the proposal makes step #10 forbidden: pool is already associated
>> > with the listener on other backend, so we don't share it with
>> > listeners on another one.
>> > That
on?
I tend to think that if we acknowledge the need for an admin API, as well
as some of the core features it's going to need, and contrast this with the
user API (which I think is mostly what Jay and Mark McClain are rightly
concerned about), it'll start to become obvious which feat
te:
>
> On Feb 25, 2014, at 10:10 AM, Stephen Balukoff
> wrote:
>
>On Feb 25, 2014 at 3:39 AM, enikano...@mirantis.com wrote:
>
>> Agree, however actual hardware is beyond logical LBaaS API but could
>> be a part of admin LBaaS API.
>>
>
>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to : openst...@lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>>
>
> _______
> Mailing list:
> http://lists
rise cloud. It will
> > require a lot of work to achieve these goals, and I believe it should
> > be something that is a goal.
>
> I don't think you'll get any disagreement from anyone on that :)
> Although there has certainly been a fragmentation of effort on the LBaaS
> fro
ermine how packets get routed to each device (and this can break
stateful protocols like TCP if you're not careful)-- but again, this would
be "routed mode" load balancing, which I understand is not yet feasible
with Neutron LBaaS, correct?
Stephen
--
Stephen Balukoff
Blue Box Grou
ot; to the concrete LB objects.
> You may want to revisit
> https://docs.google.com/document/d/1D-1n8nCEFurYzvEBxIRfXfffnImcIPwWSctAG-NXonY/edit#heading=h.3rvy5drl5b5r
> the "Logical Model + Provisioning Status + Operation Status + Statistics"
> for a somewhat more detailed explanation albeit it uses the LBaaS
to have all
> objects besides LB be treated as logical.
>
> 2. The 3rd use case bellow will not be reasonable without pool
> sharing between different policies. Specifying different pools which are
> the same for each policy make it non-started to me.
>
>
>
> -Sam.
employees a half day off on this day
... we are cancelling Wednesday's Octavia meeting. See y'all again on Dec.
3rd at 20:00 UTC in #openstack-meeting-alt (and keep working on those
gerrit reviews!)
Thanks,
Stephen
--
Stephen Balukoff
Blue Box Group, LLC
(800)613
Sam, correct me if I am wrong.
> >
> > I generally like this idea. I do have a few reservations with this:
> >
> > 1) Creating and updating a load balancer requires a full tree
> configuration with the current extension/plugin logic in neutron. Since
> updates will r
wrote:
> Hi Brandon + Stephen,
>
>
>
> Having all those permutations (and potentially testing them) made us lean
> against the sharing case in the first place. It’s just a lot of extra work
> for only a small number of our customers.
>
>
>
> German
>
>
On Sun, Dec 7, 2014 at 11:43 PM, Samuel Bercovici
wrote:
> +1
>
>
>
>
>
> *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net]
> *Sent:* Friday, December 05, 2014 7:59 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [o
d L2VPN EVPN
> >> Overlay (https://tools.ietf.org/html/draft-sd-l2vpn-evpn-overlay-03)
> to the
> >> Ryu BGP speaker will allow the hypervisor side Ryu application to
> advertise
> >> up to the FLIP system reachability information to take into account VM
> >> failover
t; Interesting to know what is “ACTIVE-ACTIVE topology of load balancing VMs”.
>
> What is the scenario is it Service-VM (of NFV) or Tennant VM ?
>
> Curious to know the background of this thoughts .
>
>
>
> keshava
>
>
>
>
>
> *From:* Stephen Balukoff [mailto:s
etings would be held), but I was assured by
the usual participants in these meetings that I would probably be the only
one attending them. As such, the next Octavia meeting we'll be holding will
happen on January 7th.
In the mean time, let's bang out some code and get it reviewed!
Th
gt;Libra completely at one point. So that one is mainly my 2c :)
>
Most people on the project are pretty new to pecan and WSME, though we
understand that OpenStack in general is moving in this direction, hence our
willingness to give it a try. It's en
juncture.
>
> I now have some feedback for my team, thanks again.
>
> Kind Regards
> --
> Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/
>
>
>
>
> _______
> OpenStack-dev mailing list
>
n which the end
> user IP might change. The project-user wishes to represent them to the
> application users as a web application available via a single IP.
>
> -Trevor Vardeman
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@li
icult if we're not starting to think about how we're going to
address operator concerns (like, say, HA) and how these potentially
intersect and/or interface with user concerns.
> 4. Work with https://review.openstack.org/#/c/89903/ to define proper
> attribute placement of existing
separate entities?
> >
> > It's not hard at all. Explaining obvious things and getting consensus
> > is hard.
> >
> >> My proposal is a design discussion.
> >
> > My opinion is that design discussion alone can be split by features.
> > My opinion is
OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal
>
> On Mon, Apr 28, 2014 at 6:23 PM, Stephen Balukoff
> wrote:
> > Hi guys,
> >
> > Sorry for all the drama on the list lately.
>
tack.org/wiki/Neutron/GroupPolicy - If I understand
> correctly, this API has a complex object model while the API adheres to the
> way other neutron APIs are done (ex: flat model, granular api, etc.)
>
>
>
> How critical is it to preserve a co
sal give workflows on how their API will operate. This is isn't
> >necessary but I think it will definitely give structure in any discussions
> >we have when comparing. If others have thoughts on how to compare the
> >proposals on equal footing then by
Jorge,
In looking over your API proposal linked above, have things significantly
changed there since you sent it out two weeks ago? (And if so, which parts
should I take a look at again?)
Thanks,
Stephen
On Wed, Apr 30, 2014 at 5:07 PM, Stephen Balukoff wrote:
> Hi Jorge!
>
&
know if this is acceptable.
>
>
>
> Regards,
>
> -Sam.
>
>
>
>
>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/open
them, too. They are essential and I would
> like to make sure they are considered first-class citizen when it comes to
> use cases.
>
>
>
> Thanks,
>
> German
>
>
>
> *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net]
> *Sent:* Thursday, May 01, 2014 12:52 PM
d together, then order no longer matters. If
we want to define a more feature-rich DSL here, then rule order would
matter. (Note that the order in which entire L7Policies appear still
matters. The first one to match wins in the case of a 'redirect' match, eh.)
>
>
> Regards,
>
> -Avishay, Evgeny and Sam
>
>
>
>
>
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
n users as a web application available via a single IP.
>
>
>
> -Trevor Vardeman
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
e confused. This same
> type of clarity would be very helpful across many of the other
> VPN-related use-cases. Thanks again!
>
> -Trevor
> _______
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/open
site overload situations.
>
> Please feel free to correct me anywhere I've blundered here, and if my
> proposed "solution" is inaccurate or not easily understood, I'd be more
> than happy to explain in further detail. Thanks for any help you can
> offer!
>
> -Trevor Vardem
ot;
> Anything specific implementation details I've mentioned are intended be
> taken as one possible example, not as a well thought out proposal. I am, as
> one might say, "speaking my mind". My hope is that some of this will simmer
> on the general subconscious. I'd like to hear what the general consensus is
> on these topics, because these are some of the assumptions I've been
> operating under during the rest of our discussions, and if they're invalid,
> I may need to rebase my view on the API discussion as a whole.
>
> Thanks ya'll, I'm looking forward to getting some additional viewpoints!
> --Adam Harwell (rm_work)
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
for 'redirect' policies-- the implication being no order applies
to block or content modification policies because they always get processed
first.
We could do this by splitting modification, block, and switching L7 policy
types into their own separate objects (all of which would h
the same subnet.
>>
>> Any member outside the specified subnets is supposedly accessible via
>> routing.
>>
>> It might be an option to state the static route to use to access such
>> member(s).
>> On many cases the needed static routes could also be comp
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Use-Cases with VPNs
> Distinction
>
>
>
> Sounds about right to me. I guess I agree with your agreement. :)
>
> Does anyone actually *oppose*
>
>
> I plan to look deeper into L7 content modification later this week to
> propose a list of capabilities.
>
>
>
> -Sam.
>
>
>
>
>
> *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net]
> *Sent:* Saturday, May 03, 2014 1:33 AM
>
> *To
I think this is too strange an edge case to be covered by the LBaaS. In
> any case I am wondering if there is a valid use case if we can add it to
> the user stories.
>
>
>
> German
>
>
>
> *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net]
> *Sent:* Monday, May 05,
nd offer their own insights.
> >>
> >>Best,
> >>-jay
> >>
> >>___
> >>OpenStack-dev mailing list
> >>OpenStack-dev@lists.openstack.org
> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
em from the last meeting.
>
> Thanks,
> Eugene.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
blish
> the survey link to ML ASAP after that.
>
>
>
> Please let me know if this is acceptable.
>
>
>
> Regards,
>
> -Sam.
>
>
>
>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> 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 ML when it's complete.
> >
> >On Wed, May 7, 2014 at 4:55 AM, Stephen Balukoff
&
ugh it would be
silly, it would still be perfectly functional. :P )
Having said all this, we already know the API is going to support
manipulation of individual objects as a way to provision services. If the
people advocating for making the "VIP" the root of the object tree don't
actually intend to use single-call for manipulating their objects, what do
we care if those who are going to use single-call would rather do this
through the "listener / load balancer" object?
And... that's about it. Sorry for the length of this e-mail, y'all!
Thanks,
Stephen
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807i
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I to
>> define multiple VIPs since a single neutron port can represent all the
>> IPs that all the VIPs require?
>>
> Right, if you want to to have both ipv4 and ipv6 addresses on the VIP then
> it's possible with single neutron port.
> So multiple VIPs for this ca
nStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/o
ey
>
>
>
> Hi everyone,
>
>
>
> I think that it is a good feedback to prioritize features.
>
> I can publish the results in time for the 2nd LBaaS meeting (so deadline
> would be end of 15th May “summit time”)
>
> Is this acceptable?
>
>
>
> -Sam.
eners. So, to be more
accurate, it's really about:
loadbalancer/VIPs/Listeners or VIPs/Listeners.
To me, that says it's all about: Does the loadbalancer object add something
meaningful to this model? And I think the answer is:
* To smaller users with very basic load balancing needs: No
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
; channel? #openstack-lbaas? Just thinking that a dedicated channel might
>> help to make the weekly meetings more productive with less crosstalk.
>> Thoughts?
>>
>> Best,
>> Craig
>>
>> ___
>> OpenStack-dev
...X-Forwarded-For, httpclose, etc.
>
> Best,
> Craig
>
>
> On Wed, May 14, 2014 at 1:32 PM, Stephen Balukoff
> wrote:
>
>> Aah-- and here's a small error correction. :)
>>
>> Please also note:
>> * We're not yet in consensus on the L7 or SSL rel
hat happen would
be appreciated!)
Thanks,
Stephen
On Mon, May 19, 2014 at 4:45 PM, Stephen Balukoff wrote:
> Hi folks,
>
> Ok, I've attached a newly-updated object diagram (and its source) which is
> hopefully both a little bit clearer than the monstrosity I created for the
> s
ficate signing request via our API someday for certain
organizations' security requirements, one should never have the only store
for this private key be a single virtual server. This is also going to be
important if a certificate + key combination gets re-used in another
listener in some way, or
x27;t need to have a single
appliance serving both types of addresses for the listener, but there's
certainly a chance (albeit small) to hit an async scenario if they're not.
Vijay: I think the plan here was to come up with an use an entirely
different DB schema than the legacy Neutron
late? What other data are your users asking for or
accustomed to seeing?
Thanks,
Stephen
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ailman/listinfo/openstack-dev
>> <https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=DYApm8uTUC2lxp%2B0qmdN9UhsdAxGdWaIHf5dr1N1tJE%3D%0A&s=ec3a8e21156d1b946db652fac0dab2e2268340aea37bd8c30adbf52fe2f3e8de>
>> >
>> >
>> > ___
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> <https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=DYApm8uTUC2lxp%2B0qmdN9UhsdAxGdWaIHf5dr1N1tJE%3D%0A&s=ec3a8e21156d1b946db652fac0dab2e2268340aea37bd8c30adbf52fe2f3e8de>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> <https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=DYApm8uTUC2lxp%2B0qmdN9UhsdAxGdWaIHf5dr1N1tJE%3D%0A&s=ec3a8e21156d1b946db652fac0dab2e2268340aea37bd8c30adbf52fe2f3e8de>
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
>
> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=DYApm8uTUC2lxp%2B0qmdN9UhsdAxGdWaIHf5dr1N1tJE%3D%0A&s=ec3a8e21156d1b946db652fac0dab2e2268340aea37bd8c30adbf52fe2f3e8de
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
cts in the model (ex: load balancer)?
>
o How can statistics from a shared logical object be obtained in context
> of the load balancer (ex: pool statistics for a specific listener in a
> specific load balancer)?
>
· Deletion of shared objects
>
> o Do we support de
may need that.
>
Thanks! I appreciate the input, eh!
>
> >
> > o From which object will the user “poll” to get statistics
> > for the different sub objects in the model (ex: load
> > balancer)?
> >
> >
> > o
on't want the old api and new api sharing the same
> tables. We can either append v2 to the names or rename them entirely.
> Sam suggested group for pool, healthcheck for healthmonitor, and node
> for member. I'd prefer nodepool for pool myself.
>
nodepool isn't
ll
> >J
> >
> >Additionally, we measure:
> >·
> >When a lb instance was created, deleted, etc.
> >·
> >For monitoring we ³ping² a load balancers health check and report/act on
> >the results
> >·
> >For user¹s troubleshooting we make the
ret-store. I think this is a problem that may need to be solved at a
> > higher level. Maybe an openstack-wide registry of dependend entities
> > across services?
>
> An optional openstack-wide registry of depended entities is called
> "Heat".
>
> ___
ote is for option #2 (without the registration). It is simpler to
> >start with this approach. How is delete handled though?
> >
> >Ex. What is the expectation when user attempts to delete a
> >certificate/container which is referred by an entity like LBaaS listener?
> >
>
view.openstack.org/#/c/98640
> >
> > You are welcome to start commenting it for any open discussions.
> > I tried to address each aspect being discussed, please add comments
> about missing things.
> >
> > Thanks,
> > Evgeny
> >
> >
tainer actually isn't in use by LBaaS
anymore, then LBaaS would simply respond that nothing is using the cert
anymore.
>
>
> Please comment on these points and review the document on gerrit (
> https://review.openstack.org/#/c/98640)
>
> I will update the document with decisio
of the meeting
> > >> > where we'll discuss this.
> > >> >
> > >> > Thanks!
> > >> > Kyle
> > >> >
> > >> > > Thanks,
> > >> > > Brandon
> > >> > >
>
1 - 100 of 203 matches
Mail list logo
