[Glass] Ubuntu 16.04 LTS

[Dale Henrichs via Glass]

On 1/14/17 6:16 AM, Sebastian Sastre via Glass wrote:
> Hi guys,
>
> Thanks for the details in your answer about DevKit Dale! I thought 
> that was for the development parts only, didn’t knew that devKit could 
> be used for installing the server too.
>
> The current target for an ubuntu install is 16.04 LTS 64bits
>
> I was taking a look at OS pre-requisites here
> https://github.com/sebastianconcept/gsDevKitHome/blob/master/docs/osPrereqs/osPrereqs.md#gsdevkit-operating-system-prerequisites
>
> and all aims to 32bits, I am missing something?
GsDevKit_home uses some code written in pharo for standard operations 
that I chose not to implement in bash:) Things like parsing .ston files 
and file manipulation creation algos... and of course pharo requires 32 
bit libraries.
>
> BTW I’ve saw also this doc on how to install gemstone in 64bits, 
> updated to Ubuntu 12.04 which isn’t supported anymore (or it ends its 
> LTS in a couple of months).
> https://downloads.gemtalksystems.com/docs/GemStone64/3.3.x/GS64-InstallGuide-Linux-3.3/GS64-InstallGuide-Linux-3.3.htm?https://downloads.gemtalksystems.com/docs/GemStone64/3.3.x/GS64-InstallGuide-Linux-3.3/1-Installation.htm
Yes, that is a bit misleading. 3.3.1 claims support for 12.04 and 14.04 
and I believe that GemStone3.x runs on 16.04 as well. Personally I've 
been doing development on 14.04 for quite a while. Typically the 
"supported" designation lags a bit behind, as it is representative of 
the operating systems that we run the full QA suite against and our 
development cycle is not necessarily in synch with Ubunutu's cycle.

Also our big commercial customers typically jump on the latest versions 
of the various operating systems so there is not the commercial demand 
for moving our QA environment to the latest operating system versions.

I have no reason to believe that there are issues with running on or 
doing development on 16.04, but for production purposes, it is best to 
follow our supported platform guidelines.
> One thing I’ve noticed is its size, it’s really long and feels like 
> many things can go wrong and lots of devops costs would sunk into that.
GsDevKit_home is aimed at an creating an initial install ... a number of 
the pieces that get built from scratch during the initial install can be 
reused for subsequent installations for sandboxes and production machines,
> Paul, is your ansible scripts solving that problem? I mean, the 
> ansible script you mention uses this as blueprints/plan on what to do? 
> If so, is there anything I can do to help you to get it out?
I think that for production, the standard GsDevKit_home directory 
structure is not quite adequate ... for best performance you will want 
to make sure that your tranlogs and extent directories on separate 
filesystems as well as make allowances for monitoring gem processes, 
restarting the stone on system startup, etc. and those types of 
customizations are best described by something like ansible ...

Dale