Bug 644328

Summary: Allow to deploy to other types of groups than platform
Product: [Other] RHQ Project Reporter: Heiko W. Rupp <hrupp>
Component: ProvisioningAssignee: John Mazzitelli <mazz>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: medium Docs Contact:
Priority: high    
Version: 4.0.0CC: mazz, skondkar
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-02 03:20:03 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 705059, 715334    

Description Heiko W. Rupp 2010-10-19 09:15:43 EDT
Provisioning actually only allows to deploy to groups of platforms as deployment roots.

It should be possible to deploy to a group of e.g. JBossAS servers. Here the deployment root directory
could be e.g. the jboss.server.home.dir

As RHQ infrastructure does not hard code such resource type specific information, this base directory (and the information if this resource can be deployed to at all), would be encoded in the deployment descriptor

<server name="JBossAS" ...>

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

</server>

ResourceTypes without such a <provisioning/> Tag can not serve as targets for provisioning.
Comment 1 John Mazzitelli 2010-10-19 09:23:04 EDT
<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".
Comment 2 John Mazzitelli 2010-10-19 09:24:26 EDT
just thought of another way:

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

This would require a <metric> trait to be defined whose name is "install.dir".
Comment 3 Heiko W. Rupp 2010-10-19 09:35:35 EDT
(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.
Comment 4 John Mazzitelli 2010-10-19 09:57:48 EDT
(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.
Comment 5 Charles Crouch 2011-05-16 11:23:15 EDT
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.
Comment 6 Charles Crouch 2011-05-20 13:58:39 EDT
Giving this more accurate priority
Comment 7 John Mazzitelli 2011-05-25 11:03:10 EDT
design page here:

http://rhq-project.org/display/RHQ/Design-BundleDeploymentToNonPlatforms
Comment 8 John Mazzitelli 2011-05-30 23:18:28 EDT
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]"
Comment 9 John Mazzitelli 2011-06-02 09:34:43 EDT
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.
Comment 10 John Mazzitelli 2011-06-07 10:10:56 EDT
new remote git branch where the work is being done: nonplatform-bundles-644328
Comment 11 John Mazzitelli 2011-06-07 10:17:01 EDT
(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.
Comment 12 John Mazzitelli 2011-06-13 17:59:34 EDT
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.
Comment 13 John Mazzitelli 2011-06-14 15:24:34 EDT
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.
Comment 14 John Mazzitelli 2011-06-15 13:02:07 EDT
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"
Comment 15 John Mazzitelli 2011-06-15 13:26:57 EDT
9) we should be prevent people doing ../../../ in the dest dir.
   security considerations should prohibit this
Comment 16 John Mazzitelli 2011-06-15 14:54:36 EDT
// 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);	
}
}
Comment 17 John Mazzitelli 2011-06-16 14:39:58 EDT
I merged the branch into master. The merge commit is a75d632.
Comment 18 John Mazzitelli 2011-06-16 15:22:27 EDT
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.
Comment 19 John Mazzitelli 2011-06-23 12:11:02 EDT
added the same two destinations (install and profile directory) to the JbossAS 5 plugin.
Comment 20 John Mazzitelli 2011-06-28 09:25:19 EDT
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.
Comment 21 John Mazzitelli 2011-06-28 09:30:36 EDT
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.
Comment 22 Sunil Kondkar 2011-07-04 09:54:27 EDT
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.
Comment 23 Heiko W. Rupp 2013-09-02 03:20:03 EDT
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.