Bug 644328

<provisioning baseDir="$jboss.server.home.dir" ... />

The $jboss.server.home.dir is only meaningful inside the JBossAS instance VM itself (e.g the name of the system property). The core RHQ Server doing the bundle provisioning won't be able to do much with it.

However, we could use some special notation that would make sense to the core server. For example, we do store the installation directory of the JBossAS instance in the resource's plugin configuration. Suppose we introduced something like what the dynagroup language has:

<provisioning baseDir="pluginConfiguration[install.dir]" ... />

This would require <plugin-configuration> to have defined inside of it a simple property called "install.dir".

The value can be obtained via resource config using this same mechanism:

<provisioning baseDir="resourceConfiguration[install.dir]" ... />

This would require <resource-configuration> to have defined inside of it a simple property called "install.dir".

just thought of another way:

<provisioning baseDir="trait[install.dir]" ... />

This would require a <metric> trait to be defined whose name is "install.dir".

(In reply to comment #2)
> This would require a <metric> trait to be defined whose name is "install.dir".

Ah ok, cool. 
At least a <provisioning/> tag should be included to make this explicit.

(In reply to comment #3)
> (In reply to comment #2)
> > This would require a <metric> trait to be defined whose name is "install.dir".
> 
> Ah ok, cool. 
> At least a <provisioning/> tag should be included to make this explicit.

Yes the provisioning tag would still be required because it is the metadata that tells us where the root install location would be for bundles.

The provisioning tag tells the core server what it should use to determine where a bundle should be deployed on a specific resource. Should it look in a plugin configuration property? resource config property? trait? what's the name of the property or trait?  The provisioning tag would tell the server that.

So "trait[install.dir]" would be something like /opt/jboss/server/default/deploy ?

A nice addition would be to allow people to override the default deployment path for a group of servers, e.g. to specify "trait[install.dir]/../myotherdeploydir" during bundle deployment time.

We will need to also prevent/warn users from doing things which we would expect they would not want to do, e.g. deploying a bundle into the root of the server in such a way that the bundle will wipe out their jboss install. Maybe a warning on the wizard screen would be sufficient here.

Giving this more accurate priority

design page here:

http://rhq-project.org/display/RHQ/Design-BundleDeploymentToNonPlatforms

Tasks to complete:

* Update plugin descriptor XML Schema to support new metadata
* Update ANT recipe to support new optional data
* Add new server-side SLSB methods/modify existing SLSB methods to support non-platform groups as bundle destinations
* Add to the GWT UI support to ask for destination base dir selection
* Add agent-side support in the PC to determine the destination base dir (e.g. parse "pluginConfig[install.dir]"

for the next couple weeks, I'll start working on:

* Update plugin descriptor XML Schema to support new metadata
* Update ANT recipe to support new optional data

As I finish that, I will move on to the next things to do.

new remote git branch where the work is being done: nonplatform-bundles-644328

(In reply to comment #9)
> for the next couple weeks, I'll start working on:
> 
> * Update ANT recipe to support new optional data

Because I'm not sure where these optional recipe data will be stored, and if not in the DB, I'm not sure how easy and efficient it will be for the GWT UI to obtain this data, I'm going to skip implementing changes to the recipe for now. When the actual feature is done (or close to done), we can revisit this and add in this optional feature. By then, it will be more clear how all of this will work and how we can have the GWT UI support this.

I'll work on server-side coding now.

everything has been checked into a separate branch to support this feature, except for "* Update ANT recipe to support new optional data" which I am skipping for now since it is optional and there were some questions as to its appropriateness. We'll revisit later.

Unit tests are checked in to test some of this, but not full end to end. I will need to run some manual integration tests to see end-to-end (from GUI to agent and back) work.

preliminary end-to-end testing show this works. I tried a deployment and a purge and both worked (I put my bundle in a subdirectory under a JBossAS installation directory).

The one thing I missed is the bundle deployment view in the UI, specifically in the "Deployment Platforms" table. The icon column is hardcoded to always show the platform icon and the column headers is "Platform" and "Operation System" since we always assumed the resource is a platform. But those columsn should now be "Resource" and "Version". the table data is correct in my test (I see the name of the JbossAS resource and the JbossAS version in those columns), its just the header strings are wrong.

Some feedback after initial demo to the team:

1) we need to figure out how to support those that may have deployed to a mixed group of different platform types (group consisting of Linux + Windows machines, or HP-UX + Solaris machines, for example). We need to test what happens if someone deployed that kind of thing and then upgrades RHQ and now has a Destination that relates to a mixed group (which means it has a null ResourceType which is now bad)

2) Need a hover over the Deployment Resource table column values in the Deployment view - just use the utility to build the disambiguation tooltip

3) The "Base Location" drop down should be a radio button with additional help text. Help text needs to be added to the plugin descriptor so we have something to put in the radio button help

4) Add release notes re: any remote API changes

5) Update the wiki with all the changes to the bundle subsystem

6) Add release notes about no longer being able to deploy to mixed platform groups

7) Add tooltip/help to other fields in the deploy wizard's "create destination" step

8) Rename the jboss "Configuration Set Directory" destBaseDirName to something else... like "Profile Directory"

9) we should be prevent people doing ../../../ in the dest dir.
   security considerations should prohibit this

// a test to see an algorithm that I will use to reject dest dir paths that have ".." that should be rejected.

String aa[] =  {
  "aaa..aaaa...aaa..a/a..a/a../"  ,
  ".."          ,
  "\\.."        ,
  "/.."         ,
  "..\\"        ,
  "../"         ,
  "\\..\\"      ,
  "/../"        ,
  "C:.."        ,
  "C:/.."       ,
  "C:\\.."      ,
  "C:../"       ,
  "C:..\\"      ,
  "C:/../"      ,
  "C:\\..\\"    ,
  "/../ad"      ,
  "../ad"       ,
  "adf/.."      , 
  "adf/../"     , 
  "adf/../aa"   , 
  "adf/../aa"   , 
  "\\..\\ad"    ,
  "..\\ad"      ,
  "adf\\.."     , 
  "adf\\..\\"   , 
  "adf\\..\\aa" , 
  "adf\\..\\aa"
};

for (String a : aa) {
if (a.startsWith("..") || a.matches(".*[/:\\\\]\\.\\..*")) {
	System.out.println("reject: " + a);
} else {
	System.out.println("ok: " + a);	
}
}

I merged the branch into master. The merge commit is a75d632.

did the following:

The "Base Location" drop down is now a radio button with additional help
text. Help text has been added to the plugin descriptor via a "description" attribute.

Release notes re: any remote API changes and the fact that you can no longer deploy to mixed platform groups is here for now: http://rhq-project.org/display/RHQ/Design-BundleDeploymentToNonPlatforms#Design-BundleDeploymentToNonPlatforms-ReleaseNotes

Created additional context help for some fields in the deploy wizard's "create destination" step

Renamed the jboss "Configuration Set Directory" to "Profile Directory"

Put in code that disallows destination directories to have ".." in the path.

added the same two destinations (install and profile directory) to the JbossAS 5 plugin.

this work has been completed. if there are any other plugins we want to add bundle-target support for, we'll do so under a separate bugzilla.

How to test:

1) create a compatible group of JBossAS Server resources
2) put together a test bundle of some content (if you want to test deploying to the deploy/ directory, have a bundle of a war)
3) Upload test bundle and deploy it to your group - if you are deploying a WAR, select the base location of "Profile Directory" and set the destination directory as something like "deploy/test-app"
4) confirm the deployment worked
5) try to upgrade or reinstall the bundle again to the same destination and make sure it works
6) try to revert the bundle and see that it works
7) try to purge the bundle and see that it works

For backwards compatibility, you should do all the above steps for compatible group of platforms and see that you can still deploy to platforms.

One other thing to test:

Make sure the deploy wizard's Create A Destination step works.  You get to this step in the wizard by selecting a particular bundle in the left-hand tree and then clicking the Deploy button.

1) What you should test is that you can only select compatible groups whose type is that which accepts bundles (today, this includes Linux platforms, Windows platforms, (and any other specific platform type), JBossAS Server resources from the jboss-as (4) plugin and JBossAS Server resources for the jboss-as-5 plugin.

2) Test the "+" button - which pops up the "create a group" wizard. Test that you can create any group and if its a valid compatible group containing the resources specified about in 1) that that group pre-populates the group drop down menu in the Bundle Deploy Wizard and the "Base Location" radio buttons change to match the options valid for that type of resource. If you create a group that doesn't match, that group drop down menu should get cleared , as should the base location component (the radio buttons get disabled/cleared).

If you do not provide a valid group in the drop down menu of the bundle deploy wizard, you should not be able to successfully click the Next button and go to the next step in the wizard.

Verified on build#170 (Version: 4.1.0-SNAPSHOT Build Number: 67e6127)

Verified deploy/upgrade/revert and purge bundle to the compatible group of JBossAS Server resources. Verified the backwards compatibility i.e; Deploy/upgrade/revert and purge bundle to the compatible group of platforms.

Verified that user can only select compatible groups for Linux/windows platforms,
JBossAS Server resources from the jboss-as (4) plugin and JBossAS Server resources for the jboss-as-5 plugin.


Verified the "+" button by creating above compatible groups. The group pre-populates the group drop down menu in the Bundle Deploy Wizard and the "Base Location" radio button change to match the options valid for that type of resource. (For JBoss-as resource, the default option selected is 'Install Directory and it shows the other option as 'Profile Directory'. For platforms, it displays the option 'Root File System)

Creating the groups that doesn't match, it clears the 'Resource Group' drop down menu and the 'Base Location'. User is not able to go to the next step if invalid group is provided in the drop down menu of the bundle deploy wizard.

Marking as verified.

Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.