I agree whole-heartedly with johnsom's assessment of diltram's
contributions. +1 from me!
On Mon, Oct 10, 2016 at 1:06 PM, Michael Johnson
wrote:
> Greetings Octavia and developer mailing list folks,
>
> I propose that we add Lubosz Kosnik (diltram) as an OpenStack Octavia
> core reviewer.
>
> H
Jay--
If this is a production install, it's very unlikely that the admin user's
password is "password". The neutron_lbaas.conf file will need to be
updated with the admin user's actual password, and the neutron services
daemon restarted.
Stephen
On Fri, Sep 23, 2016 at 2:29 AM, Jayanthi Jeyakum
Miguel--
There have been a number of tempest patches in the review queue for a long
time now, but I think the reason they're not getting attention is that we
don't want to have to import a massive amount of tempest code into our
repository (which will become stale and need hot-fixing, as has happe
Hey Sergey,
In-line comments below:
On Sun, Jun 5, 2016 at 8:07 AM, Sergey Guenender wrote:
>
> Hi Stephen, please find my reply next to your points below.
>
> Thank you,
> -Sergey.
>
>
> On 01/06/2016 20:23, Stephen Balukoff wrote:
> > Hey Sergey--
> &g
Hey Sergey--
Apologies for the delay in my response. I'm still wrapping my head around
your option 2 suggestion and the implications it might have for the code
base moving forward. I think, though, that I'm against your option 2
proposal and in favor of option 1 (which, yes, is more work initially
Hello Yong Sheng Gong!
Apologies for the lateness of my reply (I've been intermittently available
over the last month and am now just catching up on ML threads). Anyway, did
you get your question answered elsewhere? It looks like you've discovered a
bug in the behavior here-- when you created the
Hi Akshay!
In response to your questions: The Mitaka release of Octavia is version
0.8. It's got most of the features of 1.0, but since the development path
didn't exactly follow the road map (since nobody is prescient 18 months in
advance) most of us felt more comfortable calling this release 0.
you'll get to spend more time editing those documentation
> > contributions than writing them from scratch yourself. And everyone wins
> > then because the OpenStack documentation becomes more complete and sucks
> > less.
>
> We greatly appreciate all the developers who
by tapping directly at the open source faucet.
>
Exactly what I fear as well. Please note that it is offensive to accuse a
team of not stepping up when what I am doing in this very e-mail should be
pretty good evidence that we are trying to step up.
Stephen
--
Stephen Balukoff
Principal T
lf. And everyone wins
then because the OpenStack documentation becomes more complete and sucks
less.
In any case, I am certainly willing to provide feedback on the above
suggested how-to guides, should someone decide to write them.
Thanks,
Stephen
P.S. I still have no idea how I go about updatin
ot for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-re
To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org
> >>
> > Subject: Re: [openstack-dev] [lbaas] [octavia] Proposing Stephen
> Balukoff as Octavia Core
> >
> > +1
>
> > >
> > > I feel that the subnet should be mandatory as there are too many
> > > ambiguity issues due to overlapping subnets and multiple routes.
> > > In the case of an IP being outside of the tenant networks, the user
> > > would specify an external net
__
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _
k Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Stephen Balukoff
Principal Technologist
Blue Box, An IBM Company
www.blueboxcloud.com
sbaluk...@blueboxc
t;>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > > >
>>> > >
>>> >
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
ments. Any help/pointers/links
> would be great.
>
> thanks
> Sri
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-b
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
>
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
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
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
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
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
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
>
>
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
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
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.
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
; > 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/openstack-dev
talking about a 5 day Hackathon or 3 day with 2 days (Mon & Fri)
> for travel?
>
> On Thu, Nov 6, 2014 at 10:10 AM, Adam Harwell
> wrote:
>
>> Any chance it could actually be the week AFTER? Or is that to close to
>> the holidays? <_<
>> On Nov 6, 2014 7:2
t;Thanks,
> >German
> >
> >From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com]
> >
> >Sent: Wednesday, October 22, 2014 6:51 AM
> >To: OpenStack Development Mailing List (not for usage questions)
> >Subject: Re: [openstack-dev] [Neutron][LBaaS][
The current meeting time is too early for me (in PST8PDT time zone). I
prefer the 16:00 UTC time or later.
Stephen
On Nov 6, 2014 8:22 AM, "Samuel Bercovici" wrote:
> For us in Israel, the earlier the better.
>
> The current meeting time is very good for us, although I understand it too
> early
ote:
> I can probably make it up there to attend.
>
> --Adam
>
> https://keybase.io/rm_you
>
>
> From: Stephen Balukoff
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Tuesda
Howdy, folks!
We are planning to have a mid-cycle hack-a-thon in Seattle from the 8th
through the 12th of December. This will be at the HP corporate offices
located in the Seattle convention center.
During this week we will be concentrating on Octavia code and hope to make
significant progress to
to the PROS and CONS if wanted.
>
> If it is direction we can agree on going then we can add as a talking
> point in the advanced services spin out meeting:
>
>
> http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a6#.VEq66HWx3UY
>
> Thanks,
> Brando
ply, always be explicit. Implications usually stem from bad
> assumptions.
>
>
> Last but not least, we need to store every user and system load balancer
> event such as creation, updates, suspension and deletion so that we may
> bill on things like uptime and serve our customers better by knowing what
>
Just tryin to help out Balukoff :P
>
>
> ___
> 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
___
Open
Octavia, please update our standup etherpad:
https://etherpad.openstack.org/p/octavia-weekly-standup
Beyond that, this is your friendly reminder that the Octavia team meets on
Wednesdays at 20:00UTC in #openstack-meeting-alt
Thanks,
Stephen
--
Stephen Balukoff
Blu
, Sep 24, 2014 at 11:56 PM, Stephen Balukoff
wrote:
> Hi folks!
>
> First off-- thanks to Brandon for running yesterday's Octavia meeting when
> I had to step out for an emergency at the last minute.
>
> Anyway, it's clear to me from the transcripts of the meeti
which you might object to. If you're concerned
about the direction some of these blueprints might go, I encourage you to
subscribe to them, and then raise objections with me or with the group if
you see a problem. We're speccing almost everything out as well, so keep
he Octavia team meets on
Wednesdays at 20:00UTC in #openstack-meeting-alt
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/m
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
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
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
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
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
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
-
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
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.
can have
> > something definitive on that soon.
> >
> > Thanks,
> > Brandon
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> >
&g
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
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
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
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
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!
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
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
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
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
’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
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,
>
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
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
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
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?
>>
>>
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
, Stephen Balukoff
wrote:
> Wow, Trevor! Thanks for capturing all that!
>
>
> On Wed, Aug 6, 2014 at 9:47 PM, Trevor Vardeman <
> trevor.varde...@rackspace.com> wrote:
>
>> Agenda items are numbered, and topics, as discussed, are described
>> beneath in list forma
t email this out
> after each meeting to the Octavia mailing list, or should I also add it to
> a page in an Octavia wiki for Meeting Notes/Minutes or something for review
> by anyone? What are your thoughts?
>
> ___
> O
On Wed, 2014-08-06 at 15:30 -0700, Stephen Balukoff wrote:
> > Action items from today's Octavia meeting:
> >
> >
> > 1. We're going to hold off for a couple days on merging the
> > constitution and preliminary road map to give people (and in
> > particu
r" solution can actually meet the needs of the operators
developing it.
Thanks,
Stephen
On Tue, Aug 5, 2014 at 2:34 PM, Stephen Balukoff
wrote:
> Hello!
>
> We plan on resuming weekly meetings to discuss things related to the
> Octavia project starting tomorrow: Augus
me to collect and share their data as well! I'm looking at
you, Ebay. ;) )
Please feel free to respond with additional agenda items!
Stephen
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
Ope
bin/mailman/listinfo/openstack-dev
> > ___
> > OpenStack-dev mailing list
> > OpenStack-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/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
gt;>> >>>
> >>> >>>
> >>> >>>4. Tempest tests for LBaaS V2 API
> >>> >>>
> >>> >>>Miguel is currently working on these. Miguel do you expect these
> >>>to be
> >>> >>>done in time?
> >&g
ement Ceilometer
> metrics that reveal PoolMember health?
>
> Thanks,
> Mike
>
> _______
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
g list
> > OpenStack-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/c
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______
> OpenStack-dev mailing list
&g
> 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
___
O
cycle.
>
> Does anyone sees a reason why caching certificates’ data in Neutron
> database is critical?
>
>
>
> Thank you,
>
> Evg
>
>
>
>
> _______
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://li
p GEN_DIRNAME entries since RFC2818 doesn't mandate its
> support and I'm not sure if fetching the CN from the DirName is in practice
> now. I'm leery of using CN's from DirName entries as I can imagine people
> signing differen't X509Names as a DirName with no intention
wo.
Thanks,
Stephen
On Wed, Jul 16, 2014 at 7:26 PM, Stephen Balukoff
wrote:
> Hi Vijay,
>
>
>
> On Wed, Jul 16, 2014 at 9:07 AM, Vijay Venkatachalam <
> vijay.venkatacha...@citrix.com> wrote:
>
>>
>>
>> Do you know if the SSL/SNI IETF spec details abo
wo.
Thanks,
Stephen
On Wed, Jul 16, 2014 at 7:41 PM, Stephen Balukoff
wrote:
> Vijay--
>
> I'm confused: If NetScaler doesn't actually look at the SAN, isn't it not
> actually following the SNI standard? (RFC2818 page 4, paragraph 2, as I
> think Carlos point
wo.
Thanks,
Stephen
On Wed, Jul 16, 2014 at 7:31 PM, Stephen Balukoff
wrote:
> Just saw this thread after responding to the other:
>
> I'm in favor of Evgeny's proposal. It sounds like it should resolve most
> (if not all) of the operators', vendors' and users&
in
the description to cover (1)
If there are problems people are trying to solve with flavors that are not
among the above 4 points, I would suggest that these either become a part
of a later revision of flavors, or simply get discussed as a new entity
entirely (depending on what peop
>>
> >> From: Samuel Bercovici [mailto:samu...@radware.com]
> >> Sent: Tuesday, July 15, 2014 11:52 PM
> >> To: OpenStack Development Mailing List (not for usage questions);
> >> Vijay Venkatachalam
> >> Subject: RE: [openstack-dev] [Neutron][LBa
ion' error or whatnot? (I believe we're trying to get
the ability to return such errors with the flavor framework, correct?)
In any case, is there any reason to delay going forward with a model and
code that:
A. Uses an 'order' attribute on the SNI-related objects to reso
> OK.
> >
> > Let me be more precise, extracting the information for view sake /
> validation would be good.
> > Providing values that are different than what is in the x509 is what I
> am opposed to.
> >
> > +1 for Carlos on the library and that it should be ub
t; API (that's mainly because of how flavor plugin interacts with service
> plugins)
>
Yes, I think single-service flavors is almost certainly going to be a
simpler thing to implement, too-- and if we want to get flavors in for Juno
(which I know *we* really want to do), then I think reducing the complexity
here is probably a good idea, at least for the first revision.
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
e this makes sense? What
are the characteristics of a flavor that applies to more than one service
type?
Let's see if we can come to some conclusions on this so that we can get
flavors into Juno, please!
Thanks,
Stephen
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
_
d code/driver must(?) extract SCN and(?) SAN and
> use it for certificate determination for host
> >
> > Please give your feedback
> >
> > Thanks,
> > Evg
> > ___
> > OpenStack-dev mailing list
> > OpenStack-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/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
I think its a good idea to use the
> time that way at least until Octavia is more of a priority. Does anyone
> else share this same concern? Do we think that's a good use of that time?
>
>
>
> -Trevor
>
> ___
> OpenStack-dev m
with the old driver, right now. Once L7 and TLS get in then
> yes there would be.
>
> I'd just like to get people's ideas on this.
>
> Thanks,
> Brandon
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openst
a and operator
> requirements with Stephen and who else wants to contribute.
>
> Regards Susanne
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/opens
that if you do, please also do us the
courtesy of explaining how we're supposed to merge code using the gerrit
system without having a PTL or core reviewers.
Anyway, this is the list of folks we agreed upon:
Interim PTL: Stephen Balukoff
Interim core reviewers: Vivek Jain, Brandon Logan, Germa
rovisioning status of all of its children. So if a health
>>> monitor
>>> > >is updated then the load balancer that health monitor is linked to
>>> would
>>> > >have its status changed to PENDING_UPDATE. Conversely, if a load
>>> > >balancer or any entities linked to it are change
aas-l7-rules.rst
>>
>>
>>
>> Thanks
>>
>> Avishay
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-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/openstack-dev
>>
>>
>
> ___
> 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
oruk [mailto:evge...@radware.com ]
> *Sent:* Tuesday, June 24, 2014 12:25 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for
> listener be set through separate API/model?
>
>
>
> +
s silly to
spend much energy on something so minor right now.)
On Mon, Jun 23, 2014 at 6:25 PM, Stephen Balukoff
wrote:
> Ok, so we've got opinions on both sides of the argument here. I'm actually
> pretty ambivalent about it. Do others have strong opinions on this?
>
>
&
a 1:1 relationship? Putting that in a new table
> sounds like premature optimization to me; design the database change for
> the future feature when you can see the spec for it.
>
> Thanks,
> Doug
>
>
> From: Stephen Balukoff
> Reply-To: "OpenStack Development Mailin
> > Listener object.
> >
> > Cons:
> > -It's another entity
> >
> > In IRC we (sbalukoff, myself) seemed to agree option 2 is right way to
> > go. Anyone agree or disagree?
> >
> > Thanks,
> > Brandon
> >
> > On Mon, 2014
k.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/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
1 - 100 of 203 matches
Mail list logo
