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

[Heiko Robert]

Hi Jeff, hi all,

thanks for pushing things forward.

Am 16.06.2016 um 18:07 schrieb Jeff Potts:
> *1. Honeycomb should be Alfresco Community Edition plus the best of what
> the community has to offer.*
> 
> What are we adding? Definitely AMPs we feel like should be included in
> every install, such as the JavaScript Console. Potentially also critical
> fixes that Alfresco hasn't put in Alfresco CE. The goal should be to be
> additive and to avoid a complete fork, if possible.

>From my perspective Honeycomb should be
* Alfresco Community Edition
* community patches
* list of optional maintained and tested modules (but not necessarily
part of the distro)

I don't like a all-in-one approach.
We should separate Alfresco installation from module deployments. Module
deployment may be automated but is hopefully not preintegrated in the war.

> *2. Honeycomb should be available to consume in at least as many flavors
> as Alfresco Community Edition is.*

Same here we should respect that there totally different use cases and
requirements for the Alfresco and OS install and we shouldn't mix them:
* development will love the container approach to save resources and to
make switches between different envionments as easy as possible.
Containers are much faster than booting a separate VM.
* in production containers are definitly not my choice. Alfresco is far
to hungry concerning resources and containers don't provide reliable
mechanisms to garantuee resources like provessional hypervisors like
VMWare ESX do. Additionally Containers don't have high availability
support like the hipervisors do.
* the mouse clicky guys require a msi installer to be run on their
windows system. Hopefully these systems will never go into production
but this target group wouldn't be able to maintain any linux based system

I only focus on the second to with the highest prio to the hipervisor /
VM version since this is the success or failure factor in real live, in
production. I'd like to hava _also_ containter configs but only during
development and testing.


> *3. Honeycomb should be as stable as Alfresco Community Edition, making
> it suitable for running in production for the same use cases and
> implementation patterns as Alfresco Community Edition.*

At least for our customers the requird stability is already reality. But
only because we maintain and support our bugfix and feature patch
modules. As a starting point we may put our two modules (bug patches,
feature patches) on github to work on. Like in a linux distro we than
need a process how changes find their way into a patch release. I see
here the most critical point for the OOTB distro. We will need well
tested and activly maintained patches for the community but patching can
only be done once on a resource to be patched.
This means only _one_ global patch project will work which needs
organisational efforts and QA.
Concerning implementation patterns I couln't see any difference between
community and enterprise. This comparison is only senseful for the sales
guys. Means: we shouldn't focus on CE or EE for use cases and
implementation patterns we need solution which work. Some of them may be
modules / solutions listed in the OOTB maintained module list.

> remove free VMWare based infrastructure and replace with OpenVZ.
we should distingues between the use cases described above (containers
vs. VMs).
I don't agree that one should _replace_ the other but one can _use_ the
other.
Means:
* we can run OpenVZ inside a VM giving physical resources we are willing
to spent for testing, development. Since the container approach is
running with the binaries of the host we will be limited to one
OS/distro which hosts the containers
* production envionments should run inside a independant VM. If
companies expect VMs for real live deployments we should be able to
install, run and test them.
* If we need other OSes like Windows or other Linux distros we can only
install them if we keep the hipervisor aproach.

> The reason is that the free VMWare version has limitations that are hard to deal with. For example, the free version can't talk from one interface to another.
We shouldn't mix up things. I think what Matin means is that if you ssh
directly into the hipervisor's kernel you can't directly access
resources inside the running VMs.
He is used to work this way from other environments (e.g. containers or
debian's vserver). This behavior is by design and expected. I would
always force this kind of design for envionments which are accessable
from the internet.
Someone may configure a hipervisor like VMWare ESXi to have a gateway
into the internal network but I only see reasons not to do that.
I belive there are better concepts for deployments than having direct
file or network access from an unsecure WAN interface and we should
discuss the use case first.
This scenario can be compared with a network behind a internet router
like your office or like your home network which uses NAT by default. If
your router exposes an API to the internet for administration hopefully
it does never allow direct access to the systems behind the routers just
to allow to push updates from a system in the internet.

Does this make sense?

Heiko