[jboss-as7-dev] deployments directory usage with openshift

[Brian Stansberry]

It makes logical sense; it lets people separate building/copying around 
the archive from deploying/undeploying it.

Probably not a 7.0 thing though, unless there is an urgent use case.

On 5/24/11 3:04 PM, Scott Stark wrote:
> So right now how a user deploys an application to openshift express is
> that when they create an application, a side-effect of this is that they
> get a git repository on their local machine that maps to the server's
> deployments directory. However, it is only updated by the client
> actions. The repository is not updated to show status changes in the
> deployments status files.
>
> Here is a client side deployment dir repo that shows two deployed
> applications:
> [335](ironmaiden:deployments)>  git status
> # On branch master
> nothing to commit (working directory clean)
> [336](ironmaiden:deployments)>  git pull
> Already up-to-date.
> [337](ironmaiden:deployments)>  ls
> README.txt            weld-permalink.war
> ROOT.war            weld-permalink.war.dodeploy
> ROOT.war.dodeploy
>
> While the server deployments directory has updated deployment status
> file markers:
> [root at ip-10-72-59-227 deployments]# ls
> README.txt  ROOT.war.deployed   weld-permalink.war.deployed
> ROOT.war    weld-permalink.war
>
> The directory on the server is not actually a live repository:
> [root at ip-10-72-59-227 deployments]# git status
> fatal: Not a git repository (or any of the parent directories): .git
>
> it is just a copy that is updated by a git post-receive hook.
>
> Currently, to undeploy an application one git rms it and then pushes the
> content:
> [338](ironmaiden:deployments)>  git rm weld-permalink.war*
> rm 'deployments/weld-permalink.war'
> rm 'deployments/weld-permalink.war.dodeploy'
> [339](ironmaiden:deployments)>  git push
> Everything up-to-date
> [340](ironmaiden:deployments)>  git commit -a -m "undeploy weld-permalink"
> [master 6bfa575] undeploy weld-permalink
>    1 files changed, 0 insertions(+), 0 deletions(-)
>    delete mode 100644 deployments/weld-permalink.war
>    delete mode 100644 deployments/weld-permalink.war.dodeploy
> [341](ironmaiden:deployments)>  git push
> Counting objects: 5, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (2/2), done.
> Writing objects: 100% (3/3), 279 bytes, done.
> Total 3 (delta 1), reused 1 (delta 0)
> To
> ssh://efb401bdb2e641528a1f9278ca091719@as7b4test-sstark.dev.rhcloud.com/~/git/as7b4test.git/
>      067829a..6bfa575  master ->  master
>
> On server:
> [root at ip-10-72-59-227 standalone]# ls deployments/
> README.txt  ROOT.war  ROOT.war.deployed  weld-permalink.war.undeployed
>
> This works fine, it is just not as transparent an experience as working
> with a local directory. I'm not sure how much effort I want to put into
> trying to map the status deployment markers to the client side repo as
> I'm going to look at getting the http management interface multi-plexing
> on the 8080 port and exposed via a rest url associated with the
> application dns name, in this case it would be
> http://as7b4test-sstark.dev.rhcloud.com/management.
>
> So, the point of this post is to ask if it is worth adding a
> x.doundeploy marker to avoid having to remove the application content.
> I'm thinking no, but maybe there are other usecases that would wan this.
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat