[SAC] OSGeo Ganeti Cluster

[Regina Obe]

Lance,

 

It seems no one has answered you so I'll offer my assessment of the situation to hopefully get the ball rolling.

 

 

​> That's OK with us, we can do whatever makes the most sense for you and your project.​ At the time, Ganeti was the best option, but now there are a > few other options available. We have been using OpenStack internally for several years and are almost ready to open up a larger cluster for FOSS 

> projects. It's a bit more complicated to maintain, but it offers a lot more flexibility in how you manage and access the VMs using a standard public API.

 

> What are your project's needs?

 

> -----------------------------------------------------------------------------------------------------------------------------

1)     Our current VMs are very old.  I think they are of Debian 6 vintage.  These should be resetup as Debian 9ish.

So we have issue of keeping these going while we move the services we still use on them off to new VM/hardware.

 

Our newest is OSGeo6 which is Debian8, fine but a bear-metal everything as I recall so I fear when comes time will be hard to upgrade.  As I recall I think we had plans of setting up a Docker Server on this.  Not sure if it was done.

 

2)     We have our FOSS4G initiatives and many other initiatives going on around the year, and these often need a server of some sort or at least a website, and for said such folks to be able to manage their own space as they need.  Right now I don't feel confident offering this on our existing systems, because they are either 

a)     OS too old  b) taxed

As has been done we basically tell the new FOSS4G group hey you are on your own for everything.  I feel really bad about that.

 

3)     We've got our OSGeo Live group – one of our initiatives, that produces ready to use software disk for conferences workshops etc.  It would be nice if they had their own VM they can configure as they want to do things like publish their workshop material real-time.  They also have special needs like high-bandwith for holding images – which as I recall they rely on sourceforge.net for – which of course has been on a spiral decline lately.

 

4)     Of particular urgency is our new website which has been delayed on release for 6 months.   For our immediate need, Alex will follow up on you for this to see if we can use OSUOSL for cloud hosting for this for the time being, as we seem to have trouble making up our mind.

5)     We've got our Gitlab test initiative which is going no where because no hardware to put it that we don't fear is too old or too taxed.

 

 

People have bandied the idea of using Docker.  Docker is fine for somethings, maybe it's my lack of experience with it, but seems like it's suitable for things that don't change, but not something I would feel comfortable handing to a project and say – configure it as you like,  we'll manage the updates if you need us to.

 

Also given that it relies a lot on the underlying OS, seems you are stuck with OS.  So if a project comes to us and says, our stuff works best on CentOS or FreeBSD or whatever, we are stuck.

 

 

So I really really want a VM solution of some sort like Ganeti, OpenStack, Libvrt.  If they all underneath rely on the same  KVM/LVM structure, I don't see why it much matters which one we go with aside from manageability and as long as we can move images to another box while we are reconfiguring things.  And If we are having these many arguments about it, I would much prefer a solution that OSUOSL has experience supporting or wants to support.

 

For picking a VM, things we are concerned about

 

1)     How easy would it be for us to manage and provision a new one on our own so we are not too dependent on OSUOSL for everything.

2)     Ease of upgrade

3)     Can we have basically console as if "we were right there standing in front of it"  if we screw up 

4)     Ability to backup the image as needed when we fuss with it and need to do something like upgrade the OS.

5)     I would really love having some redundancy.  This redundancy can be manual if it eases manageability. Like if we need to upgrade a cluster, be able to move VMs to another.

 

 

Thanks,

Regina

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/sac/attachments/20180106/07c20257/attachment-0001.html>