[wildfly-dev] Managed exploded deployments

[Brian Stansberry]

On 6/10/16 4:27 PM, James Perkins wrote:
>
>
> On Fri, Jun 10, 2016 at 8:18 AM, Emmanuel Hugonnet <ehugonne at redhat.com
> <mailto:ehugonne at redhat.com>> wrote:
>
>
>
>     On 10/06/2016 17:06, Brian Stansberry wrote:
>     > On 6/10/16 9:39 AM, Emmanuel Hugonnet wrote:
>     >>
>     >>
>     >> On 10/06/2016 16:22, David M. Lloyd wrote:
>     >>> On 06/10/2016 08:38 AM, Brian Stansberry wrote:
>     >>>> Emmanuel Hugonnet has been working on a long requested feature
>     to have
>     >>>> WildFly support "managed exploded deployments." We have a
>     requirements
>     >>>> analysis doc for this at
>     https://developer.jboss.org/docs/DOC-55497 and
>     >>>> I just wanted to point that out to the list so anyone
>     interested can
>     >>>> have a look, and comment on this thread or on the document.
>     >>>>
>     >>>> A managed deployment is one where the user provided content is
>     copied by
>     >>>> the server/host controller into its internal content repo and then
>     >>>> thereafter that copy is what is used. I estimate that 99%+ of
>     all zipped
>     >>>> deployments in WildFly are managed. With an unmanaged
>     deployment the
>     >>>> user provides the server with the local FS path to the content
>     and then
>     >>>> the server directly uses that content. All exploded deployments are
>     >>>> unmanaged, as we don't support managed yet.
>     >>>>
>     >>>> We propose to add 5 new operations to the deployment resource:
>     >>>>
>     >>>> explode (to convert and archive deployment to exploded)
>     >>>
>     >>> Hmmm.
>     >>>
>     >>> Is deployment explosion really an deployer concern, or is it a
>     >>> deployment provider concern?  Consider:
>     >>>
>     >>> * The deployment provider is the one who will know whether or not
>     >>> his/her deployment will function correctly with or without
>     exploding.
>     >>> * The deployment will have been tested in the desired configuration
>     >>> (exploded or unexploded).
>     >>> * Making this a deployer/administrator concern means that he/she
>     must
>     >>> ensure that the extra step(s) taken in development and testing
>     are also
>     >>> replicated in production.
>     >>>
>     >>> Wouldn't it make more sense to have some deployment control metadata
>     >>> (maybe even just a MANIFEST header) that says whether the particular
>     >>> archive should be exploded?
>     >>>
>     >>> Also, I don't think it's clear that you always want to explode
>     the outer
>     >>> archive if an inner archive is to be exploded (I'm not sure that's
>     >>> necessarily implied by the proposed design, but it certainly
>     would be in
>     >>> the recursive case).  In particular it's definitely useful to
>     explode
>     >>> WARs inside of EARs that need not be exploded.
>     >>>
>     >>> Explode!!
>     >>>
>     >>> (eom)
>     >>
>     >> I think the main target for explosion scenarios are tools (IDE,
>     build tools, etc.) in a development environment. so this mecanism is
>     >> transparent from the developer point of vuiew.
>     >> You have the same functionalities as with the scanner with
>     hopefully a better control over the deployment management.
>     >> Also this means you can develop on a remote server or even on a
>     domain without having to rebuild the whole archive everytime.
>     >>
>     >
>     > So would you use the 'explode' operation in your netbeans plugin, i.e.
>     > start archived and explode? I'm curious if the JBDS guys will.
>
>     Well it depends. On NetBeans you have a "Deploy on Save" checkbox so
>     that the 'build' (since the build process it externalized in Netbeans)
>     will no longer produce an archive but a list of changes.
>     So I might need to explode the deployment somewhere in time.
>
>
> I could see this being useful in a scenario where a user launches
> WildFly in something like Docker but they want to see changes on static
> content without a full redeploy.
>
> If it's all local then it's already possible to do this using an
> unmanaged deployment.

I think David's original point was objecting to the "explode" op which 
takes an existing managed archive deployment and turns it into a managed 
exploded deployment. He questions whether that's a valid use case to 
support. It wasn't about whether managed exploded deployments are a good 
idea at all, just whether an internal conversion operation should be 
supported.

Managed exploded deployments have a number of benefits over unmanaged:

1) Remote content administration, no local FS access required
2) Automatic content replication in a managed domain.
3) The content is stored in the internal repo, less likely to get messed 
up somehow by other user activity on the filesystem.

>
>
>
>
>     >
>     > I suspect it would be used as a convenience; i.e. instead of the tool
>     > initially uploading 100 files, it uploads a zip and explodes it. And
>     > then either way it begins to manipulate the few files that the tool
>     > regards as eligible for update without redeploy (.html, .css, etc.)
>
>     That's also a use case (depending on producing an archive in the
>     first place).
>
>     Emmanuel
>
>
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> --
> James R. Perkins
> JBoss by Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat