Open Stack

> -----Original Message-----
> From: Emilien Macchi [mailto:emilien at redhat.com]
> Sent: Wednesday, March 2, 2016 8:33 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 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.

We use bash as the puppet module has evolved from our existing devstack plugin.
We are not a ruby house so we have resisted converting it until we had 
A valid business or costumer usecase. If it is required for upstreaming
Then that’s a good business/costumer requirement and it can be ported but
Our background is in c/python/bash so neither ruby or puppet are technologies we
Use frequently hence why we are reaching out not to understand how this should work
If it was to be upstreamed.
 
> > (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?

networking-ovs-dpdk is packaged on pip

debian and Ubuntu ship our kilo release in the distro.
I have reached out to redhat in the past to packaged it
But currently there has been no traction there.

I have not made a liberty release yet( I was waiting for a neutron patch to be back ported after
Another backport broke our security group driver)
But I hope to tag and release the 2.0.0 version to pip/pypi this month.

The 3.0.0 release for mitaka should be made in April around the time of the summit.


It would be nice to see the osp 9?  Or the Ubuntu cloud archive for mitaka pick up
The 3.0.0 release but I have little control over distro packaging but it will be
Available on pypi.


> 
> 
> > 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/o
> >> v
> >> 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