New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle parent/child relationship in the orchestration engine/console #63

Closed
ypujante opened this Issue May 24, 2011 · 3 comments

Comments

Projects
None yet
2 participants
@ypujante
Member

ypujante commented May 24, 2011

Currently the agent handle parent/child relationship, but it is not supported in the orchestration engine (and console). The role of this task will bring support.

Parent/child relationship can be used for:

Example1: webapp
parent = servlet container
children = webapps / wars

Example2: OSGi
parent = OSGi container
children = bundles

The idea is that the lifecycle of the children is obviously related to the lifecycle of the parent but once the parent is up, they can be undeployed/redeployed independently

@ghost ghost assigned ypujante May 24, 2011

@li-mdubey

This comment has been minimized.

Contributor

li-mdubey commented May 24, 2011

We should write unit test to make sure plan generation is working correctly with parent child relationships.
Document using examples on how GLUScripts of parent and child would need to interact with each other.

A more comprehensive test plan for this feature could be:

Create a model with empty container as parent and webapps as children. The testing will include:

  • do a deploy of a child without explicitly deploying parent first => container should be started automatically
  • do a deploy of only parent => make sure container comes up and stays up
  • do a bounce and redeploy of parent => both parent and child should be bounced and redeployed in the right order
  • do a bounce and redeploy of child => only child should be bounced and redeployed, parent remains untouched
  • stop child and do a bounce of container => make sure child remains down
  • stopping container should automatically stop the child first
  • make sure all of the above from UI and command line
@ypujante

This comment has been minimized.

Member

ypujante commented May 24, 2011

Other test case I just thought about:

  1. deploy w1 with parent c1
  2. change system so that w1 has parent c2

Expected result: w1 is undeployed completely and redeployed in c2

ypujante added a commit that referenced this issue May 25, 2011

#63: first pass.
Introducing new concepts (java) for computing delta and reusing
same delta for view and plan (see orchestration engine documentation)

ypujante added a commit that referenced this issue May 27, 2011

ypujante added a commit that referenced this issue May 27, 2011

ypujante added a commit that referenced this issue May 28, 2011

ypujante added a commit that referenced this issue May 29, 2011

#63: rewired console
use new classes for computing / executing plan (not working)

ypujante added a commit that referenced this issue May 30, 2011

#63: changed delta service to use delta mgr instead
* now returning all delta (not just one)

ypujante added a commit that referenced this issue Jun 12, 2011

#63: first pass.
Introducing new concepts (java) for computing delta and reusing
same delta for view and plan (see orchestration engine documentation)

ypujante added a commit that referenced this issue Jun 12, 2011

ypujante added a commit that referenced this issue Jun 12, 2011

ypujante added a commit that referenced this issue Jun 12, 2011

#63: rewired console
use new classes for computing / executing plan (not working)

ypujante added a commit that referenced this issue Jun 12, 2011

#63: changed delta service to use delta mgr instead
* now returning all delta (not just one)

ypujante added a commit that referenced this issue Jun 12, 2011

ypujante added a commit that referenced this issue Jun 12, 2011

ypujante added a commit that referenced this issue Jun 12, 2011

#63: introduced notion of transition
* handle transitions properly when parent/child
* need to convert transitions to plan

ypujante added a commit that referenced this issue Jun 12, 2011

ypujante added a commit that referenced this issue Jun 12, 2011

#63: handle empty agents again
fixed agent tags issue

ypujante added a commit that referenced this issue Jun 12, 2011

#63: reintroduced bounce/undeploy/redeploy
* more work needed on parent/child with filter for
bounce/undeploy/redeploy

ypujante added a commit that referenced this issue Jun 12, 2011

#63: agent self upgrade now using delta computation
* introduced RecoverableAgentProxy to allow some slack in case agent is temporarily down
* agent self upgrade uses the 'normal' delta computation
* agent upgrade cleanup alsu uses 'normal' delta compution

ypujante added a commit that referenced this issue Jun 12, 2011

#63: handle missing agent and transition
* generate a skippable transition which generates a noop step

ypujante added a commit that referenced this issue Jun 12, 2011

#63: added agent descriptor adjuster concept
* streamline plan generation and allow customization of the ouput through the adjuster

ypujante added a commit that referenced this issue Jun 12, 2011

#63: added metadata and tags to initParameters
fixed couple of issues (in bounce/redeploy)

ypujante added a commit that referenced this issue Jun 12, 2011

ypujante added a commit that referenced this issue Jun 12, 2011

#63: create empty system when new fabric
* handle non empty agents properly
* implemented rest api for /model/delta

ypujante added a commit that referenced this issue Jun 12, 2011

@ypujante

This comment has been minimized.

Member

ypujante commented Jun 12, 2011

Implemented with 3.0.0.RC1

@ypujante ypujante closed this Jun 12, 2011

ypujante added a commit that referenced this issue Jun 18, 2011

#63: no longer precompute the plans
* compute 1 delta and display a selection box instead of precomputing 8 plans!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment