[SAC] QGIS documentation for 2.2 and QGIS VM update

Hi SAC,

As off today we branched a new 2.2 branch of the QGIS Documentation.
(currently some languages building as test, see: http://docs.qgis.org/2.2)

The idea is/was we build on the qgis2 (=hetzner) and rsync output to
qgis (qgis.osgeo.osuosl.org), which is working now.

because we build for roughly 15-20 languages (both html and pdf's) this
counts for at least 15x350Mb=6Gb per branch).
Currently we are serving (or at least want to serv) 3 full branches:
1.8, 2.0 and starting now with 2.2.
Website is currently about 5Gb (including git checkouts)

But we are running out of diskspace on the QGIS VM.

One quick solution is to (temporarily) move the hosting for
QGIS-Documentation sites (docs.qgis.org) to the hetzner, untill the
diskspace problem is solved.

But a better solution would be to split off the QGIS docs/website in a
'static content serving VM', serving website and docs (and nightlies?).
Then current VM could keep serving hub.qgis.org (redmine wiki and issues).

Any ideas about this?
Would this be possible?

Regards,

Richard Duivenvoorde

On 05/20/2014 02:34 PM, Richard Duivenvoorde wrote:

Hi SAC,

As off today we branched a new 2.2 branch of the QGIS Documentation.
(currently some languages building as test, see: http://docs.qgis.org/2.2)

The idea is/was we build on the qgis2 (=hetzner) and rsync output to
qgis (qgis.osgeo.osuosl.org), which is working now.

because we build for roughly 15-20 languages (both html and pdf's) this
counts for at least 15x350Mb=6Gb per branch).
Currently we are serving (or at least want to serv) 3 full branches:
1.8, 2.0 and starting now with 2.2.
Website is currently about 5Gb (including git checkouts)

But we are running out of diskspace on the QGIS VM.

One quick solution is to (temporarily) move the hosting for
QGIS-Documentation sites (docs.qgis.org) to the hetzner, untill the
diskspace problem is solved.

But a better solution would be to split off the QGIS docs/website in a
'static content serving VM', serving website and docs (and nightlies?).
Then current VM could keep serving hub.qgis.org (redmine wiki and issues).

Any ideas about this?
Would this be possible?

Regards,

Richard Duivenvoorde

I think I asked this before, how big would a new qgis3 vm need to be? My
read of the above is your want at least 18 GB and would probably need
closer to 40-50GB just for the future growth of the docs?

I see no reason we can't make a new vm to serve the content but someone
needs to specify the specs required. If it needs to be fast I can
actually have OSUOSL attach more disk space to the current QGIS VM and
we could then just remount it to the qgis3 vm when it's ready.

Also has QGIS considered readthedocs.org for hosting the docs? It's
something I put on the idea list, we could also in house use a similar
system to theirs I think,

Thanks,
Alex

On 21-05-14 01:35, Alex Mandel wrote:

I think I asked this before, how big would a new qgis3 vm need to be? My
read of the above is your want at least 18 GB and would probably need
closer to 40-50GB just for the future growth of the docs?

I see no reason we can't make a new vm to serve the content but someone
needs to specify the specs required. If it needs to be fast I can
actually have OSUOSL attach more disk space to the current QGIS VM and
we could then just remount it to the qgis3 vm when it's ready.

Also has QGIS considered readthedocs.org for hosting the docs? It's
something I put on the idea list, we could also in house use a similar
system to theirs I think,

As number of translations are growing, as is documentation, I would
prefer a bigger disk.
Then we can put all debian, redhat, data stuff also there.

Plan then is to put all static content on it, do cron builds on other
machines, and have this one VM for serving it out (with or without
cloudflare-like backing ups).

So the disk can be whatever vanilla debian with fast internet connection.

So 100Gb? Is that ok?

Any idea about a timeline? Not sure if I can help with this myself, let
me know. Probably I need to create an issue for this?

Regards,

Richard Duivenvoorde

On 05/20/2014 11:58 PM, Richard Duivenvoorde wrote:

On 21-05-14 01:35, Alex Mandel wrote:

I think I asked this before, how big would a new qgis3 vm need to be? My
read of the above is your want at least 18 GB and would probably need
closer to 40-50GB just for the future growth of the docs?

I see no reason we can't make a new vm to serve the content but someone
needs to specify the specs required. If it needs to be fast I can
actually have OSUOSL attach more disk space to the current QGIS VM and
we could then just remount it to the qgis3 vm when it's ready.

Also has QGIS considered readthedocs.org for hosting the docs? It's
something I put on the idea list, we could also in house use a similar
system to theirs I think,

As number of translations are growing, as is documentation, I would
prefer a bigger disk.
Then we can put all debian, redhat, data stuff also there.

Plan then is to put all static content on it, do cron builds on other
machines, and have this one VM for serving it out (with or without
cloudflare-like backing ups).

So the disk can be whatever vanilla debian with fast internet connection.

So 100Gb? Is that ok?

Any idea about a timeline? Not sure if I can help with this myself, let
me know. Probably I need to create an issue for this?

Regards,

Richard Duivenvoorde

Anyone else have an opinion on this?

It should be quick and easy to request a new lvm volume be added as a
2nd disk on QGIS by OSUOSL. Then we can format it XFS or something other
than ext3 and migrate all the static content on to it. Best case it
might improve our overall i/o.

FYI, we should have at least 500 GB of currently unallocated space and
as an lvm volume it can actually be grown relatively easily, possibly
even without taking it offline since it won't be the primary disk of the vm.

I'd like to go forward with the request at the end of this week unless I
hear objections.

Thanks,
Alex

Richard,

New disk is added on QGIS
/var/www/qgisdata
100GB XFS volume

Side note about osgeo4, after deleting Backup VM:
586G now free

Go ahead and start trying to move over the static content to the new
disk. Let me know if you need any help, reconfiguring apache should be
straight forward. Next step, we can start thinking about re-doing a
clean VM.

Thanks,
Alex

On 05/21/2014 11:01 PM, Alex Mandel wrote:

On 05/20/2014 11:58 PM, Richard Duivenvoorde wrote:

On 21-05-14 01:35, Alex Mandel wrote:

I think I asked this before, how big would a new qgis3 vm need to be? My
read of the above is your want at least 18 GB and would probably need
closer to 40-50GB just for the future growth of the docs?

I see no reason we can't make a new vm to serve the content but someone
needs to specify the specs required. If it needs to be fast I can
actually have OSUOSL attach more disk space to the current QGIS VM and
we could then just remount it to the qgis3 vm when it's ready.

Also has QGIS considered readthedocs.org for hosting the docs? It's
something I put on the idea list, we could also in house use a similar
system to theirs I think,

As number of translations are growing, as is documentation, I would
prefer a bigger disk.
Then we can put all debian, redhat, data stuff also there.

Plan then is to put all static content on it, do cron builds on other
machines, and have this one VM for serving it out (with or without
cloudflare-like backing ups).

So the disk can be whatever vanilla debian with fast internet connection.

So 100Gb? Is that ok?

Any idea about a timeline? Not sure if I can help with this myself, let
me know. Probably I need to create an issue for this?

Regards,

Richard Duivenvoorde

Anyone else have an opinion on this?

It should be quick and easy to request a new lvm volume be added as a
2nd disk on QGIS by OSUOSL. Then we can format it XFS or something other
than ext3 and migrate all the static content on to it. Best case it
might improve our overall i/o.

FYI, we should have at least 500 GB of currently unallocated space and
as an lvm volume it can actually be grown relatively easily, possibly
even without taking it offline since it won't be the primary disk of the vm.

I'd like to go forward with the request at the end of this week unless I
hear objections.

Thanks,
Alex