[ovs-dev] question about availability of Centos 7.1 kernel support

[Ben Pfaff]

I recommend building a kernel module from master.

New features, such as support for new kernels, are always added on
master first.  Periodically we branch to a release branch, and then
release that branch after allowing some time to report and fix bugs.

We do not certify any version of OVS for any purpose.  If you wish to
have a certified version of OVS, you will have to obtain that
certification elsewhere.

On Fri, Apr 03, 2015 at 06:02:51PM -0700, Sabyasachi Sengupta wrote:
> 
> Well, the last released version of ovs-2.3.1 was in Dec/03/2014 (per NEWS)
> and there is no formal plan discussed about ovs-2.4 in any of the mailing
> lists. I see there is ovs-2.3.2 documented in NEWS with xxx suggesting there
> will be a release sometime in future. Unless there is a certified and tested
> refresh of ovs (ovs-2.3.2 or ovs-2.4), how would you expect ovs to build on
> latest Centos?
> 
> Trying to cherry-pick just the master patch for RHEL-7.1 as pointed out by
> Joe does not seem to work in branch-2.3. I can get back what else was needed
> to build branch-2.3 if there is a plan to make it available in ovs-2.3.2.
> 
> On Fri, 3 Apr 2015, Ben Pfaff wrote:
> 
> >On Fri, Apr 03, 2015 at 12:46:45PM -0700, Joe Stringer wrote:
> >>OVS userspace can work with the OVS kernel module distributed with the
> >>kernel. This provides a straightforward workaround.
> >>
> >>I don't understand the comment about updating the FAQ/NEWS version
> >>matrix. It already states that 2.3 supports Linux 2.6.32 to 3.14, and
> >>explicitly mentions that modified kernels like RHEL can break the
> >>build for the kernel module in the OVS tree.
> >>
> >>I briefly looked at this, and it involves more than just
> >>cherry-picking my commit from above. All of the required patches
> >>should be available on master, so it should be primarily a matter of
> >>figuring out exactly which commits need to be cherry-picked back to
> >>branch-2.3. If you're eager to look into exactly what's needed, that
> >>would be useful information; otherwise I expect that someone will look
> >>into it when they get some free cycles.
> >
> >We don't normally add support for new kernels to released branches.
> >