Sub-Profiles ProfileService changes

[emuckenhuber]

I've committed a initial prototype on sub-profiles in AS trunk, based on different comments i could gather on this topic.

The most important changes are to the ProfileService and Profile spi itself. Where ProfileService got a register and activate method for a profile and the Profile got a list of DependencyItems:

public interface ProfileService
{
 // ....
 public void registerProfile(Profile profile)
 public void activateProfile(ProfileKey key)
 public void releaseProfile(ProfileKey key)
 public void unregisterProfile(Profile profile)
}

public interface Profile
{
 // ....
 Collection<DependencyItem> getDependencies();
}

The full interfaces can be found here:
http://anonsvn.jboss.org/repos/jbossas/projects/integration/trunk/jboss-profileservice-spi/src/main/java/org/jboss/profileservice/spi/ProfileService.java
http://anonsvn.jboss.org/repos/jbossas/projects/integration/trunk/jboss-profileservice-spi/src/main/java/org/jboss/profileservice/spi/Profile.java

One other major change was that i dropped the DeploymentPhase from the profileservice.spi.* interfaces.
I think this is not needed anymore, as the relationships and order when profiles are getting installed should be based on the dependency information of the profile.

Based on that i've created a simple profile factory which does basically the same as the current profile service,
just that there are now 3 active profiles (bootstrap, deployers, $serverName).
The profileService itself uses a scoped mc controller to install/uninstall the profiles in the correct order,
this is also not really finished, but seems to work for now ;)

http://anonsvn.jboss.org/repos/jbossas/trunk/system/src/main/org/jboss/system/server/profileservice/repository/StaticProfileFactory.java
and the beans.xml: http://anonsvn.jboss.org/repos/jbossas/trunk/server/src/etc/conf/default/bootstrap/profile-service.xml

Furthermore i did a simple prototype for xml configuration, based on Adrian's examples in a different thread.
So this could for example look like the files in the 2 folders here:

http://anonsvn.jboss.org/repos/jbossas/trunk/system/src/resources/parsing-tests/
and a simple factory: http://anonsvn.jboss.org/repos/jbossas/trunk/system/src/main/org/jboss/system/server/profileservice/repository/XmlProfileFactory.java

So basically a sub-profile is just a dependency on a different profile. But the main question for me is - from where should e.g. ejb-runtime know that it depends on ejb-deployers?
At the moment i just add some dependencies based on the ordering in the xml, which is not really sophisticated :)

There should only be one single test case failure in the profileservice tests, this is because of a changed behavior of the ManagementView,
but i would like to discuss ManagementView and DeploymentManager in a different thread later on.
Not sure if the clustering tests are using the HASingleton, because i also had to remove the DeploymentPhase there, but it could maybe work - haven't tried that yet.

I don't consider the spi as done and there are still some things to do, but i think this is at least a good start for further discussions on that.
So any ideas / comments / criticism? :)

[ccrouch]

The jopr plugin uses DeploymentPhase, see below for an example

http://anonsvn.jboss.org/repos/jopr/trunk/modules/plugins/jboss-as-5/src/main/java/org/rhq/plugins/jbossas5/ManagedDeploymentComponent.java

How should we fix those?

Thanks

[emuckenhuber]

The jopr plugin uses DeploymentPhase.

How should we fix those?

The interface for DeploymentManager and ManagementView has not been changed yet. Although
i think this should be changed at one point too. Those changes affect AS trunk (AS6) only and
there hasn't been any discussion on what exactly we want to port to 5.x. But i wanted to discuss
DeploymentManager and ManagementView in a different thread anyway.

As you mentioned that there won't be much resources available to work on the jopr AS5 integration
in the next time, this might be a good time to review this too.

[starksm64]

I think we will have to deprecate the old usage and map those onto the replacement for backward compatibility in the 5.x branch. Emanuel was just pushing the prototype to the trunk for review for now.

[emuckenhuber]

So some unordered thoughts about missing things in this prototype:

** dependencies
As mentioned before the main question for me is from where should a runtime profile know that it depends
on a deployer profile in the end? Basically we can also put the deploymentPhase in here to create the
dependencies within an xml file.

** profile-spi
Maybe we should add some properties to the Profile to define some behavior?
e.g. if the profile should do a mainDeployer.checkComplete() with an uncaught exception.
This behavior could also be implied by the deploymentPhase from the xml...

** metadata
There is an initial meta data model in the profileservice.spi.metadata.* which is basically used to create
the profile dependencies and create the deployment repositories. The <sub-profile> is then getting
a simple dependency on a profileKey. The xml could look something like this:

<profiles name="ejb3">
 <profile name="ejb3-deployers">
 <source type="immutable">${jboss.server.base.url}deployers</source>
 <source type="immutable">${jboss.server.base.url}deployers2</source>
 <sub-profile>metadata-deployers</sub-profile>
 <deployment>ejb3.deployer</deployment>
 </profile>
 <profile name="ejb3-runtime">
 <source type="mutable">${jboss.server.base.url}deploy</source>
 <source type="immutable">${jboss.server.base.url}deploy2</source>
 <deployment>ejb3-container-jboss-beans.xml</deployment>
 <deployment>ejb3-interceptors-aop.xml</deployment>
 <deployment>ejb3-timer-service.xml</deployment>
 </profile>
</profiles>

I've also put a List getDependencies - for other non-profile dependencies. But not really sure if we want to have
a profile-dependency on a service?

There is also the AbstractProfileFactory - which creates the available bootstrap profiles. I don't think this is needed in
the spi, as it should just create the bootstrap profiles, which are getting registered and actived in the ProfileServiceBootstrap.

** repository spi
Based on the xml example above, it defines 2 different types for a repository. Furthermore the filtering for the deploymentName
would also need to be done by the repository itself (see FilteredDeploymentFactory).

I'm wondering if the profile should actually do more what the repository is doing now - and the repository would become more a resource discovery.
Not sure about that, but with the current RepositoryFactory spi it's hard to share the same repository for different profiles and
to combine different repository types in a profile.
Maybe a simple method like: public DeploymentRepository createDeploymentRepository(List repositorySource); would be enough.

** VFSDeployment
Due to a comment of Adrian - should we change the VFSDeployment from the profileservice-spi to a simple Deployment ?

** ProfileService
The ProfileService uses MC to resolve the dependencies between the profiles and to install them in the correct order.
Basically all known profiles are getting registered and then you can active e.g. the "default" profile,
which will first install the other profiles this profile depends on (bootstrap and deployers). At them moment profiles
are getting registered as ON_DEMAND and started based on the dependencies. At least i think that should be
the behavior of registering and activating a profile.
I mean we can start profiles also in a different way - but this was the easiest way to do that :)

One isssue though is that i'm using a Scoped MC controller - the only purpose of this was that if we want to do
e.g. mainDeployer.checkComplete() when installing the profiles it would fail, just because not all profiles are installed yet.
And it would also fail with "DEPLOYMENTS MISSING DEPENDENCIES" although it's a profile ;)

Furthermore when shutting down the server the ProfileServiceBootstrap is trying to deactivate all active profiles. This is not really nice,
as it is likely to happen that it tries to deactivate a profile which already has been deactivated due to it's dependencies.
Maybe we should just add a prepareShutdown() and shutdown() to the profileService?

[starksm64]

One other thing that is still vague in my mind is more control over the MC bootstrap components. Right now the bootstrap consists of loading a bootstrap.xml which must also include a Bootstrap bean that integrates with the profile service to load the profile elements.

Unit tests with embedded servers is one example of where there is an interaction between the MC bootstrap and the profile service. If the test was defining the profile services via annotations, the test framework would have to load a bootstrap.xml that included a profile service Bootstrap that obtained the services from the unit test metadata.

[emuckenhuber]

Hmm true, that's still vague. The easiest would be to pass the URL of the root profile xml file to the ProfileFactory.
Although changing the ProfileServiceBootstrap or directly injecting ProfileMetaData for the root profile would be harder to do.

Do we actually have a roadmap for embedded?

[brian.stansberry]

I've gotten a prototype version of deploy-hasingleton functionality to work with the new SPI. Fundamental classes are:

http://anonsvn.jboss.org/repos/jbossas/trunk/cluster/src/main/org/jboss/ha/singleton/HASingletonProfileActivator.java
http://anonsvn.jboss.org/repos/jbossas/trunk/cluster/src/main/org/jboss/ha/singleton/HASingletonProfileManager.java

The HASingletonProfileActivator is configured with the strings necessary to make up a ProfileKey and a ref to the ProfileService. It then exposes methods an HASingletonController can invoke when it becomes/stops being the master. Those methods call ProfileService.activateProfile() and releaseProfile().

The HASingletonProfileManager is a subclass that takes a List as a configuration element and uses that to create a Profile for the deploy-hasingleton content. I'll post separately about why I think this is wrong.

This code is committed but not used yet because making it work requires a change to AbstractProfileService that I want to discuss before committing. Will post separately on that as well.

Some comments on the SPI:

1) Should "public void registerProfile(Profile profile)" instead be "public void registerProfile(ProfileMetaData profile)"? Let the ProfileService handle creation of the Profile from metadata. To make my HASingletonProfileManager work I needed to inject a reference to the ProfileFactory bean, which smells wrong.

2) Similar thing with "public void unregisterProfile(Profile profile)". I think the argument should be a ProfileKey.

3) This is just a nit. Why releaseProfile(ProfileKey key) instead of inactivateProfile(ProfileKey key)?

[brian.stansberry]

As I commented above, I think my HASingletonProfileManager class is the wrong approach. It's a temporary expedient.

It's wrong because something inside a Profile is adding content to the ProfileService at runtime. That means the ProfileService isn't aware of the content unless there is a running AS underneath it that deployed the HASingletonProfileManager.

So, we're better than the AS 5.0.0 case where the ProfileService is only aware on content if there is a running AS underneath *and* it's the master. But still not where we should be.

To get where we should be I think we need something like the MC ControllerMode concept added to ProfileMetaData:

<profiles name="deploy-hasingleton">

 <profile name="deploy-hasingleton-controller">
 <source type="mutable">${jboss.server.base.url}deploy</source>
 <deployment>cluster/deploy-hasingleton-jboss-beans.xml</deployment>
 </profile>

 <profile name="deploy-hasingleton-content" mode="MANUAL">
 <source type="mutable">${jboss.server.base.url}deploy-hasingleton</source>
 </profile>

</profiles>

In this case "MANUAL" means just register the profile but don't activate it; activation requires that something call ProfileService.activateProfile().

Probably different terms than the ControllerModes would be better since the semantics are not identical.

[emuckenhuber]

1) Should "public void registerProfile(Profile profile)" instead be "public void registerProfile(ProfileMetaData profile)"? Let the ProfileService handle creation of the Profile from metadata. To make my HASingletonProfileManager work I needed to inject a reference to the ProfileFactory bean, which smells wrong.

Well the basic idea behind that was to be able to create a Profile outside the ProfileService.
The correct name for the ProfileFactory should be BootstrapProfileFactory (as this thing is just creating profiles for bootstrap).
But i was also thinking about creating a real ProfileFactory, which creates a Profile based on the ProfileMetaData - as this would also go well with some other updates on the meta data model.

2) Similar thing with "public void unregisterProfile(Profile profile)". I think the argument should be a ProfileKey.

Makes sense. I was not sure if this might could get a install/uninstall callback - but i'm not convinced that this makes sense anymore.

3) This is just a nit. Why releaseProfile(ProfileKey key) instead of inactivateProfile(ProfileKey key)?

I've updated the profileservice-spi today and named it 'deactivateProfile' - although if you say that inactivateProfile is better english, i can be easily convinced ;)

Still need to do a new release of the spi and commit some recent work i've been doing.

[emuckenhuber]

In this case "MANUAL" means just register the profile but don't activate it; activation requires that something call ProfileService.activateProfile().

Probably different terms than the ControllerModes would be better since the semantics are not identical.

Basically all Profiles are getting registered as ON_DEMAND - so unless you don't have a dependency on it, it will not get activated unless you explicitly activate it :)

But implicit dependencies with xml processing are also one issue i want to discuss here. As this is not very nice at the moment.
I've got a basic example where you can boot a web-profile, based on the "all" config
(so you have the contents of the all config, but only web is loaded)

[emuckenhuber]

"emuckenhuber" wrote:

Basically all Profiles are getting registered as ON_DEMAND - so unless you don't have a dependency on it, it will not get activated unless you explicitly activate it :)
But implicit dependencies with xml processing are also one issue i want to discuss here.

Well that's only half of the story - just to describe the problem a bit..
The main issue is basically the xml format with implicit dependencies and how you reference a profile -
so that profiles are started and stopped the correct order, or shutdown when a dependency is not satisfied anymore.

Which means you are right saying that something like mode="manual" would make sense.
As at the moment if you would define a clustering profile, like i did in the unit test case it is completely wrong (sorry for that).
In this case if you stop your clustering-hotdeployment directory it would shutdown also the "default" profile, as it is a dependency of that.
Even worse in the case i have now - where you basically shutdown all profiles which are defined after the clustering profile :)

We might want to add something to ignore this dependencies, but i still need to do some more work on that.

[brian.stansberry]

Deactivate is good. :)

"emuckenhuber" wrote:
Basically all Profiles are getting registered as ON_DEMAND - so unless you don't have a dependency on it, it will not get activated unless you explicitly activate it :)

Ah, OK, ProfileServiceBootstrap registers all profiles but only activates the one whose name matches the -c value.

I'll have to walk through SubProfile again stuff again to see how this is all tying together. Seemed like with the StaticProfileFactory "all" depends on BOOTSTRAP and DEPLOYERS but w/ XmlProfileFactory (true dependency), "all" depends on logical subelements, which would mean inactivating just one subelement in the hierarchy would cause the whole ball of wax to ... something.

Ignore the above comment; let me look again.

[brian.stansberry]

Cut-and-paste error there, meant to say:

Seemed like with the StaticProfileFactory "all" depends on BOOTSTRAP and DEPLOYERS (true dependency) but w/ XmlProfileFactory "all" depends on logical subelements ...

[emuckenhuber]

I'll have to walk through SubProfile again stuff again to see how this is all tying together. Seemed like with the StaticProfileFactory "all" depends on BOOTSTRAP and DEPLOYERS but w/ XmlProfileFactory (true dependency), "all" depends on logical subelements, which would mean inactivating just one subelement in the hierarchy would cause the whole ball of wax to ... something.

If you give me some time i'll update trunk to the changed spi and then post some words on that :)
As especially xml processing changed a bit.