[wildfly-dev] Managed exploded deployments

[Jean-Francois Denise]

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
>>
>