Managed exploded deployments

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Managed exploded deployments

Brian Stansberry
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."

--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Managed exploded deployments

David Lloyd-2
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)

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

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Managed exploded deployments

Emmanuel Hugonnet
In reply to this post by Brian Stansberry
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Managed exploded deployments

Emmanuel Hugonnet
In reply to this post by David Lloyd-2


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.

Emmanuel

>
>> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Managed exploded deployments

Brian Stansberry
In reply to this post by Emmanuel Hugonnet
So in terms of the requirements analysis:

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.

If there is no objection to this, then the requirement should be altered.

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

This I think is a nice-to-have requirement. (And yes, I know it already
exists, but if we by some strange chance find horrible problems then it
can be dropped.)

> * you can start from an 'empty' deployment and add contents to it step by step

Yep. This one is in the hard requirements.

>
> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Managed exploded deployments

Brian Stansberry
In reply to this post by Emmanuel Hugonnet
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.

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

> Emmanuel
>
>>
>>> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Managed exploded deployments

Brian Stansberry
In reply to this post by David Lloyd-2
On 6/10/16 9:22 AM, 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.
>

The admin already has this capability; they can just convert a zip to
unmanaged exploded and redeploy.  Granted, this op makes it easier to do
and bypasses limitations that currently exist like the need for said
admin to write to the local FS.

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

This one gives me a not so nice feeling, as now we are taking things
typically done by DUPs (analyzing deployment structure, extracting
files, parsing) and doing it in a different area.

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

There's a lot of complexity that comes from allowing the parent to be an
archive and the child exploded. And I don't see a huge benefit. How much
unzipped child content do ears have? Mostly a few deployments
descriptors and a manifest.

I certainly see a benefit though in having the parent and 1 child
exploded while all other children remain as zips.


> Explode!!
>
> (eom)
>
>> 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."
>>
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Managed exploded deployments

Emmanuel Hugonnet
In reply to this post by Brian Stansberry


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 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Managed exploded deployments

James Perkins
In reply to this post by Emmanuel Hugonnet


On Fri, Jun 10, 2016 at 7:24 AM, Emmanuel Hugonnet <[hidden email]> 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.

I think there should be a force attribute, or something along those lines, that can be changed to indicate an add shouldn't override. It can default to false, but there are probably scenarios where you would want an add to fail of the content already exists.
 
* 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
James R. Perkins
JBoss by Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Managed exploded deployments

James Perkins
In reply to this post by Emmanuel Hugonnet


On Fri, Jun 10, 2016 at 8:18 AM, Emmanuel Hugonnet <[hidden email]> 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 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
James R. Perkins
JBoss by Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Managed exploded deployments

Brian Stansberry
In reply to this post by James Perkins
On 6/10/16 4:20 PM, James Perkins wrote:

>
>
> On Fri, Jun 10, 2016 at 7:24 AM, Emmanuel Hugonnet <[hidden email]
> <mailto:[hidden email]>> 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.
>
>
> I think there should be a force attribute, or something along those
> lines, that can be changed to indicate an add shouldn't override. It can
> default to false, but there are probably scenarios where you would want
> an add to fail of the content already exists.

In that case, we should have an op called "update-content". :)

Oh, I think you meant the default should be 'force=true', so by default
add can update but the user can turn that off.

>
>
>     * 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
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> --
> James R. Perkins
> JBoss by Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Managed exploded deployments

Brian Stansberry
In reply to this post by James Perkins
On 6/10/16 4:27 PM, James Perkins wrote:

>
>
> On Fri, Jun 10, 2016 at 8:18 AM, Emmanuel Hugonnet <[hidden email]
> <mailto:[hidden email]>> 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
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> --
> James R. Perkins
> JBoss by Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Managed exploded deployments

James Perkins


On Fri, Jun 10, 2016 at 2:41 PM, Brian Stansberry <[hidden email]> wrote:
On 6/10/16 4:27 PM, James Perkins wrote:
>
>
> On Fri, Jun 10, 2016 at 8:18 AM, Emmanuel Hugonnet <[hidden email]
> <mailto:[hidden email]>> 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.


Got it. I think I misread something in there :)
 
>
>
>
>
>     >
>     > 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
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> --
> James R. Perkins
> JBoss by Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
James R. Perkins
JBoss by Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Managed exploded deployments

James Perkins
In reply to this post by Brian Stansberry


On Fri, Jun 10, 2016 at 2:32 PM, Brian Stansberry <[hidden email]> wrote:
On 6/10/16 4:20 PM, James Perkins wrote:
>
>
> On Fri, Jun 10, 2016 at 7:24 AM, Emmanuel Hugonnet <[hidden email]
> <mailto:[hidden email]>> 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.
>
>
> I think there should be a force attribute, or something along those
> lines, that can be changed to indicate an add shouldn't override. It can
> default to false, but there are probably scenarios where you would want
> an add to fail of the content already exists.

In that case, we should have an op called "update-content". :)

Oh, I think you meant the default should be 'force=true', so by default
add can update but the user can turn that off. 

Yes correct. If we want add-content to also act like update-content I think there should be a way to indicate the operation should fail if content is being updated instead of added.


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
James R. Perkins
JBoss by Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Managed exploded deployments

Brian Stansberry
In reply to this post by Emmanuel Hugonnet
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Managed exploded deployments

David Lloyd-2
In reply to this post by Brian Stansberry
On 06/10/2016 10:16 AM, Brian Stansberry wrote:

> On 6/10/16 9:22 AM, 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.
>>
>
> The admin already has this capability; they can just convert a zip to
> unmanaged exploded and redeploy.  Granted, this op makes it easier to do
> and bypasses limitations that currently exist like the need for said
> admin to write to the local FS.

Sure, but I think that creates a false equivalency between unmanaged
deployments and exploded deployments.  Managed deployments have many
advantages.  Exploded deployments on the other hand have key functional
differences at run time (consider the case we used to discuss all the
time: servlets which call ServletContext.getRealPath() and expect to get
a non-null answer).  If the answer to a given problem is "use an
unmanaged deployment" then I think we have a deficiency with managed
deployments, which were IMO always meant to be the primary deployment
function for most apps; unmanaged deployments were meant to be a
combination of convenience feature and continuation of capabilities from
previous JBoss AS generations.

That said, I think the IDE case (of dynamic content updates) is
completely legitimate, and honestly one I did not think of.  So maybe
the right thing is to support both an operation set as Emmanuel
proposes, *and* a deployment flag that can be set an a per-archive
basis, which would meet all the use cases.

>> 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?
>
> This one gives me a not so nice feeling, as now we are taking things
> typically done by DUPs (analyzing deployment structure, extracting
> files, parsing) and doing it in a different area.

Not necessarily - it could be a simple as adding a DUP step which
examines the descriptor and pokes the VFS mount so that at run time, the
deployment is exploded.  That would satisfy the run-time requirements
without impacting the implementation of the proposed management
operation(s).

>> 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.
>
> There's a lot of complexity that comes from allowing the parent to be an
> archive and the child exploded. And I don't see a huge benefit. How much
> unzipped child content do ears have? Mostly a few deployments
> descriptors and a manifest.

I don't think you need to actively prevent a recursive explode
situation, but I think it's just not always necessary and using the DUP
approach it's easier to just explode individual pieces.  But using the
management operation approach, the opposite is true, as addressing
interior components is more complex than just recursively exploding the
whole thing.

> I certainly see a benefit though in having the parent and 1 child
> exploded while all other children remain as zips.

Sure.

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Managed exploded deployments

Jean-Francois Denise
In reply to this post by Brian Stansberry
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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Managed exploded deployments

David Lloyd-2
In reply to this post by David Lloyd-2
Just had an offline discussion with Emmanuel and he cleared up some
things for me.  Turns out my recollection of how managed deployments
work was faulty (surprise!)... IOW carry on, nothing to see here :-)

On 06/13/2016 08:16 AM, David M. Lloyd wrote:

> On 06/10/2016 10:16 AM, Brian Stansberry wrote:
>> On 6/10/16 9:22 AM, 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.
>>>
>>
>> The admin already has this capability; they can just convert a zip to
>> unmanaged exploded and redeploy.  Granted, this op makes it easier to do
>> and bypasses limitations that currently exist like the need for said
>> admin to write to the local FS.
>
> Sure, but I think that creates a false equivalency between unmanaged
> deployments and exploded deployments.  Managed deployments have many
> advantages.  Exploded deployments on the other hand have key functional
> differences at run time (consider the case we used to discuss all the
> time: servlets which call ServletContext.getRealPath() and expect to get
> a non-null answer).  If the answer to a given problem is "use an
> unmanaged deployment" then I think we have a deficiency with managed
> deployments, which were IMO always meant to be the primary deployment
> function for most apps; unmanaged deployments were meant to be a
> combination of convenience feature and continuation of capabilities from
> previous JBoss AS generations.
>
> That said, I think the IDE case (of dynamic content updates) is
> completely legitimate, and honestly one I did not think of.  So maybe
> the right thing is to support both an operation set as Emmanuel
> proposes, *and* a deployment flag that can be set an a per-archive
> basis, which would meet all the use cases.
>
>>> 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?
>>
>> This one gives me a not so nice feeling, as now we are taking things
>> typically done by DUPs (analyzing deployment structure, extracting
>> files, parsing) and doing it in a different area.
>
> Not necessarily - it could be a simple as adding a DUP step which
> examines the descriptor and pokes the VFS mount so that at run time, the
> deployment is exploded.  That would satisfy the run-time requirements
> without impacting the implementation of the proposed management
> operation(s).
>
>>> 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.
>>
>> There's a lot of complexity that comes from allowing the parent to be an
>> archive and the child exploded. And I don't see a huge benefit. How much
>> unzipped child content do ears have? Mostly a few deployments
>> descriptors and a manifest.
>
> I don't think you need to actively prevent a recursive explode
> situation, but I think it's just not always necessary and using the DUP
> approach it's easier to just explode individual pieces.  But using the
> management operation approach, the opposite is true, as addressing
> interior components is more complex than just recursively exploding the
> whole thing.
>
>> I certainly see a benefit though in having the parent and 1 child
>> exploded while all other children remain as zips.
>
> Sure.
>

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Managed exploded deployments

Rob Stryker
In reply to this post by Brian Stansberry
Quick question here:

Will the various add / update / remove methods have syntax for working on multiple files at once? Or will one management call be required for each request? Requiring a separate management call for each changed file might be pretty slow if the server being acted against is remote.

On Fri, Jun 10, 2016 at 9:38 AM, Brian Stansberry <[hidden email]> 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."

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


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Managed exploded deployments

Emmanuel Hugonnet
Well I only made the add-content (which does the update to) and remove-content support list of content.
Exploding has only one file support as the order might have an impact. Maybe adding recusrive is sufficient ?
read-content is also one file only has I didn't have a proper use-case for multiple targets.
What do you have in mind for read-content or explode ?
Cheers
Emmanuel


On 13/06/2016 19:07, Robert Stryker wrote:

> Quick question here:
>
> Will the various add / update / remove methods have syntax for working on multiple files at once? Or will one management call be required
> for each request? Requiring a separate management call for each changed file might be pretty slow if the server being acted against is remote.
>
> On Fri, Jun 10, 2016 at 9:38 AM, Brian Stansberry <[hidden email] <mailto:[hidden email]>> 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."
>
>     --
>     Brian Stansberry
>     Senior Principal Software Engineer
>     JBoss by Red Hat
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

signature.asc (484 bytes) Download Attachment
12