Lazy consensus: Using docker builds for demo-trunk site

[Daniel Watford <da...@foomoo.co.uk>]

Hello,

Following on from recent trunk changes to build and publish OFBiz as a
container image (https://issues.apache.org/jira/browse/OFBIZ-12781), this
email is to establish if we have a lazy consensus to use the built
container images to serve the https://demo-trunk.ofbiz.apache.org/partymgr
demo site.

Using a container to serve the trunk demo site was originally listed as one
of the 'proposed next steps' in my email updating the community on the
experimental docker work (
https://lists.apache.org/thread/njg7fgwxjxt1vsfs6df8rrwvyp5pwv9p)(https://issues.apache.org/jira/browse/OFBIZ-12757
)

If consensus is established, then changes shall be initially made in a way
allowing them to be quickly reversed if needed. Once the demo-trunk site is
observed as running correctly, and with refreshes applied daily, then more
permanent changes can be applied to the demo VM and changes committed to
https://github.com/apache/ofbiz-tools/tree/master/demo-backup accordingly.

Overview of changes:
- Manually stop the trunk instance of OFBiz on the demo VM (
ofbiz-vm1.apache.org)
- Modify script
https://github.com/apache/ofbiz-tools/blob/master/demo-backup/all-manual.sh
to prevent the instance being started again during the 03:00 refresh.
- Create a docker compose application, similar to those under
https://github.com/apache/ofbiz-tools/tree/docker-experimental/demo-backup/ofbizdocker/home/ofbizdocker,
which uses the trunk-plugins-snapshot container image and loads demo data.
This container shall be configured to listen on the same AJP port as the
original demo-trunk OFBiz instance.


Some items to check:

Currently, various patches are applied to the trunk sources prior to
rebuild at 03:00 daily. We need to check the intention behind those changes
and, if needed, ensure they can be applied to a container instance of
OFBiz. This may require changes to the docker entrypoint script.


Why do this?

There are numerous reasons to explore container usage, but this effort
began in response to some difficulties in upgrading the JDK version
installed on the demo VM while running different OFBiz versions
concurrently. That particular issue has been resolved by use of sdkman, but
it will still require someone to alter deployment scripts on the VM when we
change JDK version in future.

Running OFBiz in a container means the JDK, along with all other
dependencies, is packaged in the container. There is no dependency on the
JDK installed globally on the host.

Thanks,

Dan.

-- 
Daniel Watford

Re: Lazy consensus: Using docker builds for demo-trunk site

[Jacques Le Roux <ja...@les7arts.com>]

Hi Daniel,

Those patches have all a reason to be there.

url.properties.patch: is explained there: https://markmail.org/message/mwvoh2gcjcoyg3ro
solr.config.patch:  overrides default values in solrconfig.properties (ie localhost)
fop.xconf.patch:  to allow FOP to  work correctly
birt.patch: for security reason, by default solr is enabled but disabled when released. Same disabling when used in demo.

HTH

Jacques

Le 22/03/2023 à 17:49, Daniel Watford a écrit :
> Some items to check:
>
> Currently, various patches are applied to the trunk sources prior to
> rebuild at 03:00 daily. We need to check the intention behind those changes
> and, if needed, ensure they can be applied to a container instance of
> OFBiz. This may require changes to the docker entrypoint script.
>