Hi Trevor,

thanks for sharing this minutes!
I would like to cooperate a bit to this project's developments, possibly
without ending up being just deadweight.

To this aim I have some comments inline.


On 18 August 2014 22:25, Trevor Vardeman <trevor.varde...@rackspace.com>

>  Agenda items are numbered, and topics, as discussed, are described
> beneath in list format.
>  1) Discuss future of Octavia in light of Neutron-incubator project
> proposal.
>     a) There are many problems with Neutron-Incubator as currently
> described

 Have you listed your concerns somewhere? AFAICT the incubator definition
is in progress and feedback is very valuable at this stage.

    b) The political happenings in Neutron leave our LBaaS patches under
> review unlikely to land in Juno

I am a bit disappointed if you feel like  you have been victims of
political discussions.
The truth in my opinion is much simpler, and is that most of the neutron
core team has prioritised features for achieving parity with nova-network
or increasing neutron scalability and reliability.
In my opinion the incubator proposal will improve this situation by making
the lbaas team a lot less dependent on the neutron core team.
Considering the level of attention the load balancing team has received I
would not be surprised if neutron cores are topping your most-hated list!

>      c) The Incubator proposal doesn't affect Octavia development
> direction, with inclination to distance ourselves from Neutron proper

It depends on what do you mean by "proper" here. If you're into a neutron
incubator, your ultimate path ideally should be integration with neutron.
Instead if you're planning on total independence, then it might the case of
considering the typical paths new projects follow. I'm not an expert here,
but I think that usually starts from stackforge.

>     d) With the Neutron Incubator proposal in current scope, efforts of
> people pushing forward Neutron LBaaS patches should be re-focused into
> Octavia.

Which probably sounds a reasonable thing to do (and a lot less effort for
you as well)

>  2) Discuss operator networking requirements (carry-over from last week)
>     a) Both HP and Rackspace seem to agree that as long as Octavia uses
> Neutron-like floating IPs, their networks should be able to work with
> proposed Octavia topologies
>     b) (Blue Box) also wanted to meet with Rackspace's networking team
> during 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
Moreover, you'd get minutes for free - and you can control the density you
want them to have during the meeting!

>      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

Reply via email to