Open Stack

On 01/14/2016 12:38 AM, Matthew Treinish wrote:
> On Wed, Jan 13, 2016 at 10:47:21PM +0000, Sean M. Collins wrote:
>> On Wed, Jan 13, 2016 at 03:57:37PM CST, Mooney, Sean K wrote:
>>> One of the ideas that I have been thinking about over the last month or two is do we
>>> Want to create a dedicated library file in devstack to support compilation and installation
>>> Of ovs. 
>>
>> So, my suggestion is as follows: create a new devstack plugin that is
>> *specifically* geared towards just compiling OVS and installing it to
>> get the bits that you need.
> 
> +1, you do not want a monolithic plugin that does everything. Creating a
> separate small plugin to install ovs from source and the other pieces necessary
> for doing that is the best path for enabling this.
If I understand correctly, this requires to either create a new git
repository that just provides a function to compile ovs or add it to
some already existing project like ovs.

Given that we will likely not even use it with devstack but only in
gate_hook.sh for functional/ job, I don't see the point in creating new
repository for one bash function or any "small plugin".

I know it was me who originally put the code in the Neutron devstack
plugin. So seems like the thing we need to solve is "Where will it
live". How about creating a separate script in tools?

> 
>> I'm just concerned about the feature creep
>> that is happening in the Neutron DevStack plugin ( which I didn't like in
>> the first place ) where now every little thing is getting proposed
>> against it.
>>
>> I'd prefer to see small, very specific DevStack plugins that have narrow
>> focus, and jobs that need them for specific things adding them to their
>> local.conf settings explicitly via enable_repo lines.
> 
> This is the intended way to use plugins. Dumping everything but the kitchen
> sink into a single plugin is just going to tightly couple too much and lead
> to an undebugable tangled ball of yarn. The idea with plugins is to have
> smaller plugins that can be used in conjunction to configure and enable
> various additional pieces.
> 
>>
>> The concern I have with compiling bleeding edge OVS and then running our
>> Neutron jobs is that yes, we get new features, but yes we also get
>> the newest bugs and the configuration matrix for Neutron now gets a new
>> dimension of 'packaged OVS versus git commit SHA'
>>
> 
> I don't think you ever want to have a gating job with OVS from source.
> There is way too much potential instability when building something like this
> from source to rely on it. An experimental job would probably be as far as I
> would go with something like this. Going any further than that is just asking
> for trouble.
Experimental job sounds like the best candidate but it also brings
disadvantages like having the new code prone to regressions, as tests
for new features will need to be skipped in normal gate jobs.

In functional tests we don't use any complex scenarios on OVS. It mostly
tests interface drivers with simple steps like creating bridge and
plugging interface to it. I believe this is pretty basic thing that
works even in unstable development branch of OVS.

Thanks for ideas.
Kuba

> 
> -Matt Treinish
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>