deployment options

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

deployment options

Heiko Braun

FYI, can anyone on this list respond to dave?


Begin forwarded message:

Hi Heiko,

I've been following various discussions about the deployment scanner and the content repository for a while, and it doesn't seem like there's a clear answer. What do you think about it? 

I've seen people asking on Stack Overflow whether they are safe to use both deployment methods, and I know that I've laid some foundations to the docs by suggesting that the scanner is a developer tool, and not for production. This surprised some of our consulting team recently, who suggested that customers will use the scanner for app deployments in a production environment. 

Do you have any thoughts on this? 

Dave


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

Re: deployment options

Brian Stansberry
There's nothing not production-worthy about using the deployment scanner
and our docs shouldn't imply it's not ready for production use.

What the scanner is is a task that periodically runs and monitors a
filesystem dir for changes. When it detects changes it invokes
operations against the server management API to trigger content upload
and deployment. It invokes the same operations that can be invoked quite
directly via the CLI or a bit less directly with a GUI via the console.

The CLI can be used to accomplish the same thing, and with the advantage
that the operation is synchronous -- the command is invoked and the
result is known when the command returns. The command can be executed by
a human and the result read, or it can be scripted with the script
checking the result. Contrast this with copying a file into the
deployments dir, waiting some semi-random period of time until the next
scanner run, and then trying to figure out what happened from looking at
logs or the marker files in the deployments/ dir.

In short, using the scanner can be more convenient and has less of a
learning curve, since copying a file to a dir is trivial for anyone,
while using the CLI makes it easy to have greater control. Typically the
"convenience and low learning curve" aspect is more important in a
developer environment, but that doesn't mean people won't prefer the
scanner in a production environment.

An important thing to realize with the scanner though is if you use the
scanner, your API for managing those deployments becomes the OS's
filesystem API. Users shouldn't try to then manipulate the deployments
via the CLI or console. The web console isn't going to let you update or
remove the deployments -- you need to manipulate the deployments/ dir.

On 4/23/12 1:28 AM, Heiko Braun wrote:

>
> FYI, can anyone on this list respond to dave?
>
>
> Begin forwarded message:
>
>> Hi Heiko,
>>
>> I've been following various discussions about the deployment scanner
>> and the content repository for a while, and it doesn't seem like
>> there's a clear answer. What do you think about it?
>>
>> I've seen people asking on Stack Overflow whether they are safe to use
>> both deployment methods, and I know that I've laid some foundations to
>> the docs by suggesting that the scanner is a developer tool, and not
>> for production. This surprised some of our consulting team recently,
>> who suggested that customers will use the scanner for app deployments
>> in a production environment.
>>
>> Do you have any thoughts on this?
>>
>> Dave
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


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

Re: deployment options

Heiko Braun


yes, we are working on making the distinction between the two deployment types (and lack of control for manual deployed items) more clear in the console.

/ike

On Apr 23, 2012, at 10:16 PM, Brian Stansberry wrote:

An important thing to realize with the scanner though is if you use the 
scanner, your API for managing those deployments becomes the OS's 
filesystem API. Users shouldn't try to then manipulate the deployments 
via the CLI or console. The web console isn't going to let you update or 
remove the deployments -- you need to manipulate the deployments/ dir.


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

Re: deployment options

Jason T. Greene
In reply to this post by Brian Stansberry
Another factor is that we recommend that the scanner be turned off in the performance tuning guide (unnecessary  cycles spent polling things that don't change)

In the past FS deployment was less reliable, since we just guessed that a deployment was ready. If you had wierd deployment errors we would tell you to make the scan interval larger. We have actually improved that since AS7. We verify zips are complete before deploying, and we switched to markers for exploded directories (the default).

Sent from my iPhone

On Apr 23, 2012, at 3:19 PM, Brian Stansberry <[hidden email]> wrote:

> There's nothing not production-worthy about using the deployment scanner
> and our docs shouldn't imply it's not ready for production use.
>
> What the scanner is is a task that periodically runs and monitors a
> filesystem dir for changes. When it detects changes it invokes
> operations against the server management API to trigger content upload
> and deployment. It invokes the same operations that can be invoked quite
> directly via the CLI or a bit less directly with a GUI via the console.
>
> The CLI can be used to accomplish the same thing, and with the advantage
> that the operation is synchronous -- the command is invoked and the
> result is known when the command returns. The command can be executed by
> a human and the result read, or it can be scripted with the script
> checking the result. Contrast this with copying a file into the
> deployments dir, waiting some semi-random period of time until the next
> scanner run, and then trying to figure out what happened from looking at
> logs or the marker files in the deployments/ dir.
>
> In short, using the scanner can be more convenient and has less of a
> learning curve, since copying a file to a dir is trivial for anyone,
> while using the CLI makes it easy to have greater control. Typically the
> "convenience and low learning curve" aspect is more important in a
> developer environment, but that doesn't mean people won't prefer the
> scanner in a production environment.
>
> An important thing to realize with the scanner though is if you use the
> scanner, your API for managing those deployments becomes the OS's
> filesystem API. Users shouldn't try to then manipulate the deployments
> via the CLI or console. The web console isn't going to let you update or
> remove the deployments -- you need to manipulate the deployments/ dir.
>
> On 4/23/12 1:28 AM, Heiko Braun wrote:
>>
>> FYI, can anyone on this list respond to dave?
>>
>>
>> Begin forwarded message:
>>
>>> Hi Heiko,
>>>
>>> I've been following various discussions about the deployment scanner
>>> and the content repository for a while, and it doesn't seem like
>>> there's a clear answer. What do you think about it?
>>>
>>> I've seen people asking on Stack Overflow whether they are safe to use
>>> both deployment methods, and I know that I've laid some foundations to
>>> the docs by suggesting that the scanner is a developer tool, and not
>>> for production. This surprised some of our consulting team recently,
>>> who suggested that customers will use the scanner for app deployments
>>> in a production environment.
>>>
>>> Do you have any thoughts on this?
>>>
>>> Dave
>>
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> --
> Brian Stansberry
> Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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

Re: deployment options

Max Rydahl Andersen

> Another factor is that we recommend that the scanner be turned off in the performance tuning guide (unnecessary  cycles spent polling things that don't change)

This just disable deployment at runtime, correct ?

At startup the directory is still scanned making file copying approach still viable for those that prefer that option.

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

Re: deployment options

Wolf-Dieter Fink
Depends on what you do,
if set the scan period==0 the scanner will only pick-up all during startup.
If you remove the complete subsystem the only possibility to deploy is
the web or CLI interface.

- Wolf

On 04/25/2012 01:32 PM, Max Rydahl Andersen wrote:

>> Another factor is that we recommend that the scanner be turned off in the performance tuning guide (unnecessary  cycles spent polling things that don't change)
> This just disable deployment at runtime, correct ?
>
> At startup the directory is still scanned making file copying approach still viable for those that prefer that option.
>
> /max
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: deployment options

Brian Stansberry
Yep, setting the scan-interval attribute to 0 results in a one-time scan
at boot.

Setting scan-enabled attribute to false disables a scanner altogether
but makes it easy to turn back on using the management API.

Removing the subsystem altogether is good if you're sure you'll never
want to scan.

On 4/25/12 7:55 AM, Wolf-Dieter Fink wrote:

> Depends on what you do,
> if set the scan period==0 the scanner will only pick-up all during startup.
> If you remove the complete subsystem the only possibility to deploy is
> the web or CLI interface.
>
> - Wolf
>
> On 04/25/2012 01:32 PM, Max Rydahl Andersen wrote:
>>> Another factor is that we recommend that the scanner be turned off in the performance tuning guide (unnecessary  cycles spent polling things that don't change)
>> This just disable deployment at runtime, correct ?
>>
>> At startup the directory is still scanned making file copying approach still viable for those that prefer that option.
>>
>> /max
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


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