[ 
https://issues.apache.org/jira/browse/BROOKLYN-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14275406#comment-14275406
 ] 

Aled Sage commented on BROOKLYN-106:
------------------------------------

Eureka! The problem was in our use of the VMware Java SDK for reconfiguring the 
Edge Gateway.

Our approach was to get the "edge gateway service configuration", modify the 
part of it that related to the NAT service, and then call 
`edgeGateway.configureServices(gatewayFeatures)` will all the original 
features. 

The reason that seemed like a good idea was that the API is delicate! If you 
were to create a `NatServiceType` object directly and populate it with just 
your delta, then it would override the existing configuration for all fields 
that you had left as the defaults. For example. it might set `isEnabled` to 
false (which is the default in a Java field), thus disabling the NAT service in 
a way that is invisible in the UI but accessible through the API. Therefore, 
uploading the entire configuration seemed like a better bet.

Changing this to just upload a `new 
ObjectFactory().createNetworkService(natService)` (i.e. creating it from the 
downloaded natService object) means we don't tell it to reconfigure the other 
services (GatewayDhcpServiceType, FirewallServiceType and 
GatewayIpsecVpnServiceType). Doing that - even though the configuration was 
identical - meant our ssh commands hung.

> ssh command hangs (gettin stdout/stderr) for vcloud-director
> ------------------------------------------------------------
>
>                 Key: BROOKLYN-106
>                 URL: https://issues.apache.org/jira/browse/BROOKLYN-106
>             Project: Brooklyn
>          Issue Type: Bug
>    Affects Versions: 0.7.0-SNAPSHOT
>            Reporter: Aled Sage
>            Assignee: Aled Sage
>         Attachments: debug.log.tgz, jstack.txt, messages.tgz, ssh-stdout.txt
>
>
> When deploying Tomcat to VMware's vcloud-air, to a CentOS 6.4 VM, when 
> installing Java it hangs!
> The Brooklyn web-console shows that it is still waiting for a result from the 
> ssh command (which executed `sudo -E -n -S -- yum -y --nogpgcheck install 
> java-1.7.0-openjdk-devel`).
> However, when logging into the VM I can see that the `yum` command has 
> finished, and the /var/log/messages (attached) shows that the install 
> completed.
> This fails repeatedly. It used to pass!
> The stdout is at 32040 bytes. The last few lines of the stdout (as shown in 
> the web-console) are:
> {noformat}
>   Installing : libtasn1-2.3-6.el6_5.x86_64                                
> 50/56
>   Installing : gnutls-2.8.5-14.el6_5.x86_64                               
> 51/56
>   Installing : 1:cups-libs-1.4.2-67.el6.x86_64                            
> 52/56
> {noformat}
> Could there be some buffer set to 32K, so it's stuck not reading the rest of 
> the stdout (but `SshjToolPerformanceTest.testConsecutiveBigStdoutCommands` 
> passes)?
> Why else would our ssh command be stuck, not returning?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to