The first thing to check would be to verify that that the bucket and contents exist in your account. Use the AWS console to log in, go to the S3 tab, and look for the bucket 'cm-31bf91279e41769ff78af22c1a276ece' and verify the /shared/2012-01-12--18-03 folder structure exists. -Dannon On Apr 2, 2012, at 12:40 PM, mailing list wrote:

Hi guys, I'm still stuck on this :-(.

Are there any log files I could look at to get more details? I'm definitely willing to dive in an get to the bottom of this issue. Can anyone recommend a starting point?

Thanks again,

Greg

On Mon, Apr 2, 2012 at 9:01 AM, mailing list <margeemail@gmail.com> wrote:

...

Hi guys,

After launching Cloudman on the Initial Cluster Configuration dialog I selected the "Share-an-Instance Cluster" option and put in this share string: cm-31bf91279e41769ff78af22c1a276ece/shared/2012-01-12--18-03

But after that I see this message in the log:

12:52:19 - Problem copying shared cluster configuration files. Cannot continue with shared cluster initialization.

And nothing else happens after that. The "applications" status stays yellow, and disk status says "0/0".

Here is some more information about the run:

That sharestring is from a share I made in January. It worked when I last tested it in January. I launched via the BioCloudCentral wep app.

Other run information: Instance ID i-8523cee2 Image ID (AMI) ami-500cd139 Security group CloudMan Key pair cloudman_key_pair Placement (zone) us-east-1b

Let me know what other information would be helpful.

Thanks,

Greg

___________________________________________________________ The Galaxy User list should be used for the discussion of Galaxy analysis and other features on the public server at usegalaxy.org. Please keep all replies on the list by using "reply all" in your mail client. For discussion of local Galaxy instances and the Galaxy source code, please use the Galaxy Development list:

http://lists.bx.psu.edu/listinfo/galaxy-dev

To manage your subscriptions to this and other Galaxy lists, please use the interface at:

http://lists.bx.psu.edu/

Hello Ateeq, You are correct, the disk space for accounts is a fixed amount on the public main Galaxy instance. Permanently deleting (sometimes called "Purge/purging" in the UI) datasets and histories is the method to use to create more working space. http://wiki.g2.bx.psu.edu/Main#User_data_and_job_quotas Best, Jen Galaxy team On 4/2/12 12:30 PM, Ateequr Rehman wrote:

Dear Administartor

My disk space quote is full, is their any way to increase it,or only way is delete some files... Best Ateeq Ateequr Rehman House No. 2 ground floor Blauenstr. 10 79115 Freiburg im Breisgau

------------------------------------------------------------------------ **

___________________________________________________________ The Galaxy User list should be used for the discussion of Galaxy analysis and other features on the public server at usegalaxy.org. Please keep all replies on the list by using "reply all" in your mail client. For discussion of local Galaxy instances and the Galaxy source code, please use the Galaxy Development list:

http://lists.bx.psu.edu/listinfo/galaxy-dev

To manage your subscriptions to this and other Galaxy lists, please use the interface at:

http://lists.bx.psu.edu/

How do I know which snapshot is the appropriate one? The folder Dannon mentioned seems to be missing. I swear this sharestring worked when I tested it two months ago. I can't imagine what happened. -Greg On Mon, Apr 2, 2012 at 6:48 PM, Enis Afgan <enis.afgan@irb.hr> wrote:

Along with the folder structure Dannon is referring to, an appropriate EBS snapshot should exits under your account. This is available from the EC2 tab on the AWS console. As far as the complete logs goes, on CloudMan's admin page, there is a link to the full CloudMan log (alternatively, the same log is available under /mnt/cm/paster.log on the instance itself).

Enis

On Tue, Apr 3, 2012 at 5:02 AM, Dannon Baker <dannonbaker@me.com> wrote:

...

The first thing to check would be to verify that that the bucket and contents exist in your account.  Use the AWS console to log in, go to the S3 tab, and look for the bucket 'cm-31bf91279e41769ff78af22c1a276ece' and verify the /shared/2012-01-12--18-03 folder structure exists.

-Dannon

On Apr 2, 2012, at 12:40 PM, mailing list wrote:

...

Hi guys, I'm still stuck on this :-(.

Are there any log files I could look at to get more details?  I'm definitely willing to dive in an get to the bottom of this issue.  Can anyone recommend a starting point?

Thanks again,

Greg

On Mon, Apr 2, 2012 at 9:01 AM, mailing list <margeemail@gmail.com> wrote:

...

Hi guys,

After launching Cloudman on the Initial Cluster Configuration dialog I selected the "Share-an-Instance Cluster" option and put in this share string: cm-31bf91279e41769ff78af22c1a276ece/shared/2012-01-12--18-03

But after that I see this message in the log:

12:52:19 - Problem copying shared cluster configuration files. Cannot continue with shared cluster initialization.

And nothing else happens after that.  The "applications" status stays yellow, and disk status says "0/0".

Here is some more information about the run:

That sharestring is from a share I made in January.  It worked when I last tested it in January. I launched via the BioCloudCentral wep app.

Other run information: Instance ID     i-8523cee2 Image ID (AMI)  ami-500cd139 Security group  CloudMan Key pair        cloudman_key_pair Placement (zone)        us-east-1b

Let me know what other information would be helpful.

Thanks,

Greg

___________________________________________________________ The Galaxy User list should be used for the discussion of Galaxy analysis and other features on the public server at usegalaxy.org.  Please keep all replies on the list by using "reply all" in your mail client.  For discussion of local Galaxy instances and the Galaxy source code, please use the Galaxy Development list:

 http://lists.bx.psu.edu/listinfo/galaxy-dev

To manage your subscriptions to this and other Galaxy lists, please use the interface at:

 http://lists.bx.psu.edu/

___________________________________________________________ The Galaxy User list should be used for the discussion of Galaxy analysis and other features on the public server at usegalaxy.org.  Please keep all replies on the list by using "reply all" in your mail client.  For discussion of local Galaxy instances and the Galaxy source code, please use the Galaxy Development list:

 http://lists.bx.psu.edu/listinfo/galaxy-dev

To manage your subscriptions to this and other Galaxy lists, please use the interface at:

 http://lists.bx.psu.edu/

Thanks Brad. Your last point sounds suspiciously like something I would do ... So whenever I share I can terminate my instance but I shouldn't remove any data? Is that correct? Thanks, Greg On Tue, Apr 3, 2012 at 9:18 AM, Brad Chapman <chapmanb@50mail.com> wrote:

Greg;

...

How do I know which snapshot is the appropriate one?

The Amazon console displays the description for snapshots. They should have a string like:

CloudMan share-a-cluster cluster_name: cm-31bf91279e41769ff78af22c1a276ec

...

The folder Dannon mentioned seems to be missing.

I swear this sharestring worked when I tested it two months ago.  I can't imagine what happened.

CloudMan can't re-build the shared instance without the EC2 folder, since this contains all of the metadata. If you deleted it since last testing it, that would explain the errors you're seeing.

If it wasn't manually deleted, it's possible you may have deleted the entire cm-31bf91279e41769ff78af22c1a276ec bucket at some point when shutting down another CloudMan instance and checking "Remove all data." I've made this mistake in the past, forgetting that I had shared data in that cluster_name.

Hope this helps, Brad