Open Stack

Thanks Emilien, 
It's becoming more clear to me what has to be done.
Did I get it correctly that using bash code inside puppet module is "nish nish" and will NOT be accepted by the community ?
(even if we move the logic into own module like openstack/ovs-dpdk)
Additionally building from the src or using own packages from such builds is also not possible in such modules even despite its performance or other functional benefits ?

best regards,
Michal

-----Original Message-----
From: Emilien Macchi [mailto:emilien at redhat.com] 
Sent: Wednesday, March 02, 2016 6:51 PM
To: Ptacek, MichalX <michalx.ptacek at intel.com>; 'OpenStack Development Mailing List (not for usage questions)' <openstack-dev at lists.openstack.org>; matt at mattfischer.com
Cc: Mooney, Sean K <sean.k.mooney at intel.com>; Czesnowicz, Przemyslaw <przemyslaw.czesnowicz at intel.com>
Subject: Re: [openstack-dev] [puppet] adding ovs dpdk agent into neutron



On 03/02/2016 03:07 AM, Ptacek, MichalX wrote:
> Hi all,
> 
>  
> 
> we have puppet module for ovs deployments with dpdk support
> 
> https://github.com/openstack/networking-ovs-dpdk/tree/master/puppet

IMHO that's a bad idea to use networking-ovs-dpdk for the puppet module.
You should initiate the work to create openstack/puppet-dpdk (not sure about the name) or try to patch openstack/puppet-vswitch.

How puppet-vswitch would be different from puppet-dpdk?

I've looked at the code and you run bash scripts from Puppet.
Really ? :-)

> and we would like to adapt it in a way that it can be used within 
> upstream neutron module
> 
> e.g. to introduce class like this
> 
> neutron::agents::ml2::ovsdpdk
> 
>  
> 
> Current code works as follows:
> 
> -          Openstack with installed vanilla ovs is a kind of precondition
> 
> -          Ovsdpdk puppet module installation is triggered afterwards
> and it replace vanilla ovs by ovsdpdk
> 
> (in order to have some flexibility and mostly due to performance 
> reasons we are building ovs from src code)
> 
> https://github.com/openstack/networking-ovs-dpdk/blob/master/puppet/ov
> sdpdk/files/build_ovs_dpdk.erb
> 
> -          As a part of deployments we have several shell scripts, which
> are taking care of build and configuration stuff
> 
>  
> 
> I assume that some parts of our code can be easily rewritten to start 
> using standard providers other parts might be rewritten to ruby …
> 
> We would like to introduce neutron::agents::ml2::ovsdpdk as adequate 
> solution with existing neutron::agents::ml2::ovs and not just patching it.
> 

What Puppet OpenStack group will let neutron::agents::ml2::ovsdpdk doing:

* configure what you like in /etc/neutron/*
* install what you want that is part of OpenStack/Neutron* (upstream).

What Puppet OpenStack group WILL NOT let neutron::agents::ml2::ovsdpdk
doing:

* install third party software (packages from some custom repositories, not upstream).
* build RPM/DEB from bash scripts
* build anything from bash scripts
* configure anything outside /etc/neutron/*

> 
> Actually I have following questions:
> 
> Q1) Will it be acceptable if we move build logic before deployment and 
> resulting rpm/deb will be installed instead of ovs package during 
> deployment ?

You should engage efforts to have upstream packaging in Ubuntu/Debian and Red Hat systems (RDO).

> Q2) Do we need to rewrite bash logic into ruby code ?

Drop bash scripts, and use upstream packages, like we do everywhere else.

> Q3) Do we need to raise separate blueprint, which has to be approved  
> before starting adaptations ?

Feel free to submit a blueprint so our group can be involved in this discussion, or maybe this thread is enough.
--
Emilien Macchi

--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.