[OOTB-hive] Thoughts on Honeycomb that need your input

[Heiko Robert]

I see the Alfresco install independant from the OOTB modules and don't
like to choose only one valid deployment type because there are good
reasons to chose a container or a VM dependant on the use case.
In development and testing I'd love to have containers but for today not
in production for scalable, secure systems.

I personally don't follow the puppet aproach and keep the VM distro for
us because it is much, much more work to implement and maintain all the
changes we do in the VM inside a puppet script. Additionally our VM
customisations are very often OS distro specific. None of our customers
have realy experience in puppet environments and before going this route
I'd prefer to provide OS specific (e.g. ubuntu) packages. But this is
just my favor and shouldn't stop Martin and Daren go their way.

My vote for
* do we need a windows installer: no - this is not relevant for
production and ootb modules should be installable also on an alfresco
from the Alfresco installer
* do we need a generic linux installation process: yes. But we should
balance between efforts and result. I prefer easy and pragmatic and
therefore deployments like loftux installer or VMs. If something goes
wrong most people would be able to help theirself because nothing magic
happens.
* do we need VMs and containers: I'd love to but we need to prioritize
to be able to deliver and we may combine the aproaches: using installer
like the puppet one or the loftux script to do the base install inside
VMs and containers and then make all the required customisations inside
the specific deployment by hand or separate scripts before packaging VMs
and containers ready to use. On the other hand I don't like local
installs not maintained by the OSs package manager not being able to do
any updates (java, tomcat, libreoffice, ...) which brings me back to the
beginning: Install and configure directly inside a master VM or build OS
specific packages.

In the first step we should provide Tutorials, Howtos to collect the
requied knowledge and experience before we talk about automation and
additional collect best of artefacts like tomcat, nginx, apache configs
in a common repo.

Heiko

Am 23.06.2016 um 08:50 schrieb Andreas Steffan:
> On 06/22/2016 11:55 PM, Nick Burch wrote:
>> I'm not sure about that. I'd lean more towards "should be easy to
>> consume" and "should target those interested in using an open-source
>> ECM, and those interested in helping expand it".
>>
>>> Regarding the second point, there has been a lot of hard work done to
>>> Puppet-ize the Honeycomb installation. That is great, we don't want
>>> to stop doing that. For people who have Puppet in their environments
>>> or are willing to introduce it, using Puppet to automate the install
>>> has a lot of value.
>>
>> 2 years ago, lots of people I spoke to were using puppet for
>> everything. Today, the "buzz" seems to be around containers,
>> especially for trying things out. I've come across quite a few people
>> who try and develop with containers, then use the likes of puppet to
>> manage production roll-out. It's been a while since I met anyone who
>> said "when I want to try something new, I go looking for
>> puppet/chef/ansible rules to deploy my trial instance"
>>
>> Back when Alfresco was just getting started, one-click installers were
>> the big thing for letting people easily try it out. I doubt many
>> production installs were done with the installer, but a large number
>> of people trying it for the first time found it convenient and
>> most-easy to get started. (The people in engineering maintaining it
>> much less so...). These days, it seems that "spin up a container" or
>> "spin something up in the cloud" seem to be the more popular "I wonder
>> what that's like, can I quickly try it" route.
>>
>> When it comes to containers, Docker seems to have the big edge right
>> now, though that may change with time. Orchestration frameworks (for
>> deploying multiple inter-linked containers) there still seems to be a
>> big fight/debate going on, so a single container with everything in
>> might be safest even if it offends the microserves crowd!
>>
>> So, my suggestion would be:
>>  * General instructions on building a container image
>>  * Docker image (frequently refreshed due to various issues with how
>>    containers work and age...)
>>  * Links to tutorials on how to spin up the docker image locally and on
>>    Amazon (free instances available to all) and on Azure (free instances
>>    given away to most Microsoft customers one way or another)
>>  * War files for more advanced users
>>  * Deployment scripts (eg puppet) for advanced users
>>  * Build steps + scripts + instructions for converting users to
>>    contributors
> 
> I originally volunteered to work the distro.
> 
> With all respect to Martins efforts, it was Puppet which made me step
> back. For the simple reasons that I knew almost nothing about it and
> that I felt it will never be very helpful for me. I was (and still am)
> betting on Docker. Seems I am not the only one in Alfresco Land these days.
> 
> However, seems everybody is brewing his/her own Alfresco Docker food and
> is preferring to move fast instead of far. Recently, I have been looking
> at other peoples efforts again to check whether I see hope to join
> forces. Didn't find it and decided to move on by myself for the
> following reasons:
> 
> I  want as little effort as possible, and I don't want to go a route
> duplicating efforts. I don't want to maintain a ton of scripts and
> whatnot which break every now and then. Ideally, I would like to build
> on top of sustainable efforts driven by Alfresco Inc.
> 
> Looked closely at Alfresco SPK, but abandoned it due to all the
> complexity (Vagrant, Packer, Virtualbox, Chef) it introduces while
> offering  no benefit (for our use cases).
> 
> Ironically, my docker Alfresco images leverage the old school installer
> - Because of simplicity and stability.
> 
> regards
> Andreas
>