Open Stack

On 03/02/2016 02:48 PM, Ptacek, MichalX wrote:
> 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 ?

It's really bad practice in my opinion.

> (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 ?

We like things done upstream, if networking-ovs-dpdk is part of
OpenStack, let's package it (and its dependencies) upstream too.

Do we have any blocker on that?


> 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.
> 

-- 
Emilien Macchi

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