[OSGeo] #2306: Forum service - Discourse

[OSGeo]

#2306: Forum service - Discourse
-------------------------+--------------------
 Reporter:  jive         |       Owner:  sac@…
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:
Component:  SysAdmin     |  Resolution:
 Keywords:               |
-------------------------+--------------------
Comment (by robe):

 Replying to [comment:32 whynottrycalmer]:
 > Here https://meta.discourse.org/t/install-with-docker-compose/27386/7
 they seem to say that https://github.com/libresh/compose-discourse is the
 best Compose example. But it's not officially supported. What it does not
 provide is an easy way to perform version upgrades on things like
 Postgres.
 >

 Yah the fact it's 8years old, I'd rather go with the officially supported
 way.

 > Call is yours folks, but I doubt that using a non-supported method is
 wise, no matter if nowadays nobody stitches containers like it's 2015.
 'Supported' trumps 'standardized' for me by a large margin, mostly because
 going the non-supported route might actually break plugins on which this
 initiative crucially depends.
 >

 Agree

 > So how is this shaping up? At which stage in the process do you want
 outsiders to step in?
 It's looking okay it is working on zfs (thought that's not supported), had
 to run everything with the

 --skip-prereqs

 e.g.

 {{{
 ./launcher build --skip-prereqs
 }}}

 the smtp I finally got working, I guess I had run


 {{{
 ./launcher rebuild --skip-prereqs
 }}}


 To get it to take my app.yml changes. It's the rebuild I'm finding
 extremely painful.  The actual running seems to do fine.

 I'm going to attempt next to install all those plugins, ldap etc. and see
 if I run into any stumbling blocks.  I've just been writing my
 instructions locally cause I figure I'd have to tear the thing apart and
 start from scratch anyway and don't want to bother anyone with my
 ramblings. I know how strk hates journals.  strk I have one question for
 you.

 I haven't figured out what up, but sometimes using lists.osgeo.org port
 587 doesn't work and sometimes it does.
 I ended up having to use port 25  starttls for this.  I recall having
 similar issue with I think video.osgeo.org though weblate seemed to work
 fine with 587

 Replying to [comment:31 strk]:
 >  Aren't all LXD containers using ZFS as the underlying filesystem ?
 Also, why insisting in docker if performance is a problem ? Nested
 containers will surely not help ...

 Because generally the performance has been fine running with ZFS, though I
 have read this is bad and would be much faster if we put at
 /var/lib/docker in a non-ZFS partition.  weblate.osgeo.org for example
 seems to work just fine and seems good enough running in docker on ZFS.
 So does repo.osgeo.org.  So is talks.osgeo.org.  All those are containers
 running docker and seem performance wise fine to me. I think the
 performance hit is mostly pulling docker images and such.  So woodie
 whatever we might consider putting the /var/lib/docker partition in a btfs
 or whatever since we pull images all the time. Would probably fix the disk
 cleanup issues too.

 I had purposely only used like only half of disk space on osgeo8 and
 osgeo9 with the mindset that we'd probably have to run other kinds of file
 systems.  If I ever rebuild osgeo7 I'd probably do the same, but we had
 already made the mistake of allocating all osgeo7 to zfs (except for that
 small ssd drive). My thought was to

 a) put the whole container that is running docker in a non-zfs volume

 or

 b) only put the /var/lib/docker in a non-zfs volume


 The good thing with a is that well I think we don't need to do anything
 special with backup and restore

 Option b) I think we'd have two volumes being backed up and need to
 remember to pull those.  i haven't researched what's involved there.


 As far as discourse goes.  I think postgresql tends to run better on zfs.
 I'd also like to run postgresql not in docker for  discourse cause trying
 to upgrade a postgresql database running in docker pretty much requires a
 dump and restore, which could get really painful if they grows to a non-
 trivial size.
-- 
Ticket URL: <https://trac.osgeo.org/osgeo/ticket/2306#comment:33>
OSGeo <https://osgeo.org/>
OSGeo committee and general foundation issue tracker.