Open Stack

On 11/23/2013 10:44 AM, Gary Kotton wrote:
> 
> 
> On 11/22/13 2:47 PM, "Daniel P. Berrange" <berrange at redhat.com> wrote:
> 
>> On Fri, Nov 22, 2013 at 11:25:51AM +0000, John Garbutt wrote:
>>>>> On Fri, Nov 15, 2013 at 2:21 PM, Russell Bryant <rbryant at redhat.com>
>>> wrote:
>>>>>>> In particular, has there been a decision made about whether it will
>>>>>>> definitely be deprecated in some (as yet unspecified) future
>>> release, or
>>>>>>> whether it will continue to be supported for the foreseeable
>>> future?
>>>>>>
>>>>>> We want to deprecate it.  There are some things blocking moving
>>> forward
>>>>>> with this.  In short:
>>>>>>
>>>>>> 1) Feature parity (primarily something that satisfies performance
>>> and HA
>>>>>> requirements addressed by nova-network in multi-host mode)
>>>>>>
>>>>>> 2) Testing and quality parity.  The status of Neutron testing in the
>>>>>> gate is far inferior to the testing done against nova-network.
>>>>>>
>>>>>> I'm personally more worried about #2 than #1 at this point.
>>>>>>
>>>>>> A major issue is that very few people actually stepped up and
>>> agreed to
>>>>>> help with #2 at the summit [2].  Only one person signed up to work
>>> on
>>>>>> tempest issues.  Nobody signed up to help with grenade.  If this
>>> doesn't
>>>>>> happen, nova-network can't be deprecated, IMO.
>>>>>>
>>>>>> If significant progress isn't made ASAP this cycle, and ideally by
>>>>>> mid-cycle so we can change directions if necessary, then we'll have
>>> to
>>>>>> discuss what next step to take.  That may include un-freezing
>>>>>> nova-network so that various people holding on to enhancements to
>>>>>> nova-network can start submitting them back.  It's a last resort,
>>> but I
>>>>>> consider it on the table.
>>>
>>> Another approach to help with (1) is in Icehouse we remove the
>>> features from nova-network that neutron does not implement. We have
>>> warned about deprecation for a good few releases, so its almost OK.
>>
>> We deprecated it on the basis that users would be able to do a upgrade
>> to new release providing something that was feature equivalent.
>>
>> We didn't deprecate it on the basis that we were going to remove the
>> feature and provide no upgrade path, leaving users screwed.
>>
>> So I don't consider removing features from nova-network to be an
>> acceptable approach, until they exist in Neutron or something else
>> that users can upgrade their existing deployments to.
> 
> As far as I see it the only thing that is missing for parity today is the
> HA for the floating IP's. A partial solution was added and this was
> dropped due to disagreement in the Neutron community. What I think that a
> lot of people miss is that the HA floating IP support in Nova is not
> really scalable and that is where the Neutron solution fills a void.

So this is one of the underlying issues. Even if the current Nova
solution has issues... it is the model of lots of deployments. So
Neutron should mirror that mode semantically exactly so that a
transition can take place.

After that, it can be made better. But we do keep running into places
where *better* is chosen over compatible, which is an underlying reason
for the the continued split between nova-network and neutron.

	-Sean

-- 
Sean Dague
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131125/e6b1f51f/attachment.pgp>