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
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 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:
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
________________________________
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:
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:
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:
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:
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
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
Greg;
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?
What I do is keep multiple instances with different cluster_names:
- A stable instance to store shared instances. You never want to remove all data with this, since that will destroy the shared instances as well.
- A test instance that I start from the latest snapshot of my stable instance. This is where I do development work and can cleanup without worrying about removing permanent data.
Sorry for the problems and hope this helps, Brad
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:
galaxy-user@lists.galaxyproject.org
-
Ateequr Rehman -
Brad Chapman -
Dannon Baker -
Enis Afgan -
Jennifer Jackson -
mailing list