[ovs-dev] packaging

Raymond Burkholder ray at oneunified.net
Thu Apr 19 00:18:24 UTC 2018

On 04/17/2018 06:19 PM, Ben Pfaff wrote:
> On Sat, Apr 14, 2018 at 12:19:02PM -0300, Raymond Burkholder wrote:
>> On 04/13/2018 02:52 PM, Ben Pfaff wrote:
>>> I'm quite sympathetic to that viewpoint--I think that OVS currently has
>>> far too much distro-specific stuff in it.  In the long run I'd like to
>>> drop the Debian and Red Hat and XenServer packaging from the tree.  As a
>> How would it work then, if, ..  I enjoy the fact that I can run Master, use
>> the tools in the tree to build my Debian packages, and then install those
>> packages on the machines where they need to be?
>>> Debian developer myself, I know that it's not actually helpful for
>>> upstream to provide packaging.

Ok, I got things backwards in my older comments, based upon your 
upstream/downstream definitions further down.

Are you saying that Debian maintainers for the actual distribution 
maintenance 'throw out' your packaging, and have their own packaging? 
Wouldn't they use the tooling your provide?

>> And if by upstream, you mean the distribution?  They can be quite behind at
>> times.  Debian Stretch has 2.6, and nothing in Stretch-Backports. Buster
>> does have 2.8 at the moment, but Buster can be very unstable for
>> consistently building environments on demand.
> In this case, by "upstream" I mean OVS developers and by "downstream" I
> mean a distribution such as Debian or Red Hat.

ok, got it.

> There's a couple of things going on here.
> One is that I think there is much less pressure than usual on downstream
> to keep OVS packaging up-to-date because we maintain packaging
> upstream.  I think that if OVS upstream stopped shipping packaging,
> downstreams would eventually adapt by updating packaging more
> frequently.

But wouldn't your packaging provide good hints on what needs to be 
performed downstream?  open vswitch does have a complicated built based 
upon the dkms modules, et.al.

> Also, I suspect that most users run from a release or at least a release
> branch.  On a release branch, usually the packaging changes little, or
> at least the packaging changes due to OVS changes are minimal, since OVS
> itself doesn't change much on release branches.

I guess I couldn't be counted in the 'most' category.  Have you had 
private feedback?  I don't think I've seen any other feedback messages 
for this topic on this mailing list.

> I currently have a selfish reason to keep packaging in the tree, which
> is that VMware internally uses both the .deb and .rpm packaging as part
> of its internal processes (and releases to customers).  We're working on

I thank you for that, and I whole-heartedly hope you continue to offer 
the debian packaging in the tree.

> getting together and contributing to OVS a container build and making
> that what we use internally and provide to customers.  So I have
> motivation to make sure that the containerization is good quality too,
> since otherwise customers will be unhappy.  (At that point, I'll be
> happy to transition to emeritus status as a Debian developer, since
> being able to directly contribute to OVS downstream packaging--which I
> do badly--is about the only reason I stick around there after 20+

one person's 'badly' is still way-much better than not having it all, 
'specially with the complicated build.

Sorry, if I am laying it on too thick.

> years.)
> So, if we do manage to get rid of packaging, it'll only be because
> there's an acceptable alternative.  Your options will basically be:
> * Use the containers, for any branch or master.  We might even publish
>    binaries, dunno yet.  You can be sure they'll be pretty good since
>    we'll actually use them too.

containers wouldn't really do for me.  Wouldn't they be more complex to 
build anyway?  and are you talking docker, lxc, core, .... ?

My builds, at minimum, incorporate openvswitch, frr, .. plus a bunch of 
other choice packages to build an appropriate platform.  shoe-horning my 
additional stuff into a container doesn't seem quite right.

If it matters at all, I use SaltStack to build assemble the packages and 
configurations for the varied appliances (physical, virtual, and 
containerized) I customize.  So packages are a perfect fit.

And your Master branch seems to be relatively stable, knock on wood, so 
running that seems to work out.

> * Use packaging from your favored distro, for some release branch.

is possible, but as I mentioned earlier, they could be a number of 
versions behind, even in 'testing' flavours

> * Help out downstream with keeping the packaging up-to-date with master


>    (or be patient and wait for other downstream folks to do the same).

Raymond Burkholder
ray at oneunified.net

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

More information about the dev mailing list