How to update to Discourse 1.0?


(Manthan Mallikarjun) #22

Quick question.

I ran the docker updater via /admin/dokcer. Does this automatically do everything mentioned in the OP? Do I still have to do it? In the control panel its showing that I am running 1.0.0 successfully. (Just want to make sure)

Also, when I try going to /admin/docker after the update, it just gives me a 404 error.


(Sam Saffron) #23

No, it is very important you get a new base image and follow all the steps above.

I do not know what base image you are on and our latest one is far more robust than the image I created a year ago. Now is a great time to sync up and use latest.


(ben_a_adams) #24

Wow! The discourse upgrade process with the docker system is a bit of a marvel now! Well done!

I’m wondering what the general upgrade vision is currently? There is the update page ( /admin/upgrade ) which doesn’t seem to be linked anywhere and there is the dashboard version which says up to date, when upgrade will allow updates.

Is the update page for out-of-band/interim updates; but updates more generally will flow via the version number and an update button will appear on the dashboard?


Upgrade link should always be visible (or as long as there are new commits)
(Dave McClure) #25

Good point.

Now that there are multiple branches you could track for deployment, it would probably be good to have the link to the upgrade page be always be visible, or be visible if there are any new commits.

That way, stable can get security patches without a version bump, and those tracking tests-passed or beta can get updates between versions (which is kinda the point of tracking those branches).


Upgrade link should always be visible (or as long as there are new commits)
(Jackson) #26

I’ve followed the steps in the original post but now when I try to visit /admin/upgrade/ I get an error:

The page you requested doesn’t exist or is private.

I’m logged in as an admin and can reach the other admin pages. I’m running from tests-passed if that matters.


(Chris Adams) #27

I found that my EC2 instance that I built is different, this may be the same for others so here is how I updated.

When I went to update from the previous version to this I had to skip moving anything from /var/docker to /var/discourse.

When I first installed, the /var/discourse directory was already created separate from /var/docker, I am not exactly sure why. I checked the app.yml file and there is only one instance that references /var/docker which is the the /shared directory.

So with that being said, I skipped changing any references in app.yml and I skipped mv /var/docker /var/discourse because it didn’t seem right to move things around if the locations were already set.

So I simply ran the following;

cd /var/discourse
./launcher stop app
apt-get update
apt-get dist-upgrade lxc-docker

Once that was done I ran the following (from within /var/discourse)

git pull
./launcher rebuild app

Newest version is up and running without a hitch. Hope this helps others if they run in to the same situation and possibly get confused.


(Jeff Atwood) #28

There was a bug we briefly introduced into the codebase (since patched) that was messing up routing. Looks like you got “lucky” and got that version. You’ll have to update manually from the command line, sorry!


#29

I get this message now when I ssh into the app. Just wondering if this was a symptom of moving the installation or if this is something more serious to be concerned about?

WARNING: No swap limit support
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is

(Jens Maier) #30

See this thread:

https://meta.discourse.org/t/operation-not-permitted-messages-when-updating-discourse/15079/26?u=elberet&source_topic_id=19328

#31

Thanks, running this solved it:

ssh-keygen -f "/root/.ssh/known_hosts" -R [0.0.0.0]:2222

(resure) #32

I upgraded to 1.0 without any problems, but yesterday, after system upgrade, my instance failed.

FAILED
--------------------
RuntimeError: socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1 failed with return #<Process::Status: pid 50 exit 1>
Location of failure: /pups/lib/pups/exec_command.rb:85:in `spawn'
exec failed with the params "socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1"
b37a989181b9ac5fc7b5e51aae475caf79338bc179166d6a1e88d9bd45556cc8
FAILED TO BOOTSTRAP

This was resolved by rebooting host OS, but I’m still not sure why it happened.
Oh wait, it wasn’t. Rebuild returns this:

Error response from daemon: Cannot destroy container 89dceb3d0cb0a369d28516ea7df308b05433b53695b28674165b206e2495db04: Driver devicemapper failed to remove root filesystem 89dceb3d0cb0a369d28516ea7df308b05433b53695b28674165b206e2495db04: Device is Busy
2014/08/31 10:44:38 Error: failed to remove one or more containers
Invalid cid file, deleting, please re-run

Update 2: I was able to successfully rebuild instance after 2-3 failed builds.


(Sam Saffron) #33

Device mapper has been flaky everywhere I have seen it, recommend aufs instead


(Dan Porter) #34

I’m still against dropping support for Docker v0.9.1 for a variety of reasons:

  • This is the version of Docker that Ubuntu 14.04 ships with. It is supported by the vendor (Just apt-get install docker.io and you’re done)
  • 0.9.1 still even today on latest Discourse release, has had no issues since I first deployed it for Discourse. Newer versions on the other hand, have had their fair share of bugs, regressions, and all sorts of behaviour changes.
  • Docker-hosting services (at least the two I have spoken to) are opting for a stable, vendor supported version of Docker (Ubuntu’s 0.9.1 release)
  • Docker is still to this day, in active development. There will be more changes in future, potentially even config changes that are not backwards compatible. It is not Discourse’s job to test Docker on users’ production forums. Don’t change it if it’s not broken.

I will continue to run Discourse on Docker v0.9.1, as I do not want to have to keep changing my environment every time a new version is out. I want to run an application, not spend time managing a system (which was the very goal Docker set out to do).


(Sebastien Rey) #35

I can’t use docker on my hosting (webfaction), and since last upgrade i had no problem.

I update my git repository to latest-release, now i have a problem with manual update :confused:

An error occurred while installing rbtrace (0.4.4), and Bundler cannot continue.
Make sure that `gem install rbtrace -v '0.4.4'` succeeds before bundling.

Here the error :

Fetching: rbtrace-0.4.4.gem (100%)
Building native extensions.  This could take a while...
ERROR:  Error installing rbtrace:
	ERROR: Failed to build gem native extension.

    /usr/local/bin/ruby2.0 extconf.rb
  -- tar zxvf msgpack-0.5.7.tar.gz
  -- ./configure --disable-dependency-tracking --disable-shared --with-pic --prefix=/home/reyman64/webapps/discourse/gems/gems/rbtrace-0.4.4/ext/dst/
  -- make install
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Provided configuration options:
	--with-opt-dir
	--without-opt-dir
	--with-opt-include
	--without-opt-include=${opt-dir}/include
	--with-opt-lib
	--without-opt-lib=${opt-dir}/lib/ruby20
	--with-make-prog
	--without-make-prog
	--srcdir=.
	--curdir
	--ruby=/usr/local/bin/ruby2.0
/usr/local/lib/ruby20/ruby/2.0.0/fileutils.rb:1551:in `stat': No such file or directory - /home/reyman64/webapps/discourse/gems/gems/rbtrace-0.4.4/ext/dst/ruby20/libmsgpackc.a (Errno::ENOENT)
	from /usr/local/lib/ruby20/ruby/2.0.0/fileutils.rb:1551:in `block in fu_each_src_dest'
	from /usr/local/lib/ruby20/ruby/2.0.0/fileutils.rb:1567:in `fu_each_src_dest0'
	from /usr/local/lib/ruby20/ruby/2.0.0/fileutils.rb:1549:in `fu_each_src_dest'
	from /usr/local/lib/ruby20/ruby/2.0.0/fileutils.rb:393:in `cp'
	from extconf.rb:54:in `<main>'

(Jeff Atwood) #36

Are you out of memory or disk space? What does free -m report?


(Sebastien Rey) #37
        total       used       free     shared    buffers     cached
  Mem:  32014      31779        234          0       1010      17603
-/+ buffers: 13165      18848
 Swap:  32767       3200      29567

Typical command to see webfaction process usage return only 247.207 MB used, i have 1 GB


(Jeff Atwood) #38

Regardless, we can’t support non-docker installs. Sorry.


(Jens Maier) #39

I’ve had that same problem a while ago. It’s a regression in rbtrace-0.4.4 that is triggered by certain distros and where Ruby is installed on the system.

Detailed description and temporary resolution for the problem can be found here:


(Sebastien Rey) #40

hu :confused:

I check and this is a problem which appear between a
git checkout v0.9.9.9 (update work) et
git checkout v1.0.0.0 (problem with rbtrace)

Edit : solved with help of @elberet and a little bundle install --local here :

Edit2 : Finally don’t work, don’t know why, i probably need to modify the Gemfile to force the usage on local builded gem, anybody say ?


(Jeff Atwood) #42

I really don’t think this is a good idea. I raised the concern over at the official Docker discourse: