Bug 1269391 - MongoDB 3.0.6 is available and it's a hard upgrade
MongoDB 3.0.6 is available and it's a hard upgrade
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: mongodb (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Marek Skalický
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-07 04:01 EDT by Matthias Saou
Modified: 2015-11-22 19:25 EST (History)
8 users (show)

See Also:
Fixed In Version: mongodb-3.0.7-1.fc23
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-22 19:25:43 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthias Saou 2015-10-07 04:01:41 EDT
I have been using the latest Fedora mongodb packages to rebuild the latest upstream mongodb on RHEL7 for my own use.

Currently in Fedora we have mongodb 3.0.4 and wiredtiger 2.6.1, which *seem* to mostly work together (I have a couple running in production).

I have updated my own mongodb to 3.0.6 (the latest as of writing this), still with wiredtiger 2.6.1 (also the latest) and things started going wrong.

Here is my report upstream : https://jira.mongodb.org/browse/SERVER-20753

What comes out of it is this from the upstream developers is : "MongoDB should not be built with WiredTiger as a separate library except for test purposes." and "The short answer is that what you're trying to do is currently not supported, please see the link above for further details." Here is that link :

https://groups.google.com/forum/#!searchin/mongodb-dev/mongodb$20wiredtiger$20compatibility/mongodb-dev/31FQSo4KVCI/Fx-WtJ9fzU4J

I stopped seeing issues once I rebuilt it with the included wiredtiger snapshot (which for some reason is still closer to 2.5.3 than 2.6.1 but includes new things that will be in 2.6.2), and also specifying that the code is now C++11 with the following minor changes (pseudo-diff, also required in %install) :

 %build
 # see output of "scons --help" for options
+# mongodb 3.0.x refuses to support a shared wiredtiger library, so we can't use
+# --use-system-all
 scons all \
         %{?_smp_mflags} \
-        --use-system-all \
+        --use-system-tcmalloc \
+        --use-system-pcre \
+        --use-system-boost \
+        --use-system-snappy \
+        --use-system-zlib \
+        --use-system-v8 \
+        --use-system-stemmer \
+        --use-system-yaml \
         --variant-dir=build%{?dist} \

-        CCFLAGS="%{?optflags}" LINKFLAGS="%{?__global_ldflags}"
+        CCFLAGS="%{?optflags} -std=c++11" LINKFLAGS="%{?__global_ldflags}"

Given upstream's position, it seems like an exception will need to be granted in order to rebuild MongoDB with its included WiredTiger, as it's the only option moving forward.

Note also that I tried actually *removing* the directories for pcre, boost, snappy, zlib, v8, stemmer and yaml from the src/third_party/ of the source, and that broke everything since the build relies on custom SConscript files in there to know against which libraries to link + there are two places in the src/mongo/ tree where explicit #includes are made for libstemmer.h and yaml-cpp/yaml.h. The build actually ends up linking against the system-wide libstemmer and libyaml-cpp, but uses the included forked header during the compilation. I'm guessing a simple patch should fix this.

HTH!
Comment 1 Matthias Saou 2015-10-07 06:03:09 EDT
I just noticed that for RHEL7, I also had to update boost to boost-1.59.0-5.el7 in order to get 3.0.6 to compile and work. This won't be possible in EPEL7, so updating MongoDB 3.x in EPEL7 might no longer be possible, unless another exception is granted to use the included boost snapshot...
Comment 2 Marek Skalický 2015-10-07 07:09:09 EDT
(In reply to Matthias Saou from comment #0)
> I have been using the latest Fedora mongodb packages to rebuild the latest
> upstream mongodb on RHEL7 for my own use.
> 
> Currently in Fedora we have mongodb 3.0.4 and wiredtiger 2.6.1, which *seem*
> to mostly work together (I have a couple running in production).

Currently in Fedora (F23, Rawhide) there is MongoDB 3.0.6. In current Fedora 22 there is 2.6.x version...
MongoDB 3.0.4 was working with WT 2.6.1 because the difference with the bundled version was not so big. So not so long patch fixed it...
See patch - http://pkgs.fedoraproject.org/cgit/mongodb.git/tree/wiredtiger-2.6.patch

> 
> I have updated my own mongodb to 3.0.6 (the latest as of writing this),
> still with wiredtiger 2.6.1 (also the latest) and things started going wrong.
> 
> Here is my report upstream : https://jira.mongodb.org/browse/SERVER-20753
> 
> What comes out of it is this from the upstream developers is : "MongoDB
> should not be built with WiredTiger as a separate library except for test
> purposes." and "The short answer is that what you're trying to do is
> currently not supported, please see the link above for further details."
> Here is that link :
> 
> https://groups.google.com/forum/#!searchin/mongodb-dev/
> mongodb$20wiredtiger$20compatibility/mongodb-dev/31FQSo4KVCI/Fx-WtJ9fzU4J
> 
> I stopped seeing issues once I rebuilt it with the included wiredtiger
> snapshot (which for some reason is still closer to 2.5.3 than 2.6.1 but
> includes new things that will be in 2.6.2), and also specifying that the
> code is now C++11 with the following minor changes (pseudo-diff, also
> required in %install) :
> 

You are right that MongoDB bundles WiredTiger. Is is neither WT 2.5.3 or WT 2.6.x ... It is from branch mongodb-3.0 - https://github.com/wiredtiger/wiredtiger/tree/mongodb-3.0
It is based on 2.5.3 but there is a lot of changes included. It is not compatible with any official releases of WT.
And as you mentioned upstream don't support using system version of WT.

>  %build
>  # see output of "scons --help" for options
> +# mongodb 3.0.x refuses to support a shared wiredtiger library, so we can't
> use
> +# --use-system-all
>  scons all \
>          %{?_smp_mflags} \
> -        --use-system-all \
> +        --use-system-tcmalloc \
> +        --use-system-pcre \
> +        --use-system-boost \
> +        --use-system-snappy \
> +        --use-system-zlib \
> +        --use-system-v8 \
> +        --use-system-stemmer \
> +        --use-system-yaml \
>          --variant-dir=build%{?dist} \
> 
> -        CCFLAGS="%{?optflags}" LINKFLAGS="%{?__global_ldflags}"
> +        CCFLAGS="%{?optflags} -std=c++11" LINKFLAGS="%{?__global_ldflags}"
> 

Yes since 3.0.5 MongoDB needs to be build with c++11 support. It is already in Fedora 23 and Rawhide...
http://pkgs.fedoraproject.org/cgit/mongodb.git/commit/?h=f23&id=600c5372d084abdadef0e8c5fae7cd1c9853a92c

> Given upstream's position, it seems like an exception will need to be
> granted in order to rebuild MongoDB with its included WiredTiger, as it's
> the only option moving forward.

I totaly agree. I've already created FPC ticker for this https://fedorahosted.org/fpc/ticket/562
If you can somehow speed it up please do it...

> 
> Note also that I tried actually *removing* the directories for pcre, boost,
> snappy, zlib, v8, stemmer and yaml from the src/third_party/ of the source,
> and that broke everything since the build relies on custom SConscript files
> in there to know against which libraries to link + there are two places in
> the src/mongo/ tree where explicit #includes are made for libstemmer.h and
> yaml-cpp/yaml.h. The build actually ends up linking against the system-wide
> libstemmer and libyaml-cpp, but uses the included forked header during the
> compilation. I'm guessing a simple patch should fix this.
> 

Thanks for reporting. I will check it.

Marek
Comment 3 Marek Skalický 2015-10-07 10:01:49 EDT
(In reply to Matthias Saou from comment #1)
> I just noticed that for RHEL7, I also had to update boost to
> boost-1.59.0-5.el7 in order to get 3.0.6 to compile and work. This won't be
> possible in EPEL7, so updating MongoDB 3.x in EPEL7 might no longer be
> possible, unless another exception is granted to use the included boost
> snapshot...

Yes, that is the first reason.

Second, in my point of view more important. It is not supported to directly upgrade from MongoDB 2.4 to version 3.0! You have to upgrade to 2.6 first... - http://docs.mongodb.org/manual/release-notes/3.0-upgrade/

In EPEL6 there is MongoDB 2.4 and in EPEL7 there is MongoDB 2.6... so no problem with upgrade from EPEL6 to EPEL7.
However if EPEL7 have version 3.0 the upgrade from EPEL6 to EPEL7 wouldn't be possible.
Comment 4 Fedora Update System 2015-10-15 10:17:27 EDT
mongodb-3.0.7-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-0a1bfc5290
Comment 5 Marek Skalický 2015-10-15 10:31:43 EDT
There is MongoDB 3.0.7 in Fedora 23 and Rawhide now.
Comment 6 Fedora Update System 2015-10-15 16:53:56 EDT
mongodb-3.0.7-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update mongodb'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-0a1bfc5290
Comment 7 Marek Skalický 2015-10-19 04:57:04 EDT
Using bundled versions of some header files (to note: they does not differ from system ones) should be fixed in 3.0.7-2

There will be upgrade soon...
Comment 8 Fedora Update System 2015-11-22 19:25:38 EST
mongodb-3.0.7-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.