[workspace-user] workspace deployment hangs - unexplained state change

[Tim Freeman]

This looks like expected output actually.  The details of the corruption should
have been printed server-side.  The client always "hangs" unless using the
flag that disables this behavior (it's the "--nosubscriptions" flag, see
"./bin/workspace -h" for a list of commandline flags), it's waiting for more
notifications.  

Once corrupted, the only notification that could come is a termination/destroy
notice which you will get in this case after waiting 30 minutes.  In another
terminal you could call destroy and this client would print that it received a
destroy notification (and that is the only point when it would exit unless
using the "--nosubscriptions" flag).

It's possible to include some or all of the details that are printed server
side in a corruption notification (some grid services do this, like RFT) but it
would involve us going through and picking which information is actually
security sensitive (and this is also something that could potentially be policy
controlled, some admins may be more comfortable than others releasing certain
information). 

Thanks,
Tim 

On Wed, 07 Feb 2007 10:58:39 -0800
Duncan Penfold-Brown <dpb at uvic.ca> wrote:

> Hello again -
> 
> I am having an issue with deploying a workspace using (from what I can 
> tell) a properly configured virtual workspaces system. The problem: when 
> I enter the command
> 
> "workspace --file workspace.epr --metadata sample-workspace.xml 
> --request sample-deployment-request.xml -s 
> https://ugdev10.phys.uvic.ca:8443/wsrf/services/WorkspaceFactoryService"
> 
>  from my workspace-services node, I run into the message "State changed: 
> Unstaged --> Corrupted".
> 
> After I receive this deployment message, the workspace program continues 
> on to Network Configuration, but hangs after printing out a 
> configuration scheme for NIC #1. To ensure that it was a program hang, 
> and not simply a time issue, I've left the workspace program in the 
> state for more than an hour or two, after which nothing had changed.
> 
> Checking and re-checking my system and configuration, I have found 
> nothing that would precipitate a problem like this. I am using a basic 
> ttylinux image, a default scientific linux xen kernel, and simple 
> network settings. I was wondering if this issue is something you've seen 
> before, and if so whether you could recommend tests or checks to find 
> the source of the problem.  The full output is below:
> 
> workspace --file workspace.epr --metadata sample-workspace.xml --request 
> sample-deployment-request.xml 
> -shttps://NNNN.phys.uvic.ca:8443/wsrf/services/WorkspaceFactoryService
> 
> Using endpoint:
> Address: 
> https://NNNN.phys.uvic.ca:8443/wsrf/services/WorkspaceFactoryService
> Reference property[0]:
> <ns1:WorkspaceKey xmlns:ns1="http://www.globus.org/2006/08/workspace" 
> xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
> xsi:type="xsd:string">default</ns1:WorkspaceKey>
> 
> Reading in metadata ... ok.
> Reading in deployment request ... ok.
> 
> *** Deployment request:
> 
>     - Node number: 1
>     - minDuration: 1800 seconds
>     - State: Running
>     - Default shutdown mechanism: Normal
>     - individualPhysicalMemory:
>         - exact: 256.0
> 
> *** Creating workspace "http://example1/localhost/tty-test1"... ok.
> 
> Resource key: 1
> Instantiation time: Wed Feb 07 11:37:57 PST 2007
> Duration: 1800 seconds (roughly 30 minutes)
> Shutdown time: Wed Feb 07 12:07:57 PST 2007
> Resource Termination time: Wed Feb 07 12:37:57 PST 2007
> 
> Wrote EPR to 'workspace.epr'
> 
> Subscribed to termination notification.
> 
> Subscribed to deployment changes. Waiting.
> 
> *** Deployment:
> 
>     - State changed: Unstaged --> Corrupted
> 
> 
> *** Network configuration:
> 
>     - NIC #1
>     - ------------
>     -       Name: eth0
>     -       MAC: ANY
>     -       IP configuration: AllocateAndConfigure
>     -       IP address: 192.168.17.10
>     -       IP gateway: 192.168.17.1
> 
> 
> 
> Thanks
> 
> - Duncan Penfold-Brown, UVic                                            
>