Bug 761212 - Purge deployment causes deploy and conf directory to be deleted
Purge deployment causes deploy and conf directory to be deleted
Status: CLOSED NOTABUG
Product: RHQ Project
Classification: Other
Component: Provisioning (Show other bugs)
unspecified
x86_64 Linux
medium Severity medium (vote)
: ---
: ---
Assigned To: John Mazzitelli
Mike Foley
:
Depends On:
Blocks: jon30-sprint10/rhq43-sprint10
  Show dependency treegraph
 
Reported: 2011-12-07 16:29 EST by Pilar Bravo
Modified: 2012-01-31 16:36 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-01-31 16:36:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
test bundle (4.06 KB, application/zip)
2011-12-07 16:29 EST, Pilar Bravo
no flags Details

  None (edit)
Description Pilar Bravo 2011-12-07 16:29:05 EST
Created attachment 542194 [details]
test bundle

Description of problem:

I'm trying JON 3.0 bundles component with the new feature which allows the user to deploy to a group of non-platform components (such as servers). I have created a bundle which has a test application and a test config file. The complete bundle is attached.

I've deployed the bundle to a group of jboss servers and all is working fine. The files are correctly copied into conf and deploy.

After that, I've tried the "purge" button and it has caused the deletion of directories deploy and conf, which are the ones referenced in the bundle. So it left the server unusable.

Version-Release number of selected component (if applicable):

JBoss Operations Network 3.0 GA

How reproducible:


Steps to Reproduce:
1. Create bundle with the provided file
2. Deploy the bundle to a server or server group using the profile directory as base location and deploy as deploy directory
3. Select the deployment and click Purge
4. conf and deploy directories are deleted
  
Actual results:

Bundle content deleted from the server. In this case, the application and the configuration file.

Expected results:

The server deploy and conf directories are deleted.

Additional info:
Comment 1 John Mazzitelli 2011-12-09 13:41:32 EST
the first thing that caught my eye was:

destinationFile="../conf/ejemplo-configuracion.xml" 

I think this might cause other problems. Because you are now putting files OUTSIDE of the root bundle destination directory. Perhaps we should prohibit bundles from using ".." in paths like this in the recipe?
Comment 2 John Mazzitelli 2011-12-09 13:52:18 EST
OK, and here I think is the culprit:

      <rhq:deployment-unit name="sar">

Because you are deploying this bundle to the deploy/ directory itself, you need to tell RHQ NOT to manage that root deploy directory (you do this by specifying manageRootDir="false" as an attribute to this deployment-unit element).

See these for more documention:

http://rhq-project.org/display/JOPR2/Ant+Bundles#AntBundles-rhq%3Adeploymentunit
https://bugzilla.redhat.com/show_bug.cgi?id=659142

and the bottom of this blog post talks about this kind of use-case:

http://management-platform.blogspot.com/2011/01/bundle-provisioning-via-rhq.html

this demo might also provide some insight:

http://mazz.fedorapeople.org/demos/bundles/bundles-nonplatforms.ogg
Comment 3 John Mazzitelli 2011-12-09 13:59:17 EST
BTW: if you want to add not only a deployment artifact (like a WAR or EAR) but you also want to add additional things to the core server (like a new conf/ file), then you must do so either:

a) put the conf/ files as a separate bundle and deploy that bundle with manageRootDir=false to the conf/ directory

or

b) bundle your entire JbossAS installation with the full configuration that you want (with your conf/ and deploy/ artifacts in it) and deploy it, rather than simply deploy a war in an already existing JBossAS instance. In other words, provision the JBossAS server ITSELF via the bundle subsystem
Comment 4 John Mazzitelli 2012-01-31 16:36:20 EST
I think the problem here is that the recipe needed to specify manageRootDir=false.

Closing as NOTABUG. Reopen if, after trying manageRootDir=false, problems still persist.

Note You need to log in before you can comment on or make changes to this bug.