The DeploymentManager and ProfileService

[emuckenhuber]

It seems there were some more people struggling with the DeploymentManger interface,
i'll would like to suggest some changes i was planning to do to make it a bit easier to use:

The current way to use DeploymentManager is (pseudo code):

DeploymentProgress distribute = getDeploymentManager().distribute(name, getManagedURL(name), copyContent);
distribute.run();

if (copyContent)
{
 DeploymentProgress start = getDeploymentManager().start(name);
 start.run();
}

DeploymentProgress stop = getDeploymentManager().stop(names);
stop.run();

if (copyContent)
{
 DeploymentProgress undeploy = getDeploymentManager().undeploy(names);
 undeploy.run();
}

Well atm there is still the DeploymentPhase which should also go away.
But this looks a bit confusing.

I think it should have be symmetric whether you do copyContent or not and always have:

deploymentManager.distribute(name, isCopyContent);
deploymentManager.start(name);
deploymentManager.stop(name);
deploymentManager.remove(name);

So for isCopyContent == false - we should have a own transient deployment profile - which gets activated / deactivated by the DeploymentManager.

So a isCopyContent == false app will only get removed from the repository, and not deleted (different for isCopyContent == true).
Especially if you look at the profileService tests in the testsuite, there are a lot of warnings from ManagementView
that the application (which are deployed with isCopyContent == false) don't exist anymore (because there were undeployed in the testcase before)
That's because they just can get stopped, but not be removed from the repository.

[emuckenhuber]

There is also the question whether DeploymentManager.loadProfile(ProfileKey key) is still valid
when having more active profiles.

Maybe we just want to point that to the default hot-deployment profile in future?
Otherwise it might be confusing where the file is actually copied to.

Although this would not make it possible to copy something into the deployers folder (where the question remains if there would be still a deployers folder when we have a xml based configuration)

[emuckenhuber]

Last but not least - the deploymentManager is one of the remaining parts which are making the cleanup of the profileservice-spi a bit harder.

Especially the basic locking which is done when copying a file into a hot-deployment folder.
So maybe we want to remove the enableModifiedDeploymentChecks from the Profile spi:

public interface Profile
{
 /**
 * Enable/disable the getModifiedDeployments results. This can be
 * used to disable the getModifiedDeployments results during
 * periods such as bootstrap where changes should be delayed.
 * @see #getModifiedDeployments
 * @param flag - the enable/disable flag
 */
 void enableModifiedDeploymentChecks(boolean flag);
}

And just have a HDScanner.suspendProfile(ProfileKey key) and HDScanner.resumeProfile(ProfileKey key)
to avoid that the folder is hot-deployment checked when the DeploymentManager is copying a file.
Not sure if that makes more sense, but i think the enableModifiedDeploymentChecks in the Profile spi maybe should not be there.

[starksm64]

"emuckenhuber" wrote:

I think it should have be symmetric whether you do copyContent or not and always have:
...

So for isCopyContent == false - we should have a own transient deployment profile - which gets activated / deactivated by the DeploymentManager.
...

Yes, I agree.

[starksm64]

"emuckenhuber" wrote:
There is also the question whether DeploymentManager.loadProfile(ProfileKey key) is still valid
when having more active profiles.

Isn't it still loadProfile(ProfileKey key, boolean allowHotDeployments)?

Its just a question of which profile the deployment is being added to. Calling profile.enableModifiedDeploymentChecks(allowHotDeployments) and obtaining the DeploymentRepository to upload the content are the two things this does. The later still needs to be done in my view.

[starksm64]

"emuckenhuber" wrote:
Last but not least - the deploymentManager is one of the remaining parts which are making the cleanup of the profileservice-spi a bit harder.

Especially the basic locking which is done when copying a file into a hot-deployment folder.
So maybe we want to remove the enableModifiedDeploymentChecks from the Profile spi:

The locking and enableModifiedDeploymentChecks were hacks to get the hot deployment scanning from interfering with copying new deployment content. The repository itself could either have this flag if its still needed, or just put the burden on the repository implementation to handle concurrency better. The externalized locking and enableModifiedDeploymentChecks were hacks to avoid concurrency problems I was seeing, so first consider just removing them.

[emuckenhuber]

The locking and enableModifiedDeploymentChecks were hacks to get the hot deployment scanning from interfering with copying new deployment content. The repository itself could either have this flag if its still needed, or just put the burden on the repository implementation to handle concurrency better. The externalized locking and enableModifiedDeploymentChecks were hacks to avoid concurrency problems I was seeing, so first consider just removing them.

Okay good to know - that's why i was thinking that DeploymentManager should suspends the profile automatically from scanning.
As we might allow a profile definition like this (at one point):

<hotdeployment-profile name="myhotdeploymentProfile">
 <profile source .../>
 <scan-period>12345</scan-period>
</hotdeployment-profile>

Therefore we could have one HDScanner thread per profile and DeploymentManager suspends the scanner,
when it's uploading contents.

Because i think in the end there will be quite a lot of immutable profiles (defined over xml), where you basically
don't have hot-deployment scanning.
And just the deploy/ directory and the clustering directories as hot-deployment profiles.
IMHO as soon, as you define deployments in a profile, it does not make sense to search for new content.

[emuckenhuber]

To hijack my own thread there is actually one remaining thing in the Profile spi, which i think is not really required:

public interface Profile
{
 /**
 * Update a deployment. This can be used to save attachments, other
 * metadata of the deployment.
 */
 void updateDeployment(VFSDeployment d, ManagedComponent comp) throws Exception;

}

I think it would be enough to have that in the ManagementView only.

A short explanation why... i've worked on removing the VFSDeployment from the profileservice-spi,
which seems to work pretty well.

But the main thing which changed is that ProfileService does not directly use the MainDeployer anymore,
but a kind of wrapper which actually creates a Deployment or VFSDeployment, restores the attachments
and then adds the deployment to the MainDeployer

Therefore ManagementView could simply take care of that, so that we don't have the attachment persistence in 2 different places.
What do you think?

[starksm64]

"emuckenhuber" wrote:

Therefore we could have one HDScanner thread per profile and DeploymentManager suspends the scanner,
when it's uploading contents.

Because i think in the end there will be quite a lot of immutable profiles (defined over xml), where you basically
don't have hot-deployment scanning.
And just the deploy/ directory and the clustering directories as hot-deployment profiles.
IMHO as soon, as you define deployments in a profile, it does not make sense to search for new content.

I'm not sure what your getting at with the last statement. We certainly will have hot deployment, and so a dynamic profile is needed. I would think that the distinction between dynamic/static should be explicit and the current code in the HDScanner that obtains the active profiles would get the dynamic profiles:

 // Get the active profiles
 Collection<ProfileKey> dynamicProfiles = profileService.getDynamicProfileKeys();
 if(activeProfiles == null || activeProfiles.isEmpty())
 {
 if( trace )
 log.trace("End deployment scan, no dynamic profiles");
 return;
 }

I would say the DeploymentManager disabled dynamic profile access using the ProfileService rather than knowing about an HDScanner.

However, the problem is that in general a scan will have started just before the DeploymentManager has disabled the dynamic profile access, so either the new upload has to wait for the current scan to complete (which there currently is no good way to do), or the upload has to deal with concurrency.

Actually, since the upload needs to be targeted to a profile, if only dynamic profiles support adding content, one can know if there is an active query for the modified deployments and block the upload until its done.

Let's sketch out all of the usecases of N dynamic profiles, any of which can be updated via direct access and the DeploymentManager to come up with a stable solution and base the spi from that.

[starksm64]

"emuckenhuber" wrote:

I think it would be enough to have that in the ManagementView only.

The ManagementView was the only user of the call, so if you have folded the impl into its impl there is no reason to have if on the Profile.

[brian.stansberry]

"emuckenhuber" wrote:

Because i think in the end there will be quite a lot of immutable profiles (defined over xml), where you basically
don't have hot-deployment scanning.
And just the deploy/ directory and the clustering directories as hot-deployment profiles.
IMHO as soon, as you define deployments in a profile, it does not make sense to search for new content.

I'm not sure what your getting at with the last statement. We certainly will have hot deployment, and so a dynamic profile is needed. I would think that the distinction between dynamic/static should be explicit and the current code in the HDScanner that obtains the active profiles would get the dynamic profiles

Are two different concepts getting mixed here?

1) Statically defined vs. dynamic profiles. In the former all the contents of the profile are explicitly listed, in the latter a (set of) root URLs is defined and whatever is under those roots becomes part of the profile. The former is largely used to define the server's JBoss-provided capabilities, the latter provides the "drop a war in deploy/ and it gets deployed" functionality for users.

2) Hot deployment == we monitor the profile's contents and if a file changes we redeploy. This applies to both static and dynamic profiles. For dynamic profiles this also includes detecting new items under the root URL and the removal of items under the root URL.

[starksm64]

Are two different concepts getting mixed here?

1) Statically defined vs. dynamic profiles. In the former all the contents of the profile are explicitly listed, in the latter a (set of) root URLs is defined and whatever is under those roots becomes part of the profile. The former is largely used to define the server's JBoss-provided capabilities, the latter provides the "drop a war in deploy/ and it gets deployed" functionality for users.

2) Hot deployment == we monitor the profile's contents and if a file changes we redeploy. This applies to both static and dynamic profiles. For dynamic profiles this also includes detecting new items under the root URL and the removal of items under the root URL.

For me a dynamic profile and hot deployment are a related capability, so we need to define what a profile is to agree on where dynamic behavior comes in. I would NOT agree that a set of root URLs defines a profile. I still think that is a carry over from our old notion. We should be able to define which deployments in the deploy directory for example are actually part of the profile. So I see a profile as having:
- A key which provides a name, some unused hierarchy to an admin domain
- a collection of deployments. Whether or not this can change as well as the deployments themselves can change is what I would call dynamic.
- an optional collection of admin edits to apply to the deployments
- a logical repository that contains the deployments and edits. Right now this is not explicit at the profile api level. The DeploymentManager and ManagementViews require it for their implementation.

If we completely abstract out the deployment and admin content into a deployment repository, then I can see a differentiation between a dynamic profile that is one define by root urls against the deployment repository vs a profile that allows modifications to both deployment collection make up and content changes. With the new subprofiles, we really should not be shipping anything in the deploy directory, or we should have deploy/apps be what is monitored for changes? If there is a deployment repository notion, even urls are an implementation notion, and 'deploy' is really an alias for a class of deployments that depend on the 'bootstrap' and 'deployers'.

I don't think there is a correct definition, just what is going to map best to our usecases and let us get to an spi that is going to work for the several server configurations we know we want to deal with:
- jbossas5 EE5 style
- jbossas6 EE6 style
- testsuite configurations
- embedded
- junit testing

I'm working on the later 2 as I expect that these will most impact the need for a change beyond the current 'deploy', 'bootstrap', 'deployers' notions.

[brian.stansberry]

I think we're on the same page, but I'll respond in detail in case I'm wrong.

For me a dynamic profile and hot deployment are a related capability, so we need to define what a profile is to agree on where dynamic behavior comes in.

Absolutely.

Semi-OT, but one think that makes it hard to discuss is the term "profile" is overloaded. There's an overall profile that's conceptually simple/ easy to explain as an abstraction of the old "all" "default" "minimal" config notion. Then we have elements of a profile that we're calling sub-profiles, but which are currently described in xml via a "profile" element and modelled in code as implementations of the Profile interface.

I would NOT agree that a set of root URLs defines a profile. I still think that is a carry over from our old notion.

No, by itself a set of root URLs doesn't define a profile. In the sense I was talking about, a collection of root URLs is one way of defining the 2nd of your list of things that define a profile: the collection of deployments.

We should be able to define which deployments in the deploy directory for example are actually part of the profile.

Agreed. And in practice I imagine most of the deployments JBoss itself provides will be specified this way. And maybe, in some setups, all the end-user deployments as well. But as a particular implementation of a subprofile it should also be able to define that the "xyz" dir is a location where you can copy a jar and it will be part of the profile.

So I see a profile as having:
- A key which provides a name, some unused hierarchy to an admin domain
- a collection of deployments. Whether or not this can change as well as the deployments themselves can change is what I would call dynamic.

I still see those as two different although related things. Perhaps from the point of view of an SPI it doesn't matter. I'd think management tools would care though: can the tool add or remove content from this subprofile? Can the tool update existing content? Will the repository itself detect and allow content added or removed not via the management tool? Will the repository itself detect updates to existing content? This is all information that should be exposed.

With the new subprofiles, we really should not be shipping anything in the deploy directory, or we should have deploy/apps be what is monitored for changes?

I'd think you'd have common/deploy which basically looks like server/all/deploy, and then server/xxx/deploy would be empty but monitored for changes. That's just a stock config though. People could configure things however they wish.

If there is a deployment repository notion, even urls are an implementation notion, and 'deploy' is really an alias for a class of deployments that depend on the 'bootstrap' and 'deployers'.

Yep, looking at Emmanuels XML examples last week, the "deploy" after "deployers" notion had already somewhat broken down (IMO correctly). E.g. he had a jboss-web.profile which contained a "jboss-web-deployers" subprofile and and an "jboss-web-runtime" subprofile. But within the overall sequence both come after "ejb3-runtime".

[emuckenhuber]

I'm not sure what your getting at with the last statement. We certainly will have hot deployment, and so a dynamic profile is needed.

Definitely dynamic profiles are needed, and now you can even have as many as you want ;)

The only thing i wanted to say is that enableHotDeploymentChecks should maybe not be in Profile spi.
And i haven't really thought about what exactly DeploymentManager calls to suspend HotDeployment checking.
I'm open to suggestions here, haven't done that yet - just trying to cleanup stuff :)

[emuckenhuber]

For me a dynamic profile and hot deployment are a related capability, so we need to define what a profile is to agree on where dynamic behavior comes in.

Hmm yeah we might want to have a Profile and a MutableProfile interface.

So I see a profile as having:
- A key which provides a name, some unused hierarchy to an admin domain
- a collection of deployments. Whether or not this can change as well as the deployments themselves can change is what I would call dynamic.
- an optional collection of admin edits to apply to the deployments
- a logical repository that contains the deployments and edits. Right now this is not explicit at the profile api level. The DeploymentManager and ManagementViews require it for their implementation.

In a nutshell a Profile is a group of deployments (no matter where they come from).
So it can be a static one, based on file scanning we have now or any other source.

I also introduced relationships between profiles - now thinking of it, we might want to have this as
implementation detail. In general this is not explicitly required and it can be different for each implementation.

Furthermore ProfileService / Profile should not or must not know about the actual runtime deployment.
I think this is very important, as the real deployment needs to be done by the deployers (that's why we have them :)
Therefore also the abstraction of a ProfileDeployment.

If we completely abstract out the deployment and admin content into a deployment repository, then I can see a differentiation between a dynamic profile that is one define by root urls against the deployment repository vs a profile that allows modifications to both deployment collection make up and content changes.

One thing i don't like about the current implementation is that a profile is more defined over
it's DeploymentRepository than it is defined by itself (the actual profile).

Well i mean the implementation is not a big deal, just want to say that when talking about the definition of a Profile,
a DeploymentRepository should be optional.

On the other hand this is actually the main point of this thread. Basically how the DeploymentManager gets access
to the low level source of a mutable profile.
I'm not planning to change this yet - just an idea to think about :)

With the new subprofiles, we really should not be shipping anything in the deploy directory, or we should have deploy/apps be what is monitored for changes? If there is a deployment repository notion, even urls are an implementation notion, and 'deploy' is really an alias for a class of deployments that depend on the 'bootstrap' and 'deployers'.

Yes that's where we are definitely are heading for!
I think we might ship a empty deployers directory (where the user can put his own deployers) and a almost empty deploy
directory - where we just have things like ROOT.war, jmx-console.war. So optional things which you can just delete.
But in the end that would not change anything about PS anymore :)

I don't think there is a correct definition, just what is going to map best to our usecases and let us get to an spi that is going to work for the several server configurations we know we want to deal with:
- jbossas5 EE5 style
- jbossas6 EE6 style
- testsuite configurations
- embedded
- junit testing

Hmm yes - although the canonical server is the most important requirement to enable all this.
IMHO a good integration into jboss-test, server-manager are needed before we can move on
updating the testsuite and the distribution. In the meantime we can just base this on a all config.