[JBoss AS7 Development] - AS 7 Deployment APIs
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] created the discussion
"AS 7 Deployment APIs"
To view the discussion, visit: http://community.jboss.org/message/559597#559597
--------------------------------------------------------------
Thread to discuss the client deployment APIs for AS 7.
This thread is closely related to and will probably interweave with ALR's thread at https://community.jboss.org/thread/154922?tstart=0 https://community.jboss.org/thread/154922?tstart=0 but that thread has a scope beyond AS 7, so I want a separate one for the purely AS7-focused aspects.
I've posted some thoughts on deployment API in code form in a topic branch on my github repo. See http://github.com/bstansberry/jboss-as/tree/hot-deploy http://github.com/bstansberry/jboss-as/tree/hot-deploy and in particular http://github.com/bstansberry/jboss-as/tree/hot-deploy/domain/src/main/ja... http://github.com/bstansberry/jboss-as/tree/hot-deploy/domain/src/main/ja...
That work is just a draft and a basis for discussion. So thoughts and comments are very much wanted.
The impl subpackages there aren't critical, particularly domain/impl which is for sure wrong. I'm mostly interested in the other packages, which express the API. Note also that much if not all of this should probably move out of the domain module.
There are 2 subpackages, domain and standalone. This is because the API for the full DomainController use case is significantly more complex. There is a fair bit of duplication between the two; perhaps some refactoring could be done once we decide what we want.
The core of this is a client:
1) Gets a reference to DomainDeploymentManager or StandaloneDeploymentManager. How is TBD.
2) Client creates a DeploymentPlan. This describes a coherent unit of work that should be done to add deployment content, deploy content, undeploy content, remove content.
Creation of the DeploymentPlan is done by getting a Builder object from the deployment manager and invoking operations on it.
StandaloneDeploymentManager deploymentManager = magicallyGetDeploymentManager();
File war = getWarFileFromSomewhere();
URL ear = getEarURLFromSomewhere();
DeploymentPlan plan = deploymentManager.newDeploymentPlan()
.withGlobalRollback()
.add(war).andDeploy()
.add(ear).andDeploy();
The main part of the API is in the Builder interfaces that start from the return value from StandaloneDeploymentManager.newDeploymentPlan(). There are five basic operations:
* add -- makes deployment content available to the standalone server or to the domain controller
* deploy -- instruction that previously added content should be deployed on a standalone server or to one or more server groups
* undeploy -- instruction that previously deployed content should be undeployed from a standalone server or from one or more server groups
* replace -- atomic deply+undeploy. So if rollback is enabled and deploying the new content fails, the old content would be deployed
* remove -- remove no longer deployed content from the repository where the standalone server or domain controller keeps content.
I tried to create a fluent API so following one directive to the builder, logically coherent other directives become available, e.g.
add(war).andDeploy()
3) Client asks deployment manager to execute the plan; gets back a DeploymentPlanResult which can be inspected to see what happened. The DeploymentPlanResult returns a Future for each action that went into the deployment plan, so the client can review the result asynchronously.
DeploymentPlanResult result = deploymentManager.execute(plan);
I'll post more later today on some of the nuances, but that's a quick intro. I did a lot of javadoc, so the best way to understand is to poke around.
A few other basic points:
Deployment content once added to the system has a identifying key, in this draft represented by the DeploymentUnitKey class. That's basically an encapsulation of the name of the deployment and it's SHA1 hash. Making clients use the DeploymentUnitKey class feels a bit clunky, so overloaded methods that just use a String form (e.g. "foo.war/a1b2...") are available. Perhaps we should only use the String form in the API?
The API also includes a "repository" notion, e.g. add(String name, String repository, URL content). This isn't core to the API -- it's to support a notion of separate locations where a standalone server could store deployment content, one or more of which might be a hot deployment repository with an associated scanner. We need a separate discussion on whether this is the right way to do hot deployment. If not, the "repository" notion in this API could go away.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/559597#559597]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 8 months
Re: [jboss-dev-forums] [JBoss AS7 Development] - model updates and references
by Emanuel Muckenhuber
Emanuel Muckenhuber [http://community.jboss.org/people/emuckenhuber] replied to the discussion
"model updates and references"
To view the discussion, visit: http://community.jboss.org/message/559596#559596
--------------------------------------------------------------
>
> Brian Stansberry wrote:
>
> I see us having a separate layer, not doing modifications directly on the core model. But we need to start actually fleshing this out to see how it works. I want to start with deployments; perhaps you can identify one or two more types of modifications that are fairly representative of different types of problems we need to handle?
Yeah, i do think that a separate layer would be more interesting. At least changes should be decoupled from the core model - what i mean is that if you have someone editing the domain configuration, we should do a diff based on the edited "version" and then only apply the changes to the core domain model.
Hmm some modifications i have in mind are:
-) subsystem updates - since they are part of extensions
-) creating new subsystems - since they might require an <extension /> module
-) a domain deployment used by 2 server-groups... where you update only one group with a new deployment
-) changing the value of a socket binding / jvm and determining which server-groups / servers are affected
-) a deployment targeted to a single server - which would require to split the server-group? not sure if we want to allow that, but we had some discussions with the console team about that
> Brian Stansberry wrote:
>
> David might want to comment further, but I think we should look at the AbstractModelElement.appendDifferences() method as an initial idea on how to deal with updates, something we can supplement or even move away from completely. It's based on the idea that we have another instance of the model and we then calculate differences and based on those create update actions. It's not clear where that other instance of the model comes from. One of the nice aspects of the appendDifferences idea is only update classes have access to the package-protected modifier methods on the model objects. But then how is the other instance of the model created?
I do like the diff update actions - so that might be the best way moving forward with modifications. However it's a bit unclear since the domain model is not really consistent at the moment.
appendDiff() seems to be the first thing which needs to be changed - since AbstractModel.synchronize(AbstractModel model) is always doing update.applyUpdate(AbstractModel model) on a List<AbstractModelUpdate<?>>. So i guess we would need to have sort of hierarchical updates where each modification maintains a list of updates for it's sub components? At least we should be able to use this as a way to determine whether a profile / subsystem has changed or not.
> Brian Stansberry wrote:
>
> Re: validation -- forgive me for a bit of a tangent: even with the more limited task we've done up to now of creating model objects by parsing, I think we're missing an explicit validation phase. For one thing, it's needed to give model elements a chance to resolve any references to other model elements. I've done a bit of that with RefResolver being passed into model element constructors, but there are cases where it's not valid to try and resolve the reference in the constructor (since the referent may not have been parsed yet). Now we're not resolving until the element is activated, which is too late.
>
> When we talked a week or so ago about a proper reference notion, I was thinking mostly in terms of the rename use case. So if socket-binding "foo" gets renamed "bar", any referring elements are aware of that and change their config to read "bar". But I think a richer reference notion can apply to other problems as well. For example, ServerGroupElement has a fully fleshed out "reference object" linking it to a ProfileElement. So if the ProfileElement is changed (either directly or via a change to a child subsystem) the ServerGroupElement is aware of that. We then use that information to figure out what to push out to the ServerManagers (and on to the Servers).
Yes, i was thinking of a richer notion of references - especially since we have a lot of elements which are referenced in the domain model. Where one part would be - beeing able to validate the domain model as well as figuring out if a configuration update needs to be pushed to e.g. server-group. Although i haven't really thought about merging and activation - which is basically what the RefResolver is used for as well...
Re: renaming - i think this is an operation which does not really fit into appendDiff() / calculateDiff() - if it's only a remove() and add() we would only know that that the model is not valid anymore, however we would loose the information about the renaming part.
I need to think about the actual management API a bit more though...
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/559596#559596]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 8 months
Re: [jboss-dev-forums] [JBoss AS7 Development] - using BatchBuilder for deploying services on startup
by David Lloyd
David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] replied to the discussion
"using BatchBuilder for deploying services on startup"
To view the discussion, visit: http://community.jboss.org/message/559592#559592
--------------------------------------------------------------
> Alexey Loubyansky wrote:
>
> This is what we currently do, i.e. deployments listed in standalone/domain xml are added to BatchBuilder. BatchBuilder is supposed to treat services added to the batch as one deployment, i.e., as I understand, deploy all of them or none if at least one of the services failed.
>
> We touched upon a question (in another thread) whether the server should fail to start if one of its deployments failed. It was decided that the error should be logged but the server continue deploying other services. In this case, we shouldn't use BatchBuilder during server start-up the way we do now.
>
> Or perhaps the concept of BatchBuilder should be advanced and a few different implementations should be provided, e.g.
> - if any of the deployments fail then fail the whole batch;
> - if some specific of the deployments fail then fail the whole batch;
> - each deployment isolated and has no affect on others (kind of a fake batch or no batch).
I don't think that special implementations of BatchBuilder are not the solution here. We do need to make a change to MSC so that batch errors are handled differently. We need to put the decision to cancel the batch into the hands of the caller by way of (for example) a failure list. Not using batches during startup is a non-option however: without using a batch, interdependencies in deployment units cannot be correctly resolved.
Again the type of failure is significant here: a duplicate service name or illegal circular dependency is more "fatal" to a batch. A batch which contains a service which can't start is basically harmless to the running state of the system and the ability to process additional deployments.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/559592#559592]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 8 months
Re: [jboss-dev-forums] [JBoss AS7 Development] - types of deployment errors and their handling
by John Bailey
John Bailey [http://community.jboss.org/people/johnbailey] replied to the discussion
"types of deployment errors and their handling"
To view the discussion, visit: http://community.jboss.org/message/559587#559587
--------------------------------------------------------------
I would like to add a couple definitions to the discussion.
* Activation - The process step that is executing the service activators (sub-systems, Deployments, etc)
* Service Start - The actual start operation on the services themselves
The reason I want to separate these is the error handling should be different. Activation errors in subsystem should be considered catastrophic failures. These will certainly cause major failures further in the startup/runtime. In all likelihood these are not recoverable and will result in only portions of the sub-system services to be available. I feel this should result in halting the server start. I also think service start errors in a sub-system should halt the server startup process as well. I just don't think these can be recovered with a restart.
What does everyone think?
As for deployment activation errors, this has been discussed in previous posts, but in essence these should either rollback the batch or allow the previously added services to remain. Either way, the errors should be logged and server should continue the boot process. Deployment service start errors should also either stop the whole deployment or allow partial start based on user configuration.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/559587#559587]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 8 months
Re: [jboss-dev-forums] [JBoss AS7 Development] - types of deployment errors and their handling
by John Bailey
John Bailey [http://community.jboss.org/people/johnbailey] replied to the discussion
"types of deployment errors and their handling"
To view the discussion, visit: http://community.jboss.org/message/559585#559585
--------------------------------------------------------------
It may be good to clarify the current process being used for deployments. The process for deployments is as follows:
1. Create a sub-batch for the deployment
2. Create a high-level service that represents the deployment (parent service)
3. Add a sub-batch level dependency on the deployment service created in step 2
Having a high-level service for the deployment allows the deployment to be stopped/started/removed in a single unit based on the the batch level dependency.
There are a couple additions that could be made to the process to add richer failure handling. One would be to add a sub-batch level listener that would watch for service start failures and decide whether to stop the whole deployment or to allow a partial deployment service start. This could then be a user provided configuration to decide how to handle partial starts. The second addition would be to add support to roll-back the services added to the batch if any activation errors occur prior to the batch installation. This could be driven with the same user configuration to allow partial deployments. This would require an API addition to batches in MSC.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/559585#559585]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 8 months