See also https://docs.google.com/document/d/15QSbahJKfq616JM0IrC6Xb7ywMJmlPggNk5iAP15ltY/edit#heading=h.utsrnzvuqwsv (SUIT Release Procedure Tailoring).

Firefly core

The Firefly package comprises both a library of visualization components (for images, tables, and table-based scientific plots) and a set of basic Web applications built on those components.  The system combines a Java-based server side and a JavaScript-based client side.  Firefly is designed to be deployed on a Tomcat server.  In practice most deployments include multiple servers with a load-balancing front end (typically based on NGINX or Apache HTTP Server).  Firefly is open-source and maintained on Github at Caltech-IPAC/firefly. 

Firefly was developed originally to support the astronomical archives at IRSA, was substantially revised and extended to meet the needs of the LSST project, and benefits from contributions from other IPAC projects.

Currently "vanilla Firefly" deployments are used on the lsst-demo visualization server, as well as to serve /firefly  endpoints in the LSP Kubernetes configurations at NCSA and in the cloud.  It is expected that in the operations era these applications will be phased out in favor of endpoints in the LSST-specific Portal deployment, but for the time we would like to preserve the capability to deploy "vanilla Firefly".

Firefly core release process

The IPAC build processes for Firefly typically produce both a .war file archive (which includes the Firefly server Java code and the JavaScript code to be served at run time) and a Docker-format container image containing a Java runtime, Tomcat server, and the Firefly client and server code.  LSST deployments and IPAC-internal development and test deployments are all based on the container images.  (A previous "standalone deployment" build option was to produce a .war file archive that also contained a version of Tomcat, in order to allow Firefly to be started with only a JRE pre-installed, but as of mid-2019 this option is no longer being used and the equivalent functionality is offered by providing the Docker image.)

...

The IPAC release process for Firefly is being revised to better support the increasing number of projects outside IRSA that deploy Firefly-based applications. 

IPAC controls this the development and release process through a Change Control Board on which LSST is represented.  IPAC performs the builds (using a highly automated in-house Jenkins configuration) and will periodically make releases of Firefly and generates Docker images, which are deployed on an in-house Kubernetes cluster for feature-branch and release-candidate tests.  Releases are made periodically, under CCB control, following in-house testing.  They will be made available via Github, based on tags of the form release-2019.2.0, as well as by releasing Docker-format container images corresponding to these releases, on Dockerhub, with Dockerhub tags matching the release name string.  Vanilla Firefly build  These "vanilla" Firefly release images are available at ipac/firefly on Dockerhub.

LSST deployment configuration for "vanilla" Firefly core releases

As noted above, currently Currently "vanilla Firefly" container builds such as this are used on the lsst-demo visualization server (as a bare Docker container), as well as to serve /firefly  endpoints in the LSP Kubernetes configurations at NCSA and in the cloud. (These usages are expected to be phased out by the operations era.) 

Until now, the policy has been that IPAC periodically updates the Dockerhub tag ipac/firefly:lsst-dev to indicate which build has been "blessed" for deployment on LSST services.  We will continue to do this until a new policy is agreed with LSST.

What is required is a mechanism for determining, from the available set of release-yyyy.m.n  release images, which will be used at any given time in the various LSST deployments.

It is proposed that, for now, we from time to time update tags It is proposed that we move to creating both release-specific tags, e.g., ipac/firefly:release-2019.2.1  (whose meaning never changes) and updatable tags lsst-lsp-int and lsst-lsp-stable  to signal which builds are "blessed" recommended for LSST deployment, with the former controlling which image is used on the lsst-lsp-int  cluster, and the latter which image is used in all production and otherwise widely-used contexts, including the bare-Docker lsst-demo  deployment and the production-like LSP instances on lsst-lsp-stable  and the future Commissioning Cluster.

...

Currently the Portal Aspect applications are run in LSP instances by deploying containers in Kubernetes based on the resulting container images.

SUIT release process (proposed)

Until now, IPAC has also performed these the builds of the suit container images, in Jenkins, and has released the containers at ipac/suit on Dockerhub, again periodically updating the lsst-dev Dockerhub tag to indicate which version is "blessed" for deployment.

...

As a bridge to this mechanism, IPAC will continue for a transition period to perform builds of the suit package, using the new build script, and release the resulting images at ipac/suit on Dockerhub.  Again 

Again, for now, we will continue to use a revisable lsst-dev  Dockerhub tag to indicate the "blessed" versions, until a new policy has been agreed with LSST.

...