[openstack-dev] [Quantum] [Nova] improving vif-plugging

Gary Kotton gkotton at redhat.com
Fri Jan 25 11:58:32 UTC 2013

On 01/25/2013 01:36 PM, Daniel P. Berrange wrote:
> On Fri, Jan 25, 2013 at 01:28:35PM +0200, Gary Kotton wrote:
>> On 01/25/2013 01:08 PM, Daniel P. Berrange wrote:
>>> On Fri, Jan 25, 2013 at 01:03:33PM +0200, Gary Kotton wrote:
>>>> On 01/25/2013 01:00 PM, Daniel P. Berrange wrote:
>>>>> On Thu, Jan 24, 2013 at 10:58:43AM -0800, Dan Wendlandt wrote:
>>>>>>> Maybe we should just make Nova pass across its list of supported
>>>>>>> vif types during 'create port' regardless of whether we need it
>>>>>>> now and be done with it.
>>>>>> Yes, this is what I was thinking as well.  Somewhat of a "negotiation"
>>>>>> where Nova sends a certain amount of information over (e.g., its supported
>>>>>> vif_types, its node-id) and then Quantum can determine what vif_type to
>>>>>> respond with.  I'm thinking that node-id may be needed to handle the case
>>>>>> where Quantum needs to respond with different data even for the same
>>>>>> vif_type (e.g., two different esx clusters that have different
>>>>>> port-group-ids).
>>>>>> This adds some more complexity to Quantum, as the centralized
>>>>>> quantum-server must know the mapping from a node-id to bridge-id +
>>>>>> vif_type, but some part of the Quantum plugin must know this information
>>>>>> already (e.g., an agent), so it would really just be a matter of shifting
>>>>>> bits around within Quantum, which seems reasonable given time to implement
>>>>>> this.
>>>>> Ok, so the only thing to worry about now is timing. Is it reasonable to
>>>>> get this enhancement done for Grizzly, so that I can safely deprecate
>>>>> the VIF plugins in libvirt, or do we need to wait for one more cycle
>>>>> meaning I should remove the deprecation log messages temporarily ?
>>>> I am in favour of removing the deprecation log messages.
>>> On what basis ? Whether the deprecation messages are appropriate or
>>> not depends on whether we can do the enhancements described above
>>> for Grizzly or not. Are you saying we can't do those enhancements
>>> for Grizzly ?
>> First and foremost I do not think that you should force a user to
>> change their configuration when upgrading. This defeats the purpose
>> in my opinion. I have stated that from the start of this
>> development. Not sure if others agree here.
> This is *not* forcing the user to change this configuration when
> upgrading to Grizzly. I explicitly kept backwards compatibility
> with Folsom, so that they can upgrade without changes. What we're
> doing is giving them prior warning that they will need to make a
> change at some point when they deploy the following Hxxxxx release.

The backward compatibility is great and is appreciated.

> Historically Nova releases have just unconditionally removed
> existing config parameters requiring an immediate, unanounnced
> change by people deploying. I agree that this is a bad approach.
> We can't commit to supporting every single config parameter for
> all time though. We need to be able to remove things that no longer
> make sense to remain. Having a deprecation warning for one release
> cycle prior to the change is the right balance IMHO.

We can agree to disagree. Folsom Nova/Quantum is used today in 
production. I do not think that we should force a user to make any 
changes to their configuration to ensure that things continue to work - 
in my opinion this is only in extreme circumstances and should be very 
well documented. Digging in log files to find that a configuration 
variable is no longer supported is like looking for a needle in a haystack.

> Regards,
> Daniel

More information about the OpenStack-dev mailing list