[Qgis-psc] Fwd: Response to PSC 9 May 2014

[Richard Duivenvoorde]

Forwarding a message here from Alex Mandel/wildintellect.
@alex: if I'm right, you can just sent email to
qgis-psc at lists.osgeo.org. Can you please try?


Email from Alex:


Hardware:
OSGeo is looking at buying new hardware, we want to alleviate Tim's
issue of not enough space. Short history is we bought small 15K rpm
drives, and the backup used to be on the same hardware. We now actually
have 500GB+ free space (dedicated backup machine below).

Does QGIS want to use this hardware, have a say in this hardware or even
buy some of the hardware (dedicated for QGIS use)? We do not pay for
hosting at OSUOSL and have essentially unlimited bandwidth on a
university connection.
I'm willing to talk SSDs, GeoCDN (this is what OSM uses and can be used
for more than static data), mirroring, etc... But it's all more
effective if it's pooled with other projects.

Advantage to OSUOSL service is OSGeo bought a dedicated backup server
last year. 9TB+, current QGIS machine is being backed up (according to
MartinSpott). It also means more people in more timezones available to
un-stick issues - e.g. I'm on the US West coast, often awake when the
rest of QGIS admins are sleeping.

Also we are considering adding dedicated build servers, separate
physical machines from web services. I think not having builds on the
same hardware as heavy usage websites is important for disk i/o.
Current I/O issues on QGIS were at first hardware related and now seem
to be a RAID 6 vs. Backup bottleneck. We don't plan to keep it that way.
We actually plan to convert to RAID 5.

In short, having QGIS share some hardware is supposed to allow us to
share admins a little bit. ie. Jurgen helps out on machines besides
QGIS, and other admins like MarkusN, MartinSpott, HamishB help out on
QGIS stuff - mostly just keeping an eye on things.


Hub:
I personally run Chiliproject(A fork of Redmine)+Postgres+Gitolite on a
VM. The VM part is not the bottleneck. The current hub is now behaving
fine, no more memory leaks thanks to a Phusion upgrade and switch to
Apache_Worker - FYI if no php is going on QGIS you should be running
Worker or Event, unless it's all NGINX + WSGI service

Yes, I don't think GH Issues is sophisticated enough for QGIS' needs.
Though at least this exists
http://codetheory.in/export-your-issues-and-wikis-from-github-repo-and-import-to-bitbucket-migration/

Keep in mind that uploading plugins+filing tickets is currently single
sign on. We could attempt to use OAuth for plugins and use github accounts.

There are lots of alternatives to consider:
https://www.gitlab.com/gitlab-ce/
https://www.gitlab.com/gitlab-ci/
Trac - especially if we no longer host git repos (that was why we choose
redmine before)
Bloodhound - Apache's fork of trac
Django Issues - or some other django app
I'm sure there are others...


Cloudflare:
The reason I suggested an OSGeo account, I think at some point we might
want to use the SSL features. It includes the certs so that cost would
no longer be separate(~$270/yr), and it's $20/month for the first site
and $5 for each additional site. So you can see if any other OSGeo sites
want to use it the cost per site would go down.

I'd like to start encouraging osgeo4w, plugins.qgis and other download
sites to start using SSL to better protect end-users. +1 for
plugins.qgis xml being on a CDN of some sort.


Short term: Yes we can make a fresh VM with Debian 7 and QGIS stuff can
be migrated over. However we shouldn't waste time moving Redmine if it's
just going to be abandoned. Please let me know how much disk space you
think you need in the near future for such a VM (actually one option now
is I could mount a new disk, probably XFS and the website could be moved
into that).


I'd also like to remind everyone, I joined SAC originally as my way of
contributing back to QGIS since I don't code in C++. So I'm very
interested in making this all work as best as possible. Also SAC
specifically because it was easy to apply the shared knowledge and
resources to help all the projects.

Thanks,
Alex