Open Stack

+1 Kevin. I really fail to see how a patch which has been ready for a long
time now is the worst enemy of Nova Parity. This is starting to feel kind
of ad-hoc...
On Aug 6, 2014 11:42 PM, "Kevin Benton" <blak111 at gmail.com> wrote:

> >In all seriousness, folks, I'm bringing up points about the proposed API
> because I see the current mess of Neutron integration with Nova, I see that
> nova-network has been "undeprecated" due to continuing lack of parity and
> HA concerns in Neutron, and I want things to be better, not worse.
>
> Again, I haven't seen any evidence that ongoing development of this new
> API is preventing any of the parity work from happening. Nobody is
> advocating that the parity work be delayed because of this. We are all
> aware of the threats the TC has put forth with regard to demoting Neutron
> to incubation unless the parity demands are met. If you want ongoing
> development to stop, this should be a clear requirement and it should be
> evenly applied to all work (LBaaS separation, ML2 enhancements, any third
> party drivers, etc).
>
>
>
> On Wed, Aug 6, 2014 at 3:10 PM, Jay Pipes <jaypipes at gmail.com> wrote:
>
>> On 08/06/2014 04:51 PM, Pedro Marques wrote:
>>
>>> Neutron allows vendors to speak to proprietary device APIs, it was
>>> designed to do so, AFAIK. It is also possibly to "entirely swap out
>>> all of the Neutron core"... the proponents of the group based policy
>>> didn't have to go through so much trouble if that was their intent.
>>> As far as i know most plugins talk to a proprietary API.
>>>
>>> I happen to disagree technically with a couple of choices made by
>>> this proposal; but the blueprint was approved. Which means that i
>>> lost the argument, or didn't raise it on time, or didn't argue
>>> convincingly... regardless of the reason, the time to argue about the
>>> goal has passed. The decision of the community was to approve the
>>> spec and that decision should be respected.
>>>
>>
>> Sure, no problem. I'll just go back to Nova and wait around to help clean
>> up the mess.
>>
>> In all seriousness, folks, I'm bringing up points about the proposed API
>> because I see the current mess of Neutron integration with Nova, I see that
>> nova-network has been "undeprecated" due to continuing lack of parity and
>> HA concerns in Neutron, and I want things to be better, not worse.
>>
>> Neutron contributors need to recognize that Nova is the pre-eminent
>> consumer of Neutron interfaces, and until those interfaces are stable,
>> consistent regardless of underlying hardware or driver choices, and
>> generally preferable for Nova to recommend as its default network driver,
>> then the Neutron project is sitting as an island unto itself.
>>
>> The fact that not enough Nova developers (including yours truly) are
>> paying attention to what is going on in Neutron spec-land and roadmap is a
>> serious problem we should deal with directly (cross-project spec meetings,
>> better documentation and communication, shared bug triaging and
>> verification meetings, etc). Otherwise, these kinds of conversations are
>> likely to continue.
>>
>> Best,
>> -jay
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Kevin Benton
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140806/7bf325b6/attachment.html>