[SAC] Server Planning

Committees SAC mailing list
1

To follow-up on Martin's questions I though it might be best to start a
new thread. The question was, what is going on which server?

Now that it looks like we've got the hardware part take care of the next
step will be to plan out the usage of the servers and the deployment
plan for them.

I'll toss out my rough idea of one way to implement but leave it
completely open for discussion (Probably start a wiki page) and suggest
that SAC members at the NY sprint in a couple of weeks spend some time
working out the details.

This is a summary of the Ideas sheet in that google doc.
NewServer1(Smaller discs, faster seek, faster write)
3-4 Virtual Machines
Trac/SVN, Websites(Drupal, Mediawiki, Joomla etc),MySQL

NewServer2(Bigger discs, slower seek, slower write)
3-4 Virtual Machines
Downloads, Local Backup, Mail/Lists, LDAP

Telescience
Download mirror, Offsite Backup, Lower load project websites, Buildbots

If anyone has a good suggestion for what to name a new wiki page, or
which existing page to put this on let me know and we can start
collecting alternatives there.

Thanks,
Alex

2

Alex Mandel wrote:

This is a summary of the Ideas sheet in that google doc.
NewServer1(Smaller discs, faster seek, faster write)
3-4 Virtual Machines
Trac/SVN, Websites(Drupal, Mediawiki, Joomla etc),MySQL

Alex,

I assume Trac/SVN would be one VM right? Were you suggesting there
would be a mysql VM and that Drual, Mediawiki and Joomla would
all go in one VM?

The Joomla would be for qgis, right? I think I'd prefer a
"qgis" VM that would have their joomla instance, and also any
other specialized services that project would like to establish.
We might use a similar technique for GRASS which has a few services
I think.

A per-project VM for projects that have more involved needs gives
them lots of control and autonomy. Essentially we host the VM and
what they do with it is pretty much up to them. Likewise we (SAC)
would not provide much in the way on "on VM" system administration.

I trust moving VMs from one of the servers to the other will be quite
easy, so I don't think we need to stress too much about what goes
where.

NewServer2(Bigger discs, slower seek, slower write)
3-4 Virtual Machines
Downloads, Local Backup, Mail/Lists, LDAP

Telescience
Download mirror, Offsite Backup, Lower load project websites, Buildbots

I am in no rush to move the download site, though we should use NewServer2
for mirroring the download server (a role now played by osgeo2).

I would also suggest the names "osl1" and "osl2" as our working names for
the new servers.

If anyone has a good suggestion for what to name a new wiki page, or
which existing page to put this on let me know and we can start
collecting alternatives there.

I would suggest a page linked off the SAC wiki named "OSL Transition Plan"
or something similar.

In terms of priority, I'd like to see Trac+SVN done with high priority.
I'd also like to migrate any of the services on the peer1 osgeo2 server
fairly soon so we can decommission that server. I'm sick of paying for it!
Mostly it provides: mediawiki and various backup-dump-zone services for osgeo1
and download.osgeo.org.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

3

On Mon, Feb 08, 2010 at 10:16:40AM -0500, Frank Warmerdam wrote:

I assume Trac/SVN would be one VM right? Were you suggesting there
would be a mysql VM and that Drual, Mediawiki and Joomla would
all go in one VM?

While you're at it, remember that I'm planning to migrate at least the
'regular' OSGeo Wiki over to a PostgreSQL database anyway. So please
don't count that one in for MySQL considerations.
Other Wikis are invited to join the same database instance :slight_smile:

Also note that, while the backend typically doesn't grow that large, an
OpenLDAP service under load is known for doing a _lot_ of small disk
I/O's and therefore might apply for the "small but fast" machine.

Cheerio,
  Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

4

I would also suggest the names "osl1" and "osl2" as our working names for
the new servers.

I would suggest a page linked off the SAC wiki named "OSL Transition Plan"
or something similar.

Good suggestions, just for those who maybe weren't with use back in
2006, this is our 2nd major infrastructure migration - so when
referencing the topic in the wiki it's helpful to note "2010" or OSL as
Frank noted.

5

Frank Warmerdam wrote:

Alex Mandel wrote:

This is a summary of the Ideas sheet in that google doc.
NewServer1(Smaller discs, faster seek, faster write)
3-4 Virtual Machines
Trac/SVN, Websites(Drupal, Mediawiki, Joomla etc),MySQL

Alex,

I assume Trac/SVN would be one VM right? Were you suggesting there
would be a mysql VM and that Drual, Mediawiki and Joomla would
all go in one VM?

The Joomla would be for qgis, right? I think I'd prefer a
"qgis" VM that would have their joomla instance, and also any
other specialized services that project would like to establish.
We might use a similar technique for GRASS which has a few services
I think.

A per-project VM for projects that have more involved needs gives
them lots of control and autonomy. Essentially we host the VM and
what they do with it is pretty much up to them. Likewise we (SAC)
would not provide much in the way on "on VM" system administration.

I trust moving VMs from one of the servers to the other will be quite
easy, so I don't think we need to stress too much about what goes
where.

NewServer2(Bigger discs, slower seek, slower write)
3-4 Virtual Machines
Downloads, Local Backup, Mail/Lists, LDAP

Telescience
Download mirror, Offsite Backup, Lower load project websites, Buildbots

I am in no rush to move the download site, though we should use NewServer2
for mirroring the download server (a role now played by osgeo2).

I would also suggest the names "osl1" and "osl2" as our working names for
the new servers.

If anyone has a good suggestion for what to name a new wiki page, or
which existing page to put this on let me know and we can start
collecting alternatives there.

I would suggest a page linked off the SAC wiki named "OSL Transition Plan"
or something similar.

In terms of priority, I'd like to see Trac+SVN done with high priority.
I'd also like to migrate any of the services on the peer1 osgeo2 server
fairly soon so we can decommission that server. I'm sick of paying for it!
Mostly it provides: mediawiki and various backup-dump-zone services for
osgeo1
and download.osgeo.org.

Best regards,

Great suggestions,

I think the VM story comes down to do we want a few or many. For project
autonomy many might be good but it might be resource inefficient with a
database running in each one.

Ad for the Download server, those of us on the LiveDemo project would
really appreciate being able to have files larger than 2 GB on the
server. Maybe that means shuffling things around so the blades OS can be
upgraded one at a time.

I'll get started on the new wiki page today.

Thanks,
Alex

6

Martin Spott wrote:

On Mon, Feb 08, 2010 at 10:16:40AM -0500, Frank Warmerdam wrote:

I assume Trac/SVN would be one VM right? Were you suggesting there
would be a mysql VM and that Drual, Mediawiki and Joomla would
all go in one VM?

While you're at it, remember that I'm planning to migrate at least the
'regular' OSGeo Wiki over to a PostgreSQL database anyway. So please
don't count that one in for MySQL considerations.
Other Wikis are invited to join the same database instance :slight_smile:

Also note that, while the backend typically doesn't grow that large, an
OpenLDAP service under load is known for doing a _lot_ of small disk
I/O's and therefore might apply for the "small but fast" machine.

Cheerio,
  Martin.

I was indeed suggesting a single VM dedicated to storing anything php
with apache and the db being it's own VM.

Maybe a dedicated Postgres VM would be in order then. I did notice that
Drupal's maintenance of postgres backend has been subpar compared to
MySQL so I doubt those should be moved but wiki instances sounds great.

To clear up confusion estimated disk space:
osl1 - 730 GB (Before formatting)
osl2 - 1.17 TB (Before formatting)
So only a difference of about 500 GB between machines, both will have
ample space.

Thanks,
Alex

7

Tyler Mitchell (OSGeo) wrote:

I would also suggest the names "osl1" and "osl2" as our working names for
the new servers.

I would suggest a page linked off the SAC wiki named "OSL Transition Plan"
or something similar.

Good suggestions, just for those who maybe weren't with use back in
2006, this is our 2nd major infrastructure migration - so when
referencing the topic in the wiki it's helpful to note "2010" or OSL as
Frank noted.

All,

A wiki page has been started to hash out all the ideas for deployment of
the new machines.
http://wiki.osgeo.org/wiki/Infrastructure_Transition_Plan_2010

Please go ahead and toss in your ideas. Ideally the discussion over
general approach and 1st level specifics should conclude shortly after
the New York sprint (Feb 20-23?) so that we'll have a firm plan by the
time the machines are available for configuration.

Of course if the general plan is done, they could work on the specifics
at the sprint.

Thanks,
Alex

8

Now that the servers are shipping, we can clearly focus on developing
our deployment plan.

To help here is a slew of answers from OSL to questions I had posted on
the wiki page:
http://wiki.osgeo.org/wiki/Infrastructure_Transition_Plan_2010

On Tue Feb 16 23:36:39 2010, tech@wildintellect.com wrote:

> Lance/OSL Team,
>
> The servers are on the way. See attached for details.
>
> The OSGeo team has decided on Debian Stable w/backports enabled, do
> you have any instructions, or references for how to create a kvm
> template image?

We'll have a base Debian Stable image setup for you already and then let
you configure it with the settings you need (with backports for
example).

> Any suggestion on 32 vs 64 bit, we're split on the issue right now?

I'm setting up all VMs with 64bit to keep things simple. I would
recommend doing 64bit if possible as it does give you some other
advantages down the road.

> As a side note, we are working on our deployment plan and have a wiki
> page. Most of it probably doesn't concern your team except for our
> discussion about the best way to do LDAP(will probably continue on our
> current machines until we solve it) and Backups.
> http://wiki.osgeo.org/wiki/Infrastructure_Transition_Plan_2010

Let me answer some of the questions at the bottom for you:

* Can ram be increased/decreased live?

No, not as far as I know.

* Can ram be increased/decreased via a web interface live or with power
  cycle?

Not web interface exists yet for what we'll be using but we plan on
having one eventually. A power cycle will be needed for a RAM change.
This could change down the road however depending on features that get
added.

* Is it easy to move VMs between the machines? Via web interface?

Yes with the cli, no web interface exists.

* Should the LDAP be hosted on one of the Host OS' for reliability?

Possibly, but I'm not sure where we can put that.

* Would LVM snapshot backups of virtual machines be a viable backup
  method?

Possibly, ganeti supports an export functionality which takes an LVM
snapshot, then runs dump on the filesystem. So you could use that while
its live in theory but I haven't tested that fully.

We generally just setup a normal backup process with our backend system.

* ext4 formatting

We could do that, but I haven't fully tested using ext4 with ganeti.
Ganeti doesn't really care what filesystem you use until you want to do
an import/export operation. The biggest issue is having support for ext4
in dump which I need to test. If you really need this we can do it but
I'd recommend ext3 for now.

* 32bit vs 64bit - in some cases smaller VMs with only 2 GB etc could
  perform better with 32 bit

See my statement above.

* default HD size? - remember to leave lots of room for /var, logs and
  database dumps even if there's not much in the VM

This depends on the use of the VM. Our "standard" is 10G per VM but this
is entirely up to you. We can also grow filesystems.

Another thing to note is that the partition layout for all of these VMs
need to be the same in order to allow for the export/import/install to
work properly. For now we're going with /boot, swap, / to keep things
simple.

What kind of an ETA do you have for getting this deployed? I'm pretty
swamped for the next month or so but I should be able to get this setup.
I'm also waiting for the GA relase of Ganeti 2.1 which should be fairly
soon.

Let me know if you have any more questions.

-- Lance Albertson Systems Administrator / Architect Open Source Lab

9

Alex Mandel wrote:

Now that the servers are shipping, we can clearly focus on developing
our deployment plan.

To help here is a slew of answers from OSL to questions I had posted on
the wiki page:
http://wiki.osgeo.org/wiki/Infrastructure_Transition_Plan_2010

Alex,

I have done some updates to this page, and I've sent out a query
to the GRASS and QGIS projects to see if they have need of project
VMs or not.

On this page in the priority list you have "DNS". Why was that?
Our DNS is all managed via pairnic, and I we don't run our own
dns servers at all.

I will note that snooping around on osgeo2 there seems to be lots
of stuff that isn't documented in:

   http://wiki.osgeo.org/wiki/SAC_Service_Status

Honestly, I'm a little peeved that people seem to set things up on
this server, and then never keep track of them. Will they be surprised
when they stop working? Looking around I see evidence of qgis.org,
moodle, ocs, wiktionary, fossgis wiki, community.osgeo.org,
planet.osgeo.org, but none of those were documented in the SAC list
of services hosted on the system. Perhaps several of those aren't
actually active, but it is hard for me to know, or find out who to
contact about it.

I certainly hope we can be more careful about keeping the
SAC_Service_Status page (really a catalog of SAC managed systems
and the services that are on them) up to date as we transition
services.

* Is it easy to move VMs between the machines? Via web interface?

Yes with the cli, no web interface exists.

There were quite a few questions about whether web interfaces exist
to manage the VMs. Frankly, I'm at least as comfortable doing this
sort of relatively rare thing by commandline mechanisms!

What kind of an ETA do you have for getting this deployed? I'm pretty
swamped for the next month or so but I should be able to get this setup.
I'm also waiting for the GA relase of Ganeti 2.1 which should be fairly
soon.

Ouch - this sounds like hurry up and wait.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

10

Hi Frank!

For qgis.org it's just been migrated to osgeo2 to take off some load of xblade14 ..
And it's "only" a joomla instance and a mediawiki instance ..
Never thought of entering into some SAC WIKI, but I will if it's necessary ..

I dont really think that we need our own VM for QGIS but I'm not a member of the qgis-steering committee
- so let's wait for an answer of them :wink:

hope that helps on the side of QGIS

regards
Werner

Am 17.02.2010 16:38, schrieb Frank Warmerdam:

Alex Mandel wrote:

Now that the servers are shipping, we can clearly focus on developing
our deployment plan.

To help here is a slew of answers from OSL to questions I had posted on
the wiki page:
http://wiki.osgeo.org/wiki/Infrastructure_Transition_Plan_2010

Alex,

I have done some updates to this page, and I've sent out a query
to the GRASS and QGIS projects to see if they have need of project
VMs or not.

On this page in the priority list you have "DNS". Why was that?
Our DNS is all managed via pairnic, and I we don't run our own
dns servers at all.

I will note that snooping around on osgeo2 there seems to be lots
of stuff that isn't documented in:

  http://wiki.osgeo.org/wiki/SAC_Service_Status

Honestly, I'm a little peeved that people seem to set things up on
this server, and then never keep track of them. Will they be surprised
when they stop working? Looking around I see evidence of qgis.org,
moodle, ocs, wiktionary, fossgis wiki, community.osgeo.org,
planet.osgeo.org, but none of those were documented in the SAC list
of services hosted on the system. Perhaps several of those aren't
actually active, but it is hard for me to know, or find out who to
contact about it.

I certainly hope we can be more careful about keeping the
SAC_Service_Status page (really a catalog of SAC managed systems
and the services that are on them) up to date as we transition
services.

* Is it easy to move VMs between the machines? Via web interface?

Yes with the cli, no web interface exists.

There were quite a few questions about whether web interfaces exist
to manage the VMs. Frankly, I'm at least as comfortable doing this
sort of relatively rare thing by commandline mechanisms!

What kind of an ETA do you have for getting this deployed? I'm pretty
swamped for the next month or so but I should be able to get this setup.
I'm also waiting for the GA relase of Ganeti 2.1 which should be fairly
soon.

Ouch - this sounds like hurry up and wait.

Best regards,

11

I will note that snooping around on osgeo2 there seems to be lots
of stuff that isn't documented in:

  http://wiki.osgeo.org/wiki/SAC_Service_Status

Looking around I see evidence of qgis.org,
moodle, ocs, wiktionary, fossgis wiki, community.osgeo.org,
planet.osgeo.org, but none of those were documented in the SAC list
of services hosted on the system. Perhaps several of those aren't
actually active, but it is hard for me to know, or find out who to
contact about it.

I think you'll find more info about a couple of these in trac, obviously
a bit confusing though. I'll update the status page for the ones I'm
aware of, but most were stood up as test/demos.

Just for background...

* Moodle: test instance
* OCS: test instance
* Wiktionary: http://trac.osgeo.org/osgeo/ticket/188
* FOSSGIS: http://trac.osgeo.org/osgeo/ticket/264
* Community.osgeo.* - .org are tests from me, but .net is live and
apparently undocumented, basically a mud puddle for me and CRM tools I
use privately as secretary. Will clarify these on the wiki for sure!

Thanks for pointing those out.

12

On Mon, Feb 8, 2010 at 20:41, Alex Mandel <tech_dev@wildintellect.com> wrote:

Maybe a dedicated Postgres VM would be in order then. I did notice that
Drupal's maintenance of postgres backend has been subpar compared to
MySQL so I doubt those should be moved but wiki instances sounds great.

Drupal + PostgreSQL is not a good idea if we want an easy to maintain
site. So I'd say that MySQL is a requirement.
Also for drupal it would be best if the DB is the same machine as the
webserver, since drupal is a HEAVY user of the DB. I don't know how
much a VM to VM communication compares to having DB and webserver on
the same... But as long as it is FAST all is good :stuck_out_tongue:

What OS will the webserver be running? Can it be Debian or
Debian-based? Please? :wink:

--Wolf

--
<8 )---- Wolf Bergenheim ----( 3>

13

On 02/18/2010 01:09 PM, Wolf Bergenheim wrote:

On Mon, Feb 8, 2010 at 20:41, Alex Mandel <tech_dev@wildintellect.com> wrote:

Maybe a dedicated Postgres VM would be in order then. I did notice that
Drupal's maintenance of postgres backend has been subpar compared to
MySQL so I doubt those should be moved but wiki instances sounds great.

Drupal + PostgreSQL is not a good idea if we want an easy to maintain
site. So I'd say that MySQL is a requirement.
Also for drupal it would be best if the DB is the same machine as the
webserver, since drupal is a HEAVY user of the DB. I don't know how
much a VM to VM communication compares to having DB and webserver on
the same... But as long as it is FAST all is good :stuck_out_tongue:

What OS will the webserver be running? Can it be Debian or
Debian-based? Please? :wink:

--Wolf

The OS is Debian Stable 64bit with backports enabled.
Drupal is listed with MySQL
Mediawiki which is a different VM is slated to migrate to Postgres
(Maintainers of wiki.osgeo.org were already planning this)

I'll try to clean up the wiki page to make that more clear since those
things have been determined mostly via IRC discussions.

Thanks for the interest,
Alex

14

On 02/17/2010 07:38 AM, Frank Warmerdam wrote:

Alex Mandel wrote:

Now that the servers are shipping, we can clearly focus on developing
our deployment plan.

To help here is a slew of answers from OSL to questions I had posted on
the wiki page:
http://wiki.osgeo.org/wiki/Infrastructure_Transition_Plan_2010

Alex,

I have done some updates to this page, and I've sent out a query
to the GRASS and QGIS projects to see if they have need of project
VMs or not.

On this page in the priority list you have "DNS". Why was that?
Our DNS is all managed via pairnic, and I we don't run our own
dns servers at all.

That's me not knowing how the DNS stuff is currently handled, thanks for
the info.

I will note that snooping around on osgeo2 there seems to be lots
of stuff that isn't documented in:

  http://wiki.osgeo.org/wiki/SAC_Service_Status

Honestly, I'm a little peeved that people seem to set things up on
this server, and then never keep track of them. Will they be surprised
when they stop working? Looking around I see evidence of qgis.org,
moodle, ocs, wiktionary, fossgis wiki, community.osgeo.org,
planet.osgeo.org, but none of those were documented in the SAC list
of services hosted on the system. Perhaps several of those aren't
actually active, but it is hard for me to know, or find out who to
contact about it.

Maybe we should have a sandbox VM that gets reincarnated (wiped of crud,
started from new) every once in a while for things like testing/piloting
new ideas. The nice part of experimental stuff is that we can turn those
VMs on and off whenever we feel like it - Though there needs to be a
good gatekeeper to prevent proliferation.

I certainly hope we can be more careful about keeping the
SAC_Service_Status page (really a catalog of SAC managed systems
and the services that are on them) up to date as we transition
services.

* Is it easy to move VMs between the machines? Via web interface?

Yes with the cli, no web interface exists.

There were quite a few questions about whether web interfaces exist
to manage the VMs. Frankly, I'm at least as comfortable doing this
sort of relatively rare thing by commandline mechanisms!

What kind of an ETA do you have for getting this deployed? I'm pretty
swamped for the next month or so but I should be able to get this setup.
I'm also waiting for the GA relase of Ganeti 2.1 which should be fairly
soon.

Ouch - this sounds like hurry up and wait.

I'm going to see if they can bring 1 server online sooner rather than
later so we can get started and they play shuffle if they need to update
some things.

Thanks,
Alex

15

On Wed, Feb 17, 2010 at 10:38:14AM -0500, Frank Warmerdam wrote:

I will note that snooping around on osgeo2 there seems to be lots
of stuff that isn't documented in:

  http://wiki.osgeo.org/wiki/SAC_Service_Status

Honestly, I'm a little peeved that people seem to set things up on
this server, and then never keep track of them.

I'm a bit uncertain if I'm the person being addressed here. If this is
supposed to be the case, then please talk plain language to me - I can
stand it.
Wrt. the QGIS setup, I know that they're running not just the Joomla
instance but also a Wiki. I have _not_ been the person who has made the
corresponding changes to the Apache setup, I was just helping with
getting the MySQL backend going.

Cheers,
  Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

16

On Wed, Feb 17, 2010 at 5:11 PM, Tyler Mitchell (OSGeo)
<tmitchell@osgeo.org> wrote:

I will note that snooping around on osgeo2 there seems to be lots
of stuff that isn't documented in:

http://wiki.osgeo.org/wiki/SAC_Service_Status

I have updated some links in the page.

Looking around I see evidence of qgis.org,
moodle, ocs, wiktionary, fossgis wiki, community.osgeo.org,
planet.osgeo.org, but none of those were documented in the SAC list
of services hosted on the system. Perhaps several of those aren't
actually active, but it is hard for me to know, or find out who to
contact about it.

I think you'll find more info about a couple of these in trac, obviously
a bit confusing though. I'll update the status page for the ones I'm
aware of, but most were stood up as test/demos.

Just for background...

* Moodle: test instance
* OCS: test instance
* Wiktionary: http://trac.osgeo.org/osgeo/ticket/188

  -> http://geodictionary.osgeo.org ("mine", let it die if you want)

* FOSSGIS: http://trac.osgeo.org/osgeo/ticket/264
* Community.osgeo.* - .org are tests from me, but .net is live and
apparently undocumented, basically a mud puddle for me and CRM tools I
use privately as secretary. Will clarify these on the wiki for sure!

http://planet.osgeo.org
-> administered by Mateusz, PLEASE KEEP IT! It is really important.

thanks,
Markus

17

Martin Spott wrote:

On Wed, Feb 17, 2010 at 10:38:14AM -0500, Frank Warmerdam wrote:

I will note that snooping around on osgeo2 there seems to be lots
of stuff that isn't documented in:

  http://wiki.osgeo.org/wiki/SAC_Service_Status

Honestly, I'm a little peeved that people seem to set things up on
this server, and then never keep track of them.

I'm a bit uncertain if I'm the person being addressed here. If this is
supposed to be the case, then please talk plain language to me - I can
stand it.
Wrt. the QGIS setup, I know that they're running not just the Joomla
instance but also a Wiki. I have _not_ been the person who has made the
corresponding changes to the Apache setup, I was just helping with
getting the MySQL backend going.

Martin,

The wiki.osgeo.org instance has been well documented - it is certainly
listed in the status document. I was more the moodles, ocs, planet, etc
that were not documented. In fact, I'm mostly responsible for not getting
the qgis migration documented and have rectified that to a modest extent.

If I had to wrap knuckles I think they would mostly be Tyler, Mateusz, and
myself.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

18

The wiki.osgeo.org instance has been well documented - it is certainly
listed in the status document. I was more the moodles, ocs, planet, etc
that were not documented. In fact, I'm mostly responsible for not getting
the qgis migration documented and have rectified that to a modest extent.

If I had to wrap knuckles I think they would mostly be Tyler, Mateusz, and
myself.

Is it agreed then, that we have a laid out process for how you'd like it
all documented, so that we all follow the same protocols? I think some
thought having a trac ticket open was enough, or even an email on the
SAC list or tagging a wiki page with the "infrastructure" category.
Your prodding has brought up the most excellent idea of having it all
hang off the server status page - works for me - then if it's not on
there in the future, then it can be assumed redundant.

I still like using trac as much as possible to see the progression of
things, but keeping a wiki page outlining things is valuable too. Too
many choices? Either way, let's link off the server status page.

The ocs and moodle stuff were tests not worthy of documenting, or osgeo2
was use as a dev environment before running live on osgeo1 - either way
I'll take responsibility for cleaning up those messes I made :slight_smile:

For the sheer volume of things we are running, having as few strays as
we have is quite an accomplishment!

Tyler

19

Tyler Mitchell (OSGeo) wrote:

Is it agreed then, that we have a laid out process for how you'd like it
all documented, so that we all follow the same protocols? I think some
thought having a trac ticket open was enough, or even an email on the
SAC list or tagging a wiki page with the "infrastructure" category.
Your prodding has brought up the most excellent idea of having it all
hang off the server status page - works for me - then if it's not on
there in the future, then it can be assumed redundant.

>

I still like using trac as much as possible to see the progression of
things, but keeping a wiki page outlining things is valuable too. Too
many choices? Either way, let's link off the server status page.

Tyler,

I am not against use of Trac tickets to document things, but I think it
is important that services on a system be linked from the SAC System
Service page so we can see who is running what, and how to get more info.

The ocs and moodle stuff were tests not worthy of documenting, or osgeo2
was use as a dev environment before running live on osgeo1 - either way
I'll take responsibility for cleaning up those messes I made :slight_smile:

Well, if we aren't carrying them over then there isn't anything to
clean up. But if you can confirm whether or not there is anything you
want to recover, that would be helpful.

For the sheer volume of things we are running, having as few strays as
we have is quite an accomplishment!

Agreed.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

20

Well, if we aren't carrying them over then there isn't anything to
clean up. But if you can confirm whether or not there is anything you
want to recover, that would be helpful.

Then we're done - I updated the server status page the other day for the
stuff I care about.