meeting: bundle deployment to non-platforms

Ian Springer ian.springer at redhat.com
Wed Jun 1 03:06:20 UTC 2011


Another option for people who wanted to manage the app server itself and 
application deployments as separate bundles would be for them to have 
their deploy dir live outside the app server install dir, e.g., app 
server in /opt/jboss and apps in /opt/jboss-deploy.

On 05/31/2011 09:35 AM, David A. Webster wrote:
> I think it's a given that if you deploy an app server bundle (as in to 
> install a fresh version of the server), or even to patch a server with 
> a "clean" install, it means that all app deployments, jdbc connection 
> pools, etc.,  get blown away.  Up to the bundle creator to keep track 
> of that.  An "incremental" app server bundle deployment, however, 
> should not do that....
>
> David Webster
> Union Pacific Railroad
> Lead Architect-Web Infrastructure
> Systems Engineering
> Phone: (402) 544-1094 | Email: dawebster at up.com
>
>
> *Jay Shaughnessy <jshaughn at redhat.com>*
> Sent by: rhq-devel-bounces at lists.fedorahosted.org
>
> 05/27/2011 11:09 AM
> Please respond to
> rhq-devel at lists.fedorahosted.org
>
>
> 	
> To
> 	rhq-devel at lists.fedorahosted.org
> cc
> 	
> Subject
> 	Re: meeting: bundle deployment to non-platforms
>
>
>
> 	
>
>
>
>
>
>
>
> On 5/27/2011 11:46 AM, Ian Springer wrote:
> > On 05/27/2011 11:15 AM, John Mazzitelli wrote:
> >>> * Originally bundles were designed to lay down complete servers (app
> >>> server with apps already in place, etc).   The latest proposal moves
> >>> toward smaller, one-off  deployments.  We may need to work out the
> >>> semantics around when one bundle's deployment dir is a subdir of 
> another
> >>> bundle's deployment dir.  For example, bundle-1 is an app-server and
> >>> bundle-2 is a web-app.  And then bundle-1 gets reverted...
> >> yet another good question - we need to think about this. deploying a
> >> bundle inside a bundle will be problematic.
> >
> > I think the solution here would be for the user to make sure the outer
> > bundle includes the deploy directory in the list of directories to 
> ignore.
> >
> > We could help alleviate this by checking if the selected destination dir
> > is a subdir of any other deployed bundle's destination dir before
> > deploying the bundle. The warning could look something like this:
> >
> > "Warning: The selected destination directory
> > '/opt/jboss-eap-5.1.1.GA/jboss-as/default/server/deploy' is a
> > subdirectory of the deployed bundle 'JBoss EAP' v2.0. Future updates of
> > the 'JBoss EAP' bundle could blow away the 'MyEnterpriseApp.ear' bundle
> > unless the 'JBoss EAP' bundle is configured to ignore the
> > '/opt/jboss-eap-5.1.1.GA/jboss-as/default/server/deploy' directory. Are
> > you sure you want to proceed?"
> We need a solution that does not require one bundle's design to need
> knowledge of a future bundle's needs. It may not even be possible.  I'd
> favor an approach that has very autonomous bundle behavior and just
> clearly states the semantics. The fact is that nothing prevents the user
> from deploying server-level bundles.  So, if they opt for more-granular
> bundle deployments, potentially on top of another bundle's deployment,
> then we just need to make clear what will happen. In fact it may be no
> different that what happens today.  Which, I think is a revert back to
> the previous deployment that maintains changed files. Not sure.  I think
> we may want to avoid introducing any concept of bundle hierarchy, it
> would be quite complex.  Tags and Descriptions may be enough to do what
> is needed.
>
> This is not too unlike keeping support for "clean" deployments.  When
> selected it means the entire deploy directory is wiped prior to laying
> down the new bits. This obviously could have impact on layered bundling,
> and certainly could be detrimental to something like a deploy
> directory.  And that is why everything to do with bundling should be
> done first in test, then perhaps in staging, and finally in production
> envs.  And that is exactly what bundle destinations are all about. The
> idea being that destinations can be set up for test/stage/prod envs,
> with perhaps different bundle versions deployed to each, in a
> progressive lifecycle.
>
> >>> * Question - where is the deployment meta-data kept?  It can't be 
> stored
> >>> under the deploy directory, right?
> >> and yet another good question. We do support the ability to deploy
> >> bundles in the deploy/ directory (if you enable that new feature where
> >> the recipe tells us to not fully manage the root dest dir). 
> HOWEVER, you
> >> can only deploy ONE bundle to it. You can't deploy more than one 
> because
> >> the metadata will overlap/overwrite each other. So this is something
> >> else to think about.
> > In the case of deploying an exploded ear or war, the bundle metadata
> > could potentially be stored in the ear or war directory. However, this
> > wouldn't work out if the ear or was deployed as a file, or for a bundle
> > that included multiple deployments (e.g. an ear, a sar, and a ds.xml
> > file), so I think we're going to have to add support for multiple
> > bundles deployed to the same destination directory.
> I was concerned about even the validity of placing files under some of
> these potential destination directories.
>
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/rhq-devel
> >
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
>
>
>
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel


-- 
Ian Springer
Principal Software Developer
JBoss Operations Network
Red Hat
ian.springer at redhat.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://fedorahosted.org/pipermail/rhq-devel/attachments/20110531/5b24e7a4/attachment-0001.html 


More information about the rhq-devel mailing list