[Devtools] Question on the cdk + openshift + eap deployment markers

[Rob Stryker]

On 05/02/2016 04:06 AM, Max Rydahl Andersen wrote:
> On 29 Apr 2016, at 6:02, Rob Stryker wrote:
>
>> Hey All:
>>
>> Not sure what list to send this to, since it's part CDK, part 
>> openshift, part EAP. Hope this is the right list.
>>
>> Two issues...
>> First, despite me deleting a .deployed marker (ROOT.war.deployed), 
>> and rsyncing back up to the pod using the --delete flag, the server 
>> seems to be replacing the file immediately, rather than undeploying 
>> the app as it's supposed to.  Is it the case that eap on openshift 
>> cannot undeploy root.war ?
>
> I don't know - but Have you tried doing it manually by ssh'ing in ?

Yes, I've tried this by ssh'ing in and deleting the file, and the server 
log didn't seem to have any output indicating the module stopped.

> Have you tried do it on a local running EAP ?

Yes, on a local running EAP, the server immediately responds with some 
undeploy output. This is not occurring via openshift.

>
> I don't spot what you believe is strange here. Can you be more 
> specific about what you actually expected ?

I was expecting at least one of the commands to behave as the documents 
indicate they should.  The contents of the remote server inside folder 
'x' should be transferred to the local folder 'y'. ie,   x/* should be 
moved into y  as if i had done a cp x/* y/. Instead, behavior seems to 
be either creation of a symlink (?!) or the contents of x (ie x/*) are 
being placed inside y/y-last-segment/.

For example,  when openshift folder 'deployments' has file "x.txt", then 
I would expect oc rsync eap-app-1-auugc:/opt/eap/standalone/deployments/ 
/home/local/path/deploy to place file x.txt inside 
/home/local/path/deploy/. Instead, it is placing x.txt inside 
/home/local/path/deploy/deploy. This is VERY wrong.

Is anyone else able to replicate this??

>
> note: The ending slash matters in rsync.
>
>
> /max
> http://about.me/maxandersen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/devtools/attachments/20160502/f3f99036/attachment.htm>