Deployment manager states

[Greg Wilkins]

[ for others the code for this is at
  http://dev.eclipse.org/svnroot/rt/org.eclipse.jetty/sandbox/trunk/jetty-deploy-manager ]

Joakime,

let's move past the discussion of how you've implemented the
state machine and agree to disagree for a while.

I'd like to discuss the actual states and lifecycle for a bit.


Currently you have:

  Unavailable, Deployed, Staged, Started.


I'm not sure that Unavailable should be the name of the
starting state or where failed deployments end up.

Webapps already have a concept of unavailable, which means that
something failed during start.  They are a started handler, but
they will respond with 503 unavailable responses either permantently
or for a timeout that was set in the UnavailableException.
This behaviour is governed by the servlet spec.


So the current unavailable state, is actually a substate of
Started (not that I'm keen to have a model with substate, I'm
just stating the current situation).   The current state
machine for a context is more or less:

  Stopped ---> Starting --+---> Started ---------------------+
       ^           ^      |                                  |
       |           |      +---> Started (but unavailable)----+
       |           V                                         |
       |         Failed
       |                                                     |
       +----------------------- Stopping <-------------------+


With the starting/stopping states being very transitory
and only exist for the duration of a call to start() or stop()


We currently do a lot of work during start() - unpacking
and looking at web.xml and jetty-web.xml files etc.
Something we could consider is if any of this work can
be moved out of start() to some configure phase managed
by the deployer.       I don't think we can move web.xml
handling out of start, but we can pre-validate it (as
you are working on).


Widening our view of a context object, we can infer several other
existing "states" that occur before we get to the stopped/started
lifecycle

   Constructed --> Linked --> Configured

where Linked means added to a ContextHandlerCollection (or similar)

Note that Configuration can also occur before a context
has been linked contextHandlerCollection.  I'm ok
if the deployment manager enforces most configuration to
happen after adding the context to a handler
tree - as then the server ref is available and the
context can get things like realms from the server attributes
if it needs.

So maybe the underlying context handler state machine that
we wish to enforce is:

  Constructed   ----> Destroyed
   ^   |
   |   V
   |  Linked
   |   |
   |   V
  Stopped ---> Starting --+---> Started ---------------------+
       ^           ^      |                                  |
       |           |      +---> Started (but unavailable)----+
       |           V                                         |
       |         Failed
       |                                                     |
       +----------------------- Stopping <-------------------+

Where the difference between Linked and Stopped is that
a Stopped app is a Linked app that has been configured and
is ready for start to be attempted.

A Stopped app can be unlinked and become Constructed (a really
bad name.... maybe Discovered ?)

Now these states and transitions are probably too fine grained
to be exposed to the user of the DeploymentManager, but we do
need to associate the DeploymentManager states with these states
in a deterministic way.

I think your UNAVAILABLE state needs to be renamed and equate
to Constructed (which also needs to be renamed)

I think we need at least one FAILED state.  Maybe two
with a (FAILED failed), and a (FAILED started).  The later
being the webapp state of a permanent or transient 503
serving state.

So is it that DEPLOYED == Linked  & STAGED == Stopped?
I don't think so.   DEPLOYED feels more like Stopped to me.

Actually I don't quiet get the difference between DEPLOYED
and STAGED.   Can you describe how STAGED differs from
DEPLOYED in terms of the underlying state of the Context
handler object?

cheers


















































---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[jmcconnell]

Unavailable, Deployed, Staged, Started

I see these as 'human readable' meta states as opposed anything to do
with how they are managed internally to jetty.

Unavailable -> my container knows about the webapp and it is currently
not available for anything in particular
Deployed -> my webapp is deployed, its got all the validated goop it
actually needs to start, etc
Staged -> my webapp should be accessible in some fashion for
validation that it is correctly configured before going live...this
step is optional and if enabled requires toogling via some process
(jmx, admin webapp, etc) to actually make the webapp 'live' on the
context to the real world
Started -> my webapp is 'live'

I don't like 'Started' so much, I like Live for that :)

But I have been in many environments where this staged concept was
required, and where it would be really nice if there was some way of
attaching a 'knob' to a point in the deployment lifecycle to do X.

Its like every shop has a slightly different way they want to deploy
their webapps, someone wants a email to go out when something is
transitioned, someone wants 'QA' to approve things when they go live,
etc etc...

Personally I like the idea of a 'meta' type lifecycle that I could
write a specific targeted bean to attach to and have it run by
whatever process was going on under the hood without having to
understand the entire process intimately.

Very much how I can write a maven plugin to work in a particular
lifecycle of maven without having to understand all the nuts and bolts
that drive maven under the hood.  Or to restate, the ability to have
an arbitrary workflow described for how a webapp gets deployed that I
add my little blurb into where it ought to happen.

jesse


--
jesse mcconnell
jesse.mcconnell@...



On Wed, Oct 21, 2009 at 14:43, Greg Wilkins <gregw@...> wrote:

>
> [ for others the code for this is at
>  http://dev.eclipse.org/svnroot/rt/org.eclipse.jetty/sandbox/trunk/jetty-deploy-manager ]
>
> Joakime,
>
> let's move past the discussion of how you've implemented the
> state machine and agree to disagree for a while.
>
> I'd like to discuss the actual states and lifecycle for a bit.
>
>
> Currently you have:
>
>  Unavailable, Deployed, Staged, Started.
>
>
> I'm not sure that Unavailable should be the name of the
> starting state or where failed deployments end up.
>
> Webapps already have a concept of unavailable, which means that
> something failed during start.  They are a started handler, but
> they will respond with 503 unavailable responses either permantently
> or for a timeout that was set in the UnavailableException.
> This behaviour is governed by the servlet spec.
>
>
> So the current unavailable state, is actually a substate of
> Started (not that I'm keen to have a model with substate, I'm
> just stating the current situation).   The current state
> machine for a context is more or less:
>
>  Stopped ---> Starting --+---> Started ---------------------+
>       ^           ^      |                                  |
>       |           |      +---> Started (but unavailable)----+
>       |           V                                         |
>       |         Failed
>       |                                                     |
>       +----------------------- Stopping <-------------------+
>
>
> With the starting/stopping states being very transitory
> and only exist for the duration of a call to start() or stop()
>
>
> We currently do a lot of work during start() - unpacking
> and looking at web.xml and jetty-web.xml files etc.
> Something we could consider is if any of this work can
> be moved out of start() to some configure phase managed
> by the deployer.       I don't think we can move web.xml
> handling out of start, but we can pre-validate it (as
> you are working on).
>
>
> Widening our view of a context object, we can infer several other
> existing "states" that occur before we get to the stopped/started
> lifecycle
>
>   Constructed --> Linked --> Configured
>
> where Linked means added to a ContextHandlerCollection (or similar)
>
> Note that Configuration can also occur before a context
> has been linked contextHandlerCollection.  I'm ok
> if the deployment manager enforces most configuration to
> happen after adding the context to a handler
> tree - as then the server ref is available and the
> context can get things like realms from the server attributes
> if it needs.
>
> So maybe the underlying context handler state machine that
> we wish to enforce is:
>
>  Constructed   ----> Destroyed
>   ^   |
>   |   V
>   |  Linked
>   |   |
>   |   V
>  Stopped ---> Starting --+---> Started ---------------------+
>       ^           ^      |                                  |
>       |           |      +---> Started (but unavailable)----+
>       |           V                                         |
>       |         Failed
>       |                                                     |
>       +----------------------- Stopping <-------------------+
>
> Where the difference between Linked and Stopped is that
> a Stopped app is a Linked app that has been configured and
> is ready for start to be attempted.
>
> A Stopped app can be unlinked and become Constructed (a really
> bad name.... maybe Discovered ?)
>
> Now these states and transitions are probably too fine grained
> to be exposed to the user of the DeploymentManager, but we do
> need to associate the DeploymentManager states with these states
> in a deterministic way.
>
> I think your UNAVAILABLE state needs to be renamed and equate
> to Constructed (which also needs to be renamed)
>
> I think we need at least one FAILED state.  Maybe two
> with a (FAILED failed), and a (FAILED started).  The later
> being the webapp state of a permanent or transient 503
> serving state.
>
> So is it that DEPLOYED == Linked  & STAGED == Stopped?
> I don't think so.   DEPLOYED feels more like Stopped to me.
>
> Actually I don't quiet get the difference between DEPLOYED
> and STAGED.   Can you describe how STAGED differs from
> DEPLOYED in terms of the underlying state of the Context
> handler object?
>
> cheers
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Gregw]

Jesse,

OK - so I understand STAGED now.   It is like it's running
but the load balancer has not been told yet to direct
real load to it.

I also like your LIVE state as a better name than STARTED.

So I think STAGED, LIVE and UNAVAILABLE (in the JEE sense)
are all substates of the underlying started state.

Thus we do need a better name for the initial state
so it does not clash with the JEE unavailable state.
Let's call it DISCOVERED for now (now == this email
or until a better suggestion comes up).

I'm cool with these being meta states that hide the
nuts and bolts below.  But we do need to know
exactly what the nuts and bolts are.

I think the meta states we have are:

DISCOVERED :   constructed, !validated !linked !configured

DEPLOYED:   constructed, validated, linked, configured, !started

UNAVAILABLE:  started, Unavailable(in JEE sense)

STAGED:  started, !active

LIVE:  started, active


For most webapps, STAGED will automatically flow through to LIVE
(ie if there is no other switch needed to direct traffic to it).
Or it may need even need a manual step in some environments.

UNAVAILABLE: might transit to STAGED if the unavailable exception
had a timeout and on a subsequent attempt to unavailable status
was clear.   We might need to extend jetty with some callback for
this occurrence?


Does this make sense?




Jesse McConnell wrote:

> Unavailable, Deployed, Staged, Started
>
> I see these as 'human readable' meta states as opposed anything to do
> with how they are managed internally to jetty.
>
> Unavailable -> my container knows about the webapp and it is currently
> not available for anything in particular
> Deployed -> my webapp is deployed, its got all the validated goop it
> actually needs to start, etc
> Staged -> my webapp should be accessible in some fashion for
> validation that it is correctly configured before going live...this
> step is optional and if enabled requires toogling via some process
> (jmx, admin webapp, etc) to actually make the webapp 'live' on the
> context to the real world
> Started -> my webapp is 'live'
>
> I don't like 'Started' so much, I like Live for that :)
>
> But I have been in many environments where this staged concept was
> required, and where it would be really nice if there was some way of
> attaching a 'knob' to a point in the deployment lifecycle to do X.
>
> Its like every shop has a slightly different way they want to deploy
> their webapps, someone wants a email to go out when something is
> transitioned, someone wants 'QA' to approve things when they go live,
> etc etc...
>
> Personally I like the idea of a 'meta' type lifecycle that I could
> write a specific targeted bean to attach to and have it run by
> whatever process was going on under the hood without having to
> understand the entire process intimately.
>
> Very much how I can write a maven plugin to work in a particular
> lifecycle of maven without having to understand all the nuts and bolts
> that drive maven under the hood.  Or to restate, the ability to have
> an arbitrary workflow described for how a webapp gets deployed that I
> add my little blurb into where it ought to happen.
>
> jesse
>
>
> --
> jesse mcconnell
> jesse.mcconnell@...
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[jmcconnell]

> OK - so I understand STAGED now.   It is like it's running
> but the load balancer has not been told yet to direct
> real load to it.

Yes, or I have some application I want to test with live data through
a restricted environment like only though some vpn connection to
ensure it 'looks right' before openning to the public or 'is wired up
to all the correct databases' or any of the countless fearful
situations companies processes get themselves into to 'approving
something to go live'


> Thus we do need a better name for the initial state
> so it does not clash with the JEE unavailable state.
> Let's call it DISCOVERED for now (now == this email
> or until a better suggestion comes up).

Fair enough, Discovered works for clusters as well, the webapp has
been pushed out the all of the machines on the cluster and is in
discovered state...ie everyone knows about it.

This gives me the side thought of a corridinated cluster
deployment...where there is corridination of the lifecycles, ie, ALL
machines on cluster have to be in DISCOVERED before they are told to
advance to next phase, and so on and so forth, ensuring that the
webapps transition from phase to phase in lockstep.

> I'm cool with these being meta states that hide the
> nuts and bolts below.  But we do need to know
> exactly what the nuts and bolts are.
>
> I think the meta states we have are:
>
> DISCOVERED :   constructed, !validated !linked !configured
>
> DEPLOYED:   constructed, validated, linked, configured, !started
>
> UNAVAILABLE:  started, Unavailable(in JEE sense)
>
> STAGED:  started, !active
>
> LIVE:  started, active

joakim has some pretty graphics for this he should bust out here


> For most webapps, STAGED will automatically flow through to LIVE
> (ie if there is no other switch needed to direct traffic to it).
> Or it may need even need a manual step in some environments.

agreed, I think the gist behind joakim's efforts are rooted in the
'one size does not fit all' approach to webapp deployment.  So instead
of codifying it strictly in interfaces you extend, you make it more
generally extendable such that the default deployer for jetty is
functionally equivalent in lifecycle as to how it is now, but in other
scenarios where the user needs a staged environment, or the ability to
add in a webapp registry service, or even the lockstep cluster stuff I
mentioned above you have the ability to wire up the workflow as needed
calling out the bits of functionality as needed.

at least that is how I see it

> UNAVAILABLE: might transit to STAGED if the unavailable exception
> had a timeout and on a subsequent attempt to unavailable status
> was clear.   We might need to extend jetty with some callback for
> this occurrence?

I see it that in the normal jetty deployer sense, STAGED is not even a
factor as it is not a part of the default deployer workflow...just
that it will be a very popular component (maybe even developed as a
separate module that they activate and wire in via the deployer
workflow configuration).

I could see users like google app engine tie into this, create a
custom deployment workflow and bundle it up as its own maven artifact,
drop it into lib, drop in a jetty-mydeployment.xml file and good to
go.

Shoot, that would make it really easy to make an ascii image of a
dinosaur that is wired to print to console when a webapp
deploys...awesome test case! :)

cheers,
jesse

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[janb]

I'm not totally onboard (yet) with the STAGED state. Are we saying
that is part of the core lifecycle of deployment? It seems to me
like something that a specific _type_ of deployer might want
to implement.

Jesse's example makes it sound like it is some verification step
after it is started (eg can you hit the app and get back something?)
before the context is declared to be LIVE?

Jan

Jesse McConnell wrote:

>> OK - so I understand STAGED now.   It is like it's running
>> but the load balancer has not been told yet to direct
>> real load to it.
>
> Yes, or I have some application I want to test with live data through
> a restricted environment like only though some vpn connection to
> ensure it 'looks right' before openning to the public or 'is wired up
> to all the correct databases' or any of the countless fearful
> situations companies processes get themselves into to 'approving
> something to go live'
>
>
>> Thus we do need a better name for the initial state
>> so it does not clash with the JEE unavailable state.
>> Let's call it DISCOVERED for now (now == this email
>> or until a better suggestion comes up).
>
> Fair enough, Discovered works for clusters as well, the webapp has
> been pushed out the all of the machines on the cluster and is in
> discovered state...ie everyone knows about it.
>
> This gives me the side thought of a corridinated cluster
> deployment...where there is corridination of the lifecycles, ie, ALL
> machines on cluster have to be in DISCOVERED before they are told to
> advance to next phase, and so on and so forth, ensuring that the
> webapps transition from phase to phase in lockstep.
>
>> I'm cool with these being meta states that hide the
>> nuts and bolts below.  But we do need to know
>> exactly what the nuts and bolts are.
>>
>> I think the meta states we have are:
>>
>> DISCOVERED :   constructed, !validated !linked !configured
>>
>> DEPLOYED:   constructed, validated, linked, configured, !started
>>
>> UNAVAILABLE:  started, Unavailable(in JEE sense)
>>
>> STAGED:  started, !active
>>
>> LIVE:  started, active
>
> joakim has some pretty graphics for this he should bust out here
>
>
>> For most webapps, STAGED will automatically flow through to LIVE
>> (ie if there is no other switch needed to direct traffic to it).
>> Or it may need even need a manual step in some environments.
>
> agreed, I think the gist behind joakim's efforts are rooted in the
> 'one size does not fit all' approach to webapp deployment.  So instead
> of codifying it strictly in interfaces you extend, you make it more
> generally extendable such that the default deployer for jetty is
> functionally equivalent in lifecycle as to how it is now, but in other
> scenarios where the user needs a staged environment, or the ability to
> add in a webapp registry service, or even the lockstep cluster stuff I
> mentioned above you have the ability to wire up the workflow as needed
> calling out the bits of functionality as needed.
>
> at least that is how I see it
>
>> UNAVAILABLE: might transit to STAGED if the unavailable exception
>> had a timeout and on a subsequent attempt to unavailable status
>> was clear.   We might need to extend jetty with some callback for
>> this occurrence?
>
> I see it that in the normal jetty deployer sense, STAGED is not even a
> factor as it is not a part of the default deployer workflow...just
> that it will be a very popular component (maybe even developed as a
> separate module that they activate and wire in via the deployer
> workflow configuration).
>
> I could see users like google app engine tie into this, create a
> custom deployment workflow and bundle it up as its own maven artifact,
> drop it into lib, drop in a jetty-mydeployment.xml file and good to
> go.
>
> Shoot, that would make it really easy to make an ascii image of a
> dinosaur that is wired to print to console when a webapp
> deploys...awesome test case! :)
>
> cheers,
> jesse
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

--
Jan Bartel, Webtide LLC | janb@... | http://www.webtide.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[jmcconnell]

Core lifecycle? certainly not

a common use case for workflow as it relates to deployment, sure

staged is not something to get hung up on imo, it is one example of a
phase in a lifecycle of deployment, one of a full on cornucopia
(thanksgiving coming up!) of potential deployment scenarios which is
at the heart of the discussion at this point.  in reality, we have run
across a couple of scenarios that deployment needed to be extended in
arbitrary ways.  as developers we certainly have the ability to 'make
something work' but as engineers the desire is to create something
that others with less internals knowledge can easily work with to
extend

jetty by default has a simple state machine worth of deployment
'steps' to its workflow...and ideally we would like a way to embrace
and extend that in a simple and easy to visualize way...something that
could wire up arbitrary workflows, from the simple webapp appears in a
directory and it gets unpacked and deployed (oh so simple, ya I know
:P) to the most convoluted cluster coordinated and webapp registered
human workflow finger clicky required audited and reaudited ugly
workflow someone could create (probably a government committee)

cheers,
jesse

--
jesse mcconnell
jesse.mcconnell@...



On Wed, Oct 21, 2009 at 17:49, Jan Bartel <janb@...> wrote:

> I'm not totally onboard (yet) with the STAGED state. Are we saying
> that is part of the core lifecycle of deployment? It seems to me
> like something that a specific _type_ of deployer might want
> to implement.
>
> Jesse's example makes it sound like it is some verification step
> after it is started (eg can you hit the app and get back something?)
> before the context is declared to be LIVE?
>
> Jan
>
> Jesse McConnell wrote:
>>>
>>> OK - so I understand STAGED now.   It is like it's running
>>> but the load balancer has not been told yet to direct
>>> real load to it.
>>
>> Yes, or I have some application I want to test with live data through
>> a restricted environment like only though some vpn connection to
>> ensure it 'looks right' before openning to the public or 'is wired up
>> to all the correct databases' or any of the countless fearful
>> situations companies processes get themselves into to 'approving
>> something to go live'
>>
>>
>>> Thus we do need a better name for the initial state
>>> so it does not clash with the JEE unavailable state.
>>> Let's call it DISCOVERED for now (now == this email
>>> or until a better suggestion comes up).
>>
>> Fair enough, Discovered works for clusters as well, the webapp has
>> been pushed out the all of the machines on the cluster and is in
>> discovered state...ie everyone knows about it.
>>
>> This gives me the side thought of a corridinated cluster
>> deployment...where there is corridination of the lifecycles, ie, ALL
>> machines on cluster have to be in DISCOVERED before they are told to
>> advance to next phase, and so on and so forth, ensuring that the
>> webapps transition from phase to phase in lockstep.
>>
>>> I'm cool with these being meta states that hide the
>>> nuts and bolts below.  But we do need to know
>>> exactly what the nuts and bolts are.
>>>
>>> I think the meta states we have are:
>>>
>>> DISCOVERED :   constructed, !validated !linked !configured
>>>
>>> DEPLOYED:   constructed, validated, linked, configured, !started
>>>
>>> UNAVAILABLE:  started, Unavailable(in JEE sense)
>>>
>>> STAGED:  started, !active
>>>
>>> LIVE:  started, active
>>
>> joakim has some pretty graphics for this he should bust out here
>>
>>
>>> For most webapps, STAGED will automatically flow through to LIVE
>>> (ie if there is no other switch needed to direct traffic to it).
>>> Or it may need even need a manual step in some environments.
>>
>> agreed, I think the gist behind joakim's efforts are rooted in the
>> 'one size does not fit all' approach to webapp deployment.  So instead
>> of codifying it strictly in interfaces you extend, you make it more
>> generally extendable such that the default deployer for jetty is
>> functionally equivalent in lifecycle as to how it is now, but in other
>> scenarios where the user needs a staged environment, or the ability to
>> add in a webapp registry service, or even the lockstep cluster stuff I
>> mentioned above you have the ability to wire up the workflow as needed
>> calling out the bits of functionality as needed.
>>
>> at least that is how I see it
>>
>>> UNAVAILABLE: might transit to STAGED if the unavailable exception
>>> had a timeout and on a subsequent attempt to unavailable status
>>> was clear.   We might need to extend jetty with some callback for
>>> this occurrence?
>>
>> I see it that in the normal jetty deployer sense, STAGED is not even a
>> factor as it is not a part of the default deployer workflow...just
>> that it will be a very popular component (maybe even developed as a
>> separate module that they activate and wire in via the deployer
>> workflow configuration).
>>
>> I could see users like google app engine tie into this, create a
>> custom deployment workflow and bundle it up as its own maven artifact,
>> drop it into lib, drop in a jetty-mydeployment.xml file and good to
>> go.
>>
>> Shoot, that would make it really easy to make an ascii image of a
>> dinosaur that is wired to print to console when a webapp
>> deploys...awesome test case! :)
>>
>> cheers,
>> jesse
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
> --
> Jan Bartel, Webtide LLC | janb@... | http://www.webtide.com
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Gregw]

Jesse McConnell wrote:
> Core lifecycle? certainly not
>
> a common use case for workflow as it relates to deployment, sure


If Stage is the only optional workflow state that we can think of,
then I'd prefer to have it in the base state machine and avoid
the hassles of a dynamically extensible state machine that would
be required to optionally support extra states.


cheers






---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Gregw]

A frequent request that we get is to have the jetty-maven plugin able to
run more than 1 webapp at once... both in development (edit the sources)
mode.


I don't think that could be done in the traditional mvn jetty-run style,
but perhaps we could have a MavenDeployer configuration of the deployment
manager that would discover and configure webapps from 1 or more maven
projects.   It could then share some/most of the guts of the maven
jetty plugin and setup classpaths etc from the project and run in
development mode.


cheers



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[jmcconnell]

lets see...

I see the action of wiring up something like the webapp verifier as a
step in the deployment of a webapp, maybe not a full on 'STATE" but
certainly one step in the process

so long as there is a simple way of arbitrarily wiring functionality X
to the lifecycle of deployment I am pretty happy personally

and that functionality X should be able to run the gambit from webapp
verification, to mailing a mailing list that a webapp has deployed, to
complex scenarios involving coordination in a cluster

I should also be able to wire those up so they execute in a simple
order as well...

When I was looking at wiring up the webapp verifier previously I added
it as a part of webapp configuration itself which it really wasn't I
guess, it was more of a sanity check that this webapp was going to be
allowed to deploy at all, much less get configured, etc...so it really
should have been able to slot in somewhere prior to webapp
configuration even taking place....

we can do a lot of this kinda stuff as jetty developers, but my
concern here is that I see definite points in here that a third party
could want to insert their own functionality in the deployment process
and it currently takes a harder core developer to implement

anyway, I have said my bit...i like the idea of a simple framework
located on this part of jetty that allows third parties to implement
new workflows on top of (like the jetty maven plugin for example)

jesse

--
jesse mcconnell
jesse.mcconnell@...



On Thu, Oct 22, 2009 at 18:48, Greg Wilkins <gregw@...> wrote:

> Jesse McConnell wrote:
>> Core lifecycle? certainly not
>>
>> a common use case for workflow as it relates to deployment, sure
>
>
> If Stage is the only optional workflow state that we can think of,
> then I'd prefer to have it in the base state machine and avoid
> the hassles of a dynamically extensible state machine that would
> be required to optionally support extra states.
>
>
> cheers
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Michael Gorovoy]

+1 for Jesse, and here's my 2 cents worth of thoughts on this issues.

It would take a very sophisticated developer as well as a major effort right now to be able to re-wire the application deployment lifecycle, and I agree with Jesse that Jetty needs to have a way to extend the core lifecycle at the configuration phase to include additional arbitrary steps at any point in the lifecycle, as well as change the cofiguration of the existing steps.

I would suggest to specify the application deployment lifecycle in terms of 'goals' describing where the application is in the deployment process, and 'transitions', that define the conditions that need to be met and actions that need to be performed to move the application to the next 'goal' in the lifecycle.

Each goal would be reachable by any number of transitions, but would have only one exit transition associated with it. Each goal could be either stateful or transitional. When deployment process reaches a stateful goal, the lifecycle will not process the next transition until it is externally re-activated, whereas when deployment process reaches a transitional goal, the next transition will be processed immediately after reaching this goal. Each transition would have two possible result goals that it can bring the lifecycle to, one for success and the other one for failure.

As long as the new architecture will be flexible enough to allow configuring an arbitrary deployment lifecycle using the above abstractions, with goals possibly represented by entries in a data structure, and transitions defined by classes that implement a specified interface, it would be possible to achieve the configurability and avoid having to create an one-size-fits-all solution.

Michael Gorovoy / michael@...

On Thu, Oct 22, 2009 at 9:08 PM, Jesse McConnell <jesse.mcconnell@...> wrote:

lets see...

I see the action of wiring up something like the webapp verifier as a
step in the deployment of a webapp, maybe not a full on 'STATE" but
certainly one step in the process

so long as there is a simple way of arbitrarily wiring functionality X
to the lifecycle of deployment I am pretty happy personally

and that functionality X should be able to run the gambit from webapp
verification, to mailing a mailing list that a webapp has deployed, to
complex scenarios involving coordination in a cluster

I should also be able to wire those up so they execute in a simple
order as well...

When I was looking at wiring up the webapp verifier previously I added
it as a part of webapp configuration itself which it really wasn't I
guess, it was more of a sanity check that this webapp was going to be
allowed to deploy at all, much less get configured, etc...so it really
should have been able to slot in somewhere prior to webapp
configuration even taking place....

we can do a lot of this kinda stuff as jetty developers, but my
concern here is that I see definite points in here that a third party
could want to insert their own functionality in the deployment process
and it currently takes a harder core developer to implement

anyway, I have said my bit...i like the idea of a simple framework
located on this part of jetty that allows third parties to implement
new workflows on top of (like the jetty maven plugin for example)

jesse

--
jesse mcconnell
jesse.mcconnell@...

On Thu, Oct 22, 2009 at 18:48, Greg Wilkins <gregw@...> wrote:
> Jesse McConnell wrote:
>> Core lifecycle? certainly not
>>
>> a common use case for workflow as it relates to deployment, sure
>
>
> If Stage is the only optional workflow state that we can think of,
> then I'd prefer to have it in the base state machine and avoid
> the hassles of a dynamically extensible state machine that would
> be required to optionally support extra states.
>
>
> cheers
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[jmcconnell]

All this being said...I wanted to take a quick step back and start the
review of the artifacts going into 7.0.1 as this has direct bearing on
that...

there are a couple of things in jetty trunk that are currently
deploying snapshot wise into jetty @ eclipse maven central artifact
space and that bears review with this.

namely the jetty-webapp-verifier and the jetty-centalized-logging bits
and pieces..

So, with the idea in mind that jetty @ eclipse is supposed to be best
of breed components and represent the _core_ of jetty I am thinking
that maybe we want to change this a bit.

I propose that maybe the above artifacts and this jetty-deployer work
all go back to codehaus trunk for stewing and to gain some community
traction.  Then if and when these artifacts gain a larger backing and
usage and we want to accept them into honest to god jetty core, we go
ahead and move them over (following whatever processes we need).

This represents a bit of backpedaling on my part (ok maybe a lot) as I
have been an advocate of just getting new development going on at
eclipse, but at least for now I am thinking that we ought to let
things stew at codehaus longer...and also focus on making sure that
eclipse side is a trim lean mean fighting machine, both code and
process wise within eclipse.

thoughts?

jesse


--
jesse mcconnell
jesse.mcconnell@...



On Thu, Oct 22, 2009 at 22:28, Michael Gorovoy <michael@...> wrote:

> +1 for Jesse, and here's my 2 cents worth of thoughts on this issues.
>
> It would take a very sophisticated developer as well as a major effort right
> now to be able to re-wire the application deployment lifecycle, and I agree
> with Jesse that Jetty needs to have a way to extend the core lifecycle at
> the configuration phase to include additional arbitrary steps at any point
> in the lifecycle, as well as change the cofiguration of the existing steps.
>
> I would suggest to specify the application deployment lifecycle in terms of
> 'goals' describing where the application is in the deployment process, and
> 'transitions', that define the conditions that need to be met and actions
> that need to be performed to move the application to the next 'goal' in the
> lifecycle.
>
> Each goal would be reachable by any number of transitions, but would have
> only one exit transition associated with it. Each goal could be either
> stateful or transitional. When deployment process reaches a stateful goal,
> the lifecycle will not process the next transition until it is externally
> re-activated, whereas when deployment process reaches a transitional goal,
> the next transition will be processed immediately after reaching this goal.
> Each transition would have two possible result goals that it can bring the
> lifecycle to, one for success and the other one for failure.
>
> As long as the new architecture will be flexible enough to allow configuring
> an arbitrary deployment lifecycle using the above abstractions, with goals
> possibly represented by entries in a data structure, and transitions defined
> by classes that implement a specified interface, it would be possible to
> achieve the configurability and avoid having to create an one-size-fits-all
> solution.
>
> Michael Gorovoy / michael@...
>
>
> On Thu, Oct 22, 2009 at 9:08 PM, Jesse McConnell <jesse.mcconnell@...>
> wrote:
>>
>> lets see...
>>
>> I see the action of wiring up something like the webapp verifier as a
>> step in the deployment of a webapp, maybe not a full on 'STATE" but
>> certainly one step in the process
>>
>> so long as there is a simple way of arbitrarily wiring functionality X
>> to the lifecycle of deployment I am pretty happy personally
>>
>> and that functionality X should be able to run the gambit from webapp
>> verification, to mailing a mailing list that a webapp has deployed, to
>> complex scenarios involving coordination in a cluster
>>
>> I should also be able to wire those up so they execute in a simple
>> order as well...
>>
>> When I was looking at wiring up the webapp verifier previously I added
>> it as a part of webapp configuration itself which it really wasn't I
>> guess, it was more of a sanity check that this webapp was going to be
>> allowed to deploy at all, much less get configured, etc...so it really
>> should have been able to slot in somewhere prior to webapp
>> configuration even taking place....
>>
>> we can do a lot of this kinda stuff as jetty developers, but my
>> concern here is that I see definite points in here that a third party
>> could want to insert their own functionality in the deployment process
>> and it currently takes a harder core developer to implement
>>
>> anyway, I have said my bit...i like the idea of a simple framework
>> located on this part of jetty that allows third parties to implement
>> new workflows on top of (like the jetty maven plugin for example)
>>
>> jesse
>>
>> --
>> jesse mcconnell
>> jesse.mcconnell@...
>>
>>
>>
>> On Thu, Oct 22, 2009 at 18:48, Greg Wilkins <gregw@...> wrote:
>> > Jesse McConnell wrote:
>> >> Core lifecycle? certainly not
>> >>
>> >> a common use case for workflow as it relates to deployment, sure
>> >
>> >
>> > If Stage is the only optional workflow state that we can think of,
>> > then I'd prefer to have it in the base state machine and avoid
>> > the hassles of a dynamically extensible state machine that would
>> > be required to optionally support extra states.
>> >
>> >
>> > cheers
>> >
>> >
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe from this list, please visit:
>> >
>> >    http://xircles.codehaus.org/manage_email
>> >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Greg Wilkins]

Jesse,

I agree.

In some ways, deploy, verifier and centralized logging are all about
bundling of jetty in various ways - so they almost kind of live better
at codehaus anyway.

Having said that, the existing deployers are definitely part of core
and we do need to replace them eventually with a cleaner, meaner, leaner
implementations.

So I can see the deplay manager going over sooner.... but potentially
into the existing jetty-deploy package.

cheers


Jesse McConnell wrote:

> All this being said...I wanted to take a quick step back and start the
> review of the artifacts going into 7.0.1 as this has direct bearing on
> that...
>
> there are a couple of things in jetty trunk that are currently
> deploying snapshot wise into jetty @ eclipse maven central artifact
> space and that bears review with this.
>
> namely the jetty-webapp-verifier and the jetty-centalized-logging bits
> and pieces..
>
> So, with the idea in mind that jetty @ eclipse is supposed to be best
> of breed components and represent the _core_ of jetty I am thinking
> that maybe we want to change this a bit.
>
> I propose that maybe the above artifacts and this jetty-deployer work
> all go back to codehaus trunk for stewing and to gain some community
> traction.  Then if and when these artifacts gain a larger backing and
> usage and we want to accept them into honest to god jetty core, we go
> ahead and move them over (following whatever processes we need).
>
> This represents a bit of backpedaling on my part (ok maybe a lot) as I
> have been an advocate of just getting new development going on at
> eclipse, but at least for now I am thinking that we ought to let
> things stew at codehaus longer...and also focus on making sure that
> eclipse side is a trim lean mean fighting machine, both code and
> process wise within eclipse.
>
> thoughts?
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email