Re: [openstack-dev] [lbaas] [octavia] Proposing Lubosz Kosnik (diltram) as Octavia Core

[Stephen Balukoff]

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.
>
> His contributions [1] are in line with other cores and he has been an
> active member of our community.  He regularly attends our weekly
> meetings, contributes good code, and provides solid reviews.
>
> Overall I think Lubosz would make a great addition to the core review team.
>
> Current Octavia cores, please respond with +1/-1.
>
> Michael
>
> [1] http://stackalytics.com/report/contribution/octavia/90
>
> __
> 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
>
__
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

Re: [openstack-dev] Fwd: [neutron][lbaas][barbican] Listener create fails

[Stephen Balukoff]

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 Jeyakumar  wrote:

>
> -- Forwarded message --
> From: 
> Date: Fri, Sep 23, 2016 at 11:50 AM
> Subject: [neutron][lbaas][barbican] Listener create fails
> To: jeyakumar@gmail.com
>
>
> You have to be a subscriber to post to this mailing list, so your
> message has been automatically rejected. You can subscribe at:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> If you think that your messages are being rejected in error, contact
> the mailing list owner at %(listowner)
>
>
>
> -- Forwarded message --
> From: Jayanthi Jeyakumar 
> To: openstack-dev@lists.openstack.org
> Cc:
> Date: Fri, 23 Sep 2016 11:50:29 +0530
> Subject: [neutron][lbaas][barbican] Listener create fails
> Hello All,
>
> Setup : Liberty with Barbican
>
> When i create a listener it fails with error "could not process TLS
> container , invalid user/password"
>
> DEBUG: keystoneclient.session REQ: curl -g -i -X POST
> http://x.x.x.x:9696/v2.0/lbaas/listeners.json -H "User-Agent:
> python-neutronclient" -H "Content-Type: application/json" -H "Accept:
> application/json" -H "X-Auth-Token: 
> {SHA1}2b74be94ec992cd8d53d930d743b344428eb1a4f"
> -d '{"listener": {"protocol": "TERMINATED_HTTPS", "name": "ebay_lb1_list1",
> "default_tls_container_ref": "http://10.106.100.55:9311/v1/
> containers/05b750e5-ef14-4afc-b4fe-2b4949cf3356", "admin_state_up": true,
> "protocol_port": "443", "loadbalancer_id": "773b8813-9325-43bf-8147-69de1
> 424fed5"}}'
>
> RESP BODY: {"NeutronError": {"message": "Could not process TLS container
> http://x.x.x.x:9311/v1/containers/05b750e5-ef14-4afc-b4fe-2b4949cf3356,
> Invalid user / password (Disable debug mode to suppress these details.)",
> "type": "CertManagerError", "detail": ""}}
>
> added this to my neutron.conf
> service_plugins = neutron_lbaas.services.loadb
> alancer.plugin.LoadBalancerPluginv2
>
> neutron_lbaas.conf
> [service_auth]
> auth_uri = http://localhost:35357/v2.0
> admin_tenant_name = admin
> admin_user = admin
> admin_password = password
> auth_version = 2
>
> [service_providers]
> service_provider=LOADBALANCERV2:NetScaler:neutron_lbaas.
> drivers.netscaler.netscaler_driver_v2.NetScalerLoadBalance
> rDriverV2:default
>
> Please let me know if anymore configurations need to be done..
>
> Thanks,
> Jay
>
>
>
> __
> 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
>
>
__
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

Re: [openstack-dev] [octavia] Multi-node controller testing

[Stephen Balukoff]

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 happened
with neutron-lbaas on many occasions), and it appears tempest-lib doesn't
yet support all the stuff we would need to do with it.

People have suggested Rally, but so far nobody has come forth with code, or
a strong desire to push it through.

Stephen

On Tue, Aug 9, 2016 at 5:40 AM, Miguel Angel Ajo Pelayo  wrote:

> On Mon, Aug 8, 2016 at 4:56 PM, Kosnik, Lubosz 
> wrote:
> > Great work with that multi-node setup Miguel.
>
> Thanks, I have to get my hands dirtier with octavia, it's just a tiny
> thing.
>
> > About that multinode Infra is supporting two nodes setup used currently
> by grenade jobs but in my opinion we don’t have any tests which can cover
> that type of testing. We’re still struggling with selecting proper tool to
> test Octavia from integration/functional perspective so probably it’s too
> early to make it happen.
>
>
> Well, any current tests we run should pass equally well in a multi
> node controller, and that's the point, that, regardless of the
> deployment architecture the behaviour shall not change at all. We may
> not need any specific test.
>
>
> > Maybe it’s great start to finally make some decision about testing tools
> and there will be a lot of work for you after that also with setting up an
> infra multi-node job for that.
>
> I'm not fully aware of what are we running today for octavia, so if
> you can give me some pointers about where are those jobs configured,
> and what do they target, it could be a start, to provide feedback.
>
> What are the current options/tools we're considering?
>
>
> >
> > Cheers,
> > Lubosz Kosnik
> > Cloud Software Engineer OSIC
> > lubosz.kos...@intel.com
> >
> >> On Aug 8, 2016, at 7:04 AM, Miguel Angel Ajo Pelayo <
> majop...@redhat.com> wrote:
> >>
> >> Recently, I sent a series of patches [1] to make it easier for
> >> developers to deploy a multi node octavia controller with
> >> n_controllers x [api, cw, hm, hk] with an haproxy in front of the API.
> >>
> >> Since this is the way the service is designed to work (with horizontal
> >> scalability in mind), and we want to have a good guarantee that any
> >> bug related to such configuration is found early, and addressed, I was
> >> thinking that an extra job that runs a two node controller deployment
> >> could be beneficial for the project.
> >>
> >>
> >> If we all believe it makes sense, I would be willing to take on this
> >> work but I'd probably need some pointers and light help, since I've
> >> never dealt with setting up or modifying existing jobs.
> >>
> >> How does this sound?
> >>
> >>
> >> [1] https://review.openstack.org/#/q/status:merged+project:
> openstack/octavia+branch:master+topic:multinode-devstack
> >>
> >> 
> __
> >> 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
> >
> > 
> __
> > 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
>
> __
> 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
>
__
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

Re: [openstack-dev] [octavia] enabling new topologies

[Stephen Balukoff]

Hey Sergey,

In-line comments below:

On Sun, Jun 5, 2016 at 8:07 AM, Sergey Guenender <sgs...@gmail.com> 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--
> >
> > 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) for the following reasons:
> >
> > A. We have a precedent in the code tree with how the stand-alone and
> > active-standby topologies are currently being handled. Yes, this does
> > entail various conditionals and branches in tasks and flows-- which is
> > not really that ideal, as it means the controller worker needs to have
> > more specific information on how topologies work than I think any of us
> > would like, and this adds some rigidity to the implementation (meaning
> > 3rd party vendors may have more trouble interfacing at that level)...
> > but it's actually "not that bad" in many ways, especially given we don't
> > anticipate supporting a large or variable number of topologies.
> > (stand-alone, active-standby, active-active... and then what? We've been
> > doing this for a number of years and nobody has mentioned any radically
> > new topologies they would like in their load balancing. Things like
> > auto-scale are just a specific case of active-active).
>
> Just as you say, two topologies are being handled as of now by only one
> set of flows. Option two goes along the same lines, instead of adding new
> flows for active-active it suggests that minor adjustments to existing
> flows can also satisfy active-active.
>

My point was that I think the distributor and amphora roles are different
enough that they ought to have separate drivers, separate flows, etc.
almost entirely. There's not much difference between a stand-alone amphora
and an amphora in an active-standby topology. However, there's a huge
difference between both of these and a distributor (which will have its own
back-end API, for example).


>
> > B. If anything Option 2 builds more less-obvious rigidity into the
> > implementation than option 1. For example, it makes the assumption that
> > the distributor is necessarily an amphora or service VM, whereas we have
> > already heard that some will implement the distributor as a pure network
> > routing function that isn't going to be managed the same way other
> > amphorae are.
>
> This is a good point. By looking at the code, I see there are comments
> mentioning the intent to share amphora between several load balancers.
> Although probably not straightforward to implement, it might be a good idea
> one day, but the fact is it looks like amphora has not been shared between
> load balancers for a few years.
>
> Personally, when developing something complex, I believe in taking baby
> steps. If the virtual, non-shared distributor (which is promised by the AA
> blueprint anyway) is the smallest step towards a working active-active,
> then I guess it should be considered taking first.
>

The AA blueprint has yet to be approved (and there appear to be a *lot* of
comments on the latest revision). But yes-- in general you need to walk
before you can run. But instead of torturing analogies, let me say this:
Assumptions about design are reflected in the code. So, I generally like to
do my best getting the design right... and then any baby steps taken should
be evaluated against that end design to ensure they don't introduce
assumptions that will make it difficult to get there.



>
> Unless of course, it precludes implementing the following, more complex
> topologies.
>
> My belief is it doesn't have to. The proposed change alone (splitting
> amphorae into sub-clusters to be used by the many for-loops) doesn't force
> any special direction on its own. Any future topology may leave its
> "front-facing amphorae" set equal to its "back-facing amphorae" which
> brings it back to the current style of for-loops handling.
>

See, I disagree that an amphora and a distributor are even really similar.
The idea that a distributor is just a front-facing amphora I think is
fundamentally false-- Especially if distributors are implemented with a
direct-return topology (as the blueprint under evaluation describes) then
they're almost nothing alike. The distributor service VM will not be
running haproxy and will be running its own unique API specifically because
it's fulfilling a vastly different role in the topology than th

Re: [openstack-dev] [octavia] enabling new topologies

[Stephen Balukoff]

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) for
the following reasons:

A. We have a precedent in the code tree with how the stand-alone and
active-standby topologies are currently being handled. Yes, this does
entail various conditionals and branches in tasks and flows-- which is not
really that ideal, as it means the controller worker needs to have more
specific information on how topologies work than I think any of us would
like, and this adds some rigidity to the implementation (meaning 3rd party
vendors may have more trouble interfacing at that level)...  but it's
actually "not that bad" in many ways, especially given we don't anticipate
supporting a large or variable number of topologies. (stand-alone,
active-standby, active-active... and then what? We've been doing this for a
number of years and nobody has mentioned any radically new topologies they
would like in their load balancing. Things like auto-scale are just a
specific case of active-active).

B. If anything Option 2 builds more less-obvious rigidity into the
implementation than option 1. For example, it makes the assumption that the
distributor is necessarily an amphora or service VM, whereas we have
already heard that some will implement the distributor as a pure network
routing function that isn't going to be managed the same way other amphorae
are.

C. Option 2 seems like it's going to have a lot more permutations that
would need testing to ensure that code changes don't break existing /
potentially supported functionality. Option 1 keeps the distributor and
amphorae management code separate, which means tests should be more
straight-forward, and any breaking changes which slip through potentially
break less stuff. Make sense?

Stephen


On Sun, May 29, 2016 at 7:12 AM, Sergey Guenender  wrote:

> I'm working with the IBM team implementing the Active-Active N+1 topology
> [1].
>
> I've been commissioned with the task to help integrate the code supporting
> the new topology while a) making as few code changes and b) reusing as much
> code as possible.
>
> To make sure the changes to existing code are future-proof, I'd like to
> implement them outside AA N+1, submit them on their own and let the AA N+1
> base itself on top of it.
>
> --TL;DR--
>
> what follows is a description of the challenges I'm facing and the way I
> propose to solve them. Please skip down to the end of the email to see the
> actual questions.
>
> --The details--
>
> I've been studying the code for a few weeks now to see where the best
> places for minimal changes might be.
>
> Currently I see two options:
>
>1. introduce a new kind of entity (the distributor) and make sure it's
> being handled on any of the 6 levels of controller worker code (endpoint,
> controller worker, *_flows, *_tasks, *_driver)
>
>2. leave most of the code layers intact by building on the fact that
> distributor will inherit most of the controller worker logic of amphora
>
>
> In Active-Active topology, very much like in Active/StandBy:
> * top level of distributors will have to run VRRP
> * the distributors will have a Neutron port made on the VIP network
> * the distributors' neutron ports on VIP network will need the same
> security groups
> * the amphorae facing the pool member networks still require
> * ports on the pool member networks
> * "peers" HAProxy configuration for real-time state exchange
> * VIP network connections with the right security groups
>
> The fact that existing topologies lack the notion of distributor and
> inspecting the 30-or-so existing references to amphorae clusters, swayed me
> towards the second option.
>
> The easiest way to make use of existing code seems to be by splitting
> load-balancer's amphorae into three overlapping sets:
> 1. The front-facing - those connected to the VIP network
> 2. The back-facing - subset of front-facing amphorae, also connected to
> the pool members' networks
> 3. The VRRP-running - subset of front-facing amphorae, making sure the VIP
> routing remains highly available
>
> At the code-changes level
> * the three sets can be simply added as properties of
> common.data_model.LoadBalancer
> * the existing amphorae cluster references would switch to using one of
> these properties, for example
> * the VRRP sub-flow would loop over only the VRRP amphorae
> * the network driver, when plugging the VIP, would loop over the
> front-facing amphorae
> * when connecting to the pool members' networks,
> network_tasks.CalculateDelta would only loop over the back-facing amphorae
>
>-
>
> In terms of backwards compatibility, Active-StandBy topology would have
> the 3 sets equal and contain both of its amphorae.
>
> An even more 

Re: [openstack-dev] [octavia] is l7 rule using routed L3 connectivity

[Stephen Balukoff]

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 member on server_subnet2,
an interface should have been added to the amphora in the amphora-haproxy
namespace. If you haven't yet filed a bug report on this, could you?

In any case, the behavior you're seeing (which is not correct in this case)
is that if the amphora doesn't have a directly-connected interface is that
it will use its default route to attempt to reach the member.

Stephen

On Tue, May 10, 2016 at 12:01 AM, 龚永生  wrote:

> Hi, Stephen,
>
> By running following commands:
> neutron lbaas-pool-create --lb-algorithm ROUND_ROBIN --loadbalancer
> 85800051-31fb-4ca0-962d-8835656a61ef --protocol HTTP --name pool2
>
> neutron net-create server_net2
>
> neutron subnet-create server_net2 10.20.2.0/24 --name server_subnet2
>
> neutron lbaas-member-create --subnet server_subnet2 --address 10.20.2.10
> --protocol-port 8080 pool2
>
> neutron lbaas-l7policy-create --name policy1  --action REDIRECT_TO_POOL
> --redirect-pool pool2 --listener 8ec3a2e5-8cb5-472e-a12c-f067eefa4b7a
>
> neutron lbaas-l7rule-create --type PATH --compare-type STARTS_WITH --value
> "/api" policy1
>
> I found there is no interface on server_subnet2 in namespace amphora-haproxy
> on amphora:
> ubuntu@amphora-86359e7c-f473-41c3-9531-c8bf129ec6b7:~$ sudo ip netns exec
> amphora-haproxy ip a
> 1: lo:  mtu 65536 qdisc noop state DOWN group default
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 3: eth1:  mtu 1450 qdisc pfifo_fast state
> UP group default qlen 1000
> link/ether fa:16:3e:5f:4c:c1 brd ff:ff:ff:ff:ff:ff
> inet 10.20.0.33/24 brd 10.20.0.255 scope global eth1
>valid_lft forever preferred_lft forever
> inet 10.20.0.32/24 brd 10.20.0.255 scope global secondary eth1:0
>valid_lft forever preferred_lft forever
> inet6 fe80::f816:3eff:fe5f:4cc1/64 scope link
>valid_lft forever preferred_lft forever
> 4: eth2:  mtu 1450 qdisc pfifo_fast state
> UP group default qlen 1000
> link/ether fa:16:3e:8a:3d:f5 brd ff:ff:ff:ff:ff:ff
> inet 10.20.1.5/24 brd 10.20.1.255 scope global eth2
>valid_lft forever preferred_lft forever
> inet6 fe80::f816:3eff:fe8a:3df5/64 scope link
>valid_lft forever preferred_lft forever
>
> Is L7 policy using "*Routed (layer-3) connectivity"?*
>
> *Thanks*
> *yong sheng gong*
> --
> *龚永生*
> *九州云信息科技有限公司 99CLOUD Co. Ltd.*
> 邮箱（Email）：gong.yongsh...@99cloud.net 
> 地址：北京市海淀区上地三街嘉华大厦B座806
> Addr : Room 806, Tower B, Jiahua Building, No. 9 Shangdi 3rd Street,
> Haidian District, Beijing, China
> 手机（Mobile)：+86-18618199879
> 公司网址（WebSite）：http://99cloud.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

Re: [openstack-dev] [lbaas][octavia] Queries on octavia features

[Stephen Balukoff]

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.8. You
will probably see 1.0 or something between 1.0 and 2.0 in Newton. In any
case, yes 0.8 includes active-standby support with failover that seems to
work in production. :)

Yes, we have SSL offloading and L7 based load balancing in the current (0.8
/ Mitaka) release. Documentation on using these effectively is still being
updated, but the features are there and work.

We have endeavored to make nearly every component within Octavia
driver-driven. So if you want to replace the driver designed to work with
haproxy-based amphorae with something of your own creation this should be
possible without an unreasonable amount of work. About the only major
design feature that would be difficult to work around at this point is the
*concept* of an amphora in the controller daemons: Octavia is a specialized
system for managing load balancing services across a fleet of
mostly-independent VMs / Containers / Appliances (ie. amphora) which
deliver the actual service. If you have a vendor-supplied product that can
work with this model, you should be able to develop a driver for Octavia.

Does that make sense?

On Fri, Apr 15, 2016 at 9:37 AM, Akshay Kumar Sanghai <
akshaykumarsang...@gmail.com> wrote:

> Hi,
> I am trying to use lbaas v2 for loadbalancing in openstack. I have few
> queries. I don't know whether I should directly ask you guys or not. If you
> can answer, then that would be great.
>
> - Is the v1 of octavia released? The documentation details the v0.5 design
> and under v1 project specs, there is active standby setup of amphora.
>
> - Do we have ssl offloading, L7 based loadbalancing in the current
> release?
>
> - Currently HAproxy provides the loadbalancing services in amphora. Do you
> guys plan to change the provider?
>
> Thanks,
> Akshay Sanghai
>
>
>
> __
> 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
>
>
__
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

Re: [openstack-dev] [OpenStack-docs] Fwd: [Neutron][LBaaS][Octavia][Docs] Need experienced contributor documentation best-practices and how-tos

[Stephen Balukoff]

 our guiding principle since Anne Gentle formed the openstack-manuals team.
> What else should we be doing to get this message out there?
>

I agree that handling docs like code is a good thing. Maybe adding the
"Doc-Change:" feature described above could aid in that. :)

Perhaps part of the problem is that the contributors' guide has only one
"Quickstart" page, that is aimed purely at people new to OpenStack
contribution in general. Perhaps it would be a good thing to create two
more quickstart pages:  One aimed at experienced contributors who
nevertheless don't do (or haven't done) documentation updates that often,
and another aimed at project cores which list best practices for where
different types of documentation should go, as well as best practices for
how to organize and test documentation kept within their own repositories
(even if half of this just ends up being links to infra docs)?

Part of the problem with the contributors' guide as I see it right now is
that it provides a lot of detail on specific items, but it's easy to get
quickly overloaded in detail. The detail is definitely important, but
without knowing where to get started, it can become frustrating (and people
will give up-- even people who have otherwise work with gerrit every day.)

Does that make sense?



> > Please also note that I am *NOT* volunteering to write the above
> documents
> > per se: The above docs need to be written by someone actually familiar
> with
> > the documentation system. But it will be effort well spent, because when
> > developers actually do start contributing documentation along with their
> > new code, 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 contribute to docs. There are
> many already involved, but it's always wonderful to welcome more :)
>
> >
> > 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 updating the manual for the
> major
> > features that we added to neutron-lbaas and Octavia in this cycle.
>
> Your automated content should be here:
> http://docs.openstack.org/liberty/config-reference/content/networking-plugin-lbaas.html
> Please raise a bug against openstack-manuals (
> https://launchpad.net/openstack-manuals) if that is not the case.
>
>
Ok, I will do what I can to galvanize my team to make the above not suck.
:) Given our previous discussion, I don't suppose there's an obvious way to
figure out where a relatively new project's information ought to be
inserted in the manual?  (Octavia is the reference implementation for
Neutron-LBaaS, so in the operators' guide on how to set up LBaaS we're also
going to have to describe how to set up, configure and maintain Octavia.)


> Octavia is documented here: http://docs.openstack.org/developer/octavia/
> If you have content to add, propose a patch to
> http://git.openstack.org/cgit/openstack/octavia
>
>
Yep-- contributed a good portion of that myself already, actually. :)
(Didn't know that was "kosher.")



> If you feel these things should be documented elsewhere, please raise a
> bug, or ping me on IRC (I'm loquacity) and we can chat further about the
> best place for it.
>

Cool beans! I'm "sbalukoff" on IRC and can usually be raised in the
#openstack-lbaas channel.

Thanks,
Stephen


-- 
Stephen Balukoff
Principal Technologist
Blue Box, An IBM Company
www.blueboxcloud.com
sbaluk...@blueboxcloud.com
206-607-0660 x807
__
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

Re: [openstack-dev] [Neutron][LBaaS][Octavia][Docs] Need experienced contributor documentation best-practices and how-tos

[Stephen Balukoff]

Hi Armando,

Please rest assured that I really am a fan of requiring. I realize that
sarcasm doesn't translate to text, so you'll have to trust me when I say
that I am not being sarcastic by saying that.

However, I am not a fan of being given nebulous requirements and then being
accused of laziness or neglect when I ask for help. More on that later.

Also, the intent of my e-mail wasn't to call you out and I think you are
right to require that new features be documented. I would do the same in
your position.

To start off, my humble suggestion would be to be kind and provide a TL;DR
> before going in such depth, otherwise there's a danger of missing the
> opportunity to reach out the right audience. I read this far because I felt
> I was called into question (after all I am the one 'imposing' the
> documentation requirement on the features we are delivering in Mitaka)!
>

> That said, If you are a seasoned LBaaS developer and you don't know where
> LBaaS doc is located or how to contribute, that tells me that LBaaS docs
> are chronically neglected, and the links below are a proof of my fear.
>

Yes, obviously. I am not interested in shoveling out blame. I'm interested
in solutions to the problem.

Also, how is telling us "wow, your documentation sucks" in any way helpful
in an e-mail thread where I'm asking, essentially, "How do I go about
fixing the documentation?"  If nothing else, it should provide evidence
that there is a problem (which I am trying to point out in this e-mail
thread!)

In a nutshell, this is a rather disastrous. Other Neutron developers
> already contribute successfully to user docs [5]. Most of it is already
> converted to rst and the tools you're familiar with are the ones used to
> produce content (like specs).
>

Really? Which tools? tox? Are there templates somewhere? (I know there are
spec templates... but what about openstack manual templates?)  If there are
templates, where are they? Also, evidence that others are making
contributions to the manual is not necessarily evidence that they're doing
it correctly or consistently.

You're referring to what is essentially tribal knowledge. This is not a
good way to proceed if you want things to be consistent and done the best
way.

I have been doing this for a while (obviously not as long as some), and
I've seen it done in many different ways in different projects. Where are
the usable best practices guides?


> My suggestion would be to forge your own path, and identify a place in the
> networking-guide where to locate some relevant content that describe
> LBaaS/Octavia: deployment architecture, features, etc. This is a long
> journey, that requires help from all parties, but I believe that the
> initiative needs to be driven from the LBaaS team as they are the custodian
> of the knowledge.
>
>
Again, the "figure it out" approach means you are going to get inconsistent
results (like the current poor documentation that you linked). What I'm
asking for in this e-mail is a guide on how it *should* be done that is
consistent across OpenStack, that is actually consumable without having to
read the whole of the OpenStack manual cover-to-cover. This needs to not be
tribal knowledge if we are going to hold people accountable for not
complying with an unwritten standard.

You're not seeing a lack of initiative. Heck, the Neutron-LBaaS and Octavia
projects have some of the most productive people working on them that I've
seen anywhere. You're seeing lack of meaningful guidance, and lack of
standards.

I fear that if none of the LBaaS core members steps up and figure this out,
> LBaaS will continue to be something everyone would like to adopt but no-one
> knows how to, at least not 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 Technologist
Blue Box, An IBM Company
www.blueboxcloud.com
sbaluk...@blueboxcloud.com
206-607-0660 x807
__
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

[openstack-dev] [Neutron][LBaaS][Octavia][Docs] Need experienced contributor documentation best-practices and how-tos

[Stephen Balukoff]

developer's help.

Please understand: I know that big strides have been made in the right
direction here recently, and I know that the docs team is both small and
under-appreciated. For example, the move from XML-based documentation to
.rst based documentation is a huge step in a direction that will prevent
most developers from wanting to gouge their own eyes out anymore when it
comes to writing documentation (though in my searching over the last few
days I did find one api reference repository where it looked like people
are actually editing raw XML and submitting this through the gerrit review
process... please tell me this is not actually still the state of affairs!)

Also, I certainly don't blame the docs team for the history of how we got
to where we are today. I'm pretty sure everyone on that (and most) projects
is truly here to make the OpenStack world a better place and is working
hard to make that happen. Nobody is trying to burn the house down.

But I think there are some flames that need extinguishing. I'm writing this
e-mail because I think we've got some additional steps that need to be
taken to actually help experienced openstack contributors know *how* they
go about updating the openstack docs. It's not that we aren't willing to
write documentation (well, I don't think most are unwilling), it's that the
process for doing this seems extremely obfuscated.

Ideally, I would like to see a practical and relatively short how-to guide
along the lines of: "The shiny new feature you added to your OpenStack
project has merged. Congratulations! Here's how you update the manual..."
This should be written by someone already very familiar with the OpenStack
documentation system. This practical guide would provide answers for:

* How to actually ensure that API / CLI documentation is updated (if it's
actually automated, and what the process for that is so that others can
check.)
* Criteria to know when more documentation is required than just API / CLI
reference updates
* Where to put this more extensive documentation.
* Other non-intuitive information you should know (eg. what image format
diagrams should be in, and best practices for uploading them, plus style
guides for the images)

Even more ideally, I would like to see a practical how-to guide along the
lines of: "So you've started a new OpenStack project. Here's how to make
sure it plays nice with the documentation system..." This would provide
answers for:

* How to set up automated tests to ensure documentation meets
machine-discernable standards for the openstack manual (eg. pep8 for docs
with specific style-enforcement included)
* How to set up automated tests to ensure that documentation is either
imported from your project to the OpenStack manual (less ideal, I know--
coders are coders and not writers for a reason), or that there are hooks
from the openstack manual into your project which flag and potentially
block merges of insufficiently-documented changes (ie. something better
than adding 'APIImpact' and 'DocImpact' to your commit message and hoping
somebody comes along and documents it at some point).
* Best practices for things like where to put the documentation, how and
when to require release notes, documentation templates with the proper
style, where to put sample config files so they get automatically slurped
into the openstack manual, etc.
* How to know if certain types of documentation are inappropriate for the
openstack manual, and best practices on where to put this, if not in the
manual.

I fully admit that it's possible the above may already exist scattered in
various places in the current documentation structure. However, I can tell
you from my experience in the several OpenStack projects I've contributed
to, that it is apparently not easily located or consumed because very few
of the experienced contributors I work with have any clue about much of the
above.

Please also note that I am *NOT* volunteering to write the above documents
per se: The above docs need to be written by someone actually familiar with
the documentation system. But it will be effort well spent, because when
developers actually do start contributing documentation along with their
new code, 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.

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 updating the manual for the major
features that we added to neutron-lbaas and Octavia in this cycle.


-- 
Stephen Balukoff
Principal Technologist
Blue Box, An IBM Company
www.blueboxcloud.com
sbaluk...@blueboxcloud.com
206-607-0660 x807
__
OpenStack Development Mailing Li

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Stephen Balukoff]

I am also on-board with removing LBaaS v1 as early as possible in the
Newton cycle.

On Wed, Mar 2, 2016 at 9:44 AM, Samuel Bercovici <samu...@radware.com>
wrote:

> Thank you all for your response.
>
>
>
> In my opinion given that UI/HEAT will make Mitaka and will have one cycle
> to mature, it makes sense to remove LBaaS v1 in Newton.
>
> Do we want do discuss an upgrade process in the summit?
>
>
>
> -Sam.
>
>
>
>
>
> *From:* Bryan Jones [mailto:jone...@us.ibm.com]
> *Sent:* Wednesday, March 02, 2016 5:54 PM
> *To:* openstack-dev@lists.openstack.org
>
> *Subject:* Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are
> weready?
>
>
>
> And as for the Heat support, the resources have made Mitaka, with
> additional functional tests on the way soon.
>
>
>
> blueprint: https://blueprints.launchpad.net/heat/+spec/lbaasv2-suport
>
> gerrit topic: https://review.openstack.org/#/q/topic:bp/lbaasv2-suport
>
> *BRYAN M. JONES*
>
> *Software Engineer - OpenStack Development*
>
> *Phone: *1-507-253-2620
>
> *E-mail: *jone...@us.ibm.com
>
>
>
>
>
> - Original message -
> From: Justin Pomeroy <jpom...@linux.vnet.ibm.com>
> To: openstack-dev@lists.openstack.org
> Cc:
> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are we
> ready?
> Date: Wed, Mar 2, 2016 9:36 AM
>
> As for the horizon support, much of it will make Mitaka.  See the
> blueprint and gerrit topic:
>
> https://blueprints.launchpad.net/horizon/+spec/horizon-lbaas-v2-ui
> https://review.openstack.org/#/q/topic:bp/horizon-lbaas-v2-ui,n,z
>
> - Justin
>
>
> On 3/2/16 9:22 AM, Doug Wiegley wrote:
>
> Hi,
>
>
>
> A few things:
>
>
>
> - It’s not proposed for removal in Mitaka. That patch is for Newton.
>
> - HEAT and Horizon are planned for Mitaka (see neutron-lbaas-dashboard for
> the latter.)
>
> - I don’t view this as a “keep or delete” question. If sufficient folks
> are interested in maintaining it, there is a third option, which is that
> the code can be maintained in a separate repo, by a separate team (with or
> without the current core team’s blessing.)
>
>
>
> No decisions have been made yet, but we are on the cusp of some major
> maintenance changes, and two deprecation cycles have passed. Which path
> forward is being discussed at today’s Octavia meeting, or feedback is of
> course welcomed here, in IRC, or anywhere.
>
>
>
> Thanks,
>
> doug
>
>
>
> On Mar 2, 2016, at 7:06 AM, Samuel Bercovici <samu...@radware.com
> <samu...@radware.com>> wrote:
>
>
>
> Hi,
>
>
>
> I have just notices the following change:
> https://review.openstack.org/#/c/286381 which aims to remove LBaaS v1.
>
> Is this planned for Mitaka or for Newton?
>
>
>
> While LBaaS v2 is becoming the default, I think that we should have the
> following before we replace LBaaS v1:
>
> 1.  Horizon Support – was not able to find any real activity on it
>
> 2.  HEAT Support – will it be ready in Mitaka?
>
>
>
> Do you have any other items that are needed before we get rid of LBaaS v1?
>
>
>
> -Sam.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> __
> 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
>
>
>
> __
> 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
>
>
>
> __
> 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
>
>
>
>
>
> __
> 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
>
>


-- 
Stephen Balukoff
Principal Technologist
Blue Box, An IBM Company
www.blueboxcloud.com
sbaluk...@blueboxcloud.com
206-607-0660 x807
__
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

Re: [openstack-dev] [lbaas] [octavia] Proposing Stephen Balukoff as Octavia Core

[Stephen Balukoff]

Thanks guys! I appreciate the support and vote of confidence!

On Fri, Feb 5, 2016 at 9:16 AM, Michael Johnson <johnso...@gmail.com> wrote:

> That is quorum from the Octavia cores.
>
> Congratulations Stephen!
>
> Michael
>
> On Fri, Feb 5, 2016 at 9:10 AM, Eichberger, German
> <german.eichber...@hpe.com> wrote:
> > +1
> >
> > From: Bertrand LALLAU <bertrand.lal...@gmail.com bertrand.lal...@gmail.com>>
> > Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org>>
> > Date: Friday, February 5, 2016 at 12:26 AM
> > 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
> >
> > On Fri, Feb 5, 2016 at 3:10 AM, Doug Wiegley <
> doug...@parksidesoftware.com<mailto:doug...@parksidesoftware.com>> wrote:
> > +1
> >
> > Doug
> >
> >
> >> On Feb 4, 2016, at 7:06 PM, Brandon Logan <brandon.lo...@rackspace.com
> <mailto:brandon.lo...@rackspace.com>> wrote:
> >>
> >> +1
> >>
> >>> On Fri, 2016-02-05 at 01:07 +, Adam Harwell wrote:
> >>> +1 from me!
> >>> ________
> >>> From: Michael Johnson <johnso...@gmail.com<mailto:johnso...@gmail.com
> >>
> >>> Sent: Thursday, February 4, 2016 7:03 PM
> >>> To: OpenStack Development Mailing List (not for usage questions)
> >>> Subject: [openstack-dev] [lbaas] [octavia] Proposing Stephen Balukoff
> as Octavia Core
> >>>
> >>> Octavia Team,
> >>>
> >>> I would like to nominate Stephen Balukoff as a core reviewer for the
> >>> OpenStack Octavia project.  His contributions[1] are in line with
> >>> other cores and he has been an active member of our community.
> >>>
> >>> Octavia cores please vote by replying to this e-mail.
> >>>
> >>> Michael
> >>>
> >>> [1] http://stackalytics.com/report/contribution/octavia/90
> >>>
> >>>
> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<
> http://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-requ...@lists.openstack.org?subject:unsubscribe<
> http://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-requ...@lists.openstack.org?subject:unsubscribe<
> http://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-requ...@lists.openstack.org?subject:unsubscribe<
> http://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-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-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...@blueboxcloud.com
206-607-0660 x807
__
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

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?

[Stephen Balukoff]

ss
> than ideal and also has other issues brought up in this thread.
>
> All other scenario permutations are similar to the above ones so I don't
> think i need to go through them.
>
> Basically, I'm waffling on this and am currently on the optional
> subnet_id side but as the builders of octavia, I don't think we should
> allow a load balancer external access unless the tenant has in a way
> given permission by the configuration they've explicitly set.  Though,
> that too should be defined.
>
> Thanks,
> Brandon
> On Tue, 2016-01-19 at 12:07 -0700, Doug Wiegley wrote:
> > But, by requiring an external subnet, you are assuming that the packets
> always originate from inside a neutron network. That is not necessarily the
> case with a physical device.
> >
> > doug
> >
> >
> > > On Jan 19, 2016, at 11:55 AM, Michael Johnson <johnso...@gmail.com>
> wrote:
> > >
> > > 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 network that has the appropriate routes.  We
> > > cannot always assume which tenant network with an external (or VPN)
> > > route is the appropriate one to use.
> > >
> > > Michael
> > >
> > > On Mon, Jan 18, 2016 at 2:45 PM, Stephen Balukoff <
> sbaluk...@bluebox.net> wrote:
> > >> Vivek--
> > >>
> > >> "Member" in this case refers to an IP address that (probably) lives
> on a
> > >> tenant back-end network. We can't specify just the IP address when
> talking
> > >> to such an IP since tenant subnets may use overlapping IP ranges (ie.
> in
> > >> this case, subnet is required). In the case of the namespace driver
> and
> > >> Octavia, we use the subnet parameter for all members to determine
> which
> > >> back-end networks the load balancing software needs a port on.
> > >>
> > >> I think the original use case for making subnet optional was the idea
> that
> > >> sometimes a tenant would like to add a "member" IP that is not part
> of their
> > >> tenant networks at all--  this is more than likely an IP address that
> lives
> > >> outside the local cloud. The assumption, then, would be that this IP
> address
> > >> should be reachable through standard routing from wherever the load
> balancer
> > >> happens to live on the network. That is to say, the load balancer
> will try
> > >> to get to such an IP address via its default gateway, unless it has a
> more
> > >> specific route.
> > >>
> > >> As far as I'm aware, this use case is still valid and being asked for
> by
> > >> tenants. Therefore, I'm in favor of making member subnet optional.
> > >>
> > >> Stephen
> > >>
> > >> On Mon, Jan 18, 2016 at 11:14 AM, Jain, Vivek <vivekj...@ebay.com>
> wrote:
> > >>>
> > >>> If member port (IP address) is allocated by neutron, then why do we
> need
> > >>> to specify it explicitly? It can be derived by LBaaS driver
> implicitly.
> > >>>
> > >>> Thanks,
> > >>> Vivek
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On 1/17/16, 1:05 AM, "Samuel Bercovici" <samu...@radware.com> wrote:
> > >>>
> > >>>> Btw.
> > >>>>
> > >>>> I am still in favor on associating the subnets to the LB and then
> not
> > >>>> specify them per node at all.
> > >>>>
> > >>>> -Sam.
> > >>>>
> > >>>>
> > >>>> -Original Message-
> > >>>> From: Samuel Bercovici [mailto:samu...@radware.com]
> > >>>> Sent: Sunday, January 17, 2016 10:14 AM
> > >>>> To: OpenStack Development Mailing List (not for usage questions)
> > >>>> Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should
> subnet be
> > >>>> optional on member create?
> > >>>>
> > >>>> +1
> > >>>> Subnet should be mandatory
> > >>>>
> > >>>> The only thing this makes supporting load balancing servers which
> are not
> > >>>> running i

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?

[Stephen Balukoff]

Vivek--

"Member" in this case refers to an IP address that (probably) lives on a
tenant back-end network. We can't specify just the IP address when talking
to such an IP since tenant subnets may use overlapping IP ranges (ie. in
this case, subnet is required). In the case of the namespace driver and
Octavia, we use the subnet parameter for all members to determine which
back-end networks the load balancing software needs a port on.

I think the original use case for making subnet optional was the idea that
sometimes a tenant would like to add a "member" IP that is not part of
their tenant networks at all--  this is more than likely an IP address that
lives outside the local cloud. The assumption, then, would be that this IP
address should be reachable through standard routing from wherever the load
balancer happens to live on the network. That is to say, the load balancer
will try to get to such an IP address via its default gateway, unless it
has a more specific route.

As far as I'm aware, this use case is still valid and being asked for by
tenants. Therefore, I'm in favor of making member subnet optional.

Stephen

On Mon, Jan 18, 2016 at 11:14 AM, Jain, Vivek <vivekj...@ebay.com> wrote:

> If member port (IP address) is allocated by neutron, then why do we need
> to specify it explicitly? It can be derived by LBaaS driver implicitly.
>
> Thanks,
> Vivek
>
>
>
>
>
>
> On 1/17/16, 1:05 AM, "Samuel Bercovici" <samu...@radware.com> wrote:
>
> >Btw.
> >
> >I am still in favor on associating the subnets to the LB and then not
> specify them per node at all.
> >
> >-Sam.
> >
> >
> >-Original Message-
> >From: Samuel Bercovici [mailto:samu...@radware.com]
> >Sent: Sunday, January 17, 2016 10:14 AM
> >To: OpenStack Development Mailing List (not for usage questions)
> >Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be
> optional on member create?
> >
> >+1
> >Subnet should be mandatory
> >
> >The only thing this makes supporting load balancing servers which are not
> running in the cloud more challenging to support.
> >But I do not see this as a huge user story (lb in cloud load balancing
> IPs outside the cloud)
> >
> >-Sam.
> >
> >-Original Message-
> >From: Brandon Logan [mailto:brandon.lo...@rackspace.com]
> >Sent: Saturday, January 16, 2016 6:56 AM
> >To: openstack-dev@lists.openstack.org
> >Subject: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be
> optional on member create?
> >
> >I filed a bug [1] a while ago that subnet_id should be an optional
> parameter for member creation.  Currently it is required.  Review [2] is
> makes it optional.
> >
> >The original thinking was that if the load balancer is ever connected to
> that same subnet, be it by another member on that subnet or the vip on that
> subnet, then the user does not need to specify the subnet for new member if
> that new member is on one of those subnets.
> >
> >At the midcycle we discussed it and we had an informal agreement that it
> required too many assumptions on the part of the end user, neutron lbaas,
> and driver.
> >
> >If anyone wants to voice their opinion on this matter, do so on the bug
> report, review, or in response to this thread.  Otherwise, it'll probably
> be abandoned and not done at some point.
> >
> >Thanks,
> >Brandon
> >
> >[1] https://bugs.launchpad.net/neutron/+bug/1426248
> >[2] https://review.openstack.org/#/c/267935/
> >__
> >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
> >
> >__
> >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
> >
> >__
> >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
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

Re: [openstack-dev] [lbaas] [octavia] Proposing Bertrand Lallau as Octavia Core

[Stephen Balukoff]

+1

On Thu, Nov 19, 2015 at 11:08 AM, Michael Johnson <johnso...@gmail.com>
wrote:

> +1
>
> On Thu, Nov 19, 2015 at 9:35 AM, Eichberger, German
> <german.eichber...@hpe.com> wrote:
> > All,
> >
> >
> >
> > As I said in a previous e-mail I am really excited about the deep talent
> in the Octavia sub-project. So it is my pleasure to propose Bertrand Lallau
> (irc blallau) as a new core for the OpenStack Neutron Octavia sub project.
> His contributions [1] are in line with other cores and he has been an
> active member of our community. Current cores please vote by replying to
> this e-mail.
> >
> > Thanks,
> > German
> >
> >
> > [1] http://stackalytics.com/?project_type=openstack=octavia
> >
> __
> > 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
>
> __
> 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
>



-- 
Stephen Balukoff
Principal Technologist
Blue Box, An IBM Company
www.blueboxcloud.com
sbaluk...@blueboxcloud.com
206-607-0660 x807
__
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

Re: [openstack-dev] [neutron][lbaas] - Heat support for LbaasV2

[Stephen Balukoff]

   > > Hi All,
>>> > > > > I was thinking of
>>> > starting the work on
>>> > > heat to support
>>> > > > LBaasV2,  Is
>>> > > > > there any concerns about
>>> > that?
>>> > > > >
>>> > > > >
>>> > > > > I don't know if it is
>>> > the right time to
>>> > > bring this up :D .
>>> > > > >
>>> > > > > Thanks,
>>> > > > > Banashankar (bana_k)
>>> > > > >
>>> > > > >
>>> > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>> __
>>> > > > > 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
>>> > > >
>>> > > >
>>> > >
>>> >
>>> __
>>> > > > 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
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > >
>>> >
>>> __
>>> > > > 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
>>> > >
>>> > >
>>> >
>>> __
>>> > > 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
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> >
>>> __
>>> > > 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
>>> > >
>>> > >
>>> > >
>>> > >
>>> >
>>> __
>>> > > 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
>>> >
>>> >
>>> __
>>> > 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
>>> >
>>> >
>>> __
>>> > 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
>>> >
>>> >
>>> >
>>> >
>>> >
>>> __
>>> > 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
>>> >
>>> >
>>> >
>>> >
>>> __
>>> > 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
>>>
>>>
>>> __
>>> 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
>>>
>>>
>>> __
>>> 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
>>>
>>>
>>
>> __
>> 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
>>
>>
>
> __
> 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
>
>


-- 
Stephen Balukoff
Principal Technologist
Blue Box, An IBM Company
www.blueboxcloud.com
sbaluk...@blueboxcloud.com
206-607-0660 x807
__
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

Re: [openstack-dev] custom lbaas driver

[Stephen Balukoff]

Srikumar--

I'm not aware of any particular write-up. The best advice I have is to
start with the logging noop driver and refer to the reference haproxy
namespace driver to see what these are doing to implement the functionality
of LBaaS v2.

Sorry! I wish I had better news for you.

Stephen

On Fri, Sep 4, 2015 at 10:36 AM, Srikumar Chari <sriku...@appcito.net>
wrote:

> Hello,
>
> I am trying to write an custom lbaas v2.0 driver. Was wondering if there's
> a document on how to go about that. I see a number of implementations as
> part of the source code but they all seem to be different. For instance
> HAProxy is completely different when compared to the other vendors. I am
> assuming that HAProxy is the "standard" as it is the default load balancer
> for OpenStack. Is there a design doc or some kinda write up?
>
> This thread was the closest I could get to a write-up:
> https://openstack.nimeyo.com/21628/openstack-dev-neutron-lbaas-need-help-with-lbaas-drivers
> .
>
> I guess I could reverse engineering the HAProxy namespace driver but I am
> probably going to miss some of the design elements. 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-bin/mailman/listinfo/openstack-dev
>
>


-- 
Stephen Balukoff
Principal Technologist
Blue Box, An IBM Company
www.blueboxcloud.com
sbaluk...@blueboxcloud.com
206-607-0660 x807
__
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

Re: [openstack-dev] [Octavia] Questions about the Octavia project

[Stephen Balukoff]

 in the specification there is talk of a 1 minute cache of
 security certificates.  How are you going to ensure that the cache will
 actually erase that cache after the 1 minute?  Also why cache them at
 all?  It seems to me to be a potential security risk


This is an obvious optimization for deploying a given user-supplied TLS
certificate across several amphorae in rapid succession. It's likely
initial versions of the code will not actually cache anything. Regardless,
it's pretty trivial to use something like memcache (or other volatile
storage) for this without significantly increasing any security risks.


 
 API:
 
 8. More a comment than a question.  There is talk of using Pecan+WSME.
 Libra had a 5K patch on top of WSME just to make it behave correctly with
 Pecan and correct JSON specifications in certain situations, judging by
 the planned API you will also hit those same situations.  I admit I¹ve
 not looked at WSME for a year and there was an effort to strip it out of
 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 entirely possible that we may run into
some of the issues you've vaguely alluded to here-- we would appreciate
your insight, eh!


 
 Many thanks for your time.
 
 Kind Regards
 --
 Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/
 
 


 ___
 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

Re: [openstack-dev] [Octavia] Questions about the Octavia project

[Stephen Balukoff]

Hi Andrew,

More responses inline:

On Wed, Jan 7, 2015 at 12:11 AM, Andrew Hutchings and...@linuxjedi.co.uk
wrote:

 Hi Phillip,

 Thanks for your response.

  On 6 Jan 2015, at 20:33, Phillip Toohill phillip.tooh...@rackspace.com
 wrote:
 
  Ill answer inline what I can, others can chime in to clear up anything
 and
  answer the rest.

 The reason I asked the questions I did is because I can’t find any OS the
 docs will actually compile on and it is difficult to find these answers
 trawling throw .dot and .rst files.  I’ve since found answers for a couple
 of them.

 I have several recommendations based on what I have read so far.  Such as
 not using Protobufs instead of JSON for the Amphorae-Controller
 configuration communication (I can go into lots of detail into why another
 time).  I very much like the HMAC-signed UDP messages idea though.


I think we defaulted to JSON because it's a well-understood way of
serializing data for use in a RESTful interface. I'm not familiar with
protobufs, and am willing to hear you out on reasons we should use it
instead of JSON-- but do note that what you're seeing is the result of some
hard-won compromises after extensive discussion, and we're *finally* (after
several months of this) getting to the point where we can
divide-and-conquer on this problem because we're achieving clarity and
consensus on what the components should be and how they should interface.
We're going to be resistant to changing certain details precisely because
we don't want to re-open cans of worms that we're just now getting sealed
shut-- so unless you've got some *really* compelling reasons here, we're
unlikely to want to change things at this 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
 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

[openstack-dev] [Octavia] Meetings canceled until Jan 7

[Stephen Balukoff]

Since we're in the middle of the Octavia hack-a-thon (and have been meeting
in person and online all week), it doesn't make sense for us to have an
Octavia meeting next week.

I also suggested holding Octavia meetings on Christmas Eve and New Year's
Eve (when the following two meetings 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!

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

Re: [openstack-dev] [Neutron] [RFC] Floating IP idea solicitation and collaboration

[Stephen Balukoff]

Hi Keshava,

For the purposes of Octavia, it's going to be service VMs (or containers or
what have you). However, service VM or tenant VM the concept is roughly
similar:  We need some kind of layer-3 routing capability which works
something like Neutron floating IPs (though not just a static NAT in this
case) but which can distribute traffic to a set of back-end VMs running on
a Neutron network according to some predictable algorithm (probably a
distributed hash).

The idea behind ACTIVE-ACTIVE is that you have many service VMs (we call
them amphorae) which service the same public IP in some way-- this allows
for horizontal scaling of services which need it (ie. anything which does
TLS termination with a significant amount of load).

Does this make sense to you?

Thanks,
Stephen


On Mon, Dec 8, 2014 at 9:56 PM, A, Keshava keshav...@hp.com wrote:

  Stephen,



 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:sbaluk...@bluebox.net]
 *Sent:* Tuesday, December 09, 2014 7:18 AM
 *To:* OpenStack Development Mailing List (not for usage questions)

 *Subject:* Re: [openstack-dev] [Neutron] [RFC] Floating IP idea
 solicitation and collaboration



 For what it's worth, I know that the Octavia project will need something
 which can do more advanced layer-3 networking in order to deliver and
 ACTIVE-ACTIVE topology of load balancing VMs / containers / machines.
 That's still a down the road feature for us, but it would be great to be
 able to do more advanced layer-3 networking in earlier releases of Octavia
 as well. (Without this, we might have to go through back doors to get
 Neutron to do what we need it to, and I'd rather avoid that.)



 I'm definitely up for learning more about your proposal for this project,
 though I've not had any practical experience with Ryu yet. I would also
 like to see whether it's possible to do the sort of advanced layer-3
 networking you've described without using OVS. (We have found that OVS
 tends to be not quite mature / stable enough for our needs and have moved
 most of our clouds to use ML2 / standard linux bridging.)



 Carl:  I'll also take a look at the two gerrit reviews you've linked. Is
 this week's L3 meeting not happening then? (And man-- I wish it were an
 hour or two later in the day. Coming at y'all from PST timezone here.)



 Stephen



 On Mon, Dec 8, 2014 at 11:57 AM, Carl Baldwin c...@ecbaldwin.net wrote:

 Ryan,

 I'll be traveling around the time of the L3 meeting this week.  My
 flight leaves 40 minutes after the meeting and I might have trouble
 attending.  It might be best to put it off a week or to plan another
 time -- maybe Friday -- when we could discuss it in IRC or in a
 Hangout.

 Carl


 On Mon, Dec 8, 2014 at 8:43 AM, Ryan Clevenger
 ryan.cleven...@rackspace.com wrote:
  Thanks for getting back Carl. I think we may be able to make this weeks
  meeting. Jason Kölker is the engineer doing all of the lifting on this
 side.
  Let me get with him to review what you all have so far and check our
  availability.
 
  
 
  Ryan Clevenger
  Manager, Cloud Engineering - US
  m: 678.548.7261
  e: ryan.cleven...@rackspace.com
 
  
  From: Carl Baldwin [c...@ecbaldwin.net]
  Sent: Sunday, December 07, 2014 4:04 PM
  To: OpenStack Development Mailing List
  Subject: Re: [openstack-dev] [Neutron] [RFC] Floating IP idea
 solicitation
  and collaboration
 
  Ryan,
 
  I have been working with the L3 sub team in this direction.  Progress has
  been slow because of other priorities but we have made some.  I have
 written
  a blueprint detailing some changes needed to the code to enable the
  flexibility to one day run glaring ups on an l3 routed network [1].
 Jaime
  has been working on one that integrates ryu (or other speakers) with
 neutron
  [2].  Dvr was also a step in this direction.
 
  I'd like to invite you to the l3 weekly meeting [3] to discuss further.
 I'm
  very happy to see interest in this area and have someone new to
 collaborate.
 
  Carl
 
  [1] https://review.openstack.org/#/c/88619/
  [2] https://review.openstack.org/#/c/125401/
  [3] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam
 
  On Dec 3, 2014 4:04 PM, Ryan Clevenger ryan.cleven...@rackspace.com
  wrote:
 
  Hi,
 
  At Rackspace, we have a need to create a higher level networking service
  primarily for the purpose of creating a Floating IP solution in our
  environment. The current solutions for Floating IPs, being tied to
 plugin
  implementations, does not meet our needs at scale for the following
 reasons:
 
  1. Limited endpoint H/A mainly targeting failover only and not
  multi-active endpoints,
  2. Lack of noisy neighbor and DDOS mitigation,
  3. IP fragmentation (with cells, public connectivity

Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use Cases that led us to adopt this.

[Stephen Balukoff]

So...  I should probably note that I see the case where a user actually
shares object as being the exception. I expect that 90% of deployments will
never need to share objects, except for a few cases--  those cases (of 1:N)
relationships are:

* Loadbalancers must be able to have many Listeners
* When L7 functionality is introduced, L7 policies must be able to refer to
the same Pool under a single Listener. (That is to say, sharing Pools under
the scope of a single Listener makes sense, but only after L7 policies are
introduced.)

I specifically see the following kind of sharing having near zero demand:

* Listeners shared across multiple loadbalancers
* Pools shared across multiple listeners
* Members shared across multiple pools

So, despite the fact that sharing doesn't make status reporting any more or
less complex, I'm still in favor of starting with 1:1 relationships between
most kinds of objects and then changing those to 1:N or M:N as we get user
demand for this. As I said in my first response, allowing too many many to
many relationships feels like a solution to a problem that doesn't really
exist, and introduces a lot of unnecessary complexity.

Stephen

On Sun, Dec 7, 2014 at 11:43 PM, Samuel Bercovici samu...@radware.com
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: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS -
 Use Cases that led us to adopt this.



 German-- but the point is that sharing apparently has no effect on the
 number of permutations for status information. The only difference here is
 that without sharing it's more work for the user to maintain and modify
 trees of objects.



 On Fri, Dec 5, 2014 at 9:36 AM, Eichberger, German 
 german.eichber...@hp.com 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



 *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net]
 *Sent:* Thursday, December 04, 2014 9:17 PM


 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS -
 Use Cases that led us to adopt this.



 Hi Brandon,



 Yeah, in your example, member1 could potentially have 8 different statuses
 (and this is a small example!)...  If that member starts flapping, it means
 that every time it flaps there are 8 notifications being passed upstream.



 Note that this problem actually doesn't get any better if we're not
 sharing objects but are just duplicating them (ie. not sharing objects but
 the user makes references to the same back-end machine as 8 different
 members.)



 To be honest, I don't see sharing entities at many levels like this being
 the rule for most of our installations-- maybe a few percentage points of
 installations will do an excessive sharing of members, but I doubt it. So
 really, even though reporting status like this is likely to generate a
 pretty big tree of data, I don't think this is actually a problem, eh. And
 I don't see sharing entities actually reducing the workload of what needs
 to happen behind the scenes. (It just allows us to conceal more of this
 work from the user.)



 Stephen







 On Thu, Dec 4, 2014 at 4:05 PM, Brandon Logan brandon.lo...@rackspace.com
 wrote:

 Sorry it's taken me a while to respond to this.

 So I wasn't thinking about this correctly.  I was afraid you would have
 to pass in a full tree of parent child representations to /loadbalancers
 to update anything a load balancer it is associated to (including down
 to members).  However, after thinking about it, a user would just make
 an association call on each object.  For Example, associate member1 with
 pool1, associate pool1 with listener1, then associate loadbalancer1 with
 listener1.  Updating is just as simple as updating each entity.

 This does bring up another problem though.  If a listener can live on
 many load balancers, and a pool can live on many listeners, and a member
 can live on many pools, there's lot of permutations to keep track of for
 status.  you can't just link a member's status to a load balancer bc a
 member can exist on many pools under that load balancer, and each pool
 can exist under many listeners under that load balancer.  For example,
 say I have these:

 lb1
 lb2
 listener1
 listener2
 pool1
 pool2
 member1
 member2

 lb1 - [listener1, listener2]
 lb2 - [listener1]
 listener1 - [pool1, pool2]
 listener2 - [pool1]
 pool1 - [member1, member2]
 pool2 - [member1]

 member1 can now have a different statuses under pool1 and pool2.  since
 listener1 and listener2 both have pool1, this means member1 will now
 have a different status for listener1 - pool1 and listener2 - pool2
 combination.  And so forth

Re: [openstack-dev] [Neutron] [RFC] Floating IP idea solicitation and collaboration

[Stephen Balukoff]

. If a particular
  floating ip is experiencing unusually large traffic (DDOS, slashdot
 effect,
  etc.), the Ryu application could change the announcements up to the
 Public
  layer to shift that traffic to dedicated hosts setup for that purpose.
 It
  also announces a single /32 Tunnel Endpoint ip downstream to the
 TunnelNet
  Routing system which provides transit to and from the cells and their
  hypervisors. Since traffic from either direction can then end up on any
 of
  the FLIP hosts, a simple flow table to modify the MAC and IP in either
 the
  SRC or DST fields (depending on traffic direction) allows the system to
 be
  completely stateless. We have proven this out (with static routing and
  flows) to work reliably in a small lab setup.
 
  On the hypervisor side, we currently plumb networks into separate OVS
  bridges. Another Ryu application would control the bridge that handles
  overlay networking to selectively divert traffic destined for the
 default
  gateway up to the FLIP NAT systems, taking into account any configured
  logical routing and local L2 traffic to pass out into the existing
 overlay
  fabric undisturbed.
 
  Adding in support for L2VPN EVPN
  (https://tools.ietf.org/html/draft-ietf-l2vpn-evpn-11) and 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, live-migrate, and supported encapsulation types. We believe
 that
  decoupling the tunnel endpoint discovery from the control plane
  (Nova/Neutron) will provide for a more robust solution as well as allow
 for
  use outside of openstack if desired.
 
  
 
  Ryan Clevenger
  Manager, Cloud Engineering - US
  m: 678.548.7261
  e: ryan.cleven...@rackspace.com
 
 
  ___
  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

Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use Cases that led us to adopt this.

[Stephen Balukoff]

German-- but the point is that sharing apparently has no effect on the
number of permutations for status information. The only difference here is
that without sharing it's more work for the user to maintain and modify
trees of objects.

On Fri, Dec 5, 2014 at 9:36 AM, Eichberger, German german.eichber...@hp.com
 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



 *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net]
 *Sent:* Thursday, December 04, 2014 9:17 PM

 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS -
 Use Cases that led us to adopt this.



 Hi Brandon,



 Yeah, in your example, member1 could potentially have 8 different statuses
 (and this is a small example!)...  If that member starts flapping, it means
 that every time it flaps there are 8 notifications being passed upstream.



 Note that this problem actually doesn't get any better if we're not
 sharing objects but are just duplicating them (ie. not sharing objects but
 the user makes references to the same back-end machine as 8 different
 members.)



 To be honest, I don't see sharing entities at many levels like this being
 the rule for most of our installations-- maybe a few percentage points of
 installations will do an excessive sharing of members, but I doubt it. So
 really, even though reporting status like this is likely to generate a
 pretty big tree of data, I don't think this is actually a problem, eh. And
 I don't see sharing entities actually reducing the workload of what needs
 to happen behind the scenes. (It just allows us to conceal more of this
 work from the user.)



 Stephen







 On Thu, Dec 4, 2014 at 4:05 PM, Brandon Logan brandon.lo...@rackspace.com
 wrote:

 Sorry it's taken me a while to respond to this.

 So I wasn't thinking about this correctly.  I was afraid you would have
 to pass in a full tree of parent child representations to /loadbalancers
 to update anything a load balancer it is associated to (including down
 to members).  However, after thinking about it, a user would just make
 an association call on each object.  For Example, associate member1 with
 pool1, associate pool1 with listener1, then associate loadbalancer1 with
 listener1.  Updating is just as simple as updating each entity.

 This does bring up another problem though.  If a listener can live on
 many load balancers, and a pool can live on many listeners, and a member
 can live on many pools, there's lot of permutations to keep track of for
 status.  you can't just link a member's status to a load balancer bc a
 member can exist on many pools under that load balancer, and each pool
 can exist under many listeners under that load balancer.  For example,
 say I have these:

 lb1
 lb2
 listener1
 listener2
 pool1
 pool2
 member1
 member2

 lb1 - [listener1, listener2]
 lb2 - [listener1]
 listener1 - [pool1, pool2]
 listener2 - [pool1]
 pool1 - [member1, member2]
 pool2 - [member1]

 member1 can now have a different statuses under pool1 and pool2.  since
 listener1 and listener2 both have pool1, this means member1 will now
 have a different status for listener1 - pool1 and listener2 - pool2
 combination.  And so forth for load balancers.

 Basically there's a lot of permutations and combinations to keep track
 of with this model for statuses.  Showing these in the body of load
 balancer details can get quite large.

 I hope this makes sense because my brain is ready to explode.

 Thanks,
 Brandon


 On Thu, 2014-11-27 at 08:52 +, Samuel Bercovici wrote:
  Brandon, can you please explain further (1) bellow?
 
  -Original Message-
  From: Brandon Logan [mailto:brandon.lo...@rackspace.com]
  Sent: Tuesday, November 25, 2014 12:23 AM
  To: openstack-dev@lists.openstack.org
  Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS -
 Use Cases that led us to adopt this.
 
  My impression is that the statuses of each entity will be shown on a
 detailed info request of a loadbalancer.  The root level objects would not
 have any statuses.  For example a user makes a GET request to
 /loadbalancers/{lb_id} and the status of every child of that load balancer
 is show in a status_tree json object.  For example:
 
  {name: loadbalancer1,
   status_tree:
{listeners:
  [{name: listener1, operating_status: ACTIVE,
default_pool:
  {name: pool1, status: ACTIVE,
   members:
 [{ip_address: 10.0.0.1, status: OFFLINE}]}}
 
  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 require a full tree, it means

Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use Cases that led us to adopt this.

[Stephen Balukoff]

Hi Brandon,

Yeah, in your example, member1 could potentially have 8 different statuses
(and this is a small example!)...  If that member starts flapping, it means
that every time it flaps there are 8 notifications being passed upstream.

Note that this problem actually doesn't get any better if we're not sharing
objects but are just duplicating them (ie. not sharing objects but the user
makes references to the same back-end machine as 8 different members.)

To be honest, I don't see sharing entities at many levels like this being
the rule for most of our installations-- maybe a few percentage points of
installations will do an excessive sharing of members, but I doubt it. So
really, even though reporting status like this is likely to generate a
pretty big tree of data, I don't think this is actually a problem, eh. And
I don't see sharing entities actually reducing the workload of what needs
to happen behind the scenes. (It just allows us to conceal more of this
work from the user.)

Stephen



On Thu, Dec 4, 2014 at 4:05 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:

 Sorry it's taken me a while to respond to this.

 So I wasn't thinking about this correctly.  I was afraid you would have
 to pass in a full tree of parent child representations to /loadbalancers
 to update anything a load balancer it is associated to (including down
 to members).  However, after thinking about it, a user would just make
 an association call on each object.  For Example, associate member1 with
 pool1, associate pool1 with listener1, then associate loadbalancer1 with
 listener1.  Updating is just as simple as updating each entity.

 This does bring up another problem though.  If a listener can live on
 many load balancers, and a pool can live on many listeners, and a member
 can live on many pools, there's lot of permutations to keep track of for
 status.  you can't just link a member's status to a load balancer bc a
 member can exist on many pools under that load balancer, and each pool
 can exist under many listeners under that load balancer.  For example,
 say I have these:

 lb1
 lb2
 listener1
 listener2
 pool1
 pool2
 member1
 member2

 lb1 - [listener1, listener2]
 lb2 - [listener1]
 listener1 - [pool1, pool2]
 listener2 - [pool1]
 pool1 - [member1, member2]
 pool2 - [member1]

 member1 can now have a different statuses under pool1 and pool2.  since
 listener1 and listener2 both have pool1, this means member1 will now
 have a different status for listener1 - pool1 and listener2 - pool2
 combination.  And so forth for load balancers.

 Basically there's a lot of permutations and combinations to keep track
 of with this model for statuses.  Showing these in the body of load
 balancer details can get quite large.

 I hope this makes sense because my brain is ready to explode.

 Thanks,
 Brandon

 On Thu, 2014-11-27 at 08:52 +, Samuel Bercovici wrote:
  Brandon, can you please explain further (1) bellow?
 
  -Original Message-
  From: Brandon Logan [mailto:brandon.lo...@rackspace.com]
  Sent: Tuesday, November 25, 2014 12:23 AM
  To: openstack-dev@lists.openstack.org
  Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS -
 Use Cases that led us to adopt this.
 
  My impression is that the statuses of each entity will be shown on a
 detailed info request of a loadbalancer.  The root level objects would not
 have any statuses.  For example a user makes a GET request to
 /loadbalancers/{lb_id} and the status of every child of that load balancer
 is show in a status_tree json object.  For example:
 
  {name: loadbalancer1,
   status_tree:
{listeners:
  [{name: listener1, operating_status: ACTIVE,
default_pool:
  {name: pool1, status: ACTIVE,
   members:
 [{ip_address: 10.0.0.1, status: OFFLINE}]}}
 
  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 require a full tree, it means the user would have to know the
 full tree configuration just to simply update a name.  Solving this would
 require nested child resources in the URL, which the current neutron
 extension/plugin does not allow.  Maybe the new one will.
 
  2) The status_tree can get quite large depending on the number of
 listeners and pools being used.  This is a minor issue really as it will
 make horizon's (or any other UI tool's) job easier to show statuses.
 
  Thanks,
  Brandon
 
  On Mon, 2014-11-24 at 12:43 -0800, Stephen Balukoff wrote:
   Hi Samuel,
  
  
   We've actually been avoiding having a deeper discussion about status
   in Neutron LBaaS since this can get pretty hairy as the back-end
   implementations get more complicated. I suspect managing that is
   probably one of the bigger reasons we have disagreements around object
   sharing. Perhaps it's time we discussed

Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use Cases that led us to adopt this.

[Stephen Balukoff]

Hi Samuel,

We've actually been avoiding having a deeper discussion about status in
Neutron LBaaS since this can get pretty hairy as the back-end
implementations get more complicated. I suspect managing that is probably
one of the bigger reasons we have disagreements around object sharing.
Perhaps it's time we discussed representing state correctly (whatever
that means), instead of a round-a-bout discussion about object sharing
(which, I think, is really just avoiding this issue)?

Do you have a proposal about how status should be represented (possibly
including a description of the state machine) if we collapse everything
down to be logical objects except the loadbalancer object? (From what
you're proposing, I suspect it might be too general to, for example,
represent the UP/DOWN status of members of a given pool.)

Also, from an haproxy perspective, sharing pools within a single listener
actually isn't a problem. That is to say, having the same L7Policy pointing
at the same pool is OK, so I personally don't have a problem allowing
sharing of objects within the scope of parent objects. What do the rest of
y'all think?

Stephen


On Sat, Nov 22, 2014 at 11:06 PM, Samuel Bercovici samu...@radware.com
wrote:

  Hi Stephen,



 1.   The issue is that if we do 1:1 and allow status/state to
 proliferate throughout all objects we will then get an issue to fix it
 later, hence even if we do not do sharing, I would still like 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.







 *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net]
 *Sent:* Friday, November 21, 2014 10:26 PM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS -
 Use Cases that led us to adopt this.



 I think the idea was to implement 1:1 initially to reduce the amount of
 code and operational complexity we'd have to deal with in initial revisions
 of LBaaS v2. Many to many can be simulated in this scenario, though it does
 shift the burden of maintenance to the end user. It does greatly simplify
 the initial code for v2, in any case, though.



 Did we ever agree to allowing listeners to be shared among load
 balancers?  I think that still might be a N:1 relationship even in our
 latest models.



 There's also the difficulty introduced by supporting different flavors:
  Since flavors are essentially an association between a load balancer
 object and a driver (with parameters), once flavors are introduced, any
 sub-objects of a given load balancer objects must necessarily be purely
 logical until they are associated with a load balancer.  I know there was
 talk of forcing these objects to be sub-objects of a load balancer which
 can't be accessed independently of the load balancer (which would have much
 the same effect as what you discuss: State / status only make sense once
 logical objects have an instantiation somewhere.) However, the currently
 proposed API treats most objects as root objects, which breaks this
 paradigm.



 How we handle status and updates once there's an instantiation of these
 logical objects is where we start getting into real complexity.



 It seems to me there's a lot of complexity introduced when we allow a lot
 of many to many relationships without a whole lot of benefit in real-world
 deployment scenarios. In most cases, objects are not going to be shared,
 and in those cases with sufficiently complicated deployments in which
 shared objects could be used, the user is likely to be sophisticated enough
 and skilled enough to manage updating what are essentially copies of
 objects, and would likely have an opinion about how individual failures
 should be handled which wouldn't necessarily coincide with what we
 developers of the system would assume. That is to say, allowing too many
 many to many relationships feels like a solution to a problem that doesn't
 really exist, and introduces a lot of unnecessary complexity.



 In any case, though, I feel like we should walk before we run:
 Implementing 1:1 initially is a good idea to get us rolling. Whether we
 then implement 1:N or M:N after that is another question entirely. But in
 any case, it seems like a bad idea to try to start with M:N.



 Stephen





 On Thu, Nov 20, 2014 at 4:52 AM, Samuel Bercovici samu...@radware.com
 wrote:

 Hi,

 Per discussion I had at OpenStack Summit/Paris with Brandon and Doug, I
 would like to remind everyone why we choose to follow a model where pools
 and listeners are shared (many to many relationships).

 Use Cases:
 1. The same application is being exposed via different LB objects.
 For example: users coming from the internal private organization
 network, have an LB1(private_VIP) -- Listener1(TLS) --Pool1 and user

[openstack-dev] [Octavia] Meeting on Wednesday, Nov. 26th cancelled

[Stephen Balukoff]

Hi folks!

Since:

* The agenda contains no earth-shattering updates (ie. just going over
review progress)
* Nearly all the people working on Octavia are US-based
* The meeting is in the afternoon for most folks
* Wednesday is the day before a long holiday weekend and many employers
give their 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-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use Cases that led us to adopt this.

[Stephen Balukoff]

 be hierarchical so that logical object attached to an
 LB, would have their status consumed out of the LB object itself (in case
 of an error).
 We also need to discuss how modifications of a logical object will be
 rendered 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 v1 model
 as a reference.

 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

Re: [openstack-dev] [neutron][lbaas] meeting day/time change

[Stephen Balukoff]

Awesome!

On Mon, Nov 10, 2014 at 9:10 AM, Susanne Balle sleipnir...@gmail.com
wrote:

 Works for me. Susanne

 On Mon, Nov 10, 2014 at 10:57 AM, Brandon Logan 
 brandon.lo...@rackspace.com wrote:

 https://wiki.openstack.org/wiki/Meetings#LBaaS_meeting

 That is updated for lbaas and advanced services with the new times.

 Thanks,
 Brandon

 On Mon, 2014-11-10 at 11:07 +, Doug Wiegley wrote:
  #openstack-meeting-4
 
 
   On Nov 10, 2014, at 10:33 AM, Evgeny Fedoruk evge...@radware.com
 wrote:
  
   Thanks,
   Evg
  
   -Original Message-
   From: Doug Wiegley [mailto:do...@a10networks.com]
   Sent: Friday, November 07, 2014 9:04 PM
   To: OpenStack Development Mailing List
   Subject: [openstack-dev] [neutron][lbaas] meeting day/time change
  
   Hi all,
  
   Neutron LBaaS meetings are now going to be Tuesdays at 16:00 UTC.
  
   Safe travels.
  
   Thanks,
   Doug
  
  
   ___
   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

 ___
 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

Re: [openstack-dev] [Octavia] Mid-cycle hack-a-thon

[Stephen Balukoff]

I have just learned that there will be a Neutron hack-a-thon the week of
Dec 8 in Salt Lake City. Since we don't want to conflict with that, I would
like to do the Octavia hack-a-thon the previous week: Dec. 1 through 5 in
Seattle.
On Nov 5, 2014 11:05 PM, Adam Harwell adam.harw...@rackspace.com wrote:

   I can probably make it up there to attend.

   --Adam

  https://keybase.io/rm_you


   From: Stephen Balukoff sbaluk...@bluebox.net
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: Tuesday, November 4, 2014 3:46 AM
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [Octavia] Mid-cycle hack-a-thon

   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 toward our v0.5 milestone.

 If you are interested in attending, please e-mail me. If you are
 interested in participating but can't travel to Seattle that week, please
 also let me know, and we will see about using other means to collaborate
 with you in real time.

 Thanks!
 Stephen


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements

[Stephen Balukoff]

 Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Subject:  Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements


 Hi Jorge,
 
 Good discussion so far + glad to have you back
 J
 
 I am not a big fan of using logs for billing information since ultimately
 (at least at HP) we need to pump it into ceilometer. So I am envisioning
 either the
  amphora (via a proxy) to pump it straight into that system or we collect
 it on the controller and pump it from there.
 
 Allowing/enabling logging creates some requirements on the hardware,
 mainly, that they can handle 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
 
 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][Octavia] Usage Requirements
 
 
 
 Hey Stephen (and Robert),
 
 
 
 For real-time usage I was thinking something similar to what you are
 proposing. Using logs for this would be overkill IMO so your suggestions
 were what I was
  thinking of starting with.
 
 
 
 As far as storing logs is concerned I was definitely thinking of
 offloading these onto separate storage devices. Robert, I totally hear
 you on the scalability
  part as our current LBaaS setup generates TB of request logs. I'll start
 planning out a spec and then I'll let everyone chime in there. I just
 wanted to get a general feel for the ideas I had mentioned. I'll also
 bring it up in today's meeting.
 
 
 
 Cheers,
 
 --Jorge
 
 
 
 
 
 
 From:
 Stephen Balukoff sbaluk...@bluebox.net
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: Wednesday, October 22, 2014 4:04 AM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements
 
 
 
 Hi Jorge!
 
 
 
 Welcome back, eh! You've been missed.
 
 
 
 Anyway, I just wanted to say that your proposal sounds great to me, and
 it's good to finally be closer to having concrete requirements for
 logging, eh. Once this
  discussion is nearing a conclusion, could you write up the specifics of
 logging into a specification proposal document?
 
 
 
 Regarding the discussion itself: I think we can ignore UDP for now, as
 there doesn't seem to be high demand for it, and it certainly won't be
 supported in v 0.5
  of Octavia (and maybe not in v1 or v2 either, unless we see real
 demand).
 
 
 
 Regarding the 'real-time usage' information: I have some ideas regarding
 getting this from a combination of iptables and / or the haproxy stats
 interface. Were
  you thinking something different that involves on-the-fly analysis of
 the logs or something?  (I tend to find that logs are great for non-real
 time data, but can often be lacking if you need, say, a gauge like
 'currently open 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.
 
 
 
 Stephen
 
 
 
 On Wed, Oct 15, 2014 at 4:03 PM, Jorge Miramontes
 jorge.miramon...@rackspace.com wrote:
 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 reasons:
 
 1) We can use these logs as the raw and granular data needed to track
 usage. With logs, the operator has flexibility as to what usage metrics
 they want to bill against. For example, bandwidth is easy to track and
 can
 even be split into header and body data so that the provider can choose
 if
 they want to bill on header data or not. Also, the provider can determine
 if they will bill their customers for failed requests that were the fault
 of the provider themselves. These are just a few examples; the point is
 the flexible nature of logs.
 
 2) Creating billable usage from logs is easy compared to other options
 like polling. For example, in our current LBaaS iteration at Rackspace we
 bill partly on average concurrent connections. This is based on polling
 and is not as accurate as it possibly can be. It's very close, but it
 doesn't get more accurate that the logs themselves. Furthermore, polling
 is more complex and uses up resources on the polling cadence.
 
 3) Enabling logs for all load balancers can be used for debugging,
 support
 and audit purposes. While

Re: [openstack-dev] [Octavia] Mid-cycle hack-a-thon

[Stephen Balukoff]

Adam: I've heard from multiple people that the following week is worse for
their schedules.

Susanne: I was hoping for 5 days of coding. But if you can't make it for
all of that, we'll take what we can get, eh. :)

On Thu, Nov 6, 2014 at 8:09 AM, Susanne Balle sleipnir...@gmail.com wrote:

 Are we 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 adam.harw...@rackspace.com
 wrote:

  Any chance it could actually be the week AFTER? Or is that to close to
 the holidays? _
 On Nov 6, 2014 7:21 AM, Stephen Balukoff sbaluk...@bluebox.net wrote:

 I have just learned that there will be a Neutron hack-a-thon the week of
 Dec 8 in Salt Lake City. Since we don't want to conflict with that, I would
 like to do the Octavia hack-a-thon the previous week: Dec. 1 through 5 in
 Seattle.
 On Nov 5, 2014 11:05 PM, Adam Harwell adam.harw...@rackspace.com
 wrote:

   I can probably make it up there to attend.

   --Adam

  https://keybase.io/rm_you


   From: Stephen Balukoff sbaluk...@bluebox.net
 Reply-To: OpenStack Development Mailing List (not for usage
 questions) openstack-dev@lists.openstack.org
 Date: Tuesday, November 4, 2014 3:46 AM
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [Octavia] Mid-cycle hack-a-thon

   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 toward our v0.5 milestone.

 If you are interested in attending, please e-mail me. If you are
 interested in participating but can't travel to Seattle that week, please
 also let me know, and we will see about using other means to collaborate
 with you in real time.

 Thanks!
 Stephen


 ___
 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

[openstack-dev] [Octavia] Mid-cycle hack-a-thon

[Stephen Balukoff]

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 toward our v0.5 milestone.

If you are interested in attending, please e-mail me. If you are interested
in participating but can't travel to Seattle that week, please also let me
know, and we will see about using other means to collaborate with you in
real time.

Thanks!
Stephen
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

[Stephen Balukoff]

+1 to this, eh!

Though it sounds more like you're talking about spinning the Octavia user
API out of Octavia to become it's own thing (ie. Openstack LBaaS), and
then ensuring a standardized driver interface that vendors (including
Octavia) will interface with. It's sort of a half-dozen of one, six of the
other kind of deal.

To the pros, I would add:  Spin out from Neutron ensures that LBaaS uses
clean interfaces to the networking layer, and separation of concerns here
means that Neutron and LBaaS can evolve independently. (And testing and
failure modes, etc. all become easier with separation of concerns.)

One other thing to consider (not sure if pro or con): I know at Atlanta
there was a lot of talk around using the Neutron flavor framework to allow
for multiple vendors in a single installation as well as differentiated
product offerings for Operators. If / when LBaaS is spun out of Neutron,
LBaaS will still probably have need for something like Neutron flavors,
even if it isn't an equivalent implementation. (Noting of course, that no
implementation of Neutron flavors actually presently exists. XD )

Stephen


On Fri, Oct 24, 2014 at 2:47 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:

 With the recent talk about advanced services spinning out of Neutron,
 and the fact most of the LBaaS community has wanted LBaaS to spin out of
 Neutron, I wanted to bring up a possibility and gauge interest and
 opinion on this possibility.

 Octavia is going to (and has) an API.  The current thinking is that an
 Octavia driver will be created in Neutron LBaaS that will make a
 requests to the Octavia API.  When LBaaS spins out of Neutron, it will
 need a standalone API.  Octavia's API seems to be a good solution to
 this.  It will support vendor drivers much like the current Neutron
 LBaaS does.  It has a similar API as Neutron LBaaS v2, but its not an
 exact duplicate.  Octavia will be growing more mature in stackforge at a
 higher velocity than an Openstack project, so I expect by the time Kilo
 comes around it's API will be very mature.

 Octavia's API doesn't have to be called Octavia either.  It can be
 separated out and it can be called Openstack LBaaS, and the rest of
 Octavia (the actual brains of it) will just be another driver to
 Openstack LBaaS, which would retain the Octavia name.

 This is my PROS and CONS list to using Octavia's API as the spun out
 LBaaS:

 PROS
 1. Time will need to be spent on a spun out LBaaS's API anyway.  Octavia
 will already have this done.
 2. Most of the same people working on Octavia have worked on Neutron
 LBaaS v2.
 3. It's out of Neutron faster, which is good for Neutron and LBaaS.

 CONS
 1. The Octavia API is dissimilar enough from Neutron LBaaS v2 to be yet
 another version of an LBaaS API.
 2. The Octavia API will also have a separate Operator API which will
 most likely only work with Octavia, not any vendors.

 The CONS are easily solvable, and IMHO the PROS greatly outweigh the
 CONS.

 This is just my opinion though and I'd like to hear back from as many as
 possible.  Add on 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,
 Brandon
 ___
 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

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements

[Stephen Balukoff]

 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
 happened and when.


 Cheers,
 --Jorge


 ___
 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

Re: [openstack-dev] [Octavia] Octavia Weekly Standup Reminder

[Stephen Balukoff]

Thanks Trevor!

The URL for that is here:
https://etherpad.openstack.org/p/octavia-weekly-standup

Also, the agenda for today's Octavia meeting is here (feel free to add
pertinent topics):
https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Agenda

Stephen

On Wed, Oct 8, 2014 at 9:18 AM, Trevor Vardeman 
trevor.varde...@rackspace.com wrote:

 Hey all!

 Friendly reminder to throw a little info in the Standup for this week
 before the meeting this afternoon.

 -Trevor

 PS.  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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Weekly Octavia meeting (2014-10-01)

[Stephen Balukoff]

Hi Folks!

Since I had to miss last week's meeting due to a last minute emergency, and
since it seems there was significant confusion over some of the items I had
added to last week's agenda, this week's agenda will actually be
essentially the same thing as last week's. Here's what we've got on tap:


   - Review progress on action items from last week
   - From blogan: Neutron lbaas v1 and v2 right now creates a neutron port
   before passing any control to the driver, we need to decide how Octavia is
   going to handle that
   - Discuss any outstanding blockers
   - Review status on outstanding gerrit reviews
   - Review list of blueprints, assign people to specific blueprints and/or
   tasks



Please feel free to add additional agenda items here:
https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Agenda

If you've been working on 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
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

Re: [openstack-dev] [Octavia] Thoughts on launchpad usage

[Stephen Balukoff]

I forgot to add to the etiquette section:

*Before doing work on an assigned blueprint, coordinate with the assignee*
This can help to make sure you aren't wasting time by duplicating efforts
already underway.


(Hmmm... starting to thinks I should add this to a wiki page...)

Stephen

On Wed, Sep 24, 2014 at 11:56 PM, Stephen Balukoff sbaluk...@bluebox.net
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 meeting that I've
 done a poor job of communicating what my intentions are, as far as what I'm
 doing for managing blueprints in launchpad. Y'all did notice that I'd added
 probably around a dozen new blueprints last night, and updated *all* the
 other blueprints with various tweaks-- and unfortunately wasn't around to
 explain my intentions during the meeting. So hey! Now y'all get another
 book to read by me. I apologize in advance.

 First off, let me say that I'm not a fan of the launchpad blueprint
 system, and have a hard time understanding its usefulness over, say, a text
 file or etherpad for tracking task lists and progress. In my opinion,
 launchpad has too much detail and functionality in areas that are not
 useful, and not enough in areas that actually would be useful. I could rant
 for a while on a lot of specific things launchpad gets wrong... but suffice
 to say I'm really looking forward to a transition to Storyboard (though I'm
 being told it's not the right time for us to start using that tool yet,
 dangit!). Perhaps launchpad is useful for projects that are relatively
 stable and established, or useful where volume of contribution necessitates
 more formal processes. Octavia definitely isn't that yet (and I would
 argue, very few of the existing OpenStack and Stackforge projects appear to
 be, IMO).

 (For the record, yes I am aware of this:
 https://wiki.openstack.org/wiki/Blueprints )

 So, having said this, please note that in using this tool to manage
 software and feature development in Octavia, my primary goals are as
 follows:

 *Keep a prioritized list of everything that needs to be accomplished to
 deliver v0.5*
 (And later, v1.0 and v2.0). This list is divided up into logical topics or
 areas (I'm using blueprints for this) which should contain smaller task
 lists (in the Work Items areas of the blueprints). Since there are still
 a significant number of architectural details to work out (ex. amphora
 lifecycle management), this means some blueprints are not so much about
 coding as they are about design and discussion, followed by documentation.
 Code will likely happen in one or more other blueprints. Also, some
 blueprints might be other non-design or non-coding tasks that need to be
 done in a coordinated way (ex. Do whatever we can to get Neutron LBaaS v2
 into Neutron.)

 The point here is that by tracking everything that needs to happen, a
 complete path from where we are to where we want to be emerges (and gets
 refined and updated, as we make progress, learn more and/or encounter
 obstacles).

 *Indicate who is working on what*
 This is both so that I know who is working on the most important things,
 and so that others contributing know who they should talk to if they want
 to get involved in or need to talk about a specific topic or area.

 *Keep a rough estimate of progress on any given topic*
 For what it's worth, I consider an implementation started when there's
 been a significant amount of work done on it that you can share (which
 includes specs). Heck, as we develop some of these features, specs are
 likely to change anyway. Keeping the Work Items up to date is probably
 the quickest way to provide some detail beyond that.

 *Try to make it obvious where attention is needed*
 Unfortunately, unless everyone is almost religiously using launchpad to
 keep blueprint information up-to-date, then this is difficult to accomplish
 with this tool. At best, a prioritized task list is a good place to start,
 and using the 'blocked' progress indicator can help (when blocked).

 *Try to make things as self-serve as possible*
 I hate being a bottleneck in the process, so the more I can get out of the
 way so people can get work done, the better. Ideally, this project should
 not be dependent on any single person in order to make progress at any
 stage in the game.

 This also means if you're working on a blueprint, try to keep good notes
 in the description, whiteboard, etc. so anyone can see what's going on with
 the blueprint. Links to other resources are less desirable (since following
 them off the launchpad site is distracting and disruptive), but are often
 necessary, especially when linking to what will become permanent
 documentation.

 ...

 Anyway, having said my intentions above, let me suggest the following as
 far as etiquette is concerned (please feel free to object to / discuss
 these things of course

[openstack-dev] [Octavia] Weekly meeting agenda

[Stephen Balukoff]

Hi Folks!

Please note that the IRC channel for the weekly Octavia meeting has changed
(see below)!

We've got the following agenda for tomorrow's Octavia meeting, so far:

   - Review progress on action items from last week
   - From blogan: Neutron lbaas v1 and v2 right now creates a neutron port
   before passing any control to the driver, we need to decide how Octavia is
   going to handle that
   - Discuss any outstanding blockers
   - Review status on outstanding gerrit reviews
   - Review list of blueprints, assign people to specific blueprints and/or
   tasks


Please feel free to add additional agenda items here:
https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Agenda

If you've been working on 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
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

Re: [openstack-dev] [Octavia] Responsibilities for controller drivers

[Stephen Balukoff]

Hi Brandon!

My responses in-line:

On Fri, Sep 12, 2014 at 11:27 AM, Brandon Logan brandon.lo...@rackspace.com
 wrote:

 IN IRC the topic came up about supporting many-to-many load balancers to
 amphorae.  I believe a consensus was made that allowing only one-to-many
 load balancers to amphorae would be the first step forward, and
 re-evaluate later, since colocation and apolocation will need to work
 (which brings up another topic, defining what it actually means to be
 colocated: On the same amphorae, on the same amphorae host, on the same
 cell/cluster, on the same data center/availability zone. That should be
 something we discuss later, but not right now).

 I am fine with that decisions, but Doug brought up a good point that
 this could very well just be a decision for the controller driver and
 Octavia shouldn't mandate this for all drivers.  So I think we need to
 clearly define what decisions are the responsibility of the controller
 driver versus what decisions are mandated by Octavia's construct.


In my mind, the only thing dictated by the controller to the driver here
would be things related to colocation / apolocation. So in order to fully
have that discussion here, we first need to have a conversation about what
these things actually mean in the context of Octavia and/or get specific
requirements from operators here.  The reference driver (ie. haproxy
amphora) will of course have to follow a given behavior here as well, and
there's the possibility that even if we don't dictate behavior in one way
or another, operators and users may come to expect the behavior of the
reference driver here to become the defacto requirements.



 Items I can come up with off the top of my head:

 1) LB:Amphora - M:N vs 1:N


My opinion:  For simplicity, first revision should be 1:N, but leave open
the possibility of M:N at a later date, depending on what people require.
That is to say, we'll only do 1:N at first so we can have simpler
scheduling algorithms for now, but let's not paint ourselves into a corner
in other portions of the code by assuming there will only ever be one LB on
an amphora.


 2) VIPs:LB - M:N vs 1:N


So, I would revise that to be N:1 or 1:1. I don't think we'll ever want to
support a case where multiple LBs share the same VIP. (Multiple amphorae
per VIP, yes... but not multiple LBs per VIP. LBs are logical constructs
that also provide for good separation of concerns, particularly around
security.)

The most solid use case for N:1 that I've heard is the IPv6 use case, where
a user wants to expose the exact same services over IPv4 and IPv6, and
therefore it makes sense to be able to have multiple VIPs per load
balancer. (In fact, I'm not aware of other use cases here that hold any
water.) Having said this, we're quite a ways from IPv6 being ready for use
in the underlying networking infrastructure.  So...  again, I would say
let's go with 1:1 for now to make things simple for scheduling, but not
paint ourselves into a corner here architecturally in other areas of the
code by assuming there will only ever be one VIP per LB.

3) Pool:HMs - 1:N vs 1:1


Does anyone have a solid use case for having more than one health monitor
per pool?  (And how do you resolve conflicts in health monitor check
results?)  I can't think of one, so 1:1 has my vote here.




 I'm sure there are others.  I'm sure each one will need to be evaluated
 on a case-by-case basis.  We will 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 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

Re: [openstack-dev] [Octavia] Question about where to render haproxy configurations

[Stephen Balukoff]

 additional
drivers, it may become more obvious whether it makes sense to support one
driver per controller or multiple drivers per controller (we're a ways off
from needing to worry too much about that right now anyway). But if we try
to keep the interface between the driver and controller clean, we should be
in a good spot to do either.

I think the crux of this discussion is going to really be determined around
our recommended upgrade path for controllers and amphorae (which, again, we
haven't really discussed in depth, and which probably deserves its own
thread when we get to the point that having a recommended process there
becomes pertinent.)



 I do recognize your worry about the many permutations that could arise
 from having a controller driver version and an amphora version.  I might
 be short-sighted or just blind to it, but would you be testing an nginx
 controller driver against an haproxy amphora?  That shouldn't work, and
 thus I don't see why you would want to test that.  So the only other
 option is testing (as an example) an haproxy 1.5 controller driver with
 amphorae that may have different versions of code, scripts, ancillary
 applications, and/or haproxy.  So its possible there could be N number
 of amphorae running haproxy 1.5, if you are planning on keeping older
 versions around.  You would need to test the haproxy 1.5 controller
 driver against N amphorae versions.  Obviously if we are allowing
 multiple versions of haproxy controller drivers, then we'd have to test
 N controller drivers against N amphorae versions.  Correct me if I am
 interpreting your versioning issue incorrectly.


I'm hoping we can come up with an upgrade workflow that encourages expiring
and recycling obsolete-versioned amphorae in a relatively quick, seamless,
and low-risk way. I *think* this will be possible, but again, we need to
discuss this more thoroughly (probably after we have at least one complete
concrete proposal for a solution here).

Just to point out, again: This is a very different problem from deciding
where we render haproxy configs. :) (Yes, not 100% unrelated, but still, I
think it deserves a different discussion.)


 I see this being a potential issue.  However, right now at least, I
 think the benefit of not having to update all amphorae in a deployment
 if we need to make a simple config rendering change outweighs this
 potential issue.  I feel like we will be doing a lot more of those
 changes rather than adding new haproxy version controller drivers.  Even
 when a new haproxy version is released, what are the odds that we would
 want to use it if what we already have works for what we need?  If what
 we already have doesn't, then we'd probably not use an old and busted
 controller and an old and busted amphora version.


If a new version of haproxy is released that is backward-incompatible with
previous releases, we'd probably be developing a new, separate driver for
it anyway. Same goes if it is backward-compatible but exposes a plethora of
new features we want to take advantage of that haproxy 1.5 can't do.

Seeing how long it took them to release haproxy 1.5 as stable, I don't
think this is going to be a problem we have to worry about for a long time.
:)



 That's my take on it currently.  It is subject to change of course.

 
 
  Lastly, I interpreted the word “VM driver” in the spec along the lines
  what we have in libra: A driver interface on the Amphora agent that
  abstracts starting/stopping the haproxy if we end up on some different
  and abstracts writing the haproxy file. But that is for the agent on
  the Amphora. I am sorry I got confused  that way when reading the 0.5
  spec and I am therefore happy we can have that discussion to make
  things more clear.

 I'm sure more things will come up that we've all made assumptions on and
 while reading the specs we read what we thought was what it said, but
 actually didn't.


It's very easy to miss details and even completely misunderstand certain
concepts or discussion points, both from lack of ability to convey 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

Re: [openstack-dev] [Octavia] Question about where to render haproxy configurations

[Stephen Balukoff]

 for
 all cases –


Ok, in this case, I think you're equivocating Octavia protocol with the
protocol the haproxy driver speaks to the haproxy-based amphorae, which I
think is the wrong way to think about this.

Also, how things are dealt with in the controller itself (ie. outside of
the drivers it loads) should necessarily be the same, no matter which
driver / back-end is used. I'm not in favor of a design which requires a
different controller for each kind of back-end. In that design, you'd need
to invent another controller-driver layer, or at least reduce 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
objects and protocols should happen in the controller's drivers.

I do have one other question for you or your team, German:

Is there something about rendering the haproxy configuration in the driver
which is a show-stopper (or major inconvenience) for HP's ability to use
this product? I'm trying to understand what exactly it is about shipping
rendered configuration files from the driver to the amphora that's so
distasteful to y'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

Re: [openstack-dev] [Octavia] Question about where to render haproxy configurations

[Stephen Balukoff]

 this workflow
should be handled, but it's actually somewhat secondary to the problem of
where to render the configs.  (Maybe we should have a conversation about
this in another thread?)

And in any case, I'm not seeing a need to ensure the driver works with
anything but the latest amphora image version to which it corresponds
(again, keeping in mind that amphora image and driver should be allowed to
change at different rates and are therefore versioned separately). :/ This
is especially the case if we define the 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

[openstack-dev] [Octavia] Question about where to render haproxy configurations

[Stephen Balukoff]

,
etc.) It's then
  up to the controller to render configurations appropriate to the software
  versions installed and/or to force an image to be retired in favor of
  spinning up a new one and/or return an error to the user trying
to push out
  a feature request for 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

Re: [openstack-dev] [neutron][lbaas][octavia]

[Stephen Balukoff]

Hi Kyle,

IMO, that depends entirely on how the incubator project is run. For now,
I'm in favor of remaining separate and letting someone else be the guinea
pig. :/  I think we'll (all) be more productive this way.

Also keep in mind that the LBaaS v2 code is mostly there (just waiting on
reviews), so it's probably going to be ready for neutron-incubator
incubation well before Octavia is ready for anything like that.

Stephen

On Tue, Sep 2, 2014 at 12:52 PM, Kyle Mestery mest...@mestery.com wrote:


 To me what makes sense here is that we merge the Octavia code into the
 neutron-incubator when the LBaaS V2 code is merged there. If the end
 goal is to spin the LBaaS V2 stuff out into a separate git repository
 and project (under the networking umbrella), this would allow for the
 Octavia driver to be developed alongside the V2 API code, and in fact
 help satisfy 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



-- 
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

Re: [openstack-dev] [Neutron][LBass] Design sessions for Neutron LBaaS. What do we want/need?

[Stephen Balukoff]

Hi Susanne--

Regarding the Octavia sessions:  I think we probably will have enough to
discuss that we could use two design sessions.  However, I also think that
we can probably come to conclusions on whether Octavia should become a part
of Neutron Incubator right away via discussion on this mailing list.  Do we
want to have that discussion in another thread, or should we use this one?

Stephen


On Thu, Aug 28, 2014 at 7:51 AM, Susanne Balle sleipnir...@gmail.com
wrote:

 With a corrected Subject. Susanne



 On Thu, Aug 28, 2014 at 10:49 AM, Susanne Balle sleipnir...@gmail.com
 wrote:


 LBaaS team,

 As we discussed in the Weekly LBaaS meeting this morning we should make
 sure we get the design sessions scheduled that we are interested in.

 We currently agreed on the following:

 * Neutron LBaaS. we want to schedule 2 sessions. I am assuming that we
 want to go over status and also the whole incubator thingy and how we will
 best move forward.

 * Octavia: We want to schedule 2 sessions.
 ---  During one of the sessions I would like to discuss the pros and cons
 of putting Octavia into the Neutron LBaaS incubator project right away. If
 it is going to be the reference implementation for LBaaS v 2 then I believe
 Octavia belong in Neutron LBaaS v2 incubator.

 * Flavors which should be coordinated with markmcclain and enikanorov.
 --- https://review.openstack.org/#/c/102723/

 Is this too many sessions given the constraints? I am assuming that we
 can also meet at the pods like we did at the last summit.

 thoughts?

 Regards Susanne

 Thierry Carrez thie...@openstack.org
 Aug 27 (1 day ago)
  to OpenStack
  Hi everyone,

 I've been thinking about what changes we can bring to the Design Summit
 format to make it more productive. I've heard the feedback from the
 mid-cycle meetups and would like to apply some of those ideas for Paris,
 within the constraints we have (already booked space and time). Here is
 something we could do:

 Day 1. Cross-project sessions / incubated projects / other projects

 I think that worked well last time. 3 parallel rooms where we can
 address top cross-project questions, discuss the results of the various
 experiments we conducted during juno. Don't hesitate to schedule 2 slots
 for discussions, so that we have time to come to the bottom of those
 issues. Incubated projects (and maybe other projects, if space allows)
 occupy the remaining space on day 1, and could occupy pods on the
 other days.

 Day 2 and Day 3. Scheduled sessions for various programs

 That's our traditional scheduled space. We'll have a 33% less slots
 available. So, rather than trying to cover all the scope, the idea would
 be to focus those sessions on specific issues which really require
 face-to-face discussion (which can't be solved on the ML or using spec
 discussion) *or* require a lot of user feedback. That way, appearing in
 the general schedule is very helpful. This will require us to be a lot
 stricter on what we accept there and what we don't -- we won't have
 space for courtesy sessions anymore, and traditional/unnecessary
 sessions (like my traditional release schedule one) should just move
 to the mailing-list.

 Day 4. Contributors meetups

 On the last day, we could try to split the space so that we can conduct
 parallel midcycle-meetup-like contributors gatherings, with no time
 boundaries and an open agenda. Large projects could get a full day,
 smaller projects would get half a day (but could continue the discussion
 in a local bar). Ideally that meetup would end with some alignment on
 release goals, but the idea is to make the best of that time together to
 solve the issues you have. Friday would finish with the design summit
 feedback session, for those who are still around.


 I think this proposal makes the best use of our setup: discuss clear
 cross-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 details to work out (is it possible split the space,
 should we use the usual design summit CFP website to organize the
 scheduled time...), but I would first like to have your feedback on
 this format. Also if you have alternative proposals that would make a
 better use of our 4 days, let me know.

 Cheers,



 ___
 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

Re: [openstack-dev] [Octavia] Using Nova Scheduling Affinity and AntiAffinity

[Stephen Balukoff]

I'm trying to think of a use case that wouldn't be satisfied using those
filters and am not coming up with anything. As such, I don't see a problem
using them to fulfill our requirements around colocation and apolocation.

Stephen


On Thu, Aug 28, 2014 at 1:13 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:

 Yeah we were looking at the SameHost and DifferentHost filters and that
 will probably do what we need.  Though I was hoping we could do a
 combination of both but we can make it work with those filters I
 believe.

 Thanks,
 Brandon

 On Thu, 2014-08-28 at 14:56 -0400, Susanne Balle wrote:
  Brandon
 
 
  I am not sure how ready that nova feature is for general use and have
  asked our nova lead about that. He is on vacation but should be back
  by the start of next week. I believe this is the right approach for us
  moving forward.
 
 
 
  We cannot make it mandatory to run the 2 filters but we can say in the
  documentation that if these two filters aren't set that we cannot
  guaranty Anti-affinity or Affinity.
 
 
  The other way we can implement this is by using availability zones and
  host aggregates. This is one technique we use to make sure we deploy
  our in-cloud services in an HA model. This also would assume that the
  operator is setting up Availabiltiy zones which we can't.
 
 
 
 http://blog.russellbryant.net/2013/05/21/availability-zones-and-host-aggregates-in-openstack-compute-nova/
 
 
 
  Sahara is currently using the following filters to support host
  affinity which is probably due to the fact that they did the work
  before ServerGroups. I am not advocating the use of those filters but
  just showing you that we can document the feature and it will be up to
  the operator to set it up to get the right behavior.
 
 
  Regards
 
 
  Susanne
 
 
 
  Anti-affinity
  One of the problems in Hadoop running on OpenStack is that there is no
  ability to control where machine is actually running. We cannot be
  sure that two new virtual machines are started on different physical
  machines. As a result, any replication with cluster is not reliable
  because all replicas may turn up on one physical machine.
  Anti-affinity feature provides an ability to explicitly tell Sahara to
  run specified processes on different compute nodes. This is especially
  useful for Hadoop datanode process to make HDFS replicas reliable.
  The Anti-Affinity feature requires certain scheduler filters to be
  enabled on Nova. Edit your/etc/nova/nova.conf in the following way:
 
  [DEFAULT]
 
  ...
 
  scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler
  scheduler_default_filters=DifferentHostFilter,SameHostFilter
  This feature is supported by all plugins out of the box.
 
 
  http://docs.openstack.org/developer/sahara/userdoc/features.html
 
 
 
 
 
  On Thu, Aug 28, 2014 at 1:26 AM, Brandon Logan
  brandon.lo...@rackspace.com wrote:
  Nova scheduler has ServerGroupAffinityFilter and
  ServerGroupAntiAffinityFilter which does the colocation and
  apolocation
  for VMs.  I think this is something we've discussed before
  about taking
  advantage of nova's scheduling.  I need to verify that this
  will work
  with what we (RAX) plan to do, but I'd like to get everyone
  else's
  thoughts.  Also, if we do decide this works for everyone
  involved,
  should we make it mandatory that the nova-compute services are
  running
  these two filters?  I'm also trying to see if we can use this
  to also do
  our own colocation and apolocation on load balancers, but it
  looks like
  it will be a bit complex if it can even work.  Hopefully, I
  can have
  something definitive on that soon.
 
  Thanks,
  Brandon
  ___
  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

Re: [openstack-dev] [neutron][lbaas][octavia]

[Stephen Balukoff]

On Thu, Aug 28, 2014 at 2:57 PM, Susanne Balle sleipnir...@gmail.com
wrote:

  I would like to discuss the pros and cons of putting Octavia into the
 Neutron LBaaS incubator project right away. If it is going to be the
 reference implementation for LBaaS v 2 then I believe Octavia belong in
 Neutron LBaaS v2 incubator.

 The Pros:
 * Octavia is in Openstack incubation right away along with the lbaas v2
 code. We do not have to apply for incubation later on.
 * As incubation project we have our own core and should be able ot commit
 our code
 * We are starting out as an OpenStack incubated project

 The Cons:
 * Not sure of the velocity of the project
 * Incubation not well defined.

 If Octavia starts as a 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.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

[openstack-dev] [Octavia] Agenda for tomorrow's meeting, where meeting is happening

[Stephen Balukoff]

Hello,

The current agenda for tomorrow's Octavia meeting is posted here:
https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Agenda

Please feel free to add agenda items as necessary.

Also, based on the poll Doug Wiegley created on where we should hold our
weekly meetings (IRC vs. webex), the result was a tie. So, the plan I am
going to follow at this point is to hold the next two meetings in IRC, and
then we can re-evaluate where the active participants in the group want to
be holding the weekly meetings. So again, the next Octavia meeting will be:

Wed, 27 Aug 2014 at 20:00 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/listinfo/openstack-dev

Re: [openstack-dev] [Octavia] Proposal to support multiple listeners on one HAProxy instance

[Stephen Balukoff]

 justifications. :)

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

Re: [openstack-dev] [Octavia] IRC meetings

[Stephen Balukoff]

Hi folks!

Responses in-line:

On Thu, Aug 21, 2014 at 10:26 AM, Stefano Maffulli stef...@openstack.org
wrote:

 On 08/21/2014 10:14 AM, Doug Wiegley wrote:
  We made the voice/IRC decision in the very format that favors voice.  So
  in the interest of putting the discussion to bed, voice your opinions
 here
  in a non-voice way:

 I was about to voice (ha!) my opinion there but I stopped because I
 don't think we should have that conversation to start with. Audio calls
 are ok for a lot of things but if we're talking about enabling an open
 collaboration then there is one rule to follow:

  - provide a URL with indexed, searchable text or it didn't happen


So, these have been sent to the mailing list, which I believe is both
indexed and searchable. But to help those new to the project just getting
up to speed (like yourself), I've transposed these to the wiki here:

https://wiki.openstack.org/wiki/Octavia/Meeting_Minutes



 My vote goes for the Octavia team to provide just that. If you have a
 way to do that with webex, hangout, anything fancy, use them. If not,
 consider revert to the minimum common 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!)

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

Re: [openstack-dev] [Octavia] Proposal to support multiple listeners on one HAProxy instance

[Stephen Balukoff]

Hi Dustin,

Responses in-line:



On Thu, Aug 21, 2014 at 1:56 PM, Dustin Lundquist dus...@null-ptr.net
wrote:

 I'm on the fence here, I see a number of advantages to each:

 Single HAProxy process per listener:

- Failure isolation
- TLS Performance -- for non TLS services HAProxy is IO bound, and
there is no reason to run it across multiple CPU cores, but with HAProxy
terminating TLS there is an increased potential of a DoS with a large
number of incoming TLS handshakes.
- Reduced impact of reconfiguration -- while there is very little
impact when reloading the configuration since HAProxy hands off the
listener sockets to the new instance and the old instance continues to
handle those connections, with a more complex configuration it is more
likely to affect services on other listeners.

 Multiple listeners on a single HAProxy instance:

- Enables sharing pools between listeners -- this would reduce keep
health monitor traffic, and pipe-lining requests from multiple listeners is
possible

 I spoke to this point above. Frankly, I'm starting to think this argument
might be premature optimization:  I'm guessing the number of incidents
where pools are shared between listeners on a single loadbalancer is going
to be relatively rare--  so few as to not merit consideration for the
overall design. :/



- Reduced resource usage -- we should preform the benchmarks and
quantify this

 Yep, I'm looking forward to seeing the benchmarks here.



- Simplified stats/log aggregation

 I disagree here. This is especially the case if we use something like
syslog-ng for gathering logs (which is effectively non-blocking, which is
probably desirable no matter whether one haproxy process or multiple
haproxy processes are used). I'm not sure haproxy's code for appending logs
it writes to directly is non-blocking.

Stats parsing from haproxy is simpler if more processes are used. As far as
aggregation: Well, we've yet to define what people might want aggregated.
But note here that shared pools across listeners means shared stats for
those pools:  A user might want to see that pool's stats for listener A
versus listener B, which isn't possible if the pool is shared across
listeners. :/  (In any case, we're still talking hypotheticals here...)


- Simplified Octavia instances -- I think each Octavia instance only
running a single HAProxy process is a win, its easier to monitor and
upstart/systemd/init only needs to start a single process.

 So, in the model proposed by Michael, a single haproxy instance consists
of all the listeners on that loadbalancer as a single process. So if more
than one loadbalancer is deployed to a single Octavia VM, you're going to
need to start / stop / otherwise control multiple haproxy processes anyway.
So the system upstart / systemd / init scripts aren't going to cut it for
this set-up. My thought was to write a new control script (similar to the
one we use in our environment already) which controls all the haproxy
processes, and which can be called on boot to look for and start any
processes for which configuration exists locally (assuming persistent
storage for the VM or something-- if some operators want to do this).  It's
just as likely that we would have a freshly-booted Octavia VM check in with
its controller on boot, download any configurations it should be running,
and start the associated haproxy process(es). Again, the model proposed by
Michael and the model proposed by me do not differ much in how this control
must work if we're allowing multiple loadbalancers per Octavia VM.

We can potentially debate whether we allow multiple loadbalancers per
Octavia VM, but I think restricting this to a maximum of one is not
desirable from a hardware utilization perspective. Many production load
balanced services sit nearly idle all day, so there's no reason an Operator
shouldn't be allowed to combine multiple loadbalancers on a single 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

Re: [openstack-dev] [Octavia] Minutes from 8/20/2013 meeting

[Stephen Balukoff]

:  Are we going to be incubated?
 A:  Yes, we are basically destined for incubation, period.  Note:  we will
 assuredly not be in Juno.

 Q:  Why be part of Neutron?  Why not just be our own program?
 A:  We 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 sending this out.  Not sure if I missed anything
 here, but please feel free to add
 anything necessary that I might have missed.  Thanks!


 -Trevor
 ___
 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

[openstack-dev] [Octavia] Agenda for 2014-08-20 meeting

[Stephen Balukoff]

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

-- 
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

Re: [openstack-dev] [Octavia] Object Model and DB Structure

[Stephen Balukoff]

Yes, I'm advocating keeping each listener in a separate haproxy
configuration (and separate running instance). This includes the example I
mentioned: One that listens on port 80 for HTTP requests and redirects
everything to the HTTPS listener on port 443.  (The port 80 listener is a
simple configuration with no pool or members, and it doesn't take much to
have it run on the same host as the port 443 listener.)

I've not explored haproxy's new redirect scheme capabilities in 1.5 yet.
Though I doubt it would have a significant impact on the operational model
where each listener is a separate haproxy configuration and instance.

German: Are you saying that the port 80 listener and port 443 listener
would have the exact same back-end configuration? If so, then what we're
discussing here with no sharing of child entities, would mean that the
customer has to set up and manage these duplicate pools and members. If
that's not acceptable, now is the time to register that opinion, eh!

Stephen


On Mon, Aug 18, 2014 at 11:37 AM, Brandon Logan brandon.lo...@rackspace.com
 wrote:

 Hi German,
 I don't think it is a requirement that those two frontend sections (or
 listen sections) have to live in the same config.  I thought if they
 were listening on the same IP but different ports it could be in two
 different haproxy instances.  I could be wrong though.

 Thanks,
 Brandon

 On Mon, 2014-08-18 at 17:21 +, Eichberger, German wrote:
  Hi,
 
  My 2 cents for the multiple listeners per load balancer discussion: We
 have customers who like to have a listener on port 80 and one on port 443
 on the same VIP (we had to patch libra to allow two listeners in one
 single haproxy) - so having that would be great.
 
  I like the proposed status :-)
 
  Thanks,
  German
 
  -Original Message-
  From: Brandon Logan [mailto:brandon.lo...@rackspace.com]
  Sent: Sunday, August 17, 2014 8:57 PM
  To: openstack-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,
  
  
   Responses in-line:
  
   On Fri, Aug 15, 2014 at 9:43 PM, Brandon Logan
   brandon.lo...@rackspace.com 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
   (Listeners, Pools,
Members, TLS-related objects, L7-related objects, etc.).
   This will
simplify a lot of things (like status reporting), and we can
   probably
safely work under the assumption that any user who has a use
   case in
which a shared entity is useful is probably also technically
   savvy
enough to not only be able to manage consistency problems
   themselves,
but is also likely to want to have that level of control.
   
   
Also, an haproxy instance should map to a single listener.
   This makes
management of the configuration template simpler and the
   behavior of a
single haproxy instance more predictable. Also, when it
   comes to
configuration updates (as will happen, say, when a new
   member gets
added to a pool), it's less risky and error prone to restart
   the
haproxy instance for just the affected listener, and not for
   all
listeners on the Octavia VM. The only down-sides I see are
   that we
consume slightly more memory, we don't have the advantage of
   a shared
SSL session cache (probably doesn't matter for 99.99% of
   sites using
TLS anyway), and certain types of persistence wouldn't carry
   over
between different listeners if they're implemented poorly by
   the
user. :/  (In other words, negligible down-sides to this.)
  
  
   This is fine by me for now, but I think this might be
   something we can
   revisit later after we have the advantage of hindsight.  Maybe
   a
   configurable option.
  
  
   Sounds good, as long as we agree on a path forward. In the mean time,
   is there anything I'm missing which would be a significant advantage
   of having multiple Listeners configured in a single haproxy instance?
   (Or rather, where a single haproxy instance maps to a loadbalancer
   object?)
 
  No particular reason as of now.  Just feel like that could be something
 that could hinder a particular feature or even performance in the future.
 It's not rooted in any fact or past experience.
 
  
   I have no problem with this. However, one thing I often do
   think about
   is that it's not really ever going to be load

Re: [openstack-dev] [Octavia] Object Model and DB Structure

[Stephen Balukoff]

German--

By 'VIP' do you mean something roughly equivalent to 'loadbalancer' in the
Neutron LBaaS object model (as we've discussed in the past)?  That is to
say, is this thingy a parent object to the Listener in the hierarchy? If
so, then what we're describing definitely accommodates that.

(And yes, we commonly see deployments with listeners on port 80 and port
443 on the same virtual IP address.)

Stephen


On Mon, Aug 18, 2014 at 2:16 PM, Eichberger, German 
german.eichber...@hp.com wrote:

  Hi Steven,



 In my example we don’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 Development Mailing List (not for usage questions)

 *Subject:* Re: [openstack-dev] [Octavia] Object Model and DB Structure



 Yes, I'm advocating keeping each listener in a separate haproxy
 configuration (and separate running instance). This includes the example I
 mentioned: One that listens on port 80 for HTTP requests and redirects
 everything to the HTTPS listener on port 443.  (The port 80 listener is a
 simple configuration with no pool or members, and it doesn't take much to
 have it run on the same host as the port 443 listener.)



 I've not explored haproxy's new redirect scheme capabilities in 1.5 yet.
 Though I doubt it would have a significant impact on the operational model
 where each listener is a separate haproxy configuration and instance.



 German: Are you saying that the port 80 listener and port 443 listener
 would have the exact same back-end configuration? If so, then what we're
 discussing here with no sharing of child entities, would mean that the
 customer has to set up and manage these duplicate pools and members. If
 that's not acceptable, now is the time to register that opinion, eh!



 Stephen



 On Mon, Aug 18, 2014 at 11:37 AM, Brandon Logan 
 brandon.lo...@rackspace.com wrote:

 Hi German,
 I don't think it is a requirement that those two frontend sections (or
 listen sections) have to live in the same config.  I thought if they
 were listening on the same IP but different ports it could be in two
 different haproxy instances.  I could be wrong though.

 Thanks,
 Brandon


 On Mon, 2014-08-18 at 17:21 +, Eichberger, German wrote:
  Hi,
 
  My 2 cents for the multiple listeners per load balancer discussion: We
 have customers who like to have a listener on port 80 and one on port 443
 on the same VIP (we had to patch libra to allow two listeners in one
 single haproxy) - so having that would be great.
 
  I like the proposed status :-)
 
  Thanks,
  German
 
  -Original Message-
  From: Brandon Logan [mailto:brandon.lo...@rackspace.com]
  Sent: Sunday, August 17, 2014 8:57 PM
  To: openstack-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,
  
  
   Responses in-line:
  
   On Fri, Aug 15, 2014 at 9:43 PM, Brandon Logan
   brandon.lo...@rackspace.com 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
   (Listeners, Pools,
Members, TLS-related objects, L7-related objects, etc.).
   This will
simplify a lot of things (like status reporting), and we can
   probably
safely work under the assumption that any user who has a use
   case in
which a shared entity is useful is probably also technically
   savvy
enough to not only be able to manage consistency problems
   themselves,
but is also likely to want to have that level of control.
   
   
Also, an haproxy instance should map to a single listener.
   This makes
management of the configuration template simpler and the
   behavior of a
single haproxy instance more predictable. Also, when it
   comes to
configuration updates (as will happen, say, when a new
   member gets
added to a pool), it's less risky and error prone to restart
   the
haproxy instance for just the affected listener, and not for
   all
listeners on the Octavia VM. The only down-sides I see are
   that we
consume slightly more memory, we don't have the advantage of
   a shared
SSL session cache (probably doesn't matter for 99.99% of
   sites using
TLS anyway), and certain types of persistence wouldn't carry
   over
between different listeners if they're implemented poorly

Re: [openstack-dev] [Octavia] Object Model and DB Structure

[Stephen Balukoff]

Hi German,


On Mon, Aug 18, 2014 at 3:10 PM, Eichberger, German 
german.eichber...@hp.com wrote:

  No, I mean with VIP the original meaning more akin to a Floating IP…


I think that's what I was describing below. But in any case, yes-- the
model we are describing should 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 Model and DB Structure



 German--



 By 'VIP' do you mean something roughly equivalent to 'loadbalancer' in the
 Neutron LBaaS object model (as we've discussed in the past)?  That is to
 say, is this thingy a parent object to the Listener in the hierarchy? If
 so, then what we're describing definitely accommodates that.



 (And yes, we commonly see deployments with listeners on port 80 and port
 443 on the same virtual IP address.)



 Stephen



 On Mon, Aug 18, 2014 at 2:16 PM, Eichberger, German 
 german.eichber...@hp.com wrote:

 Hi Steven,



 In my example we don’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 Development Mailing List (not for usage questions)


 *Subject:* Re: [openstack-dev] [Octavia] Object Model and DB Structure



 Yes, I'm advocating keeping each listener in a separate haproxy
 configuration (and separate running instance). This includes the example I
 mentioned: One that listens on port 80 for HTTP requests and redirects
 everything to the HTTPS listener on port 443.  (The port 80 listener is a
 simple configuration with no pool or members, and it doesn't take much to
 have it run on the same host as the port 443 listener.)



 I've not explored haproxy's new redirect scheme capabilities in 1.5 yet.
 Though I doubt it would have a significant impact on the operational model
 where each listener is a separate haproxy configuration and instance.



 German: Are you saying that the port 80 listener and port 443 listener
 would have the exact same back-end configuration? If so, then what we're
 discussing here with no sharing of child entities, would mean that the
 customer has to set up and manage these duplicate pools and members. If
 that's not acceptable, now is the time to register that opinion, eh!



 Stephen



 On Mon, Aug 18, 2014 at 11:37 AM, Brandon Logan 
 brandon.lo...@rackspace.com wrote:

 Hi German,
 I don't think it is a requirement that those two frontend sections (or
 listen sections) have to live in the same config.  I thought if they
 were listening on the same IP but different ports it could be in two
 different haproxy instances.  I could be wrong though.

 Thanks,
 Brandon


 On Mon, 2014-08-18 at 17:21 +, Eichberger, German wrote:
  Hi,
 
  My 2 cents for the multiple listeners per load balancer discussion: We
 have customers who like to have a listener on port 80 and one on port 443
 on the same VIP (we had to patch libra to allow two listeners in one
 single haproxy) - so having that would be great.
 
  I like the proposed status :-)
 
  Thanks,
  German
 
  -Original Message-
  From: Brandon Logan [mailto:brandon.lo...@rackspace.com]
  Sent: Sunday, August 17, 2014 8:57 PM
  To: openstack-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,
  
  
   Responses in-line:
  
   On Fri, Aug 15, 2014 at 9:43 PM, Brandon Logan
   brandon.lo...@rackspace.com 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
   (Listeners, Pools,
Members, TLS-related objects, L7-related objects, etc.).
   This will
simplify a lot of things (like status reporting), and we can
   probably
safely work under the assumption that any user who has a use
   case in
which a shared entity is useful is probably also technically
   savvy
enough to not only be able to manage consistency problems
   themselves,
but is also likely to want to have that level of control.
   
   
Also, an haproxy instance should map to a single listener.
   This makes
management of the configuration template simpler and the
   behavior of a
single haproxy instance more predictable. Also, when it
   comes to
configuration updates (as will happen, say, when a new
   member gets
added to a pool), it's less risky and error prone

Re: [openstack-dev] [Octavia] Minutes from 8/13/2014 meeting

[Stephen Balukoff]

 the operator summit a few weeks from
  now to thoroughly discuss network concerns
 
 
  3) Discuss v0.5 component design proposal
   [https://review.openstack.org/#/c/113458/]
  a) Notification for back-end node health (aka being
  offline) isn't required for 0.5, but is a must have later
  b) Notification of LB health (HA Proxy, etc) is definitely
  a requirement in 0.5
  c) Still looking for more feedback on the proposal itself
 
 
  I'll try and find some time to review it.
 
 
  4) Discuss timeline on moving these meetings to IRC.
  a) Most members in favor of keeping the webex meetings for
  the time being
  b) One major point was other openstack/stackforge use
  video meetings as their primary source as well
 
 
  This is one of the reasons for which I don't attend load balancing
  meetings.
  I find IRC much simpler and effective - and is also fairer to people
  for whom English is not their first language.
  Also, perusing IRC logs is much easier than watch/listen to webex
  recordings.
  Moreover, you'd get minutes for free - and you can control the density
  you want them to have during the meeting!
 
 These meetings are just for Octavia right now and will eventually get
 into IRC.  The weekly LBaaS meeting 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 is to eventually get it on IRC.  With the more interest we get
 on this the more we need to speed this up.
 
 
 
 
 
 
 
  Sorry for the lack of density.  I forgot to have the
  meeting recorded, but I hope I included some major points.
   Feel free to respond in line with any more information anyone
  can recall concerning the meeting information.  Thanks!
 
 
  -Trevor
 
  ___
  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
 
 Thanks,
 Brandon
 
 ___
 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

Re: [openstack-dev] [Octavia] Object Model and DB Structure

[Stephen Balukoff]

Hi Brandon,

Responses in-line:

On Fri, Aug 15, 2014 at 9:43 PM, Brandon Logan brandon.lo...@rackspace.com
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 (Listeners, Pools,
  Members, TLS-related objects, L7-related objects, etc.). This will
  simplify a lot of things (like status reporting), and we can probably
  safely work under the assumption that any user who has a use case in
  which a shared entity is useful is probably also technically savvy
  enough to not only be able to manage consistency problems themselves,
  but is also likely to want to have that level of control.
 
 
  Also, an haproxy instance should map to a single listener. This makes
  management of the configuration template simpler and the behavior of a
  single haproxy instance more predictable. Also, when it comes to
  configuration updates (as will happen, say, when a new member gets
  added to a pool), it's less risky and error prone to restart the
  haproxy instance for just the affected listener, and not for all
  listeners on the Octavia VM. The only down-sides I see are that we
  consume slightly more memory, we don't have the advantage of a shared
  SSL session cache (probably doesn't matter for 99.99% of sites using
  TLS anyway), and certain types of persistence wouldn't carry over
  between different listeners if they're implemented poorly by the
  user. :/  (In other words, negligible down-sides to this.)

 This is fine by me for now, but I think this might be something we can
 revisit later after we have the advantage of hindsight.  Maybe a
 configurable option.


Sounds good, as long as we agree on a path forward. In the mean time, is
there anything I'm missing which would be a significant advantage of having
multiple Listeners configured in a single haproxy instance? (Or rather,
where a single haproxy instance maps to a loadbalancer object?)


 I have no problem with this. However, one thing I often do think about
 is that it's not really ever going to be load balancing anything with
 just a load balancer and listener.  It has to have a pool and members as
 well.  So having ACTIVE on the load balancer and listener, and still not
 really load balancing anything is a bit odd.  Which is why I'm in favor
 of only doing creates by specifying the entire tree in one call
 (loadbalancer-listeners-pool-members).  Feel free to disagree with me
 on this because I know this not something everyone likes.  I'm sure I am
 forgetting something that makes this a hard thing to do.  But if this
 were the case, then I think only having the provisioning status on the
 load balancer makes sense again.  The reason I am advocating for the
 provisioning status on the load balancer is because it still simpler,
 and only one place to look to see if everything were successful or if
 there was an issue.


Actually, there is one case where it makes sense to have an ACTIVE Listener
when that listener has no pools or members:  Probably the 2nd or 3rd most
common type of load balancing service we deploy is just an HTTP listener
on port 80 that redirects all requests to the HTTPS listener on port 443.
While this can be done using a (small) pool of back-end servers responding
to the port 80 requests, there's really no point in not having the haproxy
instance do this redirect directly for sites that want all access to happen
over SSL. (For users that want them we also insert HSTS headers when we do
this... but I digress. ;) )

Anyway, my point is that there is a common production use case that calls
for a listener with no pools or members.



 Again though, what you've proposed I am entirely fine with because it
 works great with having to create a load balancer first, then listener,
 and so forth.  It would also work fine with a single create call as
 well.


We should probably create more formal API documentation, eh. :)  (Let me
pull up my drafts from 5 months ago...)


 
  I don't think that these kinds of status are useful / appropriate for
  Pool, Member, Healthmonitor, TLS certificate id, or L7 Policy / Rule
  objects, as ultimately this boils down to configuration lines in an
  haproxy config somewhere, and really the Listener status is what will
  be affected when things are changed.

 Total agreement on this.
 
  I'm basically in agreement with Brandon on his points with operational
  status, though I would like to see these broken out into their various
  meanings for the different object types. I also think some object
  types won't need an operational status (eg. L7 Policies,
  healthmonitors, etc.) since these essentially boil down to lines in an
  haproxy configuration file.

 Yeah I was thinking could be more descriptive status names for the load
 balancer and listener statuses.  I was thinking load balancer could have
 PENDING_VIP_CREATE/UPDATE/DELETE, but then that'd be painting us into a
 corner.  More general is needed

Re: [openstack-dev] [Octavia] Object Model and DB Structure

[Stephen Balukoff]

 
  So I've been assuming that the Octavia object model would be an exact
 copy of the neutron lbaas one with additional information for Octavia.
  However, after thinking about it I'm not sure this is the right way to
 go because the object model in neutron lbaas may change in the future, and
 Octavia can't just change it's object model when neutron lbaas/openstack
 lbaas changes it's object model.  So if there are any lessons learned we
 would like to apply to Octavia's object model now is the time.
 
  Entity name changes are also on the table if people don't really like
 some of the names.  Even adding new entities or removing entities if there
 are good reasons isn't out of the question.
 
  Anyway here are a few of my suggestions.  Please add on to this if you
 want.  Also, just flat out tell me I'm wrong on some of htese suggestions
 if you feel as such.
 
  A few improvements I'd suggest (using the current entity names):
  -A real root object that is the only top level object (loadbalancer).
  --This would be 1:M relationship with Listeners, but Listeners would
 only be children of loadbalancers.
  --Pools, Members, and Health Monitors would follow the same workflow.
  --Basically no shareable entities.
 
  -Provisioning status only on the root object (loadbalancer).
  --PENDING_CREATE, PENDING_UPDATE, PENDING_DELETE, ACTIVE (No need for a
 DEFEERRED status! YAY!) --Also maybe a DELETED status.
 
  -Operating status on other entities
  --ACTIVE or ONLINE, DEGRADED, INACTIVE or OFFLINE --Pools and Members
 --Listeners have been mentioned but I'd like to hear more details on that.
 
  -Adding status_description field in, 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.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

Re: [openstack-dev] [Neutron][LBaaS] Use cases with regards to VIP and routers

[Stephen Balukoff]

From the perspective of Blue Box:

* Load balancing appliances will often (usually?) live outside the same
subnet as back-end member VMs.
* The network in which the load balancing appliances live will usually have
a default router (gateway)
* We don't anticipate the need for using extra_routes at this time, though
I suspect other operators might need this.
* We also anticipate occasionally needing the load balancing appliances to
have layer-2 connectivity to some back-end member VMs.



On Tue, Aug 12, 2014 at 12:32 AM, Susanne Balle sleipnir...@gmail.com
wrote:

 In the context of Octavia and Neutron LBaaS. Susanne


 On Mon, Aug 11, 2014 at 5:44 PM, Stephen Balukoff sbaluk...@bluebox.net
 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?

 Stephen


 On Mon, Aug 11, 2014 at 9:04 AM, Doug Wiegley do...@a10networks.com
 wrote:

 Hi Susanne,

 While there are a few operators involved with LBaaS that would have good
 input, you might want to also ask this on the non-dev mailing list, for a
 larger sample size.

 Thanks,
 doug

 On 8/11/14, 3:05 AM, Susanne Balle sleipnir...@gmail.com wrote:

 Gang,
 I was asked the following questions around our Neutron LBaaS use cases:
 1.  Will there be a scenario where the ³VIP² port will be in a different
 Node, from all the Member ³VMs² in a pool.
 
 
 2.  Also how likely is it for the LBaaS configured subnet to not have a
 ³router² and just use the ³extra_routes²
  option.
 3.  Is there a valid use case where customers will be using the
 ³extra_routes² with subnets instead of the ³routers².
  ( It would be great if you have some use case picture for this).
 Feel free to chime in here and I'll summaries the answers.
 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-4305 x807

 ___
 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

[openstack-dev] [Octavia] Agenda for 13 Aug 2014 meeting

[Stephen Balukoff]

Hi folks!

This is what I have for my tentative agenda for tomorrow's Octavia meeting.
Please e-mail me if you want anything else added to this list. (Also, I
will start putting these weekly agendas in the wiki in the near future.)

* Discuss future of Octavia in light of Neutron-incubator project proposal.

* Discuss operator networking requirements (carryover from last week)

* Discuss v0.5 component design proposal:
https://review.openstack.org/#/c/113458/

* Discuss timeline on moving these meetings to IRC.

As usual, please e-mail me if you'd like information on connecting to 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

Re: [openstack-dev] [Neutron][LBaaS] Use cases with regards to VIP and routers

[Stephen Balukoff]

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?

Stephen


On Mon, Aug 11, 2014 at 9:04 AM, Doug Wiegley do...@a10networks.com wrote:

 Hi Susanne,

 While there are a few operators involved with LBaaS that would have good
 input, you might want to also ask this on the non-dev mailing list, for a
 larger sample size.

 Thanks,
 doug

 On 8/11/14, 3:05 AM, Susanne Balle sleipnir...@gmail.com wrote:

 Gang,
 I was asked the following questions around our Neutron LBaaS use cases:
 1.  Will there be a scenario where the ³VIP² port will be in a different
 Node, from all the Member ³VMs² in a pool.
 
 
 2.  Also how likely is it for the LBaaS configured subnet to not have a
 ³router² and just use the ³extra_routes²
  option.
 3.  Is there a valid use case where customers will be using the
 ³extra_routes² with subnets instead of the ³routers².
  ( It would be great if you have some use case picture for this).
 Feel free to chime in here and I'll summaries the answers.
 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-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Octavia] Weekly meetings resuming + agenda

[Stephen Balukoff]

Hi Brandon,

I don't think we've set a specific date to make the transition to IRC
meetings. Is there a particular urgency about this that we should be aware
of?

Stephen


On Wed, Aug 6, 2014 at 7:58 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:

 When is the plan to move the meeting to IRC?

 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
  particular Ebay) a chance to review and comment.
  2. Stephen is going to try to get Octavia v0.5 design docs into gerrit
  review by the end of the week, or early next week at the latest.
 
  3. If those with specific networking concerns could codify this and/or
  figure out a way to write these down and share with the list, that
  would be great. This is going to be important to ensure that our
  operator-grade load balancer solution can actually meet the needs of
  the operators developing it.
 
  Thanks,
 
  Stephen
 
 
 
 
 
 
 
 
  On Tue, Aug 5, 2014 at 2:34 PM, Stephen Balukoff
  sbaluk...@bluebox.net wrote:
  Hello!
 
 
  We plan on resuming weekly meetings to discuss things related
  to the Octavia project starting tomorrow: August 6th at
  13:00PDT (20:00UTC). In order to facilitate high-bandwidth
  discussion as we bootstrap the project, we have decided to
  hold these meetings via webex, with the plan to eventually
  transition to IRC. Please contact me directly if you would
  like to get in on the webex.
 
 
  Tomorrow's meeting agenda is currently as follows:
 
 
  * Discuss Octavia constitution and project direction documents
  currently under gerrit review:
  https://review.openstack.org/#/c/110563/
 
 
 
  * Discuss reviews of design proposals currently under gerrit
  review:
  https://review.openstack.org/#/c/111440/
  https://review.openstack.org/#/c/111445/
 
 
  * Discuss operator network topology requirements based on data
  currently being collected by HP, Rackspace and Blue Box.
  (Other operators are certainly welcome 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
 
 
 
 
  --
  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

 ___
 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

Re: [openstack-dev] [Octavia] Minutes from 8/6/2014 meeting

[Stephen Balukoff]

On where to capture notes like this long-term:  I would say the wiki is
more searchable for now. When we make the transition to IRC meetings, then
the meeting bots will capture minutes and transcripts in the usual way and
we can link to these from the wiki.


On Thu, Aug 7, 2014 at 1:29 AM, Stephen Balukoff sbaluk...@bluebox.net
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 format.

 1) Octavia Constitution and Project Direction Documents (Road map)
 a) Constitution and Road map will potentially be adopted after
 another couple days; providing those who were busy more time to review the
 information

 2) Octavia Design Proposals
 a) Difference between version 0.5 and 1.0 isn't huge
 b) Version 2 has many network topology changes and Layer 4 routing
 + This includes N node Active-Active
 + Would like to avoid Layer 2 connectivity with Load Balancers
 (included in version 1 however)
 + Layer router driver
 + Layer router controller
 + Long term solution
 c) After refining Version 1 document (with some scrutiny) all changes
 will be propagated to the Version 2 document
 d) Version 0.5 is unpublished
 e) All control layer, anything connected to the intermediate message
 bus in version 1, will be collapsed down to 1 daemon.
 + No scale-able control, but scale-able service delivery
 + Version 1 will be the first large operator compatible version,
 that will have both scale-able control and scale-able service delivery
 + 0.5 will be a good start
 - laying out ground work
 - rough topology for the end users
 - must be approved by the networking teams for each
 contributing company
 f) The portions under control of neutron lbaas is the User API and
 the driver (for neutron lbaas)
 g) If neutron LBaaS is a sufficient front-end (user API doesn't
 suck), then Octavia will be kept as a vendor driver
 h) Potentially including a REST API on top of Octavia
 + Octavia is initially just a vendor driver, no real desire for
 another API in front of Octavia
 + If someone wants it, the work is trivial and can be done in
 another project at another time
 i) Octavia should have a loose coupling with Neutron; use a shim for
 network connectivity (one specifically for Neutron communication in the
 start)
 + This is going to hold any dirty hacks that would be required
 to get something done, keeping Octavia clean
 - Example: changing the mac address on a port

 3) Operator Network Topology Requirements
 a) One requirement is floating IPs.
 b) IPv6 is in demand, but is currently not supported reliably on
 Neutron
 + IPv6 would be represented as a different load balancer entity,
 and possibly include co-location with another Load Balancer
 c) Network interface plug-ability (potentially)
 d) Sections concerning front-end connectivity should be forwarded to
 each company's network specialists for review
 + Share findings in the mailing list, and dissect the proposals
 with the information and comment what requirements are needing added etc.

 4) HA/Failover Options/Solutions
 a) Rackspace may have a solution to this, but the conversation will
 be pushed off to the next meeting (at least)
 + Will gather more information from another member in Rackspace
 to provide to the ML for initial discussions
 b) One option for HA:  Spare pool option (similar to Libra)
 + Poor recovery time is a big problem
 c) Another option for HA:  Active/Passive
 + Bluebox uses one active and one passive configuration, and has
 sub-second fail over.  However is not resource-sufficient

 Questions:
 Q:  What is the expectation for a release time-frame
 A:  Wishful thinking; Octavia version 0.5 beta for Juno (probably not,
 but would be awesome to push for that)

 Notes:
  + We need to pressure the Neutron core reviewers to review the Neutron
 LBaaS changes to get merges.
  + Version 2 front-end topology is different than the Version 1.  Please
 review them individually, and thoroughly


 PS.  I re-wrote most of the information from the recording (thanks again
 Doug).  I have one question for everyone: should I just 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?

 ___
 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




-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807

Re: [openstack-dev] [Octavia] Weekly meetings resuming + agenda

[Stephen Balukoff]

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 particular Ebay) a chance
to review and comment.

2. Stephen is going to try to get Octavia v0.5 design docs into gerrit
review by the end of the week, or early next week at the latest.

3. If those with specific networking concerns could codify this and/or
figure out a way to write these down and share with the list, that would be
great. This is going to be important to ensure that our operator-grade
load balancer solution can actually meet the needs of the operators
developing it.

Thanks,

Stephen




On Tue, Aug 5, 2014 at 2:34 PM, Stephen Balukoff sbaluk...@bluebox.net
wrote:

 Hello!

 We plan on resuming weekly meetings to discuss things related to the
 Octavia project starting tomorrow: August 6th at 13:00PDT (20:00UTC). In
 order to facilitate high-bandwidth discussion as we bootstrap the project,
 we have decided to hold these meetings via webex, with the plan to
 eventually transition to IRC. Please contact me directly if you would like
 to get in on the webex.

 Tomorrow's meeting agenda is currently as follows:

 * Discuss Octavia constitution and project direction documents currently
 under gerrit review:
 https://review.openstack.org/#/c/110563/

 * Discuss reviews of design proposals currently under gerrit review:
 https://review.openstack.org/#/c/111440/
 https://review.openstack.org/#/c/111445/

 * Discuss operator network topology requirements based on data currently
 being collected by HP, Rackspace and Blue Box. (Other operators are
 certainly welcome 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




-- 
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

Re: [openstack-dev] [Neutron][LBaaS] status in entities

[Stephen Balukoff]

Hi guys,

I understood that admin_state_up was a manipulable field which (when
working correctly) should change the entity to an operational status of
ADMIN_DOWN or something similar to that. In any case, +1 on the deeper
discussion of status.

How urgent is it to resolve the discussion around status? We could
potentially bring the interested parties together via google hangout or
webex (to facilitate the high bandwidth).

Stephen


On Tue, Aug 5, 2014 at 9:05 AM, Brandon Logan brandon.lo...@rackspace.com
wrote:

 Isn't that what admin_state_up is for?

 But yes we do need a deeper discussion on this and many other things.

 On Tue, 2014-08-05 at 15:42 +, Eichberger, German wrote:
  There was also talk about a third administrative status like ON/OFF...
 
  We really need a deeper status discussion - likely high bandwith to work
 all of that out.
 
  German
 
  -Original Message-
  From: Brandon Logan [mailto:brandon.lo...@rackspace.com]
  Sent: Tuesday, August 05, 2014 8:27 AM
  To: openstack-dev@lists.openstack.org
  Subject: Re: [openstack-dev] [Neutron][LBaaS] status in entities
 
 
  Hello Vijay!
 
  Well this is a hold over from v1, but the status is a provisioning
 status.  So yes, when something is deployed successfully it should be
 ACTIVE.  The exception to this is the member status, in that it's status
 can be INACTIVE if a health check fails.  Now this will probably cause edge
 cases when health checks and updates are happening to the same member.
  It's been talked about before, but we need to really have two types of
 status fields, provisioning and operational.  IMHO, that should be
 something we try to get into K.
 
  Thanks,
  Brandon
 
  On Tue, 2014-08-05 at 09:28 +, Vijay Venkatachalam wrote:
   Hi:
  
  I think we had some discussions around ‘status’
   attribute earlier, I don’t recollect the conclusion.
  
   Does it reflect the deployment status?
  
  Meaning, if the status of an entity is ACTIVE, the user
   has to infer that the entity is deployed successfully in the
   backend/loadbalancer.
  
   Thanks,
  
   Vijay V.
  
  
   ___
   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

 ___
 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

[openstack-dev] [Octavia] Weekly meetings resuming + agenda

[Stephen Balukoff]

Hello!

We plan on resuming weekly meetings to discuss things related to the
Octavia project starting tomorrow: August 6th at 13:00PDT (20:00UTC). In
order to facilitate high-bandwidth discussion as we bootstrap the project,
we have decided to hold these meetings via webex, with the plan to
eventually transition to IRC. Please contact me directly if you would like
to get in on the webex.

Tomorrow's meeting agenda is currently as follows:

* Discuss Octavia constitution and project direction documents currently
under gerrit review:
https://review.openstack.org/#/c/110563/

* Discuss reviews of design proposals currently under gerrit review:
https://review.openstack.org/#/c/111440/
https://review.openstack.org/#/c/111445/

* Discuss operator network topology requirements based on data currently
being collected by HP, Rackspace and Blue Box. (Other operators are
certainly welcome 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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Status and Expectations for Juno

[Stephen Balukoff]

 priority for this to make
 it
  in.  Plus, it really hasn't been worked on in a while.  This is
 just my
  opinion, though.  Hopefully, we won't need this for Kilo.
  
  6. Horizon - LBaaS V2 API
  
  This I do not see happening for Juno.  It could happen but I don't
 know
  of anyone who has even talked about doing this.  I'm reluctantly
 okay
  with it not making it into Juno because V2 API will kind of be in a
 beta
  state in my opinion since there won't be very much driver support,
  especially without a shim layer.  I suggest this goes in Kilo. I
 know
  some won't like this though (I'm looking at you doug).
  
  7. Devstack for LBaaS V2 API
  
  The only changes devstack would need for this piece is to just
 change
  the config.  However, I have not worked on this piece myself and
 didn't
  think of it as a high priority for Juno.  If someone has or wants to
  tackle that, please let us know.  Otherwise, move it to Kilo.
  
  8. HAProxy Agent driver
  
  Since we decided to go with a simpler agentless driver that only
 runs on
  the API node and is not scalable at all, the agent driver part still
  needs to be completed.  I definitely don't see this going into Juno
  because other higher priorities should get in first.  I suggest this
  gets in Kilo.
  
  8. TLS for LBaaS V2 API
  
  Evgeny is doing this one. I think this is a top priority for us and
 we
  all want this in Juno.  It depends on #1 getting in as well.  If #1
  doesn't get in, we have bigger issues.  I am hopeful that this will
 get
  in for Juno, as I think it should be our #2 priority Neutron LBaaS.
  
  9. Docs, CLI, Tempest tests, and Devstack for TLS
  
  Evgeny, are these being worked on in tandem?
  Devstack is definitely going to require some other changes for use
 of
  haproxy 1.5.
  
  10. L7 for LBaaS V2 API
  
  This is the 3rd priority for Neutron LBaaS in my opinion.  I am not
  certain that this will get in Juno.  Can we get updates on this?
  
  
  I think that about covers it.  Sorry for the long email.
  
  Thanks,
  Brandon
  
  
  ___
  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
 
  ___
  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

 ___
 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

Re: [openstack-dev] [Neutron] Flavor Framework spec approval deadline exception

[Stephen Balukoff]

I am wholly in favor of this sentiment!


On Tue, Jul 22, 2014 at 8:16 AM, Kyle Mestery mest...@mestery.com wrote:

 On Tue, Jul 22, 2014 at 10:10 AM, Eugene Nikanorov
 enikano...@mirantis.com wrote:
  Hi folks,
 
  I'd like to request an exception for the Flavor Framework spec:
  https://review.openstack.org/#/c/102723/
 
  It already have more or less complete server-side implementation:
  https://review.openstack.org/#/c/105982/
 
  CLI will be posted on review soon.
 
 We need the flavor framework to land for Juno, as LBaaS needs it. I'm
 ok with an exception here. Can we work to close the gaps in the spec
 review in the next few days? I see a few -1s on there still.

 Thanks,
 Kyle

  Thanks,
  Eugene.
 
 
 
  ___
  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

Re: [openstack-dev] [Neutron][LBaaS] TLS capability - certificates data persistency

[Stephen Balukoff]

I'm willing to go with simpler code that gets us this feature faster, and
re-evaluating whether storing some extra data on certificates locally makes
significant performance gains later on.

First we need to get it working, then we need to make it work fast. :)

Stephen


On Tue, Jul 22, 2014 at 4:04 PM, Carlos Garza carlos.ga...@rackspace.com
wrote:


 On Jul 20, 2014, at 6:32 AM, Evgeny Fedoruk evge...@radware.com wrote:

  Hi folks,
 
  In a current version of TLS capabilities RST certificate
 SubjectCommonName and SubjectAltName information is cached in a database.
  This may be not necessary and here is why:
 
  1.   TLS containers are immutable, meaning once a container was
 associated to a listener and was validated, it’s not necessary to validate
 the container anymore.
  This is relevant for both, default container and containers used for SNI.
  2.   LBaaS front-end API can check if TLS containers ids were
 changed for a listener as part of an update operation. Validation of
 containers will be done for
  new containers only. This is stated in “Performance Impact” section of
 the RST, excepting the last statement that proposes persistency for SCN and
 SAN.
  3.   Any interaction with Barbican API for getting containers data
 will be performed via a common module API only. This module’s API is
 mentioned in
  “SNI certificates list management” section of the RST.
  4.   In case when driver really needs to extract certificate
 information prior to the back-end system provisioning, it will do it via
 the common module API.
  5.   Back-end provisioning system may cache any certificate data,
 except private key, in case of a specific need of the vendor.
 
  IMO, There is no real need to store certificates data in Neutron
 database and manage its life cycle.
  Does anyone sees a reason why caching certificates’ data in Neutron
 database is critical?

 Its not so much caching the certificate. Lets just say when an lb
 change comes into the API that wants to add an X509 then we need to parse
 the subjectNames and SubjectAltNames from the previous X509s which aren't
 available to us so we must grab them all from barbican over the rest
 interface. Like I said in an earlier email its a balancing act between
 Single Source of Truth vs how much lag were willing to deal with.



  Thank you,
  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

Re: [openstack-dev] [heat] health maintenance in autoscaling groups

[Stephen Balukoff]

It's probably worth pointing out that most of the Neutron LBaaS team are
spending most of our time doing a major revision to Neutron LBaaS. How
stats processing should happen has definitely been discussed but not
resolved at present-- and in any case it was apparent to those working on
the project that it has secondary importance compared to the revision work
presently underway.

I personally would like to have queries about most objects in the stats API
to Neutron LBaaS return a dictionary or statuses for child objects which
then a UI or auto-scaling system can interpret however it wishes. Your
points are certainly well made, and I agree that it might also be useful to
inject status information externally, or have some kind of hook there to
get event notifications when individual member statuses change. But this is
really a discussion that needs to happen once the current code drive is
near fruition (ie. for Kilo).

Stephen


On Wed, Jul 23, 2014 at 1:27 PM, Doug Wiegley do...@a10networks.com wrote:

  Great question, and to my knowledge, not at present.  There is an
 ongoing discussion about a common usage framework for ceilometer, for all
 the various *aaS things, but status I not included (yet!).  I think that
 spec is in gerrit.

  Thanks,
 Doug


   From: Mike Spreitzer mspre...@us.ibm.com
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: Wednesday, July 23, 2014 at 2:03 PM

 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [heat] health maintenance in autoscaling
 groups

  Doug Wiegley do...@a10networks.com wrote on 07/23/2014 03:43:02 PM:

  From: Doug Wiegley do...@a10networks.com
  ...
  The state of the world today: ‘status’ in the neutron database is
  configuration/provisioning status, not operational status.  Neutron-
  wide thing.  We were discussing adding operational status fields (or
  a neutron REST call to get the info from the backend) last month,
  but it’s something that isn’t planned for a serious conversation
  until Kilo, at present.

 Thanks for the prompt response.  Let me just grasp at one last straw: is
 there any chance that Neutron will soon define and implement 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-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

Re: [openstack-dev] [Neutron][LBaaS] TLS capability - certificates data persistency

[Stephen Balukoff]

Evgeny--

The only reason I see for storing certificate information in Neutron (and
not private key information-- just the certificate) is to aid in presenting
UI information to the user. Especially GUI users don't care about a
certificate's UUID, they care about which hostnames it's valid for. Yes,
this can be loaded on the fly whenever public certificate information is
accessed, but the perception was that it would be a significant performance
increase to cache it.

Stephen


On Sun, Jul 20, 2014 at 4:32 AM, Evgeny Fedoruk evge...@radware.com wrote:

  Hi folks,



 In a current version of TLS capabilities RST certificate SubjectCommonName
 and SubjectAltName information is cached in a database.

 This may be not necessary and here is why:



 1.   TLS containers are immutable, meaning once a container was
 associated to a listener and was validated, it’s not necessary to validate
 the container anymore.
 This is relevant for both, default container and containers used for SNI.

 2.   LBaaS front-end API can check if TLS containers ids were changed
 for a listener as part of an update operation. Validation of containers
 will be done for
 new containers only. This is stated in “Performance Impact” section of the
 RST, excepting the last statement that proposes persistency for SCN and SAN.

 3.   Any interaction with Barbican API for getting containers data
 will be performed via a common module API only. This module’s API is
 mentioned in
 “SNI certificates list management” section of the RST.

 4.   In case when driver really needs to extract certificate
 information prior to the back-end system provisioning, it will do it via
 the common module API.

 5.   Back-end provisioning system may cache any certificate data,
 except private key, in case of a specific need of the vendor.



 IMO, There is no real need to store certificates data in Neutron database
 and manage its life 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://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

Re: [openstack-dev] [Neutron][LBaaS] Update on specs we needed approved

[Stephen Balukoff]

Yes, thanks guys! These are really important for features we want to get
into Neutron LBaaS in Juno! :D


On Mon, Jul 21, 2014 at 2:42 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:

 In reference to these 3 specs:

 TLS Termination - https://review.openstack.org/#/c/98640/
 L7 Switching - https://review.openstack.org/#/c/99709/
 Implementing TLS in reference Impl -
 https://review.openstack.org/#/c/100931/

 Kyle has +2'ed all three and once Mark Mcclain +2's them then one of
 them will +A them.

 Thanks again Kyle and Mark!


 ___
 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

Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509

[Stephen Balukoff]

Ok, folks!

Per the IRC meeting this morning, we came to the following consensus
regarding how TLS certificates are handled, how SAN is handled, and how
hostname conflict resolution is handled. I will be responding to all three
of the currently ongoing mailing list discussions with this info:


   - Driver does not have to use SAN that is passed from API layer, but SAN
   will be available to drivers at the API layer. This will be mentioned
   explicitly in the spec.
   - Order is a mandatory attribute. It's intended to be used as a hint
   for hostname conflict resolution, but it's ultimately up to the driver to
   decide how to resolve the conflict. (In other words, although it is a
   mandatory attribute in our model, drivers are free to ignore it.)
   - Drivers are allowed to vary their behavior when choosing how to
   implement hostname conflict resolution since there is no single algorithm
   here that all vendors are able to support. (This is anticipated to be a
   rare edge case anyway.)

I think Evgeny will be updating the specs to reflect this decision so that
it is documented--  we hope to get ultimate approval of the spec in the
next day or two.

Thanks,
Stephen




On Wed, Jul 16, 2014 at 7:31 PM, Stephen Balukoff sbaluk...@bluebox.net
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' concerns with regard to
 handling TLS certificates.

 Stephen


 On Wed, Jul 16, 2014 at 12:35 PM, Carlos Garza carlos.ga...@rackspace.com
  wrote:


 On Jul 16, 2014, at 10:55 AM, Vijay Venkatachalam 
 vijay.venkatacha...@citrix.com
  wrote:

  Apologies for the delayed response.
 
  I am OK with displaying the certificates contents as part of the API,
 that should not harm.
 
  I think the discussion has to be split into 2 topics.
 
  1.   Certificate conflict resolution. Meaning what is expected when
 2 or more certificates become eligible during SSL negotiation
  2.   SAN support
 

 Ok cool that makes more sense. #2 seems to be met by Evgeny proposal.
 I'll let you folks decide the conflict resolution issue #1.


  I will send out 2 separate mails on this.
 
 
  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][LBaaS] TLS capability - SNI -
 Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
 
  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 ubiquitously used.
 
  I will wait for Vijay to speak for himself in this regard…
 
  -Sam.
 
 
  From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
  Sent: Tuesday, July 15, 2014 8:35 PM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI -
 Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
 
  +1 to German's and  Carlos' comments.
 
  It's also worth pointing out that some UIs will definitely want to show
 SAN information and the like, so either having this available as part of
 the API, or as a standard library we write which then gets used by multiple
 drivers is going to be necessary.
 
  If we're extracting the Subject Common Name in any place in the code
 then we also need to be extracting the Subject Alternative Names at the
 same place. From the perspective of the SNI standard, there's no difference
 in how these fields should be treated, and if we were to treat SANs
 differently then we're both breaking the standard and setting a bad
 precedent.
 
  Stephen
 
 
  On Tue, Jul 15, 2014 at 9:35 AM, Carlos Garza 
 carlos.ga...@rackspace.com wrote:
 
  On Jul 15, 2014, at 10:55 AM, Samuel Bercovici samu...@radware.com
   wrote:
 
   Hi,
  
  
   Obtaining the domain name from the x509 is probably more of a
 driver/backend/device capability, it would make sense to have a library
 that could be used by anyone wishing to do so in their driver code.
 
  You can do what ever you want in *your* driver. The code to extract
 this information will be apart of the API and needs to be mentioned in the
 spec now. PyOpenSSL with PyASN1 are the most likely candidates.
 
  Carlos D. Garza
  
   -Sam.
  
  
  
   From: Eichberger, German [mailto:german.eichber...@hp.com]
   Sent: Tuesday, July 15, 2014 6:43 PM
   To: OpenStack Development Mailing List (not for usage questions)
   Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI -
 Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
  
   Hi,
  
   My impression was that the frontend would extract the names and hand
 them to the driver.  This has

Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SubjectAlternativeNames (SAN)

[Stephen Balukoff]

Ok, folks!

Per the IRC meeting this morning, we came to the following consensus
regarding how TLS certificates are handled, how SAN is handled, and how
hostname conflict resolution is handled. I will be responding to all three
of the currently ongoing mailing list discussions with this info:


   - Driver does not have to use SAN that is passed from API layer, but SAN
   will be available to drivers at the API layer. This will be mentioned
   explicitly in the spec.
   - Order is a mandatory attribute. It's intended to be used as a hint
   for hostname conflict resolution, but it's ultimately up to the driver to
   decide how to resolve the conflict. (In other words, although it is a
   mandatory attribute in our model, drivers are free to ignore it.)
   - Drivers are allowed to vary their behavior when choosing how to
   implement hostname conflict resolution since there is no single algorithm
   here that all vendors are able to support. (This is anticipated to be a
   rare edge case anyway.)

I think Evgeny will be updating the specs to reflect this decision so that
it is documented--  we hope to get ultimate approval of the spec in the
next day or two.

Thanks,
Stephen


On Wed, Jul 16, 2014 at 7:41 PM, Stephen Balukoff sbaluk...@bluebox.net
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 pointed out in another thread.) Or at least, isn't that
 ignoring how every major browser on the market that support SNI operates?

 Anyway, per the other thread we've had on this, and Evgeny's proposal
 there, do you see harm in having SAN available at the API level
 (informationally, at least). In any case, duplication of code is something
 I think we can all agree is not desirable, and because so many other
 implementations are likely to need the SAN info, it should be available to
 drivers via a universal library (as Carlos is describing).

 Stephen


 On Wed, Jul 16, 2014 at 3:43 PM, Eichberger, German 
 german.eichber...@hp.com wrote:

 +1 for not duplicating code

 For me it's scary as well if different implementation exhibit different
 behavior. This very contrary to what we would like to do with exposing LBs
 only as flavor...

 German

 -Original Message-
 From: Carlos Garza [mailto:carlos.ga...@rackspace.com]
 Sent: Wednesday, July 16, 2014 2:05 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability -
 SubjectAlternativeNames (SAN)


 On Jul 16, 2014, at 3:49 PM, Carlos Garza carlos.ga...@rackspace.com
 wrote:

 
  On Jul 16, 2014, at 12:30 PM, Vijay Venkatachalam
  vijay.venkatacha...@citrix.com
  wrote:
 
 We will have the code that will parse the X509 in the API scope of
 the code. The validation I'm refering to is making sure the key matches the
 cert used and that we mandate that at a minimum the backend driver support
 RSA and that since the X509 validation is happeneing at the api layer this
 same module will also handling the extraction of the SANs. I am proposing
 that the methods that can extract the SAN SCN from the x509 be present in
 the api portion of the code and that drivers can call these methods if they
 need too. Infact I'm already working to get these extraction methods
 contributed to the PyOpenSSL project so that they will already available at
 a more fundemental layer then our nuetron/LBAAS code. At the very least I
 want to spec to declare that SAN SCN and parsing must be made available
 from the API layer. If the PyOpenSSL has the methods available at that time
 then I we can simply write wrappers for this in the API or simple write
 more higher level methods in the API module.

 I meant to say bottom line I want the parsing code exposed in the API
 and not duplicated in everyone elses driver.

  I am partioally open to the idea of letting the driver handle the
 behavior of the cert parsing. Although I defer this to the rest of the
 folks as I get this feeling having differn't implementations exhibiting
 differen't behavior may sound scary.
 
 
 I think it is best not to mention about SAN in the
 OpenStack TLS spec. It is expected that the backend should implement
 according to the SSL/SNI IETF spec.
  Let's leave the implementation/validation part to the driver.  For ex.
 NetScaler does not support SAN and the NetScaler driver could either throw
 an error if certs with SAN are used or ignore it.
 
 How is netscaler making the decision when choosing the cert to
 associate with the SNI handshake?
 
 
  Does anyone see a requirement for detailing?
 
 
  Thanks,
  Vijay V.
 
 
  From: Vijay Venkatachalam
  Sent: Wednesday, July 16, 2014 8:54 AM
  To: 'Samuel Bercovici'; 'OpenStack Development Mailing List (not for
 usage questions)'
  Subject: RE: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI -
  Extracting SubjectCommonName

Re: [openstack-dev] [Neutron][LBaaS] TLS capability - Certificate conflict resolution

[Stephen Balukoff]

Ok, folks!

Per the IRC meeting this morning, we came to the following consensus
regarding how TLS certificates are handled, how SAN is handled, and how
hostname conflict resolution is handled. I will be responding to all three
of the currently ongoing mailing list discussions with this info:


   - Driver does not have to use SAN that is passed from API layer, but SAN
   will be available to drivers at the API layer. This will be mentioned
   explicitly in the spec.
   - Order is a mandatory attribute. It's intended to be used as a hint
   for hostname conflict resolution, but it's ultimately up to the driver to
   decide how to resolve the conflict. (In other words, although it is a
   mandatory attribute in our model, drivers are free to ignore it.)
   - Drivers are allowed to vary their behavior when choosing how to
   implement hostname conflict resolution since there is no single algorithm
   here that all vendors are able to support. (This is anticipated to be a
   rare edge case anyway.)

I think Evgeny will be updating the specs to reflect this decision so that
it is documented--  we hope to get ultimate approval of the spec in the
next day or two.

Thanks,
Stephen


On Wed, Jul 16, 2014 at 7:26 PM, Stephen Balukoff sbaluk...@bluebox.net
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 about conflict resolution. I
 am assuming not.



 Because of this ambiguity each backend employs its own mechanism to
 resolve conflicts.



 There are 3 choices now

 1.   The LBaaS extension does not allow conflicting certificates to
 be bound using validation

 2.   Allow each backend conflict resolution mechanism to get into
 the spec

 3.   Does not specify anything in the spec, no mechanism introduced
 and let the driver deal with it.



 Both HA proxy and Radware uses configuration as a mechanism to resolve.
 Radware uses order while HA Proxy uses externally specified DNS names.

 NetScaler implementation uses the best possible match algorithm



 For ex, let’s say 3 certs are bound to the same endpoint with the
 following SNs

 www.finance.abc.com

 *.finance.abc.com

 *.*.abc.com



 If the host request is  payroll.finance.abc.com  we shall  use  *.
 finance.abc.com

 If it is  payroll.engg.abc.com  we shall use  *.*.abc.com



 NetScaler won’t not allow 2 certs to have the same SN.




 Did you mean CN as in Common Name above?

 In any case, it sounds like:

 1. Conflicts are going to be relatively rare in any case
 2. Conflict resolution as such can probably be left to the vendor. Since
 the Neutron LBaaS reference implementation uses HAProxy, it seems logical
 that this should be considered normal behavior for the Neutron LBaaS
 service-- though again the slight variations in vendor implementations for
 conflict resolution are unlikely to cause serious issues for most users.

 If NetScaler runs into a situation where the SCN of a cert conflicts with
 the SCN or SAN of another cert, then perhaps they can return an
 'UnsupportedConfigruation' 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 resolve name
 conflicts.
 B. Includes a ubiquitous library for extracting SCN and SAN that any
 driver may use if they don't use the 'order' attribute?

 Thanks,
 Stephen


 --
 Stephen Balukoff
 Blue Box Group, LLC
 (800)613-4305 x807




-- 
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

Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509

[Stephen Balukoff]

From the comments there, I think the reason for storing the subjectAltNames
was to minimize the number of calls we will need to make to barbican, and
because the barbican container is immutable, and therefore the list of
subjectAltNames won't change so long as the container exists, and we don't
have to worry about cache invalidation. (Because really, storing the
subjectAltNames locally is a cache.)  We could accomplish the same thing by
storing the cert (NOT the key) in our database as well and extracting the
information from the x509 cert that we want on the fly. But this also seems
like we're doing more work than necessary to keep extracting the same data
from the same certificate that will never change.

How we store this in the database is something I'm less opinionated about,
but your idea that storing this data in a separate table seems to make
sense.

Do you really see a need to be concerned with anything but GEN_DNS entries
here? Or put another way, is there an application that would likely be used
in load balancing that makes use of any subjectAltName entries that are not
DNSNames? (I'm pretty sure that's all that all the major browsers look at
anyway-- and I don't see them changing any time soon since this satisfies
the need for implementing SNI.)  Secondary to this, does supporting other
subjectAltName types in our code cause any extra significant complication?
 In practice, I think anything that does TERMINATED_HTTPS as the listener
protocol is only going to care about dNSName entries and ignore the rest--
but if supporting the rest opens the door for more general-purpose forms of
TLS, I don't see harm in extracting these other subjectAltName types from
the x509 cert. It certainly feels more correct to treat these for what
they are: the tuples you've described.

Thanks,
Stephen



On Thu, Jul 17, 2014 at 2:29 PM, Carlos Garza carlos.ga...@rackspace.com
wrote:

 I added the following comments to patch 14 but I'm not -1 it but I think
 its a mistake
 to assume the altSubjectName is a string type. See below.

 --- Comments on patch 14 below 

 SubjectAltNames are not a string and should be thought
  of as an array of tuples. Example
  [('dNSName','www.somehost.com'),
 ('dirNameCN','www.somehostFromAltCN.org'),
 ('dirNameCN','www.anotherHostFromAltCN.org')]

 for right now we only care about entries that are of type dNSName
 or the entries that are of type DirName that also contain a CN in the
 DirName container. All other AltNames can be ignores as they don't seem to
 be apart of hostname validation in PKIX

 Also we don't need to store these in the object model. since these
 can be extracted from the X509 on the fly. Just be aware though that
 the SubjectAltName should not be treated as a simple string but as a
 list of (general_name_type,general_name_value) tuples

 were really close to the end but we can't mess this one up.

 I'm flexible if you want these values store in the database
 or not. If we do store it in a database we need a table called
 general_names that contains varchars for type and value for
 now with what ever you guys want to use for the keys. to
 map back to the tls_container_id. unless we want with a
 firm decision on what strings in type should map to
 GEN_DNS and GEN_DIRNAME CN entries from the
 OpenSSL layer.

 For now we can skip 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 of host name
 validation. Excample
 (dirName, 'cn=john.garza,ou=people,o=somecompany)

 dNSName and DirName encodings are mentioned in RFC2459. if you want a more
 formal definition.

 On Jul 17, 2014, at 10:19 AM, Stephen Balukoff sbaluk...@bluebox.net
 wrote:

  Ok, folks!
 
  Per the IRC meeting this morning, we came to the following consensus
 regarding how TLS certificates are handled, how SAN is handled, and how
 hostname conflict resolution is handled. I will be responding to all three
 of the currently ongoing mailing list discussions with this info:
 
• Driver does not have to use SAN that is passed from API layer,
 but SAN will be available to drivers at the API layer. This will be
 mentioned explicitly in the spec.
• Order is a mandatory attribute. It's intended to be used as a
 hint for hostname conflict resolution, but it's ultimately up to the
 driver to decide how to resolve the conflict. (In other words, although it
 is a mandatory attribute in our model, drivers are free to ignore it.)
• Drivers are allowed to vary their behavior when choosing how to
 implement hostname conflict resolution since there is no single algorithm
 here that all vendors are able to support. (This is anticipated to be a
 rare edge case anyway.)
  I think Evgeny will be updating the specs to reflect this decision so
 that it is documented--  we hope to get

Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509

[Stephen Balukoff]

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' concerns with regard to
handling TLS certificates.

Stephen


On Wed, Jul 16, 2014 at 12:35 PM, Carlos Garza carlos.ga...@rackspace.com
wrote:


 On Jul 16, 2014, at 10:55 AM, Vijay Venkatachalam 
 vijay.venkatacha...@citrix.com
  wrote:

  Apologies for the delayed response.
 
  I am OK with displaying the certificates contents as part of the API,
 that should not harm.
 
  I think the discussion has to be split into 2 topics.
 
  1.   Certificate conflict resolution. Meaning what is expected when
 2 or more certificates become eligible during SSL negotiation
  2.   SAN support
 

 Ok cool that makes more sense. #2 seems to be met by Evgeny proposal.
 I'll let you folks decide the conflict resolution issue #1.


  I will send out 2 separate mails on this.
 
 
  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][LBaaS] TLS capability - SNI -
 Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
 
  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 ubiquitously used.
 
  I will wait for Vijay to speak for himself in this regard…
 
  -Sam.
 
 
  From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
  Sent: Tuesday, July 15, 2014 8:35 PM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI -
 Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
 
  +1 to German's and  Carlos' comments.
 
  It's also worth pointing out that some UIs will definitely want to show
 SAN information and the like, so either having this available as part of
 the API, or as a standard library we write which then gets used by multiple
 drivers is going to be necessary.
 
  If we're extracting the Subject Common Name in any place in the code
 then we also need to be extracting the Subject Alternative Names at the
 same place. From the perspective of the SNI standard, there's no difference
 in how these fields should be treated, and if we were to treat SANs
 differently then we're both breaking the standard and setting a bad
 precedent.
 
  Stephen
 
 
  On Tue, Jul 15, 2014 at 9:35 AM, Carlos Garza 
 carlos.ga...@rackspace.com wrote:
 
  On Jul 15, 2014, at 10:55 AM, Samuel Bercovici samu...@radware.com
   wrote:
 
   Hi,
  
  
   Obtaining the domain name from the x509 is probably more of a
 driver/backend/device capability, it would make sense to have a library
 that could be used by anyone wishing to do so in their driver code.
 
  You can do what ever you want in *your* driver. The code to extract
 this information will be apart of the API and needs to be mentioned in the
 spec now. PyOpenSSL with PyASN1 are the most likely candidates.
 
  Carlos D. Garza
  
   -Sam.
  
  
  
   From: Eichberger, German [mailto:german.eichber...@hp.com]
   Sent: Tuesday, July 15, 2014 6:43 PM
   To: OpenStack Development Mailing List (not for usage questions)
   Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI -
 Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
  
   Hi,
  
   My impression was that the frontend would extract the names and hand
 them to the driver.  This has the following advantages:
  
   · We can be sure all drivers can extract the same names
   · No duplicate code to maintain
   · If we ever allow the user to specify the names on UI rather
 in the certificate the driver doesn’t need to change.
  
   I think I saw Adam say something similar in a comment to the code.
  
   Thanks,
   German
  
   From: Evgeny Fedoruk [mailto:evge...@radware.com]
   Sent: Tuesday, July 15, 2014 7:24 AM
   To: OpenStack Development Mailing List (not for usage questions)
   Subject: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI -
 Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
  
   Hi All,
  
   Since this issue came up from TLS capabilities RST doc review, I
 opened a ML thread for it to make the decision.
   Currently, the document says:
  
   “
   For SNI functionality, tenant will supply list of TLS containers in
 specific
   Order.
   In case when specific back-end is not able to support SNI capabilities,
   its driver should throw an exception. The exception message should
 state
   that this specific back-end (provider) does not support SNI capability.
   The clear sign of listener's requirement for SNI capability is
   a none empty SNI container ids list.
   However, reference

Re: [openstack-dev] [Neutron][LBaaS] TLS capability - Certificate conflict resolution

[Stephen Balukoff]

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 about conflict resolution. I
 am assuming not.



 Because of this ambiguity each backend employs its own mechanism to
 resolve conflicts.



 There are 3 choices now

 1.   The LBaaS extension does not allow conflicting certificates to
 be bound using validation

 2.   Allow each backend conflict resolution mechanism to get into the
 spec

 3.   Does not specify anything in the spec, no mechanism introduced
 and let the driver deal with it.



 Both HA proxy and Radware uses configuration as a mechanism to resolve.
 Radware uses order while HA Proxy uses externally specified DNS names.

 NetScaler implementation uses the best possible match algorithm



 For ex, let’s say 3 certs are bound to the same endpoint with the
 following SNs

 www.finance.abc.com

 *.finance.abc.com

 *.*.abc.com



 If the host request is  payroll.finance.abc.com  we shall  use  *.
 finance.abc.com

 If it is  payroll.engg.abc.com  we shall use  *.*.abc.com



 NetScaler won’t not allow 2 certs to have the same SN.




Did you mean CN as in Common Name above?

In any case, it sounds like:

1. Conflicts are going to be relatively rare in any case
2. Conflict resolution as such can probably be left to the vendor. Since
the Neutron LBaaS reference implementation uses HAProxy, it seems logical
that this should be considered normal behavior for the Neutron LBaaS
service-- though again the slight variations in vendor implementations for
conflict resolution are unlikely to cause serious issues for most users.

If NetScaler runs into a situation where the SCN of a cert conflicts with
the SCN or SAN of another cert, then perhaps they can return an
'UnsupportedConfigruation' 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 resolve name
conflicts.
B. Includes a ubiquitous library for extracting SCN and SAN that any driver
may use if they don't use the 'order' attribute?

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

Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SubjectAlternativeNames (SAN)

[Stephen Balukoff]

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 pointed out in another thread.) Or at least, isn't that
ignoring how every major browser on the market that support SNI operates?

Anyway, per the other thread we've had on this, and Evgeny's proposal
there, do you see harm in having SAN available at the API level
(informationally, at least). In any case, duplication of code is something
I think we can all agree is not desirable, and because so many other
implementations are likely to need the SAN info, it should be available to
drivers via a universal library (as Carlos is describing).

Stephen


On Wed, Jul 16, 2014 at 3:43 PM, Eichberger, German 
german.eichber...@hp.com wrote:

 +1 for not duplicating code

 For me it's scary as well if different implementation exhibit different
 behavior. This very contrary to what we would like to do with exposing LBs
 only as flavor...

 German

 -Original Message-
 From: Carlos Garza [mailto:carlos.ga...@rackspace.com]
 Sent: Wednesday, July 16, 2014 2:05 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability -
 SubjectAlternativeNames (SAN)


 On Jul 16, 2014, at 3:49 PM, Carlos Garza carlos.ga...@rackspace.com
 wrote:

 
  On Jul 16, 2014, at 12:30 PM, Vijay Venkatachalam
  vijay.venkatacha...@citrix.com
  wrote:
 
 We will have the code that will parse the X509 in the API scope of
 the code. The validation I'm refering to is making sure the key matches the
 cert used and that we mandate that at a minimum the backend driver support
 RSA and that since the X509 validation is happeneing at the api layer this
 same module will also handling the extraction of the SANs. I am proposing
 that the methods that can extract the SAN SCN from the x509 be present in
 the api portion of the code and that drivers can call these methods if they
 need too. Infact I'm already working to get these extraction methods
 contributed to the PyOpenSSL project so that they will already available at
 a more fundemental layer then our nuetron/LBAAS code. At the very least I
 want to spec to declare that SAN SCN and parsing must be made available
 from the API layer. If the PyOpenSSL has the methods available at that time
 then I we can simply write wrappers for this in the API or simple write
 more higher level methods in the API module.

 I meant to say bottom line I want the parsing code exposed in the API
 and not duplicated in everyone elses driver.

  I am partioally open to the idea of letting the driver handle the
 behavior of the cert parsing. Although I defer this to the rest of the
 folks as I get this feeling having differn't implementations exhibiting
 differen't behavior may sound scary.
 
 
 I think it is best not to mention about SAN in the
 OpenStack TLS spec. It is expected that the backend should implement
 according to the SSL/SNI IETF spec.
  Let's leave the implementation/validation part to the driver.  For ex.
 NetScaler does not support SAN and the NetScaler driver could either throw
 an error if certs with SAN are used or ignore it.
 
 How is netscaler making the decision when choosing the cert to
 associate with the SNI handshake?
 
 
  Does anyone see a requirement for detailing?
 
 
  Thanks,
  Vijay V.
 
 
  From: Vijay Venkatachalam
  Sent: Wednesday, July 16, 2014 8:54 AM
  To: 'Samuel Bercovici'; 'OpenStack Development Mailing List (not for
 usage questions)'
  Subject: RE: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI -
  Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
 
  Apologies for the delayed response.
 
  I am OK with displaying the certificates contents as part of the API,
 that should not harm.
 
  I think the discussion has to be split into 2 topics.
 
  1.   Certificate conflict resolution. Meaning what is expected when
 2 or more certificates become eligible during SSL negotiation
  2.   SAN support
 
  I will send out 2 separate mails on this.
 
 
  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][LBaaS] TLS capability - SNI -
  Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
 
  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 ubiquitously used.
 
  I will wait for Vijay to speak for himself in this regard...
 
  -Sam.
 
 
  From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
  Sent: Tuesday, July 15, 2014 8:35 PM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject

Re: [openstack-dev] [Neutron] Flavor framework proposal

[Stephen Balukoff]

 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.


 Yes. At the end of the day I have no problem with going with single
 service flavours. Mostly because it will be already a win if we manage to
 bind this framework to a single advanced service in the juno release cycle.


Yay! That's the goal: Get this into Juno!  And it seems to me like a good
first step toward multi-service_type flavors, if we as a group decide
that's where we want to go.

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

Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509

[Stephen Balukoff]

+1 to German's and  Carlos' comments.

It's also worth pointing out that some UIs will definitely want to show SAN
information and the like, so either having this available as part of the
API, or as a standard library we write which then gets used by multiple
drivers is going to be necessary.

If we're extracting the Subject Common Name in any place in the code then
we also need to be extracting the Subject Alternative Names at the same
place. From the perspective of the SNI standard, there's no difference in
how these fields should be treated, and if we were to treat SANs
differently then we're both breaking the standard and setting a bad
precedent.

Stephen


On Tue, Jul 15, 2014 at 9:35 AM, Carlos Garza carlos.ga...@rackspace.com
wrote:


 On Jul 15, 2014, at 10:55 AM, Samuel Bercovici samu...@radware.com
  wrote:

  Hi,
 
 
  Obtaining the domain name from the x509 is probably more of a
 driver/backend/device capability, it would make sense to have a library
 that could be used by anyone wishing to do so in their driver code.

 You can do what ever you want in *your* driver. The code to extract
 this information will be apart of the API and needs to be mentioned in the
 spec now. PyOpenSSL with PyASN1 are the most likely candidates.

 Carlos D. Garza
 
  -Sam.
 
 
 
  From: Eichberger, German [mailto:german.eichber...@hp.com]
  Sent: Tuesday, July 15, 2014 6:43 PM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI -
 Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
 
  Hi,
 
  My impression was that the frontend would extract the names and hand
 them to the driver.  This has the following advantages:
 
  · We can be sure all drivers can extract the same names
  · No duplicate code to maintain
  · If we ever allow the user to specify the names on UI rather in
 the certificate the driver doesn’t need to change.
 
  I think I saw Adam say something similar in a comment to the code.
 
  Thanks,
  German
 
  From: Evgeny Fedoruk [mailto:evge...@radware.com]
  Sent: Tuesday, July 15, 2014 7:24 AM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI -
 Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
 
  Hi All,
 
  Since this issue came up from TLS capabilities RST doc review, I opened
 a ML thread for it to make the decision.
  Currently, the document says:
 
  “
  For SNI functionality, tenant will supply list of TLS containers in
 specific
  Order.
  In case when specific back-end is not able to support SNI capabilities,
  its driver should throw an exception. The exception message should state
  that this specific back-end (provider) does not support SNI capability.
  The clear sign of listener's requirement for SNI capability is
  a none empty SNI container ids list.
  However, reference implementation must support SNI capability.
 
  Specific back-end code may retrieve SubjectCommonName and/or
 altSubjectNames
  from the certificate which will determine the hostname(s) the certificate
  is associated with.
 
  The order of SNI containers list may be used by specific back-end code,
  like Radware's, for specifying priorities among certificates.
  In case when two or more uploaded certificates are valid for the same
 DNS name
  and the tenant has specific requirements around which one wins this
 collision,
  certificate ordering provides a mechanism to define which cert wins in
 the
  event of a collision.
  Employing the order of certificates list is not a common requirement for
  all back-end implementations.
  “
 
  The question is about SCN and SAN extraction from X509.
  1.   Extraction of SCN/ SAN should be done while provisioning and
 not during TLS handshake
  2.   Every back-end 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

[openstack-dev] [Neutron] Flavor framework proposal

[Stephen Balukoff]

Hi folks!

I've noticed progress on the flavor framework discussion slowing down over
the last week. We would really like to see this happen for Juno because
it's critical for many of the features we'd also like to get into Juno for
LBaaS. I understand there are other Neutron extensions which will need it
too.

The proposal under discussion is here:

https://review.openstack.org/#/c/102723/

One of the things I've seen come up frequently in the comments is the idea
that a single flavor would apply to more than one service type (service
type being 'LBaaS', 'FWaaS', 'VPNaaS', etc.). I've commented extensively on
this, and my opinion is that this doesn't make a whole lot of sense.
 However, there are people who have a different view on this, so I would
love to hear from them:

Could you describe a specific usage scenario where 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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Flavor framework proposal

[Stephen Balukoff]

 LBaaS-- we want it to be feature-rich enough in Juno for us to be
able to actually do interesting things with Octavia without having to
resort to building our own independent API endpoint if at all possible.) If
Octavia ever splits off and has its own API endpoint, it would need to
implement something like the Neutron flavor framework itself-- and in this
case, what we decide to do there should not affect the Neutron flavor
framework at all (or visa versa).

If you want to provide the illusion of two different top-level services /
API endpoints having the same flavor, then I would say, that's what
orchestration is for.

On Tue, Jul 15, 2014 at 2:07 PM, Eugene Nikanorov enikano...@mirantis.com
 wrote:

 Hi Stephen,

 So, as was discussed, existing proposal has some aspects which better to
 be postponed, like extension list on the flavor (instead of tags).


Agreed-- I think we need to more fully flesh out how extension list / tags
should work here before we implement it. But this doesn't prevent us from
rolling forward with a version 1 of flavors so that we can start to use
some of the benefits of having flavors (like the ability to use multiple
service profiles with a single driver/provider, or multiple service
profiles for a single kind of service).


 Particularly that idea has several drawbacks:
  - it makes public API inflexible
  - turning features on/off is not what flavors should be doing, it's a
 task for policy framework and not flavors
  - flavor-based rest call dispatching is quite complex solution giving no
 benefits for service plugins


I'm confused as to what you mean by that idea here. Are you taking about
the extension list? If this is the case, I agree that that aspect needs
to be refined and should probably be postponed if possible.


 While this is not explicitly written in proposal - that's what implied
 there.
 I think that one is a major blocker of the proposal right now, it deserves
 future discussion and not essential to the problem flavors are supposed to
 solve.


Yes, I think there are many benefits we can get out of the flavor framework
without having to have an extensions list / tags at this revision. But I'm
curious: Did we ever define what we were actually trying to solve with
flavors?  Maybe that's the reason the discussion on this has been all of
the place: People are probably making assumptions about the problem we're
trying to solve and we need to get on the same page about this.



 Other than that, I personally don't have much disagreements on the
 proposal.

 The question about service type on the flavor is minor IMO. We can allow
 it to be NULL, which would mean multiservice flavor.
 However, multiservice flavors may put some minor requirements to driver
 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

Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor

[Stephen Balukoff]

Per the IRC discussion this morning, I believe it was decided that we would
prioritize creating a v2 agent which should run in parallel with the v1
agent. Further, for any subsequent driver shim layer, this should happen
after the v2 agent is functional.

... or I may have misunderstood what was decided in the meeting. :)  In any
case, y'all should feel free to correct me here and/or raise other concerns
we didn't think about, eh!

Stephen


On Wed, Jul 9, 2014 at 3:12 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:

  Shim will become quite complicated due to the fact we won't be able to
 actually send any load balancer information to the driver until a load
 balancer is linked to a listener, pool, and member.  The reason is because
 for a vip to be created it needs attributes from a load balancer and
 listener.  A vip also has a required attribute of pool_id in the old API so
 all the old driver are expecting a pool_id.  So this means we need a pool
 first.  Since the subnet_id has been moved off the pool and onto the pool
 member, we will need to have a pool with at least one member before we can
 send all that information to the driver.

 Now once that is done, it will probably get even crazier with updates and
 deletes to each one of those entities.

 So should time and effort be spent on the shim, which is temporary and
 eventually thrown away. Or should time be spent on creating a new version
 of the agent and namspace driver based off the new driver interface, which
 will need to be done anyway?

 Doing the shim could end up being faster than creating a new version of
 the agent, but since there are going to be a lot of crazy edge cases, I
 question the stability of it and the time it may take for it to become
 stable.

 One problem with not doing the shim is the older drivers cannot be used
 with the new API and will have to be updated.  To this, I would argue that
 there is no benefit to using the new API with an old driver versus using
 the Old API 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.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

Re: [openstack-dev] [Neutron][LBaaS] Wednesday meeting agenda topics

[Stephen Balukoff]

I'm OK with essentially skipping the Wednesday video meetings until we're
at a point that we're ready to concentrate on Octavia as a project.

In previous video meetings there was a general sentiment that more could be
accomplished (and faster) using video communications, while avoiding a lot
of misunderstandings that crop up when people use text as a sole means of
communication. (And there's science to back up this claim:
http://www.nonverbalgroup.com/2011/08/how-much-of-communication-is-really-nonverbal/

http://www.psychologytoday.com/blog/beyond-words/201109/is-nonverbal-communication-numbers-game
 )

Having said this, even if someone is recording all the video feeds that go
into a video conference, this is difficult to document in any useful way
for posterity or even for people who aren't able to make it to the
discussion.

When the Octavia project kicks into high gear once the Neutron LBaaS stuff
is in a good state for Juno, we'll probably start with the high-bandwidth
video conferences among those interested in contributing to the project and
probably move to IRC or some other more document-able solution once the
initial groundwork for the project is laid and high-bandwidth communication
isn't as vital.

Stephen




On Thu, Jul 10, 2014 at 5:14 AM, Samuel Bercovici samu...@radware.com
wrote:

  I prefer IRC only.

 As I am located in Israel and so are other Radware people, it is easier
 for us to use IRC which is also more available from more devices and
 locations.

 OpenStack has chosen IRC as a way to allow different people from different
 places and different speaking capabilities to work together and this has
 proven fine till now.





 -Sam.





 *From:* Brandon Logan [mailto:brandon.lo...@rackspace.com]
 *Sent:* Wednesday, July 09, 2014 10:44 PM

 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Wednesday meeting agenda
 topics



 My personal opinion is I prefer the IRC meetings right now.  I,
 personally, don't get any more value out of a video chat than I would with
 an IRC meeting.  However, I know others do get more out of it, and that
 includes people on my team at Rackspace.  Basically, what I am saying is
 I'd be fine with only doing the IRC meeting, at least for now.  Once more
 focus is put on Octavia, then it would need its own meeting.

 Thanks,
 Brandon
  --

 *From:* Doug Wiegley [do...@a10networks.com]
 *Sent:* Wednesday, July 09, 2014 11:39 AM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Wednesday meeting agenda
 topics

 Have the IRC meetings been time constrained or unproductive?  Having a
 pre-meeting before the IRC meeting risks being exclusionary to the folks
 that can’t make it for that timezone, and I haven’t seen that the IRC
 meetings are having communication/decision issues, beyond it being bloody
 dang early.



 The webex time slot is open for whatever, and if this is what the group
 wants to use it for, by all means go for it.  But IMO, just cloning the IRC
 meeting is something that doesn’t sound right to me.



 Thanks,

 doug



 *From: *Trevor Vardeman trevor.varde...@rackspace.com
 *Reply-To: *OpenStack Development Mailing List (not for usage
 questions) openstack-dev@lists.openstack.org
 *Date: *Wednesday, July 9, 2014 at 9:34 AM
 *To: *OpenStack Development Mailing List (not for usage questions) [
 openstack-dev@lists.openstack.org] openstack-dev@lists.openstack.org
 *Subject: *[openstack-dev] [Neutron][LBaaS] Wednesday meeting agenda
 topics



 Hello all!



 Earlier in the meetings we discussed using the Wednesday meeting for only
 Octavia discussions.  One of my teammates would like to allocate the
 Wednesday meeting time for face-to-face discussions of the same meeting
 topics we have on Thursday morning.  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 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

Re: [openstack-dev] [Neutron][LBaaS] topics for Thurday's Weekly LBaaS meeting's agenda

[Stephen Balukoff]

Hi Suzanne,

Just got back from a few days' vacation. I would love to work with you to
co-present a talk on Octavia, eh!

Thanks,
Stephen


On Tue, Jul 8, 2014 at 6:57 AM, Susanne Balle sleipnir...@gmail.com wrote:

 Hi

 I would like to discuss what talks we plan to do at the Paris' summit and
 who will be submitting what? The deadline for submitting talks is July 28
 so it is approaching.

 Also how many working sessions do we need? and what prep work do we need
 to do before the summit.

 I am personally interested in co-presenting a talk on Octavia 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/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

[openstack-dev] [Octavia] Temporary project leadership team

[Stephen Balukoff]

Howdy folks,

Given the feedback from people on this list last week to my suggestion
about holding elections for PTL and core reviewers for the Octavia project,
it's clear that since we've only recently been added as a stackforge
project, we don't have any code or review history on which people can base
their opinions for voting on project leadership.

The problem is that if we want to be able to use the gerrit system for
reviewing code, specs, and documentation then somebody needs the ability to
+2 proposed changes and workflow so they get merged into the source tree
(ie. if we want to follow the usual OpenStack process on this, which we do.)

So after discussing this with the group of people who have been working
together on the design for this project for the last several months, the
consensus was to elect from among ourselves an interim PTL and interim core
reviewers until we have enough official history on this project to be able
to actually do meaningful public elections. We are anticipating holding
these elections around the time of the Juno summit.

Obviously, please feel free to disagree with our process and/or decision
for doing this, but I would ask 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, German Eichberger

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

Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?

[Stephen Balukoff]

Evgeny--

Two minor nits:

* Your spec lists the new SNI related settings 'sni_list' (and it contains
more than just IDs, so calling it 'sni_container_ids_list' is misleading).
Please be precise in the terms you use, and don't switch them mid
discussion. :)
* Also, I personally really hate long table names when they're unnecessary.
vipsniassociations isn't mentioned in your spec anywhere, and frankly, is
a lot worse than sni_list. I personally prefer SNIPolicies, but I'm
also OK with a short name like sni_list.

Otherwise I agree with you on all points.

Stephen





On Tue, Jun 24, 2014 at 3:26 AM, Evgeny Fedoruk evge...@radware.com wrote:

  Vijay, there is no intension for a new TLS settings API.

 Creation of a listener with TLS offloading will be one-step.



 When tenant creates listener with TERMINATED-HTTPS protocol he must supply
 default_tls_container_id for offloading.

 Not supplying default TLS container id for offloading for TERMINATED-HTTPS
 listener will raise an error.

 SNI list may or may not be supplied by the tenant. Default value for SNI
 certificates list is an empty list.



 So listener resource will have another two attributes:
 default_tls_container_id and sni_container_ids_list. These are relevant for
 TERMINATED-HTTPS protocol listeners only. In other cases its default value
 are ‘None’ and empty list.

 In schema, Default_tls_container_id will be added to listener object as
 another column.

 Sni_container_ids_list wil be managed by new table “vipsniassociations”
 which has listener_id, container_id, and position (for ordering) columns



 Does it make sense?



 Thanks,

 Evg









 *From:* Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
 *Sent:* Tuesday, June 24, 2014 12:31 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?





 To clarify, the request is for a new TLS settings API with
 “default_tls_container_id”  “sni_list”.



 If there is a new API, then we would have an object model reflecting this
 as a separate entity.



 The tenant would do the following



 1.   Create a listener with TERMINATED_HTTPS

 2.   Set the TLS settings for the listener using
 /v2.0/listener/listenerid/tlssettings  (if at all we are having some
 default values this can be reflected here)



 The only good thing is the separation of the TLS settings out of the
 listener API.



 But, I can see 2 downsides

 1.   The loadbalancer creation is a 2 step procedure

 2.   We cannot enforce certificate attachment as part of the create
 of listener.



 If the new API itself has “-1”s then I am perfectly OK with the current
 object model with default_tls_container_id in listener table.



 Thanks,

 Vijay V.





 *From:* Evgeny Fedoruk [mailto:evge...@radware.com evge...@radware.com]
 *Sent:* Tuesday, June 24, 2014 2:19 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?



 Vipsniassociations table: Line 147 in last patch of the document



 *From:* Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com
 vijay.venkatacha...@citrix.com]
 *Sent:* Tuesday, June 24, 2014 10:17 AM
 *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?





 SNI list is managed by separate entity

 What is this entity?



 *From:* Evgeny Fedoruk [mailto:evge...@radware.com 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?



 +1 for option 1. SNI list is managed by separate entity, default TLS
 container is part of a listener object. It will have None value when
 listener does not offloads TLS.

 Managing another entity for 1:0-1 relationship just for future use seems
 not right to me. Breaking TLS settings apart from listener can be done when
 needed, if needed.



 Thanks,

 Evg





 *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net
 sbaluk...@bluebox.net]
 *Sent:* Tuesday, June 24, 2014 4:26 AM
 *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?



 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?



 On Mon, Jun 23, 2014 at 6:03 PM, Doug Wiegley do...@a10networks.com
 wrote:

 Put me down for being in favor of option 1.



 A single attribute in a 1:1 relationship?  Putting that in a new table
 sounds like premature optimization to me; design the database

Re: [openstack-dev] [Neutron][LBaaS] Layer7 Switching - L7 Rule - comapre_type values

[Stephen Balukoff]

Making sure all drivers support the features offered in Neutron LBaaS means
we are stuck going with the 'least common denominator' in all cases. While
this ensures all vendors implement the same things in the functionally the
same way, it also is probably a big reason the Neutron LBaaS project has
been so incredibly slow in seeing new features added over the last two
years.

In the gerrit review that Dustin linked, it sounds like the people
contributing to the discussion are in favor of allowing drivers to reject
some configurations as unsupported through use of exceptions (details on
how that will work is being hashed out now if you want to participate in
that discussion).  Let's assume, therefore, that with the LBaaS v2 API and
Object model we're also going to get this ability-- which of course also
means that drivers do not have to support every feature exposed by the API.

(And again, as Dustin pointed out, a Linux LVS-based driver definitely
wouldn't be able to support any L7 features at all, yet it's still a very
useful driver for many deployments.)

Finally, I do not believe that the LBaaS project should be held back
because one vendor's implementation doesn't work well with a couple
features exposed in the API. As Dustin said, let the API expose a rich
feature set and allow drivers to reject certain configurations when they
don't support them.

Stephen



On Tue, Jun 24, 2014 at 9:09 AM, Dustin Lundquist dus...@null-ptr.net
wrote:

 I brought this up on https://review.openstack.org/#/c/101084/.


 -Dustin


 On Tue, Jun 24, 2014 at 7:57 AM, Avishay Balderman avish...@radware.com
 wrote:

  Hi Dustin

 I agree with the concept you described but as far as I understand it is
 not currently supported in Neutron.

 So a driver should be fully compatible with the interface it implements.



 Avishay



 *From:* Dustin Lundquist [mailto:dus...@null-ptr.net]
 *Sent:* Tuesday, June 24, 2014 5:41 PM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Layer7 Switching - L7
 Rule - comapre_type values



 I think the API should provide an richly featured interface, and
 individual drivers should indicate if they support the provided
 configuration. For example there is a spec for a Linux LVS LBaaS driver,
 this driver would not support TLS termination or any layer 7 features, but
 would still be valuable for some deployments. The user experience of such a
 solution could be improved if the driver to propagate up a message
 specifically identifying the unsupported feature.





 -Dustin



 On Tue, Jun 24, 2014 at 4:28 AM, Avishay Balderman avish...@radware.com
 wrote:

 Hi

 One of L7 Rule attributes is ‘compare_type’.

 This field is the match operator that the rule should activate against
 the value found in the request.

 Below is list of the possible values:

 - Regexp

 - StartsWith

 - EndsWith

 - Contains

 - EqualTo (*)

 - GreaterThan (*)

 - LessThan (*)



 The last 3 operators (*) in the list are used in numerical matches.

 Radware load balancing backend does not support those operators   “out of
 the box” and a significant development effort should be done in order to
 support it.

 We are afraid to miss the Junu timeframe if we will have to focus in
 supporting the numerical operators.

 Therefore we ask to support the non-numerical operators for Junu and add
 the numerical operators support post Junu.



 See
 https://review.openstack.org/#/c/99709/4/specs/juno/lbaas-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

Re: [openstack-dev] [Neutron][LBaaS] Which entities need status

[Stephen Balukoff]

, not the object, and I could argue
  multiple ways in which that should be one way or another based on the
  backend, which to me, again implies driver question (backend could
 queue
  for later, or error immediately, or let things run degraded, orŠ)

 Yeah that is definitely an argument.  I'm just trying to keep in mind
 the complexities that could arise from decisions made now.  Perhaps it
 is the wrong way to look at it to some, but I don't think thinking about
 the future is a bad thing and should never be done.

 
  Thanks,
  Doug
 
 
 
 
  On 6/24/14, 11:23 AM, Brandon Logan brandon.lo...@rackspace.com
 wrote:
 
  I think we missed this discussion at the meet-up but I'd like to bring
  it up here.  To me having a status on all entities doesn't make much
  sense, and justing having a status on a load balancer (which would be
 a
  provisioning status) and a status on a member (which would be an
  operational status) are what makes sense because:
  
  1) If an entity exists without a link to a load balancer it is purely
  just a database entry, so it would always be ACTIVE, but not really
  active in a technical sense.
  
  2) If some of these entities become shareable then how does the status
  reflect that the entity failed to create on one load balancer but was
  successfully created on another.  That logic could get overly complex.
  
  I think the best thing to do is to have the load balancer status
 reflect
  the provisioning 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 changed and the load
  balancer's status is in a non-ACTIVE state then that update should not
  be allowed.
  
  Thoughts?
  
  Thanks,
  Brandon
  
  
  ___
  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



 ___
 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

Re: [openstack-dev] Should TLS settings for listener be set through separate API/model?

[Stephen Balukoff]

The separate entity makes sense for certificates participating in an SNI
configuration, but probably not so much for the 'default' certificate used
when TLS is being terminated.

Vijay: You're also right that other TLS-related attributes will probably
get added to the Listener object. This probably makes sense if they apply
to the Listener object as a whole. (This includes things like TLS version
and cipher selection.)

I don't see much of a point in creating a separate object to contain these
fields, since it would have a 1:1 relationship with the Listener. It's true
that for non-TLS-terminated Listeners, these fields wouldn't be used, but
isn't that already the case in many other objects (not just in the Neutron
LBaaS sub project)?

Thanks,
Stephen




On Mon, Jun 23, 2014 at 9:54 AM, Brandon Logan brandon.lo...@rackspace.com
wrote:

 Vijay,
 I think the separate entity is still going to happen.  I don't think it
 has remvoed.  Or that is may just be my assumption.

 Thanks,
 Brandon

 On Mon, 2014-06-23 at 15:59 +, Vijay Venkatachalam wrote:
  Hi:
 
 
  In the “LBaaS TLS termination capability specification” proposal
 
  https://review.openstack.org/#/c/98640/
 
  TLS settings like default certificate container id and SNI cert list are
 part of the listener properties.
 
  I think it is better to have this as a separate entity so that the
 listener properties are clean and is not “corrupted” with TLS settings.
 
  I liked the original SSL proposal better where TLS settings was a
 separate entity.
 
  It is just 2 properties now but in future the TLS settings would grow
 and if we are going to introduce a TLS profile/params/settings entity
 later, it is better to do it now (albeit with min properties).
 
  Thanks,
  Vijay V.
  ___
  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

Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?

[Stephen Balukoff]

Also to add to pros for 2:

* Keeping the TLS stuff contained to its own objects means we can have
separate development resources on each and not worry as much about
overlapping domains. (TLS-related knowledge and knowledge of dealing with
TCP / UDP listeners are separate knowledge domains. Or at least, the former
is a more specialized subset of the latter.)

Note that what we're proposing means there's essentially a 1:0-1
relationship between Listener and this new yet-to-be-named object. (0 in
case the Listener is not terminating TLS.)

Stephen

On Mon, Jun 23, 2014 at 3:38 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:

 Whoops, [Neutron][LBaaS] got taken out of the subject line here.
 Putting it back in.

 On Mon, 2014-06-23 at 21:10 +, Brandon Logan wrote:
  Okay so we've talked a bit about this in IRC and now I'm sending this
  out as an update.  Here are the options with pros and cons that have
  come from that discussion.
 
  1) default_certificate_id is an attribute of the Listener object.
 
  Pros:
  -No extra entity needed
 
  Cons:
  -May bloat Listener object when more attributes are needed for only TLS
  termination.  Sounds like TLS version and cipher selection will be
  needed attributes in the future.
 
 
  2) A separate TLS Entity is created that is referenced by the Listener
  object.  This entity at first may only contain a certificate_id that
  references barbican.  Name and description can be allowed as well.
 
  Pros:
  -TLS domain specific attributes contained in its own entity
  -Future attributes would just be added to this entity and not bloat the
  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-06-23 at 12:15 -0700, Stephen Balukoff wrote:
   The separate entity makes sense for certificates participating in an
   SNI configuration, but probably not so much for the 'default'
   certificate used when TLS is being terminated.
  
  
   Vijay: You're also right that other TLS-related attributes will
   probably get added to the Listener object. This probably makes sense
   if they apply to the Listener object as a whole. (This includes things
   like TLS version and cipher selection.)
  
  
   I don't see much of a point in creating a separate object to contain
   these fields, since it would have a 1:1 relationship with the
   Listener. It's true that for non-TLS-terminated Listeners, these
   fields wouldn't be used, but isn't that already the case in many other
   objects (not just in the Neutron LBaaS sub project)?
  
  
   Thanks,
   Stephen
  
  
  
  
  
  
   On Mon, Jun 23, 2014 at 9:54 AM, Brandon Logan
   brandon.lo...@rackspace.com wrote:
   Vijay,
   I think the separate entity is still going to happen.  I don't
   think it
   has remvoed.  Or that is may just be my assumption.
  
   Thanks,
   Brandon
  
   On Mon, 2014-06-23 at 15:59 +, Vijay Venkatachalam wrote:
Hi:
   
   
In the “LBaaS TLS termination capability specification”
   proposal
   
https://review.openstack.org/#/c/98640/
   
TLS settings like default certificate container id and SNI
   cert list are part of the listener properties.
   
I think it is better to have this as a separate entity so
   that the listener properties are clean and is not “corrupted”
   with TLS settings.
   
I liked the original SSL proposal better where TLS settings
   was a separate entity.
   
It is just 2 properties now but in future the TLS settings
   would grow and if we are going to introduce a TLS
   profile/params/settings entity later, it is better to do it
   now (albeit with min properties).
   
Thanks,
Vijay V.
  
___
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
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list

Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?

[Stephen Balukoff]

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?


On Mon, Jun 23, 2014 at 6:03 PM, Doug Wiegley do...@a10networks.com wrote:

  Put me down for being in favor of option 1.

  A single attribute in 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 sbaluk...@bluebox.net
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: Monday, June 23, 2014 at 5:25 PM
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for
 listener be set through separate API/model?

   Also to add to pros for 2:

  * Keeping the TLS stuff contained to its own objects means we can have
 separate development resources on each and not worry as much about
 overlapping domains. (TLS-related knowledge and knowledge of dealing with
 TCP / UDP listeners are separate knowledge domains. Or at least, the former
 is a more specialized subset of the latter.)

  Note that what we're proposing means there's essentially a 1:0-1
 relationship between Listener and this new yet-to-be-named object. (0 in
 case the Listener is not terminating TLS.)

  Stephen

 On Mon, Jun 23, 2014 at 3:38 PM, Brandon Logan 
 brandon.lo...@rackspace.com wrote:

 Whoops, [Neutron][LBaaS] got taken out of the subject line here.
 Putting it back in.

 On Mon, 2014-06-23 at 21:10 +, Brandon Logan wrote:
  Okay so we've talked a bit about this in IRC and now I'm sending this
  out as an update.  Here are the options with pros and cons that have
  come from that discussion.
 
  1) default_certificate_id is an attribute of the Listener object.
 
  Pros:
  -No extra entity needed
 
  Cons:
  -May bloat Listener object when more attributes are needed for only TLS
  termination.  Sounds like TLS version and cipher selection will be
  needed attributes in the future.
 
 
  2) A separate TLS Entity is created that is referenced by the Listener
  object.  This entity at first may only contain a certificate_id that
  references barbican.  Name and description can be allowed as well.
 
  Pros:
  -TLS domain specific attributes contained in its own entity
  -Future attributes would just be added to this entity and not bloat the
  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-06-23 at 12:15 -0700, Stephen Balukoff wrote:
   The separate entity makes sense for certificates participating in an
   SNI configuration, but probably not so much for the 'default'
   certificate used when TLS is being terminated.
  
  
   Vijay: You're also right that other TLS-related attributes will
   probably get added to the Listener object. This probably makes sense
   if they apply to the Listener object as a whole. (This includes things
   like TLS version and cipher selection.)
  
  
   I don't see much of a point in creating a separate object to contain
   these fields, since it would have a 1:1 relationship with the
   Listener. It's true that for non-TLS-terminated Listeners, these
   fields wouldn't be used, but isn't that already the case in many other
   objects (not just in the Neutron LBaaS sub project)?
  
  
   Thanks,
   Stephen
  
  
  
  
  
  
   On Mon, Jun 23, 2014 at 9:54 AM, Brandon Logan
   brandon.lo...@rackspace.com wrote:
   Vijay,
   I think the separate entity is still going to happen.  I don't
   think it
   has remvoed.  Or that is may just be my assumption.
  
   Thanks,
   Brandon
  
   On Mon, 2014-06-23 at 15:59 +, Vijay Venkatachalam wrote:
Hi:
   
   
In the “LBaaS TLS termination capability specification”
   proposal
   
https://review.openstack.org/#/c/98640/
   
TLS settings like default certificate container id and SNI
   cert list are part of the listener properties.
   
I think it is better to have this as a separate entity so
   that the listener properties are clean and is not “corrupted”
   with TLS settings.
   
I liked the original SSL proposal better where TLS settings
   was a separate entity.
   
It is just 2 properties now but in future the TLS settings
   would grow and if we are going to introduce a TLS
   profile/params/settings entity later, it is better to do it
   now (albeit with min properties).
   
Thanks,
Vijay V

Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?

[Stephen Balukoff]

Actually, I should say: The only thing I care about on this is that we not
delay getting TLS implemented over what are really minor details like this.
(I know we're likely going to be delayed by changes that need to happen on
the barbican side since they're pretty extensive. But it seems silly to
spend much energy on something so minor right now.)


On Mon, Jun 23, 2014 at 6:25 PM, Stephen Balukoff sbaluk...@bluebox.net
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?


 On Mon, Jun 23, 2014 at 6:03 PM, Doug Wiegley do...@a10networks.com
 wrote:

  Put me down for being in favor of option 1.

  A single attribute in 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 sbaluk...@bluebox.net
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: Monday, June 23, 2014 at 5:25 PM
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for
 listener be set through separate API/model?

   Also to add to pros for 2:

  * Keeping the TLS stuff contained to its own objects means we can have
 separate development resources on each and not worry as much about
 overlapping domains. (TLS-related knowledge and knowledge of dealing with
 TCP / UDP listeners are separate knowledge domains. Or at least, the former
 is a more specialized subset of the latter.)

  Note that what we're proposing means there's essentially a 1:0-1
 relationship between Listener and this new yet-to-be-named object. (0 in
 case the Listener is not terminating TLS.)

  Stephen

 On Mon, Jun 23, 2014 at 3:38 PM, Brandon Logan 
 brandon.lo...@rackspace.com wrote:

 Whoops, [Neutron][LBaaS] got taken out of the subject line here.
 Putting it back in.

 On Mon, 2014-06-23 at 21:10 +, Brandon Logan wrote:
  Okay so we've talked a bit about this in IRC and now I'm sending this
  out as an update.  Here are the options with pros and cons that have
  come from that discussion.
 
  1) default_certificate_id is an attribute of the Listener object.
 
  Pros:
  -No extra entity needed
 
  Cons:
  -May bloat Listener object when more attributes are needed for only TLS
  termination.  Sounds like TLS version and cipher selection will be
  needed attributes in the future.
 
 
  2) A separate TLS Entity is created that is referenced by the Listener
  object.  This entity at first may only contain a certificate_id that
  references barbican.  Name and description can be allowed as well.
 
  Pros:
  -TLS domain specific attributes contained in its own entity
  -Future attributes would just be added to this entity and not bloat the
  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-06-23 at 12:15 -0700, Stephen Balukoff wrote:
   The separate entity makes sense for certificates participating in an
   SNI configuration, but probably not so much for the 'default'
   certificate used when TLS is being terminated.
  
  
   Vijay: You're also right that other TLS-related attributes will
   probably get added to the Listener object. This probably makes sense
   if they apply to the Listener object as a whole. (This includes
 things
   like TLS version and cipher selection.)
  
  
   I don't see much of a point in creating a separate object to contain
   these fields, since it would have a 1:1 relationship with the
   Listener. It's true that for non-TLS-terminated Listeners, these
   fields wouldn't be used, but isn't that already the case in many
 other
   objects (not just in the Neutron LBaaS sub project)?
  
  
   Thanks,
   Stephen
  
  
  
  
  
  
   On Mon, Jun 23, 2014 at 9:54 AM, Brandon Logan
   brandon.lo...@rackspace.com wrote:
   Vijay,
   I think the separate entity is still going to happen.  I
 don't
   think it
   has remvoed.  Or that is may just be my assumption.
  
   Thanks,
   Brandon
  
   On Mon, 2014-06-23 at 15:59 +, Vijay Venkatachalam wrote:
Hi:
   
   
In the “LBaaS TLS termination capability specification”
   proposal
   
https://review.openstack.org/#/c/98640/
   
TLS settings like default certificate container id and SNI
   cert list are part of the listener properties.
   
I think it is better to have this as a separate entity so
   that the listener properties are clean and is not “corrupted”
   with TLS settings.
   
I liked the original SSL

Re: [openstack-dev] [Octavia] PTL and core team members

[Stephen Balukoff]

Hi Brandon,

Yep, that sounds like a good way to approach this. And FWIW, this week I'm
planning on moving several of the designs I've presented to the group into
blueprints / gerrit specs for the project and otherwise start working on a
roadmap to actually get the thing built.

In the mean time, there's still a ton that needs to be done on the Neutron
LBaaS side of things to make sure we get feature improvements and cleaner
Neutron API interfaces in before the Juno freeze. So I don't think there's
a reason anyone should be idle working on these two projects, eh.

Stephen


On Sun, Jun 22, 2014 at 11:38 AM, Brandon Logan brandon.lo...@rackspace.com
 wrote:

 I'm thinking we are going to need more than 2 on the core team at first
 but it is hard to tell exactly how many people will be contributing code
 at first.  I know we've got a lot of interested parties and the
 possibility that some 10+ people are actively contributing.  Of course,
 these things can only be predicted and will be unknown until it is
 actually known.

 Also, we really need to have a good plan of action.  Once we get a
 consensus on the design we should start breaking the implementation up
 into umbrella blueprint specs (or epic blueprint specs) with each one
 detailing the bigger picture and breaking up the bigger picture into
 smaller tasks/stories that can be accomplished.  Then people can start
 choosing which they would like to implement.  Sounds good in theory, but
 actually executing it will be the tough part.

 Thanks,
 Brandon

 On Sun, 2014-06-22 at 13:42 +0200, Flavio Percoco wrote:
  On 20/06/14 07:29 +0100, Mark McLoughlin wrote:
  On Thu, 2014-06-19 at 20:36 -0700, Dustin Lundquist wrote:
   Dolph,
  
  
   I appreciate the suggestion. In the mean time how does the review
   process work without core developers to approve gerrit submissions?
  
  If you're just getting started, have a small number (possibly just 1 to
  begin with) of developers collaborate closely, with the minimum possible
  process and then use that list of developers as your core review team
  when you gradually start adopting some process. Aim to get from zero to
  bootstrapped with that core team in a small number of weeks at most.
  
  Minimum possible process could mean a git repo anywhere that those
  initial developers have direct push access to. You could use stackforge
  from the beginning and the developers just approve their own changes,
  but that's a bit annoying.
 
  +1 this is how we did it in Marconi (except for the repo with push
  access). At the beginning, we kept a core team of 2 developers despite
  there being at least 4 ppl working on the project. This allowed the
  team to have better discussions on what got in the repo and what not.
 
  One benefit of using stackforge is that you get a great CI system to
  test your project with but the development will slow down for sure. We
  started on stackforge right away, then had a 2 days hackathon on a
  github fork which was not a good idea because we had to submit al
  those patches for review after the hackathon. :(
 
  Flavio
 
  ___
  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

Re: [openstack-dev] [Neutron][LBaaS] Great Mid-cycle Sprint

[Stephen Balukoff]

+1 to what Brandon just said. :)

Seriously, though-- this week was nothing short of amazing! It's great to
have such a wonderful team to work with, eh! And yes-- special thanks to
Mark McClain and Kyle Mestery for being willing to come out and work so
hard with us to make so much progress in such little time.

LBaaS in Juno is going to kick ass!

Stephen


On Thu, Jun 19, 2014 at 9:17 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:

 Greetings all,
 I'd like to thank everyone who attended the LBaaS mid-cyle sprint for
 taking the time and effort to make the trip to San Antonio.  This was a
 very productive sprint in all forms: direction, consensus, blueprints,
 documentation, and of course code.  It was just great to be able to get
 so much done and have a clearer idea on the direction this project is
 headed.

 I'd like to especially thank Kyle Mestery and Mark Mcclain for taking
 the time out of their busy schedules to direct, teach, and giving us
 help where and when we needed.  The fact that they managed to have the
 patience for three full days of this is just amazing.  Actually, them
 having the patience over the last few months and still willing to help
 is just short of miraculous.  Thanks again guys, you are great!

 I look forward to continuing to work with everyone on this and other
 projects.  We've got a lot to do but we'll be able to accomplish
 everything we want if we continue to work together.  Thanks again to all
 involved!

 Brandon

 ___
 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

[openstack-dev] [Neutron][LBaaS] and [Octavia] haproxy-1.5.0 is out

[Stephen Balukoff]

 of /devel/
for the sources and the introduction of haproxy-1.5.git since this is
not the development tree anymore :

  Site index   : http://www.haproxy.org/
  Sources  : http://www.haproxy.org/download/1.5/src/
  Git repository   : http://git.haproxy.org/git/haproxy-1.5.git/
  Git Web browsing : http://git.haproxy.org/?p=haproxy-1.5.git
  Changelog: http://www.haproxy.org/download/1.5/src/CHANGELOG
  Cyril's HTML doc :
http://cbonte.github.com/haproxy-dconv/configuration-1.5.html

I'm figuring that tomorrow is Friday. Guys, be reasonable, don't forget the
good old principle of not upgrading on Fridays, try to hold on till monday
if you can :-)

BTW, since I've got this question off-list a number of times now, yes we're
going to release updated HAPEE packages very soon, please keep an eye on it
:

https://www.haproxy.com/products/haproxy-enterprise-edition/

And finally the changelog since 1.5-dev26.

Have fun an as usual, please report anything abnormal you'd face up, but
after checking the doc.

Willy


2014/06/19 : 1.5.0
- MEDIUM: ssl: ignored file names ending as '.issuer' or '.ocsp'.
- MEDIUM: ssl: basic OCSP stapling support.
- MINOR: ssl/cli: Fix unapropriate comment in code on 'set ssl
ocsp-response'
- MEDIUM: ssl: add 300s supported time skew on OCSP response update.
- MINOR: checks: mysql-check: Add support for v4.1+ authentication
- MEDIUM: ssl: Add the option to use standardized DH parameters = 1024
bits
- MEDIUM: ssl: fix detection of ephemeral diffie-hellman key exchange
by using the cipher description.
- MEDIUM: http: add actions replace-header and replace-values in
http-req/resp
- MEDIUM: Break out check establishment into connect_chk()
- MEDIUM: Add port_to_str helper
- BUG/MEDIUM: fix ignored values for half-closed timeouts (client-fin
and server-fin) in defaults section.
- BUG/MEDIUM: Fix unhandled connections problem with systemd daemon
mode and SO_REUSEPORT.
- MINOR: regex: fix a little configuration memory leak.
- MINOR: regex: Create JIT compatible function that return match strings
- MEDIUM: regex: replace all standard regex function by own functions
- MEDIUM: regex: Remove null terminated strings.
- MINOR: regex: Use native PCRE API.
- MINOR: missing regex.h include
- DOC: Add Exim as Proxy Protocol implementer.
- BUILD: don't use type uint which is not portable
- BUILD: stats: workaround stupid and bogus -Werror=format-security
behaviour
- BUG/MEDIUM: http: clear CF_READ_NOEXP when preparing a new transaction
- CLEANUP: http: don't clear CF_READ_NOEXP twice
- DOC: fix proxy protocol v2 decoder example
- DOC: fix remaining occurrences of pattern extraction
- MINOR: log: allow the HTTP status code to be logged even in TCP
frontends
- MINOR: logs: don't limit HTTP header captures to HTTP frontends
- MINOR: sample: improve sample_fetch_string() to report partial
contents
- MINOR: capture: extend the captures to support non-header keys
- MINOR: tcp: prepare support for the capture action
- MEDIUM: tcp: add a new tcp-request capture directive
- MEDIUM: session: allow shorter retry delay if timeout connect is small
- MEDIUM: session: don't apply the retry delay when redispatching
- MEDIUM: session: redispatch earlier when possible
- MINOR: config: warn when tcp-check rules are used without option
tcp-check
- BUG/MINOR: connection: make proxy protocol v1 support the UNKNOWN
protocol
- DOC: proxy protocol example parser was still wrong
- DOC: minor updates to the proxy protocol doc
- CLEANUP: connection: merge proxy proto v2 header and address block
- MEDIUM: connection: add support for proxy protocol v2 in accept-proxy
- MINOR: tools: add new functions to quote-encode strings
- DOC: clarify the CSV format
- MEDIUM: stats: report the last check and last agent's output on the
CSV status
- MINOR: freq_ctr: introduce a new averaging method
- MEDIUM: session: maintain per-backend and per-server time statistics
- MEDIUM: stats: report per-backend and per-server time stats in HTML
and CSV outputs
- BUG/MINOR: http: fix typos in previous patch
- DOC: remove the ultra-obsolete TODO file
- DOC: update roadmap
- DOC: minor updates to the README
- DOC: mention the maxconn limitations with the select poller
- DOC: commit a few old design thoughts files






-- 
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

Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit

[Stephen Balukoff]

Hi Samuel,

Yes, it's more friendly to extract this information on behalf of the user,
but does occasionally break use cases we've seen. It should be possible,
when there is hostname overlap, for the user to specify which certificate
to use. It sounds like the Radware solution uses certificate ordering to
resolve this conflict.

stunnel requires the user to specify which certs should be used with which
hostnames, and I think balks if you try to repeat a hostname. So in
stunnel's case, conflict resolution happens through user configuration.

So in both cases, the user specifies some way to do conflict resolution.

There's not a reason we couldn't do it the Radware way for stunnel. The
algorithm would be:
1. Order configured certificates based on the 'order' attribute.
2. One by one in sequence, extract CN and Subject Alternative Names from
the certificates.
3. If a conflict arises, do not allow certs later in the sequence to
supersede / override hostnames set earlier in the sequence.

However, I'm not sure it's possible to do the opposite (ie. stunnel way)
for Radware and get exactly similar behavior.

People should be aware that we are potentially catering to one vendor's
needs here by adopting the above conflict resolution / certificate hostname
extraction model.

In any case, it is probably still very handy to show the list of hostnames
for which each certificate is valid to the user (ie. in UI's or whatever).

What do people think?

Stephen


On Thu, Jun 19, 2014 at 12:03 AM, Samuel Bercovici samu...@radware.com
wrote:

  Hi Stephen,



 The difference is whether the user get to specify hostnames or whether
 this get concluded from the certificate.

 I agree, that it might be more friendly if we have an immutable hostname
 field that get cached in lbaas but being read from the certificate and not
 managed by the end user.



 -Sam.







 *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net]
 *Sent:* Thursday, June 19, 2014 1:44 AM

 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document
 on Gerrit



 So... what I'm hearing here is that we might want to support both a
 'hostname' and 'order' attribute. Though exact behavior from vendor to
 vendor when there is name overlap is not likely to be consistent.



 Note that while we have seen that corner case, it is unusual... so I'm not
 against having slightly different behavior when there's name overlap from
 vendor to vendor.



 Stephen



 On Wed, Jun 18, 2014 at 2:15 PM, Samuel Bercovici samu...@radware.com
 wrote:

 Hi Stephen,



 Radware Alteon extract the hostname information and the alt subjectAltName
 from the certificate information.

 It then do:

 1.  Find if there is exact match with the name in the https handshake
 and the ones extracted from the certificate, if there are more than a
 single match, the 1st one in the order will be used

 2.  If no match was found than try to use the regexp hostname to
 match, if you have multiple matches, the 1st one will be used

 3.  If no match was found than try to use subjectAltName to match. If
 you have multiple matches, the 1st one will be used

 4.  If no match than use default certificate



 -Sam.









 *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net]
 *Sent:* Thursday, June 19, 2014 12:03 AM


 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document
 on Gerrit



 Hi Evg,



 I do not think stunnel supports an ordered list without hostnames. Since
 we're talking about making the reference implementation use stunnel for TLS
 termination, then this seems like it's important to support its behavioral
 model.



 It is possible to extract hostnames from the CN and x509v3 Subject
 Alternative Names in the certs, but, as has been discussed previously,
 these can overlap, and it's not always reliable to rely on this data from
 the certs themselves. So, while I have nothing against having an ordered
 certificate list, stunnel won't use the order here, and stunnel will likely
 have unexpected behavior if hostnames are duplicated.



 Would it work for Radware to simply order the (unique) hostnames
 alphabetically, and put any wildcard certificates at the end of the list?



 Also, while I'm loathe to ask for details on a proprietary system: How
 does Radware do SNI *without* hostnames? Isn't that entirely the point of
 SNI? Client sends a hostname, and server responds with the certificate that
 applies to that hostname?



 Thanks,

 Stephen



 On Wed, Jun 18, 2014 at 8:00 AM, Evgeny Fedoruk evge...@radware.com
 wrote:

 Hi Stephen,
 Regarding your comment related to SNI list management and behavior in the
 RST document:

 I understand the need to explicitly specify specific certificates for
 specific hostnames.
 However we need to deliver lowest common denominator for this feature
 which every vendor