[wildfly-dev] Managed exploded deployments

[Kabir Khan]

Please open a separate EAP7 issue linked to the WFCORE one, and let Bilge know so he can rank it
> On 13 Jun 2016, at 17:14, Jean-Francois Denise <jdenise at redhat.com> wrote:
> 
> Hi,
> 
> we have discussed the CLI requirements. The main item is the addition of 
> a support for streams (in batch and non batch) in low level Operation. 
> Doing so we will support the update/add-content operation.
> 
> A field that it a File stream, will be annotated with attached_stream 
> and filesystem_path.
> 
> In the particular case of the update/add-content operation, the 
> index_stream attribute should be renamed to a more appropriate name 
> since we won't use any aliasing in the cli (something like source_file). 
> This does answer the path/stream duality that CLI user could observe (a 
> file system path converted internally onto an array index). Introducing 
> some special aliasing in the metadata would make ergonomics constraint 
> to slip into lower level API. For a simpler command, with better 
> options, we should implement a dedicated Command.
> 
> Discussing the explode operation, we could have a need for an extra 
> operation (list-content) that would allow to offer completion when 
> selecting sub archives to explode.
> 
> JF
> 
> 
> On 10/06/16 23:48, Brian Stansberry wrote:
>> Emmanuel,
>> 
>> Can you work with Alexey and Jeff to add some CLI requirements to this?
>> I went on PTO and forget about our discussions in Neuchatel about being
>> able to associate streams wit the add-content op. If we can't make it
>> easy to do that with low level operations, we'd need a high level command.
>> 
>> The doc already mentions there needs to be some CLI "deploy" command
>> support for starting an empty exploded deployment. Perhaps that's not
>> strictly required though; a low level op could suffice. The deployment
>> doesn't need to be mapped to server groups or enabled until it isn't
>> empty any more.
>> 
>> On 6/10/16 9:24 AM, Emmanuel Hugonnet wrote:
>>> Some details on the current implementation :
>>> * the add-content will overwrite existing content so there is no update-content
>>> updating instead of just adding means having the state on the client as well as on the server which would require more checks to keep those
>>> in sync for no real value from my point of view.
>>> * the add-content/remove-content work with a list of contents thus for an IDE we don't have to create a bunch of ops to upload or delete
>>> each change.
>>> * you can start from an 'empty' deployment and add contents to it step by step
>>> 
>>> Emmanuel
>>> 
>>> 
>>> On 10/06/2016 15:38, 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)
>>>> add-content
>>>> update-content
>>>> remove-content
>>>> read-content
>>>> 
>>>> There is one "nice-to-have" requirement listed on the doc where I'm
>>>> increasingly thinking it needs to be a hard requirement, so thought on
>>>> this are appreciated:
>>>> 
>>>> 
>>>> "The explode operation can take an optional path parameter, the value of
>>>> which is a path within the deployment that should be exploded.
>>>>      * The use case for this is scenarios like an exploded ear that
>>>> contains an unexploded war, and then the user later wishes the war to be
>>>> exploded.
>>>>      * This is much closer to a hard requirement if the nice-to-have
>>>> requirement for recursively exploding is not supported.
>>>>      * This operation will fail if the content referred to by the path
>>>> parameter is already exploded or is not a zip file.
>>>>      * This operation will fail if any content between the root of the
>>>> deployment and the content referred to by the path parameter is an
>>>> unexploded archive.
>>>>          * So,
>>>> /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar)
>>>> would fail if thewar.war hadn't previously been exploded."
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> 
>> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev