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
Yes!!
(or be patient and wait for other downstream folks to do the same).
--
Raymond Burkholder
r...@oneunified.net
https://blog.raymond.burkholder.net
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
